UniTime ActiveDirectory Authentication

[shaftain]

I have setup UniTime in Eclipse on Windows and using blank-data database schema. The application is logging in successfully when I use admin as username and passwrod. But I am encountering "Authentication failed: Login Failure: all modules ignored." error when I try to login using LDAP credentials. As far as I could understand from the instructions on https://help.unitime.org/LDAP, I have added line "unitime.spring.context.security=securityContextLDAP.xml" in Tomcat's catalina.properties file. I have also made test application to check if LDAP is being authenticated on my machine and the test application is successfully authenticating LDAP users. Can anyone help me understand what I am missing?

[tomas-muller]

Setting up the LDAP authentication can be tricky. If you set the logging level for org.springframework.security.ldap to DEBUG, what messages/errors are you getting? Do you see any errors in Tomcat's log?

How do the parameters in the securityContextLDAP.xml match with what you have in your test application?

Also, please note that UniTime needs an external id of an LDAP authenticated user. If you do not have such an attribute (typically a university id), you can use the uid (or cn, or email for instance) instead. However, for the user to get a role, this external id must match the external id in the Timetable Magers, Instructors, Students, or Advisors. Authenticated users that do not have a special UniTime-role will get the No Role role (e.g., a user does not need a UniTime role to see a class schedule or request an event).

[shaftain]

The following messages appear when I enabled debugging of org.springframework.security.ldap

[02/15/23 19:40:54] DEBUG BindAuthenticator> Attempting to bind as samaccountname=username
[02/15/23 19:40:54] DEBUG DefaultSpringSecurityContextSource> Removing pooling flag for user samaccountname=username
[02/15/23 19:40:54] DEBUG BindAuthenticator> Failed to bind as sAMAccountName=username: org.springframework.ldap.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 52e, v2580

I was getting the same error when I first tried to test authentication using this code

public static boolean authenticate(String username, String password) {
	Hashtable<String, String> env = new Hashtable<>();
	env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
	env.put(Context.PROVIDER_URL, ldapUrl);
	env.put(Context.SECURITY_AUTHENTICATION, "simple");
	env.put(Context.SECURITY_PRINCIPAL, MessageFormat.format(LDAP_USER_DN_PATTERN, username) + "," + LDAP_DOMAIN);
	env.put(Context.SECURITY_CREDENTIALS, password);
	try {
		DirContext ctx = new InitialDirContext(env);
		ctx.close();
		LOGGER.log(Level.INFO, "LDAP authentication successful for user: {0}", username);
		return true;
	} catch (NamingException e) {
		LOGGER.log(Level.WARNING, "LDAP authentication failed for user: {0}", username);
		return false;
	}
}

Then I changed

env.put(Context.SECURITY_PRINCIPAL, MessageFormat.format(LDAP_USER_DN_PATTERN, username) + "," + LDAP_DOMAIN);

to

env.put(Context.SECURITY_PRINCIPAL, username + "@" + ldapDomain);

and the authentication started working without error.

I am unable to figure out where UniTime is doing the same thing.

Not sure about other errors except that I notice the following if it is a problem

[02/15/23 19:40:37] INFO  DefaultSpringSecurityContextSource>  URL 'ldap://10.99.0.17:389', root DN is ''
[02/15/23 19:40:37] INFO  AbstractContextSource> Property 'userDn' not set - anonymous context will be used for read-write operations

Regarding third para of your answer, I think our LDAP do not have external id attribute and also our network domain is lums.net whereas our email address suffix is lums.edu.pk. This creates authentication problem on currently deployed production instance of UniTime. Our systems team handle this issue by adding some exceptions in identity manager.

[tomas-muller]

I think that making the same change would mean updating the unitime.authentication.ldap.user-dn-pattern parameter to something like

unitime.authentication.ldap.user-dn-pattern={0}@ldapDomain

Where ldapDomain is what you have in that parameter ({0} is replaced by the username provided).

[shaftain]

Owing to my ignorance, I couldn't completely decipher your answer and have been trying different things. Currently I am stuck in the following:

When the control goes in this function:

