Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
tutorial:adm:sso_ad_domain [2020/01/13 12:01]
doischert
tutorial:adm:sso_ad_domain [2020/06/12 16:27]
apeterova
Line 2: Line 2:
  
 CzechIdM supports Single-Sign-On of the AD domain users. The mechanism uses web server, which handles the Kerberos authentication and provides the login of the authenticated user in the HTTP header. Then CzechIdM processes this header and authenticates the user automatically. CzechIdM supports Single-Sign-On of the AD domain users. The mechanism uses web server, which handles the Kerberos authentication and provides the login of the authenticated user in the HTTP header. Then CzechIdM processes this header and authenticates the user automatically.
 +
 +<note important>The SSO implementation works by looking up a username returned by Kerberos in IdM. This means that the user must have the same sAMAccountName in AD and username in IdM. Also, AD is not case-sensitive but IdM is, i. e., if your sAMAccountName is "jnovak", you can log in to AD as "JNovak" but this is not the case in IdM. **Make sure that usernames in IdM are the same as sAMAccountNames in AD, otherwise, SSO will fail.**</note>
  
 If the user is the Application Admin (e.g. has assigned the role superAdminRole), SSO authentication is disabled for security reasons. If the user is the Application Admin (e.g. has assigned the role superAdminRole), SSO authentication is disabled for security reasons.
Line 154: Line 156:
   * The keytab shouldn't be generated with only some ciphers, so use ''-crypto all'' in the command as above.   * The keytab shouldn't be generated with only some ciphers, so use ''-crypto all'' in the command as above.
  
-Usual messages in Apache error log:+Usual messages in Apache error logs:
   * ''krb5\_get\_init\_creds\_password() failed: Cannot contact any KDC for requested realm'': make sure that DC in /etc/krb5.conf kdc communicates on port 88:   * ''krb5\_get\_init\_creds\_password() failed: Cannot contact any KDC for requested realm'': make sure that DC in /etc/krb5.conf kdc communicates on port 88:
 <code bash> <code bash>
Line 162: Line 164:
   * ''krb5\_get\_init\_creds\_password() failed: Preauthentication failed'': the given user has different password.   * ''krb5\_get\_init\_creds\_password() failed: Preauthentication failed'': the given user has different password.
   * ''gss\_accept\_sec\_context() failed: No credentials were supplied, or the credentials were unavailable or inaccessible (, Unknown error)'': the client doesn't trust the address of IdM, i.e. it isn't in Trusted sites in Internet Explorer.   * ''gss\_accept\_sec\_context() failed: No credentials were supplied, or the credentials were unavailable or inaccessible (, Unknown error)'': the client doesn't trust the address of IdM, i.e. it isn't in Trusted sites in Internet Explorer.
 +  * ''gss\_accept\_sec\_context() failed: An unsupported mechanism was requested (, Unknown error)'': the client doesn't trust the address of IdM, i.e. it isn't in Trusted sites in Internet Explorer. (probably)
 +  * ''request failed: error reading the headers'' (and HTTP response 400): This happens to users who are members of many AD groups (e.g. more than 100) and use IE. More precisely: the Authorization header (holding Kerberos ticket) is longer than the max size of HTTP headers in the Apache webserver. Some browsers, e.g. Chrome, cuts off the tickets, but IE doesn't. You may increase the limit of the header size in Apache HTTP Server by the [[https://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize|LimitRequestFieldSize]] directive. However, the limit may be also on the application server (Apache Tomcat, JBoss). Then you can unset the header so it's not proxied to the application server - put ''RequestHeader unset Authorization'' in the ''/etc/httpd/conf.d/ssl.conf''.
   * ''failed to verify krb5 credentials: Key table entry not found'': something is wrong with the keytab. Try to compare its version (KVNO) and the version of Kerberos ticket:   * ''failed to verify krb5 credentials: Key table entry not found'': something is wrong with the keytab. Try to compare its version (KVNO) and the version of Kerberos ticket:
 <code> <code>
Line 181: Line 185:
  
 ===== See also ===== ===== See also =====
-[[9.7:adm:tips_for_configuring_sso_on_windows|Tips for configuring SSO on Windows (can be useful on Linux servers as well)]]+[[tutorial:adm:sso_configuring_tips|Tips for configuring SSO on Windows (can be useful on Linux servers as well)]]
  • by apeterova