Problems logging on 10.8.3 server from certain Macs

Question

Level 1

8 points

Problems logging on 10.8.3 server from certain Macs

I have two 10.8.3 servers.

Server 1 is the main Fileserver and also is running an OD master.

Server 2 is an FTP server (running Rumpus) but I also have Filesharing running for practical reasons. Server 2 are also running the internal DNS and is connected to the OD master through User & Groups.

Now the problem I have is that some of my Macs cannot login to either of the servers. It's not an issue with the users not beeing set up properly since I have tried the same user on all of them and it works on some but not on others. If I check the system log it only says:

4/12/13 4:36:27.666 PM	kdc[930]	Got a canonicalize request for a LKDC realm from 192.168.0.167:51123
4/12/13 4:36:27.666 PM	kdc[930]	Asked for LKDC, but there is none
4/12/13 4:36:27.667 PM	kdc[930]	Got a canonicalize request for a LKDC realm from fe80::21f:5bff:fe37:beed%bond0:51124
4/12/13 4:36:27.667 PM	kdc[930]	Asked for LKDC, but there is none

The above is one example but not all of the problem macs generates this message. At least not an entry with their IP address so I can tie the message to the mac. The weird thing is that this message (or similar) also can be found sometimes even if the login was successful. Like the next example where I logged in connected through our Cisico firewall using AnyConnect:

4/13/13 10:48:49.168 AM kdc[930]: Got a canonicalize request for a LKDC realm from local-ipc

4/13/13 10:48:49.168 AM kdc[930]: Asked for LKDC, but there is none

4/13/13 10:48:54.998 AM kdc[930]: Got a canonicalize request for a LKDC realm from local-ipc

4/13/13 10:48:54.998 AM kdc[930]: Asked for LKDC, but there is none

It seems to be tied to the particular macs or IP addesses but I have no idea where to look for a solution. Speaking of IP addresses, I checked all the macs that could not log on and compared with the address of those which could and could not find a pattern. They are all spread over the whole subnet.

Any ideas would be much appreciated!

Posted on Apr 13, 2013 1:54 AM

Reply

Answer 1

davidh

Level 4

1,890 points

Apr 13, 2013 5:55 AM in response to eckeph

How exactly are you connecting to the server/s ?

Via the Server listed in the sidebar ?

Are your workstations bound to your OD ?

When connecting, try using Go (menu) "Connect to Server..." and specifying the IP address of the server (one or the other).

The LKDC will get invoked by using the sidebar-listed server, possibly/probably also browsing via "Network"

- For troubleshooting this, please try the Go > Connection option.

For troubleshooting Kerberos, see http://www.dreness.com/blog/?p=43
which is alot to wade through.

Run this on the CLIENT:

sudo syslog -c syslog -d

sudo syslog -c 0 -d

killall NetAuthAgent

kdestroy -A

syslog -w

start a connection in Finder using ‘connect to’

once you attempt a connection using the proper fqdn, enter a name / pw if prompted

then wait 30 seconds for syslog in teh terminal to catch up, then cntrl-c it

you should find ample / useful debugging info in the terminal (syslog) output

For more about the LKDC, http://www.dreness.com/blog/?p=42

But the above is for troubleshooting Kerberos as presented by your server(s) as specifically opposed to the LKDC

Reply

Answer 2

eckeph Author

Level 1

8 points

Apr 15, 2013 2:35 AM in response to davidh

It doesn't matter if I use the sidebar or the CMD+K. I have also tried to use the DNS name and the IP-address in CMD+K but no change.

If you by "bound to your OD" mean that the workstation uses my OD as 'Network account server" (as configured in Users & Groups) then no, they don't.

The thing is, my workstations finds the server (otherwise the login screen would not appear, right?) but they seem to freeze right after submitting user and password and you have to relaunch Finder to get rid of the login screen. It doesn't matter if I submit a correct user or something completely random.

I have found out something interesting though. All of the workstations (5) that cannot login are running 10.7.5 (up to date with the latest patches, at least according to Software Update) However, I have one mac running 10.7.5 that can log in. All other macs that can log in are running 10.8.3, 10.8.2, 10.6.8 or 10.5.8. Why one 10.7.5 mac can log in but the rest cannot is a mystery. I have not yet been able to figure out what's different between that one and the others.

Reply

Answer 3

eckeph Author

Level 1

8 points

Apr 15, 2013 5:15 AM in response to eckeph

Yet another finding.

If I create a new share point on the 10.8.3 server and turn on Guest Access on that share point, the macs that previously couldn't log in can now log in (as Guest) and see this new share point. They still cannot login as a proper user though. The reason I though of trying this is that I tried to log in to 10.8.3 workstations using filesharing and found out that I could log in to them if they had guest access on but not if I tried to log in with their user.

Reply

Answer 4

eckeph Author

Level 1

8 points

