Windows 2003 Authentication using Kerberos and mod-auth-kerb
Foswiki can be configured to transparently authenticate Windows users.
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 Foswiki
I am running Ubuntu so I installed Foswiki and Apache using the steps in
FoswikiOnUbuntu.
For anyone using the
FoswikiDebianPackages
apt-get install foswiki foswiki-ldapcontrib foswiki-newuserplugin
and then enable and configure
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 [email protected]
, 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 in this example.
Then, use
ktpass from the Windows 2003 Support Tools (on install CD in
/SUPPORT/TOOLS
) to create a keytab file the linux server will need. At the command line, enter
pre win2003 sp1
ktpass -princ HTTP/wikisvr.acme.local@ACME.LOCAL -mapuser wikikerb -mapop set +desonly -pass accountpassword -out c:\http.keytab
post win2003 sp1
ktpass /out c:\http.keytab /mapuser wikikerb@wikisvr.acme.local /princ HTTP/wikisvr.acme.local@ACME.LOCAL /crypto RC4-HMAC-NT /pass accountpassword /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.
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/foswiki.conf, add the entries for Kerberos authentication. Enter
# in front of
AuthType basic to disable plain text authentication.
<Directory /usr/lib/cgi-bin/foswiki/>
Order Deny,Allow
Allow from all
AuthType Kerberos
KrbAuthRealm 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 Foswiki sees to
[email protected]. To map these login names to
WikiNames, install
LdapContrib and use
configure
to set your
{LoginManager}
to
Foswiki::LoginManager::LdapApacheLogin
and
{UserMappingManager}
to
Foswiki::Users::LdapUserMapping
, and then Set the
LDAP Settings to match your server
- remember, to remove the
@
from the login name - set $Foswiki::cfg{Ldap}{NormalizeLoginNames}
to 1
(See
LdapContrib for more deatils)
SvenDowideit tried the following and they seemed to work (not the Groups yet)
$Foswiki::cfg{Ldap}{Host} = win2k3.acme.local';
$Foswiki::cfg{Ldap}{Port} = 389;
$Foswiki::cfg{Ldap}{Version} = '3';
$Foswiki::cfg{Ldap}{Base} = 'cn=Users,dc=acme,dc=local';
$Foswiki::cfg{Ldap}{BindDN} = 'cn=wiki kerb,cn=Users,dc=acme,dc=local';
$Foswiki::cfg{Ldap}{BindPassword} = 'accountpassword';
$Foswiki::cfg{Ldap}{UseSASL} = 0;
$Foswiki::cfg{Ldap}{SASLMechanism} = 'PLAIN CRAM-MD5 EXTERNAL ANONYMOUS';
$Foswiki::cfg{Ldap}{UseTLS} = 0;
$Foswiki::cfg{Ldap}{TLSSSLVersion} = 'tlsv1';
$Foswiki::cfg{Ldap}{TLSVerify} = 'require';
$Foswiki::cfg{Ldap}{TLSCAPath} = '';
$Foswiki::cfg{Ldap}{TLSCAFile} = '';
$Foswiki::cfg{Ldap}{TLSClientCert} = '';
$Foswiki::cfg{Ldap}{TLSClientKey} = '';
$Foswiki::cfg{Ldap}{Debug} = 1;
$Foswiki::cfg{Ldap}{UserBase} = 'cn=Users,dc=acme,dc=local';
$Foswiki::cfg{Ldap}{LoginFilter} = 'objectClass=user';
$Foswiki::cfg{Ldap}{LoginAttribute} = 'sAMAccountName';
$Foswiki::cfg{Ldap}{WikiNameAttribute} = 'cn';
$Foswiki::cfg{Ldap}{NormalizeWikiNames} = 1;
$Foswiki::cfg{Ldap}{NormalizeLoginNames} = 1;
$Foswiki::cfg{Ldap}{WikiNameAliases} = '';
$Foswiki::cfg{Ldap}{AllowChangePassword} = 0;
$Foswiki::cfg{Ldap}{SecondaryPasswordManager} = 'none';
$Foswiki::cfg{Ldap}{GroupBase} = 'cn=Users,dc=acme,dc=local';
$Foswiki::cfg{Ldap}{GroupFilter} = 'objectClass=group';
$Foswiki::cfg{Ldap}{GroupAttribute} = 'cn';
$Foswiki::cfg{Ldap}{PrimaryGroupAttribute} = 'gidNumber';
$Foswiki::cfg{Ldap}{MemberAttribute} = 'memberUid';
$Foswiki::cfg{Ldap}{MemberIndirection} = 0;
$Foswiki::cfg{Ldap}{WikiGroupsBackoff} = 1;
$Foswiki::cfg{Ldap}{NormalizeGroupNames} = 0;
$Foswiki::cfg{Ldap}{MapGroups} = 1;
Foswiki::LoginManager::LdapApacheLogin
will remove the @ACME.LOCAL domain portion from the login, and
Foswiki::Users::LdapUserMapping
will then be able to look up the server for the matching user information.
NewUserPlugin
The
NewUserPlugin works well with this setup, as it creates the user page when they first login by copying a template and filling in their details from LDAP.
--
Contributor: MattEverson - 05 Dec 2007,
SvenDowideit Feb2009
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
This page is mostly outdated as the debian packages aren't maintained anymore.
--
MichaelDaum - 25 Jan 2021