Apache Syncope and Active Directory SSO: OpenAM configuration

This is the first post of a series on the same topic: an Apache Syncope overlay to perform single sign on between Active Diretory and Apache Syncope Console.

In this articles, we will analyze the different steps to have an user that, after his authentication on Windows PC, can access the Apache Syncope admin web console without further authentication.

Environment

• Windows Server 2008 R2: acacia.fabioad.controller.tirasa.net
• AD domain:fabioad.controller.tirasa.net:389
• Apache Syncope (port 9080) and OpenAM (port 8080), in two different Tomcat on the same Debian server: joda.tirasa.net

Overall goal: Single Sign On from Active Directory to Apache Syncope

• Authentication on Windows PC with an Active Directory user;
• Go to http://joda.tirasa.net:9080/syncope-console;
• Use of Syncope Console with same user previously authenticated without further authentication.

This post goal: OpenAM configuration

Pre-requisite

• OpenAM correctly installed

Windows Desktop SSO authentication module configuration

To obtain final goal we decide to use Windows Desktop SSO authentication module to get, easily, the single sign on between the Active Directory server and OpenAM. We will use OpenAM agent into Apache Syncope Console webapps. So, to do module configuration we have to follow next steps:

1. Create an AD user that "represents" OpenAM: openam / password
2. Associate a keytab to be used in the OpenAM authentication module:

    ktpass /out joda.HTTP.keytab /mapuser openam /pass password /princ HTTP/joda.tirasa.net@FABIOAD.CONTROLLER.TIRASA.NET /ptype KRB5_NT_PRINCIPAL /Target  FABIOAD.CONTROLLER.TIRASA.NET 

3. Copy the generated keytab on Debian server and configure authentication module; this is my configuration, created by the ssoadm command:

    ./ssoadm create-auth-instance -m AD -t AD -u amadmin -f pwdFile -e / 

   and then

    ./ssoadm update-auth-instance -e / -m AD -u amadmin -f pwdFile -a "iplanet-am-auth-ldap-server=srv-dctest.adtest.lan:389" "iplanet-am-auth-ldap-base-dn=ou=domain,dc=adtest,dc=lan" "iplanet-am-auth-ldap-bind-dn=cn=administrator,cn=users,dc=fabioad,dc=controller,dc=tirasa,dc=net" "iplanet-am-auth-ldap-bind-passwd=password" "iplanet-am-auth-ldap-user-naming-attribute=sAMAccountName" "iplanet-am-auth-ldap-user-search-attributes=sAMAccountName" "iplanet-am-auth-ldap-user-search-attributes=userprincipalname" "iplanet-am-auth-ldap-return-user-dn=false" 

   Same result with console configuration:

    Service Principal: HTTP/joda.tirasa.net@FABIOAD.CONTROLLER.TIRASA.NET Keytab File Name: /home/tirasa/keytab/joda.HTTP.keytab Kerberos Realm: FABIOAD.CONTROLLER.TIRASA.NET Kerberos Server Name: acacia.fabioad.controller.tirasa.net Return Principal with Domain Name: false Authentication Level: 0 

4. Configure browser (in this case IE) to pass kerberos token:
   1. Internet Options > Advanced > Security.
   2. Select Integrated Windows Authentication option. (default)
   3. On Tab Security >Local Internet.
   4. Select Custom Level in User panel, and select Automatic Logon Only in Intranet Zone option.
   5. Open Sites and select all the
   6. Click on Advanced and add joda.tirasa.net url.

Active directory data store configuration

After authentication module configuration, we have to configure the active directory data store, so that OpenAM can obtain user profile after successful authentication.
This is my data store configuration created by ssoadm command:

 ./ssoadm create-datastore -e / -m AD -t LDAPv3ForAD -u amAdmin -f pwdFile -a "sunIdRepoAttributeMapping=cn=cn" "sunIdRepoAttributeMapping=userPassword=unicodePwd" "sunIdRepoAttributeMapping=sn=sn" "sunIdRepoAttributeMapping=uid=sAMAccountName" "sun-idrepo-ldapv3-config-ldap-server=fabioad.controller.tirasa.net:389" "sun-idrepo-ldapv3-config-authid=FABIOAD\Administrator" "sun-idrepo-ldapv3-config-authpw=password" "sun-idrepo-ldapv3-config-organization_name=cn=users,dc=fabioad,dc=controller,dc=tirasa,dc=net" "sun-idrepo-ldapv3-config-users-search-attribute=userPrincipalName" "sun-idrepo-ldapv3-config-createuser-attr-mapping=cn=cn" "sun-idrepo-ldapv3-config-createuser-attr-mapping=userPassword=unicodePwd" "sun-idrepo-ldapv3-config-createuser-attr-mapping=sn=sn" "sun-idrepo-ldapv3-config-createuser-attr-mapping=uid=sAMAccountName" "sun-idrepo-ldapv3-config-groups-search-attribute=sAMAccountName" "sun-idrepo-ldapv3-config-group-container-name=sAMAccountName" "sun-idrepo-ldapv3-config-group-container-value=" "sun-idrepo-ldapv3-config-people-container-name=sAMAccountName" "sun-idrepo-ldapv3-config-people-container-value=" "sun-idrepo-ldapv3-config-auth-naming-attr=sAMAccountName" "sun-idrepo-ldapv3-config-psearchbase=cn=users,dc=fabioad,dc=controller,dc=tirasa,dc=net 

Focus

This is probaby the less interesting phase from a technical point of view.

Maybe the only very interesting thing is the ktpass command used to create user keytab because googling to right solution we haven't find a definitive guide and all the guides suggest us to execute at least two commands. We made the same thing with one command. Ah! In the previous ktpass command, fabioad.controller.tirasa.net is the hostname of the windows server where the active directory server works.

0 VOTINot rated yet