...

Microsoft Active Directory^® that supports memberOff attribute

General

Groupsearch

Microsoft Active Directory^® that supports memberOff attribute

...

• sos ==> it_operator
• apl ==> administrator,application_manage

...

An LDAP Browser can be used to get the correct values for the searchBase and the userSearchFilter. Perform a directory search with the values. You should find only one entry. 

Image Added

The searchBase is the value of the base DN (or ParentDN in the screenshot above).


Hint: if the attribute name in your environment is not the default memberOf then you can specify the name of the attribute with the groupNameAttribute key as described in the next section.

If the Account entries have the memberOf attribute

...

then you can skip this section and proceed with Using memberOf with

...

User Search.

...

Settings: 

• ldapRealm.searchBasegroupSearchBase 
• ldapRealm.groupNameAttribute
• ldapRealm.userSearchFilter

This approach looks for the Account entry and reads the memberOf attribute. This attribute is often used when, for example, configuring Microsoft Active Directory® LDAP servers. 

Define a userSearchFilter and a searchBase that will find the account (%s will be replaced by the Account name from the login without the domain part).

Example for User Search

• groupSearchFilter

When the memberOf attribute is not available for the Account then you can use the Group Search.

Define the groupSearchBase and the groupSearchFilter. For example:

• ldapRealm.groupSearchBase = ou=Groups
• ldapRealm.searchBase = ou=People,dc=sos
• ldapRealm.userSearchFilter groupSearchFilter = (uniqueMember=uid=%s)

Example for User Search in Active Directory®

• ldapRealm.searchBase = dc=example,ou=People,dc=com
• ldapRealm.userSearchFilter = (sAMAccountName=%s)

An LDAP Browser can be used to get the correct values for the searchBase and the userSearchFilter. Perform a directory search with the values. You should find only one entry. 

Image Removed

The searchBase is the value of the base DN (or ParentDN in the screenshot above).


Hint: if the attribute name in your environment is not the default memberOf then you can specify the name of the attribute with the groupNameAttribute key as described in the next section.

...

b) Using Group Search 

If the Account entries have the memberOf attribute then you can skip this section and proceed with Using memberOf with User Search. Settings: 

• ldapRealm.groupSearchBase 
• ldapRealm.groupNameAttribute
• ldapRealm.groupSearchFilter

After defining the Group Search the shiro.ini configuration file will look like this:

...

• sos)

Getting the value for the groupSearchBase

Identify the location where the groups are stored. This is your groupSearchBase.

Image Added

Image Added

Getting the value for the groupSearchFilter

Click one group Entry (in the screenshot, cn=apl) and see how the members are stored there.

Image Added

The groupSearchFilter is configured with attr=val where attr is name of the attribute and val is the content. In this example, the attr is uniqueMember and the val uid=%s,ou=People,dc=sos, where the userid is replaced with %s. This results in:

• ldapRealm.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)

Verifing the groupSearchFilter with the ldapSearch command


 ldapsearch -h localhost -p 389 -b "ou=Groups,dc=sos" -s sub "uniqueMember=uid=ur

...

,ou=People,dc=sos

...

" -x

This search should return the group entries the Account is a member of. Identify the attribute containing the group name that is to be used in the user roles mapping. This can be seen in the next listing

# extended LDIF
#
# LDAPv3
# base <ou=Groups,dc=sos> with scope subtree
# filter: uniqueMember=uid=ur,ou=People,dc=sos

...

...

# 

...

When the memberOf attribute is not available for the Account then you can use the Group Search.

Define the groupSearchBase and the groupSearchFilter. For example:

• ldapRealm.groupSearchBase = ou=Groups,dc=sos
• ldapRealm.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)

...

Getting the value for the groupSearchBase

Identify the location where the groups are stored. This is your groupSearchBase.

Image Removed

Image Removed

Getting the value for the groupSearchFilter

Click one group Entry (in the screenshot, cn=apl) and see how the members are stored there.

Image Removed

The groupSearchFilter is configured with attr=val where attr is name of the attribute and val is the content. In this example, the attr is uniqueMember and the val uid=%s,ou=People,dc=sos, where the userid is replaced with %s. This results in:

• ldapRealm.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)

Verifing the groupSearchFilter with the ldapSearch command


 ldapsearch -h localhost -p 389 -b "ou=Groups,dc=sos" -s sub "uniqueMember=uid=ur,ou=People,dc=sos" -x

