A customer of mine raised an issue in regards network drives not being mapped for users. This includes drives mapped via Group Policy and Home Drives mapped via the NT4 Home Drive option of the Active Directory user account.
When users attempt to navigate to the UNC paths manually or map a drive manually it works as expected, however mapping network drives automatically upon logon simply did not work.
Also users were unable to navigate to the domain name "\\domain.local". However users could navigate to "\\domain.local\netlogon" and "\\domain.local\sysvol". Navigating to the domain root resulted in this error being generated:
\\domain.local is not accessible. You might not have permissions to use this network resource. Contact the administrator of this server to find out if you have access permissions.
Logon Failure: The target account name is incorrect.
When users attempt to navigate to the UNC paths manually or map a drive manually it works as expected, however mapping network drives automatically upon logon simply did not work.
Also users were unable to navigate to the domain name "\\domain.local". However users could navigate to "\\domain.local\netlogon" and "\\domain.local\sysvol". Navigating to the domain root resulted in this error being generated:
\\domain.local is not accessible. You might not have permissions to use this network resource. Contact the administrator of this server to find out if you have access permissions.
Logon Failure: The target account name is incorrect.
This issue with not being able to navigate to the domain root UNC share occurred on all member workstations and servers throughout the organisation. Domain Controllers were not effected by the issue.
The following three event logs were also found throughout the SYSTEM event log on all client workstations throughout the companies domain.
Log Name: System
Source: NETLOGON
Date: 26/10/2015 7:56:15 AM
Event ID: 5719
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: COMPUTER.domain.local
Description:
This computer was not able to set up a secure session with a domain controller in domain DOMAIN due to the following:
There are currently no logon servers available to service the logon request.
This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.
Log Name: System
Source: Microsoft-Windows-Security-Kerberos
Date: 23/10/2015 4:02:46 PM
Event ID: 4
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: COMPUTER.domain.local
Description:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server candc1$. The target name used was cifs/domain.local. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (DOMAIN.LOCAL) is different from the client domain (DOMAIN.LOCAL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.
Log Name: System
Source: Microsoft-Windows-GroupPolicy
Date: 28/10/2015 6:18:58 PM
Event ID: 1006
Task Category: None
Level: Error
Keywords:
User: DOMAIN\UserAccount
Computer: COMPUTER.domain.local
Description:
The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.
Some computers were also receiving:
The processing of Group Policy failed. Windows attempted to read the file \\domain.local\sysvol\domain.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:
a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.
This GUID referenced the Default Domain Policy (the first policy in the domain). There was nothing wrong with the Default Domain Policy on the customers network, policy was simply not applying to domain members due an issue in Active Directory.
One issue which I focused on was the Kerberos error "KRB_AP_ERR_MODIFIED". I have seen this issue before when the same SPN was registered on at least two accounts. For example, a SPN was registered on two accounts: A and B. What happens is that KDC will generate a service ticket that may be encrypted with password of account A. Then, when the client sends that ticket to the service during authentication, the service may try to decrypt this using account B.
I searched the customers domain for duplicated SPN's using "setspn.exe -X" and found some however they were not related to the error received. Also I have never seen the "KRB_AP_ERR_MODIFIED" error generated on EVERY domain member workstation/server in an Active Directory environment.
Looking further into the SPN's we decided to dump the entire domain with every object/attribute to a text file using:
ldifde -f out.txt -d dc=domain,dc=local
Generally SPN against a user account reference a member server on the network running a particular service account such as SQL However as this issue was affecting the entire domain and KRB_AP_ERR_MODIFIED refers to duplicated SPN records, we looked to see if there were any SPNs set at domain level on an account by searching our output from ldifde for "host/domain.local".
We found an SPN set to the root of the domain from the search results. Important content from output below is blurred to protect the privacy of the customer.
We went and removed the incorrectly setup SPN record from the problematic service account svc_adfs using Active Directory Users and Computers with Advanced Features turned on then forced replication with "repadmin /syncall /APeD".
The issues with network drives not mapping on logon were also resolved.
The SVC_ADFS account was created as part of an AD FS deployment for federation with applications and Microsoft Cloud Services. AD FS backend roll was installed on two corporate domain controllers and two proxy servers were deployed in a DMZ setup to process the authentication requests from external services. This is the Microsoft Best Practice for corporate organisations under 1000 seats as it reduces the amount of servers required and provides high redundancy by leveraging NLB on both the backend and frontend AD FS servers as per:
https://msdn.microsoft.com/en-us/library/azure/dn151324.aspx
I went over the engineers build documentation who was in charge of implementing AD FS and could not see how the SPN was set, he did not manually set it.
Hope this post helps someone who experiences this same issue.
I searched the customers domain for duplicated SPN's using "setspn.exe -X" and found some however they were not related to the error received. Also I have never seen the "KRB_AP_ERR_MODIFIED" error generated on EVERY domain member workstation/server in an Active Directory environment.
Looking further into the SPN's we decided to dump the entire domain with every object/attribute to a text file using:
ldifde -f out.txt -d dc=domain,dc=local
Generally SPN against a user account reference a member server on the network running a particular service account such as SQL However as this issue was affecting the entire domain and KRB_AP_ERR_MODIFIED refers to duplicated SPN records, we looked to see if there were any SPNs set at domain level on an account by searching our output from ldifde for "host/domain.local".
We found an SPN set to the root of the domain from the search results. Important content from output below is blurred to protect the privacy of the customer.
We went and removed the incorrectly setup SPN record from the problematic service account svc_adfs using Active Directory Users and Computers with Advanced Features turned on then forced replication with "repadmin /syncall /APeD".
After removing the incorrectly configured SPN, we purged the kerberos tickets off a workstation then attempted to start explorer at the root of the domain "\\domain.local". We were able to navigate to this share successfully.
The SVC_ADFS account was created as part of an AD FS deployment for federation with applications and Microsoft Cloud Services. AD FS backend roll was installed on two corporate domain controllers and two proxy servers were deployed in a DMZ setup to process the authentication requests from external services. This is the Microsoft Best Practice for corporate organisations under 1000 seats as it reduces the amount of servers required and provides high redundancy by leveraging NLB on both the backend and frontend AD FS servers as per:
https://msdn.microsoft.com/en-us/library/azure/dn151324.aspx
I went over the engineers build documentation who was in charge of implementing AD FS and could not see how the SPN was set, he did not manually set it.
Hope this post helps someone who experiences this same issue.
This is dummy text. It is not meant to be read. Accordingly, it is difficult to figure out when to end it. But then, this is dummy text. It is not meant to be read. Period.
ConversionConversion EmoticonEmoticon