I'm trying out an AD 2003 migration in the lab and ran into an issues
where SID history doesn't seem to be working as I'm expecting it to
work.
I have two w2k3 native mode single forests/domains. There is a full
forest level trust with SID History enabled and Quarantine disabled
(via netdom trust <…> /EnableSIDHistory:yes and /Quarantine:No). I
have migrated a user via Quest QMM with SID History. Verifying the
principal via ADSIEDIT, I can see that objectSID in source domain
matches an entry in sIDHistory attribute in target domain for this
user.
To test that the SID history is working I'm trying a simple test. I
have created a share on a workstation in the source domain with a few
folders permissioned to the migrated user, to the group the user
belongs to, to EVERYONE, to no one, etc. I then login the user to a
workstation in the target domain and attempt to access the shared
folders.
My expectation were that I should be able to access a folder
permissioned to the user in the source domain via SID History. This,
however, did not work for me. I get access denied error. If I add
newly migrated user directly to folder, I am able to access it.
On the workstation with the folders I see NT AUTHORITY\ANONYMOUS
LOGON, Event ID: 540, every time I try to access a folder and get
permission denied.
Successful Network Logon:
User Name:
Domain:
Logon ID: (0x0,0x196CBC)
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: DANIEL-PC
Logon GUID: {00000000-0000-0000-0000-000000000000}
I have tried kerbtray, klist and tokensz utilities on the PC that I’m
connecting from, to try to see if I have the proper token, but I don't
think these tools will help me here.
Any idea and troubleshooting steps are highly appreciated.
Best regards,
Daniel S
hth
Marcin
"Daniel S" <dsh...@gmail.com> wrote in message
news:f9b0a02e-2ff4-42e1...@h31g2000yqd.googlegroups.com...
I get access denied while trying to access a folder permissioned
directly to the user from the source domain.
On Aug 14, 7:34 am, "Marcin" <mar...@community.nospam> wrote:
> Daniel,
> make sure that permissions on the folder you are testing grant direct access
> to the user account in the source domain - not via a group. If you are doing
> the latter, then you would need to migrate the group (with its sIDHistory)
> first...
>
> hth
> Marcin
>
> "Daniel S" <dshl...@gmail.com> wrote in message
Have you done what is suggested in the following link?
Enabling the use of SIDHistory
http://techrepublic.com.com/5208-6230-0.html?forumID=101&threadID=211113&messageID=2319523
/quoted from the above lnk:
---
I just resolved this issue at a customers site. An "undocumented"
requirement when using ADMT in a Windows 2003 forest.
On PDC run:
NETDOM TRUST trusting_domain_name /Domain:trusted_domain_name
/EnableSIDHistory:yes
/EnableSIDHistory Valid only for an outbound, forest trust. Specifying "yes"
allows users migrated to the trusted forest from any other forest, to use
SID history to access resources in this forest. This should be done only if
the trusted forest administrators can be trusted enough to specify SIDs of
this forest in the SID history attribute of their users appropriately.
Specifying "no" would disable the ability of the migrated users in the
trusted forest to use SID history to access resources in this forest.
Specifying
/EnableSIDHistory without yes or no will display the current state.
---
/endquote
--
Ace
This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.
Please reply back to the newsgroup or forum to benefit from collaboration
among responding engineers, and to help others benefit from your resolution.
Ace Fekay, MCT, MCTS Exchange, MCSE, MCSA 2003 & 2000, MCSA Messaging
Microsoft Certified Trainer
For urgent issues, please contact Microsoft PSS directly. Please check
http://support.microsoft.com for regional support phone numbers.
Even though I was sure that SIDhistory was enabled for the trust,
running "NETDOM TRUST BFCORP /Domain:BMSL /EnableSIDHistory" command
proved otherwise. Re-running NETDOM TRUST with /EnableSIDHistory:YES
has fixed the issue.
My appologies for not catching such obvious thing ealier.
On Aug 14, 10:02 am, "Ace Fekay [MCT]"
<ace...@mvps.RemoveThisPart.org> wrote:
> "Daniel S" <dshl...@gmail.com> wrote in message
>
> news:40b3dccd-2d79-4b89...@o35g2000vbi.googlegroups.com...
>
> > Thank you for your reply.
>
> > I get access denied while trying to access a folder permissioned
> > directly to the user from the source domain.
>
> Have you done what is suggested in the following link?
>
> Enabling the use of SIDHistoryhttp://techrepublic.com.com/5208-6230-0.html?forumID=101&threadID=211...
Even though I was sure that SIDhistory was enabled for the trust,
running "NETDOM TRUST BFCORP /Domain:BMSL /EnableSIDHistory" command
proved otherwise. Re-running NETDOM TRUST with /EnableSIDHistory:YES
has fixed the issue.
My appologies for not catching such obvious thing ealier.
Hey, no problem, and good to hear! Yep, one of those not so well documented
things... :-)
Cheers!
Ace