This search should return the group entries the Account is a member of. Identify the attribute containing the group name that is to be used in the user roles mapping. This can be seen in the next listing

# extended LDIF
#
# LDAPv3
# base <ou=Groups,dc=sos> with scope subtree
# filter: uniqueMember=uid=ur,ou=People,dc=sos
# requesting: ALL
#
 
# sos, Groups, sos
dn: cn=sos,ou=Groups,dc=sos
description: Employees of SOS GmbH
objectClass: top
objectClass: groupofuniquenames
cn: sos
uniqueMember: uid=ur,ou=People,dc=sos
uniqueMember: uid=fTester,ou=People,dc=sos

# apl, Groups, sos
dn: cn=apl,ou=Groups,dc=sos
objectClass: top
objectClass: groupofuniquenames
cn: apl
uniqueMember: uid=ur,ou=People,dc=sos
uniqueMember: uid=fTester,ou=People,dc=sos
 
# search result
search: 2
result: 0 Success
 
# numResponses: 3
# numEntries: 2

Verifing the groupSearchBase and groupSearchFilter with an LDAP Browser

Image Removed

Now set the groupNameAttribute to the name of the attribute that contains the group name.

• ldapRealm.groupNameAttribute = cn

Hint: The complete content of this attribute must be used in the groupRolesMap attribute. Typical content of the attribute could be ou=Groups,dc=sos,cn=groupname .

...

If the roles are assigned with the JOC Account Manager (i.e. there is a [users] section in the shiro.ini configuration file) you can skip this chapter.

If the value of the member of the groups contains the Account name from the login then you can skip this chapter

Sometimes the values of the member do not contain the Account Name from the login but, for example, the cn of the Account. In this case you have to search for the Account first and then specify the name of the attribute that should be used instead of the Account name from the login .

To achieve this, specify a searchBase, a userSearchFilter and a userNameAttribute.

ldapRealm.searchBase = ou=People,dc=sos
ldapRealm.userSearchFilter = (uid=%s)

Verify by use of ldapSearch

This search should return the Account with the given Account name. Identify the attribute that should be used for substitution in the Group Search base if it is not the Account name from the login.

ldapsearch -h localhost -p 389 -b "ou=People,dc=sos" -s sub "uid=fTester" -x

# This should return the following result

# extended LDIF
#
# LDAPv3
# base <ou=People,dc=sos> with scope subtree
# filter: uid=fTester
# requesting: ALL
#

# fTester, People, sos
dn: uid=fTester,ou=People,dc=sos
mail: info@sos-berlin.com
uid: fTester
givenName: Fritz
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: Tester
cn: Fritz Tester

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

requesting: ALL
#
 
# sos, Groups, sos
dn: cn=sos,ou=Groups,dc=sos
description: Employees of SOS GmbH
objectClass: top
objectClass: groupofuniquenames
cn: sos
uniqueMember: uid=ur,ou=People,dc=sos
uniqueMember: uid=fTester,ou=People,dc=sos

# apl, Groups, sos
dn: cn=apl,ou=Groups,dc=sos
objectClass: top
objectClass: groupofuniquenames
cn: apl
uniqueMember: uid=ur,ou=People,dc=sos
uniqueMember: uid=fTester,ou=People,dc=sos
 
# search result
search: 2
result: 0 Success
 
# numResponses: 3
# numEntries: 2

Verifing the groupSearchBase and groupSearchFilter with an LDAP Browser

Image Added

Now set the groupNameAttribute to the name of the attribute that contains the group name.

• ldapRealm.groupNameAttribute = cn

Hint: The complete content of this attribute must be used in the groupRolesMap attribute. Typical content of the attribute could be ou=Groups,dc=sos,cn=groupname .

Anchor
substitution_of_the_username substitution_of_the_username

Substitution of the account name

If the roles are assigned with the JOC Account Manager using the Identity Service LDAP-JOC you can skip this chapter.

If the value of the member of the groups contains the Account name from the login then you can skip this chapter

Sometimes the values of the member do not contain the Account Name from the login but, for example, the cn of the Account. In this case you have to search for the Account first and then specify the name of the attribute that should be used instead of the Account name from the login .

To achieve this, specify a searchBase, a userSearchFilter and a userNameAttribute.

