Cliffs Notes: Unless you work in IT, don't bother reading this thread. It'll probably just look really to you. This is a reply to a post I made from another board I visit, so that's why some things are quoted. So far, binding the computer itself to the domain is cake. It was the case in 10.3 as well, but it was a huge headache for me for a while. But I recently became the primary domain admin of a new area my division has annexed, so now I can test things without jumping through all the bureaucratic loops and hoops. I was having a problem with computers not being able to be added to the domain, despite the fact that users trying to add the Mac to the domain was getting the error of "Invalid User Name or Password." I tried adding the computer to the domain using my NT Local Admins account (a user group we created for the techs to be able to access medium security shares and have administrative user rights to all the Windows workstations, and even went as far as having one of the analysts add the computer using the domain administrator account, but again, no dice. Tiger seems to be a lot better about this now. Also, we have a fair amount of Citrix users on campus that are also Mac users as well, so this gives us some opportunities, as well as some potential headaches. Note before I start: user profile and home directory are one in the same in this context. Option 1: all-out profile redirection: Have the user's entire home directory be stored on and run directly off of the network. 10.4 now has native support for AFP (Apple File Protocol, which is part of the TCP/IP protocol suite) and SMB-based home directories, so you don't necessarily need an Apple-brand server to store Mac users' home directories; File Services for Macintosh on your data stores will do just fine. In fact, the Windows 2003 Server domain I'm testing 10.4 on has nothing but Windows 2003 servers, all running SP1. An awesome advantage we have using this method is the fact that absolutely no user data is stored on the user's physical computer unless the user explicitly stores data locally, and we can create true roaming profiles that carry over to either another Mac, or even a Windows computer (granted, things like Favorites in their Windows roaming profile won't automatically transfer over to the Mac), but you could import them into, say, Firefox on the Mac if you wanted to). This would make supporting the hardware much, MUCH easier, as a computer that breaks down and requiring off-site repairs can be sent off to either the manufacturer or an authorized support center without worrying about either loss of data, or potential invasion of privacy by prying eyes. At the same time, the user's home directory is backed up every time the server storing the home directory gets backed up. One last plus of this is that the techs responsible for the support of the computer at the hardware/OS level could become relieved of the responsibility of backing up the user's computer, assuming the suits allow for not backing up the computer when it comes in for service, and a policy is made to release liability by the techs for data integrity when a computer comes in and needs to be re-imaged, and responsibility for making sure the documents are put on a place where they can be backed up be put on the user, thus saving major amounts of money in the process by making supporting the Macs just that more efficient. One major downside of this is the fact that of course, if the NAS or whatever's storing the home directory just dies, the user's totally SOL, as their home directory and everything on it just went poof. Another downside of this is that storing all the users' home directories may eventually lead to backups of the server/NAS becoming simply massive, especially if said users happen to store their iTunes music folders in their home directories, or if they decide to save their unedited video captures to their home directories as well. If the latter were the case, one had better hope that your pipe to the desktop in question is at LEAST gigabit, or be prepared to hear about it when you check your voicemail (or the Helpdesk theirs) on Monday mroning. Another concern that was expressed is that the users would be directly working off of the server. I could see how this could be interpreted as a "bad practice," however. Laptops, however, would be excluded from all this, and the home directories would continue to be run completely locally. Option 2: store profile locally with remote home directory mapped at login: Upon authentication and login, the user's remote home directory (we use \\server\share\%username%) is available as a shortcut that you can click in the Dock and access your home directory from there (Tiger creates the new user's profile using the custom default user template that's in our standard build, and modifies it so that a shortcut to the user's remote home directory specified in AD appears on the right-hand side of the Dock, just to the right of the separator bar). Users can then manually copy their files to their remote home directory through the Finder whenever they like, but they will not be able to process it all at once...well, you could by going into the Finder and doing an Edit -> Select All on /users/username/*, but this is a bit sloppy. From the user's standpoint, at least this service is there for them without having to manually map their remote home directory via Go -> Connect to Server, but I can understand how they could become confused to figure out the difference between their local and remote home directories, so from a support standpoint, this could become rather cumbersome and frustrating for tier 1 support personnel (read: helpdesk and training personnel) to constantly point out to Joe User that their local home directory and remote home directory are two different things. If option 3 fails (see below), I could see this likely becoming the option we go with for the interim. Option 3: store profile locally with ability to synchronize with profile on the network at will: This is more or less a combination of options 1 and 2, and my understanding is that this is management's goal, as they want to have Macs run as closely to the way Windows is run as possible. Initially, we'll be putting Option 2 into play, but unlike Option 2, the user will have the ability to sync their local home directory on the fly to their remote home directory using one simple menulet at the top of their screen, versus syncing everything to the remote home directory upon logout like Windows does. I'm all for this method too, as laptop users would be able to also sync their home directories on the fly as well. This particular option is going to be a PITA to research, but this seems to be the option that has the best of both worlds. I'm able to work with GPOs via testing a new OU that I've created specifically for Macs right now, so far password expiration and disabling of an AD user account works great. You can now even change your domain password within OS X now! There's one caveat to changing domain passwords though that I've noticed: If you change your domain password from anything other than the Mac you use (say, either AD Users and Computers, or another Mac, or a Windows computer), you'll need to change your keychain password manually using the Keychain Access program. Keychain Access is a program on the Mac that stores frequently used user names and passwords to Web sites, applications (such as iChat/AIM/MSN Messenger, etc.), and so forth. If you or some poor user forgot their password and needs to reset it, they might as well delete their keychain and start all over again. A workaround I can see with this is that, for users using multiple computers, and their Mac is the primary computer, recommend that the user change their domain password from their Mac. I'm also testing a GPO that allows the user to be notified as to when their password/account is going to expire, but so far I'm not having much luck. Hopefully the Apple KB will have some more info on getting this to work. Another problem I saw with the AD integration in 10.3 (Panther) was that if a user was logged into the computer using their AD credentials, when they try to connect to a share that's hosted on a Windows 2003 Server, they receive an error that translates to "Access Denied." There's nothing wrong with the OS itself, but rather, the core problem exists in the domain controller security policy. To put it simply, the domain's security policy is too strict, and you'll need to tone things down a bit in order for the Macs to be able to access shares on Win2K3 servers. To do this, sign on to one of your domain controllers, and go to Start -> Programs -> Administrative Tools -> Domain Controller Security Policy. In the Domain Controller Security Policy editor, expand Local Policies -> Security Options. Now, set the following options to the ones specified below: Microsoft network client: Digitally sign communications (always): Disabled Microsoft network client: Digitally sign communications (if server agrees): Enabled Microsoft network server: Digitally sign communications (always): Disabled Microsoft network server: Digitally sign communications (if client agrees): Enabled Domain member: Digitally encrypt or sign secure channel data (always): Disabled Domain member: Digitally encrypt secure channel data (when possible): Enabled Domain member: Digitally sign secure channel data (when possible): Enabled Domain member: Require strong (Windows 2000 or later) session key: Disabled When finished, close the Domain Controller Security Policy window, and either wait for your domain controller security policy to automatically refresh itself, or you can force the issue by going to Start -> Run... and typing in gpupdate. You'll see a command prompt window that tells you that the policy is being updated, and the rest of your domain controllers will receive the updated policy information when they next refresh themselves (this is, of course, dependent on how often you specify your domain controllers be updated). NOTE: - By default, Workstations have SMB packet signing only enabled and active if server agrees. - Windows Server 2003 and Windows 2000 Server SP3 Domain Controllers have the policy "Microsoft network server: Digitally sign communications (always)" Enabled which causes the Server Message Block (SMB) server to perform SMB packet signing. The reason you have to tone down your encryption a bit is that 10.4 does not have a version of Samba that allows high-encryption connections (the latest version is somewhere in the 3.x range, whereas the installed version that comes with Tiger is only 1.2). But, it is recommended that if you're looking for high-encryption connections to Windows shares using Macs, install File Services for Macintosh instead, and let your Mac users connect over AFP instead of SMB. Since our IP addresses are all private to begin with, I don't really digitally signing SMB connections being a problem to begin with, but then again, I could be wrong... There's imaging programs that you can use in OS X called Carbon Copy Cloner and NetRestore. In a nutshell, think of it as a fully functional, freeware version of Ghost. Exactly. Right now, my campus' standard build image comes with a complete installation of OS X and all its built-in apps, Microsoft Office, FireFox, NAI Virex 7.6, the Cisco VPN Client (I'm using this instead of the built-in OS VPN client, since the Cisco client supports split-tunneling), some other multimedia-related apps like RealPlayer and what not, and all the OS and application patches pre-loaded. Basically, you download the image to the client computer, create the user's profile on the computer, transfer any documents/settings the user has from the backup you made of their computer before you imaged it, drop it off on their desk, and call it a day. CCC and NetRestore use bit-level transfers, so you can create a fully-bootable clone of their computer to an image file, and even download that same image to a completely different Mac, without needing to worry whether or not it'll run on different hardware. Actually, I'm able to use one image for all the computers that I support. There's also a drop-down box that allows you to pick from a list of multiple images, in case you need to create different images for different reasons. The only reason I would need to create different images is to accommodate different areas of the college that have different functions (e.g. staff/faculty/administration computers, student computer labs, etc.). Me too, I just hope they can update Samba down the road so we can re-activativate high-encryption connections again.