Forum Replies Created

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • in reply to: iLife Support 9.04 #380015
    Mike Boylan
    Participant

    Aha – ndpete mentioned not running it on the server version of OS X. That seemed to be the problem. I ported the InstaDMG folder over to a client mac and built the image there and sure enough, iLife Support was baked in. Glad that’s taken care of…

    in reply to: iLife Support 9.04 #380009
    Mike Boylan
    Participant

    Hi Guys,

    I’m having this same problem. I’m starting with a 10.6.0 retail disc and here are my catalogs (top down – each one includes the one below it):
    [url]http://pastie.org/1320818[/url]
    [url]http://pastie.org/1320820[/url]
    [url]http://pastie.org/1320823[/url]
    [url]http://pastie.org/1320824[/url]

    I’ve literally tried putting that iLife Support package in all different locations throughout the build. I started with before iLife, then directly after iLife, and now, as a last resort, I put it at the end right before the create admin user package.

    Upon boot, iLife Support still shows in software update.

    This is really odd – I wonder what’s different for those of us having the problem?

    Mike Boylan
    Participant

    Thanks for the reply! I had found that article as well and it seemed to work for us, too.

    However, after some discussion with our Apple Systems Engineers, we decided to stick with all OD and ditch the idea of having the dual directory structure with augmented records. Essentially the main question they asked us was “Why?” Our Mac install base isn’t very large, and it’s not a whole lot of work to run the oracle export through Passenger and import the accounts into OD. It’s like a 20 minute process. The main advantage for us was going to be integration with our Password Change service, but it looks as though we can do a native OD password change script anyway.

    I wish you the best of luck, though. The vibe we got from our SEs was to really not go down the road of augments for two different home folders, and especially not for syncing. It can and should work, but it’s supported very little and can always be prone to problems.

    As far as scripting the augmentation process, Mike Bombich has a nicely script written to do this. It’s at the bottom of this page:
    http://www.bombich.com/mactips/scripts.html

    You’ll have to add support for the keyword attribute in your augmentconfiguration as well as the home folder attributes. It’s all documented in the Read me.

    Good luck!

    Mike Boylan
    Student IT Assoc Sys Admin
    Mac OS X / Mac OS X Server
    Robert Morris University

    in reply to: AD authentication OD Mobile Account 10.6.2 #378532
    Mike Boylan
    Participant

    When I first read your thread, I didn’t think it was related to mine because you specifically mentioned not using augments. However, if you want to have [i]separate[/i] windows and mac home directories, it is absolutely necessary to augment the records, as confirmed by our Apple engineers today.

    That being said, I didn’t realize our threads were so similar – but they are. In my thread, I describe essentially the exact some problem. Mobile accounts for augments (AD users) are asking for a password on manual sync or logout sync. Login sync doesn’t even check. Sometimes it just says “never synced” and won’t even let you sync. Very sporadic behavior. The server is definitely kerberized correctly in the AD realm because logging in as an augment [i]without[/i] any mobility prefs set successfully generates the right tickets.

    Talking to our apple engineers a bit more today, essentially they said to avoid augments at all cost unless absolutely necessary. In fact, they weren’t even going to mention them in the presentation. They also said they were aware of a kerberos problem with AD accounts and linked me to that article you found on your own about forcing a tgt for an AD login.

    I have yet to see if that works for us. Unfortunately, I may not test it at all as we essentially decided today, with the encouragement of the engineers, to just keep our AD and OD records separate but write a password change script for OD available to our students on our password reset website.

    If I do have time to test it though, I’ll definitely let you know what I find out. And if you find anything out, I’d love to hear it as well.

    Mike Boylan
    RMU IT :: Mac OS X

    Home



    @mboylan
    on Twitter

    Mike Boylan
    Participant

    Thanks. I saw this actually and it served as the guide for my efforts. I talked with the creator a bit over the weekend because it’s (obviously) not working for me. :p

    Hopefully someone else has tried this. 🙂

    in reply to: “The Cylinder of Destiny” #378495
    Mike Boylan
    Participant

    [QUOTE][u]Quote by: nvp[/u][p]Has anyone setup “The Cylinder of Destiny” with Snow Leopard??

    I’ve add all the necessary attributes to my augmented user to get an AFP home folder but when I run the createhomedir -s command, nothing happens.

    I’ve search but I can’t find that much documentation about it….[/p][/QUOTE]
    —————————————–
    Yes, I have a successful working test environment running on my desk in the office on a Mac Mini acting as a server. Network home directories for augmented users are working great. The order in which you do things is very, very important.

    Essentially:
    1.) Ensure *perfect* DNS records, both forward and reverse.
    2.) Bind to AD
    3.) Kerberize your services
    4.) Promote to OD master and verify kerberos wasn’t configured for the OD domain. You can verify this by looking for the following in the slapconfig log:
    “Not configuring Kerberos for this OD master. Remove all nodes on Search Policy except Local Nodes to kerberize this server”

    Initially, the createhomedirs wasn’t working for me either, but a combination of the following fixed that.

    Make sure that you have edited the augmentconfiguration record in the config section in workgroup manager to allow for the two home directory attributes you’re trying to add to the augmented user. Also make sure in the AD connector (both on client and server) that you uncheck everything but “Default user shell” on the first pane of options. (The “use unc path…” was overriding the attributes for the augment for me.) Then, kill DirectoryService, or preferably, reboot the server. This forces DirectoryService to notice the changes you made to the augmentconfiguration to allow for the additional attributes for the augments.

    Try running the createhomedir command again. If nothing happens, what happens if you specifically specify the user with the -u? sudo createhomedir -u augmentuser

    Verify using dscl that the server is correctly finding the attributes for the augment:
    dscl /Search -read /Users/augmentuser NFSHomeDirectory HomeDirectory

    It should spit back the two attributes you’ve defined for it.

    I’m new to this dual-directory setup as well, so if none of this works for you, then hopefully someone else can chime in here. 😀

    Mike Boylan
    RMU IT :: Mac OS X

    Home



    @mboylan
    on Twitter

    in reply to: Kerberized services only work on AD DNS subdomain #378465
    Mike Boylan
    Participant

    Thanks for this thread. I was having this issue as well, and sure enough, that article was exactly what I needed.

    Also, peet, you were correct about AFP. I also needed to edit the AppleFileServer plist file to point it to the right kerberosPrincipal.

    For SMB, though, readding and restarting the service seemed to force it to use the correct principal. I did reboot the server after making the change on the AD controller but before doing this though. Not sure if that had any affect or not.

    Also, Arek, big thanks to you on the excellent Directory Services book for 10.6. I’m learning more than my brain can take in. :p

    Thanks,
    Mike Boylan
    RMU IT :: Mac OS X

Viewing 7 posts - 1 through 7 (of 7 total)