So I set out to find a solution and I found a post by loudhush which described using the scutil to modify DNS network settings after connecting to a Cisco VPN. This was great, but I needed something a bit handier.

So, I cranked out the following which goes in my /Users/username/.profile:

# .profile or .bash_profile
function myvpn {
vpnclient connect VPNPROFILENAME user MYVPNUSERNAME
myworkdns
}
function myworkdns {
printf "get State:/Network/Service/com.cisco.VPN/DNS\nd.add ServerAddresses * 192.168.1.252, 192.168.1.198\nd.add SearchDomains * example.com, other.example.com\nset State:/Network/Service/com.cisco.VPN/DNS" | sudo scutil
}


These are bash functions which i run from the command line. (I also find the Client GUI Cisco to be a pain, and prefer command line)

So, obviously, you’ll need to substitute in your Cisco VPN profile name ( found in /etc/opt/cisco-vpnclient/Profiles), your VPN username, your DNS server IP addresses, and your DNS search domains to your legitimate values.

To use, run Terminal, then type myvpn. The VPN client will prompt you for your username and password. You’ll then have to hit CTRL+Z to suspend the VPN client so the script can run the DNS updates; this part uses sudo to run the command as root, so you will probably need to type your Mac password immediately after hitting CTRL+Z. If you didn’t want to bother with the command line VPN client, you could just use your GUI Cisco VPN client, then run myworkdns from Terminal, which will still probably prompt you for your Mac password.

Hope others find this useful. If I find a cleaner way, I’ll post that too.

I recently completed an upgrade of these two core services on a network I manage. We had been running outdated (but functional) BIND v8 and OpenLDAP v2.0 instances for of DNS and LDAP servers. Also, throw a Windows Server 2003 into the mix, which, as an Active Directory domain controller has to run its own DNS and LDAP (AD is tweaked LDAP) servers.

First, the DNS upgrade was substantial, not just because we upgrade to a more modern BIND v9.x installation, but because we implemented a split view configuration. Previously, our local users operated on a sub-domain of “local.example.com” such that each computer was named “host.local.example.com”. The main public services utilized the proper full-domain of “example.com”. This was fine in the beginning, as when we set this up, few users had laptops, so we didn’t use individual client VPN or have road warriors with laptops out trying to access “local” services from home or a customer locations. Also, some services we started deploying (eg, our XMPP chat server, Openfire) preferred to be bound to one host name (like, im.example.com). Internally, that host name still resolved to our public IP address which then needed some interesting firewall rules in order to support the routing or traffic. But this issue was already present with mail services; if I wanted a laptop user to use “mail.example.com” for his server while out of the office, while on VPN that user would have to change to “mail” or “mail.local.example.com” because the VPN essentially made the user part of the local network.

The solution I came up with, as mentioned above, was to use BIND views, and get rid of a “local” DNS sub-domain. All our servers and host names would be part of the base “example.com” domain, thus, local, VPN, or public users would only have one host name for accessing services like mail (mail.example.com) or chat (im.example.com). BIND views essentially provide a different view to your DNS based on the host IP address you are using to access the server. So, if users are at the office, im.example.com resolves to a private RFC 1918 address, same as it resolves if they are connected via VPN, but if they are on the public internet, im.example.com resolves to a publicly routable address assigned to our organization.

Are there any tricks or gotchas when making a change like this in your organization’s DNS? The biggest trick is BE METICULOUS! Seriously, if your organization was like ours, you had a mix of both FQDNs and non FQDNs in your intranet & application URLs, user documentation, etc. Undertaking a naming change like this could be very daunting given a large enough organization. You may find that you can only migrate those services which really need to have split view DNS. In my case, most of the time spent prepping for this transition was spent searching out where the “local.” part of FQDNs was used and switching to non-qualified host names or making a note so I could change it to the new FQDN after the migration. All in all, this proved to be a fairly painless migration for this smaller organization.

The LDAP transition initially concerned me more than the change to DNS, but in the end, proved to be less painful. However, it did require more new knowledge to transition to a totally new server instead of simply upgrading and reconfiguring. OpenLDAP had served us well, but some other admins in the group had been playing with Fedora Directory Server (FDS) and had it installed in other production environments. A few key things prompted us to migrate. First, multi-master replication is a SNAP with FDS. Having that is key part of having redundant and available directory services. Yes, it can be done with OpenLDAP now (as of v2.4 or so), but it wasn’t there when we put our first FDS server into play. Also FDS has nice built-in facilities for account password expiration and password policies and account lockouts. Also, we’d used a bit of hack to push password updates to OpenLDAP from Windows Server for users who had both Windows and Unix accounts, but FDS prvoides a very complete two-way password synchronizer for Windows. Again, I’ll emphasize that replication is a SNAP with FDS. This is largely due to its very useful and easy to use Java based GUI management interface. This is a stand-alone client which runs on your desktop and connects to FDS’s admin server. Fear not, command-line junkies, everything that can be done in the GUI is available on the command-line and via ldapadd LDIF commands, etc. The management interface not only lets you configure the server, options, ACLs (FDS calls them ACIs), etc, but this tool is also a data management tool for all your LDAP data. This was plus for us as we’d never been thrilled with our data management options in OpenLDAP. We used multiple tools to managed accounts in OpenLDAP, but in the end, the best all around tool we had used was phpLDAPdmin. I’m sue the tool has matured A LOT since we last upgraded, and it was pretty nice, we may even install it again with FDS, but the built in GUI from FDS is just a nice touch.

The actual work of transitioning from OpenLDAP to FDS was not as hard as I’d expected. First, I installed FDS on the new server. The installation process was pretty straight forward if you’ve used OpenLDAP before and done your resarch ahead of time. A slapcat of the old OpenLDAP database created an LDIF dump of my old data. From there, I experimented with importing the data into FDS using ldapadd. There were a few schema changes required, but not many. In my case, the LDIF lines that FDS didn’t like were not required (eg, “struturalObjectClass” was dumped by OpenLDAP but required by FDS) and I simply ran my LDIF dump through a series of “grep -v” filters to remove the unwanted lines. One other concern was the format of the userPassword fields. I’d been storing passwords as MD5 hashes; FDS supports this, but the storage format of the hashes was not compatible. FDS’s website has links to user contributed scripts to solve this, but they didn’t seem to work for me. Again, having a small organization was useful, as I was able to change the default storage type to something more compatible (eg, SHA, SHA1, CRYPT, etc) and have my users update their passwords. Voila! Updated password formats. Once all this was completed, I simply pointed LDAP clients to the FDS instead of the old OpenLDAP and everything just worked!

Overall, my migrations were pretty smooth. Your mileage may vary, but if you need the features, or just yearn to run on updated software, the migration is well worth it.