Question:
How do I enable Active Directory Authentication for my site?
Answer:
Our Active Directory implementation provides both authentication and authorization.
LDAP authentication may be retired in a future version of sfPMS. See KBA-01845: Microsoft Entra Authentication
Overview
There is a new tab in ICTool that has some settings. Once configured, any login ID with a backslash or @ is checked using a secure LDAPS client. If validated, the ID is then verified for membership in a designated Authorization group.
- Active Directory authentication is triggered by a backslash (\) or @ in the login ID (e.g., SPITFIREMGT\chrisdemo) or chrisdemo@ad.spitfiremanagement.com).
- Mixed authentication is supported (which means you can migrate sfPMS users all at once or piecemeal).
- Admin and our sfSupport logins can continue to use native authentication (or whatever you prefer).
- For an Active Directory authenticated account,
- the password, expiration, and other “common security criteria” in sfPMS become hidden and are automatically disabled. In other words, sfPMS defers to the LDAP provider.
- Password recover is disabled. The user is instructed to recover their active directory password.
Preparation
- Obtain license for this feature from Spitfire. A service fee is required for this feature.
- See the “migration” section below and plan your strategy. Use the sample migration sheet.
- In ICTool, on the sfPMS Authentication LDAP tab (shown below):
- Check the box to enable login.
- Enter the name of the LDAP server. ICTool guesses a default.
- Enter the domain context. ICTool guesses a default; multiple contexts are supported. If you have users in various domains, they may all need to be listed, separated by semicolons.
- Enter a Security Group (role) name that authorizes the authenticated user to access the sfPMS application. Nested roles are supported. In our testing it took (quite) a while for the Active Directory replication to update the LDAP database across to our test network. So you may wish to have some users in the intended role before starting. You could use “Domain Users”, but this would mean every domain account could log into sfPMS. We suggest something like “sfPMS Users”, and then potentially make other roles existing roles members of the “sfPMS Users” group. Get the idea?
- Consider using the login page note feature to remind users that the logins are changing (see KBA-01565).
- Consider enabling Google Authentication to allow single sign on. Backslashes are a nuisance on mobile device “keyboards”. Google Authentication is *not* authorization: A Google-supplied identity requires the user to log in once with their sfPMS identity so the two can be associated. Only then does the Google Identity allow single sign in. All actions are audited using the sfPMS identity.
Migration
As you can imagine, migration will require some planning. You have a choice:
- Cheaper: The email address directory attribute will be used to potentially match the identity to an existing identity in sfPMS. But, if the LDAP supplied email address is not already known in sfPMS, a new identity will be created and granted only the “everyone” and “LDAP Authorization” roles in sfPMS.
- Better: Use a worksheet something like this one to map sfPMS logins to Active Directory SAMs. The workbook creates a SQL update command. Run these to switch the user over to Active Directory authentication.
Note: Once switched, the only way to return to sfPMS authentication for a specific user is to
- Go to the sfPMS Contact Details for that user,
- Wipe out the login,
- Reassign a login without a backslash. (The Contact record is not lost—just the login ID and pw-hash data.)
Contact your implementer for assistance.
Additional Comments:
sfPMS uses a third party SSL enabled LDAP client. For comparison, online apps like Slack.com force you into a higher SLA with an upcharge of $72+ per user per year. Currently only Microsoft Active Directory using LDAPS is supported.
The LDAP connector BINDS using the credentials supplied by the user. This step always works, but some shops lock down access and the attempt to read the user’s groups throws an “Unknown Error” 0x80005000n. This is an access denied error and typically effects all users. Make sure that your web application pool is using AD credentials (a service account) and grant that service account the ability to read Active Directory objects.
By contrast Invalid Credentials with DSID-0C090447 means that the specific user’s password is invalid or has expired.
KBA-011642; Last updated: January 1, 2024 at 15:16 pm ;
Keywords: none