Credentials for use with PowerShell

[David Pichard]

Hi all, gotta question for you. It's not clear what credentials I need to use and how to use them in the following scenario:

SN > MidServer > PowerShell > Active Directory > Create New User.

I have a credential that I can use locally on the Mid Server to add new users to AD via PowerShell. It's encrypted and lives in the script in the MidServer > Scripts directory. Do I also need to have a windows credential in my credentials table that can log on to the mid server host and should the mid server service also run under this account?

The error message I'm getting is: "Credentials cannot be used for local connections"

Thanks in advance,

David

[SusanWinKY]

David, the situation you describe is exactly what we're experiencing.  If you're not using the mid server as target host, what did you use for the target host?

[David Pichard]

Hi all, a few revelations to share since my last post. It seems the credentials table in SN is mostly used with Discovery so it can go through the list of credentials and try to log into various networks resources and devices and as such doesn't necessarily pertain to the service account you run a mid server as. However, see Rev 1. Smarter people than me please feel free to chime in and make corrections as necessary.

Revelation 1: At least one credential in your SN credentials table needs to be able to authenticate to the windows server host that your mid server is running on. In my case, I used the same credential that one of my mid server services is running as for simplicity.

Revelation 2: You will need a different mid server for each intended purpose unless you plan to use one single credential for all your endeavors which in my humble opinion is not a good idea as that one credential would have too much juice if it were compromised. So in my scenario I currently have two separate mid server hosts each with two sets of mid servers each, soon to be adding a third. Each of the pairs (between the two server hosts) are functioning as either a failover cluster or a load balancing cluster.

One cluster is being used for an SCCM integration, each of the mid servers in this cluster use a credential (ie run the windows service as this credential) which has read only access to the prod SCCM database. The other cluster is being used to run powershell scripts that create and manage AD accounts. This cluster uses a different credential than the SCCM mid servers and has permissions in specific OUs in AD. 

Revelation 3: The accounts/credentials you run the mid server services as need to be local administrators on the mid server host.

Other notes: At K18 one of the guru's suggested trying to run my powershell scripts using the mid server IP address as the target host thinking this might allow me to use the mid server host machine as the target for running powershell scripts against. I haven't tried this yet so not sure if it will work or not. I do know that using the fully qualified domain name of the mid server host does not work as your powershell target. So, what I did was just target another machine on the network, in my case two separate file server machines, ones that I know are mission critical and will likely always be online. I suppose I could set up a dedicated windows machine solely for the purpose of being a target host but that seems like a waste of resources. 

In retrospect, for the work I'm doing in AD I wish I had used the SN suggested practice of using an LDAP server with write capability. This is what is taught in the orchestration class and all of the OOB activities for AD that come with orchestration use this approach. As such I wasn't able to use any of the OOB activities and ended up writing all my own Powershell scripts for handling AD interactions. For whatever reason our infrastructure peeps weren't into the idea of setting up an LDAP server for me and I didn't have time to fight the political battles to make it happen in the given amount of time available for the project deadline. So it goes.

The main problem I've run into with using powershell for AD mangling is running up against the threading limitations of Powershell. There's about 5k employees in my org and if there's an org wide request for staff to go into Workday, which is the headwaters of my SN/AD integration, and update some piece of information - the powershell activities will bomb out if a significant number of people have changes to process at the same time. 

May some of my pain and suffering limit your pain and suffering!

All the best,

David