How do you get the Kerberos Realm into the directory?

[flowctrl]

Hello,

Leopard server has been running for a week now, with clients doing network logins and other wonderful things. However, “single signon” isn’t really working. Users get prompted for passwords as if Kerberos wasn’t enabled, despite that the users, hosts and services for those hosts all have kerberos principles on the KDC.

I noticed this today though:
[code]
# sudo sso_util info -g
Default Realm Name: MYHOST.MYREALM.CA

# sudo sso_util info -r /LDAPv3/127.0.0.1/
The Local realm name is:(null)
[/code]

From the sso_util man page, it looks like the ‘configure’ command may be what I need, but I want to be careful not to over-write all of the existing credentials in the KDC. What would be the best way to get the Kerberos Realm into the directory?

When new clients join the directory, they do get the correct REALM, and the services are auto-configured for them, so there is a directory entry for the client configuration data, but apparently Open Directory doesn’t know it’s realm, or am I misunderstanding this “Local realm” thing?

Thanks!

[flowctrl]

Yes, the clients that are bound to the directory have edu.mit.Kerberos files from the server, and the server itself has the same file in /Library/Preferences. In the files, the realm and other data is correct.

On the server, in /Library/Logs/SingleSignOnTools.log, I have this, repeated over and over:

[code]
This machine is part of a kerberized directory, realm name is:
This machine is part of a kerberized directory, realm name is:
This machine is part of a kerberized directory, realm name is:
[/code]

I’m guessing that the LDAP server holds the client configuration data for the edu.mit.Kerberos files in cn=KerberosClient,cn=config…, but keeps configuration data for the server itself in a different part of the directory.

I took a look at the results of an ‘ldapsearch “(objectclass=*)”‘, and I see an entry that looks like a good candidate, but seems to have the correct the realm name:

# KerberosKDC, config, mydomain.ca
dn: cn=KerberosKDC,cn=config,dc=mydomain,dc=ca
cn: KerberosKDC
objectClass: apple-configuration
objectClass: top
apple-config-realname: MYSERVER.MYDOMAIN.CA
apple-kdc-configdata:: W2xpYmRlZmF1bHRzXQo…

Maybe the missing data should be part of the binary apple-kdc-configdata?

[John Lockwood]

Is your Leopard server an upgrade of a 10.4 server, or a Leopard server in to which you have restored an Open Directory database backed up from a 10.4 server?

I and someone else who I regard as technically competent have both had problems with Kerberos not working on Leopard servers. In my case I had restored an Open Directory database as a method of moving the accounts to a new replacement Leopard server (DNS etc. settings were identical so it could just be swapped in), in the other persons case he did an upgrade over the top of an existing Tiger server. Both resulted in Kerberos being completely broken.

I tried multiple times, making the Leopard server an OD master and then restoring the 10.4.11 OD data, however, when I did another test of making on the same new 10.5.1 server a fresh empty Open Directory master and then importing accounts exported from a 10.4.11 Workgroup Manager, then Kerberos did work fine (with all other settings like DNS unchanged).

I therefore suspect that Leopard server is currently broken in terms of upgrading a 10.4 Open Directory database (which both scenarios involve).

[robinson]

[QUOTE][u]Quote by: flowctrl[/u][p]…
I noticed this today though:
[code]
# sudo sso_util info -g
Default Realm Name: MYHOST.MYREALM.CA

# sudo sso_util info -r /LDAPv3/127.0.0.1/
The Local realm name is:(null)
[/code]

From the sso_util man page, it looks like the ‘configure’ command may be what I need, but I want to be careful not to over-write all of the existing credentials in the KDC. What would be the best way to get the Kerberos Realm into the directory?

When new clients join the directory, they do get the correct REALM, and the services are auto-configured for them, so there is a directory entry for the client configuration data, but apparently Open Directory doesn’t know it’s realm, or am I misunderstanding this “Local realm” thing?

Thanks!

[/p][/QUOTE]

I have exactly the same situation. But when I make a ldapsearch, I get an error:

[code]sh-3.2# ldapsearch “(objectclass=*)”
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No credentials cache found)
sh-3.2#
[/code]

How to correct this?

[coincident]

[code]
# sudo sso_util info -r /LDAPv3/127.0.0.1/
The Local realm name is:(null)
[/code]
But, without the trailing forward slash:
[code]
# sudo sso_util info -r /LDAPv3/127.0.0.1
The Local realm name is:YOUR_REALM_HERE
[/code]

[flowctrl]

[QUOTE][u]Quote by: coincident[/u][p][code]
# sudo sso_util info -r /LDAPv3/127.0.0.1/
The Local realm name is:(null)
[/code]
But, without the trailing forward slash:
[code]
# sudo sso_util info -r /LDAPv3/127.0.0.1
The Local realm name is:YOUR_REALM_HERE
[/code]
[/p][/QUOTE]

haha! I love it when the solution is totally simple.

Thanks.

[wstrucke]

[QUOTE][u]Quote by: John+Lockwood[/u][p]Is your Leopard server an upgrade of a 10.4 server, or a Leopard server in to which you have restored an Open Directory database backed up from a 10.4 server?

I and someone else who I regard as technically competent have both had problems with Kerberos not working on Leopard servers. In my case I had restored an Open Directory database as a method of moving the accounts to a new replacement Leopard server (DNS etc. settings were identical so it could just be swapped in), in the other persons case he did an upgrade over the top of an existing Tiger server. Both resulted in Kerberos being completely broken.

I tried multiple times, making the Leopard server an OD master and then restoring the 10.4.11 OD data, however, when I did another test of making on the same new 10.5.1 server a fresh empty Open Directory master and then importing accounts exported from a 10.4.11 Workgroup Manager, then Kerberos did work fine (with all other settings like DNS unchanged).

I therefore suspect that Leopard server is currently broken in terms of upgrading a 10.4 Open Directory database (which both scenarios involve).[/p][/QUOTE]

I also have been unable to get kerberos working on a 10.5.5 server with an imported 10.4.11 directory. Does anyone have any clues on how to fix kerberos without destroying authentication?

[Author]

Posts