My employer's Jira setup uses an Active Directory connector to maintain the user database. Our license counts every enabled user that appears in the directory as a seat regardless of application permissions or ability to log-in. Let's rewrite Jira's Active Directory connector rules to better reflect who's really using the product.
The setup wizard uses a very broad LDAP query to find Jira users in Active Directory: (&(objectCategory=Person)(sAMAccountName=*)). This makes for simple setup at the cost of every user found in Active directory eating-up a license seat. As a consequence of firm silos between internal IT and app engineering, not enough folks knew that an Active Directory object is created for every user as part of HR on-boarding.
Our corporate INFOSEC policy requires passwords to expire after 90 days and Jira doesn't honor logins from users who have a "Change password next login" flag. Let's assume that users who haven't changed their passwords in 2019 can live without immediate access to Jira and just drop their usernames out of the directory completely.
Active Directory stores the last password reset time in the field pwdLastSet in LDAP's time format (Windows folks may recognize this as "NT time"). The good people at epochconverter.com provide a calculator for converting wall time to LDAP format, which let me turn "Jan 1 2019 00:00:00" into the LDAP timestamp "131907744290000000".
Our refined query for finding users in Active Directory will look like:
(&(objectCategory=Person)(pwdLastSet>=131907744290000000)(sAMAccountName=*))
Updating a test server's directory showed that 40% of the users registered in Jira disappeared in a puff of smoke after this change.
Oldest comments (0)