mac will not log on

[BootManager]

Regarding my DNS rebuild.

I am writing these notes down now so that I dont forget what I did when I post an update on how my network is behaving (probably in a few weeks time).

 

My feeling is that our windows network was fine for PC clients but macs, being extremely fussy, didnt like it. I rather suspect the apple have just done some minimal testing as far as integrating into windows environments is concerned and therefor if your network isnt 'just so' then your macs are going to go into a huff, ......did I mention about the hassle with using macs on our expensive and sophisticated network environment - the upshot was that we had to 'dumb-down' our switches in order to accommodate the picky macs with network card drivers that dont conform to internationally recognised networking standards [and Apple think its not their problem].

 

Anyway this is what I've done to our servers and I am still monitoring the situation, so dont take it as gospel....

 

Most of the client computers had been switched off over easter so the DNS records would have mostly been stale - the DNS was going to be flushed and rebuilt so it was to our advantage too.

 

First step make sure all the servers (windows and OS X) are updated with patches, and BACKUP system state.

Second step, refresh my brain on how to configure DNS & DHCP, I'm a great believer on setting things up with the instructions in front of me, then hopefully I wont need to look at for at least a few years.

Third step clear down DNS and de-integrate it from active directory. Then stop the service and delete all traces of DNS in AD or text file.

Fourth, check DHCP, reconfigure if neccessary

Fifth, configure the servers and get them all talking and behaving nicely with one another.

Next, rebuild DNS and replicate across servers, check DNS contains correct records and register any machines with static IPs.

Next get the windows client PCs back onto the network, well logon to an AD account cos you just know they are gonna work

Finally reconfigure each mac client (our machines are dual boot), this is the tedious bit involving coming off the domain, clearing down plists, renaming, rebooting, rejoining domains etc, hoping that things get finally sorted.

 

some reading (do read them):

How to clear bad information in Active Directory-integrated DNS

How to reinstall a dynamic DNS Active Directory-integrated zone

How to configure DNS dynamic updates in Windows Server 2003

How To Install and Configure a DHCP Server in a Workgroup in Windows Server 2003

there are other articles, you can take days to read, but I'd decided that I was going to rebuild DNS so they were irrelevant to me.

 

oh I'm too long on my text, read my next post....

[BootManager]

(continued)....

what I found after doing some reading was that our DNS was probably in a bit of a mess from upgrading the server from win 2000 to win 2003 some years back and also from having various experts come in and allowing them to hack about, particularly when they manually add records to windows DNS from their client machines (eg a mac server). The DHCP settings were also messed about with, probably by external 'experts' like half-setting-up range policies when in fact the top level server policy had all the relevant settings already set up. But I also found that our Active Directory was 'old' and needed to upgrade to Win 2003 (a single mouse click operation).

 

The articles on DNS are fairly straightforward though I found that some things didnt apply to our setup here and there were a couple of minor panics when I thought I'd done some damage, but as it turned out everything was really quite easy, you just have to plan it out.

I'm not going to go into massive detail, most of the actions are performed from menu options or right mouse clicks, you do need to feel your way around the DNS structure but most actions are performed on the 'server' container and not the zones (which were getting deleted). I think that the steps that I took [on each DC server] were to:

1) break the replication across the servers by setting DNS to standard primary on each server and make sure there is no cross referencing of servers.

2) from the dos prompt use command "ipconfig /flushdns" to flush cache, then after a couple of minutes to go into DNS console and just delete all the A and PTR records for each zone, then note down all the C records (because you will need to recreate them), before deleting each zone in the forward and reverse containers (I also found/deleted a top level _msdcs_ zone that I think was supposed to be a child of a named zone - can these things be moved?!?)

3) clear out the DNS events log, then come out of DNS console. another flush of the dns from the dos prompt, and then stop the DNS service (net stop dns).

4) The microsoft documentation talks about deleting zones from within Active Directory but I couldnt see where any old records were kept, however I did find that there were some old files in the folder c:\windows\system32\dns, (these have the extension .dns) so I moved the ones that obviously belonged to us out of the way to a new folder [ I left behind cache.dns and dns.log and the folders Samples and Backup ].

