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
Next revision Both sides next revision
tutorial:adm:sso_ad_domain [2019/10/04 09:06]
kopro [Enable authentication in browsers] add information about automatic logon 		tutorial:adm:sso_ad_domain [2020/02/17 10:38]
poulm link to SSO tutorial tips
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 89: Line 91:
 </code> </code>
  
-Add Kerberos configuration and setting the ''REMOTE_USER'' header inside the **VirtualHost tag** in ''/etc/httpd/conf.d/ssl.conf'':+Add Kerberos configuration and setting the ''REMOTE_USER'' header inside the **VirtualHost tag** in ''/etc/httpd/conf.d/ssl.conf''. And exlude "/idm/api/v1/status" from authentication so everyone can access it:
 <code> <code>
        <Location /idm>        <Location /idm>
Line 103: Line 105:
  
        RequestHeader set REMOTE_USER %{REMOTE_USER}s        RequestHeader set REMOTE_USER %{REMOTE_USER}s
 +       
 +       <Location /idm/api/v1/status>
 + Satisfy Any
 +       </Location>
 </code> </code>
 This configuration enables **Negotiate** (the users logged in domain computer will be automatically authenticated - this must be enabled in the browser), as well as **Basic Auth** (the user, who is not logged in domain computer, will be first prompted for username and password with the message "Kerberos Login" and the credentials will be sent to AD for authentication). Negotiate can be disabled by KrbMethodNegotiate, Basic Auth can be disabled by KrbMethodK5Passwd. This configuration enables **Negotiate** (the users logged in domain computer will be automatically authenticated - this must be enabled in the browser), as well as **Basic Auth** (the user, who is not logged in domain computer, will be first prompted for username and password with the message "Kerberos Login" and the credentials will be sent to AD for authentication). Negotiate can be disabled by KrbMethodNegotiate, Basic Auth can be disabled by KrbMethodK5Passwd.
Line 176: Line 182:
   * ''krb5\_rd\_req() failed when verifying KDC'' followed by ''failed to verify krb5 credentials: Permission denied'': Bad permissions on the keytab file. All httpd processes must have ''read'' access to the keytab.   * ''krb5\_rd\_req() failed when verifying KDC'' followed by ''failed to verify krb5 credentials: Permission denied'': Bad permissions on the keytab file. All httpd processes must have ''read'' access to the keytab.
  
 +===== See also ===== 
 +[[tutorial:adm:sso_configuring_tips|Tips for configuring SSO on Windows (can be useful on Linux servers as well)]]
  • by apeterova