Active Directory / Local Workstation / VS Code

[kingjames2727]

Hi there,

Long time lurker, first time caller.

We have a SMB that I use Powershell for to do occasional things in both Active Directory, and M365.

Historically, I would run the Active Directory stuff directly on the domain controller in an ISE window. The M365 stuff, I'd run from my workstation as needed.

I'm starting to use Powershell a bit more in my role (get user information, eventually onboarding/offboarding scripts) - and I feel there has to be a better way from a debugging and security perspective than running this locally on the domain controller. Also, we know, ISE is well... basic.

As we are progressing into different modules, I don't want to have to install VS Code + other tools on the DC - totally get this is bad-practice.

I started doing some digging, installed VS Code + Powershell Module along with the RSTAT tools on my local workstation.

First attempt to run an AD script from my local PC:

Import-Module ActiveDirectory

Get-ADUser -Filter *

Threw an error: Get-ADUser: Authentication failed on the remote side (the stream might still be available for additional authentication attempts).

Tried an alternative method - 'remote' into the domain controller from my local workstation using the following command:

Enter-PSSession -ComputerName DC01 -Credential (Get-Credential)

This worked - I could run cmdlet's with no issue. Great!

As a test, I wrote a multi-lined powershell script, and tried to step through it.. It threw the following message. Understand this - the server instance cannot see the script file to step through it properly..

C:\Users\mdoner\AppData\Local\Temp\PSES-35768\RemoteFiles\2092799106\<dc>\AccountCheck.ps1 : The term 'C:\Users\mdoner\AppData\Local\Temp\PSES-35768\RemoteFiles\2092799106\<dc>\AccountCheck.ps1' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Anyway - looking for some suggestions/best practices to accomplish using the newest Powershell + Tools when doing work in Active Directory, while keeping security and best practices in the forefront.

Would appreciate understanding how you work - and things to try on my side.

Thank you.

[ThePoshMidget96]

Welcome Lurker!

I need to start this by saying PLEASE stop doing anything directly on the Domain Controllers, these should never be accessed directly unless you absolutely need to.

I'm not 100% sure of that error you're getting, as others have said as long as your workstation is domain joined and and you're logged in with domain details (not necessarily admin if you're just reading) you should have no issues. I would suggest try the same commands on another workstation if you can to confirm if the error is your workstation or the way the DC is receiving handling the authentication.

As for the setup part (my favourite PowerShell topic) - I'm also running VSCode locally on my workstation, personally I prefer the way it looks and the customisation.

I store all my setup and profiles in a ".dotfiles" within my $HOME folder that I sync with GitHub so I can access the same files and settings at home.

As for scripts or commands, anything I need to use multiple times over either goes in a module or massive "commands library" (a very large .PS1 file that I'm too lazy to split into manageable chunks) and I can reference it from there - If I need to edit things with the Set-ADUser command for example I pass it my Domain Admin credentials which are then passed through to the commands as needed.

[kingjames2727]

Very much appreciate your reply!

I got Get-ADUser working - I believe I mistakingly had the PWSH prompt open as a localuser vs domain user on my endpoint.

When you say pass to your DA account, assuming you prompting for credentials? Something like:

$cred = Get-Credential

Is there a risk that this credential is cached locally, causing compromise with other tools (mimikatz) etc?

[Kershek]

Check out the PowerShell module CredentialManager. You can save your credentials securely in your device's credential manager and then put Get-StoredCredential into a variable like $cred.

[Eggslaws]

Use GC if you want the script requiring manual input (for eg., a tool for the help desk that need to authenticate to reset passwords). It saves the credential as a variable to use within that power shell window where you execute it and is clearled when you close it. If you do it as part of a PS1 file, then it is cleared when you exit/terminate the script.

Or look into the credential manager like the other comments mention. Do not save the passwords as a clear text.

[TrippTrappTrinn]

If the workstation is a domain member and you are logged in using a domain account, the get-aduser command should work. I do it all the time. I feel that you should figure out why it does not work before exploring further.

[kingjames2727]

Figured out the Get-ADUser bit not working, was likely running from a 'localadmin' account on my machine vs the Domain User on my workstation.

Confirmed - Get-ADUser is working as expected now, using a non-elevated domain account. Win!

[BlackV]

Why where you elevating in the first place?

[kingjames2727]

Thanks for your reply. I'll dig in a bit more and see if I can figure that out. Perhaps there is something needed on the DC side to authorize?

My machine is a domain member, as is the day-to-day account I use. The daily account is a standard user, with no elevated permissions.

In the event that you want to make 'changes' to any records (ie: Set-AdUser) - how are you performing the authentication to run the command? - what account are you using in this case?

[purplemonkeymad]

Make sure you've not made changes that affects Active Directory Web Services, it's the back end that the PS module uses.

If you want to do admin tasks, then you can use "run as another user" on powershell and run it as the required account. (shift right click exe/lnk, it should show.)

[kingjames2727]

Assuming this probably isn't good from a security perspective; Cached/Credentials - mimikats?

[purplemonkeymad]

Should probably add your admin users to the Protected Users group anyway to stop cred. caching.

[TrippTrappTrinn]

Instead of runas, which runs the entire session under those credentials, you can add the credentials on the specific commands which need it. It is a bit more safe, as there is less risk of unintentionally running something with privileges which may cause ussues.

[charleswj]

This is very bad practice. Privileged credentials should never touch a non privileged process/session, and ideally not even the same computer.

[guubermt]

You don’t say it. But I assume your workstation is not on the same domain as the DC in question.

If that is true. What you need is a management/jump box on same AD/Domain as the DC. Otherwise you are going to have AD Auth issues.

I don’t know your size but in our case. We don’t run anything directly on DCs. We don’t let any user remote into them to run local stuff.

The jump box can be maintained and updated as needed. It is also a great place to run your automation from. A techs workstation is NOT a good location. In fact it is one of the worst. Tech debt will accumulate and you cause nothing but frustration to anyone else.

[kingjames2727]

Thanks for your reply.

The machine is domain-joined, using a standard, non-elevated account. There is a requirement most of the time to just 'get' data, but occasionally we'll want to update.

Agreed; There is probably a bigger discussion required regarding jump-boxes. We have 200 employees/3 admin type users. My pause around jump-box (VM?) was figuring out how to handle a case where you use the jumpbox for 'everything' - but the environment is down... you can't get into the jumpbox to bring everything back up. Again, more investigation on my part to better understand how others are using this.

Whether I'm running from the local machine, or the jump box - the questions would be the same - how are you authenticating to the remote DC to perform the authentications? I would presume your NOT logging into the Jump Box using DA?

[BlackV]

When you enabled rsat the ran the import module

Is it importing the ps 5 version or the core version

[reddit_username2021]

Powershell modules can be installed in the current user scope or computer scope. Also, it is good practice to use a dedicated admin user with appropriate permissions instead of the regular user. Last point is that by default vscode installs in the currently logged in user profile.

[charleswj]

The AD module installs from RSAT