fluxcoil wiki

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.

• 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

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 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?

• GSSAPI-patched putty was available, various implementations
• SecureCRT, works only when KerberosForWindows is also installed?

• add it to the domain, net join
• ksetup /addkdc FLUXCOIL.NET sid64.fluxcoil.net # to make it aware of our kerberos-realm

• 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

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

• 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?

krb5kdc[18236](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.0.2.31: PROCESS_TGS: authtime 0,  <unknown client> 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”

and just displays “Using username <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.

'/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

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.

“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 .