none
New-PAMDomainConfiguration: The Netdom trust command returned the following error:

    Question

  • I have been following the MIM PAM lab guide here: https://technet.microsoft.com/en-us/library/mt488766.aspx

    When I reach the point at which to use the New-PAMDomainConfiguration command, I get an error stating that the Netdom trust command returned the following error:

    However, no error is presented. Running the command with -Debug, it just provides a little more information stating that the trust between priv.contoso.local and contoso failed.

    The preceding command - to set up the one way forest trust work just fine - using the same credential object.

    • Have any others seen this issue and found a resolution?
    • Can anyone provide some ideas for further debugging?
    • What changes does the New-PAMDomainConfiguration cmdlet make on the target domain?

    Regards,

    Jon.

    Monday, February 15, 2016 9:31 AM

Answers

  • Hi Jon,

    Not sure of the cause, but I believe you can work around the two PAM trust commands by running netdom directly:

    netdom trust corp.com /domain:priv.local /userO:CORP\administrator /passwordo:password_here /add

    netdom trust corp.com /domain:priv.local /EnableSIDHistory yes /userO:CORP\administrator /passwordO:password_here

    netdom trust corp.com /domain:priv.local /Quarantine no /userO:CORP\administrator /passwordO:password_here

    The first netdom command may fail if you've already created the trust, so you can either keep the existing trust you have established and run the other two commands or you can delete the trust you've established between "CORP" and "PRIV" and run all three in order.

    Let me know how that works out for you.

    Best,

    Jeff Ingalls

    • Marked as answer by Jon Bryan Wednesday, February 24, 2016 10:17 PM
    Monday, February 15, 2016 6:17 PM

All replies

  • Hi Jon,

    Not sure of the cause, but I believe you can work around the two PAM trust commands by running netdom directly:

    netdom trust corp.com /domain:priv.local /userO:CORP\administrator /passwordo:password_here /add

    netdom trust corp.com /domain:priv.local /EnableSIDHistory yes /userO:CORP\administrator /passwordO:password_here

    netdom trust corp.com /domain:priv.local /Quarantine no /userO:CORP\administrator /passwordO:password_here

    The first netdom command may fail if you've already created the trust, so you can either keep the existing trust you have established and run the other two commands or you can delete the trust you've established between "CORP" and "PRIV" and run all three in order.

    Let me know how that works out for you.

    Best,

    Jeff Ingalls

    • Marked as answer by Jon Bryan Wednesday, February 24, 2016 10:17 PM
    Monday, February 15, 2016 6:17 PM
  • Jeff,

    Thanks for the response.

    Yes, I figured that I could bypass the cmdlet using netdom, thanks for indicating what the cmdlet was carrying out and providing the syntax.

    I have run the last two commands successfully on my test system - SIDHistory enabled/ SID filtering disabled. I'll proceed with the rest of the lab and see how it behaves when it comes to managing PAM/ administrative access.

    The weird thing is the first time the New-PAMDomainConfiguration command is run, it seems to process, in other words it takes some time. After that it presents the error immediately. I tried some network captures during the initial run, but saw nothing relevant.

    Anyway, thanks again. I'll feedback once I finish the lab.

    Regards,

    Jon

    Monday, February 15, 2016 7:45 PM
  • I've added the error message and work around to the TechNet Wiki PAM FAQ.

    Best,

    Jeff Ingalls

    Monday, February 15, 2016 9:48 PM
  • Jeff,

    I'm glad to report that the workaround that you provided results in a working MIM PAM configuration.

    Thank you for your help.

    Regards,

    Jon

    Wednesday, February 24, 2016 9:00 PM
  • Awesome. Mind marking as answered so that others can quickly find the answer?

    Best,

    Jeff Ingalls

    Wednesday, February 24, 2016 9:27 PM