none
Setting an OU ACL in a remote (untrusted) forest via Powershell RRS feed

  • Question

  • I'm using Powershell to copy an OU structure and delegation from a production forest to a test one. There is (intentionally) no trust between production and test.

    The standard AD commandlets work fine when specifying the remote server and credentials (I can create the OUs without any issue), but I run into problems trying to copy the ACL.

    By using new-PSDrive and linking to the test forest this way, I am able to retrieve the current ACL using get-acl as usual.  However, when attempting to add an ace to the ACL the script errors due to "the trust relationship" between domains failing.  I should clarify that the ACE I am attempting to add is for a group object in the same domain as the OU.

    I can get the group (using get-adgroup) and find its SID that way, and create the ace using New-Object System.DirectoryServices.ActiveDirectoryAccessRule.  The rule is created fine (in an object I am calling $destACE), however when I try to add this access rule to the existing ACL (using $destACL.AddAccessRule($destACE) ) the error is

    Exception calling "AddAccessRule" with "1" argument(s): "The trust relationship between primary domain and trusted domain failed"

    Does anyone have any ideas of how to get around this?  As specified, I have created a PSDrive linked to the remote forest (bound with administrative credentials) which appears to work fine, at least in allowing me to read the existing ACL.

    I did notice that it doesn't resolve the SIDs in the existing ACL though either, which I'm sure is cause by the same fundamental issue.

    To summarise - DNS resolution is fine.  I can manipulate the remote forest using standard Active Directory commandlets with server and credentials specified.  I have created a PSDrive (ADTEST:) bound to the remote forest by specifying the same server and commandlets.  Within that drive I can use Get-Acl to return the existing ACL (within which SIDs are not resolved), but when I attempt to add a new ACE (created using a SID as the identity reference for the group in the remote forest) the script errors with an exception calling "AddAccessRule", complaining about the lack of trust relationship.


    The Voice of Shatner

    Wednesday, June 22, 2016 2:57 PM

Answers

  • I revisited this recently and came up with an answer, in case anybody else is reading this hoping to do the same thing. 

    So this is how to set an ACE in a domain when you are running PowerShell from a machine in an untrusted domain.  Ideal for managing development environments, etc, which you do not wish to have a trust relationship with.  (Note this is all in combination with the New-PSDrive get-acl/set-acl comments I made previously - I appreciate this is a very brief summary.  If anybody needs more info happy to share.)

    You do not need to be able to resolve the SID - just read it from the AD object!  Seems obvious in hindsight.

    E.g you can do a standard get-adgroup or get-aduser, etc, to look up the group name in question then read the SID from the object as follows:

    $GroupObj = get-adgroup <groupname> -Server <DC in untrusted domain> -Credential $SomePSCreds

    [System.Security.Principal.SecurityIdentifier]$GroupSID=$Groupobj.sid

    You can then use $GroupSID as the identity parameter when creating the new ACE (system.directoryServices.ActiveDirectoryAccessRul) without having to rely on the SID being resolved at any point.


    The Voice of Shatner

    Monday, February 26, 2018 2:32 PM