5) Network Connection Settings. I had some conflicting info on this change but what I opted for was for each network connection on our nominated DNS servers to make sure that if its a static IP then the network settings has preferred DNS pointing to itself, ie a server with replicated DNS doesnt point to the primary DNS server instead, the alternate DNS was set to point to the internet service providers DNS. In case you are interested conflicting arguement was pretty much the exact opposite ie to point to the primary DNS and the alternate DNS to point to a secondary internal DNS - but I'll monitor what happens as I can always change these settings at a later date.

6) configure DHCP service on the machine where it resides. I didnt have to do much to ours but I changed a couple of settings out of interest, on the general tab "enable DHCP audit logging" ticked, on the advanced tab "conflict detection attempts" set to 1, and on the DNS tab everything ticked (I selected "always dynamically update DNS A and PTR records" on the option) . Although I didnt delete any records, you may want to tidy things up if you know some leases have expired, you can select the Reconcile action to give a little peace of mind afterwards. One thing which I did do was delete the scope options that someone had half-heartedly set up on the main scope - on our DHCP server these options are correctly set up in the global options and therefore do not need any overriding (or messing up).

7) when all servers are stripped of dns operations then reboot each server, except for the mac servers - which got taken off the windows AD domain and then shut down.

8) The DC servers get booted first, the other servers get booted after you set up DNS.

9) IMPORTANT NOTE: On the Primary DC in Active Directory a right click >properties, on the domain name revealed that our Domain Functional Level was set to Windows 2000, but a simple mouse click allowed this to be upgraded to Windows 2003 (an upgrade that cannot be reversed). I feel this is an important issue because it shows that the AD is being made overly complicated by trying to retain compatibility with Windows 2000 or whatever, but since we no longer have Windows 2000 servers I decided to ditch the functionality and upgrade.

10) On the primary DC I setup DNS pretty much using default settings of the DNS wizard (from "Configure Your Server"), there is an option to replicate to all the DCs and you should do that. Give it a few minutes to replicate across your servers. You can also run some tests to check DNS is behaving correctly.

11) On each server with a static IP you should then go to the dos prompt and issue the command "Ipconfig /registerdns", note on the mac servers there isnt really a command to do this but on the macs you can configure IPv4 with the option "using DHCP with manual address" which will register the static IP address in DNS.

12) You can use directory utility to get your mac servers rejoined onto AD; note I did put a tweak on my mac servers (dsconfigad -passinterval 0) as per some earlier recommendation.

13) remember to manually enter any C (alias) records in your DNS, things like which server hosts your website are fairly important.

 

Hopefully thats everything to configure the servers. Thats all I can remember. I wanted a situation where the DNS entries are controlled by windows and tied in with active directory. If you read the microsoft notes it talks about records remaining in DNS if they were manually inserted, ie the owner of the record is not the system, something that I would consider bad news if you want a to go for dynamic updates, and could potentially lead to conflict/duplicates on addresses I think.

I'm sure that there is going to be a whole lot of people out there who are going to criticise my actions, telling me that I cant possible be right, well OK you have your opinions, but solutions like "have you synchronised time" or putting techie tweaks on mac variables are not exactly 'out of the box' and one fact that I think you should chew over before you rush ahead anyway is to consider this:

Some sites that I know of do not have any problems with mac integration. The people who set those sites up didnt go off performing techie tweaks, they just had a bog-standard windows network, freshly built, which they then connected their brand new apple macs to using Directly Utility. AND IT WORKED AND CONTINUES TO WORK.

So all I'm trying to do here is to take away some of the complexity which potentially has been caused through upgrading, upgrading is a nice convenient thing but sometimes its messy. So I've rebuilt my DNS and made some slight changes to DHCP and Active Directory, as far as I'm concerned I'm trying to simplify the network, thats all.

 

Finishing Off

Well this is the moment of truth, which unfortunately I wont find out if its worked until probably a few weeks time.

 

First step, just boot all the windows machines and logon to an AD account, you can probably guess that nothing went wrong with this step. (dual boot macs were booted onto the windows side before even thinking about booting onto the OS X side).

 

On the macs, (dual boot macs were booted onto the windows side before even thinking about booting onto the OS X side), I booted into the local admin account, then did the tedious setup:

1) followed the procedure to get the macs off the AD and OD, deleting directory utility plists afterwards.

2) check the computer name is correct, then check/correct the name of each network connection, the TCP/IP tab should state "Configure IPv4 using DHCP"

