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 john%NETBSD.ORG@localhost 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:john%NETBSD.ORG@localhost 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/>