Kyle Brandt » Windows / Exchange

Non-Exchange Active Directory Users and the Global Address List

Kyle — Fri, 10 Apr 2009 15:03:56 +0000

The Problem
I have some users who are on a different mail system but still part of my company. The problem was that the users without Exchange 2003 accounts were not showing up in the Global Address List (GAL).

Solution
The first step was to look at the LDAP filter that generates the GAL. This can be viewed by going into the ‘Exchange System Manager’ and then ‘Recipients::All Global Address Lists::Default Global Address List::General Tab’. The following is the filter on my Exchange system (which I am guessing is the default ):


(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=contact))(objectCategory=group)(objectCategory=publicFolder)(objectCategory=msExchDynamicDistributionList) ))

Looking at this filter, and not being rain man, I couldn’t just glance at and figure out what it meant. The trick was to load it with VIM, because it will highlight matching parenthesis (When your cursor is over the opening parenthesis, the match closing parenthesis gets highlighted). I then I indented based on that which resulted in:


(&
   (mailnickname=*)
   (|
      (&
         (objectCategory=person)
         (objectClass=user)
         (!(homeMDB=*))
         (!(msExchHomeServerName=*))
      )
      (&
         (objectCategory=person)
         (objectClass=user)
         (|
            (homeMDB=*)
            (msExchHomeServerName=*))
      )
      (&
         (objectCategory=person)
         (objectClass=contact)
      )
      (objectCategory=group)
      (objectCategory=publicFolder)
      (objectCategory=msExchDynamicDistributionList)
   )
)

The next step was to look at the active directory key value pairs for for one of the users that wasn’t showing up in the GAL. I know of two ways to do this, one is to use adsiedit.msc for windows, or, if you want to be super cool, use ldapsearch in Linux. To use ldapsearch to look at the attributes for the object, you would use a command like: ldapsearch -w $PW -v -x -D "cn=Administrator,cn=Users,dc=myDomain,dc=com" "cn=Kyle Brandt" where ‘Kyle Brandt’ is the user you want to look at, Administrator is the user you use to authenticate with AD, PW is a shell environment variable with you password, and myDomain is your company’s AD domain name.
Once I saw that mailNickname was not set, and since the filter says ’show in GAL if mailNickname is set to something, OR if … lots of stuff …’ all I had to do was use adsiedit to set that attribute to something. To learn how to read and write these filters see this rfc or this msdn page. You can see if the change will effect the GAL book by clicking ‘Preview’ on the tab were the filter originally was. It will probably take a day or so (depending on your settings) before the change is actually made to the GAL.

Moving a Front-End Exchange 2003 Server into your DMZ

Kyle — Mon, 02 Feb 2009 23:13:57 +0000

Introduction:
A common practice in networks is to have at least two Exchange servers, a front-end server in the demilitarized zone (DMZ, perimeter network in Microsoft terminology) and a back-end server in the company’s main network. The front-end server hosts the public SMTP server and web mail. The back-end server hosts the actual mail (information stores). There are two firewalls, one between your DMZ and your own network, and the second is between the DMZ and the Internet.

Although the firewall rules are well documented on the web, I ran into a couple of blocks when moving the Exchange front-end server into the DMZ. I hope in sharing what I encountered helps others find doing the same thing a little less frustrating. My instructions will be specific to my experience in doing this, and is certainly not the only way to do it.

Planning the Firewall Rules:
As I mentioned in previously there are two firewalls in this setup. One is between the Internet and the DMZ and the other is between the DMZ and the internal network. In this example both the firewalls are just the Access Control Lists ( ACLs ) on the Internet interface and the DMZ interface of a Cisco router. The the front-end server is also behind Network Address Translation ( NAT ), so the server gets assigned a local IP.

