(collection point for "general future Kerberos things related to Linux")

Current

IT-FIO runs KDCs for CERN.CH used by the UNIXish clients for authentication, and for the AFS service.

IT-IS runs KDCs (actually Active Directory), also for CERN.CH.

Tests: Linux client vs Windows service

Use a special CERN "Windows" Kerberos config, use KRB5_CONFIG=... to make clients use that.

kdc = CERNdc01.cern.ch:88

Use separate Krb5 ticket cache ( KRB5CCNAME=..) to keep the KDC environments apart.

You can use /afs/cern.ch/user/i/iven/public/kinit.win to get such a test environment.

Web

Firefox and Mozilla both support SPNEGO (needs to be enabled via about:config? howto1 howto2; key is network.negotiate-auth.trusted-uris).

Debug:

export NSPR_LOG_MODULES=negotiateauth:5 
export NSPR_LOG_FILE=~/.firefox-debug.log

look for

HTTP/1.x 401 Unauthorized
 WWW-Authenticate: Negotiate

header from server. Firefox needs to reply with

Authorization: Negotiate YIIIiAYJKoZIhvcSAQICAQBuggh3MI..... (junk)

Server should say

HTTP/1.x 200 OK

Test:

• works fine against "Virtual server" manager: cernwod14
• work somewhat against login.cern.ch (need to modify URL to say /adfs/ls/auth/integrated/), some issues with load-balanced service (login=webr5=secondary interface to webredir0X..) and keytab

Mail: IMAP (i.e. reading+folder operations)

Tested in Oct 2007 (A.Lossent), via a test Exchange 2007 "frontend" server (cernfe10) and a test account that lives on a 2007 backend server. Requires Exchange 2007 since MS Technet (section "Client Access server data paths ") says IMAP4 should be GSSAPI-aware on that platform.

pine

works (pine-4.58-2.8o.6.cern) However, if the user has a TGT for the "AFS" CERN.CH realm (and hence no way to get a service ticket for the "Windows" realm), pine will not fall back to Password auth! Need to disable GSSAPI in order to proceed, via

disable-these-authenticators=GSSAPI

in /etc/pine.conf or the user's .pinerc.

Debug output from a "working" connection (TGT from WIN CERN.CH):

IMAP DEBUG 12:04:45.232262 10/10: * CAPABILITY IMAP4 IMAP4rev1 AUTH=NTLM AUTH=GSSAPI IDLE NAMESPACE LITERAL+

12:04:45.236063 IMAP DEBUG 12:04:45.236071 10/10: 00000001 AUTHENTICATE GSSAPI

(blabla, long encrypted strings).

12:04:46.616994 IMAP DEBUG 12:04:46.617021 10/10: 00000001 OK AUTHENTICATE completed.

thunderbird

works - use port 993, SSL, tick "secure authentication"

evolution

works - select "GSSAPI" explicitly as authentication type.

Mail: SMTP (delivery)

Not tested.

pine

thunderbird

seamonkey

evolution

Directory/LDAP (over SSL/SASL/TLS)

Not tested.

ldapsearch (command line)

pine

thunderbird

seamonkey

evolution

Terminal Service/rdesktop

Seems to require "Vista" Terminal server (which implements RDPv6 or RDPv6.1, MS blog). MS blog claims that Kerberos is used by default, via some CredSSP SPNEGO-lookalike. Protocol-level details are not availbale?

Several attempts to figure out Kerberos for RDP for rdesktop are documented (archive search) , no conclusion. Looks like rdesktop doesn't do RDPv6 at all.

Update Feb 2008: Microsoft has had to release a number of specifications as result of their dealing with the European Commision, this includes a MSDN reference for most of the authentication aspects, as well as documentation on RDPv5.(1,2) (nothing on RDPv6 yet?).

Pointers

• CNIC has a workshop to collect auth/auth/aud solutions from the experiments and all over CERN
• FIO-FS is looking at a REGIS (authorization) replacement (RequirementsDocument, "Didi")

Kerberos5 (copied over from SLC4 wishlist page)