ldapRealm.searchBase = ou=People,dc=sos
ldapRealm.userSearchFilter = (uid=%s)

Verify by use of ldapSearch

ldapsearch -h localhost -p 389 -b "ou=People,dc=sos" -s sub "uid=fTester" -x

# This should return the following result

# extended LDIF
#
# LDAPv3
# base <ou=People,dc=sos> with scope subtree
# filter: uid=fTester
# requesting: ALL
#

# fTester, People, sos
dn: uid=fTester,ou=People,dc=sos
mail: info@sos-berlin.com
uid: fTester
givenName: Fritz
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: Tester
cn: Fritz Tester

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Verification by use of LDAP Browser

Perform a directory search with your LDAP client to check the User Search configuration. You should find only one Account entry with the given Account name.

Image Added

Then identify the name of the attribute that contains the value for substitution. For example:

• ldapRealm.userNameAttribute = cn

The configuration will look like this:

Examples and special configurations

Verification by use of LDAP Browser

Perform a directory search with your LDAP client to check the User Search configuration. You should find only one Account entry with the given Account name.

Image Removed

Then identify the name of the attribute that contains the value for substitution. For example:

• ldapRealm.userNameAttribute = cn

The configuration will look like this:

Examples and special configurations

...

Add the iniRealm to 

• securityManager.realms = $ldapRealm, $iniRealm

[users]
...
 
[main]
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.userDnTemplate = uid={0},ou=People,dc=sos

ldapRealm.groupSearchBase = ou=Groups,dc=sos
ldapRealm.contextFactory.url = ldap://centos6_9_ldap.sos:389
ldapRealm.groupNameAttribute = cn
ldapRealm.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)
ldapRealm.groupRolesMap = \
group1: it_operator, \
group2: administrator|application_manager
 
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver

cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager

securityManager.realms = $ldapRealm, $iniRealm
 
# Session timeout in milliseconds
securityManager.sessionManager.globalSessionTimeout = 900000

Behavior Notes:

• By default roles from the shiro ini are added to the roles of an authenticated LDAP user with the same name. This happens regardless of whether or not a password is set for the account in the shiro ini file. However, a number of options can be configured to modify this behavior. These are described in the Multi-Realm Authentication and Authorization article.

Example LDAP Configuration for Active Directory with mixed LDAP and Shiro Authentication

Login with sAMAccountName specified for domain\account or account@domain:

• ldapRealm.userDnTemplate = {0}

• Consider use of uppercase/lowercase spelling for domain and account

Add the ldapRealm and iniRealm like this: 

• securityManager.realms = $ldapRealm, $iniRealm

Add domain\account to the [users] section. Assign roles but omit passwords for LDAP authenticated users like this: 

• COMPANY\account = ,role [,role]

[users]
# Locally authenticated users (specified with a hashed password)
root = $shiro1$SHA-512$500000$W0oNBkZY9LRrRIGyc4z2Ug==$NcoU+ZFM9vsM0MeHJ3P5NJ0NdvJrK38qVnl7v7YG7p9o5ZJfMccugJsA9myJsTNx2BF5rbvA696UhTGdUtSnOg==,all


# LDAP authenticated users (specified without a password)
COMPANY\homer = ,all
COMPANY\alice = ,all
 
[main]
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm


# Realm for Domain company.local
# -------------------------------
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.contextFactory.url = ldap://company.local:389


#    users can login with COMPANY\account and account@COMPANY.local where the account maps to the sAMAccountName
ldapRealm.userDnTemplate = {0}
ldapRealm.rolePermissionResolver = $rolePermissionResolver
# -------------------------------


# Authentication via domains ite.local, domain.local and via shiro.ini [users] section
securityManager.realms = $ldapRealm, $iniRealm


passwordMatcher = org.apache.shiro.authc.credential.PasswordMatcher
iniRealm.credentialsMatcher = $passwordMatcher


cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager


# Session timeout in milliseconds
securityManager.sessionManager.globalSessionTimeout = 1800000

Example LDAP Configuration with several LDAP Servers

LDAP configuration with several LDAP servers is achieved by defining more than one LDAP realm as shown in the next code block.

Define two realms and assign them like this:

• securityManager.realms = $ldapRealm1, $ldapRealm2

