Directory Binding not working in SL

[#1]

Hello- Our active directory bind has stopped working with Casper Remote. If I send
a CR command to bind to our AD, it says it runs successfully, and when I
look under System PreferenceAccountsLogin Items it says that the computer
is joined to our domain, but domain accounts can not log in until I manually
unbind and then rebind.
Any thoughts?
Thanks-
Colleen

[#2]

We're seeing the same sort of behavior. We are able to unbind/rebind from
Casper Remote, but the majority of machines are not bound in the load
process.

Bob

[ImAMacGuy]

I noticed this too on our newest builds for the Mac Mini...

However, those with global admin rights on the domain ARE able to logon,
but not regular domain users...

John Wojda

Lead System Engineer, CTS

3333 Beverly Rd. B2-338B

Hoffman Estates, IL 60179

Phone: (847)286-7855

SMS / Text Page: 2245873298
<mailto:12245873298 at messaging.sprintpcs.com>

Team Lead: Chris Sta Ana
<mailto:cstaana at searshc.com;jwojda at searshc.com?subject=John%20Wojda%20Fe
edback&body=I%20am%20contacting%20you%20regarding%20John%20Wojda.>

[ImAMacGuy]

I posted a similar question on another site... their response was...I
haven't tried it though, as I only noticed it on the new mini's - and I
don't have one available for testing at the moment.

If you ssh in to the machine in question, you can tail the logs in
realtime - that's at least one way to figure out where the error lies.
Especially when it's successful with some logins(possibly it has to do
with the OU? Is DNS looking at the right place/is this workstation on
the right network?) and not others you have an A/B comparison to look at
the difference between. Perhaps logging on the server could tell you as
well.

.....

/var/log/system.log is where I'd start looking on your system, and when
you're doing the SSH trick mentioned above you can monitor it via

tail -f /path/to/somename.log

John Wojda

Lead System Engineer, CTS

3333 Beverly Rd. B2-338B

Hoffman Estates, IL 60179

Phone: (847)286-7855

SMS / Text Page: 2245873298
<mailto:12245873298 at messaging.sprintpcs.com>

Team Lead: Chris Sta Ana
<mailto:cstaana at searshc.com;jwojda at searshc.com?subject=John%20Wojda%20Fe
edback&body=I%20am%20contacting%20you%20regarding%20John%20Wojda.>

[#5]

Hi guys,

I recently (and still currently) had similar problems with binding. My story goes like this....

I installed Casper Suite this last June. I did not have a lot of time to fully setup the managed preferences solely on my Casper server (too many lines of code to transfer in too little time). I asked Jamf if I could still use Apple's Workgroup Manager to manage my preferences. They said yes, no prob. Well, I built up my image (and used the Apple binding on it). Blasted my image out to my lab terminals and did some testing. At first, everything seemed to be working fine. I spot checked the lab computers to test the preferences and bindings and all seem to be working. Then, when I started testing my new user setups (and my returning users), I started to experience anomalies. Preferences were not being applied (such as dock, login, printer, etc. prefs). I thought my clone was corrupt and rebuilt it several times with the same effect.

I called Jamf and after going over all details, we decided that somehow the Apple bindings were not being applied correctly. So, we wrote a policy to rebind all the lab computers using the JSS Management "Directory Bindings" setup. We first setup the rules for binding in Directory Bindings and then created a policy to apply the rule ONCE, triggered by "startup". I restarted all the lab computers (and added this policy to my future images). This seemed to fix the problem. My preferences started working again and all the users were getting the correct user experience when they logged in. About a week later, things started to go "south" again. I restarted all the lab computers, but nothing changed. So, I reset the JSS policy to trigger the binding rule "Once ever day". I did this yesterday and, again, restarted all the computers. So far so good.

Now the real question is this. I did not have this binding problem last year (pre-Casper) when I was operating on OS 10.5.8. After I upgraded to Snow Leopard, I did notice that the whole binding process changed a bit. Apple got removed "Directory Utility" from the Utilities folder and buried it in the /library folder (also making it available in "Accounts area" of System Preferences. This made me question if other changes had been made to the binding scenario. The big question is: is there a bug in the binding process? Or, is there some incompatibility with Casper and Apple where binding is concerned? We are also using Apple's Portable Homes scenario. This also seems to be a factor, as we have "many users on many computers". This mobility and the "synchronization" that follows the user from computer to computer also raises the question of whether some corruption may be occurring in the ~/library/FileSync folder. I am also wondering, since we never turn our computers off (they go to sleep after an hour of non use), could the "sleep" process be causing the computers to stop handshaking and lose their binding?

So far, I am tracking everything. But, that's about it for now.....

Submitted for pondering........

Best,

Roy

[tlarkin]

I think it is because these laptops have no autorun data, so they don't
know which file server to mount? I think I need to look at prestaging
them, however, I have 500 of them in 6 different locations.....this is
not going to be fun. They are already deployed to their designated
building too.

Guess I can scan all the serial number boxes?

[tlarkin]

dang, sorry I replied to the wrong email, disregard that. Been a crazy
day today.

[ImAMacGuy]

Wasn't sure if anything has been done with this.

Last week, I took a system that had the problem and I 'tailed' the logs.
I took one log of my credentials logging in and another of a user's
credentials logging in and saved them in separate files. My log was
over 200 pages, whereas the user's log was only 85ish... Unfortunately I
have not delved into AD logs before so I don't know what belongs and
what does not.

Since we're binding with Casper, I can't say that Apple is going to be
much help, so I figured I would check back in here to see if anybody
else had gotten more info before I check in with Jamf.

John Wojda

Lead System Engineer, CTS

3333 Beverly Rd. B2-338B

Hoffman Estates, IL 60179

Phone: (847)286-7855

SMS / Text Page: 2245873298
<mailto:12245873298 at messaging.sprintpcs.com>

Team Lead: Chris Sta Ana
<mailto:cstaana at searshc.com;jwojda at searshc.com?subject=John%20Wojda%20Fe
edback&body=I%20am%20contacting%20you%20regarding%20John%20Wojda.>

[#9]

John,

Here is a reprint of the post I sent out a couple of weeks ago. Since this post, I have worked with Jamf and we came up with this fix:

I "unbound" my master image before installing it into Casper Admin's list. I then added the binding policy to my Casper Admin configuration. This seems to be working. I have had no problems so far.....

Hope this helps,

Roy

(repost)
I recently (and still currently) had similar problems with binding. My story goes like this....

I installed Casper Suite this last June. I did not have a lot of time to fully setup the managed preferences solely on my Casper server (too many lines of code to transfer in too little time). I asked Jamf if I could still use Apple's Workgroup Manager to manage my preferences. They said yes, no prob. Well, I built up my image (and used the Apple binding on it). Blasted my image out to my lab terminals and did some testing. At first, everything seemed to be working fine. I spot checked the lab computers to test the preferences and bindings and all seem to be working. Then, when I started testing my new user setups (and my returning users), I started to experience anomalies. Preferences were not being applied (such as dock, login, printer, etc. prefs). I thought my clone was corrupt and rebuilt it several times with the same effect.

I called Jamf and after going over all details, we decided that somehow the Apple bindings were not being applied correctly. So, we wrote a policy to rebind all the lab computers using the JSS Management "Directory Bindings" setup. We first setup the rules for binding in Directory Bindings and then created a policy to apply the rule ONCE, triggered by "startup". I restarted all the lab computers (and added this policy to my future images). This seemed to fix the problem. My preferences started working again and all the users were getting the correct user experience when they logged in. About a week later, things started to go "south" again. I restarted all the lab computers, but nothing changed. So, I reset the JSS policy to trigger the binding rule "Once ever day". I did this yesterday and, again, restarted all the computers. So far so good.

Now the real question is this. I did not have this binding problem last year (pre-Casper) when I was operating on OS 10.5.8. After I upgraded to Snow Leopard, I did notice that the whole binding process changed a bit. Apple got removed "Directory Utility" from the Utilities folder and buried it in the /library folder (also making it available in "Accounts area" of System Preferences. This made me question if other changes had been made to the binding scenario. The big question is: is there a bug in the binding process? Or, is there some incompatibility with Casper and Apple where binding is concerned? We are also using Apple's Portable Homes scenario. This also seems to be a factor, as we have "many users on many computers". This mobility and the "synchronization" that follows the user from computer to computer also raises the question of whether some corruption may be occurring in the ~/library/FileSync folder. I am also wondering, since we never turn our computers off (they go to sleep after an hour of non use), could the "sleep" process be causing the computers to stop handshaking and lose their binding?

So far, I am tracking everything. But, that's about it for now.....

[Farrell]

I was having the exact same problem that Colleen is having. What I discovered was that the OS was not deleting the Kerberos file. My solution was this (I used ARD to send out the commands, but Casper will work too):

unjoin the domain:

/usr/sbin/dsconfigad -r -u "username" -p "password"; /usr/bin/killall DirectoryService

delete Kerberos cert/Directory Service prefs:

rm -rf /Library/Preferences/edu.mit.Kerberos;rm -rf /Library/Preferences/DirectoryService/;/usr/bin/killall DirectoryService

rejoin domain:

/usr/sbin/dsconfigad -f -domain example.comany.com -u "username" -p "password" -ou "OU=Computers,DC=example,DC=company,DC=com"

Hope this helps.
Amoreena

[#11]

Thank you. I will give this a try.
Thanks-
Colleen