today I am not writing because of a certain problem or thing I stumbled upon. The “news” I want to share is somewhat “old” (26 August 2013), too: VMware announced vSphere 5.5 and ESXi 5.5!
Why am I posting this? Besides some cool new features in Hardware Version 10 or on the VDP side and Hypervisor side, a mayor change that will affect how we use vCenter in our Company is: Full Mac OS X Client integration (including the plugin for vCenter WebClient).
So, we’ve all been there: A user is using his Mac with a local account. At some point IT needs to manage all Computers and Passwords, and thus this Mac together with it’s user needs to be ActiveDirectory managed. But of course: No setting, no file, nothing should change, because the user is king (and maybe the company’s boss that hates being upset, and even a changed background or shortcut-location upsets him….). Here’s how to do it:
Create a new local user with admin rights.
Logout of existing User and into the new admin user.
Delete the user you want to migrate. When the system asks, don’t delete or archive the user folder, just leave it where it is.
In a terminal issue the following command “sudo mv /Users/oldusername /Users/newusername” where newusername is the shortname of the AD User. This is critical!
If not already happened bind the Mac to the AD.
Use “chown” in terminal to change the owner of the users directory to the new domain user. Use the shortname, no need to write the FQDN of the AD.
Use “directory utility” to change the settings and check the box to create a “mobile account at login”, and check the second box, too.
Now logout, maybe reboot. (Sometimes it is needed, sometimes not, depending on how quickly the Mac gets the new AD binding.
Login using the new users shortname. It should ask for a mobile profile, create one!
You might need to update the keychain password.
Thats it: Enjoy your migrated user folder and settings. You shouldn’t notice any difference besides a new password 😉
One note: The new user is a standard user without administrative rights. If you need to give him/her or the Administrator-Group admin rights, you can to this in the “Directory Utility” as well. Single users won’t work, use groups like this: DOMAINNAME\groupname .
So, one of our domain printers was acting up and the printer department wanted me to sniff all the packets to and from the printer. So far so good, usually you could use a hub (still got one around? neither do I), or for example a switch with a monitoring or promiscuous port (not available? Welcome to the club!). Ok, now I could start arp spoofing the printer, but was too lazy to do that, besides: we have intrusion prevention up and running…
Take a good look at your machine. Is it a portable laptop like mine? Does it have any flavor of Unix or Linux on it? Well, so does mine, in this case Apple OS X (10.8.2). There’s got to be a way to bridge two ethernet interfaces, connect myself to the network and let the printer talk to the world through my laptop? You betcha!
Here’s what I did:
grab one of those USB or Thunderbolt Ethernet Adapters
ifconfig // to find out which interface is which
sudo ifconfig en3 up // bring up the USB/Thunderbolt adapter, or it won’t work!
sudo ifconfig bridge0 create
sudo ifconfig bridge0 up
sudo ifconfig bridge0 addm en0 addm en3
sudo sysctl -w net.inet.ip.forwarding=1
It works! Now we can sniff away with tcpdump or wireshark for example, and are sure that no packet is going to escape us…
And to undo what we just did:
sudo ifconfig bridge0 down
sudo ifconfig bridge0 deletem en0 deletem en3
sudo ifconfig bridge0 destroy
sudo sysctl -w net.inet.ip.forwarding=0
Many thanks to Chrissy from netnerds, who set me on the right track with her post about NAT on OS X 🙂