+ Post New Thread
Page 4 of 4 FirstFirst 1234
Results 46 to 50 of 50
Mac Thread, mac will not log on in Technical; This is a general post aimed at everyone who has a .local domain and is still frustrated with the Active ...
  1. #46

    Ephelyon's Avatar
    Join Date
    Aug 2008
    Location
    Cheshire, England
    Posts
    1,656
    Thank Post
    283
    Thanked 318 Times in 192 Posts
    Rep Power
    141

    Lightbulb Potential fix

    This is a general post aimed at everyone who has a .local domain and is still frustrated with the Active Directory authentication issue on Snow Leopard, i.e. where at least 50% of the time the Macs will fail to authenticate AD users following a reboot and display "This domain is not responding" in Accounts -> Login Options. I haven't seen any other definitive fixes for this problem yet, so I thought I'd post something that works 100% for us.

    The problem, as I understand it, comes down to Apple's buggy Multicast DNS Responder implementation (the processes "mDNSResponder" and "mDNSResponderHelper"), whereby .local domains conflict with the Bonjour service and the KDC(s) for the Windows domain can't be resolved, causing authentication to fail. None of the multitude of "fixes" I've seen posted so far have had much success at my workplace, e.g. adding .local to the DNS domain search path, increasing the mdns_timeout value, adding the nameservers / domain controllers to /etc/hosts or setting the AD preferred server to the IP address of a domain controller.

    As the problem only rears its ugly head when a machine is rebooted (for us), the logical choice for a guaranteed automated fix is to create a StartupItem. Unbinding and rebinding to the domain will fix the problem, but apart from being messy, laborious and causing problems with managed computer preferences mapped to AD computer accounts, which then change, this sometimes fails when automated from the CLI over a period of time, with computer accounts not being successfully recreated and etc. So that's out.

    Killing the mDNSResponder process is also known to work well, but occasionally fails. Changing any form of DNS setting (to a different value and then back to the old one) will fix it sometimes as well, but neither of these methods work 100% of the time. It therefore seems logical to have our StartupItem shell script use a While Loop to keep repeating the action until the domain is recognised as available again, testing for connectivity in between. Restarting the responder is the most effective option of the two, but killing its process too often (as the Launch Daemon will automatically respawn it) sometimes goes wrong and the process is somehow "permakilled" until reboot - at that point, all DNS resolution goes down the drain and a number of other critical system functions will also begin to fail.

    This leaves changing a DNS setting. The one I've picked (setting the domain search path to the .local domain in question, which is probably the right setting for most deployments anyway) can be done as many times as you like without causing problems, and while it may typically take over 100 attempts to fix the problem, this normally doesn't last more than about 30 seconds for us. I've just told our users to give the machine around 30 seconds from when it displays the login window before trying it, and they're fine with that. All our Macs now work first time, every time with no problems.

    To create this StartupItem, create the following directory as root:

    /Library/StartupItems/FixADAuth

    Then chown it to root:wheel and chmod it to 755. These must also be the owner/permissions on the two files it will contain, below:

    Contents of our /Library/StartupItems/FixADAuth/FixADAuth:

    #!/bin/bash
    . /etc/rc.common
    date > /var/log/FixADAuth.log
    n=0
    AuthSuccess=0
    while [ $AuthSuccess != 1 ]
    do
    id Administrator && AuthSuccess=1 || networksetup -setsearchdomains Ethernet "Empty"; networksetup -setsearchdomains Ethernet middlewich.local; n=$(($n+1))
    done
    echo Authentication successful: $AuthSuccess >> /var/log/FixADAuth.log
    echo Operation count: $n >> /var/log/FixADAuth.log
    date >> /var/log/FixADAuth.log

    Contents of our /Library/StartupItems/FixADAuth/StartupParameters.plist:

    {
    Description = "Fixes Active Directory authentication issue";
    Uses = ("Disks");
    }

    Obviously you'll need to change "middlewich.local" to your own domain name (and the network interface name if your connection is wireless). The script checks to see if it can see the user "Administrator" on the domain, as he's a fairly common bloke, but if you've renamed yours for security reasons then pick another one. I've also included some logging functionality for debug purposes, so you can verify how well the script is working if you need to and time it in your environment before telling the users how long to wait. The /var/log/FixADAuth.log file will contain the date/time the process started, the success variable set to 1 (just to verify), how many DNS operations were required to fix the problem, and the date/time it ended. For us the time difference is normally about +30-40 seconds with around 120-180 operations taking place. Once you're happy with the script, you can strip it down to its bare functionality if you like, like so for us:

    #!/bin/bash
    . /etc/rc.common
    AuthSuccess=0
    while [ $AuthSuccess != 1 ]
    do
    id Administrator && AuthSuccess=1 || networksetup -setsearchdomains Ethernet "Empty"; networksetup -setsearchdomains Ethernet middlewich.local
    done

    I hope this helps someone!

  2. #47
    PEO
    PEO is offline
    PEO's Avatar
    Join Date
    Oct 2007
    Posts
    2,093
    Thank Post
    457
    Thanked 150 Times in 95 Posts
    Rep Power
    71
    Hi this script comes back with an error 'Expected end of line, etc. but found unknown token.'

    can you help?

  3. #48

    Ephelyon's Avatar
    Join Date
    Aug 2008
    Location
    Cheshire, England
    Posts
    1,656
    Thank Post
    283
    Thanked 318 Times in 192 Posts
    Rep Power
    141
    I know the script works as it's been copied and pasted directly and success has been reported from other users in this thread:

    Snow Leopard AD Integration woes

    Please check to ensure you have entered the code 100% accurately.

  4. #49
    Carter's Avatar
    Join Date
    Sep 2010
    Location
    Canada
    Posts
    269
    Thank Post
    10
    Thanked 64 Times in 41 Posts
    Rep Power
    18
    Some of this has been posted in the thread buy figured I'd share my findings on this since I did a fair bit of research on this last year. I had it posted on my blog here TwistedMac - Fix/Solution for using Mac OS X with AD authentication

    ~~~~~~~~~~~~~~


    Fix/Solution for using Mac OS X with AD (Active Directory) authentication

    ISSUE
    For sometime now we have had an issue with the Macs keeping bound to AD (Active Directory). For some reason they lose the ability to authenticate which would usually happens after a couple weeks of a Mac being bound to AD.
    This has been pretty consistent for over a year now, which has prevented us from using AD for user authentication. In turn we had to go to using a local “Student” user on the Macs but with a local user we lose the ability to track printing with PCounter and the tracking of users login info.

    CAUSE
    You should only be having this issue if you are using the following together:

    • Mac OS X 10.5+
    • AD (Active Directory) for Authentication
    • Faronics Deep Freeze

    What I found online is that there is a 14 day password renewal period that is a standard 'recommended' by Microsoft in order to keep a good level of trust between client computers and Active Directory server(s).
    For everyday use this is not something to worry about but in a lab setting that uses Faronics Deep Freeze the 14 day password renewal will cause issues. When a Mac is bound to an AD server a private unique key is created between the two. Due to the default 14 day password renewal the Mac looks to the AD server to renew this key but if frozen this key does not get changed and in turn, though the status of AD still shows green and functional users will not be able to authenticate with an AD account.
    If you do not run Deep Freeze you will not experience this issue.

    SOLUTION
    To solve this issue there are three solutions:

    1. Disable or uninstall Deep Freeze.
    2. With an individual client/image install, you can run the following Terminal command that will change the password expiration time. dsconfigad -passinterval 0
    Setting the system to a password renewal period of “0” ignores the need to check the authenticated account that binds the client Mac to AD and requesting a new private key.
    3. If you are using Deploy Studio for lab imaging you just need to set the “Password Change Interval” by using the ‘Active Directory binding task” found in the Deploy Studio Workflow options as seen in the following image.


    MY TEST
    For my test I imaged 12 Macs in our common area. Prior to this test I was un-binding & re-binding all of these Macs to AD aprox. every 2 weeks so that students could continue to print from their credited account. Since I reimaged these computers with the “Password Change Interval” set to “0” I have not had one computer drop from AD and lose the ability to have users login with AD credentials. ** In short, if you are running Mac, AD & Deep Freeze you need to set the password expiration time to “0” to prevent AD authentication from breaking.

  5. #50

    Ephelyon's Avatar
    Join Date
    Aug 2008
    Location
    Cheshire, England
    Posts
    1,656
    Thank Post
    283
    Thanked 318 Times in 192 Posts
    Rep Power
    141
    This is a very helpful solution, but unfortunately it's for a different issue. In our case, the Macs are losing their connection to AD on most, if not all, restarts. You've clearly done a lot of work on this though.

    What's Deep Freeze then?

SHARE:
+ Post New Thread
Page 4 of 4 FirstFirst 1234

Similar Threads

  1. Mac will not log onto network
    By training_needed in forum Mac
    Replies: 8
    Last Post: 29th March 2010, 02:01 PM
  2. Replies: 15
    Last Post: 24th November 2009, 11:17 AM
  3. Replies: 7
    Last Post: 27th August 2009, 11:20 PM
  4. clear old cookies on log off (or log on)
    By ZeroHour in forum Scripts
    Replies: 0
    Last Post: 4th November 2008, 09:32 AM
  5. Can log on Local can't log on to domain
    By speckytecky in forum Network and Classroom Management
    Replies: 16
    Last Post: 25th April 2008, 12:05 PM

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •