Odd Logins from InstaDMG / Leopard Image

[vogtstev]

WHOA!! I am getting the craziest stuff I have ever seen as far as logins into my machines…… I thought everything was working grand until now and it’s time for school to start!!! Help!!!! If you have any ideas on how to troubleshoot this please let me know!!! Thank you! Thank you!

The Setup:
I’ve created an image with InstaDMG. I’ve packaged all my software and all of that seems to work great. I have used createUser to create two accounts – one admin and one guest. When the computer starts up for the first time of course it creates the users on login and pulls the User Template for them. Still so far so good. I am bound to an Open Directory server for my network logins. The first time I login I run a little setup script that basically just adds printers, adds a user if needed, etc.

Here’s where the trouble starts:
At random when the computer logs in with a local user it will login as the wrong user!!!! i.e. I type “admin” and the password, and it logs in and says something like this… “The home folder admin cannot be found in the usual location,” etc. The really crazy part is when I go to logout it shows I’m logged in as “Email Postmaster” or “Hyper Text Transfer Protocol”!!! Even more bizarre – this happens via ssh as well!!!!

So I’m thinking something is goofed up in dscl, but I’m not sure how to fix it or if there is a repair option, etc. I would love to hear any ideas as I am desperately searching for an answer!!!

Thank you!!
Steve

[larkost]

I agree that it sounds like there is something messed up in dslocal, specifically I think you have somehow corrupted the dslocal store with something that you have put in there. The way that I would troubleshoot this is to go to the command line:

sudo -s
– this gets us to a point where we are “root” (so to speak)

cd /var/db/dslocal/nodes/Default/users/
– warning… we are playing with fire now

ls
– get a list of all the users, we are looking for things without under-scores

– you can view the contents of the files with:
cat

Get a feel for what should be in there. My feeling is that either one of the files is just-plain-wrong (and is messing up everything else), or there are two files in users that has a duplicate uid entries.

Edit: It just occurred to me that if your LDAP users are coming in with uid’s in the wrong range, then they could be overlapping with the local users. You can use dscl to explore the settings on the local and LDAP users, and compare the results.

[vogtstev]

OK, so I did a lot of “catting” around as well as using dscl read. Everything on the local system appeared normal as I could tell. I did notice something though. There happens to be users on the server with names postmaster and httpd that happen to have corresponding UID’s to my local users (501 and 502). So I think it may be looking at the LDAP directory before the local directory. However, Directory Utility shows local as being the first thing to search. Hmmm.

The LDAP server was the same server we were using with our Tiger clients. Nothing has changed to my knowledge. Even the schema is the same although we are about to update it. We are using an OpenLDAP server.

Not sure if I’m going about it the right way, but in my InstaDMG build I have a package that installs the “Directory Service” directory into /Library to give my clients all the LDAP settings.

Hope this gives more clues. Keep the ideas coming! Thank you! Thank you for you fast response!!

[vogtstev]

One other thing I noticed: It’s not like the user is completely coming off the LDAP server. It’s as if it’s logging in with the proper local name and password, but looking on the server for the home directory of user 501 and 502. hmmm.

[larkost]

You have found your problem. I don’t know how your LDAP users got uid’s in the 500 range, but that is what is causing the problem. Essentially DirectoryServices is synthesizing records for you by combining the two entries together. This is called “Augmented Records”, and is new in later versions of 10.5 (note: the name “Cylinder of Destiny” has been rejected…).

If you want to see what DirectoryServices is creating you can use dscl and go into the “Search” area. This will show you what the record looks like to DirectoryServices after all the combinations happen.

The solution is going to be to move one of the users so that the LDAP and local users don’t conflict.

[knowmad]

Check your user numbers…. did you pick UIDs? or did you let create user grab them?
The last time I saw something like this it turned out my user setup was majorly off. At the time I was trying to figure out how to hide a user in leopard (leopard was new and the ins-outs were not clear yet). I gave my admin account a sub 500 number and to my great chagrin I logged in as html parser (or something). Then I listed all the users on the machine and discovered I had chosen (by random) an already assigned useID. It totally screwed with my system and I had a heck of time getting anything to work properly as that user.
If you check the thread over here: [url]http://forums.macosxhints.com/showthread.php?t=80670[/url] you will find the entire list of user IDs and group IDs that are built in.
You could (I guess) do it for yourself with [code]dscl . -list /Groups PrimaryGroupID[/code] and [code]dscl . -list /Users UniqueID[/code] and then make absolute certain your setup (both ldap and local) are not walking all over that list. Lastly, and very importantly, if the user hasno rights to his own home drive he will get an error similar to the one you saw regarding the location of home folder…… or you could be pointing it to a nonexistent directory…. check for typos.
Anyway, that is how I would start troubleshooting this.

