This computer is already 'bound' to Active Directory. You must 'unbind' with '-remove' first.

[ericbenfer]

Recently I've been running into a problem with Casper binding to AD.
If I try to bind a Mac to AD, and it already has a computer record in AD, it will fail.
This scenario comes up if you are rebuilding a Mac that was bound to AD.

I have "rebound" other Macs in the past. I know it was working back in June using 10.7.x and Casper 8.5.x.
If I manually join using Directory Utility I get the "Join Existing Account?" message. Click OK then it joins it properly.

Here is the policy log.

/usr/sbin/jamf is version 8.63
Executing Policy my.domain.com AD...
Binding eric-ml15 to dockside.benfer.com...
An error occurred binding to Active Directory: dsconfigad: This computer is already 'bound' to Active Directory. You must 'unbind' with '-remove' first. (Attempt 1)
An error occurred binding to Active Directory: dsconfigad: This computer is already 'bound' to Active Directory. You must 'unbind' with '-remove' first. (Attempt 2)
An error occurred binding to Active Directory: dsconfigad: This computer is already 'bound' to Active Directory. You must 'unbind' with '-remove' first. (Attempt 3)
An error occurred binding to Active Directory: dsconfigad: This computer is already 'bound' to Active Directory. You must 'unbind' with '-remove' first. (Attempt 4)
An error occurred binding to Active Directory: dsconfigad: This computer is already 'bound' to Active Directory. You must 'unbind' with '-remove' first. (Attempt 5)
Error: Giving up on Active Directory binding after 5 attempts.
Running Recon...
Blessing i386 OS X System on /...
Creating Reboot Script...

Thoughts?

[JPDyson]

Interesting that the error message you're getting doesn't correlate to the stated problem; dsconfigad implies that the computer is already bound, not that the object already exists and you don't have permissions to join to it. While the Casper Admin AD config mimics the GUI options, I'm not sure what command line switches are actually invoked (specifically in this case, -force).

Have you looked at the AD computer objects in question to determine what your permissions are on them? It's entirely possible that you have sufficient permissions to delete an AD object without permissions to overwrite it.

[jarednichols]

Funny, I've seen this exact error message in jamf.log though the system binds just fine in cases where the computer object is pre-populated. You may want to make sure the service account you're binding with has the appropriate permissions.

[donmontalvo]

We had a similar problem where our AD binding script in JSS was failing on computer being reimaged (and rebound).

We had to request the account used by JSS be given rights to "Join Existing Account", once that was done the errors went away.

While we were at it, we had to also ask to be given rights to delete accounts from AD, since the workaround that was being used was to append a character to the Computer ID when joining to the domain.

Not sure if this helps, just wanted to share.

Don

[oopsydaisy]

We had to request the account used by JSS be given rights to "Join Existing Account"

Where would these rights be given? In AD?

[jhbush]

I agree with others that this seems like a permissions issue in AD. When we re-image machines we don't remove them from our Mac OU. The JAMF created BIND works for us on the reboot. We use a specific service account in AD for joining machines to the domain.

[donmontalvo]

Where would these rights be given? In AD?

Yes.

[franton]

I've seen this caused by two things on our setup.
1) There's a policy trying to bind a mac that it thinks is unbound from the inventory record, but that record is inaccurate.
2) The computer has been unbound from the AD uncleanly and the AD thinks there's still a record.

Not much you can do for the first one apart from make sure your inventory is updated as often as feasible. The second involves deleting the existing computer object from AD, making sure the target computer is also unbound and then attempting another bind.

[ericbenfer]

If I make sure to delete the computer record from AD before re-imaging, there is no problem. This has worked for me in the past on another network.
I am on a totally different network, and my own (fairly vanilla) AD environment. So there is a high likelihood something is screwed up in my AD.

To (hopefully) eliminate any permissions issues, I have been testing with the domain admin account (in my dev environment).

Here are the variables that work (all using domain admin).
Casper Directory Binding with NO existing computer object in AD.
OS X Directory Utility with NO existing computer object in AD.
OS X Directory Utility with existing computer object in AD. (Displays "Join Existing Account?" message)
dsconfigad -add with NO existing computer object in AD.
dsconfigad -add with existing computer object in AD. (Displays message in terminal "Computer account already exists? Bind to Existing? (y/n))
dsconfigad -remove then dsconfigad -add with existing computer object in AD.

Here are the variables that DO NOT work (all using domain admin).
Casper Directory Binding with existing computer object in AD.

Can anyone else re-bind using a 8.63 Casper Directory Binding with an existing computer object in AD 2008 r2?

[ericbenfer]

More anecdotal data...
I was working with someone last week. Casper 8.63 and AD 2008 R2
In their AD they must first create the computer object in Active Directory, then they bind to that object. This is a security/procedural requirement, not a technical requirement.
They are having the same problem. (An error occurred binding to Active Directory: dsconfigad: This computer is already 'bound' to Active Directory. You must 'unbind' with '-remove' first.)

[JPDyson]

Curious; the last place I worked, we did the same thing - we had an in-house utility that would create the objects and then you could bind to them. I put out a feeler to a colleague to see if that's causing any problems lately.

I'm on 8.62 and not having any problems with this; we're using a service account for binds, and it has all the sufficient permissions on creating/deleting records.

[ericbenfer]

Josh,

Did you get any feedback from your colleague?

Eric

[ericbenfer · Accepted solution]

never mind.

[jcavallino]

The way i go about this is first fire up active directory users and computers, go to the particular mac os ou in AD, find the computer name delete it. wait between 15-20mins depending replication and how big AD environment is. Once that is complete i run my binding script to rejoin the mac back to the domain. I have a service account that i created in AD just for joining and removing machines to AD and also dose Ldap query as well.

[mthakur]

Eric,

The issue appears to be that Casper can only to unbind from AD by running a script ... which of course means that you then have to deal manually with AD passwords being hardcoded into the script, or being passed over the network.

What Casper should do is allow options to:
1. Unbind from AD
2. Join existing account or force unbinding (i.e. specify dsconfigad -force).

Sure, I can write a script to do all this... but why not add some UI into Casper to make this very common operation easier?

-Manavendra

[donmontalvo]

@mthakur wrote:

Sure, I can write a script to do all this... but why not add some UI into Casper to make this very common operation easier?

Casper Remote, Self Service... ;)