3) check for software updates, then reboot. Back into mac (on dual boot machines)

4) rejoin AD and OD, this time I joined OD first of all. Shut down.

5) hope and pray that your mac woes have gone away

 

have I forgotten something - well probably - but do your research. reconfiguring your server can be a bit scary but some times its got to be done.

[BootManager]

An update....

 

well I found out that some of my dual boot macs that got reconfigured now wont log onto windows, it says the domain is not available, fixed this by logging into a local windows admin account, deleting all the local profiles for domain accounts (they all were marked as unknown account anyway), then coming off the domain and finally back on domain.

It seems that although the dual boot win side was originally happy, problems occurred after the dual boot OS X side was taken off the domain (and re-added).

Generally it doesnt bode well. Oh and yet another mac has gone faulty, is there anything more unreliable than an apple-built computer?

[HodgeHi]

Of note, not sure if this is the reason for your machines not finding domain afterwards. You can't have the OS X side client named the same as it's Windows counterpart. When you bind on the OS X side it removes the account from the AD. Then windows cannot join. IIRC that is. I tried this myself only to find it messes up. In the end i decided to use OSX- and XP- prefixes for the names.

 

Also what machines are these? are they the new education alu iMac machines? If so these have the nvidia nforce network chipsets. GPO will not deploy software until you update the nforce chipset drivers. When i get back to work on Monday i will post a link if you like. I say this since this also may be the reason domain is unavailable as they tend to be flippin slow connecting to the domain sometimes. I thought it may have something to do with my network config but the old white Intel ones are as quick as they have always been.

 

Interesting to see what you have tried though to get Macs working as they should.

 

But all of this may just be blah and not related in any way. If this is the case. Sorry

[HodgeHi]

I just found this:

 

Windows 2003 DHCP/DNS server and non-Windows clients

 

May be useful for the DNS issue. Maybe not so much for the problem of not being able to log in. Usually i find this to be due to pre-auth failure. I may look into the passinterval=0 thing myself.

[saplinpoo]

I've just deployed my new AD/OD system out to about 50 macs in the dept, and having this problem!! Generally, things are fine, but usually there are around 5-10 machines (out of 30) in a suite that will not find the AD domain on first boot. Generally a reboot will sort the problem, but a lot of the time it takes a fair few boots before i have both "Network Accounts Available". Not a great problem in a school where it is important that things "just work" straight away!

 

At the same time as me deploying the new mac server in the dept. the main IT network structure has changed and upgraded to Windows 2008 servers. It is only since this change that I have had these intermittent problems. It's such a pain that I get my problems when the mac server and clients are not bound to an RM build anymore!!

 

Based on the problems arising after the Windows 2008 upgrade, the only thing I can blame it on is that changes in 2008 do not bode well for dual directory mac clients. I hoped this article would solve my problem..

 

Mac OS X: Cannot authenticate when Active Directory includes Windows 2008 Servers

 

but it did nothing. Which was a shame as it describes the fault perfectly.

 

So, not a helpful comment to anybody, but I just wanted to join the gang. Hopefully something will arise soon, and I will continue to investigate and update if anything changes!!

[HodgeHi]

First of all you need to find out what version of OS X you have deployed. If it is 10.6.2 have you tried updating to 10.6.3? It may resolve this issue. If this is indeed the version installed then try this.

 

When one fails to find the AD, log in as the local admin. OPen the console and check the logs for any problems around that time. There may be some info in there that could point you in the right direction. If it's a time issue in think it says something like time skew to great. If it's a kerberos issue for the machine account i think it says something like computer failed Pre-auth. If this doesn't lead to anything, then check the dir util. It may bring up further information. I.E it may say not responding. Or in my case, One of the binds may be missing. I have an issue where the OD bind is removed on each reboot of the machine.

 

I don't have a Server 2008 set up so can't help much further than this. But IIRC you can put the Dir Util in to debug mode. Can't remember how though. Check AFP548 or Bombich site for some clues or even Apple's site.

 

Hope this helps in some way.

[AntonioRocco]

Hi

 

@salinpoo

 