[vogtstev]

Ah that totally makes sense!!! I’m guessing if I change my local UID’s if any others are created they will run into the same issue because Leopard will start with the next available UID. I asked about changing on the server and the system admin is looking into it, although I guess the accounts are tied to a lot of things.

Looking at things from a different angle, in our situation we shouldn’t need the augmentation. Is there actually a way to disable it easily on each client?

Thanks for the great advice!!!

[vogtstev]

I did check my local user and group ID’s. I don’t see any conflicting. createUser has picked them with the exception of one hidden acount I have for extra administration. This user had an ID of 499, but so far everything seems to be working fine with that one.

I am pretty convinced that it is something to do with the record augmentation happening, but I’m not sure how to stop if from doing that.

[vogtstev]

So I went to Search/Users and looked at each record. They of course had all different info, with the exception of the UniqueID. I also looked at /Search/config and only noticed my MCX and a macosodconfig containers and nothing to do with augmenting. Not sure if I was looking in the right spot for the augmented record or not. I have never specifically setup augmented records either. Am I looking in the right spots?

Thank you!!!!!!
Steve

[knowmad]

I have not yet worked with leopard server or augmented records, but you might be able to find some answers by reading this:
https://www.afp548.com/article.php?story=20080528204603120
and following up with any leads found in the comments thread.

[vogtstev]

Hmmm. So I’m thinking it’s not really augmenting since i haven’t ever set that up, but definitely using some form of the magic triangle. I’ve been trying to think of ways to get this fixed and so far this is what I have:

1. Prevent the “augmentation” – no idea how I can do this aside from removing machine from directory services which means I would loose all management. I would like this to work.
2. Asked OpenLDAP admins to change the UID’s of the few in the 500 UID range. They said they were worried about this causing problems. What would this cause?
3. Have to change UID’s on all my clients. This is the most work, but maybe what I’ll have to do. The only problem is that I believe leopard will create UID’s again starting in the 500 range. Is there a way to tell it to start at 550 or 601 or something?

Thanks again for any ideas!

[knowmad]

well… what are you using to create your user accounts? If your using createuser, you can specify user account numbers….
If your using the server, I think you can do the same though it is a bit different.

[vogtstev]

My initial accounts get created with InstaDMG, but faculty are free to rule their own computer to a point and add their own accounts. They usually do this through system prefs on the local workstation. So I would need to update something on my workstations. Hmmm.

[larkost]

The real problem is that the server admins should never have put any accounts in the 500 uid space. They probably had to play with things in order to get them there, and that should have been their first indication that this was a bad idea.

Anything you do to work around that initial mistake is going to involve a lot of work and a lot of potential gotchas that have to be avoided on a lot of computers. Get the server admins to change their userids. They are going to have to chase those ids though the system a bit, but that is a lot less hassle then modifying everything everywhere else.

[hetjan]

[QUOTE][u]Quote by: vogtstev[/u][p]Hmmm. So I’m thinking it’s not really augmenting since i haven’t ever set that up, but definitely using some form of the magic triangle. I’ve been trying to think of ways to get this fixed and so far this is what I have:

1. Prevent the “augmentation” – no idea how I can do this aside from removing machine from directory services which means I would loose all management. I would like this to work.
2. Asked OpenLDAP admins to change the UID’s of the few in the 500 UID range. They said they were worried about this causing problems. What would this cause?
3. Have to change UID’s on all my clients. This is the most work, but maybe what I’ll have to do. The only problem is that I believe leopard will create UID’s again starting in the 500 range. Is there a way to tell it to start at 550 or 601 or something?

Thanks again for any ideas!
[/p][/QUOTE]

2. Changing the UIDs is trivial. You will get privilege errors if the user is logged in somewhere until you chown the files. Until then ls -al will show the old UID or even the matching local username (with that UID) as the owner (depending on where you look at the files from).

3. Don’t do this. Best practices are there for a reason. Like larkost said the problem is being caused by the admins creating LDAP users in the wrong UID space.

[Author]

Posts