Troubleshooting Checklist for Windows Single Sign on

(For tips on troubleshooting Enfold Server itself or the Encontrol utility, see Troubleshooting Enfold Server).

If you are having problems initially configuring the service user, go to the User & Server Security reference.

If you are locked out of your Plone site because you changed authentication profiles, you will need to log on with your Zope account, not your domain user account. (Read the steps to access your Plone site after being locked out).

Configuring automatic login for Windows can be tricky. Here is a list of some things to check for:

Preliminaries

• ensure that your machine with Enfold Server is in the domain and you can login as a domain user. (The Active Directory administrator can confirm that).
• check the Windows Event Log, found at Start > Settings > Control Panel > Administrative Tools > Event Viewer. This will identify whether there are serious problems with the application.
• before testing that Windows single sign on works, you should initially use a cookie-based authentication profile (such as Active Directory Users with Cookie Authentication). When you use cookie-based authentication: remember:
  • You should also close the current browser and reopen.
  • You should login to the management port (i.e., http://localhost:8080/Plone) instead of a port proxied by a Proxy Server. (i.e., http://qehouston.local). You can set up Enfold Proxy or Squid later.
• If you are using trusted proxy authentication profile, single sign on (NTML Authentication) will take place on Internet Information Services (IIS) instead of Enfold Server. (See this explanatory diagram about Trusted Proxy and NTLM). Therefore, you should first verify that Enfold Server works without Trusted Proxy and only then use a trusted proxy authentication profile.

Browser

• Is the user signing onto the domain when logging onto Windows (User must be a member of the domain to sign on to it through Active Directory).
• Can the user sign on successfully when Enfold Server is configured to use a cookie-based authentication profile? (If no, that indicates an Active Directory problem).
• Are you trying to test the user on the same machine with the domain controller/Windows Server/Enfold Server? (Enhanced Security Internet Explorer on Windows Server 2003 has additional features that conflict with automatic login. It is a Windows component which is installed by default on Windows Server; it will need to be removed or disabled to allow single sign on to work on Internet Explorer. You may also wish to test the browser from a different machine that doesn't run Windows Server 2003.)
• Have you closed the browser? (It is recommended to close all browser windows, clear browser cache and restart the browser after making a change to authentication or groups).
• If you can't succeed on one browser (like Internet Explorer), can you succeed on another browser (like Firefox)? (Sometimes, because of caching and browser security issues, it helps to use a different browser).
• Are you using a browser which supports NTLM authentication (check Test in browser for information about how to do this in each browser).
• Have you tried testing Windows authentication with another domain user on the same machine or different machine?
• Have you tested the domain user's credentials on a different machine? (If a domain user on one machine can't sign onto one domain, but can sign in from a different machine, that suggests a browser issue).

Enfold Server

• Have you verified that another user on the domain can login successfully? (That could indicate problems with Active Directory or perhaps a problem with that specific user).

Active Directory

• If you go to Plone Site Setup --> Users & Groups and click the See All button, do you see a complete list of your domain users? (If no, this could indicate that your Windows domain is down or that your server is unable to reach the network. Another possibility: your Authentication Profile is configured incorrectly or your Windows domain was not automatically recognized. See also problems configuring the service user.
• Are you trying to do do Single Sign On to an Internet host (i.e., www.dummyhost.com) with your Windows domain account when your Windows domain is associated with another Internet host (i.e., www.theactualsite.com)? (For Single Sign On to work, the Internet host you type must match exactly the Internet host associated with the Windows domain on which Enfold Server was installed. If you want to sign on to a different Internet host not associated with the current Windows domain, that is an advanced configuration which is not currently supported by Enfold Server.)
• Have you made a change to Active Directory that is not being reflected in the user's browser when logging in? (If you delete a user or rename a group or create a group or delete one, the old settings will remain in the server's authentication cache for 10 minutes -- that's the default. You can speed the process by signing onto your Plone site as a Zope user or a user with Manager privileges. Then, go to Plone Control Panel --> Authentication Profiles and hit the button for Clear Authentication Cache at the bottom of this page).
• Are some of your domain users experiencing timeout issues on AD authentication? Check to see if the account which installed Enfold Server had local admin rights and was a member of the domain. Also check to see if the service user is a member of the Windows domain. (Timeout issues can occur if you are trying to run Enfold Server on a domain with Active Directory authentication and your service user is not a member of the Windows domain).

IIS/Proxy

• If using IIS and Trusted Proxy Authentication Profile, have you checked the box for Integrated Windows authentication and unchecked the box for Anonymous Web login? (Unchecking Anonymous Web login is required for NTLM authentication to succeed)

• If using Enfold Proxy(EP), have you verified that the proxy definition is associated with the correct IIS site? (Open EP, select the proxy definition, select Site tab, and make sure the correct Site is chosen from the dropdown box).

• If using a trusted proxy (i.e., if your Enfold Server uses a second machine for authentication---commonly Enfold Proxy on a second machine), have you

  • selected an authentication profile with "trusted proxy" in the name? (other profiles are not compatible when IIS/EP are handling the authentication).
  • confirmed that the IP address of the machine with the trusted proxy/Enfold Proxy is listed on the Trusted Proxy configuration menu? (See Configuring Trusted Proxy on Enfold Server).

See also: Enfold Server FAQ and Configuring the Windows service user .

Troubleshooting preparation

The first step is to set the Zope log to record "DEBUG" events. Debug mode is not recommended for production machines, but only for testing and troubleshooting). Open zope.conf and find:

<logfile>
path $INSTANCE/log/event.log
level info
</logfile>

Change it to:

<logfile>
path $INSTANCE/log/event.log
level debug
</logfile>

After restarting Zope, event.log will record much more information about all the above steps and will help to diagnose the issues detailed below.

Note

Troubleshooting authentication

Authentication is the first step in this process. Authentication problems will generally result in 'unexpected' behavior related to credentials. For example, if you are hoping to use NTLM authentication, but are presented with a HTTP authentication dialog, or see an 'Unauthorized' page, it is probably related to authentication.

Successful Windows authentication will log a debug message:

------
2006-11-29T20:13:43 DEBUG EnfoldWindowsPlugins extractCredentials has user 'username' ('username')
------

If you see such a message, the windows username and password (or NTLM credentials) have been accepted - so your problem may be related to the fetching of the user properties via the Active Directory.

Troubleshooting Active Directory user property issues

After authentication, the Active Directory is queried for user properties. There are generally two manifestations of problems in this area. Either:

• An error will be returned from the Active Directory code.
• No error will be returned, but user properties will not be set. For example, the email address, full name and groups will not be set for the member.

In both cases, the problem is likely to be related to the configuration of the Active Directory integration. In the first case (an explicit error), the configuration error is likely to relate to the specification of the distinguished name - if no server can be reached to perform the search, an error is returned. The second error is more subtle - a server could be contacted and a search was performed - however, no records were returned. This is currently not considered an error, but it is hoped that future versions of PAS will treat this condition as an error.

You can diagnose both these issues by performing the following steps: