(2006-12-01) NT4, W2K3, Trusts And Security Policies
Posted by Jorge on 2006-12-01
Last Tuesday (28-11-2006), almost at the end of the day, and old customer (Customer "X") called me and told me they were having issues with the interoperability between their NT4 environment (yes, they still exist! 😉 ) and their AD environment. As I had no important plans for that evening I decided to go and help them out.
The issue was that users in the AD environment (W2K3 SP1) were not able to access data in the NT4 environment and it was getting worse and worse. In that case there was a two-way trusts in place between the AD environment and the NT4 environment. The one-way trust from AD (outgoing) to NT4 (incoming) still worked, but not the other way around (from NT4 (outgoing) to AD (incoming)).
The trust was in place, but the secure channel died that day for some reason. Because of latency in AD replication I was able to see the trust password was last changed on the 21st and that it changed on that day (as expected – 7 days later).
Resetting the secure channel was not an option as one of the end points was NT4. To be able to do that with either DOMAIN.MSC or NETDOM both domains must be at least Windows 2000 Server based or later. So the only option was to recreate the trust. Because of the trust issues we tried multiple times to recreate the trust. Sometimes we were able to recreate or we got errors/messages like "access denied" or "could not find a domain controller"…
So lets examine this:
- The trusts (both ways) have been in place for years
- It has worked with the current configuration
- Adding NT4 security principals to AD security principals (membership) or AD resources (ACEs) worked
- Adding AD security principals to NT4 security principals (membership) or NT4 resources (ACEs) did worked until the trust from NT4 to AD broke
- AD groups or resources did NOT show unresolved SIDs
- NT4 groups or resources did show unresolved SIDs
- Creation of the trust sometimes succeeded but most of the times it did not.
Something must either have changed that day to prevent the creation and configuration of the trust OR some configuration was put in place after the first trust creation years ago that allowed the trust to work until it broke
Thinking about this, it was time to check GPOs linked to the Domain Controllers OU and their GPO settings. Customer "X" only had the Default Domain Controllers Policy linked to the Domain Controllers OU and nothing else. The first thing we saw right away after comparing their policy settings (User Rights and Security Options) with the default configured policy settings. It was like comparing the colours black and white. The differences were huge!
Looking at the articles"MS-KBQ889030 ("Trust between a Windows NT domain and an Active Directory domain cannot be established or it does not work as expected")" and "MS-KBQ823659("Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments")", the solution we all thought of was to relax the security settings on the AD side. We followed the recommendations as mentioned in the first article for the security settings. After that we were to recreate the trust and access to the NT4 resources from the AD side was restored.
Everyone was happy! Customer was happy as the business was able to continue to work the next day and we were able to go home and go to sleep. For me, the next day was an appointment with another customer about migration scenarios. It was midnight before I saw my bed. ;-(
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########