Our security teams is wanting to restrict Privileged users from being able to use NTLM authentication by utilizing the ‘Protected Users’ group in Active Directory for any ID’s deemed privileged accounts. When this was enabled previously it blocked the ability to authenticate with LDAP using the any ID’s that were in the ‘Protected users’ group.
We are trying to figure out what our alternative options are since the BigFix Console and WebUI both appear to be using NTLM authentication with LDAP integration. We are thinking that our only option might be SAML integration with Azure AD but we aren’t sure if that is our only option. Has anyone else had to go through anything like this or used Azure AD SSO for SAML authentication?
Here is some information about the Protected Users group if you need reference.
I’d expect you should still be able to logon to the Console with the “Use Windows Credentials” option, which would be a Kerberos authentication to the root server using your logged-on Windows account.
If your BESRootServer service is using a domain account rather than LocalSystem for its “log on as” Service entry, there are some steps you have to take with setspn to assign the Kerberos service to the domain account. That’s in the docs and here in the forum, if that’s your configuration we can help you find it.
The problem with that is that our Privileged credentials that we use with BigFix through LDAP aren’t the same accounts that we login to the machine with, because we don’t login into our work computers with privileged accounts. These accounts are for privileged functions like Deploying tasks to servers or administrative privileges on machines.
I see a forum post on using setspn but i’m not really sure that I understand how that sets it so that the user logging into the portal isn’t authenticating with NTLM. I’m also not seeing anything under the BigFix 10 documentation for using an SPN or using the setspn command.
Does “Run as other user” right-click option on the Console work? If you’re allowed to log on / run as using the protected account, you should be able to use “RUNAS” and then “Use Windows credentials”
I can test that in the thick console, but that wouldn’t really help us with the Webui scenario because there isn’t a “Use Windows credentials” for WebUI. They have to provide their credentials on Webui.
Just be aware that you won’t be able to use any AD Account for the REST API once you enable SAML. In case you have automation that run with a Protected User Account that could be another consideration.
I’d just note that part of the “Protected Users” configuration is specifically to block LDAP/LDAPS configuration. “Protected Users” basically can’t use anything but Kerberos authentication, and as far as I can see only to Microsoft services. A cursory search indicates that Protected Users can’t use DUO LDAP Gateway, or Apache’s mod_auth_ldap, or basically any other LDAP service.
We have a Domain service account that uses RestAPI to deploy installs and i’m trying to figure out if we implemented SAML if we would have to setup the account as a local bigfix operator. I’m guessing it would have to be a local operator.
I speculate it might be possible to actually do REST with SAML accounts, but your script would have to have SAML intelligence itself - which can vary by provider; for instance Okta publishes a Python toolkit for SAML clients on their service. But I’ve not had an opportunity to explore that at any length yet.
For now I think your safest bet is to use non-Protected Users for your BigFix auth, even if that means setting up a third AD account.
We have been running SAML via Okta for authentication and LDAP for roles for years, where on Okta-app side we even have MFA. It works perfectly fine. The problem with the accounts being different (normal vs privilleged) we address by accessing console via Citrix, where people can provide their privileged account. RestAPI does break with SAML but we just create all the RestAPI as “local” (BigFix accounts) and those work just fine.
Ok that was the other thing i was hoping wouldn’t break as we do have quite a few roles that are assigned via LDAP, so i’m glad to know that it doesn’t affect that. Thank you for this information.
I recommend segmenting accounts by needs and usecases. In my shop we admin-types have up to three additional, depending on what one does.
Normal user Domain account
(I leverage these accounts when assigning operator roles for MSP-type clients in BigFix.)
Member of domain workstation admins group; can join machines to the domain, and local administrator on user workstations.
“Remote Admin” account. Can RDP to servers. Which servers may also be limited by additional group memberships.
*(I leverage these accounts when assigning the Master Operator role in BigFix.)
“Server Admin” accounts. These are “Protected User” accounts. They can only login locally (or via Kerberos) on servers; local admin on servers, where allowed.
Our segmented accounts have different suffixes in the username field (e.g domain\username-xx, domain\username-yy). Rigorous adherence to the suffix naming scheme eases discussion and memory of which account to use when.
BigFix uses Active Directory via LDAP, with NTLM. If the user is logging into Windows with their RDP “Remote Admin” account, they can check the Console’s “Windows Session” box. (I use this mode myself.)
The roles would still work just fine and you can still assign the local RestAPI account to the roles you already have, the only thing it will require creating the local accounts equivalent to the domain RestAPI accounts you need and managing them manually then. That’s the bit that we are struggling a bit with - with LDAP you can force password expiration; accounts can change their own passwords; it is quite easily traceable; etc. With local accounts they can’t really change the password themselves, so it automatically becomes your task as the admin to periodically reset passwords and coordinate the update on their side.
