mac will not log on

[robertsenior]

we now have 20 macs that are allowsing students to log on throught the AD.

 

some time the macs will not let domain users log on even tho the green light is on

and domain users are avaliable.

 

i have seen this on some of the forums but no one has really posted a comment on how to resolve the issue

 

does anyone know what is wrong

[samba_man]

we now have 20 macs that are allowsing students to log on throught the AD.

 

some time the macs will not let domain users log on even tho the green light is on

and domain users are avaliable.

 

i have seen this on some of the forums but no one has really posted a comment on how to resolve the issue

 

does anyone know what is wrong

 

If this appears to be happening randomly our best 'fix' at the moment is for one of their fellow students to log in and out then the first student can usually log in. Failing that a restart of the Mac in question usually does the job.

 

If it is happening with every network user on a Mac, unbind from AD, remove AD object and rebind. We're still in the process of working out why this happens.

[BootManager]

its an ongoing problem here too and I havent found anyone that knows the real reason why this happens but I'm getting closer to the solution myself.

Heres the tedious 'dirty fix' -

log onto the troublesome mac using local admin, typically username "ladmin" if you've been on an Apple Course - thats what they get everyone to setup/use. you should be able to get in as you wont be validating against AD or OD.

 

OK - the steps are 1) get off AD & OD, 2) delete the pref files, 3) rejoin AD & OD, 4) log out local admin and log in to the domain user that you want.

 

Step1) run Applications>Utilities>Directory Utility. Hopefully you should know how to use the + and - buttons to add and remove entries so I wont go into detail, you just need to remove all the entries then exit out of the Directory Utility, YOU MUST EXIT OUT OF DIRECTORY UTILITY.

 

Step2) browse to this folder Macintosh HD > Library > Preferences > Directory Utility > .... delete all of the files within the folder but dont delete the folder itself. (note that the files are just preferance files in xml format and dont bother trying to decipher them as you will find many red herrings, the contents are quite different across various OS X updates so you really aint going to get anywhere are you)

 

Step3) go back into directory utility and use the + button to get back onto your win domain and mac server open directory.

 

Step 4) zzzzzzzzzz you know, log off and log on as the proper user. Thats It, a dirty fix that you will have to keep doing every week or so until someone finds the real solution.

 

 

Heres some things that I have noticed and some myths debunked:

Reboot the machine - myth - if you reboot the machine you will probably find that you dont gain anything except having to wait about 5 minutes while it reboots and 'thinks'.

 

IP address changes cause this problem - expand your IP range as its too small - myth - so much effort expanding the IP range and the end result is still the same, your mac is not giving you problems because its IP address has changed, your mac's IP address can still change even if you have thousands of spare IP addresses at hand.

 

On a dual boot mac you should keep the machine name the same on both the windows and mac side - ABSOLUTELY NOT! - I followed this 'advice' and found that my 'computers' active directory entries for windows got replaced/trashed by the fact that the machines were then listed in AD as having MAC operating systems and then nobody could logon to the domain when using windows instead.

 

DNS problems - well I think this is more likely, but why DNS is playing up is another matter. One thing that you may observe is that if you look closely at your machine name on a badly behaving mac, you may see that its changed to something else !, it may have picked up the name of a differnt computer - even the name of a PC computer!! Look closely at your DNS entries, particularly following the forward lookup and reverse lookup, do you notice any stray duplicates, do you notice that reverse entries are missing. I certainly have been observing these things here and have came to the conclusion that my DNS is getting messed up. I suspect that open directory is messing things up but I dont have any hard proof, all I know is that dual-boot computers are causing problems.

[BootManager]

sorry I forgot.

 

Also on DNS subject, it would appear that the bad Apple mac client uses its last-used IP address to query a reverse lookup on DNS to find out what its computer name is ??!??? yeah it sounds crazy but follow the DNS trail, you will probably find that the only connection between the bad computer name that the bad mac client has got can only be directly linked via DNS using the reverse lookup, why this happens I dont know.

the problem is that once the IP address is renewed by DHCP you will have to wait for the lease to expire before a issues re-occur.