Apr 15, 2013 6:36 AM in response to eckeph

This is the output from my log (from the terminal) I'm assuming that you meant NetAuthSysAgent in your instructions above since I couldn find any NetAuthAgent running?

There is more but I just copied the section that looks most interesting. The rest is basically just repeats.

Apr 15 14:46:44 Olofs-IMac NetAuthSysAgent[257] <Debug>: NAHCreate-krb: have_kerberos=yes try_iakerb_with_lkdc=no try-wkdc=yes try-lkdc-classic=no use-spnego=yes

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: NAHCreate: hostname=fileserver.inhouse.com service=afpserver

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: NAHCreate: will use hostname=fileserver.inhouse.com

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: NAH: specific name is: erikphersson foo

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: NAHCreate: username=erikphersson username given

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: NAHCreate: password

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: NAHCreate: SPNEGO hints name not_defined_in_RFC4178@please_ignore

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: Turing off LKDC classic since server announces support for wellknown name: <CFBasicHash 0x7fe62b825170 [0x7fff7d821fa0]>{type = mutable dict, count = 7,

entries =>

3 : <CFString 0x7fe62b825030 [0x7fff7d821fa0]>{contents = "1.2.840.48018.1.2.2"} = <CFData 0x7fe62b8251f0 [0x7fff7d821fa0]>{length = 0, capacity = 0, bytes = 0x}

4 : <CFString 0x7fe62b8252a0 [0x7fff7d821fa0]>{contents = "1.3.6.1.5.5.14"} = <CFData 0x7fe62b8251f0 [0x7fff7d821fa0]>{length = 0, capacity = 0, bytes = 0x}

6 : <CFString 0x7fe62b825220 [0x7fff7d821fa0]>{contents = "1.3.5.1.5.2.7"} = <CFData 0x7fe62b8251f0 [0x7fff7d821fa0]>{length = 0, capacity = 0, bytes = 0x}

7 : <CFString 0x7fe62b825240 [0x7fff7d821fa0]>{contents = "1.2.840.113554.1.2.2"} = <CFData 0x7fe62b8251f0 [0x7fff7d821fa0]>{length = 0, capacity = 0, bytes = 0x}

8 : <CFString 0x7fe62b825340 [0x7fff7d821fa0]>{contents = "1.3.6.1.4.1.311.2.2.10"} = <CFData 0x7fe62b8251f0 [0x7fff7d821fa0]>{length = 0, capacity = 0, bytes = 0x}

9 : <CFString 0x7fe62b825270 [0x7fff7d821fa0]>{contents = "1.2.752.43.14.3"} = <CFData 0x7fe62b8251f0 [0x7fff7d821fa0]>{length = 0, capacity = 0, bytes = 0x}

10 : <CFString 0x7fe62b825010 [0x7fff7d821fa0]>{contents = "1.3.6.1.5.2.5"} = <CFData 0x7fe62b8251f0 [0x7fff7d821fa0]>{length = 0, capacity = 0, bytes = 0x}

}

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: NAHCreate-krb: have_kerberos=yes try_iakerb_with_lkdc=yes try-wkdc=no try-lkdc-classic=no use-spnego=yes

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: addSelection: IAKerb (3) erikphersson@WELLKNOWN:COM.APPLE.LKDC afpserver/localhost@WELLKNOWN:COM.APPLE.LKDC SPNEGO matching

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: addSelection: Kerberos (1) erikphersson@INHOUSE.COM afpserver/fileserver.inhouse.com@INHOUSE.COM SPNEGO matching

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: addSelection: Kerberos (1) erikphersson@COMPANY.LOCAL afpserver/fileserver.inhouse.com@COMPANY.LOCAL SPNEGO matching

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: NAHSelectionAcquireCredential: iakerb erikphersson@WELLKNOWN:COM.APPLE.LKDC

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: GetPascalCFString: Using the default string

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: afpIsUAMDisabled: <Cleartxt Passwrd> UAM is disabled

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: afpIsUAMDisabled: <MS2.0> UAM is disabled

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: GetPascalCFString: Using the default string

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: afpIsUAMDisabled: <2-Way Randnum exchange> UAM is disabled

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: afpIsUAMDisabled: <DHCAST128> UAM is disabled

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: GetPascalCFString: Using the default string

--- last message repeated 3 times ---

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: 3:GSS

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: 4:DHX2

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: 15:No User Authent

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: DoGSSLogin: SendRequestPtr failed -5023

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: TSocketAFPSession: Disposing of a TSocketAFPSession 594cd60

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: UserCommand failed: error 0x16, afpResult 0xffffec61

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: ERROR: AFP_OpenSession - theEnumerator->Count failed -5023

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: NAHSelectionAcquireCredential: kerberos client: erikphersson@INHOUSE.COM (server afpserver/fileserver.inhouse.com@INHOUSE.COM)

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: acquire_kerberos: erikphersson@INHOUSE.COM with pw:yes cert:no

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: acquire_kerberos: trying with erikphersson@INHOUSE.COM as client principal

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: NAH: error: acquire_kerberos failed erikphersson@INHOUSE.COM: -1765328228 - unable to reach any KDC in realm INHOUSE.COM

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: NAHSelectionAcquireCredential: kerberos client: erikphersson@COMPANY.LOCAL (server afpserver/fileserver.inhouse.com@COMPANY.LOCAL)

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: acquire_kerberos: erikphersson@COMPANY.LOCAL with pw:yes cert:no

