Link to home
Start Free TrialLog in
Avatar of briancullen
briancullen

asked on

Setting ACL permissions after creating user with DC replication lag possible?

Hello,

I'm creating a user Programmatically, which works just fine. Right after, I create the users home directory and set the permission for

domain\domain admins
domain\newlycreateduser

I believe the problem I'm running into is

1) When I run the program from the headquarters building the user is being added to the correct DC but is then being read by a different DC.
2) There is replication lag and so the user cannot be found and I get a IdentityNotMappedException (since it can't find the user to translate)

I'm authenticating my directoryentries as follows, using the same DC across all domains so that it will pick the right DC for germany, netherlands, austria, etc...depending on which DC I am creating the user.

    Dim dirEntry As New DirectoryEntry()
        dirEntry.Path = "LDAP://000DC01-XX.ad.company.com/OU=Users,DC=XX,DC=ad,DC=company,dc=com
        dirEntry.Username = XX & "\Domain-Admin"
        dirEntry.Password = "password"

Open in new window

This works fine and I can create users and directories on all writable DCs.

Then I try to set the ACL rules and create the directory (Where item is a listviewdataitem):
 Dim securityRules As DirectorySecurity = New DirectorySecurity()

securityRules.AddAccessRule(New FileSystemAccessRule(XX & "\" & Item("SamAccountName").ToString, FileSystemRights.FullControl, InheritanceFlags.ContainerInherit, PropagationFlags.None, AccessControlType.Allow))
 
securityRules.AddAccessRule(New FileSystemAccessRule(XX & "\" & Item("SamAccountName").ToString, FileSystemRights.FullControl, InheritanceFlags.ObjectInherit, PropagationFlags.InheritOnly, AccessControlType.Allow))
             

Open in new window



I've tried, as suggested, reading the SID of the created user and using that instead of the account name but that didn't work, same translation error. Perhaps I did not do the translation correctly, I don't know... it did give me an SID when I queried the user but I read it as a string.

As a minor workaround, I can create the user on 000DC01 (the one I'm using for all directory entries) and also 199DC01 (which is probably the one the DirectorySecurity is trying to read from), then I don't get an error and the acl goes through like it should.

So if anyone has any ideas of what I can do to either properly avoid SID translation or somehow authenticate to a specific DC for the DirectorySecurity to look I would very much appreciate it. Please be aware that I consider myself a novice/intermediate programmer.

Thanks!
Avatar of LesterClayton
LesterClayton
Flag of Norway image

Replication lag is always possible - even with servers using Intra-Site replciation.  I'm not sure that replication lag is your issue though - I think the issue is that the global catalog needs to be populated with the new SID's, and while this happens quickly - it's not instant.

I've had this same issue in the past and all I did was add a delay between creating the groups, and then performing other things to them such as nesting them or setting ACL's.

My script waits 3 seconds after creating the objects - ever since adding this in, it's never failed to run.

Write-Host "`nWaiting 3 seconds, to ensure that the AD Groups have syhcnronized with the Global Catalog" -ForegroundColor Cyan
Start-Sleep 3

Open in new window

Avatar of briancullen
briancullen

ASKER

Hi Lester,

thanks for the reply. i've done some more testing throughout the day and have found that it takes between 10-15 minutes to replicate from the main DC GC to the second DC GC. If I pause and wait for 20 minutes the ACLs get added successfully.

If I write to both DCs I get objects with CNF:<objectID> which I need to delete later.

I guess the delay is not something I can overcome at this point. Is there any way to keep queries, writes, and searches confined to the specific AD Server?

Thanks
ASKER CERTIFIED SOLUTION
Avatar of LesterClayton
LesterClayton
Flag of Norway image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
It doesn't seem to have any affect at all. The first time I tried it, I though it worked as I saw the account on both DCs but alas, I think it was just a coincidence.

PsExec v2.2 - Execute processes remotely
Copyright (C) 2001-2016 Mark Russinovich
Sysinternals - www.sysinternals.com


CALLBACK MESSAGE: SyncAll Finished.
SyncAll terminated with no errors.

repadmin exited on 199SVDC01.xx.ad.compny.com with error code 0.

Open in new window


It seems to run through and I've tried all three GC, writable DCs and even synced the RODCs but no change at all. Each domain has 2 GC DCs and then 1 per location, meaning there could be up to 50 per domain. Usually they all write to the same DC for their Domain but each time the ACL tries to get added it just picks the DC I'm currently on.

Somehow I don't think there's a solution to my problem as it seems to be more related to sync times being enormous. i do appreciate the help though.
Ok so I believe I have the answer thanks to you.

The syncall didn't give me the desired results but I'm now using the following to sync the GC DC down to the current RODC where I'm setting the ACL on for remote sites.

Format:
PsExec <domaincontroller to run on> <user> <password> repadmin /replicate <destinationDC> <sourceDC> <Domain> </readonly for RODC dest>

psexec \\XXXSVDC01.XX.ad.company.com -u Ent\EntpriseAdmin -p password repadmin /replicate XXXSVDC01.XX.ad.company.com 000SVDC01-XX.XX.ad.company.com DC=XX,DC=ad,DC=company,DC=com /readonly

Open in new window