Its a tedious problem and not one to easily track down.

 

Oh and by the way another myth to solving the problem is configure DHCP so that leases never expire or expire within a day. Both bits of advice seem to be clutching at straws, I tried both configurations, didnt help either way.

[samba_man]

Im not so sure that the problem is DNS related as all of our Macs and the Ubuntu file server described in this topic are all on static IPs and have been since installation.

[somabc]

Are you specifying the Domain Controller?

[TomH]

Does the window just shake, or does it say the home folder cannot be located in the usual place ?

 

We see these problems daily with our new customers, and generally the problems can be resolved.

 

These days there is no reason why a stable binding cannot be achieved with OSX to active directory.

 

The dynamic DNS mentioned below is generally only a cosmetic problem where clients are concerned, so i wouldn't focus to much of your time on it.

 

Tom

[bladedanny]

One thing we've had in regards to Mac login problems is Time, if the times are out then they won't be able to authenticate. I'd check the time before doing anything more complex.

[BootManager]

we've had apple experts in to fix our problem on several occasions, the result is just the same - once the mac is bound to active directory they think the problem is fixed.

The problem THE REAL PROBLEM is that for some unpredictable reason a mac will 'forget' that its bound and there is absolutely nothing that you can do about it until you unbind/rebind again, this typically happens a few days or weeks after the apple experts have been and gone.

 

The apple experts that we've had tend to think that nothing can possibly be wrong cause macs are 'so superior' that nothing could possible be at fault. But I've been on the Apple Certified training courses and the off-the-cuff advice we got was dont rely on any bundled apple service (except the web service), apple may upply pretty-looking software but business critical software it isnt. So though I'm not saying this particular problem is all apple's fault, I think its probably DNS related, dont be suprised if it does turn out to be apple.

 

The time thing is again another red herring, yes if the time is out of sync then it will cause problems, but here all of our computers are synced internally to the main server and DHCP provides the correct parameters, everything looks OK on that front. There was an issue regarding daylight saving on the windows side of things but a boot camp patch fixed that problem some while back.

[u8dmtm]

We had this problem of few years back and it was due to the times being out between the Mac and the Domain. The root cause was that the CMOS batteries were flat and we ended up replacing every single one. After that and resetting the clocks, the problem went away.

[BootManager]

until you have experienced this problem for real then you cannot even begin to guess what the cause is.

Currently I'm looking at rebuilding DNS, over easter when nobody is using the systems.

 

its not a trivial problem, believe me there is no easy fix relating to time-sync, or locked-out accounts.

you can logon as a local administrator and inspect everything on the mac client, everything looks fine, green lights on directory utility entries, time-synced ok.

the only thing that I notice that is wrong is that the mac client may have somehow, strangely, inherited a name that it was never originally given. you cannot change the name unless you unbind from the AD & OD and even then the name change will only be affected after a reboot. there are no malicious people going around in the middle of the night hacking the computers or anything that would give a simple explaination. One day you can log on fine the next day you get the shake off.

 

Do note that my computers are dual boot macs, that means that the NIC on the network card will obviously be the same if I choose to boot mac or boot windows, but the 'machine name' needs to be different for mac and for windows otherwise the AD entry for that particular computer may be right royally messed up.

 

Our Domain was created many years ago and the operating system has been upgraded from win 2k server to win 2003 server. I can visit a neighbouring school which has a similar mac set up to ours except their win 2003 server was a fresh build a in recent years. Comparing our DNS setup to that schools reveals some wild differences, and since that school isnt experiencing the problems we are experiencing then I'm inclined to think thats where the issue lies.

Also I have to think about what services the mac client may use, there really isnt many services that store info relating to machine name and ip address.

 

going back to the weird computer-name-change thing, this was something I stumbled across completely by chance, after all you dont expect it to happen so you diont look in that area.

Anyone that is experiencing these mac refusal to logon problems please do click the info text found underneath where it says "MAC OS X" on the logon box and note down what it says for the computer name, IP address, etc. you can then investigate your DNS, or AD and follow the trail DNS forward lookup to reverse lookup and note if there are any duplicate entries particularly on the reverse lookup.

