You can make a difference in the Apple Support Community!

When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Does anyone know how to configure Kerberos with Lion?

It was bad enough that kerberos changed from 10.5 to 10.6, but now they've completely removed MIT Kerberos and replaced it with Heimdal in 10.7. So my existing kerberos configuration, which worked great in 10.6, no longer works in 10.7. This is a real show-stopper for me, until I can find some docs or other information on how to configure OS X as a kerberos client (the KDC is a Red Hat Enterprise Linux box).


Has anyone figured out how to do this? Whenever I try to get a ticket, it tells me that it cannot reach the KDC, but it's failing so fast that I don't think it's even trying to actually talk to my KDC (and I see no traffic to the KDC), so I don't think it knows the address for the KDC. According to the Heimdal manpages and other information, the /etc/krb5.conf file should be where this is defined, and the format should be the same as an MIT Kerberos client, but it just keeps failing miserably.


Any pointers would be highly appreciated!

Posted on Jul 20, 2011 7:54 AM

Reply
49 replies

Jul 21, 2011 7:46 AM in response to sonestad

No, nothing works. It is a complete mess. I've done some poking around and can't find any clues. The manpage for kinit talks about /etc/krb5.conf, but creating that does nothing, kinit still can't find an associated KDC for the realm in question. Ticket Viewer is equally useless (but it gives an "incorrect password" error as opposed to kinit saying it can't find the corresponding KDC). /Library/Preferences/edu.mit.Kerberos no longer seems valid either, which is where you defined the realms/KDCs in Snow Leopard.


