[Macleod]

I suggest you read the man page for pwpolicy, or goole around pwpolicy -enableuser.
The exact syntax can be tricky.

[Macleod]

The directions are in the first post, but I’ll expand them a bit here.
Use this from the command line:
dscl . -read /Users/cachedusername AuthenticationAuthority
Replace cachedusername with the name of the user account you suspect is locked.
If you see ;DisabledUser; in the output, the user account is locked in the local node.
You can also run Workgroup Manager on the machine in question and point it to the local node. Dismiss the login dialog when launching WGM, choose View Directories from the Server drop down, and then change the “Viewing” drop down menu to point to the local node.
Locked users show with a red X over their user icon, and have the “access account” checkbox unchecked.

[Macleod]

Scarrab, just to clarify, did you check the local directory (dslocal/nodes/Default), or OpenDirectory?
Locked in the local directory domain is not the same as locked in the OD domain.
The user’s accounts in the OD domain would be fine, and unlocked. Thats why they can login to other machines.
When a cached account is locked in the local domain, you get the exact circumstances you mentioned: user can still login elsewhere, account no longer shows in System Preferences, users’s home folder is untouched. That this happened after applying password policy makes it even more likely that you are dealing with a cached account lockout issue.
The only other thing that would make sense would be the user’s cached accounts expiring due to MCX. You can set an expiration for cached credentials via MCX, and if set, it would have similar circumstances, /except/ the user would still be able to login to the machine via OD.

–DH

[Macleod]

If you look at dsconfigad, you will see that the arguments have changed.
10.6:
dsconfigad [-f] [-a computerid] -domain fqdn -u username [-p password]
[-lu username] [-lp password] [-ou dn] [-status]
10.7:
dsconfigad -add domain -username value [-computer value] [-force]
[-password value] [-ou dn] [-preferred server]
[-localuser value] [-localpassword value]
Update your scripts to use the new arguments, and you should be fine.
You should note though that dsconfigad now automatically adds “All Domains” to the search path on bind, and few options can be configured before the machine is bound, since there is no longer a persistent plist tracking the ad options. If you turn off “All Domains”, you will need to manually remove it from the Search Path.

–DH

[Macleod]

Your users have likely had their mobile accounts locked in the local domain, because of the new password policy.
When their accounts are locked out, the accounts disappear from System Preferences.
Checking for this is simple, you can either view the AuthenticationAuthority attribute in dscl (dscl . -read /Users/localcacheduser AuthenticationAuthority), or you can point Workgroup Manager at the local domain on the machine and see if the “access account” checkbox is unchecked.
WGM should be able to re-enable the account, or you can use the pwpolicy -enableuser command line tool to do so.
You could also delete the user’s cached credentials, and recreate the account manually, but that seems a waste given how easy it is to re-enable.

[Macleod]

You should be aware that the computer group object does not exist in the extended schema.
If you are managing mcx using computer groups, you will need to adjust your strategy to either use computer lists (yuck), or the other objects: computers, users, user groups.

[Macleod]

Trust your memory Joel. Its good here. 🙂
10.5 began the registration of machines into DNS. I thought it was actually the SMB side of the house that did it though, but I didn’t see anything in the conf file to support that.
My logs on 10.5 have entries from com.apple.DirectoryServices that say “successfully registered hostname with DNS”, or the negative if they can’t.
Don’t know what could be the issue that would have a 10.6 machine registering, and a 10.5 not, but at least you know they should be.

–DH

[Macleod]

You mention they are bound for network home reasons. Are you mapping anything else?
For instance, static UID/GID attributes, or shell attributes?
If any of those are mapped to invalid values, you experience logon failure.
It might be informative to use dscl to read the user accounts, and look at the values for those fields.

–DH

[Macleod]

Were you not able to do so in 10.5? I had AD Kerb ssh logins to my 10.5x server working…

[Macleod]

> I’m not sure what you mean by this or how to fix it.

Joelfink,
It means that the computer group object that Open Directory uses has no analog in Active Directory. Workgroup Manager cannot create a computer group in Active Directory, and as you’ve noticed, the 10.5 version of WGM has no ability to create computer lists.
This creates a catch 22 that requires the 10.4 version of WGM to rectify.

As MacTroll states “So… you need to use 10.4 WGM to create computer lists.
10.5 introduced computer groups and that’s all 10.5 WGM will create. This wouldn’t be a problem except that the AD plugin only understands lists and groups. So create a computer list in 10.4 and then manage it with 10.5 WGM”

Its an unsatisfactory solution, but its the only one we have for now.

If you want a slightly more technical answer as to what is happening here, look at the error you are getting back. eDSNoStdMappingAvailable The Open Directory plugins use mappings to relate open directory objects (Computer, Group, User, etc) to remote directory service objects. In this case, the AD plugin cannot map the Open Directory Computer Group object to anything in AD because there is no mapping available. AD does not have a computer group object, nor does the standard group object work for OD’s computer groups.
You can see this for yourself in the ActiveDirectory plist file. In /Library/Preferences/DirectoryService/ActiveDirectory.plist -> AD Attribute Mapping Table you will notice there is a mapping for dsRecTypeStandard:ComputerLists, but there is no dsRecTypeStandard:ComputerGroups.

MacTroll told me that you could probably build your own computer group object in AD with enough know-how, but schema extension is enough of a trial without reverse engineering objects from OD. Even if you built it, and got the mappings working, there is no promise that an OS update wouldn’t wipe out the custom mapping. (The AD plugin does not support custom mappings for non-user objects)

The schema extensions and ds mappings do still contain the Computer List object though, so that is what is available to manage groupings of computers. Yes, they use MAC addresses and can’t be nested. Yes, a computer can’t belong to more than one group. They are imperfect, and a step back from the Computer Group object.
Hopefully the DS team can work to get the grouping of Computer objects fixed in some future OS release. I’d personally like to see the plugin handle computers in standard groups, like AD supports for windows clients.

–DH

[Macleod]

Did you create the Mac OS X container at the root of the domain?
AFAIK, all computer lists are automatically added to the Mac OS X container at the root of whatever domain you are pointed at. If that container does not exist, or you don’t have the appropriate privs, you won’t be able to create the computer lists.
If you are in a multi-domain environment and authenticate to “All Domains”, WGM will attempt to create the computer list in the Mac OS X container located in your forest root domain.
At least thats been my experience. I can also add the WGM against AD has always been buggy for me. Random weird permissions errors don’t always accurately reflect the outcome of an operation.
In the case of computer lists, I sometimes need to type * into the search box to find the lists I created, after I was told they weren’t created.

–DH

[Macleod]

Be aware that the failure with the computer password rotation could be a symptom of bigger issues.
Most of the time when I see this it is because there are kerberos/dns issues that are causing the password change to fail.
Just an FYI.

–DH

[Macleod]

The best I can do is to suggest you turn on ds debugging, and poke through the log.
Ssh into your server with an admin account and do the following:
sudo killall -USR1 DirectoryService
tail -f /Library/Logs/DirectoryService/DirectoryService.debug.log
Then try to login graphically with the domain admin account and see what comes back.
You can turn off ds debugging the same way you turned it on.

Other things to look at are any static mapping you might have (uid/gid are the likely culprits in the GUI) that might not be set on a specific account.

Good luck.

–DH

[Macleod]

I actually just got there. After pouring through the schema changes, and looking at the mappings in the AD plist, computergroup does not exist.
There was a few minutes of incredulity, followed by the realization that this really is the case.
Any idea how the heck this got left out Joel?

[Macleod]

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.

[Author]

Posts