KBA-01642: Using LDAP Active Directory for Authentication


How do I enable Active Directory Authentication for my site?


Our Active Directory implementation provides both authentication and authorization.


There is a new tab in ICTool that has some settings. Once they are “right”, any login ID with a backslash is checked using a secure LDAP client. If validated, the ID is then verified for membership in a designated Authorization group. Logins with an @ are also checked against LDAP.

  • Active Directory authentication is triggered by a backslash (\) in the login ID (e.g., SPITFIREMGT\chrisdemo) or an @ (e.g., 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.


  1. Obtain license for this feature from Spitfire.  A service fee is required for this feature.
  2. See the “migration” section below and plan your strategy.   Use the sample migration sheet.
  3. In ICTool, on the sfPMS Authentication LDAP tab (shown below):
    1. Check the box to enable login.
    2. Enter the name of the LDAP server. ICTool guesses a default.
    3. 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.
    4. Enter a 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?
  4. Consider using the login page note feature to remind users that the logins are changing (see KBA-01565).
  5. 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.

LDAP Setup


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” role 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.

KBA-011642; Last updated: September 19, 2017 at 12:15 pm ;
Keywords: none