And please do report back here, I would be interested to know.

[_Bat_]

Lol. At almost 3am on a saturday morning, I have been thinking over some of the issues we have remaining (yes, I have no life) and the first thread I see is this one, which saves me having to create a new one. We've been having this issue ever since we integrated OD and AD in a triangular setup during the summer last year. I've not had that many complaints, but every now and then someone mentions not being able to log on until they have rebooted the mac. I've had them try and log on in front of me, and then try and log on to the same mac myself, neither set of credentials work so it's not something silly. Once the mac has been rebooted however, all domain users can log on fine - nothing else is changed. When the mac refuses to log any domain users in, the green light is displayed on the login window, specifying that all network accounts are available, as per normal.

 

Once I get back into work in the middle of next week, I'll come back to this thread and follow any potential leads. Just glad to know I'm not the only one with issues like this.

[dbhbbc]

Before everyone goes off and destroys their networks or whatever, you may want to try this first:

 

1) Join OSX computer to your AD domain

 

2) Test to see if joined correctly (see if it logs in)

 

3) Open terminal (need to be an admin user on the local machine)

 

4) Type: dsconfigad -passinterval 0

 

5) Press enter and type your password if it asks

 

This should set the trust password refresh interval for the computer to never expire.

 

Alternatively, setup and use DeployStudio freeware, closest I've come to finding something useful for macs.

[MarsRed]

I second what dbhbbc says about the passinterval. OS X, by default, changes its AD machine account password every 14 days. However, if the machine cannot contact the domain controller at that time, it seems that the machine still changes its password and AD just doesn't know it!

 

When you bind your Macs for the first time, you may want to do so with a script so that you can set the passinterval at the beginning and avoid issues. Bombich has a script that you can take a look at (Bombich.com: Mac OS X Management Custom Shell Script Library). Just plug in your site-specific info and make sure to change the "passinterval" option to 0.

[mac_shinobi]

I second what dbhbbc says about the passinterval. OS X, by default, changes its AD machine account password every 14 days. However, if the machine cannot contact the domain controller at that time, it seems that the machine still changes its password and AD just doesn't know it!

 

When you bind your Macs for the first time, you may want to do so with a script so that you can set the passinterval at the beginning and avoid issues. Bombich has a script that you can take a look at (Bombich.com: Mac OS X Management Custom Shell Script Library). Just plug in your site-specific info and make sure to change the "passinterval" option to 0.

 

The script section does not exist anymore

[MarsRed]

The script section does not exist anymore

 

If you click on that link I posted, it should say "ad-bind-login.sh" about halfway down the page. In case anyone has trouble getting to it, I'll post the contents of the Leopard (and SL) AD Bind script here. Note that it looks like this one is meant to be used as a login hook, so it will probably be necessary to alter it a little to fit an individual's needs.

 

----

 

#!/bin/sh

 

# This script binds to AD and configures advanced options of the AD plugin

# As this scripts contains a password, be sure to take appropriate security

# precautions

#

# A good way to run this script is to set it as a login hook on your master machine

# Because it only needs to be run once, the last thing this script does is to delete

# itself. If you have another login script that you typically run, include the

# script on your master machine, and indicate its path in the "newLoginScript"

# variable.

#

# If running this as a one-time login hook to bind to AD after imaging,

# be sure to enable auto-login (for any local user) before creating your master image

 

 

# Host-specific parameters

# computerid should be set dynamically, this value must be machine-specific

# This value may be restricted to 19 characters! The only error you'll receive upon entering

# an invalid computer id is to the effect of not having appropriate privileges to perform the requested operation

#computerid=`/sbin/ifconfig en0 | awk '/ether/ { gsub(":", ""); print $2 }'` # MAC Address

#computerid=`hostname`

#computerid=`/usr/sbin/scutil --get LocalHostName | cut -c 1-19` # Assure that this will produce unique names!

computerid=`/usr/sbin/scutil --get LocalHostName`

 