SLC4 gets Kerberos5 credentials by default. Investigate implications on all services including Web auth, proxy credentials for Web/Grid, ORACLE.

• Web auth: We will run into trouble with the CERN.CH split between Windows and AFS web servers here - either we can set up some trust relationship (Between two realms with same name??), or all possible servers need to be specified explicitly in /etc/krb5.conf (and we will need to get tickets for both at login...)
  • firefox/mozilla support SPNEGO
  • apache has Kerberos5 support, including for SPNEGO, http://modauthkerb.sourceforge.net/. Small FAQ/Howto is at KerberosAuthWWW
  • IIS should work as soon as "Integrated Windows auth" is enabled.

• ORACLE: should in principle work with Kerberos5 but may have trouble with the current Kerberos5 setup at CERN; oracle.support/IT-DES is working on this (contact; N.Segura)

• KerberosMigrationTests - things that should get checked

• new service principals ( cdb/host@CERN.CH, HTTP/host@CERN.CH) can be created by a selected few via arc -h afsdb1 kas ext cdb/somehost.cern.ch > /tmp/tttt . Contact B.Antoine for details.

---

Current (AFS) KDC services and integration

The (AFS) KDC is integrated with a number of other services. All these interfaces need to be considered during an eventual migration, the following tries to list them with the respective client applicaton that needs to work.

One utility used regularly within the AFS service is ARC.

• "pure" Kerberos 5 KDC: TGTs and service tickets; access should be largely via standardized APIs. This is an advertised external service, i.e. other labs are using this functionality.
  • pam_krb5 on Linux, /usr/kerberos/bin/kinit (on Linux) to acquire TGTs
  • provide service tickets for host/, cvs/, cdb/, HTTP/ hostname.cern.ch@CERNNOSPAMPLEASE.CH, afs@CERN.CH (AFS:special case - encoding type etc?, via pam_krb5afs or /usr/bin/klog or /usr/bin/aklog or /usr/bin/afs5log)
  • password changing functionality /usr/kerberos/bin/kpasswd (unless subsumed into "CERN account" password change procedure)

• Kerberos 4 KDC: TGT and service tickets. API are less standard than on Kerberos 5 (32/64bit issue already observed). Advertised external service. Kerberos4 is deprecated by CERN but still widely used. Might be tightly integrated with AFS (i.e. Krb4 server advertised as "AFS KDC"?)
  • /usr/bin/klog.krb (Krb4 functionality only)
  • Kerberos5-to-4 translators: pam_krb5, /usr/kerberos/bin/krb524init (requires special conversion service on the server?)
  • service tickets for rcmd/hostname@CERN.CH; afs@CERNNOSPAMPLEASE.CH (*AFS: special case? via /usr/bin/klog, /usr/bin/afslog)

• delegated KDC administration: user and service principal registration. This is beside the KDC-native methods of adding/deleting principals. All these methods imply delegated trust. The service protects itself against modifications of "core" accounts and systems.
  • CRA interface to add/delete/block users, forced password changes. Uses polling from known server (?)
  • new: NICE/"CERN-account" password change/account block interface. Uses SSH (pubkey auth).
  • cern-config-keytab - "root" on a machine can (re-)create the host/ (aka rcmd.) principal for that machine. Uses ARC, trusts IP address, DNS and "only root can bind() below port 1024"
  • administration delegation for specific services: cdb/, HTTP/, see above. Uses ARC.

• Impersonation, non-Kerberos authorization "translation". These should list the mechanism as well as the trusted entities (IP address, keytab file, CA list etc). The current mechanism on Heimdal uses a defined interface. MIT (and apparently AD) only have an interface (ktadd) that resets the password on keytab extraction - this would not be useful to impersonate user accounts.
  • LSF/Batch service: user jobs need (at least) AFS tokens, and these may expire between job submission and job start. Mechanism documented on the ARC page, extends (possibly expired) AFS tokens if coming from a registered batch machine; implemented via ARC. Contact: Rainer
    • http://www.kapet.de/kb/krb_afs_batch/ has a nice summary (from 2004) on the options between Batch systems and AFS
  • Grid certificate translation: incoming user job has valid X509 certificate from known CA, needs Kerberos TGT and AFS token. Implemented via gssklog service. Trusts: (?). Contact: Arne
  • acron service: time-delayed/recurring user job needs Kerberos TGT and AFS token. Mechanism documented on the ARC page. Cron job submission requires a valid TGT, executiion: executing machine gets a valid Kerberos TGT and AFS token from the acron server which in turn uses direct access to the KDC DB.

