|
|
|
Microsoft have replaced the NTLM authentication method (the default authentication method used by NT 4.0) with a Kerberos style authentication method. Kerberos is a standard protocol designed to be used for authentication of clients and servers in an insecure environment, making it ideal for use on the internet.
Microsoft claim that their implementation of Kerberos is interoperable with the standard MIT Kerberos. This leads to several interesting possibilities. Using a Windows 2000 server, a Kerberos realm can be set up to authenticate all users on the network that have Kerberos clients. This includes Windows 2000 clients, Unix systems, and many other types of machines. Kerberos tickets are portable between operating systems, meaning that true Single Sign On is possible using a Kerberos realm hosted on a Windows 2000 server.
We tested the interoperability of Microsoft's Kerberos implementation with MIT Kerberos servers and clients.
It must be taken into account that this is beta software, and there may be features that are currently unimplemented, or not working correctly, for various reasons.
Microsoft's implementation of Kerberos appears to be interoperable to some extent with MIT Kerberos clients.
There is no implementation of a Kerberos Administration Server (kadmind) in Windows 2000 server, meaning that several of the MIT clients will not work. This includes the MIT kpasswd client, which allows users to change their passwords.
This seriously affects the usability of Windows 2000 server as a Single Sign On service.
Our previous trials measured the interoperability of the ADS vs the LDAP standards.
I tried several authentication attempts, using plain LDAP authentication, against user accounts in the LDAP trees in both OpenLDAP and ADS. All of these attempts appear to produce the expected results (i.e. using a valid account and password succeeds, using an invalid account and/or password fails).
I did not attempt Kerberos based authentication from an LDAP client.
The Microsoft Key Distribution Center (KDC) came installed and ready to run out of the box. The default realm name is the uppercased name of the ADS name. So, for our directory (called chc.someco.co.nz) there was a Kerberos realm of CHC.SOMECO.CO.NZ.
I used the MIT Kerberos client version 1.0-3 which I downloaded in RPM format from Replay Associates.
I set up the /etc/athena/krb5.conf file as follows:
[libdefaults]
ticket_lifetime = 600
default_realm = CHC.SOMECO.CO.NZ
default_tkt_enctypes = des-cbc-md5
default_tgs_enctypes = des-cbc-md5
[realms]
CHC.SOMECO.CO.NZ = {
kdc = 172.17.32.130
admin_server = 172.17.32.130
default_domain = someco.co.nz
}
[domain_realm]
.someco.co.nz = CHC.SOMECO.CO.NZI was successfully able to authenticate to the Kerberos server as follows:
[del@chns1 del]$ kinit Password for del@CHC.SOMECO.CO.NZ:
( I entered my password at this point. No error message was received, and therefore I assumed that the login was successful. I then tested this by listing my current Kerberos keys):
[del@chns1 del]$ klist Ticket cache: /tmp/krb5cc_501 Default principal: del@CHC.SOMECO.CO.NZ Valid starting Expires Service principal 16 Jul 99 02:44:08 16 Jul 99 12:45:24 krbtgt/CHC.SOMECO.CO.NZ@CHC.SOMECO.CO.NZ
The fact that my ticket granting ticket (krbtgt) was listed indicates at this point that the login was successful.
On an MIT Kerberos system there is a Kerberos Administration Server (kadmind). This runs on the master Kerberos server, which stores the KDC principal database, and the KADM5 policy database. The Kerberos Administration Server typically runs over a TCP connection on port 749.
There is no implementation of the Kerberos Administration Server in Windows 2000 server. This means that Unix users are unable to change their Kerberos passwords using the kpasswd client.
Without allowing a Unix user to change their password, there is no real point in storing these passwords in the Windows 2000 server Kerberos database. Although Unix users would be able to change their Unix passwords from a Windows 2000 client, this would be unacceptable to Unix users who did not have access to a Windows 2000 PC.
It appears not to be possible to use the Kerberos Administration Server running on a non-Windows system to change passwords on a Windows 2000 server, as Microsoft have stated that they do not support the Kerberos password changing protocol (download the document and read for confirmation of this). I have yet to test this.
Windows 2000 server still supports NTLM style authentication for Windows 95/98 and Windows NT workstation 4.0 clients. Sites wishing to switch to all-Kerberos authentication are able to do so either by:
Upgrading all Windows NT workstation 4.0 and earlier clients to Windows 2000 Professional, or
Implementing Kerberos style authentication in Windows NT 4.0. This is possible using by replacing the GINA.DLL used in Windows NT Workstation 4.0 with one that supports Kerberos.