org.springframework.security.ldap.authentication.BindAuthenticator
private DirContextOperations bindWithDn(String userDnStr, String username, String password, Attributes attrs) {
		BaseLdapPathContextSource ctxSource = (BaseLdapPathContextSource) getContextSource();
		DistinguishedName userDn = new DistinguishedName(userDnStr);
		DistinguishedName fullDn = new DistinguishedName(userDn);
		fullDn.prepend(ctxSource.getBaseLdapPath());
		logger.debug(LogMessage.format("Attempting to bind as %s", fullDn));
		DirContext ctx = null;
		try {
			ctx = getContextSource().getContext(fullDn.toString(), password);
			// Check for password policy control
			PasswordPolicyControl ppolicy = PasswordPolicyControlExtractor.extractControl(ctx);
			logger.debug("Retrieving attributes...");
			if (attrs == null || attrs.size() == 0) {
				attrs = ctx.getAttributes(userDn, getUserAttributes());
			}
			DirContextAdapter result = new DirContextAdapter(attrs, userDn, ctxSource.getBaseLdapPath());
			if (ppolicy != null) {
				result.setAttributeValue(ppolicy.getID(), ppolicy);
			}
			return result;
		}
		catch (NamingException ex) {
			// This will be thrown if an invalid user name is used and the method may
			// be called multiple times to try different names, so we trap the exception
			// unless a subclass wishes to implement more specialized behaviour.
			if ((ex instanceof org.springframework.ldap.AuthenticationException)
					|| (ex instanceof org.springframework.ldap.OperationNotSupportedException)) {
				handleBindException(userDnStr, username, ex);
			}
			else {
				throw ex;
			}
		}
		catch (javax.naming.NamingException ex) {
			throw LdapUtils.convertLdapException(ex);
		}
		finally {
			LdapUtils.closeContext(ctx);
		}
		return null;
	}

I have sAMAccountName=MyUsername stored in userDnStr variable. The application throws exception if I continue the execution. But if I change userDnStr value to MyUsername's distinguishedName as stored in ActiveDirectory which is CN=MyUsername,OU=MyDepartment,OU=MyEmployeeType,OU=Active Employees,OU=Entire Org,DC=org,DC=net the application executes few more steps without throwing exception i.e. ctx and attrs variables successfully gets InitialLdapContext and user attributes, respectively. The data these variables have obtained appear to correct. However, ppolicy couldn't obtain a meaningful data and has null stored in it. The result also seems to have some missing information i.e. base and referralUrl inside result do not have any values. I think these missing values again causes the application to throw exception and the authentication does not succeed.

I was wondering if you can guide me any further because I have tried myself a lot but nothing is working out.

[tomas-muller]

Ok, if the userDnStr is only sAMAccountName=MyUsername, the search base either has to be the rest (CN=MyUsername,OU=MyDepartment,OU=MyEmployeeType,OU=Active Employees,OU=Entire Org,DC=org,DC=net) or youw would need to use a search filter with (sAMAccountName={0}) instead of the user DN matching.

I did set up LDAP authentication against an Active Directory for an institution in Canada once, and we had to use a search filter with (sAMAccountName={0}) instead of the user DN matching (they also had different trees for faculty, students, and for staff). The spring security configuration was changed as follows (the ldapAuthProvider bean):

<beans:bean id="ldapAuthProvider" class="org.unitime.timetable.spring.ldap.SpringLdapAuthenticationProvider">
    <beans:constructor-arg>
        <beans:bean class="org.springframework.security.ldap.authentication.BindAuthenticator">
            <beans:constructor-arg ref="unitimeLdapContextSource"/>
            <beans:property name="userSearch">
                <beans:bean class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
                    <beans:constructor-arg value="${unitime.authentication.ldap.search-base}"/>
                    <beans:constructor-arg value="${unitime.authentication.ldap.search-filter:(sAMAccountName={0})}"/>
                    <beans:constructor-arg ref="unitimeLdapContextSource"/>
                    <beans:property name="searchSubtree" value="${unitime.authentication.ldap.search-subtree:true}"/>
                </beans:bean>
            </beans:property>
        </beans:bean>
    </beans:constructor-arg>
    <beans:property name="userDetailsContextMapper" ref="unitimeUserContextMapper"/>
</beans:bean>

We have also updated the ldap-server element, filling in manager-dn and manager-password.

    <ldap-server url="${unitime.authentication.ldap.url}" id="unitimeLdapContextSource"
    	manager-dn="${unitime.authentication.ldap.manager-dn}"
    	manager-password="${unitime.authentication.ldap.manager-password}"
    />

And they had the following properties set:

unitime.authentication.ldap.url=ldap://cmccdc2.cmccad.local:389
unitime.authentication.ldap.manager-dn=CN=ldapu,OU=Adm,OU=CMCC,DC=cmccad,DC=local
unitime.authentication.ldap.manager-password=fixme
unitime.authentication.ldap.search-base=DC=cmccad,DC=local
unitime.authentication.ldap.search-filter=(sAMAccountName={0})

But they have used their sAMAccountName attribute for their external ids in UniTime, so we have omitted the authorities populator part that is used to take the external id from some other attribute (bean using DefaultLdapAuthoritiesPopulator).

This is pretty much the extent of my knowledge of LDAP authentication when it comes to Active Directory.

[shaftain]

It resolved the authentication error and UniTime is now successfully authenticating from ActiveDirectory. Thanks you for the prompt responses and helpful suggestions regarding the errors I was encountering. Your support and assistance always helped a lot and this time too it resolved the issue.

I admire your dedication in maintaining the UniTime. Your work undoubtedly helped many users like myself.

Thank you once again for your help and support.