AFP548 Changing the world one server at a time.

Managing Open Directory Accounts from Unix/Linux

Home › Forums › OS X Server and Client Discussion › Open Directory › Managing Open Directory Accounts from Unix/Linux

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #377317
    jonabbey
    Participant

    Hello World!

    We are moving to add support for a dedicated Open Directory cluster in
    our laboratories for our Mac users.

    We currently have Active Directory, NIS, DHCP, DNS, Radius, and a
    bunch of custom applications that are being managed by a sophisticated
    and open source directory mastering application we wrote called
    Ganymede.

    Our intention is to have Ganymede create and administer accounts in
    Open Directory from a non-Mac Unix server, as we do for all of the
    rest of our directory services.

    My question is, how can one communicate with Apple’s Password Server
    from a non-Macintosh system?

    Currently, I am syncing to Open Directory via both LDAP and Kerberos.
    Whenever changes are committed by our admins in Ganymede, a sync
    process (written in Python) runs to create or update user and group
    accounts on Open Directory via LDAP. This sync process also uses
    kadmin to create, delete, and/or change passwords for the Mac users’
    Kerberos principals on the Open Directory server.

    As I understand it, Kerberos (kadmin) is the intended control
    mechanism for Password Server.

    Unfortunately, when my sync process uses kadmin to create or update a
    principal’s credentials, Password Server is unaffected.

    If I login to the Open Directory server system, I can do a
    ‘listprincs’ under kadmin and see all of the users that should have
    accounts on the Mac. I can go into Workgroup Manager and see all the
    accounts via LDAP.

    What I cannot do is see any of the accounts when I do a ‘mkpassdb
    -dump’. It appears that the kadmind daemon on our Open Directory
    server is simply not passing password information to the Password
    Server.

    I assume that what is missing is a value in the authAuthority entry
    for the user accounts that tells Kerberos to go ahead and push the
    password information over to the Password Server.

    I’m generating a unique UUID for all of our accounts, and I’m creating
    an authAuthority record for them in LDAP that looks like this:

    Kerberosv5;%s;%s@OD1.ARLUT.UTEXAS.EDU;OD1.ARLUT.UTEXAS.EDU

    where the first %s is the UUID and the second is the account’s short
    name.

    I can create a value for the password server similar to the following:

    authAuthority: ;ApplePasswordServer;0x00000000000000000000000000000001,1024 3
    5 13461273668355270159481515931670032704170039349483239870599168641207915799
    2253311122849860052497272739025434735508259611557374537234079641707448624039
    3286777943430050541948856431196727459300481913219916739421096063046092821131
    6857660859939156230303624142209129786180953928012077465284300310249603868628
    9599831 root@od1.arlut.utexas.edu:10.4.16.14

    but I don’t have any a priori way of knowing the public key that
    should be in this value, nor do I know if creating an entry in LDAP
    with an appropriate authAuthority value will cause kadmind on the Mac
    server to do the right thing when I go to create/update the principal.

    I will run the experiment today, but I’m surprised that I can’t find
    any documentation that touches on the specific details of what must be
    done to manage Mac users in Open Directory from a non-Mac system.

    Has anyone else out there had any experience with this? Am I on the
    right track? Is there a right track?

    I can write a daemon to run on the Mac and make DirectoryService API
    calls for me if I have to, but I’d prefer not to have to take that
    step if I don’t have to.

    Thanks,

    Jon

    #377318
    jonabbey
    Participant

    Ah, this is on an up-to-date Leopard server, if it matters.

    I also sent this to macos-x-server@lists.apple.com, but I will summarize any helpful replies to both fora.

Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.