Nick Bonadies

IT Specialist :: Boston office

Nick is the IT Bearded Gentlemen who handles infrastructure, network, servers and technical operations for the Boston office. He is so ridiculously nice it’s not even funny. Like amazingly so. He even fixes servers at 3 AM when people are randomly working on something and they go down. He doesn’t even act grumpy, and really he usually isn’t. Unless you interrupt a serious round of Call of Duty 4 or Rainbow Six Vegas 2. Then he might get a little miffed, but only for a minute. He enjoys fixing problems, especially if he doesn’t have the slightest clue how to fix it. He also likes the woods and taking pictures. And yes, those are his mom’s dogs.

Hats 2

Back by popular demand, hats and more identities.

Data Security at the Doctors office

I was at the doctors office last week for a checkup and was appalled at the data security. First off, their networking closet is actually a closet. I know its the data closet because the door was wide open, and the door was wide open probably because it doesn’t have proper ventilation for the servers and networking gear. Strike one.
Strike two came when I was waiting for the doctor in the examination room. The nurse first came in and logged into the GE medical history software (the actual machine was already logged in, didn’t check to see if it was logged in as administrator but I bet you anything it was/is). Then she left the room. Left the room with the software that contained every medical record of probably every Beth Israel patient logged in. At this point I was a little freaked out, but was happy to see that at least it timed out after 5 minutes of inactivity and logged the nurse out. Oh that and the computer in the room was totally unlocked, I had full physical access to the machine for a good 15 minutes totally unattended. I could have done anything to that machine.
Then strike three came while I was getting blood drawn. Since the office is so small the label printer for samples is in the same room as the “collection” seat. So I sat in the seat and glanced about the room. Then the technician that was drawing my blood and preparing the samples sat at the computer terminal, which is plainly visible to anyone in the waiting room and anyone sitting having their blood drawn, and started to look up my information. There in a list of maybe 6 other people were my DOB, my social security number, my mothers maiden name, and my address. Plenty of information to steal my identity. Not only that but the other records on screen contained the same information for other patients. Great!
Needless to say I was stunned mortified. Actually so mortified that I totally neglected to complain, but how do you even complain about something like that to your doctor? I’m sure they do the best they can, and that their IT department is probably mostly to blame for letting the security get so lax.

Migrating Users from a Tiger server to a clean Leopard server

