Binding lost, password prompt for rebinding

[kirkmshaffer]

Currently we're seeing an issue where AD suddenly stops working on certain machines (<10% of them). I think that's caused by the machine password reset issue described in several places, including here: https://jamfnation.jamfsoftware.com/discussion.html?id=8775

However, when I go to fix the issue, I cannot rebind with jamf policy because it prompts for a password. We have a bind-only service account we use to bind, and it works 99% of the time. But not in these instances. Has anyone run into this? Any suggestions?

I've tried unbinding first and: resetting machine account in AD; running jamf enroll; removing/reinstalling casper. Nothing has worked. We still get prompted for the service account's password even though the process works on other machines.

[lisacherie]

Next time this happens before rebinding, can you try:

sudo killall opendirectoryd

If this lets you query AD again eg. using dscl, might have some suggestions for you.

[dwandro92]

are these machines running 10.6.x ? I'm experiencing the same issues here, and am beginning to the think it has something to do with the syntax of the DSConfigAD command that is called by the JSS directory bindings.

[nessts]

dsconfigad -passinterval 0 probably will fix your problems

[kirkmshaffer]

@lisacherie - the killall didn't help me query AD again, I'm still getting shutout

@dwandro92 - We're on 10.9 (10.9 and 10.9.1 both exhibit this issue)

@nessts - we're discussing this with our security group right now, but trying to find a non-invasive way to clean this up so end users are affected in the meantime

[ClassicII]

@Shaffer][/url

We have continued to investigate this issue. Few questions for you.

On the machines that are disconnected are they vpn users or in office or school users?

Get one of the disconnected machines and then go into Keychain Access. Look for the an entry under the System Keychain "Active Directory/yourdomainname"

What is the date on that keychain?

Also do you have a 2nd entry right under that?

I would not recommend setting the password change to 0 as it is a security risk.

[lisacherie]

Do you have a custom edu.mit.Kerberos file?

Is another computer binding to AD with the same computer name?
(If this happens the computer will still appear to have the config ie. a dsconfigad -show)

[kirkmshaffer]

@ClassicII - Our Mac environment is 95% laptop, so these machines at anytime are wired, wireless, VPN, etc. All in an office setting. My machine just happens to be having the issue, I have the Active Directory/domain entry in System Keychain, dated 11/12/2013. I do not have a second one.

@lisacherie - We don't have a custom edu.mit.Kerberos file. It's possible machine names are being duplicated, but not probable. We hand out Thunderbolt Ethernet dongles with each laptop and they are imaged/named in our MAC DB with those dongles. What does the bind/renew process use for the computer name? local hostname or network hostname? As in: if someone borrowed someone else's dongle would that affect AD or Casper?

BTW - thanks so much for the responses folks, much appreciated!

[kirkmshaffer]

Just adding more info here.

dsconfigad -show:
Active Directory Forest = redacted
Active Directory Domain = redacted
Computer Account = redacted
Advanced Options - User Experience Create mobile account at login = Enabled Require confirmation = Disabled Force home to startup disk = Enabled Mount home as sharepoint = Enabled Use Windows UNC path for home = Disabled Network protocol to be used = smb Default user Shell = /bin/bash
Advanced Options - Mappings Mapping UID to attribute = uidNumber Mapping user GID to attribute = not set Mapping group GID to attribute = not set Generate Kerberos authority = Enabled
Advanced Options - Administrative Preferred Domain controller = not set Allowed admin groups = not set Authentication from any domain = Enabled Packet signing = allow Packet encryption = allow Password change interval = 14 Restrict Dynamic DNS updates = not set Namespace mode = domain

nlcontrol status
Connection Status: ERROR_NO_LOGON_SERVERS (0x0000051f)
Connection Flags: HAS_IP (0x00000010)
Trusted DC Name: (null)
Trusted DC Connection Status: ERROR_NO_LOGON_SERVERS (0x0000051f)

nlcontrol reconfigure
nlcontrol: netlogon control failed with error ERROR_NO_LOGON_SERVERS (0x0000051f)

[ClassicII]

@Shaffer
ok the field Password change interval = 14

is default so thats good to know but...

Active Directory/domain entry in System Keychain, dated 11/12/2013

is not so good. That password shoudl have changed a long time ago. The next time that machine was on the network it should have tried to talk AD and change its trust password.

What you should try to do is go into the directory utility and search for that computer name. Its possible that the record was deleted so the machine has nothing to talk to. If the record is there check at the bottom for the last time the record was modified. That will tell you the last contact from the machine to AD.

[kirkmshaffer]

@ClassicII - So the machine I had been poking is no longer available for testing. But i've got another with the same issues. The dsconfigad -show results are the same. The keychain entry for the domain is from 12/12/13, the AD record itself shows whenCreated as 11/9/2013, and whenChanged as 1/9/2014 10:29.

The fact that it changed this morning was odd to me. I'm not sure what kind of items that includes. But the local system log of the machine in question has this entry at that time (10:29am) with not much around it in proximity:

rpcsvchost[113]: failed to create secure channel: STATUS_ACCESS_DENIED (0xC0000022)

[ClassicII]

today hmm

it almost sounds like a machine took over the record. Are you sure that its not possible ?

We actually had this happen because we started off using 4 letters then the mac address for our naming convention. we had to chop off the last letter or number due to length and it ended up that we had 2 machines that were the same to the 15th character.

Check the keychain again is it still 12/12/13 and no dupe entry ?

[lisacherie]

You've probably already done this..
But try increasing the log level for opendirectoryd in case there are any clues in the log file.

odutil set log debug

The log file is /var/log/opendirectoryd

[lisacherie]

Just reread and saw the comment about removable adaptors..

Don't know if you are on Casper 8 or 9, if still on 8 ensure all the adaptors are added in the removable MAC address screen. Without this you will have computers attempting to use the wrong computer record in Casper.

[kirkmshaffer]

Hey folks - thanks again for the input. It turns out our server version 8.71 was causing issues. We were waiting to upgrade to 9.x once an issue we found with it was resolved, but that hasn't happened yet so we did the 8.73 upgrade and now the rebind using our policy works. Still very confused why it works on initial bind, but not rebind.

We're also still tracking the stale bind issues, but it seems like it's hostname based (our users have admin rights and are changing their machine names sometimes)