SSO - configuring tips for Windows

This page contains tips and trick we have used to get SSO for CzechIdM on Windows working. Some are certainly relevant even when setting up SSO on Linux servers. This is not a how-to guide; rather, the how-to guide can be found here. These are just some tips based on our experience with using this guide. The guide will be referenced throughout this text. You should also use the tutorial on this wiki.

As said in the guide in the link above, you will need to create a technical user that Tomcat will use to find accounts in AD (the Tomcat service will run under this user). You will also need to have some testing user with whom you can log in to AD. Also, you will need to have a group in AD defined whose members can use SSO. (This may not be necessary but we couldn't get it to work without using the group.) Ask the admin of the AD to create the users and the group in one location. We had them all created in CN=Users. Later, they can be moved elsewhere as required by the AD admin but to avoid any issues with permissions or anything else, have them created in CN=Users.

As you can see in the guide, there are a number of configation files you need to get SSO working. The guide supplies sample files you can use.

You will need the following config files:

• jaas.conf which contains the path to the generated keytab and the name of the server and domain (HTTP/FQDN@REALM)
• krb5.ini which you should setup just as shown in the guide
• server.xml in which you should edit the content of <Engine name="Catalina" defaultHost="localhost">. userBase is the DN of the container with users who can use SSO (you can just specify the DC), roleBase specifies the DN of the container in which the group whose members can use SSO to authenticate is located (again, you can just specify the DC). We also had to comment out this piece of code which is not mentioned in the guide:

<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
               resourceName="UserDatabase"/>
      </Realm>

• web.xml which you should setup just as shown in the guide. The role-name should contain DN of the group whose members can use SSO to authenticate.

IdM is a large application and it takes several minutes for it to start on Windows. You will likely need to stop and start Tomcat many times. Instead of using IdM to test SSO, use the Sample app which can be downloaded here.

Once started, you should see a log-in dialog window such as this one:

If you log in successfully, you will see the main app:

If you then go to "To a JSP page", you should see the DN of the user with whom you logged in and the DN of the groups whose member the user is.

This is sufficient to debug the SSO settings and saves a lot of time otherwise spent waiting for IdM to load.

We couldn't get SSO working on Firefox and we didn't try any other browser with the exception of Internet Explorer. This is unfortunate since IE doesn't properly tell you what's wrong and always show you that a page is unavailable which is completely useless.

Be sure to check the tutorial on wiki for IE configuration. Just be aware that it is possible that you won't see the domain name of the server in trusted sites if every server in the domain is added in trusted sites as a global setting. It is also possible that you will have to set up some proxy, the client should be able to help with this configuration.

There are numerous issues that can arise and to identify them, you should enable every debug option available. Some are already mentioned in the guide but there are many more. Apart from the ones mentioned in the guide, enable the following as seen in the screenshots:

Modify your tomcat logging.properties (temporarily):

#change to ALL (or FINE at least) from default or previous value:
1catalina.org.apache.juli.AsyncFileHandler.level = ALL

#add temporarily
org.apache.catalina.realm.level = ALL
org.apache.catalina.realm.useParentHandlers = true
org.apache.catalina.authenticator.level = ALL
org.apache.catalina.authenticator.useParentHandlers = true

Once you are done setting SSO up, don't forget to turn these off! They will make the log gigantic.

If you turn on these debug options, you will see a number of error in the stderr log. Some of them appear even if SSO is working and you need not worry about them:

• Unable to login as the service principal: java.security.PrivilegedActionException: GSSException: Defective token detected
• org.apache.catalina.authenticator.AuthenticatorBase.invoke Failed authenticate() test
• org.apache.catalina.authenticator.SpnegoAuthenticator.doAuthenticate Unable to login as the service principal
• org.apache.catalina.authenticator.SpnegoAuthenticator.doAuthenticate No authorization header sent by client

These appear on Windows even if SSO works fine.

When you create keytab file for the technical user and there is any error, remove the keytab user before you create the keytab file again. (Otherwise kerberos doesn't work and there's no explaining error.)

How keytab and test users were created for one of the customers (it's non-public ticket): https://redmine.bcvsolutions.eu/issues/18946#note-15

It's genaraly described at (already mentioned above): https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w

On Linux servers, IdM will not let you to log into IdM if you have the superAdminRole assigned. On Windows servers, this is different and you can access IdM via SSO even with superAdminRole.