In a previous post I mentioned that we’ve been testing a new mail server solution. So far so good! I really like Kerio.
Only problem is that our internal authentication setup wasn’t really up to snuff, so I migrated everything over from our current Tiger server to a clean Leopard server. It was kind of a muddled process, and I figure other people might want to do the same thing, so here we go! steps!
What we’ll have at the end of this is a clean Leopard server running as an OD master, with kerberos rockin’ and all of our old users AND their passwords.
First things first, get you Leopard server box up and running, update it, get Open Directory running and set it to Open Directory Master. BE CAREFUL HERE. If you set your search base wrong or your kerberos realm wrong YOU WILL HAVE PROBLEMS LATER. Search base really could be anything, but I highly suggest you keep it as simple as possible, or if you can keep it the same as the search base on your old Tiger server.
Once you have Open Directory running, make damn sure that kerberos is also running before you do ANYTHING else. If its not, check your DNS, you should be able to resolve your server from its hostname AND ip address. If you need help, email me.
Now we need to export our users with their passwords, cause they are important and stuff. So on your old Tiger box get terminal buzzing cause everything we need to do is done there. Oh yeah, and this won’t harm your production server at all, so you can keep everything running live.
Lets export your users into an ldif file, like so:
sudo slapcat -l /path/to/users.ldif
While we’re here lets make a directory to put our passwords in and then grab our password db, like so:
mkdir /path/to/tiger_passwd_db<br />sudo mkpassdb -backupdb /path/to/tiger_passwd_db
Now you’ve got a flat file with all of your users and a folder with your password database files, but wait, you can’t just go and import this stuff whilly nilly into your clean install. The install is clean, and your old user db is DIRTY.
So lets clean it up! The first thing you’ll want to remove from the ldif file is anything that already exists in your clean Leopard install, so things like the root user and the old diradmin account need to get trashed. These entries will look similar to this:
dn: uid=diradmin,cn=users,dc=barbariangroup,dc=com
uid: diradmin
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: apple-user
objectClass: extensibleObject
objectClass: organizationalPerson
objectClass: top
objectClass: person
sn: 99
structuralObjectClass: inetOrgPerson
entryUUID: 5355461a-cb28-102b-8468-c17ea9eda937
creatorsName: uid=root,cn=users,dc=barbariangroup,dc=com
createTimestamp: 20070720161633Z
gidNumber: 20
uidNumber: 1000
authAuthority: (bunch of junk here)
userPassword::(bunch of junk here)
loginShell: /bin/bash
apple-generateduid: (blahblah more junk)
homeDirectory: /Users/diradmin
cn: Directory Administrator
entryCSN: 20070720161633Z#00000e#00#000000
modifiersName: uid=diradmin,cn=users,dc=barbariangroup,dc=com
modifyTimestamp: 20070720161633Z
Now hopefully you’re asking yourself, “how the hell do i know what to get rid of?” What I did was go to my Leopard server and exported the user database to an ldif file just like I did to the Tiger server and then compared the two, anything that already existed in the Leopard ldif file, I trashed from the Tiger ldif file.
But wait! Still not done cleaning that file up. You’ll need to search and replace your old LDAP search base with the new one for the Leopard server because this gets written to every user record. Annoying right? So for instance, on your Tiger server your search base was dc=server,dc=domain,dc=com and on your new Leopard server you’ve simplified things to just dc=domain,dc=com you’ll need to find/replace the dc=server in the Tiger ldif to match the NEW search string.
Cool, so that’s done, now you’re got a (nearly) perfect ldif file will all of your old user data. hooray! Lets get the Leopard server ready for the transition. Now since you’ve already set up Open Directory and made it the master, you will have already created a diradmin account. Since we don’t want to lose that password, we’ll first export your Leopard password database then import all your Tiger users, and then merge the two password databases.
So lets export that Leopard password database, open up terminal and run:
sudo mkdir passwords_from_leopard_server<br />sudo mkpassdb -backupdb passwords_from_leopard_server
You’ll notice that’s exactly what we did before to export our passwords from Tiger. Now we need the public key from the Leopard server, grab that by running:
mkpassdb -dump
You’re looking for a section titled “Public Key.” It’ll start with a 1024 and end with root@yourdomain.com. Hang onto that and head back to your Tiger ldif file, we’ve got some more find/replace-ing to do. The part you’re looking for is the “authAuthority” its a part of every user section of your ldif file and will look something like this:
authAuthority: ;ApplePasswordServer;0×46a0rewe95q184c10000000a0000000a,1024 35
1656695931665909934885529650807878698902444799687544911514204277892750444560
40005936512372916582789463659890238498589238402348023840210107069530617774018
50577252081327366279005303145695496695847004346878374632327359789719986361946
35779287349872349872349872349872347676758484746738357768598768767876313084048
91 root@server.com:ipaddress
You need to replace the string that starts with 1024 and ends with root@server.com:ipaddress with the string from the leopard server that starts and ends similarly. Make sense? good.
Now you’re done with that good ol’ ldif file, it should be perfect. Phew! That was a lot of finding and replacing eh? Take a break and get yourself a soda, you deserve it.
Alright lets get those users imported now! Send that Tiger ldif file over to your Leopard server. Since you’ve got Open Directory running already you’ve gotta kill slapd before you can import anything. Like so:
sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist
Then import the Tiger ldif file:
sudo slapadd -c -l users.ldif
and then reload slapd
sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist
Now you can launch Workgroup Manager on your Leopard server and make sure all your users made it over, lovely they’re all there! Now time for the passwords, send that whole directory we created earlier from the Tiger server over to the leopard server. Then merge the databases:
sudo mkpassdb -mergeparent /path/to/tiger_passwd_db /path/to/passwords_from_leopard_server
And now for the moment of truth, try and authenticate yourself against the new server with the same password you had on the old server. If that goes well, hooray! If not, you’ll need to demote the server to stand-alone and then back to master and repeat everything, mega burn.
If all went well though, and you’re able to authenticate your users just fine, you’ll wanna go ahead and kerberize your server, like so:
sudo mkpassdb -kerberize
and you’re done! you now have a fresh clean Leopard server that is running Kerberos fine, and has all your old user data and passwords imported. Sit back, relax, then get back to work sorting out the rest of your network!
Other tips:
  • Check out the inspiration for this post here actually most of these steps are taken straight from there, though this is more Leopard centric in that you need to kill slapd before importing users. Credit to Ian for finding that article in the first place, AFP548.com is a great resource for any Apple sysadmin.
  • Have a fellow IT guy/gal near at hand for those frustrating moments, it helps to have someone to bounce ideas off of.
  • Take your time. You will fail at least once, everyone does!

Mail Servers

Hey look at that! We’re growing! It’s really awesome because we get to meet and hang out with all these new fun people! but being the IT guy I of course see the stress adding all these people into the mix puts on our network.
Our current mail server/calendar solution just isn’t working anymore.
We rely on iCal pretty heavily for meeting scheduling, and let me tell you, since the last Leopard update it is BROKEN. We don’t use Apple’s CalDAV server, don’t even get me started on that, so the method we’ve adopted is one of subscription/updating flat files on a sever. Which works alright if you have like 30 people in the company all downloading and uploading their flat calendar files all at the same time. but if you double that number, well, you’re just asking for trouble buddy.
So the new thing we’re looking at is this Kerio Mail Server solution, which is just software, but it’ll run on Windows/Linux/Mac OS. Which is pretty awesome if you ask me, course I’m a sucker for flexible software. The best part about this software though is that it’s exchange-esque without having to bow to the whims of Microsoft.

Formal Friday Salute!

my first FFS!

Secure your home wireless networks!!

If there were ever reason to secure your home wireless network this is it!
When Indian police investigating bomb blasts which killed 42 people traced an email claiming responsibility to a Mumbai apartment, they ordered an immediate raid. But at the address, rather than seizing militants from the Islamist group which said it carried out the attack, they found a group of puzzled American expats.

Hats

I wear many different hats at The Barbarian Group. Sometimes I’m a network technician, other times I’m a server administrator, and still other times I’m a desktop support specialist.
Here are those different hats.

Latest Attackers

64.44.140.110 ->
218.7.13.215 ->
202.102.245.121 ->
61.145.119.11 ->
59.108.79.152 ->
213.60.194.35 -> cm194035.red.mundo-r.com
85.131.212.26 ->
202.163.75.29 ->
216.129.98.144 -> www2.pramati.com
Doing these posts is really sort of surreal for me. Its like if you could check your blood for all the germs that tried to make you sick, but didn’t quite make it.