[Dr.Junk]

UPDATE.

You can confirm this behavior by turning on debug in fcsvr itself.

cd to /Library/Application Support/Final Cut Server/Final Cut Server.bundle/Contents/Resources/sbin/fcsvr_debug and run:
[b]./fcsvr_ctl.sh debug[/b]
then restart fcsvr (either through sysprefs or via ./fcsvr_ctl.sh stop; ./fcsvr_ctl.sh start

The authentication process then shows (for both successful and failing external ldap attempts):
[code]10:21:58.984492 0xb0114000 DEBUG2 doCRAMMD5AuthStep auth.C:342 [DS] using response:21ef4cdd1cd48cc3bee59f0a57cfed6c8[/code]
From ealier lines in the log there’s no evidence that any auth methods other than cram-md5 are attempted.

For more info on fcsvr command line tools see: [url]http://krypted.com/final-cut-server/the-final-cut-server-command-line/[/url]

[Dr.Junk]

I think I’ve found the cause. Appears that when FCSvr (fcsvr_stored) negotiates with DirectoryService it always ends up deciding that it should send a CRAM-MD5 hash for authentication.
See below for an example from /Library/Logs/DirectoryService/DirectoryService.debug.log after turning on debug with killall -USR1 DirectoryService (ldap hostname and usernames replaced with dummy placeholder values):
[code]2011-02-08 13:47:01 EST – T[0xB0103000] – Client: fcsvr_stored, PID: 12412, API: dsOpenDirNode(), LDAPv3 Used : DAC : Dir Ref = 16800117 : Node Name = /LDAPv3/ldaphostname)
2011-02-08 13:47:01 EST – T[0xB0103000] – Client: fcsvr_stored, PID: 12412, API: dsOpenDirNode(), LDAPv3 Used : DAR : Dir Ref = 16800117 : Node Ref = 16800122 : Result code = 0
2011-02-08 13:47:01 EST – T[0xB0207000] – Client: fcsvr_stored, PID: 12412, API: dsDoDirNodeAuth(), LDAPv3 Used : DAC : Node Ref = 16800122 : User Name = ldapusername) : Auth Method = dsAuthMethodStandard:dsAuthNodeCRAM-MD5 : Auth Only Flag = 1 : Continue Data = 0
2011-02-08 13:47:01 EST – T[0xB0207000] – CLDAPv3Plugin: DoAuthenticationOnRecordType – Attempting use of authentication method dsAuthMethodStandard:dsAuthNodeCRAM-MD5
2011-02-08 13:47:01 EST – T[0xB0207000] – CLDAPv3Plugin: LookupAttribute error -14131
2011-02-08 13:47:01 EST – T[0xB0207000] – CLDAPv3Plugin: DoBasicAuth::
2011-02-08 13:47:01 EST – T[0xB0207000] – CLDAPv3Plugin: DoBasicAuth – Attempting use of authentication method dsAuthMethodStandard:dsAuthNodeCRAM-MD5
2011-02-08 13:47:01 EST – T[0xB0207000] – Client: fcsvr_stored, PID: 12412, API: dsDoDirNodeAuth(), LDAPv3 Used : DAR : Node Ref = 16800122 : Result code = -14091
2011-02-08 13:47:01 EST – T[0xB0207000] – Plug-in call “dsDoDirNodeAuth()” failed with error = -14091.
2011-02-08 13:47:01 EST – T[0xB0207000] – Port: 0 Call: dsDoDirNodeAuth() == -14091[/code]
For security reasons our OpenLDAP server does not support MD5 hashes so it fails every time with a -14131 (eDSInvalidAttributeType – see DS manpage here: [url]http://www.manpagez.com/man/8/DirectoryService/[/url]) and then a -14091 (eDSAuthMethodNotSupported), which is what shows up /var/log/system.log and in /Library/Logs/Final Cut Server/fcsvr_stored_xxxxx.log
You can test and break FCSvr auth for local accounts by simply disabling CRAM-MD5 in Workgroup Manager on a local account (select the local account, Advanced Tab -> Security -> uncheck CRAM-MD5, Save). Any attempt to log in to FCSvr as a local user will then fail, even though there are still other hash methods available for shadow password auth (e.g. NTLMv1 and 2). This is because FCSvr is still wanting to user CRAM-MD5 for authentication
[code]2011-02-08 17:41:35 EST – T[0xB0218000] – Client: fcsvr_stored, PID: 21733, API: dsOpenDirNode(), Local Used : DAC : Dir Ref = 16777551 : Node Name = /Local/Default
2011-02-08 17:41:35 EST – T[0xB0218000] – Client: fcsvr_stored, PID: 21733, API: dsOpenDirNode(), Local Used : DAR : Dir Ref = 16777551 : Node Ref = 16777556 : Result code = 0
2011-02-08 17:41:35 EST – T[0xB0103000] – Client: fcsvr_stored, PID: 21733, API: dsDoDirNodeAuth(), Local Used : DAC : Node Ref = 16777556 : User Name = localusername : Auth Method = dsAuthMethodStandard:dsAuthNodeCRAM-MD5 : Auth Only Flag = 1 : Continue Data = 0
2011-02-08 17:41:35 EST – T[0xB0103000] – CDSLocalPlugin::ReadHashConfig(): got error -14136
2011-02-08 17:41:35 EST – T[0xB0103000] – CDSLocalPluginNode::GetFileAccessIndex – found match in index – type file
2011-02-08 17:41:35 EST – T[0xB0103000] – CDSLocalAuthHelper::DoShadowHashAuth(): Attempting use of authentication method dsAuthMethodStandard:dsAuthNodeCRAM-MD5
2011-02-08 17:41:35 EST – T[0xB0103000] – Client: fcsvr_stored, PID: 21733, API: dsDoDirNodeAuth(), Local Used : DAR : Node Ref = 16777556 : Result code = -14090
2011-02-08 17:41:35 EST – T[0xB0103000] – Plug-in call “dsDoDirNodeAuth()” failed with error = -14090.
2011-02-08 17:41:35 EST – T[0xB0103000] – Port: 0 Call: dsDoDirNodeAuth() == -14090[/code]
even though this hash mechanism should not even be available. You can switch User Password Type to “Open Directory” in WGM for this user and it still won’t be able to authenticate, as FCSvr will keep wanting to send CRAM-MD5 hashes and as this no longer exists in the Local database it will fail. You have to re-enable CRAM-MD5 hashes in WGM and reset the password to re-generate the MD5 hash for FCSvr auth to work again for this user. macchiato – this could explain why you’re having to go through resetting passwords for auth to work.
If this is the issue, then I don’t have any sensible workarounds, it looks like Apple may have to modify the code for fcsvr_stored and release a patch? Does anyone have any ideas?

[Dr.Junk]

I’m hitting a similar error on a OS 10.5.8 server. DirectoryService is configured to authenticate users via an external OpenLDAP serverr (RFC 2307) and it works perfectly for authentication for our other services we’re running on this server (sshd, filemaker server).

However we’re trying to get our FinalCut Server authentication happening and hitting the same snag, i.e. any non-local (i.e. LDAP) user cannot login and the only clue is the dsDoDirNodeAuth error (-14091) error written to system.log every time a ldap user attempts authentication.

[Dr.Junk]

This is a very interesting thread. I just returned under warranty a 500GB Seagate ST3500320NS Barracude ES.2 drive which was part of a spontaneously recurring degraded RAID-1 array only to find the replacement drive exhibited _exactly_ the same characteristic as the “failed” drive. (i.e. exactly the same profile as described above). Attached the replacement drive via external SATA to my machine and gave it a thorough thrashing and then ran all the Seatools tests on the replacement drive only to find the drive was functioning perfectly (so I now strongly suspect the original drive was also not faulty).

I was left perplexed in a similar fashion to what people describe above. I ended up sticking the stupid 80GB pair of Apple supplied drives back in my brand new xserve to avoid wasting any more time/money. Like others the whole reason I purchased the pair of 500GB barracudas was to save money since the only other alternative to the 80GB drives from Apple was overpriced pair of 1TB drives.

I’m not going to bother putting the 1.5Gbps clip back on my drives and re-testing to see if this overcomes the apple raid dma timing issue, I feel like I’ve already wasted enough time with this pretty much undocumented problem. I also don’t feel like hobbling my drives to get it to function with apple’s raid, I’d prefer to save them and use them where they can be better utilised.

Leaves me with a bit of a sour taste in my mouth though…

[Author]

Posts