All replies

  • ACLs cannot be copied because the SIDS will never match.

    You should be using the server migration tools that are supplied to do this.  It will analyze the move and show you what needs to be created and then apply the changes.  It is very efficient and produces sufficient reports to validate the migration.


    \_(ツ)_/

    Wednesday, June 22, 2016 3:23 PM
  • That doesn't answer my question at all.  As I stated, I am using the AddAccessRule method to specify an ACE with a SID for a security principal in the target domain.

    I am aware there are other ways to do similar tasks.  I have a specific set of requirements here that means it would be ideal to be able to use PowerShell.  Does anyone know of a way to use a combination of Get-ACL and Set-ACL to add some ACEs to the ACL on an OrganizationalUnit in an untrusted domain/forest?


    The Voice of Shatner

    Wednesday, June 22, 2016 3:30 PM
  • You have to be authenticated on a domain as a Domain Admin to alter ACLs in AD.

    You can use Net directory access and authenticate on the remote domain but you will have to use Net to modify the ACL.

    Look in Gallery for examples.

    You can also use Invoke-Command and Ps remoting.


    \_(ツ)_/


    • Edited by jrv Wednesday, June 22, 2016 3:58 PM
    Wednesday, June 22, 2016 3:58 PM
  • Can you please read the question properly before answering?

    The Voice of Shatner

    Wednesday, June 22, 2016 4:03 PM
  • Get-Acl and Set-Acl do not support remoting.

    You can try to attach the remote AD as a drive and then they will work.

    To resolve SIDS you must bein a trust and have access to both members of the trust.  This cannot be done in an untrusted setting.

    You posted: "the script errors with an exception calling "AddAccessRule", complaining about the lack of trust relationship."

    That is the bottom line.

    The migration tools solves this by creating the accounts and tagging them with the original SID as well as creating another structures that allow for accessing the ACLs without having to resolve SIDS. It builds tables to do this.


    \_(ツ)_/


    • Edited by jrv Wednesday, June 22, 2016 4:09 PM
    Wednesday, June 22, 2016 4:06 PM
  • I did attach the remote AD as a drive...

    So you don't think it will work - that's fine.  Which migrations tools are you talking about?  I don't think that's suitable for what I'm doing.  There are other things I can do, I'm not exactly a novice in this game, but I would have liked to be able to run it all from a single powershell script.  Which is why I asked a question about powershell in a scripting forum.

    Anyone else have an opinion on this, or has anyone found a way to make set-acl work on a remote untrusted AD forest?


    The Voice of Shatner

    Wednesday, June 22, 2016 6:45 PM
  • The issue will always be trying to get authenticated cross domain.  If you authenticate in one domain then you can add any objects in that domain.  You cannot add objects from an untrusted domain.  There has never been a way to do that.

    The migration tool creates parallels account structure in the new domain and copied the account structure including any special delegation applied. It allows us to create a new AD structure that mirrors the old structure.

    For more information on how to do this and use these tools post you issue in the Directory Services forum.

    https://www.microsoft.com/en-us/download/details.aspx?id=19188

    https://technet.microsoft.com/en-us/library/cc974332(v=ws.10).aspx


    \_(ツ)_/

    Wednesday, June 22, 2016 7:58 PM
  • There's no issue authenticating across domains.  I can authenticate across domains.  I can connect the drive to the domain with admin credentials, create the OUs.

    ADMT is not the solution I'm looking for.  It's not suitable for this - not to mention ADMT requires a trust between domains.

    Once again - I asked a powershell question in a scripting forum.  I'm looking for an answer to that question.  If you have nothing specific to add, then please stop replying.  I don't want alternatives - I can come up with alternatives myself.  There are many peculiarities to this scenario, and I have no inclination to spend hours justifying why I want to do things this way. 

    All I want is a means of using powershell to set and acl in a untrusted domain.  I'm reluctant to accept that it's not possible, as I have managed many things that I was told were not possible in the past.

    \_(ツ)_/


    The Voice of Shatner

    Wednesday, June 22, 2016 8:05 PM
  • ADMT is you only mechanism.  Even if you can authenticate to both domains with credentials you cannot do cross domain ACLs with no trust.  Sorry.

    Of course I am still not able to decode exactly what you are asking. I recommend asking in the Directory Services forum where they can try to help you find a solution if one exists.


    \_(ツ)_/

    Wednesday, June 22, 2016 8:10 PM
  • Well if you can't "decode" what I'm asking then please stop replying.  This isn't a game of "give me an answer to any question you fancy".

    FYI ADMT is not the only way to do this (or a way to do this at all...since there is no trust between the domains).  You can copy OU structures any number of ways and you can set ACLs any number of ways (including batch files using DSACLS and VBScript). 


    The Voice of Shatner

    Wednesday, June 22, 2016 8:27 PM
  • No matter what you use you cannot reference an account from an untrusted domain.  I cannot understand you issue because you continue to reject a common rule.  A domain cannot add an object from an untrusted domain.  The error you are getting is telling you that.  No matter how much you argue you cannot change that.


    \_(ツ)_/

    Wednesday, June 22, 2016 8:30 PM
  • Both the OU and the group being delegated permissions are in the same domain.  I've clarified this several times.  The only remote element is that I'm running the script on a computer which is not in that domain, but is in an untrusted domain (for valid reasons).  However, I have created a powershell drive to that domain with admin credentials.  This is how I'm able to read the ACL on the OU in the first place.


    The Voice of Shatner

    Wednesday, June 22, 2016 8:38 PM
  • It sounds like AD is not optioned to allow full access from an external domain assuming that the accounts are all on the same domain as the OU.

    AD must allow external access from untrusted sources and you must connect to AD using credentials from the remote domain.  By default AD only allows full access with Kerberos.  Kerberos will not authenticate outside ot the domain so you are probably connecting with NTLM authentication.  If AD is not set to allow NTDS full access then you may have issue.

    Of course you domain might have other issues.  You may have 2nd hop issues because you are not authenticating inside of the domain and do not have credentials on anything but the server you are attached to. 

    I also suspect that Get-Acl/Set-Acl will not work outside of a trust.  It , too, needs to read AD.

    Post is DS forum to see if they know of the best method to do what you are trying to do.  They wrote the AD subsystem or, at least, they maintain the forum for it.

    The key will be correct external authentication if that will work in your scenario.


    \_(ツ)_/

    Wednesday, June 22, 2016 8:51 PM
  • This isn't a game of "give me an answer to any question you fancy".

    Also, FYI, this is a peer user-to-user forum with no SLA. There is no guarantee of an answer, or an answer you will like, as this forum is not an official support outlet.


    -- Bill Stewart [Bill_Stewart]

    Wednesday, June 22, 2016 10:02 PM
    Moderator
  • No, but there always seems to be a guarantee of people jumping in and making pointless remarks....

    The Voice of Shatner

    Wednesday, June 22, 2016 11:45 PM
  • The remark isn't pointless but rather just a (valid) reminder.

    I would also suggest that perhaps alienating the people who might be able to help you with your question might not be a winning strategy...


    -- Bill Stewart [Bill_Stewart]

    Thursday, June 23, 2016 3:29 AM
    Moderator
  • Thanks, dad.

    The Voice of Shatner

    Thursday, June 23, 2016 6:17 AM
  • If you're unhappy with the service here, make sure to contact customer service for your refund.

    -- Bill Stewart [Bill_Stewart]

    Thursday, June 23, 2016 2:32 PM
    Moderator
  • I revisited this recently and came up with an answer, in case anybody else is reading this hoping to do the same thing. 

    So this is how to set an ACE in a domain when you are running PowerShell from a machine in an untrusted domain.  Ideal for managing development environments, etc, which you do not wish to have a trust relationship with.  (Note this is all in combination with the New-PSDrive get-acl/set-acl comments I made previously - I appreciate this is a very brief summary.  If anybody needs more info happy to share.)

    You do not need to be able to resolve the SID - just read it from the AD object!  Seems obvious in hindsight.

    E.g you can do a standard get-adgroup or get-aduser, etc, to look up the group name in question then read the SID from the object as follows:

    $GroupObj = get-adgroup <groupname> -Server <DC in untrusted domain> -Credential $SomePSCreds

    [System.Security.Principal.SecurityIdentifier]$GroupSID=$Groupobj.sid

    You can then use $GroupSID as the identity parameter when creating the new ACE (system.directoryServices.ActiveDirectoryAccessRul) without having to rely on the SID being resolved at any point.


    The Voice of Shatner

    Monday, February 26, 2018 2:32 PM