The logical layout is how to think about the set up. Firewall 1 is actually an inbound ACL on the Gig 0/0 interface and Firewall 2 is and inbound ACL on the Gig 0/1 interface. In this usage of inbound, ‘in’ means heading into the interface ( see the actual layout ) and not ‘inbound’ in the sense of inbound traffic from the Internet. Firewall 1 is the firewall between the front-end server and the Internet. Firewall 2 is the firewall between the front-end exchange server and the primary domain controller as well as the back-end Exchange server. The rules on Firewall 2 assume you have bound remote procedure call ( RPC ) to specific port, which I will talk about more in the section about configuring the domain controller. The rules for Firewall 1 use the public Internet IP because that is in front of the NAT, in my example the public IP is 74.125.45.100 and it gets translated to 172.16.1.2 .

Gig 0/0 ACL in ( Firewall 1 ):
permit tcp any host 74.125.45.100 eq 25 permit tcp any host 74.125.45.100 eq 80 permit tcp any host 74.125.45.100 eq 110 permit tcp any host 74.125.45.100 eq 143 permit tcp any host 74.125.45.100 eq 443
Gig 0/1 ACL in ( Firewall 2 ):
permit tcp host 172.16.1.2 host 10.10.1.51 eq 25 permit tcp host 172.16.1.2 host 10.10.1.51 eq 80 permit tcp host 172.16.1.2 host 10.10.1.51 eq 143 permit tcp host 172.16.1.2 host 10.10.1.51 eq 110 permit tcp host 172.16.1.2 host 10.10.1.51 eq 691 permit tcp host 172.16.1.2 host 10.10.1.50 eq 88 permit udp host 172.16.1.2 host 10.10.1.50 eq 88 permit tcp host 172.16.1.2 host 10.10.1.50 eq 389 permit udp host 172.16.1.2 host 10.10.1.50 eq 389 permit tcp host 172.16.1.2 host 10.10.1.50 eq 3268 permit tcp host 172.16.1.2 host 10.10.1.50 eq 53 permit udp host 172.16.1.2 host 10.10.1.50 eq 53 permit tcp host 172.16.1.2 host 10.10.1.50 eq 135 permit tcp host 172.16.1.2 host 10.10.1.50 eq 12125

Active Directory Changes:
There were three changes I had to make in Active Directory. The first was to change the DNS entries for the mail servers. The second, which took me sometime to figure out, was to add the subnet to ‘Active Directory Sites and Services’. I had to do this because this was the first Windows server being deployed in the DMZ. To do this go to Control Panel :: Administrative Tools :: Active Directory Sites and Services :: Right-Click Subnets :: New Subnet and then for our example add ‘172.16.1.1/24′ and assign to whatever site it it is in. You may also need to give it time to replicate. The third change is to bind RPC replication to a specific port so you don’t have to open the firewall between the front-end and back-end servers as much. I chose to bind it to port 12125, if you don’t do this you will have open up TCP ports 1024 and above on the firewall. To bind RPC you need two registry entires, see: http://support.microsoft.com/kb/224196

Changes on the Front End Mail Server:
Besides Assigning the new IP to the front end exchange server, you might need to bind each service to this new IP. This wasn’t apparent to me because I could still connect to the SMTP and 443 ports but I got disconnected immediately. This indicates that even though the service is set not to be listening on that IP, it does listen and just disconnects if the first packets of the session are not destined for the IP the service is bound to. I can’t image how someone at Microsoft thought that this would be a good way to design the network stack on their operating system but that seems to be the way it works. To adjust what IP webmail (ports 80 and 443) are bound to, go to: Control Panel :: Administrative Tools :: Internet Information Services ( IIS ) Manager :: Local Computer :: Web Sites :: Right Click which ever web sites is for web mail :: Web Site Tab and then change the IP to whatever the new IP is for your front-end server, in our example, 172.16.1.2. Then to change the SMTP port and other service are bound to, go to: Exchange System Manager :: Administrative Groups :: Your Administrative Group ( i.e. First Administrative Group ) :: Servers :: The Front-End Server :: Protocols and then expanded each protocol, right click the virtual server, and change the IP in the General Tab.

