Three Platforms, One Server Part 8: A Minor Snafu
So far we've hit only one very minor snag in our migration to a single, unified authentication server for Mac, Windows and Linux. Since Mac and Linux behave so similarly with regards to authentication — in fact, I'd say they're practically identical — and since Windows is so utterly, infuriatingly different, you can expect most of our problems to happen on the Windows side. At this point it should go without saying. This latest snag is no exception.
Today we discovered that applications to be used by network users on Windows machines must be installed by a network user, and this network user must be a domain admin. Put another way, if a Windows application is installed by a local administrator, it will not be fully accessible by users who authenticate via the domain hosted by the Authentication Server. Typical.
The solution is fairly easy, albeit kind of a pain. On each client workstation, you must give the network admin user (i.e., a user whose account exists only on the authentication server) full access to the "C" drive. You heard me: On each computer. Giving full access to a user on Windows requires logging in as a local admin and granting the network user full access rights. Windows then changes the access permissions on every file on the machine, which takes a long-ass time. You heard me: long-ass.
If we had to do this on every machine by hand, I'd be grumpy about it (but I'd do it anyway). Fortunately, we'll be building our Windows boxes from clones, which means we only have to do this once on a master build. the change should propagate via the clones after that. So I'm a pretty happy camper. And we're back on track.
Still, Windows, what the fuck?
And just to be clear on this, I honestly don't know enough about Windows or Active Directory to understand why this is happening. All I know is what we've observed, which is that Windows apps fail to run properly for network users when installed by local users. We tried matching the users and groups we'd had on the old Windows Server, but that did no good. Setting full access locally for a networked user was the only thing we could find that worked. It's very possible, however, that there's a better solution than the one we're using. If anyone can enlighten me, I'm all ears.
Oh, and yes, our network user has full access privileges for the directory domain. Confused? Me too.
More to come...
UPDATE: I found a better solution. A network user can be added to the "Administrators" group via the Users and Groups control panel. Doing so is not particularly intuitive, but it works and saves us the trouble of having to modify permissions on the entire "C" drive.
It essentially requires logging in as a local Administrator, navigating to the "Advanced" window in Users and Groups, and then adding the user to the "Administrator" group.
Group Properties: Do We Really Need This Window?
(click image for larger view)
Windows doesn't see a network user unless she's logged in, so you have to know how to enter a network user. It should look something like this: DOMAIN\user, where "DOMAIN" is your Active Directory Domain, and "user" is the user name.
Add the User Here: Who'd a Thunk It?
(click image for larger view)
You can find more complete instructions here, which is where I got these images.
Fun stuff.
Today we discovered that applications to be used by network users on Windows machines must be installed by a network user, and this network user must be a domain admin. Put another way, if a Windows application is installed by a local administrator, it will not be fully accessible by users who authenticate via the domain hosted by the Authentication Server. Typical.
The solution is fairly easy, albeit kind of a pain. On each client workstation, you must give the network admin user (i.e., a user whose account exists only on the authentication server) full access to the "C" drive. You heard me: On each computer. Giving full access to a user on Windows requires logging in as a local admin and granting the network user full access rights. Windows then changes the access permissions on every file on the machine, which takes a long-ass time. You heard me: long-ass.
If we had to do this on every machine by hand, I'd be grumpy about it (but I'd do it anyway). Fortunately, we'll be building our Windows boxes from clones, which means we only have to do this once on a master build. the change should propagate via the clones after that. So I'm a pretty happy camper. And we're back on track.
Still, Windows, what the fuck?
And just to be clear on this, I honestly don't know enough about Windows or Active Directory to understand why this is happening. All I know is what we've observed, which is that Windows apps fail to run properly for network users when installed by local users. We tried matching the users and groups we'd had on the old Windows Server, but that did no good. Setting full access locally for a networked user was the only thing we could find that worked. It's very possible, however, that there's a better solution than the one we're using. If anyone can enlighten me, I'm all ears.
Oh, and yes, our network user has full access privileges for the directory domain. Confused? Me too.
More to come...
UPDATE: I found a better solution. A network user can be added to the "Administrators" group via the Users and Groups control panel. Doing so is not particularly intuitive, but it works and saves us the trouble of having to modify permissions on the entire "C" drive.
Windows "Advanced" Users and Groups: By "Advanced" I Think They Mean "Annoying"
(click image for larger view)
(click image for larger view)
It essentially requires logging in as a local Administrator, navigating to the "Advanced" window in Users and Groups, and then adding the user to the "Administrator" group.
Group Properties: Do We Really Need This Window?
(click image for larger view)
Windows doesn't see a network user unless she's logged in, so you have to know how to enter a network user. It should look something like this: DOMAIN\user, where "DOMAIN" is your Active Directory Domain, and "user" is the user name.
Add the User Here: Who'd a Thunk It?
(click image for larger view)
You can find more complete instructions here, which is where I got these images.
Fun stuff.
Labels: Lab, MacOSX, NIX, Server, Systems, ThreePlatformsOneServer, Windows
This entry was posted
on Thursday, May 25, 2006 at 3:02 AM.
You can skip to the end and leave a response.
» Post a Comment