[itdiscuss] Of Mac, Active Directory and .local

Wed Oct 19 13:24:55 EDT 2011

OK!!! This is definitely good news... at least for us and our network (your mileage may vary). Preliminary results are good! We added the ability for Domain Users to log into the machine which would require the Mac to access the directory to determine membership status and authenticate. They have and they are allowed to log in.

The next step is to access shared resources. They have and the response is snappy. It finally looks like our Mac users have a way to access domain resources without the pain we have experienced in the past.

A good outcome with this is that access to resources can be unified and password security policies enforced.

Bobby Stewart
Network Analyst
Brentwood Baptist Church
Brentwood, TN
www.brentwoodbaptist.com
+1 (615) 324-6149 office
+1 (615) 830-0012 cell

From: Dayron Daugherty [mailto:ddaugherty at precept.org]
Sent: Wednesday, October 19, 2011 8:41 AM
To: discuss at itdiscuss.org
Subject: Re: [itdiscuss] Of Mac, Active Directory and .local

I recall a .local domain name (or any .nonvalidDNSname) recommended for internal domain back in the intro of AD having to do with security concerns, and potential routing and DNS problems if your company already had a large public internet presence and recommended a .local (or whatever internal name). It wasn't an MS source. But I do remember a Microsoft book that mentioned not using your top level internet domain as your internal name space (and using the .local as an example as stated earlier in the thread). It was a Windows 2003 book if I recall. It's been a long time. I've read about issues where people have used the top level domain internally, but the way around that is use something like whatever.yourdomainname.com as your internal name space and just don't setup public DNS records for it.

From: J.R. Pitts [mailto:jrp at wjponline.com]<mailto:[mailto:jrp at wjponline.com]>
Sent: Wednesday, October 19, 2011 1:16 AM
To: discuss at itdiscuss.org<mailto:discuss at itdiscuss.org>
Subject: Re: [itdiscuss] Of Mac, Active Directory and .local

I can't remember when Microsoft started warning against .local... whether it was Server 2000 or Server 2003, but yeah, too bad your vendor disregarded your comments.

I don't use the macs myself on a day-to-day basis, so I've never noticed any slowness... but they've seemed fine when I have done stuff on them, and my users haven't complained, so I haven't looked into it at all.

Good luck with your situation; doesn't sound fun.

J.R.

From: Bobby Stewart [mailto:bStewart at brentwoodbaptist.com]<mailto:[mailto:bStewart at brentwoodbaptist.com]>
Sent: Wednesday, October 19, 2011 12:55 AM
To: discuss at itdiscuss.org<mailto:discuss at itdiscuss.org>
Subject: Re: [itdiscuss] Of Mac, Active Directory and .local

Also, it may have been more than eight years ago that we originally constructed our current domain naming scheme. I think was when we first got "real" servers instead of Desktop PCs running NT4 with two PDCs and Exchange 5.5 (don't look at me that way, I inherited it!). Ah, the good ol' days!

Bobby Stewart
Network Analyst
Brentwood Baptist Church
Brentwood, TN
www.brentwoodbaptist.com<http://www.brentwoodbaptist.com>
+1 (615) 324-6149 office
+1 (615) 830-0012 cell

From: J.R. Pitts [mailto:jrp at wjponline.com]<mailto:[mailto:jrp at wjponline.com]>
Sent: Tuesday, October 18, 2011 9:31 PM
To: discuss at itdiscuss.org<mailto:discuss at itdiscuss.org>
Subject: Re: [itdiscuss] Of Mac, Active Directory and .local

I don't know when you created your domain, but Microsoft has been recommending against using .local for internal domains for over 8 years for just this reason; if your domain is newer than that, then it's unfortunate that whoever designed/installed your AD didn't follow suggested "best practices".

But since you're in this position, I concur with the other's suggestion of not adding the macs to the domain. I'm not sure why you consider connecting macs to smb shares painful, unless you're referring to password changes? It's a pretty simple process.

I do feel your pain though.... If I had my way we wouldn't have macs on our network at all.

J.R.

From: Bobby Stewart [mailto:bStewart at brentwoodbaptist.com]<mailto:[mailto:bStewart at brentwoodbaptist.com]>
Sent: Tuesday, October 18, 2011 7:18 PM
To: IT Discussion Forum
Subject: [itdiscuss] Of Mac, Active Directory and .local

We've been battling connectivity issues for our Macs in our Active Directory domain. We ran across it today trying to join some new OS X Lion systems to our .local domain.

This was written specifically for the Centrify product but I think you'll see that the same should apply to OS X systems that do not use the Centrify product as well.

Bobby Stewart
Network Analyst
Brentwood Baptist Church
Brentwood, TN
www.brentwoodbaptist.com<http://www.brentwoodbaptist.com>
+1 (615) 324-6149 office
+1 (615) 830-0012 cell

>From Lance McAndrew of Centrify
http://bit.ly/nuQrPj

After installing the Centrify DirectControl 4.4.3 agent on Mac OS 10.7, the following issues are observed:

1)      If the home directory is located on a SMB share, it will take a long time time to login.

2)      If a Centrify user logs in and tries to mount a SMB share folder in Finder, it will take a long time to login.

3)      Centrify may be in disconnected mode (adinfo -V on a terminal).

Cause:
The problem exists on Mac OS 10.7, because 10.7 always uses Bonjour first to resolve any .local hostname. If Bonjour fails (timeout), it will then use standard DNS, thus causing the delay.

For Mac, the .local domain is reserved for Bonjour, and the Mac will only lookup these hostname using Bonjour (multicast). On Mac OS 10.7, a hostname that contains only one level under .local (i.e. xxx.local) is resolved using multicast, other hostnames are resolved using both multicast and unicast (multicast first). It will try several times with a timeout (default 5 seconds for each try). If the host cannot be resolved, then it will try unicast. This is the reason for the mount delay.

Under these conditions, it may not be possible to ping domain.local, therefore adclient will stay in disconnected mode for up to 60 seconds after start.

Workaround:
NOTE: The following steps require root or sudo privileges. Customers are advised to take a backup of the original files in an alternate location to avoid any mistakes when editing these files.

Step 1:
The below step forces Mac 10.6/10.7 to do both multicast and unicast query to xxx.local. On the DNS server (AD or Unix), create a primary zone "local". You do not need to modify it. Just SOA (Start of Authority) needs to exist in this zone. After configuration, restart mDNSResponder on the Mac by running # sudo killall mDNSResponder. Then you should be able to ping domain.local.

Step 2:
Mac 10.7 always does both IPv4 and IPv6 query. Disabling IPv6 won't stop the Mac from doing IPv6 query, but it improves performance. Unfortunately you cannot disable IPv6 from System Preferences and so you need to manually edit the /Library/Preferences/SystemConfiguration/preferences.plist on the Mac.

Find the network adapter (Ethernet or Airport) under NetworkServices key, then edit the IPv6 setting and change the config method to "__INACTIVE__":

<plist version="1.0">
<dict>
<key>CurrentSet</key>
<string>/Sets/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</string>
... ...
<key>NetworkServices</key>
<dict>
<key>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</key>
<dict>
... ...
<key>IPv6</key>
<dict>
<key>ConfigMethod</key>
<string>__INACTIVE__</string>
</dict>
... ...

Step 3:
There's no way to change the DNS lookup order, so what we can do is to reduce the multicast DNS timeout by editing mdns_timeout in "/System/Library/SystemConfiguration/IPMonitor.bundle/Contents/Info.plist". The default setting is 5. Set mdns_timeout to 0 by editing the /System/Library/SystemConfiguration/IPMonitor.bundle/Contents/Info.plist and changing the value to 0 as shown below:

<key>mdns_timeout</key>
<integer>0</integer>

Step 4:
If you set mdns_timeout to 0, then you won't be able to ping any ".local" host/domain, but other apps such as Finder and Apple's AD plugin work well (it can resolve a .local hostname). You can login as a network home user really fast.

If you try to mount a SMB share in Finder, although it first prompts that there's a problem connecting to the server, eventually it will connect if you wait for several seconds and retry. This prompt can be solved by adding the machine that hosts the DNS server and Windows share into /etc/hosts file on the Mac:

192.168.x.x server.domain.local
192.168.x.x anotherserver.domain.local

where 192.168.x.x is the IP address of the DNS server in your organization.

NOTE: As you cannot ping domain.local, adclient will stay in disconnected mode for up to 60 seconds after start (which means you need to wait for more than 1 minute after reboot). Adding domain.local into /etc/hosts solves the disconnect issue.

Step 5:
You need to REBOOT the Mac after performing steps 1) through 4).

Step 6:
Login to Mac and you should not see any delay during login. Also you should not see any delay when mounting a SMB folder in Finder.

Resolution:
None. This is an Apple Bug. Centrify opened a Bug 9887516 as well and we provided the above steps as a workaround after testing in the lab. For more information on Bonjour and how it works, please refer to the link from Apple:

http://www.apple.com/support/bonjour/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://optimus.thompsonic.com/pipermail/discuss/attachments/20111019/1869fa49/attachment-0001.html>