[...]Tiger to Leopard Server Migration, Part Two | Netmojo Systems[...]…

[...]Tiger to Leopard Server Migration, Part Two | Netmojo Systems[...]…

[...]Tiger to Leopard Server Migration, Part Two | Netmojo Systems[...]…

I figured it out. So, basically, the kerberosv5 entry is pretty much the same as the ApplePasswordServer entry, only it has the realm info shoved in there.

So, I wrote up a basic script that’ll do the dirty work of a couple “sed”s and add those entries to the users that don’t have them.

It can be found here: http://www.staze.org/static/addKerberosv5.sh

The comments on the script are larger than the script itself, and I’m by no means a SH wizard, so there’s probably a faster way to do it than what I did. But, either way, there you go. =)

I’ve been looking into this some more (finally), and it seems that the rsa “key” is the same for both the passwordserver and kerberosv5 section for all the users, but the slot ID is specific to each user.

So, it should be possible to write a script that finds the slot-ID for a user using mkpassdb -dump | grep username, then constructs the appropriate value for the kerberosv5 entry based on that, and the RSA key.

It’s odd to me that slapconfig -kerberize hangs, and doesn’t actually populate this info on users that don’t have it. It’s also odd that my passdb is full of ancient users that have been gone for years. I’d think it would remove those entries… I’ve been toying with the idea of writing a script to remove them with mkpassdb -deleteslot.

At this point, on a test server, I have removed all the authAuthority: ;Kerberosv5 entries for all the users. I guess next I’ll work out a script to repopulate that info. Will post more when I have something. Certainly let me know if you have anything that might help.

I tested on a larger directory, and got the same results. Some of the users have what appear to be the same keys, but many are different. I would like to know the relationship between these values and the Password Server and Kerberos databases. A specific key probably does not align with a specific password or account in the database, since some users share the same key. I thought that these keys simply matched a particular password server or kerberos server, but obviously servers do not require unique keys. I don’t have time to investigate right now. If you’re going to do this, I’d appreciate it if you let me know what you find.

Thanks!
Brent

Example:

server:~ admin$ dscl /LDAPv3/127.0.0.1 read /Users/user1 dsAttrTypeNative:authAuthority
dsAttrTypeNative:authAuthority:
;ApplePasswordServer;0x470bb9eb325f31c3000040ee00002257,1024 35 142348687369980182134507175767473848406728018835938950439244504199810591467084867869429532763785664902803450035110236201552277202539905523086333992178101548673534094938083763850217881171960226316582341046758647121979394968026644558722582733133246430363127883800192071325741645982074225105651514207812440564579 root@server.example.com:123.123.123.123
;Kerberosv5;0x470bb9eb325f31c3000040ee00002257;user1@EXAMPLE.COM;EXAMPLE.COM;1024 35 142348687369980182134507175767473848406728018835938950439244504199810591467084867869429532763785664902803450035110236201552277202539905523086333992178101548673534094938083763850217881171960226316582341046758647121979394968026644558722582733133246430363127883800192071325741645982074225105651514207812440564579 root@server.example.com:123.123.123.123
server:~ admin$ dscl /LDAPv3/127.0.0.1 read /Users/user2 dsAttrTypeNative:authAuthority
dsAttrTypeNative:authAuthority:
;ApplePasswordServer;0x48c859af4df339b7000043aa00002a0a,1024 35 142348687369980182134507175767473848406728018835938950439244504199810591467084867869429532763785664902803450035110236201552277202539905523086333992178101548673534094938083763850217881171960226316582341046758647121979394968026644558722582733133246430363127883800192071325741645982074225105651514207812440564579 root@server.example.com:123.123.123.123
;Kerberosv5;0x48c859af4df339b7000043aa00002a0a;user2@EXAMPLE.COM;EXAMPLE.COM;1024 35 142348687369980182134507175767473848406728018835938950439244504199810591467084867869429532763785664902803450035110236201552277202539905523086333992178101548673534094938083763850217881171960226316582341046758647121979394968026644558722582733133246430363127883800192071325741645982074225105651514207812440564579 root@server.example.com:123.123.123.123


So, don’t think that’ll work… can you confirm your’s are the same for any user?

I’ll give this a shot on my test OD master and write back…

Any idea what the kerberos auth entry actually gives you? users without that still get tickets…

Also, semi-related… the users that don’t have kerberos entries also can’t seem to have their ical server set. Could this have something to do with it?

And, have you heard anything about the “Allow simultaneous login…” being broken in WGM? even with it unchecked, users can login multiple times, and yes, they are on managed clients, and yes, they’re network home directories. =P

Thanks Brent!


for user in `dscl /LDAPv3/127.0.0.1 list /Users | grep -E "[^root|diradmin]"`;
do
dscl -u diradmin -P s3cr3t /LDAPv3/127.0.0.1 delete Users/$user dsAttrTypeNative:authAuthority
dscl -u diradmin -P s3cr3t /LDAPv3/127.0.0.1 create Users/$user dsAttrTypeNative:authAuthority ';ApplePasswordServer;0x4a1db4...'
done


Only users “root” and “diradmin” are excluded — you may want to expand that list. I noticed that the vpn user doesn’t have the kerberos part of the authAuthority attribute, probably because you don’t want that user to be able to login…