This is a contribution for <http://wiki.netbsd.org/kerberos/web_browser/>, section "Internet Explorer".
Parts of this are already present in <http://www.netbsd.org/docs/network/#win2k>, although that section is incomplete. Windows is very Active Directory-oriented, but its Kerberos protocol is [more-or-less] standard and can use non-AD services. It's not at all "easy" or "convenient", however; installing MIT Kerberos and Firefox is a better choice. First, configuration. The 'ksetup' tool will be useful; for XP it can be installed from Windows 2003 Support Tools (download). 'regedit' can be used as a last resort. Also, 'klist' will be necessary; it comes with Windows 2003 Resource Kit. More recent Windows versions appear to have both tools preinstalled. 1. Add KDCs (*optional* -- SRV records are sufficient): ksetup /addkdc NETBSD.ORG kerberos.netbsd.org 2. Set realm flags (optional, but useful for TCP and other stuff): ksetup /addrealmflags NETBSD.ORG tcpsupported ncsupported delegate "tcpsupported" - self-explanatory. With "delegate", servers will always be trusted for delegation regardless of whether they have "ok-as-delegate" principal flag enabled. Windows SSPI checks this flag; MIT/Heimdal do not. Recent Windows versions also have a flag to enable AES enctypes; older versions only support RC4-HMAC (arcfour-hmac). 3. Map principals to local user accounts (required): ksetup /mapuser j...@netbsd.org John This is needed because LSA Kerberos ticket caches are tied to local authentication (in some way), and Windows cannot use accounts from non-AD LDAP or whatever your realm is using. Finally, usage. 4. Obtain a TGT. Note: Host principals are *not* needed; this is a client-only setup. However, do *not* run "ksetup /setmachpassword", because this *will* enable the host principal requirement, and I have not figured out how to undo it 100%, not even by SAM surgery. - One way, as already mentioned in the wiki, is to enter the Kerberos principal on the login screen. (For Windows XP "Welcome" screen, use double Ctrl+Alt+Del to reveal an input box. AFAIK, later versions allow to enter arbitrary usernames in the main "Welcome" screen.) If MIT Kerberos is installed, it will automatically copy the TGT from LSA to its own ccache when logged in using this method. However, if the local and Kerberos passwords are different, you will have problems with CryptoAPI -- for example: user certificates, EFS encrypted files, even stored network passwords will be inaccessible. - Another way is to use 'runas', which creates a new LSA session: runas /u:j...@netbsd.org cmd This is easier in many cases, but there are downsides as well. The newly created processes are put by 'runas' in a "job object", which will cause problems with Chrome and possibly other programs, since Chrome puts its subprocesses in a resource-limited job object as well, and they cannot be nested. 5. Run programs. Internet Explorer supports HTTP Negotiate, and will use it when all(): 1. "Integrated Windows Authentication" is enabled under "Internet Properties" -> |Advanced| -> "Security". 2. The apropriate zone under "Internet Properties" -> |Security| has the "User Authentication" option set to "Automatic logon ..." (under "Custom level"). Chrome will use HTTP Negotiate when the domains are whitelisted, using either "--auth-server-whitelist" or Group Policy templates. - Also, as said in #4.2, Chrome will not work from inside 'runas'. Firefox and Thunderbird will use HTTP Negotiate and SASL GSSAPI respectively when "network.auth.use-sspi" is set to true. Windows will attempt Kerberos authentication when connecting to SMB file shares, if the other end offers. (Samba can.) PuTTY 0.61 will try both SSPI and MIT GSSAPI in the configured order. "Quest PuTTY" only supports SSPI. -- Mantas M. The text above is released under WTFPL v2 <http://sam.zoy.org/wtfpl/>
