===== please notice =====
Nowadays I recommend for the crossrealm setup of Windows/Linux/unix the FreeIPA or Red Hat Identity Management server. IPA has become available just after my initial setup which of the single components, IPA includes these components. Since I work at Red Hat I also gained some experience. Version 3 plans to support crossrealm trusts with Windows.
===== the environment =====
* our MIT-kerberos realm with linux/unix-servers/services in it
* a AD-domain, this has joined windows xp workstations, and users - usual AD-domain
* after establishing the crossrealm-trust between MIT-realm and AD-server users from the domain can use kerberized services from the realm
===== setup at the MIT-KDC =====
krb5.conf
------------------
[libdefaults]
default_realm = FLUXCOIL.NET
default_tgs_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5
default_tkt_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5
permitted_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5
# permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
# des3-hmac-sha1 des3-cbc-sha1 rc4-hmac des-cbc-crc des-cbc-md5
dns_lookup_realm = false
dns_lookup_kdc = false
[realms]
FLUXCOIL.NET = {
admin_server = fed10.fluxcoil.net:749
default_domain = fluxcoil.net
kdc = fed10.fluxcoil.net:88
# the two lines below make logins possible without appropriate ~/.k5login
auth_to_local = RULE:[1:$1@$0](.*@WINB.FLUXCOIL.NET$)s/@.*//
auth_to_local = DEFAULT
}
WINB.FLUXCOIL.NET = {
admin_server = 10.0.2.32:749
kdc = 10.0.2.32:88
}
[domain_realm]
.fluxcoil.net = FLUXCOIL.NET
fluxcoil.net = FLUXCOIL.NET
.winb.fluxcoil.net = WINB.FLUXCOIL.NET
winb.fluxcoil.net = WINB.FLUXCOIL.NET
[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log
[appdefaults]
pam = {
validate = true # yes, we want mutual authentication
debug = true
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
use_shmem = true
}
------------------
### now define krbtgt/WINDOWS.COM@UNIX.COM and krbtgt/UNIX.COM@WINDOWS.COM principals with password ABC
### windows younger than 2003 SP1 beta should also allow RC4-HMAC
kadmin.local
> addprinc -e des-cbc-crc:normal -pw mypass krbtgt/WIN.FLUXCOIL.NET@FLUXCOIL.NET
> addprinc -e des-cbc-crc:normal -pw mypass krbtgt/FLUXCOIL.NET@WIN.FLUXCOIL.NET
===== setup at the AD-server =====
### setup the AD-domain
### extract ksetup.exe and ktpass.exe from the cd under support/tools/support.cab, i.e. store the files under c:\
### On Active Directory define the MIT realm and MIT kerberos master with ksetup
ksetup /addkdc FLUXCOIL.NET sid64.fluxcoil.net
### define the realm trust (one way, incoming) with the password ABC
- in 'domains and trusts' right-click your domain, properties, trusts, new trust
- enter REALM.NAME, and password for the trust
- alternatively use this: netdom TRUST MY.W2KDOMAIN.ORG /Domain:MY.MITREALM.ORG /Add /Realm /PasswordT:"someolpswd"
- and if transitive is needed: netdom TRUST MY.W2KDOMAIN.ORG /Domain:MY.MITREALM.ORG /Transitive:yes
### only needed for having users from kerberos-realm using services from the AD-domain:
- create user with name map0
- ktpass princ host/sid64.fluxcoil.net@WIN.FLUXCOIL.NET mapuser map0@win.fluxcoil.net -pass somenewpass out unix.keytab
- not needed: tool ms2mit.exe can convert tickets
- users&computers: activate view/advanced features, then rightclick on user, "name mappings", "kerberos names"
- with a usermapping ksetup will look like this:
>ksetup
default realm = windows.com (NT Domain)
FLUXCOIL.NET:
kdc = sid64.fluxcoil.net
Realm Flags = 0x0 none
Mapping XYZ@FLUXCOIL.NET to XYZ
### for debugging:
- windows 2003 ressource kit: kerbtray.exe
- is time in sync everywhere?
- dns a- and ptr-records properly set up?
== kerberos-enabled ssh-clients for windows ==
* GSSAPI-patched putty was available, various implementations
* SecureCRT, works only when KerberosForWindows is also installed?
== adding new workstations to the AD-domain ==
* add it to the domain, net join
* ksetup /addkdc FLUXCOIL.NET sid64.fluxcoil.net # to make it aware of our kerberos-realm
== adding new users to AD-domain that can use MIT-services ==
* on AD-server: manage users, add the user, set password
* login on a workstation that is in the domain
* on the destination-host make sure userdata is there, i.e. 'useradd -m newusername' to prepare for ssh-logins
* on the destination-host %%echo 'newusername@WIN.FLUXCOIL.NET'>~newusername/.k5login%%
* on workstation start gssapi-enabled ssh, enter hostname, under 'Data' enter newusername for autologin, at 'Auth' enable GSSAPI/SSPI and the three options below, hit 'open' and user logs in
===== setup a windows-client for singlesignon-usage =====
Users existing in the AD-domain can log onto windows-clients that are members of the AD-domain. With these instructions user can log on using their domain-password and then use kerberized services from the realm.
* install MIT-kerberos for windows 3.1 (the 3.1 refers to the version of the software, not win3.1) This is used as cache for the mit-tickets. The ticket-cache that newer windows-versions used natively is not influenced by this, so the server can still be domain-member etc.
Now you can use MIT-kerberized applications, for example:
* Mozilla's firefox and Thunderbird (auth with POP3, IMAP and SMTP)
* get putty with gssapi-patch (this will be using the mit-ticketcache later for authentication)
* winscp (also uses the mit-ticketcache)
* several FTP clients, Eudora, X Windows packages
* SecureCRT SSH from vandyke.com. It actually gives a choice between using an external GSSAPI library (e.g. KfW), or SSPI.
* WinCVS, TortoiseCVS using ssh/gssapi
===== debugging =====
== generic debuggingsteps==
* watch the KDC logfiles of kadmind and krb5kdc
* watch the auth-logs on the SSH server
* sniff the traffic between participating hosts
* list principals from kadmin.local
* get crdentials with kgetcred
* run ssh -vvvv on the client
* run /usr/bin/sshd -de on the SSH-server for debugmode
* use klist -l/kdestroy
* check krb5.conf files: realms known? kdc? extra_addresses?
* check sshd_config: GSSAPI or pam_krb5?
* check ssh_config, GSSAPI enabled?
* time in sync among participating hosts?
==problem: tickets are denied==
krb5kdc[18236](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.0.2.31: PROCESS_TGS: authtime 0, for
host/sid64.fluxcoil.net@FLUXCOIL.NET, Encryption type not permitted
Sniff traffic, add correct encryptiontype both sides understand to /etc/krb5.conf, i.e. "permitted_enctypes = des3-hmac-sha1 rc4-hmac des-cbc-crc des-cbc-md5"
==problem: login with gssapi-putty hangs==
and just displays "Using username ".
No login allowed on remote host? Try 'echo "username@AD.DOMAIN">~username/.k5login' and if it works you can create 'auth_to_local'-settings in krb5.conf on the remote host.
==problem: kerberized ssh-login not possible==
'/usr/sbin/sshd -ddd' shows this:
debug1: Unspecified GSS failure. Minor code may provide more information
Wrong principal in request
Check dns-stuff, try to access the ssh-box with/without full domain name, write full domain in /etc/hosts file like this: %%10.0.0.23 fc6.fluxcoil.net%%
==problem: the user trying to log is guessed to be from the wrong REALM==
User tries to log in via ssh, pam_krb5 tries to get credentials from the defauls_realm, but the user doesnt exist there but in a different realm. pam_krb5 calls can be stacked like this:
other auth sufficient pam_krb5 REALM=LOC1.DOM.COM
other auth sufficient pam_krb5 REALM=LOC2.DOM.COM
One can also try just not to use pam.
==problem: no credential-forwarding via ssh==
"sshd -ddd" on server reports: 'Got no client credentials'. Try 'use_shmem = true' in /etc/krb5.conf on ssh-client, or this pam_krb5 here: http://www.eyrie.org/~eagle/software/pam-krb5 .