New Domain, same users - Need to fix existing accounts

[mhegge]

I have an issue with allowing existing account log into new domain. All account information is a the same, but I need a script to fix permissions on the user folder to correlate with the new domain.

We unbind from old domain and bind to new, existing user account login is refused.

[bramstedtb]

Are you using mobile accounts? We are currently in the process of moving accounts to a new domain, and saw the same issue when using mobile accounts. We use this script to delete the account while retaining the home folder, and it seems to have done the trick. You will want to be careful with FileVault machines.

#!/bin/sh
# This script will delete Mobile Accounts while retaining the home folders

userList=`sudo dscl . list /Users UniqueID | awk '$2 > 1000 {print $1}'`
loggedInUser=$(ls -l /dev/console | awk '{ print $3 }') 
echo "Deleting Mobile Account For:"

for a in $userList ; do
    find /Users -type d -maxdepth 1 -mindepth 1 -not -name "*.*" | grep "$a" | grep -v "$loggedInUser"
        if [[ $? == 0 ]]; then
            sudo dscl . delete /Users/$a  #delete the account
            sudo chown -R $a /Users/$a

        fi
done

[mhegge]

Yes, we are using managed, mobile accounts. I can test this, but can you give me your complete workflow?

[bramstedtb]

Not sure what you mean by complete workflow. The script does all the work. I can try to give you more detail about our organization.

We use Enterprise Connect here, so it is primarily multi-user machines that are AD bound. We are also split into multiple sites. My site wasn't affected by the move, since we don't use managed mobile accounts, but other sites are. Our accounts team found that the issue was with managed mobile accounts, and that deleting the account was the fix. I was asked if I could come up with a script to delete mobile accounts, while retaining the home folders, and that's what I gave you. Each site has it's own policy tho run this script once-per-day and they scope it to their AD bound machines.

[mhegge]

The reason I ask for a workflow is because, in my case, I have faculty users (not a multi machines scenario).

• Machine needs to be unbound from current domain
• Script run while logged into admin account (cannot make this a self service policy)
• Machine joined to new domain.

Then, if your script works like I hope, log into user and it will use the existing user folder for the new domain account?

[bramstedtb]

If the user name is the same in both domains then the script should let the user log into their original folder. You will want to bind to the new domain before running the script though. The script uses the chown command to assign the folder to the AD user, and if you aren't bound to AD yet, then you are assigning ownership to a non-existent account. You can probably do all of this through a single policy without needing to be logged in to any account.

• Run a script to force unbind from AD. Run with Before set on priority
• Use Directory Bindings to bind to new domain
• Use the script above to "reset" the mobile accounts. Run with After set on priority

Once it's tested and working, you could have this run on startup, and have your users reboot when they leave for the day, or push a reboot over night.

[mhegge]

One question, will the script delete all accounts? (concerned for Shared and AdobeInstall, and local admins) They are local accounts.

[bramstedtb]

It won't. The script only deletes accounts if the UID is above 1000, which is a range reserved for mobile accounts.

[mhegge]

Did not work. Could not log into the test user after running the policy:

Executing Policy Unbind - Bind - Fix Account
Running script Force-Unbind from Domain...
Script exit code: 0
Script result: Binding ACCAMM1010MAC1 to ccc.xxx.edu...
Bound to Active Directory (ccc.xxx.edu)
Running script Delete Mobile Accounts Maintain Folders...
Script exit code: 0
Script result: Deleting Mobile Account For:
/Users/s15XXXXX9

[mhegge]

I found the missing link. I have a script that changes in the search paths (CSPSearchPath, -delete, -append, blah blah)

Once that ran on the machine, I was able to log into user in new domain. I will include that in my policy and see how it goes.