Hello!
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.
I ran Directory Service in debug mode using the command:
sudo killall -USR1 Directory Services
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!).
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
125280141129637898884104238047875342101630266299749908962906167109467378870509676263414275741172253977858037810862804861395704905837770232525646712346803415386444466661845563138100584912815361849819424235063659051097507184908146871399560606234901931006996837483144372834668945058758755820591527550008022187537
email@hidden:172.16.8.21
2007-11-07 14:17:32 CET - CLDAPv3Plugin: LookupAttribute value
found ;Kerberosv5;0x467292e57ffe2d72000001ac000001ab;email@hidden
;ODEN.AFTONBLADET.SE;1024 35
125280141129637898884104238047875342101630266299749908962906167109467378870509676263414275741172253977858037810862804861395704905837770232525646712346803415386444466661845563138100584912815361849819424235063659051097507184908146871399560606234901931006996837483144372834668945058758755820591527550008022187537
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
125280141129637898884104238047875342101630266299749908962906167109467378870509676263414275741172253977858037810862804861395704905837770232525646712346803415386444466661845563138100584912815361849819424235063659051097507184908146871399560606234901931006996837483144372834668945058758755820591527550008022187537
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.
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:
sudo mkpassdb -dump
slot 0427: 0x467292e57ffe2d72000001ac000001ab lincon
11/07/2007 02:41:27 PM
Yet, the authentication fails:
2007-11-07 14:17:32 CET - PasswordServer PlugIn: SASL authentication
error 0
I noticed when browsing the PasswordServer database that I have
duplicates in the database, for example:
slot 0017: 0x4659c5616cf2592a0000001200000011 ianvan
08/22/2007 06:23:48 PM
slot 0021: 0x4659caf612b0207f0000001600000015 ianvan
11/07/2007 03:17:14 PM
How can that happen, when no two users or machines can have the same
shortname?
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.
Any ideas or suggestions?
Best regards
Ian
____________________________________________
I A N V Ä N N M A N
Teknisk affärsutvecklare / Technical Business Developer
AFTONBLADET
Postal address: SE-105 18, Stockholm, Sweden.
Internet: www.aftonbladet.se
E-mailadress: email@hidden
Telephone: +46 (0)8-725 20 00
Mobile: +46 (0)706 01 27 58
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden
This email sent to email@hidden