Changes on the Back End Mail Server:
When I did this I did not have to make any changes to the back end server, but you can check the references section for things you may need to do. Also, this is windows, so you should probably reboot the server for good measure, and maybe several times.

Conclusion:
Although your experience may be different I hope this helps people trying to do a similar thing.

References:
http://technet.microsoft.com/en-us/library/aa997436(EXCHG.65).aspx
http://windowsitpro.com/article/articleid/46571/what-ports-do-you-need-to-open-to-allow-communication-between-a-microsoft-exchange-server-back-end-server-and-an-exchange-front-end-server.html

Authenticating with Active Directory using Likewise Open and Migrating from NIS

Kyle — Thu, 20 Nov 2008 13:55:00 +0000

The current infrastructure at my office uses network information services (NIS) to authenticate users on Linux machines against the office’s Window’s domain. I found this to be unreliable. It depends upon Microsoft Identity Management for Unix, version 5.2, which is flaky in my experience.

My goal was to be able to transition from NIS to authenticating directly with Active Directory (AD) smoothly. I also wanted to maintain the shared home directories that reside on a network file system (NFS) server. The solution I have chosen is Likewise Open, I have found it very easy to set up while still being customizable. In order to maintain the shared home directories I have just taken the automount configuration out of NIS and put it locally on each machine. Even though this may not be as centralized I think it is better because the mounts don’t depend upon Microsoft’s Unix Identity Management.

The following are the steps I took to set this up. Likewise has good documentation so I recommend you look at that before you follow my steps. I am deploying this as I rebuild machines with Centos 5.2 which makes the process a little neater (If you want to transition current machines you will probably need to google nsswitch.conf):

When deploying Centos be sure to set up Network Time Protocol (NTP) during the installation because Kerberos authentication depends on approximate clock synchronization between the client and the server.
Download and install Likewise Open (as root):
a) wget http://www.likewisesoftware.com/bits/Fall08/3895/LikewiseIdentityServiceOpen-5.0.0.3895-linux-i386-rpm-installer
b) chmod +x LikewiseIdentityServiceOpen-5.0.0.3895-linux-i386-rpm-installer
c) ./LikewiseIdentityServiceOpen-5.0.0.3895-linux-i386-rpm-installer
Join the domain (as root):
a) /opt/likewise/bin/domainjoin-cli join mydomain.com administrator
b) Where administrator is a user with privileges to join a computer to the domain
Customize Likewise to use the mounted home directories (automount of home directories explained in step 5). It is important to do this before logging in, because once users have logged in you can’t change the home directory without reinitializing likewise:
a) in /etc/likewise/lsassd.conf edit the following:
i) Change the homedirecy path: homedir-template = %H/users/%U
ii) Make sure it doesn’t mess up a home directory: create-homedir = no
iii) Make it so when logging in the domain does not have to be specified: assume-default-domain = yes
iv) Changed the shell to bash: login-shell-template = /bin/bash
Set up automount to mount people’s home directories which live on a NFS server:
a) Add the following to /etc/auto.master: /home/users /etc/auto.home –timeout 60
b) Create auto.home and enter the following into the file: * -rw [nfs_server_ip]:/dir_where_homes_are/&
c) restart autofs: /etc/init.d/autofs restart
d) The home directories will not appear until you change directory into them, hence automount
Migrate from NIS:
a) After a successful login with a windows username type the id command and note the users UID number. The UID number is what Unix cares about, the name isn’t important. The UID that Likewise generates is a hashed version of the Windows SID.
b) Log into your Windows domain controller. Click the user properties and then in the “Unix Properties” tab change the UID to match what Likewise generated. This way servers that are still on NIS will be consistent with Likewise Open.
c) Reown the users home directory with the new UID: chown -R [UID] /home/users/[user]
Optional: Change users shell
a) Since everyone with Likewise uses the same shell, if you like a different shell like zsh you can put the following in /home/users/[user]/.profile : if which zsh; then; exec zsh; fi
b) The exec command replaces the current shell with whatever command you specify, so you won’t be running zsh within a bash process.