I had a recent request for some information in regard to constrained endpoints. There was a lengthy article posted in a PowerShell.org TechLetter earlier this year that I authored (it actually won me a free 4-day pass to the PowerShell + DevOps Global Summit 2016). As of now, those don’t appear to be back online, since the recent redesign and changes over there.
Therefore, I’ve opted to post the paper here. Keep in mind, as you read this, that we should be moving away from constrained endpoints of the past and toward JEA endpoints of the future. Realistically though, I’m pretty sure those constrained endpoint cmdlets of the past, are the ones of the future, with some new additions… I should probably go get my hands dirty. Enjoy!
Note: Throughout the course of this previously written paper, I used the term proxy function rather loosely. I’ve done some thinking since then, and no longer use it that way. Going forward, or if I were to rewrite this paper, I wouldn’t use the term proxy function. Instead, I would refer to the included functions as wrapper functions, as they wrap other commands, and didn’t have anything to do with obtaining the cmdlet metadata and using that to write a function. If they had, then they’d be a proxy function.
I guess if you do this long enough, you start finding and reporting on errors before anyone else does. My decision to write today began because of this error message: “Register-PSSessionConfiguration : The verification of the runAs user credentials failed with the error 1326.”
After receiving the error, I took it to Google, and wrapped it in double quotes, only to find there were no relevant results. Once I had a solution, I decided I should do my part to help the next person that encounters this error. As you may be able to conclude, the error message appeared when I tried to register a PowerShell constrained endpoint, using the Register-PSSessionConfiguration cmdlet’s -RunAsCredential parameter.
The primary reason I figured this out so quickly, was because I noticed that the user logon name I chose ended up being longer than my ‘Pre-Windows 2000 logon.’ Think SamAccountName (and its length limitation) vs. the Name property.
It’s apparent (now) that the Register-PSSessionConfiguration’s -RunAsCredential Parameter is expecting the username portion of the PSCredential object to be the SamAccountName, even if the help file doesn’t explicitly indicate that. Hope this helps someone else.
Update: I decided to do the same Google Search I did last week (for the error message), and now something is showing up: this post. Yea, Internet!