[itdiscuss] Of Mac, Active Directory and .local

Sun Oct 23 07:06:37 EDT 2011

Yeah we have recently continued joining macs to the domain however we
don't use network accounts to login.  This was where most of our
troubles were.  As most of our machines have 1 primary user, we set a
local account for them to login with, and the reason for binding it to
the domain, is simply to track the computer account in AD, and to
populate ldap searches like address book etc. 

Most of our mac users don't have much need for network shares and those
that do, we just help and train them as needed.  I guess it depends on
how many  computers/users you're working with.

Kind regards - Andrew Huddleston | IT Systems Engineer | Hillsong Church
| 02 8846 4800

From: Jason Powell [mailto:jpowell at gccwired.com] 
Sent: Wednesday, 19 October 2011 11:50 AM
To: IT Forum
Subject: Re: [itdiscuss] Of Mac, Active Directory and .local

We're now 63% of our staff on macs ... will prob be 80%+ next year. No
management nightmares and people connect to shares and printers as
needed. We don't have users sharing mac (or win machines for that
matter) so that helps.

The beauty of church IT ... solutions are not 1 size fits all :-)

From: "derek.schwab at jfbc.org" <derek.schwab at jfbc.org>
Reply-To: IT Forum <discuss at itdiscuss.org>
Date: Tue, 18 Oct 2011 23:45:42 +0000
To: IT Forum <discuss at itdiscuss.org>
Subject: Re: [itdiscuss] Of Mac, Active Directory and .local

Best practice it to use a real domain name or subdomain of a real
domain.  Of course, redoing an existing domain, especially a larger one
is pretty much an impossibility.

Another option is just to disable Bonjour.  It won't work properly on
most enterprise networks with multiple VLAN's anyway.

I have to completely disagree with not joining to AD - That's a
management nightmare - Causes lots of issues with connecting to network
drives etc, since you wouldn't have Kerberos authentication and
everything would need to be in the keychain. Also doesn't really work
when you have shared computers where multiple users might log into the
same machine or multiple machines - you'd have to create an account for
every user on every machine.

-Derek

From: Jason Powell [mailto:jpowell at gccwired.com] 
Sent: Tuesday, October 18, 2011 7:40 PM
To: IT Forum
Subject: Re: [itdiscuss] Of Mac, Active Directory and .local

Or another option ... don't bother with joining your macs to AD.
Working well for us ;-)

From: Bobby Stewart <bStewart at brentwoodbaptist.com>
Reply-To: IT Forum <discuss at itdiscuss.org>
Date: Tue, 18 Oct 2011 23:18:06 +0000
To: IT Forum <discuss at itdiscuss.org>
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
+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.plis
t". 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/

_______________________________________________ it discuss mailing list:
discuss at itdiscuss.org Mailing List: http://itdiscuss.org/discuss
Internet Relay Chat: irc://irc.freenode.net/citrt 

_______________________________________________ it discuss mailing list:
discuss at itdiscuss.org Mailing List: http://itdiscuss.org/discuss
Internet Relay Chat: irc://irc.freenode.net/citrt 

________________________________________________________________________
The material contained in this email may be confidential, and may also
be the subject of copyright and/or privileged information. If you are
not the intended recipient, any use, disclosure or copying of this
document is prohibited. If you have received this document in error,
please advise the sender and delete the document.

This email communication does not create or vary any contractual
relationship between Hillsong and you. Internet communications are not
secure and accordingly Hillsong does not accept any legal liability
for the contents of this message.

Please note that neither Hillsong nor the sender accepts any
responsibility for viruses and it is your responsibility to scan the
email and any attachments.

Hillsong
www.hillsong.com

________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://optimus.thompsonic.com/pipermail/discuss/attachments/20111023/f8307758/attachment-0001.html>