[main]
ldapRealm1 = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm1.userDnTemplate = uid={0},ou=People,dc=sos
ldapRealm1.groupSearchBase = ou=Groups,dc=sos
ldapRealm1.contextFactory.url = ldap://centos6_9_ldap.sos:389
ldapRealm1.groupNameAttribute = cn
ldapRealm1.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)
ldapRealm1.groupRolesMap = \
group1: it_operator, \
group2: administrator|application_manager

ldapRealm2 = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm2.userDnTemplate = uid={0},ou=People,dc=sos
ldapRealm2.groupSearchBase = ou=Groups,dc=sos
ldapRealm2.contextFactory.url = ldap://anotherHost:389
ldapRealm2.groupNameAttribute = cn
ldapRealm2.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)
ldapRealm2.groupRolesMap = \
group1: it_operator, \
group2: administrator|application_manager
 
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm1, $ldapRealm2

cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager

# Session timeout in milliseconds
securityManager.sessionManager.globalSessionTimeout = 900000

A full shiro.ini example with Group Search 

[main]
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.userDnTemplate = uid={0},ou=People,dc=sos
ldapRealm.groupSearchBase = ou=Groups,dc=sos
ldapRealm.contextFactory.url = ldap://centos6_9_ldap.sos:389 
ldapRealm.groupNameAttribute = cn
ldapRealm.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)
ldapRealm.groupRolesMap = \
group1: it_operator, \
group2: administrator|application_manager

rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager

# Session timeout in milliseconds
securityManager.sessionManager.globalSessionTimeout = 900000

A full shiro.ini example with Group Search where the member attribute does not contain the account name but the common name

[main]
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.userDnTemplate = uid={0},ou=People,dc=sos
ldapRealm.groupSearchBase = ou=Groups,dc=sos
ldapRealm.contextFactory.url = ldap://centos6_9_ldap.sos:389 
ldapRealm.groupNameAttribute = cn
ldapRealm.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)
ldapRealm.searchBase = ou=People,dc=sos
ldapRealm.userNameAttribute = cn
ldapRealm.userSearchFilter = (uniqueMember=uid=%s,dc=example,dc=com)
ldapRealm.groupRolesMap = \
group1: it_operator, \
group2: administrator|application_manager

rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager

# Session timeout in milliseconds
securityManager.sessionManager.globalSessionTimeout = 900000

A full shiro.ini example with memberOf in the account record

[main]
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.contextFactory.url = ldap://centos6_9_ldap.sos:389 
ldapRealm.userDnTemplate = uid={0},ou=People,dc=sos
ldapRealm.searchBase = ou=People,dc=sos
ldapRealm.userSearchFilter = (uid=%s)
ldapRealm.groupRolesMap = \
group1: it_operator, \
group2: administrator|application_manager

rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager

# Session timeout in milliseconds
securityManager.sessionManager.globalSessionTimeout = 900000

A public LDAP Server for testing the connection

An online public LDAP server which can be accessed using a relatively simple configuration is available from Forum Systems. This server can be used to set up a test environment with LDAP authentication. In this article we will refer to the authentication of two user accounts on this server - gauss and newton - that are each members of a different LDAP group as shown in the following table:

To implement the authentication configuration - or realm - for accessing this public LDAP server, add the following lines to the [main] section of the shiro.ini file:

...

...

...

A public LDAP Server for testing the connection

An online public LDAP server which can be accessed using a relatively simple configuration is available from Forum Systems. This server can be used to set up a test environment with LDAP authentication. In this article we will refer to the authentication of two user accounts on this server - gauss and newton - that are each members of a different LDAP group as shown in the following table:

Save the modified shiro.ini file. (It is not required to restart the Jetty web server.)

You will now be able to use JOC Cockpit to authenticate the two User Account name:password combinations listed in the table above with the LDAP server.

The Shiro authentication (using, for example, the default root:root User Account) will still be active alongside the LDAP accounts listed above.

The LDAP group memberships will be mapped to the default Roles configured in the shiro.ini [roles] section as can be seen in lines 15-17 of the code listing above. This can be checked in the JOC Cockpit by looking at the Permissions section of the relevant User Profiles - the User Account gauss, for example, will have all permissions.

Logging

References

• JS7 - Logging
  
  • JS7 - Log Files and Locations
  • JS7 - Log Levels and Debug Options

...