As part of getting of getting my shop ready to support 10.7, I’ve made some updates to the interactive MigrateLocalUsertoADDomainAcct that I have posted to my GitHub repositiory. The script (adapted from the original by Patrick Gallagher) helps you migrate a local user account to an equivalent AD domain account.
If you need this for your own shop, feel free to download a copy.
Direct link to script and README: https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/migrate_local_user_to_AD_domain
In Mac OS X 10.6.x, it’s possible to set the login window to not allow network users to log into the computer, even when the Mac itself is correctly bound to the your Active Directory or Open Directory domain.
If you run across a machine that is correctly bound to your domain, but not allowing logins from network accounts, see below the jump for how to check if the login window has been set to not allow logins by network users.
If your Mac environment is using a directory service for authentication (like Apple’s Open Directory or Microsoft’s Active Directory), you can add a group from your directory service to be a member of your Mac’s local admin group (members of which have administrative rights on your Macs.) This helps simplify granting administrative rights on your Macs, as you can add and remove accounts to your server-end group to grant and remove administrative rights for those accounts on your Macs.
To add a group from your directory service to your Mac, you can use the following command:
sudo dseditgroup -o edit -a “group name” -t group admin
If you’re adding an AD group, you may need to add the AD domain’s name:
sudo dseditgroup -o edit -a “DOMAIN\group name” -t group admin
For Active Directory, you can also use the dsconfigad tool to enable or disable administrative rights for a particular AD group:
sudo dsconfigad -groups “group name”
One thing to watch for with adding AD groups is that the group whose members you want to give administrator rights to needs to be listed as the Primary Group in AD for those accounts. Otherwise, they may not be given administrative rights on the Macs despite the AD group being added to the local admin group.
One of the occasional issues I’ve run into at work is that we don’t have one central location that stores all of our AD home directories. As a result, telling someone where it is can take some digging and delay. To help speed up the process, I worked with Peter Bukowinski to build an easy-to-use AppleScript that looks this information up. It should be pretty generic, but the only location I’ve tested it at is here at my workplace. Your milage may vary.
Assumptions: In order to work correctly, the script needs for the Mac to be bound to an AD domain. The AD-bound Mac also needs to be connected to the AD domain via a domain-reachable network connection or via VPN.
Using the script:
Launch the script and provide the username in the blank provided, then click OK.
The home folder will then be displayed in a dialog box. You’ll also be prompted to copy the home folder information to the Mac’s clipboard for pasting (if needed.) Click OK to dismiss the dialog without copying the information. Clicking either button will quit the script.
Update: Peter added some more functionality to the script by making the copying of the information to the clipboard optional and adding error checking for when an AD account was set up without having a home directory set in the account profile. Downloads and source code have been updated to reflect the changes.
Click here to download the script. Source code is beneath the jump.
If you’re running Mac OS X Server 10.5.x or higher, you may be backing it up with Time Machine. However, Time Machine has gotten a bad reputation with some admins because of what Time Machine *doesn’t* back up. That being said, since Time Machine saved my bacon this past weekend, I wanted to post a Time Machine restoration how-to that (depending on your configuration) can be a lifesaver for your Mac or XServe running Mac OS X Server.
To recover the system:
1. Connect the Time Machine backup disk to the server (should already be connected, but double-check.)
If you’re restoring your system because of a problem with the startup disk, make sure the disk has been repaired or replaced.
2. Insert your Mac OS X Server Install disk, and boot from the installer disk.
3. In the Installer, choose Utilities > Restore System from Backup.
4. In the Restore Your System dialog, click Continue.
5. Select your Time Machine backup volume.
6. Select the Time Machine backup you want to restore.
7. Follow the onscreen instructions.
YouTube video showing the recovery process: http://www.youtube.com/watch?v=ZmvwcRJ6sww
Following a Time Machine restore:
Recreate folders that are not included in the Time Machine backup as described below.
Open Terminal (in /Applications/Utilities).
Execute these commands, each on its own line, followed by Return. Note: When using these commands you will be prompted for an administrator’s password.
sudo mkdir /var/log
sudo mkdir /var/log/apache2
sudo mkdir /var/log/samba
sudo mkdir /var/log/swupd
sudo touch /var/log/daily.out
sudo touch /var/log/weekly.out
sudo touch /var/log/monthly.out
To restore the Wiki service (server), run the following commands in addition to those above:
sudo mkdir /Library/Logs/wikid
sudo chown _teamsserver:_teamsserver /Library/Logs/wikid
To restore the Mail service, execute the following command:
sudo /etc/postfix/post-install create-missing
After running these commands, restart the server.
Exceptions to the rule:
Databases – Time Machine is a file-based backup, and doesn’t handle backing up active databases that well. However, it does a good job of backing up database backup files. If you’re running a database on your server (and you are if the server is an Open Directory Master, as OD works from an LDAP database), make sure to set up an automated process that automatically backs up your database to the appropriate backup file (varies by database) on a regular basis.
Mail – On 10.5 Server (I don’t know about 10.6.x Server), Time Machine does not back up the /private/var/spool directory. As a result, nothing in /private/var/spool or the directories inside spool are backed up. This is important for those running a mail server because /private/var/spool/imap which is where IMAP users’ E-mail is stored.
If you’re using Time Machine to back up a 10.5.x server where you’re also running mail services, I recommend that you go to /System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions.plist and comment out the /private/var/spool exclusion using the following:
<!– /private/var/spool –>
I had a problem today with unbinding and rebinding my MacBook Pro from work’s AD domain (this process was started by my AD account lookups failing, which made me think that my Mac wasn’t talking to AD as well as it thought it was.) When I tried to unbind, I got an error stating “Invalid user name and password combination”. Thinking that my DirectoryService preferences were hosed, I tossed my /Library/Preferences/DirectoryService folder which should have cleared out my AD settings, then restarted. After the restart, I was able to connect back to my OD server without a problem, but then ran into the same “Invalid user name and password combination” error when I tried to bind to AD again.
After googling to see if anyone else had the same problem, I ran across this Apple Support discussion thread, where PetarM suggested the following:
I was having trouble logging in with my AD account to some iMacs added to our AD. In fact, not a single AD account was able to login. Directory Utility claimed it can’t see the domain controller (which it could, since it was online, in the same subnet as other identical computers, it could ping the domain and packets were sent back and forth between it and the domain, without loss). Unbinding it didn’t work, but it offered to force the ubind, which I did. Then I was unable to bind it back (updated to 10.5.6 rebooted, still not binding). The error I kept getting was invalid username and password (after entering the domain username and password that we use for binding). Using the same username and password worked on other computers (either brand new, or existing computers that I unbound, then bound back with no issues — again same subnet, same image). I deleted the computer accounts from the domain, but the problem persisted. Finally, I used fseventer to see what’s being access during the bind process. The system threw the error message not after communicating with the domain, but after checking the plists in /Library/Preferences/DirectoryService and /var/db/dslocal/nodes/Default/config — so I deleted these two folders and was able to bind back with no issues! WARNING: This deletes a lot of directory service settings, so use it at your own risk! Here are the commands I used:
sudo rm -rdfv /Library/Preferences/DirectoryService
sudo rm -rdfv /var/db/dslocal/nodes/Default/config
sudo sudo killall -USR1 DirectoryService
I tried those commands on my own laptop, and behold! It wiped my DirectoryService settings (as noted above), but I could now rebind to AD!
So, for those who need it, here’s another thing to try on 10.5.x when you can’t bind to AD:
1. Log in with your admin account and open Terminal.
2. Run the following commands
sudo rm -rdfv /Library/Preferences/DirectoryService
sudo rm -rdfv /var/db/dslocal/nodes/Default/config
sudo killall -USR1 DirectoryService
3. Try to rebind again.
I ran into an odd and hopefully rare issue with Active Directory-bound Xserves (I’ve seen it on both G5 XServes and Intel XServes) and Apple’s Common Criteria software. Essentially, when you turned the audit software on, Active Directory would crash. Turn it off, and Active Directory wouldn’t crash. Leave it off then, right? Sadly, if you’re in a situation where you’ve got the audit software installed, you most likely have a good reason for needing it on (in my case, it’s to satisfy security regs.) Even weirder, I had three servers (all G5 XServes) that were bound to Active Directory and were running the CC software, but didn’t have Active Directory crash.
What was the problem? Apple enterprise support chewed on it for a while and discovered that the crash was happening when the Active Directory plug-in was administering the admin group in the local NetInfo database. In other words, in the Active Directory plug-in’s Administrative tab, the Allow administration by: option was checked off. My three servers that weren’t having the crashes didn’t have that option checked, which supported the theory.
Update – 2-6-2008:
We tested this out later in October, and unchecking the Allow administration by: checkbox fixed the issue on all of the affected servers. Hopefully this won’t be an issue on Mac OS X Server 10.5.x. but I haven’t tested it yet.