Moving mac from default "computers" OU to a different OU. How to get mac to see the change

kateswist
New Contributor

When I join my macs to my 2008 AD, they all join in the default "computers" OU. But I need to move a subset of them to a different OU called "JrHi." Once I move those computer accounts to the new OU, AD recognizes it just fine. But how do I get the mac to recognize its new OU? I need the computer itself to recognize and report that it is in a different OU than the one it was originally joined into.

Any thoughts?

21 REPLIES 21

nessts
Valued Contributor II

join them to the correct OU in the first place.

nessts
Valued Contributor II

the flag to dsconfigad is -ou dn

kateswist
New Contributor

Ya, well its too late for me to join them to the new OU. These were joined to the domain months ago and now for lots of reasons they need to be in a different OU and I need the computer to recognize that change.

What does that command do?

mm2270
Legendary Contributor III

I don't think you're going to be able to do this without rebinding them. The OU is only set at the time the Mac is bound into AD. Its not something you can easily change after the fact to my knowledge.

If you do man dsconfigad in Terminal, scroll down and you'll see the -ou dn instructions, but as it mentions in the man page, its only used when adding a computer to the domain, so during bind operations, not after the fact. For example, run dsconfigad -show on any AD bound Mac and you won't see that information (the OU) show up anywhere.

kateswist
New Contributor

Ugh.. Ok thanks for the info. I appreciate the explanations.

ernstcs
Contributor III

@kateswist, I'm in agreement with @mm2270 here in regards to rebinding them. For many reasons that's the cleanest option. That shouldn't be hard at all if you're using the binding tools within the JSS.

spalmer
Contributor III

@kateswist][/url][/url][/url][/url Could you give a little more background as to why you need the Mac to recognize the new OU it has been moved to? Are you simply wanting a report as a sanity check?

The built-in AD Plugin is really only used for user authentication and doesn't care what OU the computer object is in after binding is complete. Part of our standard Mac and PC imaging process is to bind them to AD in a special imaging OU and then move them to the correct departmental OU after the fact.

Even if you do rebind them directly to the correct OU, like @mm2270][/url][/url][/url][/url mentioned the AD plugin (dsconfigad -show) still won't show you the OU you bound them to if you need another sanity check months later.

kateswist
New Contributor

I have a content filter at school where I can apply rule sets based on OU membership. If I can have all of these Junior High laptops in an OU I can apply a rule set specific to Junior High, regardless of how the user logs on. That is why I would like the computer to recognize that it is in a different OU so it can get a specific rule set.

kateswist
New Contributor

I guess I should elaborate a bit. If junior high students log on with their own AD user account they get the Junior High rule set which is fairly restrictive (no youtube, no facebook, no games, etc...) But if they log on with their little brother's account from 2nd grade they will get a different rule set that allows them to go somewhere the junior high can't.

I can apply rule sets to IP ranges as well, but if the student changes the wireless setting on the laptop to his buddy's hotspot from a cell phone, the rule set isn't applied.

These are laptops in carts, specific for junior high student use, so I'd really like the rule set applied to the computer, regardless of IP or user logon.

I could apply the rule set by individual computer name, but that would mean I would have to create a least 60 individual assignments and that gets messy and unruly in my content filter.

mm2270
Legendary Contributor III

Its possible to do an unbind and rebind back to AD, completely automated. But, it will take some careful planning, scripts, Extension Attributes, Smart Groups and policies, all working together.
Here's a high level view of how I'd consider doing it.

1 - Create an EA that would query the AD environment for the Mac's current OU, place it into the EA's results.
2 - Build a Smart Group for any Macs that are in the default "Computers" OU, and perhaps any other identifying criteria that I might need to target the correct Macs.
3 - Build a policy, that uses the above Smart Group(s) which runs at logout to unbind the Mac, then rebind it to the new/correct OU. The script could do the binding, or you could use a stored Directory Binding from the JSS (safer - no passwords stored in the script)

The only issue with the above is the logout. I don't think i'd want something like an unbind to happen while users are logged in, so getting the policy to trigger might be the most challenging aspect.

spalmer
Contributor III

@mm2270][/url][/url I built an EA, probably based on some of your comments from another JAMF nation thread, to display the current OU our Macs are in. Maybe I am thinking too much along the Windows way of doing this but I don't see why she needs to go to all of the trouble to create smart groups to detect the Macs in the incorrect OU and unbind/rebind to move the computer objects to a new correct OU. Just use Active Directory Users and Computers on a Windows box to drag-n-drop the computer objects to the new OU. If she doesn't have the AD administrative rights or a Windows box to do this on she can ask a domain administrator to do this for her.

The dscl command that the EA is based on will return the new OU at the next inventory of the computers. She can use the results of the EA to create smart groups based on the new OU the Macs are in and apply policies to those smart groups.

mm2270
Legendary Contributor III

@spalmer, you may in fact be 100% correct. I haven't tried moving a computer from one OU to another in AD, generally because we don't need to do that, and probably wouldn't do it. so I have no point of reference. If its true that the Mac then picks up its OU correctly, then you'd be right that @kateswist doesn't need to do anything more than manually move them. Good call on that if true.
The EA as you've done, is still a good idea to get confirmation of the AD OU at next inventory check in, and could be used for other groups and policies, if needed.

kateswist
New Contributor

@spalmer @mm270

If that works the way you describe it, I would do a happy dance at my desk. The computers are already in the new OU. Can you explain in more detail the EA and dscl areas? I am a windows girl trying to figure out this mac business.

Thank you.

mm2270
Legendary Contributor III

@spalmer][/url can post what he has together, but here is one way-

#!/bin/sh

ADCompName=$(dsconfigad -show | awk '/Computer Account/{print $NF}')

ADOU=$(dscl "/Active Directory/DOMAIN/All Domains" read /Computers/$ADCompName dsAttrTypeNative:distinguishedName | awk -F, '{getline; print substr($0, index($0,$2))}')

echo "<result>$ADOU</result>"

The above may need to be adjusted to your environment. Can't say for sure that the "dsAttrTypeNative:distinguishedName" part will actually pull what you want. Change the "DOMAIN" to your AD domain name.
Also, the script assumes a valid connection with AD. The Mac has to be bound to AD to do such a lookup and the DC has to be available, meaning it probably won't work from outside the org walls.

You could easily do a check up front in the script to see if the Mac is a) bound to AD, and b) can talk with the domain controller.

