Pode and creating AD groups

[Skakiz]

Hi all,

I have developed a service using Pode. Pode is running in a Windows Service and I think that may be the problem.

My issue is that I can not create an AD group. But when I execute the same script in a PowerShell prompt, it is no problem. The powershell prompt and pode is executing by the same user account. I have also tried to create groups in different ways, New-ADGroup, New-Object System.DirectoryServices.DirectoryEntry - But is result in the same way.

In New-Object System.DirectoryServices.DirectoryEntry way I get:

Exception calling "CommitChanges" with "0" argument(s): "Access is denied.\r\n" StackTrace : at \u003cScriptBlock\u003e, C:\Pode\Server.ps1: line 117\r\nat Invoke-PodeScriptBlock, C:\Pode\Public\Utilities.ps1: line 634\r\nat \u003cScriptBlock\u003e, \u003cNo file\u003e: line 114

In New-ADGroup way I get :

Access is denied StackTrace : at \u003cScriptBlock\u003e, C:\Pode\Server.ps1: line 96\r\nat Invoke-PodeScriptBlock, C:\Pode\Public\Utilities.ps1: line 634\r\nat \u003cScriptBlock\u003e, \u003cNo file\u003e: line 114

As I have mentioned, If run the same script in a PS prompt it works just fine and AD group is created. Any Ideas why? The Windows Service is made via NSSM. Do Pode have to have some other rights?.

I have no problem searching in the AD (Get-ADGroup, Get-ADGroupMember, Get-ADObject), add/remove users to groups (Add-ADGroupMember, Remove-ADGroupMember), all via Pode.

• Windows Server 2016 Standard
• Versions:
  • Pode 2.6.2
  • PowerShell 5.1.19041.2364

Cheers! //Andreas

createADGroups.txt

[Badgerati]

Hi @Skakiz,

I'm not overly familiar with the AD module but:

• Are you running Import-Module ActiveDirectory before Start-PodeServer?
• Are you running Pode on the DC itself, or from another server? (I know the AD module doesn't like running on a DC at times)
• Are you, or have you tried, passing the -Credential parameter - see if it makes a difference.
• As a test, what happens if you call New-ADGroup directly within the Start-PodeServer scriptblock?
• If you run Pode directly from a PowerShell terminal does it make any difference - or same error as a Windows Service?

It's a little strange that adding and removing users works all right, but it fails on groups 🤔

[SeriousMikeDE]

Do you have a different user which is running the service?

I use the project shawl (also here on GitHub) because the NSSM isn't updated anymore. I specified a user which has no rights anywhere except local admin of the webserver itself. I get credentials from the user authenticating to pode and use them to run the AD command.

Hope that helps

[jbaechtelMT]

I don't see anywhere where you are providing credentials needed to create the new AD object. Hence the "Access Denied" error message. When you are running the script from a PowerShell prompt, the command-lets are using your credentials since none were provided. Running the script as a service, the script is running (most likely) using the System account that won't have the needed rights to create AD objects.

Instead of running Pode/script as a service try running it as a Windows Scheduled Task. The Scheduled Task method will allow you to specify the credentials that Pode/script should run as. As long as those credentials have Create AD object rights, the script will be able to then create new AD objects.

[Skakiz]

Hi, thanks for all the input. I will try to answer all your questions and comments.

I can see that Import-Module ActiveDirectory is called upon start. Im running the powershell on the server, no DC. I will try -Credential parameter and New-ADGroup directly within the Start-PodeServer that asap, good idea.

If you run Pode directly from a PowerShell terminal does it make any difference - or same error as a Windows Service? I will clear this up. When I run the ps in a terminal/prompt it is all good. But when the same code is ran in Pode, I get the error messages above.

The users are the same in both terminal and Windows Service. I will look into shawl and passing in credentials. The only thing is that I have noticed the pode takes its time to authenticate AD login. But I believe it may have be resolved in a newer version of pode.

@jbaechtelMT - So you mean that I can use the Windows Service login I have specified in the Windows Service Manager. I know that the account can create AD object, maybe not users actually.

I will get back to you when I have tried the different approches you have given.

Cheers! //Andreas

[phdavis]

Are you running the command/s directly from Pode server or are you using PSSession?

In our case everything worked fine (using NSSM) except DNS cmdlets. For those, we had to find a workaround. We connect to the remote machine (a management box in the desired domain), create a Scheduled Task, launch it, then read the output and return back to Pode. For whatever reason running the DNS cmdlets within a PSSession didn't work, but running the exact same code as a Scheduled Task as the same user works fine.

[SeriousMikeDE]

Hey Philip, the issue you're running into is the "second hop problem" related to Kerberos. You're only authenticated on the first machine (that management box) but if you try to do AD stuff the domain controller cannot "see" the authentication and refuses it.

By creating that scheduled task on the box you eliminate one hop so authentication works again.

I used PSSessionConfigurations with the credentials given from Pode and then execute the commands in the context of that configuration.

[phdavis]

Hey Philip, the issue you're running into is the "second hop problem" related to Kerberos. You're only authenticated on the first machine (that management box) but if you try to do AD stuff the domain controller cannot "see" the authentication and refuses it.

By creating that scheduled task on the box you eliminate one hop so authentication works again.

I used PSSessionConfigurations with the credentials given from Pode and then execute the commands in the context of that configuration.

We did have this issue originally with AD cmdlets, but passing the credentials into the session scriptblock as an argument worked around that. This same method doesn't work for DNS cmdlets though. I'll do some more testing with the config as you mentioned. Ultimately that would be much cleaner 👍🏻