# Standard parameters

domain="apple.edu" # fully qualified DNS name of Active Directory Domain

udn="bind_account" # username of a privileged network user

password="" # password of a privileged network user

ou="CN=Computers,DC=apple,DC=edu" # Distinguished name of container for the computer

 

# Advanced options

alldomains="enable" # 'enable' or 'disable' automatic multi-domain authentication

localhome="disable" # 'enable' or 'disable' force home directory to local drive

protocol="afp" # 'afp' or 'smb' change how home is mounted from server

mobile="disable" # 'enable' or 'disable' mobile account support for offline logon

mobileconfirm="disable" # 'enable' or 'disable' warn the user that a mobile acct will be created

useuncpath="enable" # 'enable' or 'disable' use AD SMBHome attribute to determine the home dir

user_shell="/bin/bash" # e.g., /bin/bash or "none"

preferred="-nopreferred" # Use the specified server for all Directory lookups and authentication

# (e.g. "-nopreferred" or "-preferred ad.server.edu")

admingroups="" # These comma-separated AD groups may administer the machine (e.g. "" or "APPLE\mac admins")

packetsign="allow" # allow | disable | require

packetencrypt="allow" # allow | disable | require

passinterval="14" # number of days

namespace="domain" # forest | domain

 

# Login hook setting -- specify the path to a login hook that you want to run instead of this script

newLoginHook="" # e.g., "/Library/Management/login.sh"

 

 

### End of configuration

 

# Activate the AD plugin

defaults write /Library/Preferences/DirectoryService/DirectoryService "Active Directory" "Active"

plutil -convert xml1 /Library/Preferences/DirectoryService/DirectoryService.plist

 

# Bind to AD

dsconfigad -f -a $computerid -domain $domain -u $udn -p "$password" -ou "$ou"

 

# Configure advanced AD plugin options

if [ "$admingroups" = "" ]; then

dsconfigad -nogroups

else

dsconfigad -groups "$admingroups"

fi

 

dsconfigad -alldomains $alldomains -localhome $localhome -protocol $protocol \

-mobile $mobile -mobileconfirm $mobileconfirm -useuncpath $useuncpath \

-shell $user_shell $preferred -packetsign $packetsign -packetencrypt $packetencrypt \

-passinterval $passinterval -namespace $namespace

 

# Restart DirectoryService (necessary to reload AD plugin activation settings)

killall DirectoryService

 

# Add the AD node to the search path

if [ "$alldomains" = "enable" ]; then

csp="/Active Directory/All Domains"

else

csp="/Active Directory/$domain"

fi

 

dscl /Search -append / CSPSearchPath "$csp"

dscl /Search -create / SearchPolicy dsAttrTypeStandard:CSPSearchPath

dscl /Search/Contacts -append / CSPSearchPath "$csp"

dscl /Search/Contacts -create / SearchPolicy dsAttrTypeStandard:CSPSearchPath

 

# This works in a pinch if the above code does not

#defaults write /Library/Preferences/DirectoryService/SearchNodeConfig "Search Node Custom Path Array" -array "/Active Directory/All Domains"

#defaults write /Library/Preferences/DirectoryService/SearchNodeConfig "Search Policy" -int 3

#plutil -convert xml1 /Library/Preferences/DirectoryService/SearchNodeConfig.plist

#killall DirectoryService

 

 

# Destroy the login hook (or change it)

if [ "${newLoginHook}" == "" ]; then

defaults delete /var/root/Library/Preferences/com.apple.loginwindow LoginHook

else

defaults write /var/root/Library/Preferences/com.apple.loginwindow LoginHook $newLoginHook

fi

 

 

# Disable autologin

defaults delete /Library/Preferences/com.apple.loginwindow autoLoginUser

srm /etc/kcpassword

 

# Kill loginwindow to return to the login screen

killall loginwindow

 

# Destroy this script!

srm "$0"

[PEO]

if the macs time are out of sync that can cause failed login atempts. are they picking up time from dc?

[TomH]

Guys,

 