Apr 15 14:46:57 Olofs-IMac NetAuthSysAgent[257] <Debug>: acquire_kerberos: trying with erikphersson@COMPANY.LOCAL as client principal

Reply

Answer 5

eckeph Author

Level 1

8 points

Apr 18, 2013 12:55 AM in response to eckeph

Ok, I gave up trying to fix this isssue and started upgrading all the 10.7.5 Macs to 10.8 instead which fixes the problem. The only information I got is that for one reason or another 10.7 are having problems dealing with Kerberos. Don't ask me for the source on that since it was something a Mac tech told me he had heard from somewhere...

Reply

Answer 6

Apr 26, 2013 10:13 AM in response to eckeph

Your solution makes me sad. We have no Mac OS X v10.7 users to upgrade and I'm having a similar problem. Those exact errors are being logged when one of my OD Master users tries to log into an AFP share on a 10.8.3 server. And my client is on 10.8.3, too. My client is bound to a *different* OD master that is running 10.6.8, and I am leaning on beliueving this to be our problem. I'll investigate further...

Reply

Answer 7

Apr 26, 2013 10:26 AM in response to M Delfino

I have unbound from all OD Masters on my client. I get the same error. I have done an authenticated bind to the OD Master upon which the AFP server is running and now I get this message:

4/26/13 12:18:33.843 PM kdc[49]: Got a canonicalize request for a LKDC realm from local-ipc 4/26/13 12:18:33.844 PM kdc[49]: Asked for LKDC, but there is none 4/26/13 12:18:33.848 PM kdc[49]: AS-REQ mdelfino@SERVER.DOMAIN.LOC from 10.0.0.100:56585 for krbtgt/SERVER.DOMAIN.LOC@SERVER.DOMAIN.LOC 4/26/13 12:18:33.854 PM kdc[49]: AS-REQ mdelfino@SERVER.DOMAIN.LOC from 10.0.0.100:56585 for krbtgt/SERVER.DOMAIN.LOC@SERVER.DOMAIN.LOC 4/26/13 12:18:33.855 PM kdc[49]: Client sent patypes: REQ-ENC-PA-REP 4/26/13 12:18:33.855 PM kdc[49]: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ 4/26/13 12:18:33.862 PM kdc[49]: AS-REQ mdelfino@SERVER.DOMAIN.LOC from 10.0.0.100:55791 for krbtgt/SERVER.DOMAIN.LOC@SERVER.DOMAIN.LOC 4/26/13 12:18:33.866 PM kdc[49]: AS-REQ mdelfino@SERVER.DOMAIN.LOC from 10.0.0.100:55791 for krbtgt/SERVER.DOMAIN.LOC@SERVER.DOMAIN.LOC 4/26/13 12:18:33.867 PM kdc[49]: Client sent patypes: ENC-TS, REQ-ENC-PA-REP 4/26/13 12:18:33.867 PM kdc[49]: ENC-TS pre-authentication succeeded -- mdelfino@SERVER.DOMAIN.LOC 4/26/13 12:18:33.867 PM kdc[49]: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, using aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96 4/26/13 12:18:33.867 PM kdc[49]: Requested flags: canonicalize 4/26/13 12:18:33.886 PM kdc[49]: TGS-REQ mdelfino@SERVER.DOMAIN.LOC from 10.0.0.100:58925 for afpserver/server.domain.loc@SERVER.DOMAIN.LOC [canonicalize]

It all actually looks good, but my authentication window on the client shakes me off every time. Any ideas about what I'm doing wrong?

Reply

Answer 8

Apr 26, 2013 11:08 AM in response to M Delfino

I got it. In Server.app, you have to click on Groups in the Server app, under Accounts. Choose the group(s) to which you want to grant access to the share(s), click the cog-wheel pop-up at the bottom and selecting "Edit Access to Services…" then check the box next to "File Sharing." Boom. Frustrating problem solved.

This works the same for individual users, too.

Reply

Answer 9

jimmayl

Level 1

5 points

May 9, 2013 2:40 PM in response to M Delfino

This did the trick for me, too; thank you for sharing!

Reply

Answer 10

tyeguy37

Level 1

0 points

Oct 3, 2013 8:44 AM in response to M Delfino

Thanks M Delfino - these instructions worked for us!

Reply