Home › Forums › OS X Server and Client Discussion › Open Directory › Share point Authentication to ODR takes 10+ minutes to be successful
- This topic has 5 replies, 1 voice, and was last updated 16 years ago by
kennyj.
-
AuthorPosts
-
March 16, 2009 at 4:09 pm #375706
kennyj
ParticipantI have been having some issues with 10.4.11 OD replica server that I inherited a while back. Last week users began to have problems logging in to file shares (both AFP and SMB ). The auth would not time out, but we found that if you let it run, it would eventually connect 10 – 15 minutes later. A bounce of the server would let it respond normally again for a little while.
I called Apple about this and their recommendation was to demote the ODR to stand-alone, reboot, and promote it again to ODR. This at first had looked promising… but this morning the problem is back again.
Some of the things I’ve noticed…
[b]DNS:[/b]
* I can perform reverse lookup through nslookup, but not with dig
* DNS lives on windows server and has correct forward and reverse entries[b]PasswordService.Error.log[/b]
[color=red]I see the following errors on Saturday afternoon which is when I brought the server back up after dropping the replica[/color]
* Mar 14 2009 13:45:49 Listener exception error: -1.
* Mar 14 2009 13:47:08 LauchTaskWithIO path = /usr/sbin/kadmin.local, arg1 = -q, arg2 = add_principal +requires_preauth vpn_756d4e7ad6a6, status = 1[b]Console Log:[/b]
[color=red]This was happening before and after the re-promotion – a huge amount of these:[/color]
* Mar 16 06:55:48 [i]servername[/i] /usr/sbin/PasswordService: client response doesn’t match what we generated[color=red]After the re-promotion… messages like this seem to have started showing up:[/color]
* CoreEndianFlipData: error -4940 returned for rsrc type DITL (id 134, length 125, native = no)
* CoreEndianFlipData: error -4940 returned for rsrc type cicn (id 1099, length 290, native = no)
[color=red]I believe these to be from NetVault Replicator… I really want to get rid of this thing, it will need to wait though[/color][b]On the Master which is also 10.4.11, in Server Admin I see:[/b]
Replicas
[i]ipaddress[/i] Error (see /var/run/openldap-slurp/replica/[i]ipaddress[/i].reglooking at [i]ipaddress[/i].reg I see…
[quote]ERROR: No such attribute: modify/delete: apple-ldap-replica: no such value
replica: [i]ipaddress[/i]:389
time: 1237063208.0
dn: cn=ldapreplicas,cn=config,dc=[i]server[/i],dc=[i]domain[/i], dc=
changetype: modify
delete: apple-ldap-replica
apple-ldap-replica: ldap://[i]ipaddress[/i]
–
replace: entryCSN
entryCSN: 20090314204008Z#000001#00#000000
–
replace: modifiersName
modifiersName: uid=diradmin,cn=users,dc=[i]server[/i],dc=[i]domain[/i],dc=
–
replace: modifyTimestamp
modifyTimestamp: 20090314204008Z[/quote]I figure I will call Apple again today, but I was wondering if anyone has been able to resolve a similar issue.
Thank you for any suggestions,
kennyjMarch 16, 2009 at 8:59 pm #375711kennyj
ParticipantMy bad about the dns… everything is fine there. I was just typing dig [i]ipaddress[/i] for a reverse instead of dig -x [i]ipaddress[/i]
Also, I have been unable to reproduce any SMB problems on my side from Windows or Mac computers. Suggested windows users should reboot their machines or check dns.
I also contacted AppleCare again and got the following suggestion:
* Demote to Stand Alone
* Reboot
* Make sure it is bound to ODM through Directory Access (it was actually bound to itself for some reason)
* Reboot if any changes to Directory Access
* Test connectivity to AFP (since this took a while for the symptoms to appear, I’m not sure if I will be able to do a valid test right away)
* If still having problems, try renaming or removing /Library/Preferences/AppleFileSesrver.plist
* Reboot and try again
* Do not re-promote to Replica until everything is perfectI am going to give this a shot tonight… probably won’t promote it to a replica again until it is tested tomorrow by the users.
March 17, 2009 at 1:31 pm #375715kennyj
ParticipantDropped the replica down to a Stand Alone server connected to the ODM. I also removed the AFP preference file. Everything seems to be fine and I have not yet re-promoted it to a replica server.
I have noticed this morning a lot of failed login attempts for the admin account and another account that has elevated privs. There is a group that is using a lot of scripts to move files around and rename things on the server… I believe it actually may go as far as mounting the shares. I’m pretty sure these scripts may be to blame for these failed logins, I will need to check on this today.
I plan on re-promoting to Replica tonight if everything goes well today.
March 18, 2009 at 1:31 pm #375735kennyj
ParticipantPromotion seems to have gone well. I think there were two major issues here that I fixed. One was having the replica bound to itself in Directory Access. The other was removing or renaming /Library/Preferences/com.apple.AppleFileServer.plist
March 18, 2009 at 8:27 pm #375745kennyj
ParticipantArgh, after posting this, it started up again… however the wait time was not as bad as it was originally. Now users are seeing anywhere from 1 to 10 minutes to authenticate to the server via afp.
March 19, 2009 at 8:57 pm #375757kennyj
ParticipantRemoved /Library/Preferences/com.apple.AppleFileServer.plist again. This seemed to work after a reboot (I suppose you could probably just stop/start the afp service too). Something must have not come over properly after promoting to a replica in this file. Everything has been fine all day today.
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed