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.
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 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:
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.