Differences

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

Link to this comparison view

documentation:2.1:kerberos [2019/01/15 15:55] (current)
Line 1: Line 1:
 +====== Kerberos ======
  
 +===== Presentation =====
 +
 +This documentation will explain how to use Active Directory as Kerberos server, and provide transparent authentication for one or multiple AD domains.
 +
 +You can use Kerberos ​ in LL::NG with the following authentication modules:
 +  * [[authkerberos|Kerberos]] (recommended):​ use Perl GSSAPI module, compatible with Apache and Nginx
 +  * [[authapache|Apache]]:​ use mod_auth_kerb or mod_auth_gssapi in Apache
 +
 +===== Prerequisites =====
 +
 +==== Example values ====
 +
 +We will use the following values in our examples
 +  * **EXAMPLE.COM**:​ First AD domain
 +  * **ACME.COM**:​ Second AD domain
 +  * **auth.example.com**:​ DNS of the LL::NG portal
 +  * **KERB_AUTH**:​ AD account to generate the keytab for LL::NG server
 +
 +==== Server time ====
 +
 +It is mandatory that LL::NG servers and AD servers have the same time. It is recommended to use NTP to do this.
 +
 +==== DNS ====
 +
 +The auth.example.com must be registered in the DNS server (which is Active Directory). The reverse DNS of auth.example.com **must** return the portal IP.
 +
 +<note tip>If you have a SSO cluster, you must setup a Virtual IP in cluster and register this IP in DNS.</​note>​
 +
 +==== SSL ====
 +
 +SSL is not mandatory, but it is strongly recommended. Your portal URL should be https://​auth.example.com.
 +
 +==== Web browser configuration ​ ====
 +
 +=== Firefox ===
 +
 +Type ''​about:​config''​ in a tab and search for ''​trusted''​. Then edit the property ''​network.negotiate-auth.trusted-uris''​ and set value ''​example.com''​.
 +
 +=== Internet Explorer ===
 +
 +Add ''​https://​auth.example.com''​ as trusted site.
 +
 +Check into security parameters that Kerberos authentication is allowed.
 +
 +===== Single AD domain =====
 +
 +==== Client Kerberos configuration ====
 +
 +On LL::NG server, edit ''/​etc/​krb5.conf'':​
 +
 +<file ini>
 +[libdefaults]
 + ​default_realm = EXAMPLE.COM
 + ​dns_lookup_kdc = false
 + ​dns_lookup_realm = no
 + ​ticket_lifetime = 24h
 + ​forwardable = yes
 + ​renewable = true
 +
 +[realms]
 + ​EXAMPLE.COM = {
 +  kdc = ad.example.com
 +  admin_server = ad.example.com
 + }
 +
 +[domain_realm]
 + ​.example.com = EXAMPLE.COM
 + ​example.com = EXAMPLE.COM
 +</​file>​
 +
 +You can check that Kerberos is working by trying to get a ticket for a user of the domain (for example coudot):
 +<​code>​
 +kinit coudot@EXAMPLE.COM
 +</​code>​
 +
 +You should be prompted to enter password. Then list the tickets:
 +
 +<​code>​
 +klist -e
 +</​code>​
 +
 +You should see a krbtgt ticket:
 +
 +<​code>​
 +Valid starting ​    ​Expires ​           Service principal
 +06/04/15 15:​43:​24 ​ 06/05/15 01:​43:​29 ​ krbtgt/​EXAMPLE.COM@EXAMPLE.COM
 +        renew until 06/05/15 15:43:24, Etype (skey, tkt): aes256-cts-hmac-sha1-96,​ aes256-cts-hmac-sha1-96
 +</​code>​
 +
 +You can then close the Kerberos session:
 +<​code>​
 +kdestroy
 +</​code>​
 +
 +==== Obtain keytab file ====
 +
 +You have to run this command on Active Directory:
 +
 +<​code>​
 +ktpass -princ HTTP/​auth.example.com@EXAMPLE.COM -mapuser KERB_AUTH@EXAMPLE.COM -crypto DES-CBC-MD5 -ptype KRB5_NT_PRINCIPAL -mapOp set -pass <​PASSWORD>​ -out c:​\auth.keytab
 +</​code>​
 +
 +<note important>​
 +The values passed in -crypto and -ptype depend on the Active Directory version and the windows version of the workstations. You can for example use RC4-HMAC-NT as crypto protocol if DES is not supported by workstations (this the case by default for Window 8 for example).
 +</​note>​
 +
 +The file ''​auth.keytab''​ should then be copied (with a secure media) to the Linux server (for example in ''/​etc/​lemonldap-ng''​).
 +
 +Change rights on keytab file:
 +<​code>​
 +chown apache /​etc/​lemonldap-ng/​auth.keytab
 +chmod 600 /​etc/​lemonldap-ng/​auth.keytab
 +</​code>​
 +
 +You can check the validity of the keytab file by trying to request a service ticket, and compare the result with the keytab content.
 +
 +Open a Kerberos session (like done in the previous step):
 +<​code>​
 +kinit coudot@example.com
 +</​code>​
 +
 +Request a service ticket:
 +<​code>​
 +kvno HTTP/​auth.example.com@EXAMPLE.COM
 +</​code>​
 +
 +The result of the command should be:
 +<​code>​
 +HTTP/​auth.example.com@EXAMPLE.COM:​ kvno = 3
 +</​code>​
 +
 +Read the service ticket:
 +<​code>​
 +klist -e
 +</​code>​
 +
 +You should see this kind of ticket:
 +<​code>​
 +06/04/15 16:​28:​49 ​ 06/05/15 02:​28:​11 ​ HTTP/​auth.example.com@EXAMPLE.COM
 +        renew until 06/05/15 16:28:07, Etype (skey, tkt): arcfour-hmac,​ arcfour-hmac
 +</​code>​
 +
 +You can close the Kerberos session:
 +<​code>​
 +kdestroy
 +</​code>​
 +
 +Now you can compare the above result with the same request done trough the keytab file:
 +<​code>​
 +klist -e -k -t /​etc/​lemonldap-ng/​auth.keytab
 +</​code>​
 +
 +The result of the command should be:
 +<​code>​
 +Keytab name: FILE:/​etc/​lemonldap-ng/​auth.keytab
 +KVNO Timestamp ​        ​Principal
 +---- ----------------- --------------------------------------------------------
 +   3 01/01/70 01:00:00 HTTP/​auth.example.com@EXAMPLE.COM (arcfour-hmac)
 +</​code>​
 +
 +The important things to check are:
 +  * KVNO must be the same
 +  * Principal names must be the same
 +  * Encryption types must be the same
 +
 +
 +===== Multiple AD domains =====
 +
 +==== Client Kerberos configuration ====
 +
 +The two domains must be defined in ''/​etc/​krb5.conf'':​
 +
 +<file ini>
 +[libdefaults]
 + ​default_realm = EXAMPLE.COM
 + ​dns_lookup_kdc = false
 + ​dns_lookup_realm = no
 + ​ticket_lifetime = 24h
 + ​forwardable = yes
 + ​renewable = true
 +
 +[realms]
 + ​EXAMPLE.COM = {
 +  kdc = ad.example.com
 +  admin_server = ad.example.com
 +  default_domain = EXAMPLE.COM
 + }
 + ​ACME.COM = {
 +  kdc = ad.acme.com
 +  admin_server = ad.acme.com
 +  }
 +
 +[domain_realm]
 + ​.example.com = EXAMPLE.COM
 + ​example.com = EXAMPLE.COM
 + ​.acme.com = ACME.COM
 + ​acme.com = ACME.COM
 +</​file>​
 +
 +You should then be able to open a Kerberos session on each domain:
 +<​code>​
 +kinit coudot@EXAMPLE.COM
 +klist -e
 +kdestroy
 +</​code>​
 +<​code>​
 +kinit coudot@ACME.COM
 +klist -e
 +kdestroy
 +</​code>​
 +
 +==== Obtain keytab file ====
 +
 +You need to obtain a keytab for each node on each domain. This means the ktpass commands should be run on both AD.
 +
 +Then you will have 2 keytab files for each node, for example:
 +  * node1-example.keytab
 +  * node1-acme.keytab
 +
 +You need to concatenate the keytab files, thanks to ''​ktutil''​ command:
 +<​code>​
 +ktutil
 +ktutil: read_kt node1-example.keytab
 +ktutil: read_kt node1-acme.keytab
 +ktutil: write_kt /​etc/​lemonldap-ng/​auth.keytab
 +ktutil: quit
 +</​code>​
 +
 +You can then remove the original keytab files and protect the final keytab file:
 +<​code>​
 +chown apache /​etc/​lemonldap-ng/​auth.keytab
 +chmod 600 /​etc/​lemonldap-ng/​auth.keytab
 +</​code>​
 +
 +===== Other resources =====
 +
 +You can check these documentations to get more information:​
 +  * [[http://​modauthkerb.sourceforge.net/​configure.html]]
 +  * [[http://​www.grolmsnet.de/​kerbtut/​]]