Tags:
authentication1Add my vote for this tag ldap1Add my vote for this tag windows1Add my vote for this tag create new tag
, view all tags
ALERT! NOTE: This is a SupplementalDocument topic which is not included with the official TWiki distribution. Please help maintain high quality documentation by fixing any errors or incomplete content. Put questions and suggestions concerning the documentation of this topic in the comments section below! Use the Support web for problems you are having using TWiki.

Windows 2003 Authentication using Kerberos and mod-auth-kerb

This is a discussion of the TWiki I setup on linux that transparently authenticates Windows users. There were a few snags that required sifting through many websites. This is my effort to improve that experience for others.

Our Information

For this explanation I'll use sample data - replace with your own.

  • Active Directory/DNS domain: acme.local
  • Windows 2003 Server: win2k3.acme.local
  • Linux/TWiki Server: wikisvr.acme.local
  • Username in AD: wikikerb

Setup TWiki

I am running Ubuntu so I installed TWiki and Apache using the steps in TWikiOnUbuntu.

Setup Kerberos

Install MIT Kerberos. On Ubuntu the package manager can install this:

sudo apt-get install krb5-user

The dependencies for this package will provide the rest of the required files.

Edit /etc/krb5.conf

[libdefaults]
    default_realm = ACME.LOCAL

[domain_realm]
    acme.local = ACME.LOCAL
[realms]
     ACME.LOCAL = {
                      kdc = win2k3.acme.local
                      admin_server = win2k3.acme.local

Test your Kerberos configuration so far:

  • Ensure that you can ping between the Windows 2003 server and the linux server in both directions and using both the fully-qualified domain name (win2k3.acme.local) and the IP address.

Note: You must be able to ping your Windows 2003 KDC using the fully-qualified domain name from the linux host. In the unlikely event you have mDNS enabled this will fail if your Active Directory domain ends in .local. If you try to work around the name resolution issue by entering the IP address in krb5.conf, the next test will succeed but Apache authentication will fail later with "No principal in keytab matches desired name" in the Apache error log.

  • In a shell type kinit username@ACME.LOCAL, entering an Active Directory username you know. If it is successful it will ask for the account's password and then exit without an error. Use klist to view the Kerberos ticket that was just added to the machine.

Setting up a keytab file

Now switch to your Windows 2003 server and create a user account that will represent the HTTP service on the linux server. Let's use wikikerb. We will use ktpass from the Windows 2003 Support Kit to create a keytab file the linux server will need. At the command line, enter

ktpass /out c:\my.keytab /mapuser HTTP-user@acme.local /princ HTTP/wikisvr.acme.local@ACME.LOCAL /crypto RC4-HMAC-NT /pass passw0rd /ptype KRB5_NT_PRINCIPAL

Note: Even if you created a CNAME to redirect wiki.acme.com to wikisvr.acme.local, and all your users will be entering wiki.acme.com, the principal name ( -princ) must still use the canonical DNS name. This will not affect what your users need to type to get to the site.

Copy the keytab file to the linux server and place it in /etc/apache2.

Test the keytab file like so:

kinit -k -t /etc/apache2/http.keytab HTTP/wikisvr.acme.local

This should exit without any error messages, and this Kerberos ticket will now appear in klist. If you want to purge the ticket cache use kdestroy.

Alternatively, instead of using kinit, proceed to configuring mod_auth_kerb for Apache.

For more information see the guide at http://grolmsnet.de/kerbtut/

Setup mod-auth-kerb

Once again the package manager works wonders:

sudo apt-get install libapache2-mod-auth-kerb

In /etc/apache2/conf.d/twiki.conf, add the entries for Kerberos authentication. Enter # in front of AuthType basic to disable plain text authentication.

<Directory /usr/lib/cgi-bin/twiki/>
   Order Deny, Allow
   Allow from all
   
   AuthType Kerberos
   KrbAuthRealms ACME.LOCAL
   KrbServiceName HTTP
   Krb5Keytab /etc/apache2/http.keytab
   KrbMethodNegotiate on
   KrbMethodK5Passwd on
   Require valid-user
</Directory>

Setup Plugins

Kerberos authentication will set the login name TWiki sees to username@ACME.LOCAL. To map these login names to WikiNames, I use LoginNameAliasesPlugin and LdapContrib.

LoginNameAliasesPlugin

Install LoginNameAliasesPlugin normally. Once installed setup suffix removal of @ACME.LOCAL.

NewUserPlugin

The NewUserPlugin works great with this setup, and creates the user page when they first login by copying a template and filling in their details from LDAP.

-- Contributor: MattEverson, JacobGreenleaf - 05 Dec 2009-12-28



Comments & Questions about this Supplemental Document Topic

Thanks Matt for contributing this topic. I moved it from the Main web, linked to it from TWikiUserAuthenticationSupplement and tagged it so people can discover it.

-- PeterThoeny - 07 Dec 2007

Excellent! I am using a similar setup, but have to apologize that I was too lazy to write it down. I am curious about how you are using LdapContrib to create wikinames. Do you require your users to register or do you pull their data from LDAP on-the-fly?

-- HaraldJoerg - 08 Dec 2007

For anyone who is trying this on Windows Server 2008, there is a bug in Active Directory that authentication with principals that contain a slash (such as HTTP/wikisvr.acme.local) in the name is broken. It took me a day to find this out, and I hope this can save others some hair-pulling time.

-- BeilinZhang - 06 May 2008

Another caveat: in 4.2 the same setup applies, but at this time LdapContrib needs a couple of modifications to use LDAP users and groups in access lists. Those changes are described in LdapUserMappingWithDotInLoginname.

-- MattEverson - 05 Jun 2008

I attempted the ktpass command line above, but had to modify it in a couple of ways to get the keytab to successfully create without errors. First, the -mapop flag is deprecated for the crypto option, so use the /crypto flag. Second, DES is old and insecure, so use RC4-HMAC-NT (the most current crypto type compatible with both MS and MIT kerberos implementations). Third, include a ptype flag '/ptype KRB5_NT_PRINCIPAL' in order to avoid the error "WARNING: pType and account type do not match. This might cause problems."

I also tried this with the keytab created in the previous step, but it appears that kinit does not work for Service Principals, only for User Principals. The error message when attempting kinit for the service principal is: "kinit(v5): Client not found in Kerberos database while getting initial credentials"... having talked with my local kerb guru, he was dubious that kinit should work for this at all, and recommended that I just skip this step and proceed to configuring mod_auth_kerb for apache. After doing so, the keytab appears to work fine.

-- JacobGreenleaf - 2009-12-28

Thank you Jacob for sharing your experience. I changed the comments you made above and folded them into the document. Please review for accuracy.

-- PeterThoeny - 2010-01-03

At the kinit step using the keytab I found myself hitting "Generic preauthentication failure" messages. After much searching, trial, and error, I found adding "default_tkt_enctypes = arcfour-hmac-md5" and "default_tgs_enctypes=arcfour-hmac-md5" got me past the issue, despite the keytab file generated by Windows' ktpass claimed it was using des3-cbc-sha1. Tricky Windows.

-- Ian Berdei - 2013-07-12

Please use the Support forum if you have questions about TWiki features. This comment section is about the documentation of this topic.
Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r12 - 2013-07-12 - IanBerdei
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.