Sorry to hear you've having problems. If it's any consolation I've successfully integrated OSX Server and Clients in a Windows Server 2008 R2 AD environment with none of the problems you're seeing. More than once. There is a 30 second or so delay before Network Accounts are available but I think that's a natural consequence of an environment that contains 65000 active nodes. Apart from this it works well as you would expect.

 

@Mark

 

sudo killall -USR1 DirectoryService

 

Enables the DS Debug Log. Once enabled you view the log by lauching Console and selecting /Library/Logs/DirectoryService/DirectoryService.debug.log. Or launching terminal and issuing "tail -f /Library/Logs/DirectoryService/DirectoryService/debug.log". The "tail" command with the "-f" switch displays constantly updated entries to the screen. You use the same command to disable the log. Don't let it go on for too long - 30 minutes or so should be long enough? It can get large fairly quickly if you forget.

 

There's also another command that enables API (Application Program Interface) logging and lasts only for 5 minutes which you may also find useful?

 

sudo killall -USR2 DirectoryService

 

You could also issue this command in another shell:

 

man DirectoryService

 

Which is the manual for DirectoryService and should list all the error codes. These may be useful in understanding the logs? You could also log what DirectoryService does at startup by creating two files (use TextEdit with the Plain Text option) and save them as .DSLogDebugAtStart and .DSLogAPIAtStart. Save them in /Library/Preferences/DirectoryService folder.

 

Restart for logging to take effect.

 

 

It's advisable to not use hyphens when naming mac workstations. This could contribute to what you're seeing? Malformed SRV Records could also be a factor. Double-check they were created properly. I have been to sites where this was the case and macs were losing 'sight' of Directory Services as you've described. Avoid using user names that take this form: firstname.lastname. The full point between the names can cause login problems.

 

HTH?

 

Antonio Rocco (ACSA)

Edited April 18, 2010 by AntonioRocco

[HodgeHi]

That might come in handy for the six weeks me thinks

[saplinpoo]

Thank you for your replies.

 

Today was the first day that students used the environment, so i've been very busy today and haven't looked into any of your solutions, but i'll be sure to get back in the week and let you know how I get on. As a quick fix, i've set the computers not to sleep during the day, so the problem only occurs in the morning. Takes a few reboots on some machines to find both domains, but once it's done, the machine is completely available for the whole day.

 

Somehow I can't see the problem being timeskew. Although I haven't fully investigated this, I can't see why it would connect sometimes and not others? This means that the server or client must be drifting in and out of time, which is unlikely. Correct me if i'm wrong!!

 

And I did an update to 10.6.3 last week in a hope that this would help, and it had no effect whatsoever. Shame really!

[HodgeHi]

I would consult the logs. If it is time skew it will state in the logs. If it is pre-auth it will also mention it in the logs. It could just be that they take a little longer to connect than the others. Also what type of machines are they? Edu iMacs, standard off the shelf iMacs, Mac pros?

 

Also are they dual-booted? If so you could check to find out what network chipsets are used in Windows. Apple's System profiler doesn't give you this info as far as i know. The reason i ask (and i keep mentioning this each time i hear of these issues) is that the Nvidia chipsets can take longer than usual to find the domain.

[saplinpoo]

Hi,

 

They are mac minis, of varying age. Some have Nvidia chips and others don't, but the problem doesn't seem to reside on any particular machine type.

 

I've done some debug logging, and the only errors I can find are the following...

 

14260 - eDSBufferTooSmall

 

14002 - eDSOpenNodeFailed

 

These errors both occur during an unsuccessful boot attempt (in that both directories are not found)

 

These don't show me anything in particular, but then my largely untrained mind might be missing something quite important!! 've looked around on the net for any answers but nothing obvious is sticking out.

 

Any ideas????!!!!

 

Thanks,

 

Arron

[HodgeHi]

How have you deployed these machines?

Did you use deploystudio?

 

If so take one of the machines that is behaving badly and re-image it. I've had a few where the Directory Services hasn't quite bound properly during the restore process.

[saplinpoo]

I have deployed using DS.

 

Problem is, there aren't any particular machines that are behaving badly. It is a very intermittent and random problem.

 

In Directory Utility, even when the AD hasn't responded, the bind still exists, but just has a red light and says that the domain server does not respond. Things that can give a quick fix are re-binding the machine, restarting or unplugging the ethernet cable and replugging when the OD connection is lost. Sometimes these steps work, sometimes it takes bloody ages!!

 

