We are experiencing a problem with our Mac OS X Server 10.4.8
PasswordServer. The problem reared itself after a recent unexpected
power outage. We use Periodik Labs Elektron server to allow our
Cisco 4400 WLAN Controller to authenticate users. After the power
outage which only struck our OS X Server, Elektron will not
authenticate users. We reason that the problem is with the
Directory Service, because Elektron works fine when using it's own
internal user database. When switching to using Directory Services
as for authentication it does not.
By this point in a msg it would be nice to hear what the problem you
think there is w DS. Sounds like your problem is with something else
entirely.
Browsing through the debug log I found that all authentication
attempts from Elektron failed. It is odd, because the Directory
Service is used by hundreds of clients and servers to authenticate
the users, but we don't have any problems with them (thank god!).
Indicating that DS seems to be working, which would lead someone,
normally, to presume a problem with some other thing was with
something else.
Here is a failed attempt:
2007-11-07 14:17:32 CET - Client: elektrond, PID: 1340, API:
dsDoDirNodeAuth(), LDAPv3 Used : DAC : Node Ref = 16815018 : User
Name = lincon : Auth Method = dsAuthMethodStandard:dsAuthMSCHAP2 :
Auth Only Flag = 0 : Continue Data = 0
2007-11-07 14:17:32 CET - CLDAPv3Plugin:
DoAuthenticationOnRecordType - Attempting use of authentication
method dsAuthMethodStandard:dsAuthMSCHAP2
2007-11-07 14:17:32 CET - CLDAPv3Plugin: Attempting to get
dsAttrTypeStandard:AuthenticationAuthority
2007-11-07 14:17:32 CET - CLDAPv3Plugin: LookupAttribute value
found ;ApplePasswordServer;0x467292e57ffe2d72000001ac000001ab,1024
35
1252801411296378988841042380478753421016302662997499089629061671094673
7887050967626341427574117225397785803781086280486139570490583777023252
5646712346803415386444466661845563138100584912815361849819424235063659
0510975071849081468713995606062349019310069968374831443728346689450587
58755820591527550008022187537 email@hidden:172.16.8.21
2007-11-07 14:17:32 CET - CLDAPv3Plugin: LookupAttribute value
found ;Kerberosv5;0x467292e57ffe2d72000001ac000001ab;email@hidden
BLADET.SE;ODEN.AFTONBLADET.SE;1024 35
1252801411296378988841042380478753421016302662997499089629061671094673
7887050967626341427574117225397785803781086280486139570490583777023252
5646712346803415386444466661845563138100584912815361849819424235063659
0510975071849081468713995606062349019310069968374831443728346689450587
58755820591527550008022187537 email@hidden:172.16.8.21
2007-11-07 14:17:32 CET - CLDAPv3Plugin: DoPasswordServerAuth::
2007-11-07 14:17:32 CET - CLDAPv3Plugin: Attempting use of
authentication method dsAuthMethodStandard:dsAuthMSCHAP2
2007-11-07 14:17:32 CET - Internal Dispatch, API: dsOpenDirService
(), Server Used : DAR : Dir Ref 16815068 : Result code = 0
2007-11-07 14:17:32 CET - Client: Requesting dsOpenDirNode with PID
= 0, UID = 0, and EUID = 0
2007-11-07 14:17:32 CET - Unable to determine fPluginPtr from node
table
2007-11-07 14:17:32 CET - Determined plugin ptr for call
2007-11-07 14:17:32 CET - Internal Dispatch, API: dsOpenDirNode(),
PasswordServer Used : DAC : Dir Ref = 16815068 : Node Name = /
PasswordServer/172.16.8.21
2007-11-07 14:17:32 CET - CPSPlugIn::OpenDirNode
2007-11-07 14:17:32 CET - CPSPlugIn::OpenDirNode path = /
PasswordServer/172.16.8.21
2007-11-07 14:17:32 CET - CPSPlugIn::EndServerSession opens: 495,
closes 450
2007-11-07 14:17:32 CET - Determined plugin ptr used and returns
result 0
2007-11-07 14:17:32 CET - Internal Dispatch, API: dsOpenDirNode(),
PasswordServer Used : DAR : Dir Ref = 16815068 : Node Ref =
16815069 : Result code = 0
2007-11-07 14:17:32 CET - Internal Dispatch, API: dsDoDirNodeAuth
(), PasswordServer Used : DAC : Node Ref = 16815069 : User Name =
0x467292e57ffe2d72000001ac000001ab,1024 35
1252801411296378988841042380478753421016302662997499089629061671094673
7887050967626341427574117225397785803781086280486139570490583777023252
5646712346803415386444466661845563138100584912815361849819424235063659
0510975071849081468713995606062349019310069968374831443728346689450587
58755820591527550008022187537 email@hidden : Auth
Method = dsAuthMethodStandard:dsAuthMSCHAP2 : Auth Only Flag = 0 :
Continue Data = 0
2007-11-07 14:17:32 CET - CPSPlugIn::DoAuthentication
2007-11-07 14:17:32 CET - PasswordServer PlugIn: Attempting use of
authentication method dsAuthMethodStandard:dsAuthMSCHAP2
2007-11-07 14:17:32 CET - GetAuthMethodConstant siResult=0,
uiAuthMethod=1241, mech=
2007-11-07 14:17:32 CET - hexHash=A3C2012F7C8342E3ED06FA5FD233CE2D
2007-11-07 14:17:32 CET - HandleFirstContact
2007-11-07 14:17:32 CET - BeginServerSession, inSock = -1
2007-11-07 14:17:32 CET - mech=SMB-NTLMv2
2007-11-07 14:17:32 CET - mech=SMB-NT
2007-11-07 14:17:32 CET - mech=MS-CHAPv2
2007-11-07 14:17:32 CET - mech=OTP
2007-11-07 14:17:32 CET - mech=NTLM
2007-11-07 14:17:32 CET - mech=GSSAPI
2007-11-07 14:17:32 CET - mech=DIGEST-MD5
2007-11-07 14:17:32 CET - mech=CRAM-MD5
2007-11-07 14:17:32 CET - mech=DHX
2007-11-07 14:17:32 CET - GetAuthMethodSASLName siResult=0, mech=MS-
CHAPv2
2007-11-07 14:17:32 CET - CPSPlugIn::DoSASLAuth
2007-11-07 14:17:32 CET - PasswordServer PlugIn: Attempting
Authentication
2007-11-07 14:17:32 CET - PasswordServer PlugIn: SASL
authentication error 0
2007-11-07 14:17:32 CET - CPSPlugIn::DoAuthentication returning 0
2007-11-07 14:17:32 CET - Internal Dispatch, API: dsDoDirNodeAuth
(), PasswordServer Used : DAR : Node Ref = 16815069 : Result code = 0
I know that the password being sent from the client is correct.
Indeed, as the above indicates that.
I know that the key being sent to PasswordServer (User Name =
0x467292e57ffe2d72000001ac000001ab) is correct, because it is
listed in the database that I looked up using the command:
How can that happen, when no two users or machines can have the
same shortname?
You misunderstand.
I suspect the database may be corrupt, but still it is strange that
authentications against the same Directory Service from other
services with the same users work without a problem.
Why do you suspect corruption?
It works w/o problems b/c there appears to be no problem with DS.
Look elsewhere and stop trying to fit a problem to a service that's
working.
Everything you presented so far isn't showing a problem.
WHat I haven't seen in the above is anything trying to authenticate a
users on your Cisco.
Have you tried restarting it??????
-dhan
------------------------------------------------------------------------
Dan Shoop
Computer Scientist
iWiring / U.S. Technical Services