[coreythefore]

just had this issue with having to re-bind a hundred or so teacher MacBooks. deleted from AD, created script to run before, that "unbinds" then the policy runds AD binding and sets open firmware password for us. Works like a charm!

[Look]

Here is the solution I used for machines that simply refuse to leave AD.

echo "---Removing from AD"
dsconfigad -remove -force -u ANADACCOUNT -p ANADPASSWORD
sleep 15
echo "---forcing the issue" rm /Library/Preferences/OpenDirectory/Configurations/Active Directory/ANADDOMAIN.plist

Pretty sure the error is being generated because the local machine still thinks it's bound rather than AD thinking it is bound, either way unless there is a permissions issue with the actual account in AD this seems to resolve the problem.

Edit: But as mentioned earlier it does require passing credentials out from Casper.

[alexk]

I came across this post because I was having the same problem as the original poster ericbenfer and some others. I was able to resolve it by granting additional AD permissions on the account being used to bind to AD, what I believe donmontalvo is talking about in his post when he says to grant the right "Join Existing Account" in AD. I wanted to post some additional info on how to do that just in case it is helpful for anyone else who may come across this in the future.

Background info: My exact situation is that I use an AD service account (this solution applies to any AD user account though) in the JSS Directory Bindings to bind Macs to AD. It was working fine for Macs that the service account binds and creates as new computer objects in AD or existing Macs in AD that the service account had previously bound and created in AD. The problem would occur if it would try to bind an existing Mac in AD, meaning the Mac's Computer Object already existed in AD, and it was created with a different AD account. I most often saw the AD dsconfigad errors when re-imaging and then re-binding that Mac to AD, because I do not delete the AD computer object when re-imaging Macs.

Solution: Grant additional permissions in AD to the AD account that you are using to bind Macs to AD ("Join Existing Account"). It's easiest to do this in on a Windows computer that has the Active Directory Users and Computers MMC. I'm assuming you or whoever is managing your AD infrastructure has the MMC and has the ability to grant additional rights to an account.

Luckily, this person outlined the steps in great detail with screenshots. Scroll down about 1/3 of the page to the second section titled "2. Allowing a security principal to join and re-join a computer to a domain" and follow these exact steps.

http://morgansimonsen.wordpress.com/2013/12/17/delegating-computer-object-management-tasks/

After following these exact steps, I was able to join a new Mac or an existing one to AD using the JSS Directory Bindings and the AD account. Nothing additional or special to do and no need to delete the AD computer object first or force remove or add in any way.

Hope this helps someone else!

[Federico_Carbon]

@ Look. Works like a charm.

echo "---Removing from AD"
dsconfigad -remove -force -u "serviceaccount" -p "passw"
sleep 15
echo "---forcing the issue" rm /Library/Preferences/OpenDirectory/Configurations/Active Directory/yourAD.plist

Cheers!

[Bhughes]

I am seeing this same problem, happening when someone re-enrolls.
An error occurred binding to Active Directory: dsconfigad: This computer is already 'bound' to Active Directory. You must 'unbind' with '-remove' first. (Attempt 1)

Is there a better way to unbind it than the script that passes the credentials?

[alexjdale]

One great thing about "-remove -force" is that if you don't care about the system being removed from AD and/or only want it disjoined locally, you can just make up any username and password. Even if that authentication fails, the system will be disjoined locally.

[rtrouton]

To follow up on @alexjdale , I have a post on how that works:

https://derflounder.wordpress.com/2013/10/09/force-unbinding-with-dsconfigad-without-using-an-active...

[Bhughes]

Nice. That should work thanks

To follow up on @alexjdale , I have a post on how that works: https://derflounder.wordpress.com/2013/10/09/force-unbinding-with-dsconfigad-without-using-an-active-directory-admin-account/

[Bhughes]

Did you create a script with this and add it before your AD binding policy?

[bentoms]

@Bhughes So you have your AD binding triggered on enrolment?

Why not scope to a smart group that has directory status "not bound" & the policy is triggered post enrolment?

[Bhughes]

@Bhughes So you have your AD binding triggered on enrolment? Why not scope to a smart group that has directory status "not bound" & the policy is triggered post enrolment?

Thanks for the idea @bentoms a co-worker was able to solve the issue by removing the ad bind: /usr/sbin/dsconfigad -remove -force -u a -p a

in our computer naming policy that runs first.

Then created a custom event called "adbind" to run after naming the computer.

[xpd154]

If your AD binding account has permission to join an existing account, pipe the yes command. If unbinding did not happen or did not happen correctly, or if the machine account still exists, the system will continue to bind assuming 'Yes' to "join to existing account".
/usr/bin/yes | dsconfigad -add DOMAIN -computer scutil --get ComputerName -username binduser -password pass -ou "ou=path"