UUID for client machine not the same as UUID for account on Server...

Hello.

I've been having some odd issues with permissions and I'm wondering if it has something to do with UUIDs on our system. We're coming from an environment running 10.3 Server (running as Standalone OD) and just upgraded to 10.5 Server (running OD as Master) and the setup is something like this:

- Intel Xserve running OS X Server 10.5.6 running the following services:
- AFP/File Sharing
- DNS (internal DNS, Primary Zone)
- Open Directory (OD Master)
- VPN

There are other 2 other Xserves on the networking, both with OD connected to an OD Master (the Xserve listed above.

All employees have had Open Directory based accounts created on the Xserve. But, these accounts are not used for logging into desktop Macs (ie. network homes), these accounts are for logging into th server ONLY, via AFP, for file sharing.

All desktop computers are Macs and a mix of G4, G5 and Intel, running the latest version of either 10.4 or 10.5 (though all machines are being upgraded to 10.5 this summer). As for user accounts on these computers — each employee has their own computer and on each computer they have a local user account (ie. not a network based user accounts) for logging in — thus, they're tied to a single computer. There are also some computers that have generic user accounts (for example "Design" or Production" depending on the department) that anyone can log into.

So, here's where I think I'm having a problem. Since machine-based user accounts are "local" to the machine, the UUID of the local account wouldn't be the same as the UUID of the account they login to the server with. And even if they were the same (per user), on the machines with generic logins, these generic logins don't have equivalent OD/Server accounts — for example, a user logs into the computer via a generic "Design" account, but once logged into the computer they mount a Share Point using their server-based OD account credentials (via AFP). So, there's no way the local machine account UUID could ever be the same as the UUID of the server-based account they're logging in as.

So, since 10.5 Server pretty much relies on UUID (or, so it seems), is there any way I can deal with this sort of environment and have permissions work properly (ie. local machine accounts utilizing server-based OD accounts to mount Share Points which utilize ALCs based on these server-based OD accounts)?

If anyone is still reading this, and I haven't thoroughly confused you, your advice would be appreciated!

Regards,
Kristin.

20" Intel iMac 2.16 Ghz, 12" PowerBook G4 1.33 Ghz, Power Mac G4 667 Mhz, Mac OS X (10.5.6), Xserve (Intel), Xserve (G5), Mac Pro

Posted on Apr 22, 2009 2:19 PM

Reply
7 replies

Apr 23, 2009 6:39 AM in response to kristin.

Leopard doesn't 'rely' on UUIDs as such. They're are used for two things. One: ACLs and two: 'External Accounts'. If you are using neither then you are not suffering from differing UUIDs. The Server will always work with the accounts on itself. So when someone connects to a service from that Server they are authenticating with the network account. If the username and passwords happen to match that is purely coincidence. The Server cannot read your clients' local db.

Ideally you could work from the Server's Mobile accounts with Portable Home Directories. This would however be an issue when you have huge home directories and limited network bandwidth. If you need people to be able to move around from Mac to Mac then this option will be slow at login if they've got lots of data and they move to a Mac they haven't used yet. The next Leopard alternative is External Accounts. This is where they would store their accounts on a portable removable drive. Each Leopard client they plug it in to would recognise the presence of the account and allow them to log in. This is also a setting within the Mobile preferences management. In this case there would be no need to sync data back to the Server unless you want that as a redundant copy/backup.

I hope I helped there. 🙂

Apr 23, 2009 8:20 AM in response to Andrew-ACT-ACSA

Well, I am using ACLs...a lot.

ACLs were the reason we were sold on moving from 10.3 Server to 10.5 Server. I know there are a lot of reasons to move from 10.3 to 10.5, but we had a solid system running since 10.3 was released and the only thing we required beyond what 10.3 was offering was more fine-tuned control over permissions. So, ACLs are definitely being used now. We don't have the bandwidth to be able to handle PHDs, and external accounts aren't really an option as all employees already have a dedicated Mac, so moving the account to an external drive just so they can log back into their Mac doesn't really make a lot of sense.

Is there no way local machine-based accounts can be tied into OS X Server 10.5 and have ACL permissions handled correctly?

I can't even get a simple all-access shared folder to work.

On the server, POSIX permissions are:
Owner = Root= R&W
Group = Admin = R&W
Others = R&W

ACLs are:
Everyone = R&W (This folder, Child Files, Child Folder, All descendents)
Contact_Staff = Deny

But, when someone uploads a job folder to this group, permissions on the sub-folders and files become totally out of wack (viewing via Server Admin). Some files are fine, others are totally wrong:

POSIX:
Owner = User who copied file to server = R&W
Admin = Read Only
Others = Read Only

ACLs look OK.

And then when someone else mounts the Share Point and copies FROM the server to their local desktop, for some files, they don't have permission to copy to the local desktop (I've determined the culprit being QuarkXPress 7.5 files being the files that can't be copied) and all other files within the job folder become READ ONLY across the board. At the very least, the user who copied the file from the server to their desktop (who now becomes the owner) should retain R&W, but they're not, it's READ ONLY across the board (and that's only on the files that actually get copied — Quark files don't get copied).

This is quite frustrating on what is only a glorified, all-access shared folder.

<sigh>
k.

Apr 23, 2009 8:45 AM in response to kristin.

Just another bit of information, when the Quark files are copied to the server, the POSIX on them become:

Owner = person who copied to server = R&W
Group = Admin = Read Only
Others = none

It's the Others = none that is causing the problem in regards to the files not being able to copy from the server to the desktop, even though they have full R&W permissions on the file via ACLs. Though, if there's an issue with ACLs not working properly because the user is using a local machine account, but is accessing the server via AFP via an OD account, then that would explain things? Though, it doesn't explain why only Quark files become OTHERS = NONE, and it doesn't explain why all other files become READ ONLY across the board?

Help!!!
k.

Apr 23, 2009 12:51 PM in response to kristin.

Doh! Misread your original post. I thought you'd said they move around.

Ok, I've heard a lot of complaints about ACLs not always being reliable. First of all, are you up-to-date? If you're already on 10.5.6, then first suggestion is to wait for the next update and try again. It could be released very soon.

Next... clearly the inheritance setting on your ACL is not working OR Quark and some other things are getting to set their permissions differently. Can you change your Everyone ACL to not allow administration of the owner and permissions? This might help prevent software products like Quark from overriding the inheritance. As I'm sure you are aware Quark can be a law unto itself.

Apr 23, 2009 1:05 PM in response to Andrew-ACT-ACSA

Ok, I ended up wiping the server and reinstalling everything, reconfiguring, etc. and that seems to have done the trick. Not an ideal situation, but at least things are working "OK". I say they're working "OK" because I'm still having an issue with permissions where I'm trying to create a Share Point (of digital resources) that is READ ONLY (re: the files/folders on the server) but then inherit local user permissions once copied to the local machine. But, there are other threads going on trying to sort this out. In the meantime, it looks like my bigger issue has been resolved by a reinstallation/reconfiguration of OS X Server.
Regards,
Kristin.

Apr 23, 2009 1:18 PM in response to kristin.

I think you should get a hold of "Mac OS X Server Essentials v10.5" and "Advanced System Administration v10.5" books. It may help you to understand how the permissions come together.

Better still attend the Server Essentials (Leopard 201) training course and then you can ask questions about your specific issues after getting beyond the Authorisation chapter.

http://training.apple.com/itpro/leopard201
http://training.apple.com/schedule/leopard201

Apr 23, 2009 1:32 PM in response to Andrew-ACT-ACSA

Yea, I found Server Essentials to be a good resource, and for the majority of the things I was looking to do it's been a great resource for setting up the various things I've been looking to do. The section on ACLs/Permissions was pretty good, though it didn't really go into many complex scenarios (though, the fundamentals it provided paved the way for most things I required). I hit the roadblock I've been battling the last while though, but it seems like a reinstall has done the trick (unfortunately, I see "I reinstalled and now it works" as a solution to too many of the issues on these discussion boards). Whatever the random issue was that was resulting in my permissions weirdness, it led me on a complete tangent, grasping for an explanation, which lead to this original post. But, like I said, the reinstall did the trick.

Server Essentials is also a good read (depending on what you consider a good read), but much of the information relies on CL instructions, and I'm trying to keep things GUI-based as much as possible (I don't need to get into this here, but short story — I'm going to be away from managing these servers for over 4 months and I'm trying to get them to a point where the person who will be dealing with them when I'm gone needs to do as little as possible, but when they do have to do something, CL won't be an option — not an ideal situation, but it is what it is).

As for attending the training course, that would be ideal, but it's not happening (again, circumstances that I don't need to go on in here). And, I'd rather push for training on 10.6 Server once it arrives as there's a much greater longevity with that version IMO.

Anyway, thanks again!
Kristin.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

UUID for client machine not the same as UUID for account on Server...

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.