spalmer
Contributor III

I have something similar to @mm2270][/url][/url][/url][/url][/url][/url][/url][/url][/url][/url. Again I am sure I based this on his work or work others have posted on JAMF Nation, but can't remember at the moment:

#!/bin/bash

boundToAD=`dsconfigad -show | awk '/Active Directory Domain/{print $NF}'`

if [[ "$boundToAD" == "" ]]
then
    eaResult="Not bound to Active Directory"
else
    adComputerName=`dsconfigad -show | awk '/Computer Account/{print $NF}' | tr '[a-z]' '[A-Z]'`  
    awkFieldSeperator="CN=`dscl localhost -read /Search/Computers/$adComputerName dsAttrTypeNative:cn  | tr -d "
" | awk -F": " '{ print $NF }'`,"

    eaResult=`dscl localhost -read /Search/Computers/$adComputerName dsAttrTypeNative:distinguishedName  | tr -d "
" | awk -F": " '{ print $NF }' | awk -F"$awkFieldSeperator" '{ print $2 }'`
fi

echo "<result>$eaResult</result>

There is in an extra check up front to detect if the Mac is bound to AD and populates the results with something I can use to later create a Smart Group for Macs that aren't bound to AD. Also, this script looks in /Search/Computers so that the active directory domain name doesn't need to be known ahead of time. This way it also doesn't matter if the "All Domains" option was enabled or disabled when the Mac was bound.

Since I have about 20 different OU's our Macs can be in I waited until the EA started getting populated before creating any Smart Groups, but basically you will end up with something like:

"OU=SubDepartment,OU=Department,OU=College,OU=Workstations,DC=school,DC=edu"

You can then just create a Smart Group with that entire string for a specific sub-department or you can create a smart group based on just part of it.

"OU=Department,OU=College,OU=Workstations,DC=school,DC=edu" will give you everything at the department level
"OU=College,OU=Workstations,DC=school,DC=edu" will get you everything at the college level
"OU=Workstations,DC=school,DC=edu" will give you everything at the workstations level

etc... etc... Of course this somewhat depends on how your AD structure is laid out.

I guess if you think about it this kind of allows you to emulate your Windows Group Policy structure for Macs by using Casper Smart Groups.

bentoms
Release Candidate Programs Tester

Hi all,

I don't think the Mac really cares which OU it was bound to & where the object exists. As long as there is one in AD & the computer is a domain member for authentication purposes.

The content filter also doesn't care which OU the mac WAS in, only where it IS from there it knows how to apply the policy.

This is me taking a guesstimated leap in logic. TEST, TEST, TEST.

Sorry if I've missed some pertinent detail.

nkalister
Valued Contributor

I've always done what spalmer suggested- if the mac is in the wrong OU, I just move the computer object using Active Directory Users and Computers on a Windows machine. The mac client won't care that the object's been moved since it's still in the search path within AD

gregp
Contributor

We recently tested moving our Macs from one OU to another and the Mac doesn't seem to care. We did a few of them a couple of months ago and they are just as happy today as they were initially.

Our binding script will now bind to the new OU and sometime in the near future, our AD admin will move the machines in the current OU. And I don't plan on doing anything except spot checking a few of them.

dwandro92
Contributor III

Here's the extension attribute script we're using:

#!/bin/sh

NetName=`scutil --get ComputerName`

ADOU=`ldapsearch -Hldap://MyDomain.MyCompany.com -tt -x -D "MyDomainMyLDAPQueryUser" -w "MyLDAPQueryUserPassword" -b "dc=MyDomain,dc=MyCompany,dc=com" -L "cn=$NetName" | grep 'dn:' |sed -e 's/dn: //g'`

if [[ $ADOU == "" ]]; then
    echo "<result>Not Found or Not Bound</result>"
else
    echo "<result>$ADOU</result>"
fi

exit 0

Obviously this is only helpful from a reporting standpoint, but maybe it will help you.

kateswist
New Contributor

@mm2270
If I run your script with my own environmental variables, will the mac then recognize that it is in a different ou than the one it was bound to? I know what OU the mac is in because I manually moved it from the default. I need the mac to know and report that it is in the new OU. Does that make sense?

mm2270
Legendary Contributor III

@kateswist][/url][/url][/url - believe it will report the OU its now in, because its telling the Mac to query AD directly, rather than reading any information from its local node. But, since I haven't moved a Mac to a new OU (and I'm not going to) I haven't run a direct test, so I can't be completely certain. 99% sure though. I'd say just compile the script as a bash script and run it manually on one of the Macs that you know is in the new OU. You should get the proper results.
In Terminal:

sh /path/to/script.sh

Also try @spalmer][/url][/url's script, since it seems he put a little more logic in it to trap any odd instances.