• Other/ internal services (and unsorted). Unclear how these authenticate and to what service(s).
  • AFS backup and restore. Based on CASTOR, have own stager.
  • AFS volume migration/load-balancer
  • afs_admin - clarify whether this elevates privileges or just exposes already-existing AFS-level privileges
  • Security team can trigger a "clone" of user "home" volumes, new volume will be mounted with read-only access; implemented via ARC

Future (AD?) KDC services and integration

• "cern-config-keytab" replacement (allow machines to join the AD domain "automatically"). Uses a dedicated AD account nicekdc (password is essentially public so will need to be extremely restricted), and some SAMBA utilities.
  • run old cern-config-keytab; keep copy: cp -av /etc/krb5.keytab /etc/krb5keytab.afs
  • create stub /etc/samba/smb.conf (FIXME: add all NICE AD KDCs)

    workgroup = CERN
    security = ads
    realm = cern.ch
    use kerberos keytab = true
    password server = CERNdc01.cern.ch

  • optionally: correct SELinux context on /etc/krb5.keytab (or turn to permissive for the duration?) - otherwise may get error messages from SAMBA, of the form:

      smb_krb5_kt_add_entry: adding keytab entry for (host/it-adc-test08.cern.ch@CERN.CH) with encryption type (1) and version (6)
      smb_krb5_kt_add_entry: adding entry to keytab failed (No such file or directory)

(or plain segaults.. even with correct SELinux context??)

• • change LanDB OS field to have "Windows" in it, and wait for the "Computer Account status" to be updated (FIXME cannot do this for all (Linux) machines at CERN)
  • run net -Unicekdc ads join (and type password as requested). This should create a new /etc/krb5.keytab file, use klist -k -e to check.
  • FIXME merge AFS and AD credentials via ktutil: This only works if the kvno (key version numbers) are different between AD and AFS

    # ktutil
    ktutil:  rkt /etc/krb5.keytab
    ktutil:  rkt /etc/krb5.keytab.afs
    ktutil:  wkt /etc/krb5.keytab
    ktutil:  list
    ktutil:  exit

    This setup allows clients from both the AFS and AD world to e.g. login via GSSAPI. Obviously, AD TGTs cannot be converted into AFS tokens at this stage.
• general impersonation on AD: Microsoft calls this (constrained) delegation and (integrated) "Windows authentication" usually means "Kerberos" (inside an AD domain, recent Win clients). Old Win2k only would do "unconstrained" delegation (i.e. hand over valid TGTs??), Win2003 allows to configure for which services a ticket can be created (but still can do unconstrained delegation, as per GUI). Local service privileges make a difference, "Act as part of the operating system"-privilege (SYSTEM, also called TCB) is required to get usable credentials (otherwise the service can just check group membership but the received cred is invalid)
  • described on MS TechNet (has some code samples) and MSDN "Kerberos Technical Supplement"
  • see also "Exploring S4U Kerberos Extensions" - introduction to how services pretend to be a user; some code samples; screenshot of the delegation GUI; S4U2Proxy
  • see also a walkthrough for kerberizing IIS by K.Schaefer
  • see also "Protocol Transition" in ASP NET2.0 (i.e. use non-Kerberos for Auth, then "switch" to Kerberos for impersonating - useful for a service that just hands out creds without ever talking to the user, since by default Win would use the authenticated user's service ticket)
  • see also "Explained: Windows Authentication in ASP.NET 2.0"
• C.Delles: "Realm Trust between Windows domains and Kerberos realms should be possible using http://technet.microsoft.com/en-us/library/bb742433.aspx and enables to points unix clients to MS KDC server or the reverse"