dsconfigad -passinterval 0 need to be ran BEFORE binding to AD.. and i agree all the symptoms above sound like a bad machine password if there is no output from DSCL.

 

You have to remember that a Mac queries AD as a machine and not as a user, and uses a old and unreliable kpasswd method to change it.

 

cat /Library/Preferences/DirectoryService/ActiveDirectory.plist

 

and look for:

 

Password Change Interval

0

 

If you wish to prove the theory you can convert the machine password from ActiveDirectory.plist into a plain text password and then try and authenticate against kerberos as that machine.

 

I would also review your DNS service records that should be created when you run dcpromo the following article should help :

 

Mac OS X 10.5: Verifying DNS consistency for Active Directory binding

 

also if anyone runs anti virus make sure it doesn't scan /var/db/dslocal/

 

you can logon as a local administrator and inspect everything on the mac client, everything looks fine, green lights on directory utility entries, time-synced ok.

 

Do you query DSCL to see if you can read AD ? Also at this point i would pull the machine password from ActiveDirectory.plist and try and authenticate against kerberos using it.

 

going back to the weird computer-name-change thing, this was something I stumbled across completely by chance, after all you dont expect it to happen so you diont look in that area.

 

If you wish to prevent this then, either set static IP's or as part of your post deployment script configure HOSTNAME=DesiredName in the host config this should prevent any host name changes.

 

On another note you can also edit smb.conf to prevent DDNS entries if required.

 

if the macs time are out of sync that can cause failed login atempts. are they picking up time from dc?

 

Yes they have to be within 5 minutes.

 

If you do disable password changes make sure your AD guys know.. as allot of people cull old accounts which is what they will appear as.

Edited March 28, 2010 by TomH

[Hacksawbob]

Cant offer any help but watching this thread with interest, when I get back in I have at least got a few things to try now, rather than reading over and over about "how to bind mac clients to AD". It seems to be an elephant in the corner with apple that actually for all their confidence about getting MAC-AD "working out of the box" actually it is pretty flakey. I have done it before in a separate environment and it worked a treat, I would dearly love to get to the bottom why it doesn't work where I am now.

[AntonioRocco]

Hi

 

@ TomH

 

A lot of good knowledgeable advice however this statement:

 

"if the macs time are out of sync that can cause failed login atempts. are they picking up time from dc?"

 

"Yes they have to be within 5 minutes"

 

Is not strictly true. The default time sync interval when promoting to DC is indeed 5 minutes but can be easily expanded to 10. Simply changing the relevant Kerberos Policy setting in the Local or Group or Domain Security Policies is enough. Unbinding and rebinding afterwards is a good idea as that way clients will get a fresh TGT based on the expanded time sync interval. You could also do this via the command line. IMO it's still a good idea to disable the requirement for SMB Digital Signing (if Server/Client agrees). Not the 'deal breaker' it used to be in 10.4 and earlier it can still introduce an unnecessary 'lag' which might make it possible for workstations to 'lose contact' with the DC. Add this to the usual mix of a 5 minute time sync interval; slightly iffy DNS; TLDs based around .local; stale reverse DNS records resolving to hostnames previously assigned to PCs and even (depending on switches used) an inability to query ntp on port 119 can easily add up to the problems being reported.

 

It should also be noted that PCs (no integrated macs at all) can also 'lose sight' (admittedly not as often) of the DC and present similar problems. If this happens at your location look at the network itself. A lot of school networks still have the odd hub hidden away somewhere probably up-linking something to something. Duplex mismatching is another thing to look at as well as Port Fasting and even Spanning Tree. Just because a switch is new does not mean it's not faulty.

 

One thing is certain: Introducing macs into a mature AD environment will find every flaw and weakness like nothing else. The platform in many ways is a little like Goldilocks looking for the bowl of porridge that "tastes just right."

 

However not all sites have problems. There are many many sites where macs don't have problems logging in or losing sight of AD. Admittedly they may have or do have other problems. There are also sites in my experience (and probably TomH's?) that have had and still have no problems at all. Generally these tend to be sites where the AD environment was built to accommodate macs to begin with.

 

