Home › Forums › OS X Server and Client Discussion › Active Directory › 10.5.4: AD administer group users lose rights when off network

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • August 9, 2008 at 10:56 pm #373697
    erd
    Participant

    We have 10.5.4 laptops and AD user authentication. Teachers are to be admin users by the “allow administration by” option in the Directory Utility Active Directory services. The teachers log in to the computers and their account on campus shows admin, mobile. They, however, appear to lose their admin rights when they go home or off of the schools network. Has anyone else encountered this?

    August 10, 2008 at 7:03 pm #373698
    larkost
    Participant

    This depends on an MCX group (that is how it is implemented in the background), and MCX groups are not cached on the client, only mobile users are (not a great solution in my opinion), so if you can’t see your directory service, you can’t resolve groups from your AD (or OD, or LDAP) servers.

    There are a couple of ways around this: since your admin users are probably relatively static you could add a loginhook that would look to see if the user was in your admin group on your AD server (I assume this is how you are controlling it), and then add them to the local admin group. Actually, for ease of troubleshooting I would create another local admin group, then nest that one in regular admin group.

    The code might look something like this (not tested… and off the top of my head just to give you a starting point):

    [code]c
    #!/bin/bash

    AD_PATH=’/Active Directory/mydomain.here.com’
    REMOTE_ADMIN_GROUP=’domain_admins’
    LOCAL_ADMIN_GROUP=’admin’

    for user in `/usr/bin/dscl “$AD_PATH” read Groups/$REMOTE_ADMIN_GROUP GroupMembership | /usr/bin/awk ‘sub(“GroupMembership: “, “”)’`; do
    if [ “$user” -eq “$1” ]; then
    /usr/bin/dscl . merge Groups/$LOCAL_ADMIN_GROUP GroupMembership “$1”
    fi
    done

    exit 0
    [/code]

    This will make them a local admin every time they log in and are on the network, and that will remain even when off-network. Note that this will add them, but never remove them. If you ever want to remove someone you will have to do it manually (or add this to the script). You will also have to adjust the variables at the top of the script to your environment.

    January 5, 2009 at 11:58 pm #375079
    Macleod
    Participant

    Strangely enough, 10.5 caches group information for users in their user account, but does not cache groups at all.
    This means that locally cached user accounts will show which groups they are a member of, as well as all the other members in that group.
    try dscl . read /Users/username cached_groups
    Unfortunately, the group lookups in 10.5 do not think to look in the user record for group info. 🙁
    While connected, you should be able to type dseditgroup -o checkmember -m youradadmin youradgroup, and successfully resolve group membership. Disconnecting will cause the same command to fail.
    Hopefully this is an issue that will be resolved. Remember, 10.5 ushers in the “single daemon” approach to user and group lookups, so it was bound to have a few teething pains.
    The fact that the group info is cached in the user account does mean that you can hack some solutions.

    The code larkost offered looks like it would probably work to add the admin group members to the local admin group, but you may not want to hard code your users in the admin group.
    If you would rather nest things, like the plugin does when its online, you can use the dseditgroup command. This command can be used to create and edit groups with ease, so taking advantage of that we can do something like this:
    Create a local group (dseditgroup -o create -r “Group Name” groupname), and nest it in the admin group (dseditgroup -o edit -a groupname -t group admin). At login, if the user is in the network admin group (read from their cached account), add them to the nested group you created (dseditgroup -o edit -a username -t user groupname).
    At logout, either remove the users from the nested group, or destroy the group.

    Or if you prefer to do things in one fell swing, when connected, iterate the members of the AD group that has admin access as larkost has suggested, but add them all to the local nested admin group. This would basically do the exact same thing as his code, but keep your admin group cleaner, and allow for easy disablement of your network admins if you so choose. This makes it easier to try to do something like swapping the offlineadmins group in and out based on reach-ability of your DC.

    Good luck.

    January 8, 2009 at 12:20 am #375089
    erd
    Participant

    Thank you for the reply, Macleod. I’ll test this out.

    April 16, 2009 at 4:38 pm #376009
    dds
    Participant

    This has affected my laptop users too. I just make sure to make them local admins when Im deploying their system. This can be done by hand, via SSH or through some outomated/scripted process. I dont have too many laptop/mobile users so its not a huge deal.

    dscl . -append /Groups/admin GroupMembership

    May 11, 2009 at 9:36 pm #376152
    erd
    Participant

    Thanks, dds. I am not very familiar with dscl. Do I need to add any other text to the command:
    dscl . -append /Groups/admin GroupMembership
    I’m just trying to type it in terminal first to test and then will push out as script.

    Thanks.

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

Comments are closed

Copyright © 2025 AFP548. All Rights Reserved.