<@U01BW3YRCTA> Is seeing some odd behavior when at...
# fleet
@Dan Achin Is seeing some odd behavior when attempting to enroll new hosts using osquery flags: We recreated the osquery.flags and the enroll secret files under
and now we see the client trying to communicate with Fleet when running:
"C:\Program Files\osquery\osqueryd\osqueryd.exe" --flagfile="C:\Temp\osqueryconf\osquery.flags" --verbose --tls_dump
To me this validates that the service was in fact skipping the flags file. Progress! However, we are now getting an enrollment error –
Copy code
<https://fleet.xxxx.net:443/api/v1/osquery/enroll> (No node key returned from TLS enroll plugin) retrying...
"error": "enroll failed: no matching secret found",
"node_invalid": true
We’ve triple checked the enroll secret value (which I took straight from Fleet), checked for whitespace, etc but to no avail. Here’s what the error on Fleet’s side looks like:
Copy code
2022-03-10T19:54:06.128619+00:00 <http://xxxx.xxxx.net|xxxx.xxxx.net> fleet: {"component":"service","err":"enroll failed: no matching secret found","host_identifier":"xx-xx-xx-xx-xx","ip_addr":"xxx.x.x.x:xxxxx","level":"info","method":"EnrollAgent","took":"1.789708ms","ts":"2022-03-10T19:54:06.128302224Z","x_for_ip_addr":"xx.xxx.xx.x"}
👀 1
Flags File:
@Dan Achin Can you try removing the quotes from the path for the
flag and let me know if that changes things for you?
🙏 1
I would try using env var as enroll secret to by-pass any issues reading those files (some sneaky permissions thing..) rather than
use the env var flag:
and then set
Copy code
set ENROLL_SECRET=foobarsecret
Thanks, will try those. For those that weren't directly troubleshooting with us earlier today, it's worth noting that we have ~30k hosts that work fine and it's just one team having issues with Windows systems. The fact that we got farther along in the debug (vs just exiting) and are now communicating with Fleet, shows that we must not have been able to read the osquery.flags file when it existed under Program Files, even though the permissions looked correct and other internal teams are not having the issue.
👍 1
Looks like removing the quotes around the secret file path may have worked
🦜 1
yep, that worked! We have to figure out where we want to put the files now and it's strange that our original location worked fine on some windows systems and not these...but at least we have a path forward. Thanks!
Excellent! That's definitely an odd one as well, but I'm glad you've got a good path forward.
👍 1