As a quick fix, I have stopped the machines sleeping during the day, as a sleep seems to restart the directory service and sometimes after waking the AD Domain isn't found. So by stopping sleeping, once the machine is bound to both domains in the morning, it should stay that way for the rest of the day.

 

Not very carbon neutral I know, but I have no choice. One thing Apple could build into the next OS update is if the directory service can continually refresh a bad connection until it becomes good. This might mean a bit of time for machines that aren't playing ball, but at least they should all eventually connect.

[HodgeHi]

Maybe try re-installing the OS from the DVD /cd drive to see if this helps one of the clients. After re-install try binding this machine.

 

Also update your Deploy Studio and then try again. It does however say that you should re-build the image /.NBI for the latest version though. Maybe try rebuilding the Client and then imaging that machine once built?

 

Just a few things to try. As you can probably guess, I do suspect that the re-imaging is a possible problem. I have seen a few things that have been a little strange after imaging and all related to Directory Binding (macbooks losing the OD bind after restart on the same 3 machines.Exactly the same image).

 

At least we can remove another potential cuplrit.

[BootManager]

Hi All,

finally got back to posting a reply and the good news is that my apple-no-login-shake problem now seems to have gone away, *joy* , so the rebuild of the DNS did the trick, I can use the windows side for weeks, then switch to the mac side for a lesson (no shake off), then back to windows.

To think of all the time I wasted rejoining the domain on each and every mac for each and every time I needed to use it. Well now its fixed and nobody, not even the apple experts, ever suggested that the problem is all down to DNS.

 

Thank you.

[AntonioRocco]

Hi

 

@ BootManager

 

It's pleasing you managed to fix your particular problem.

 

"nobody, not even the apple experts, ever suggested that the problem is all down to DNS"

 

Perhaps you choose to remember and understand only what you want to? These boards (as well as others) continually stress the importance of a properly configured DNS Service. An earlier post of mine (as well as others) in this thread actually mentions:

 

"slightly iffy DNS"

 

As being relevant to the problems the OP (and others) mention. Even if DNS is 'perfect' you can still have problems logging in that may be caused by something else.

 

Antonio Rocco (ACSA)

Edited June 3, 2010 by AntonioRocco

[HodgeHi]

@ BootManager,

 

So which aspects of the DNS rebuild did the trick. Perhaps a summary of what you did (as opposed to the massive post you made. Some may not want to read it all. ) might help. I for one am curious as to what you did try in the end and what was successful. Did you use reserved DNS entries coupled with reserved DHCP addresses?

[BootManager]

I think the main thing was that it just looked in a mess when comparing it to DNS at a different school, or I should say that perhaps it just looked 'different'. When I rebuilt DNS I had the forward and reverse zones, my cached lookups and my events folders, nice and neat. One the old DNS I also had things like _msdcs on the same level and possible some other entries.

I guess the important thing was that the server had been through an upgrade path from Win2K so some old functionality was being catered for, possible to the detriment of a happy win-mac environment. So when I did the rebuild I took the opportunity to switch to Win 2003 functionality ONLY.

Another important issue is probably to not manually add records to DNS while logged in as another user, I think the old records got added by our apple contractor using remote desktop, (no idea what he would have logged in as), and I believe windows system then treats those records totally hands-off, or something [i can't remember exactly what I read but it was in a windows online doc], ....erm basically I registered my servers, including macs, by instructing the servers to register themselves in DNS instead of manually adding records to DNS directly.

 

Anyway, I'm still happy to say the network is continuing to behave itself now.

[BootManager]

By the way, I do have reserved DHCP entries although some of these dont actually get used since the servers have fixed/manual IPs. It doesnt do any harm to list the items anyway since it puts everything in one place and I know whats free and what isnt.

[Ephelyon]

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!

[PEO]

Hi this script comes back with an error 'Expected end of line, etc. but found unknown token.'

 

can you help?

[Ephelyon]

I know the script works as it's been copied and pasted directly and success has been reported from other users in this thread:

 

http://www.edugeek.net/forums/mac/43879-snow-leopard-ad-integration-woes.html

 

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

[Carter]

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.

 

http://www.twistedmac.com/images/blog//Mac%20OS%20X%20with%20AD.jpg

 

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.

[Ephelyon]

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?