?
Solved

Migrated users cannot access resources in source domain even though sid history is enabled.

Posted on 2014-01-22
2
Medium Priority
?
5,947 Views
Last Modified: 2014-01-27
This is a similar situation to the question asked by WeirdFishes in 2011.  I'm working on cross-forest migration, with one domain per forest.  A test user has been migrated to the target domain (Windows 2008) but cannot access resources now in the source domain (Windows 2003).  I have a two-way forest trust setup.  Using the test user in the target domain, I can access resources in the source domain where all users have permissions, but a folder where the test user account in the source domain has specific permission cannot be accessed.

I've confirmed that the test user account in the target domain has the correct SID history.

Can you help?
0
Comment
Question by:vphul
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
2 Comments
 
LVL 37

Accepted Solution

by:
Mahesh earned 2000 total points
ID: 39802141
Have you disabled SID Filtering and enabled SID History across the forest trust ?
If its not done source domain SID will get dropped by source domain when accessing resources from target domain over trust.
If not please enable SID history and disable SID filtering across forest trust from target domain controller
You must be run below command through elevated command prompt and you must be logged on as root domain "domain administrator in target domain
Also your account must be present in source domain built-in administrators group

To disable SID filtering:
netdom trust <source domain FQDN> /domain:<trusted domain> /Quarantine:NO

To Enable SID filtering:
netdom trust <source domain FQDN> /domain:<trusted domain> /EnableSIDHistory:yes

http://blogs.technet.com/b/csstwplatform/archive/2010/05/06/how-to-disabling-sid-filter-quarantining-allowing-sid-history.aspx

Both commands should get completed successfully.
Then force replication in source domain.

Also I suggest you to remigrate all groups in merge mode with SID History post your user migration is completed as it will help to fix target users group membership wrt source domain.
At least migrate those affected groups with SID History to which user is member of.

Then logoff user once and try to access shared folder in source domain.

Also i suggest you instead of granting access to individual users in source domain, grant access to security groups and make individual users member of security groups.
Ensure that all source domain security groups are migrated 1st, then all users and then remigrate groups in merge mode with SID History for best \ accurate results as far as possible.

Mahesh
0
 

Author Comment

by:vphul
ID: 39812092
Hello Mahesh,

Thanks very much for your comment.  I had enabled SID history but not disabled SID filtering.  I'm very pleased to report that my test user can now access the resources in the source domain.

Thanks very much for your help.
0

Featured Post

Does Powershell have you tied up in knots?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Resolving an irritating Remote Desktop connection that stops your saved credentials from being used.
Compliance and data security require steps be taken to prevent unauthorized users from copying data.  Here's one method to prevent data theft via USB drives (and writable optical media).
This tutorial will show how to configure a single USB drive with a separate folder for each day of the week. This will allow each of the backups to be kept separate preventing the previous day’s backup from being overwritten. The USB drive must be s…
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…
Suggested Courses

800 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question