On Mon, Feb 04, 2013 at 09:55:07PM -0800, Ray Van Dolson wrote:
On Fri, Feb 01, 2013 at 04:47:48PM -0800, Ray Van Dolson wrote:
On Fri, Feb 01, 2013 at 04:39:26PM -0800, Ray Van Dolson wrote:
We're having authentication issues with SCCM pointed at a CIFS share on a filer running ONTAP 8.0.x. SCCM uses a domain computer account to authenticate (our filer is also joined to our domain).
We've added the computer account at the share level (as well as "Domain Computers") with full permissions, but continue to get authentication denied errors back from the filer.
Speficially:
This reads like the problem is with AD rejecting the login, but when we point to another CIFS share on a real Windows box we don't get the same problem, so we don't think that's the case.
We came across this KB article[1] which seems to disable the use of the computer account for authentication. However, this seems to send *no* authentication information at all (anonymous?) which of course is rejected as well.
Help?
We'll be reaching out to support as well.
Thanks, Ray
[1] https://kb.netapp.com/support/index?page=content&id=2013374
Also stumbled across this:
http://samba.2283325.n4.nabble.com/ncacn-np-NETLOGON-with-workstation-trust-account-ok-tt2482146.html#a2482147It relates to Samba, but makes it sound like the above errors could be because the filer doesn't include the MSV1_0_ALLOW_WORKSTATION_TRUST_ACCOUNT flag in its logon request to the domain controller.
pktt may help me prove that out...
Thanks for all the replies. We're waiting for some additional direction from NetApp on this, and also considering adding additional SPN's per this tip[1].
Will let everyone know how it goes.
Thanks, Ray
[1] http://social.technet.microsoft.com/Forums/en-US/ocsplanningdeployment/threa...
FYI adding additional SPN's is almost certainly the answer. When we joined this filer to the domain we used a "generic" name -- FILER. However, as it has multiple interfaces, it's actually referenced in DFS by FILERV49 (which repreents the VLAN ID of the network that particular interface is on).
When connections to the filer are initiated by a system or computer account, during the Kerberos negotiation, the FILERV49 name is passed through to the KDC as the principal. The KDC only knows about 'FILER' though and rejects the Kerberos negotiation with a principal unknown error. This forces our client to fall back to NTLM which results in the trust account error above.
Yet to try it, but fairly confident adding FILERV49 as an additional SPN will solve our issue.
Thanks, Ray