LDAP AD Authentication issue

Scott G, modified 10 Years ago. New Member Posts: 9 Join Date: 1/21/16 Recent Posts
Hey everyone! I am working with 6.2 CE GA6 and I have setup LDAP with Windows AD and have had no issues importing groups/users that are needed for this portal. I have no error trace when importing or authenticating, but authentication always fails with the AD user. I've exhausted all the threads on the forum dealing with LDAP authentication issues, but there were no clear answers to my problem. Here are my settings:

## Overrides in portal-ext.properties

users.screen.name.allow.numeric=true
users.screen.name.validator=com.liferay.portal.security.auth.LiberalScreenNameValidator
users.email.address.required=false

ldap.auth.enabled=true
ldap.auth.required=true
ldap.import.enabled=true
ldap.import.on.startup=true
ldap.import.interval=10
ldap.import.method=group
ldap.password.policy.enabled=true
ldap.import.user.password.enabled=false
ldap.export.enabled=false
ldap.export.group.enabled=false


## Preferences set in PortalPreferences table - I've narrowed the list to what is applicable

    <preference>
        <name>ldap.import.user.search.filter.20877</name>
        <value>(&amp;(sAMAccountType=805306368)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))</value>
    </preference>
    <preference>
        <name>ldap.user.mappings.20877</name>
        <value>emailAddress=mail[$NEW_LINE$]firstName=givenName[$NEW_LINE$]fullName=cn[$NEW_LINE$]group=memberOf[$NEW_LINE$]lastName=sn[$NEW_LINE$]middleName=middleName[$NEW_LINE$]password=userPassword[$NEW_LINE$]screenName=sAMAccountName</value>
    </preference>
    <preference>
        <name>ldap.auth.search.filter.20877</name>
        <value>(sAMAccountName=@screen_name@)</value>
    </preference>
    <preference>
        <name>company.security.auth.type</name>
        <value>screenName</value>
    </preference>


So I have setup the portal to authenticate using screen name and the AD user credential is getting imported into the screen name correctly. The auth filter is valid, so I am not sure what I am missing. I wanted to see the full debug trace when authenticating and turned the two ldap log level categories to 'ALL', but still do not see where the failure is occurring (No logging in the tomcat console). Can anyone assist?

Thanks,
Scott
Scott G, modified 10 Years ago. New Member Posts: 9 Join Date: 1/21/16 Recent Posts
I have been able to replicate my issue with a brand new instance of liferay. Here are the steps I used:
  • Shutdown Liferay and tomcat
  • Deleted Liferay.home directory
  • Dropped all tables in SQL Server database
  • Extracted Liferay
  • Created portal-ext.properties in new liferay.home directory (full properties file below)
  • Started Liferay tomcat and configured database to point to existing database (left everything as default except sample data and database config)
  • Once started, confirmed the LDAP group and all associated users were imported correctly. Made sure AD username was what was mapped to screen name. Noticed in DB that the password for all LDAP users was plain text 'test'
  • Logged out of omniadmin account and tried to log in with AD user and AD password - Authentication failed
  • Try to login in with AD user and password 'test' - Authentication failed
  • Shutdown Liferay tomcat
  • Commented out the omniadmin.users property
  • Started Liferay.
  • The default Test user is still able to successfully login. This tells me that even though LDAP authentication is required, LR is allowing non-ldap user to authenticate with LR and this is the not the expected behavior. Everything looks like it is setup correctly for my needs: (1) Successful import of LDAP group and users (2) User's passwords are not being imported from AD and instead using the password test as indicated from portal.properties

So really there are two issues regarding LR's LDAP configuration. 'Required' is not working as expected and LR is not authenticating with AD with respect to my current configuration in this release.

Here is the full 'portal-ext.properties' file:
##
## Company - Overrides Only
##
    company.security.auth.type=screenName

##
## Users - Overrides Only
##
    users.screen.name.allow.numeric=true
	users.screen.name.validator=com.liferay.portal.security.auth.LiberalScreenNameValidator
    users.email.address.required=false

##
## LDAP - Overrides Only
##
    ldap.auth.enabled=true
    ldap.auth.required=true
	
    ldap.import.enabled=true
    ldap.import.on.startup=true
    ldap.import.interval=10
	
    ldap.import.method=group

    ldap.password.policy.enabled=true
    ldap.import.user.password.enabled=false
	
    ldap.export.enabled=false
    ldap.export.group.enabled=false
	
    ldap.base.provider.url.0=ldap://dc1.xxxxxxxx.net:389
    ldap.base.dn.0=OU=Company Department,OU=Applications,DC=xxxxxx,DC=net
    ldap.security.principal.0=Account_with_access_to_base_dn
    ldap.security.credentials.0=password
	
	ldap.auth.search.filter.0=(sAMAccountName=@screen_name@)
	ldap.import.user.search.filter.0=(&amp;(sAMAccountType=805306368)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
	ldap.user.mappings.0=emailAddress=mail\nfirstName=givenName\nfullName=cn\njobTitle=title\nlastName=sn\nmiddleName=middleName\npassword=userPassword\nscreenName=sAMAccountName
	
	ldap.import.group.search.filter.0=(cn=SPECIFIC_SUB_DEPARTMENT)
	ldap.group.mappings.0=description=description\ngroupName=cn\nuser=member

##
## Passwords - Overrides Only
##
	passwords.encryption.algorithm=NONE
	
	
##
## Groups and Roles - Overrides Only
##	
    omniadmin.users=20198
    terms.of.use.required=false

Anyone see any glaring issues? The goal, obviously, is to always authenticate with AD and due to security governance, not import the passwords. I overrode the password encryption to make sure that the passwords were not being imported.

Thanks,
Scott
Scott G, modified 10 Years ago. New Member Posts: 9 Join Date: 1/21/16 Recent Posts
This issue has been resolved.

The issue is with the base dn chosen. I was using a base dn that is pertinent for all the subgroups within my org unit. This works fine when importing the groups and associated users, however, the actual authentication for those users are against that same base dn. Our AD setup is much different then all the LDAP Liferay examples. There is no such thing as a user cn or a group cn. All users are defined at the top level and groups are split into nested organizational units. To fix this, I changed the base dn to the base domain controller and adjusted the group filter appropriately. On the plus side, I learned a lot more about LDAP. Now I get to dive into permissions...

Thanks,
Scott
Scott G, modified 10 Years ago. New Member Posts: 9 Join Date: 1/21/16 Recent Posts
Spoke too quick....

New issue. Since I needed to revert all the way back to the base dc so I could authenticate the users, new users who are not members of the group or subgroups specified in the group import filter, are being automatically imported. I have tried to add the following to the user auth filter:
ldap.auth.search.filter.0=(&amp;(sAMAccountName=@screen_name@)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(memberOf:1.2.840.113556.1.4.1941:=OU=My Department,OU=Applications,DC=xxxxxx,DC=net))
I was hoping this would authenticate all users who are members, but unfortunately, it is not working the way I hoped.

Any ideas?

Thanks,
Scott