I'm sure they had a reason for changing from MIT Kerberos to Heimdal, but it sure would have been nice to get some clues as to how to configure things. sso_util seems to be for configuring a local KDC, which I don't want. I don't know if they made the change so that you have to use OpenDirectory now, but if they did, that's really lame (maybe some people will use Lion Server for this stuff, but I've got a perfectly good RHEL6 box that does it all right now, and I've been using Linux for the KDC for 10.5 and 10.6 and it's worked great).


I'm extremely frustrated as this kills SSO on my LAN for my mac clients that upgrade to Lion. It means that kerberized services like my intranet web server, subversion, and SSH are useless when it comes to the macs now.


Kerberos worked great in 10.5, and then the butchered it for 10.6, but it was doable (inconvenient but doable). Now in 10.7 it's even worse and they claim this is even more enterprise-ready than previous versions? Yeah right.

Jul 21, 2011 3:52 PM in response to Vincent Danen

Hi,


I have similar problem, I can not connect to my Lion server to the SSH and IMAP services using Kerberos to authenticate :-|


The server is able to mount kerberized NFS volumes, but do not accept kerberos clients :-|


Mi Lion client is able to connect to other kerberized services in other platforms (SnowLeopard, Linux, Solaris), but not Lion Server!!! Amazing.....


My KDC is a Solaris Kerberos server.


Thanks in advance for any idea.


H.

Jul 21, 2011 3:57 PM in response to hmolina

Wait... you are able to get a Lion client to authenticate to a solaris KDC?


How?!?!


How did you configure the Lion client to do anything more than return errors? What configuration files did you edit/create? Clean update or did you have an existing Snow Leopard install that you upgraded?


Details please! We can't even obtain a ticket on a Lion client, nevermind connecting to a Lion server (I've not put out any $$ on Lion server when Lion client isn't doing what I really need it to do first!).


Please share any and all configuration details of the Lion client that you can! Maybe if we can make the Lion client actually work, we might be able to help you with your connection to the Lion server.


Thanks!

Jul 21, 2011 5:08 PM in response to Vincent Danen

Hi!


Sincerly.. I don't do anything new. I reuse mi old /etc/krb5.conf :-|


From my Lion Client and Server I am able to use kinit to request kerberos tickets, and use them to authenticate to all my kerberized services (NFS, IMAP, HTTP, SSH, LDAP) in other servers, but it do not work with the Lion server.


I am not able to connect to my KDC with the Lion kadmin....


When I try to connect to the Lion Server, it reply the new ticket, but (i think) he is not able to recognize them :-|, so it reject the ticket.


I will try to change the /etc/authorization file to try to automatic kinit in the login process in my iMac desktop.


This is my /etc/krb5.conf


I hope this be useful for other people.


Best regards.


H.


#

#pragma ident "@(#)krb5.conf 1.2 99/07/20 SMI"

# Copyright (c) 1999, by Sun Microsystems, Inc.

# All rights reserved.

#



# krb5.conf template

# In order to complete this configuration file

# you will need to replace the __<name>__ placeholders

# with appropriate values for your network.

#

[libdefaults]

default_realm =MY_REALM

renewable = true

forwardable= true

ticket_lifetime = 20d

renew_lifetime = 1d

default_tgs_enctypes = aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5

default_tkt_enctypes = aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5









[realms]

MY_REALM = {

kdc = FQDN_MASTERKDC:88

kdc = FQDN_REPLICA1KDC:88

kdc = FQDN_REPLICA2KDC:88

kdc = FQDN_REPLICA3KDC:88

admin_server = FQDN_MASTERKDC:749

default_domain = dns_domain

}



[domain_realm]

dns_domain = MY_REALM



[appdefaults]

kinit = {

renewable = true

forwardable= true

renew_time = 24h

ticket_lifetime = 20d

}

Jul 21, 2011 6:32 PM in response to hmolina

Interesting. Ok, your /etc/krb5.conf doesn't work for me, but I am finding out something even more interesting. It looks like /Library/Preferences/edu.mit.Kerberos is still valid. On my macbook air, I have two realms defined: one for work, one for home. I _can_ kinit to the work realm (also running Red Hat Enterprise Linux), but I cannot kinit to the home realm. I'm at a loss as to why. My /Library/Preferences/edu.mit.Kerberos looks like this (I have no /etc/krb5.conf):


[domain_realm]

.home.com = HOME.COM

home.com = HOME.COM

.work.com = WORK.COM

work.com = WORK.COM



[libdefaults]

default_realm = HOME.COM

allow_weak_crypto = yes

dns_lookup_realm = false

dns_lookup_kdc = false

ticket_lifetime = 36000



[realms]

HOME.COM = {

admin_server = kerberos.home.com

kdc = kerberos.home.com

default_domain = home.com

}

WORK.COM = {

admin_server = kerberos.corp.work.com

kdc = kerberos.corp.work.com

default_domain = work.com

}



[logging]

kdc = FILE:/var/log/krb5kdc/kdc.log

admin_server = FILE:/var/log/krb5kdc/kadmin.log



I'm completely scratching my head on this one. Obviously, Lion _is_ capable of obtaining tickets, but I'm not sure why it will work on one but not the other. It might be server settings, but kinit isn't giving me any real information because:


% kinit

user@HOME.COM's Password:

kinit: krb5_get_init_creds: unable to reach any KDC in realm HOME.COM


isn't overly helpful. =(


Both servers are MIT Kerberos (the work KDC might be running on RHEL5, my home KDC is running RHEL6 (the work one might as well, but I have no way of finding out easily)).


Each time I try the work one, after connecting to the VPN, I get a ticket (have done so a half dozen times now, not one failure). This makes absolutely no sense. I set the odutil command noted in an earlier comment to enable debug logging, and saw some attempts to do a lookup in the /Local/Default directory for the host, but...


Ha!


Ok, this is fun.. type and work at the same time. Sorry if the above is a bit of a notepad, but... maybe it will help others find it.


Seems like the problem was I did not have UDP ports 88 and 749 open on the KDC (there was no need before, everything with MIT Kerberos went over TCP). However, heimdal seems to want _UDP_. Opening those ports on the KDC's firewall is all it took, and now I can kinit fine on this laptop. Will try my wife's in a moment.


hmolina, maybe see if the firewall on the Lion server is allowing UDP connections to those two ports?

Jul 21, 2011 7:32 PM in response to Vincent Danen

Just another status update. There are still oddities here.


SSH works. Using safari to visit a mod_auth_kerb-protected site works.


Subversion does not work for some reason. Nor does Google Chrome (I have Chrome kerberized on launch, works great on 10.6). So it's not fully there. Even the Apple-supplied subversion (/usr/bin/svn; I also have fink installed and /sw/bin/svn is the same 1.6.16 version) doesn't work.


The server reports:


[Thu Jul 21 20:25:43 2011] [error] [client 192.168.250.109] gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (Unknown code krb5 144)


Strange thing is that if I klist on the client, I have tickets for those services, but for some reason svn and Chrome aren't picking up on them. Not sure what that means yet.

Jul 21, 2011 10:51 PM in response to Vincent Danen

I got it nearly working (and partly even better than in SL).


  1. removed /Library/Preferences/edu.mit.Kerberos
  2. created /etc/krb5.conf


The latter now seems to be considred (it was not in SL). However, the syntax changed. The differences between the former and the one I use now are the following:


[libdefaults]

default_realm = ...

default_etypes = arcfour-hmac-md5

default_etypes_des = des-cbc-md5,des-cbc-crc


KDC is an Active Directory Server 2008 R2.


ssh, imap, smtp, web works with Kerberos-authentication.


However: we restrict encryption-types in order to allow NFS with sec=krb5 on Linux-hosts. NFS worked in SL, but not in Lion anymore. The following error is reported in /var/log/system.log:


Jul 22 06:24:25 ... com.apple.netauth.user.auth[1687]: mount_nfs: can't mount /export/dat/... from ... onto /Volumes/...: Permission denied

Jul 22 06:24:41 ... gssd-agent[1689]: nfs client Kerberos...:/export/dat/..., uid=... - unknown mech-code 2529638926 for mech unknown


Checking tickets in a terminal after the attempt does not reveal any nfs-ticket!


Command was:


/sbin/mount_nfs -o resvport,sec=krb5 ...:/export/dat/... /tmp/a


Anyone an idea?


The good part is, that smb now works in the Finder (it did not for us in SL). So we could use that, but actually NFS/automounter would be nicer as it does not require passwords.


And yes, like other before me stated as well: Lion gives me the impression of a not quite ready product. The interface changes are nice, but the enterprise features are buggy and all that hiding of formerly visible directories s..... Guess we are not that far away from the point, where the terminal and X11 vanish for ever, which - to my opinion - would diminish greatly the use fullness of OSX in the edu market.

Jul 22, 2011 2:05 AM in response to Vincent Danen

Hi Vincent,



About the problem kinit is not able to reach KDC: sometimes I had the same problem in a linux boxes in my workplace. Add a new line in the /etc/hosts file with the KDC's IP address BUT (and this is important) use the FQDN in first place:


192.168.1.1 kerberos.home.com kerberos


If you use just the hostname, does not work


About the firewall: I deactivate the firewall in the Lion Server while I finish the migration, in order to avoid any communication restriction.


Thanks in any case.

Jul 22, 2011 2:32 AM in response to Vincent Danen

FYI:


To activate the kerberos ticket request at login in the MacOS Lion (Server or standalone), you can modify the /etc/authorization file making the follow changes:


In section system.login.done


<key>system.login.done</key>

<dict>

<key>class</key>

<string>evaluate-mechanisms</string>

<key>mechanisms</key>

<array>

<string>builtin:krb5authnoverify,privileged</string>

</array>

</dict>


changing

<array/>

for

<array>

<string>builtin:krb5authnoverify,privileged</string>

</array>

And in system.login.tty make the follow changes:


add <string>builtin:krb5login</string> in mechanisms array. The final setting looks like:


<key>system.login.tty</key>

<dict>

<key>class</key>

<string>evaluate-mechanisms</string>

<key>mechanisms</key>

<array>

<string>push_hints_to_context</string>

<string>authinternal</string>

<string>builtin:krb5login</string>

</array>

<key>tries</key>

<integer>1</integer>

</dict>


There are the same changes for SL, but was deactivated in the migration process.....


I hope this information be useful for anybody


H.

Jul 23, 2011 12:03 PM in response to Vincent Danen

Hi,


After the upgrade to Lion, I too had difficulties in getting Kerberos working. This thread proved very helpful in tracking down and resolving the problem - many thanks for that. I thought it may be helpful to summarize what eventually worked for me.


With the switch from the MIT to Heimdal Kerberos implementation, the default connection type changed from TCP to UDP (as mentioned previously in this thread). Since my KDC (Key Districution Center) does not allow UDP connections on port 88 and 749, I was unable to request a Kerberos ticket. The kinit command simply hangs with no response and Ticket Viewer fails with "Invalid Password".


Since I do not have control over my KDC, I needed to find a way to force Heimdal to use TCP. This was achieved by prepending "tcp/" before each server name in the krb5.conf file (or edu.mit.Kerberos). Using the example from this posting, it should be as follows:


[realms]

HOME.COM = {

admin_server = tcp/kerberos.home.com:749

kdc = tcp/kerberos.home.com:88

default_domain = home.com

}

WORK.COM = {

admin_server = tcp/kerberos.corp.work.com:749

kdc = tcp/kerberos.corp.work.com:88

default_domain = work.com

}


The only other change that was required was to the default encryption types, which I set as follows:


default_etypes = arcfour-hmac-md5

default_etypes_des = des-cbc-md5,des-cbc-crc

default_tgs_enctypes = des-cbc-md5,des-cbc-crc

default_tkt_enctypes = des-cbc-md5,des-cbc-crc

permitted_enctypes = des-cbc-md5,des-cbc-crc


As for the configuration, both /etc/krb5.conf and /Library/Preferences/edu.mit.Kerberos seem to be valid, but ensure that you only have ONE present.


After this, both kinit and Ticket Viewer worked as they did under Snow Leopard (10.6).


Regards,
Dave

Jul 24, 2011 4:07 AM in response to antst

You can mount NFSv3 with Kerberos? Thats goog news and is what we could do in SL (but not in Lion any more). Could you please post your /etc/krb5.conf. Is there a /Library/Preferences/edu.mit.Kerberos? What is the exact command you use to mount using NFSv3?


Do you see any error-messages logged to /var/log/system.log (from gssd, see my previous post above).


Thanks in advance,

Peter

Jul 24, 2011 4:56 AM in response to pwcaligari

There is my /Library/Preferences/edu.mit.Kerberos


Important to note that I have OD server.


[libdefaults]

default_realm = my.realm

[realms]

my.realm = {

admin_server = kdc.at.my.realm

kdc = kdc.at.my.realm

kdc = secondary.kdc.at.my.realm

}

[domain_realm]

.realm = my.realm

realm = my.realm

[logging]

kdc = FILE:/var/log/krb5kdc/kdc.log

admin_server = FILE:/var/log/krb5kdc/kadmin.log



I mount NFS directories from Solaris 11 Express server.

I do mount non from root, but from mu user account. (after kinit of course)

different ways works:


mount_nfs -o vers=3,sec=krb5 nfs.server:/export/share/test /tmp/qq1

/usr/libexec/mount_url "nfs://nfs.server/export/share/test" /tmp/qq1


(mounts are exported with sec=krb5:krb5i, so mount_url also mounts it with sec=krb5/5i)


When I mount as

mount_nfs -o vers=4,sec=krb5 nfs.server:/export/share/test /tmp/qq1

then I see in the logs


7/24/11 1:55:58.000 PM kernel: nfs_gss_clnt_gssd_upcall: gssd port not valid

7/24/11 1:55:58.000 PM kernel: nfs4_setclientid failed, 13

Does anyone know how to configure Kerberos with Lion?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.