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:
Fri Feb 1 16:28:27 PST [red-str-napc2-p2: auth.trace.authenticateUser.loginTraceIP:info]: AUTH: Login attempt by user red-inf-cm-p01$ of domain DOMAIN from client machine 1.1.1.1 (RED-INF-CM-P01). Fri Feb 1 16:28:27 PST [red-str-napc2-p2: auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- attempting authentication with domain controller \REDDC1. Fri Feb 1 16:28:27 PST [red-str-napc2-p2: auth.trace.authenticateUser.loginRejected:info]: AUTH: Login attempt by user rejected by the domain controller with error 0xc0000199: STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT. Fri Feb 1 16:28:28 PST [red-str-napc2-p2: auth.trace.authenticateUser.loginTraceIP:info]: AUTH: Login attempt by user red-inf-cm-p01$ of domain DOMAIN from client machine 1.1.1.1 (RED-INF-CM-P01).
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
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:
Fri Feb 1 16:28:27 PST [red-str-napc2-p2: auth.trace.authenticateUser.loginTraceIP:info]: AUTH: Login attempt by user red-inf-cm-p01$ of domain DOMAIN from client machine 1.1.1.1 (RED-INF-CM-P01). Fri Feb 1 16:28:27 PST [red-str-napc2-p2: auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- attempting authentication with domain controller \REDDC1. Fri Feb 1 16:28:27 PST [red-str-napc2-p2: auth.trace.authenticateUser.loginRejected:info]: AUTH: Login attempt by user rejected by the domain controller with error 0xc0000199: STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT. Fri Feb 1 16:28:28 PST [red-str-napc2-p2: auth.trace.authenticateUser.loginTraceIP:info]: AUTH: Login attempt by user red-inf-cm-p01$ of domain DOMAIN from client machine 1.1.1.1 (RED-INF-CM-P01).
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-...
It 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...
Ray
Is there universal groups on that share - maybe the filer can't reach a Global Catalog server Sent from my Verizon Wireless BlackBerry
-----Original Message----- From: Ray Van Dolson rvandolson@esri.com Sender: toasters-bounces@teaparty.net Date: Fri, 1 Feb 2013 16:47:48 To: toasters@teaparty.net Subject: Re: Authentication Issues w/ SCCM talking to filer via CIFS w/ Computer Account
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:
Fri Feb 1 16:28:27 PST [red-str-napc2-p2: auth.trace.authenticateUser.loginTraceIP:info]: AUTH: Login attempt by user red-inf-cm-p01$ of domain DOMAIN from client machine 1.1.1.1 (RED-INF-CM-P01). Fri Feb 1 16:28:27 PST [red-str-napc2-p2: auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- attempting authentication with domain controller \REDDC1. Fri Feb 1 16:28:27 PST [red-str-napc2-p2: auth.trace.authenticateUser.loginRejected:info]: AUTH: Login attempt by user rejected by the domain controller with error 0xc0000199: STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT. Fri Feb 1 16:28:28 PST [red-str-napc2-p2: auth.trace.authenticateUser.loginTraceIP:info]: AUTH: Login attempt by user red-inf-cm-p01$ of domain DOMAIN from client machine 1.1.1.1 (RED-INF-CM-P01).
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-...
It 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...
Ray _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Check for duplicate entries of IP address and computer object...
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Ray Van Dolson Sent: Friday, February 01, 2013 7:48 PM To: toasters@teaparty.net Subject: Re: Authentication Issues w/ SCCM talking to filer via CIFS w/ Computer Account
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:
Fri Feb 1 16:28:27 PST [red-str-napc2-p2:
auth.trace.authenticateUser.loginTraceIP:info]: AUTH: Login attempt by user red-inf-cm-p01$ of domain DOMAIN from client machine 1.1.1.1 (RED-INF-CM-P01).
Fri Feb 1 16:28:27 PST [red-str-napc2-p2:
auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- attempting authentication with domain controller \REDDC1.
Fri Feb 1 16:28:27 PST [red-str-napc2-p2:
auth.trace.authenticateUser.loginRejected:info]: AUTH: Login attempt by user rejected by the domain controller with error 0xc0000199: STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT.
Fri Feb 1 16:28:28 PST [red-str-napc2-p2:
auth.trace.authenticateUser.loginTraceIP:info]: AUTH: Login attempt by user red-inf-cm-p01$ of domain DOMAIN from client machine 1.1.1.1 (RED-INF-CM-P01).
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#a2482147
It 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...
Ray _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
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:
Fri Feb 1 16:28:27 PST [red-str-napc2-p2: auth.trace.authenticateUser.loginTraceIP:info]: AUTH: Login attempt by user red-inf-cm-p01$ of domain DOMAIN from client machine 1.1.1.1 (RED-INF-CM-P01). Fri Feb 1 16:28:27 PST [red-str-napc2-p2: auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- attempting authentication with domain controller \REDDC1. Fri Feb 1 16:28:27 PST [red-str-napc2-p2: auth.trace.authenticateUser.loginRejected:info]: AUTH: Login attempt by user rejected by the domain controller with error 0xc0000199: STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT. Fri Feb 1 16:28:28 PST [red-str-napc2-p2: auth.trace.authenticateUser.loginTraceIP:info]: AUTH: Login attempt by user red-inf-cm-p01$ of domain DOMAIN from client machine 1.1.1.1 (RED-INF-CM-P01).
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#a2482147
It 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...
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#a2482147
It 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
On Mon, Feb 04, 2013 at 11:07:02PM -0800, Ray Van Dolson wrote:
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#a2482147
It 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
Last follow up on this one. Adding additional service principal names (SPN's) resolved our issue.
Thanks everyone!
Ray