January 8, 2018 at 10:54 pm #91084
My company supports an application that allows uses to authenticate via LDAP. For years we have struggled whenever someone called in looking for help with user authentication issues because we only have access to the server that our product is on, not the AD server. We're usually pretty certain the customer isn't giving us the whole truth (the ever-typical "nothing changed on our side, it just stopped working!"). A while back we discovered we could use PowerShell to gather all of this information, and it has become a life-altering experience... But we still have one situation that we can't seem to get around, and that's when our customer puts the server with our product in the DMZ, and does not connect it to the domain. They configure the LDAP settings to connect to an AD server via FQDN. I know how to run
Start-Process powershell.exe -Credential “Domain\User”
if I'm signed into the server with a local account when the server is actually connected to the domain, but I'm curious if there might be a way to connect to AD to a remote server based on FQDN. My guess is that would be a major security breach, but figured I'd throw it out there anyhow in case somebody else may have an answer.
January 9, 2018 at 7:05 am #91085
Risk management is paramount for all things.
A machine that is not part of the domain is a work group machine and thus you cannot use AD cmdlets to access it.
There are specific steps to get a workgroup machine setup to allow PowerShell.
There are several cmdlet than can be used with or without PSRemoting enabled.
Tip: Work Remotely with Windows PowerShell without using Remoting or WinRM
All else requires PSremoting, and PSRemoting requires an account that is a local admin on the target host.
PowerShell remoting between two workgroup machines
You must be logged in to reply to this topic.