It should also be noted, in some cases, integration may not the best option? Especially true if the AD environment is an RM build. CC3 certainly although, strangely, not all of them. As for CC4? Don't even go there. It's bad enough for PCs alone. If this is true for your site it might be best to consider a different strategy instead. A separate OD environment completely divorced from AD yet still interacting it with on many levels is more than doable and possibly even desirable.

 

HTH?

 

Antonio Rocco (ACSA)

Edited March 28, 2010 by AntonioRocco

[TomH]

 

Is not strictly true. The default time sync interval when promoting to DC is indeed 5 minutes but can be easily expanded to 10.

 

True... as with all these things were talking 'out the box' rather than 5 generations of various IT Technicians tweaks

 

Have you ever seen a environment with a larger than default Clock Skew?

 

As im sure AntonioRocco will agree, most things can be resolved and generally its just a case of proving what the problem is before applying 'random' fixes from google that may or may not improve the situation.. i have seen some really weird fix's that just havent helped the situation at all.

[AntonioRocco]

Hi TomH

 

as with all these things were talking 'out the box' rather than 5 generations of various IT Technicians tweaks

 

Absolutely!! Can't say that about OD can we? As we know mature, 'Legacy' AD environments have the most imponderables to deal with. Generally because the current admins have no notion of what was done before. Why would they? Besides previous admins have a tendency to not tell successors anything anyway. "Must keep hold of knowledge - Bad to share" attitude which ultimately helps no-one. For current admins, as far as they're concerned it works. There's no need to do anything to upset it.

 

Does not make it right though does it?

 

Some IT Admins facing mac integration don't know what Kerberos (along with DNS, sadly) really is; how it's implemented in their environment or how it truly works. Let alone that the time sync interval can be expanded. This is standard MIT Kerberos stuff as you know.

 

This is not a criticism guys just an observation. I have nothing but respect for all of you as it's not easy doing what you do. Especially when someone takes an arbitrary decision not involving you in any way regarding equipment you know nothing about yet are expected to fully support. Gets your back up doesn't it? Sometimes this develops (quickly) into an 'unwilling attitude' which can add to the general 'mix'.

 

"Have you ever seen a environment with a larger than default Clock Skew?"

 

Yes as I always make that recommendation. Sadly only a few listen or understand its implication. Coupled with the 'passinterval' setting (sometimes) it can 'cure' all sorts of problems. Assuming everything else is perfect of course.

 

"most things can be resolved and generally its just a case of proving what the problem is before applying 'random' fixes from google that may or may not improve the situation"

 

I'm with you there Tom. We're talking the same language.

 

"I have seen some really weird fix's that just hasn't helped the situation at all"

 

Absolutely.

 

Tony

Edited March 28, 2010 by AntonioRocco

[BootManager]

just been reading this thread which has expands on my dns hunch...

http://www.edugeek.net/forums/windows-server-2000-2003/50877-dns-reverse-lookup-server-2003-a.html

[BootManager]

another (old) thread on AD binding problems...

Snow Leopard AD Integration woes

 

today I rebuilt my Windows DNS and also played around with some DHCP settings. Also in Active directory I found that our domain it was flagged/running as "Windows 2000 Mixed" so I upgraded to "Windows 2003" (a simple click of a button - but one where there is no going back). Obviously quite a few changes and I'm currently monitoring the situation.

 

I'll let you know what the outcome was in due course.

[HodgeHi]

I've been having this problem since we moved schools on some new edu intel alu imacs. it seems to be a select few machines which have the issue recur now and again. Each time i check the logs it's a pre-auth failure causing the issue. A quick unbind of the ad and rebind sorts the issue. I'm not entirely sure whats causes this and would be willing to try anything. What is really funny though is i have a couple of standard macs with intel, networking and ATI cards and the old edu white intel imacs. I have 25 of these types and these have never had the problem. Still don't. These too have the intel networking chipsets.

 

I still think the nvidia networking chipsets are to blame for some things. Just can't prove it I doubt Apple will change their manufacturing because of me though. Do you ?