New-PSSession localhost issue

This topic contains 2 replies, has 1 voice, and was last updated by Profile photo of Axel Bøg Andersen Axel Bøg Andersen 8 months ago.

  • Author
    Posts
  • #37638
    Profile photo of Axel Bøg Andersen
    Axel Bøg Andersen
    Participant

    I have a few AD users that are not able to enter a PSSession anywhere. The error is:
    Enter-PSSession : Connecting to remote server localhost failed with the following error message : The WinRM client rece
    ived an HTTP bad request status (400), but the remote service did not include any other information about the cause of
    the failure. For more information, see the about_Remote_Troubleshooting Help topic.
    At line:1 char:1
    + Enter-PSSession localhost
    + ~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : InvalidArgument: (localhost:String) [Enter-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : CreateRemoteRunspaceFailed

    If I run:
    New-PSSession localhost -Credential $(Get-Credential)
    with credentials of a user without the problem, the session is created. If I run the same command with credentials of the user with the issue, it generates the error – even thoug its on the same machine in the same console.

    I have examined the AD user attributes and the groupmemberships and they are identical. I have chedked the userobject for spns but found none.

    What should I try next?

    Regards,
    Axel

  • #37639
    Profile photo of Axel Bøg Andersen
    Axel Bøg Andersen
    Participant

    For uncertain reasons it works again.

  • #37641
    Profile photo of Axel Bøg Andersen
    Axel Bøg Andersen
    Participant

    It turns out WINRM is sensitive to tokensize bloat. Someone removed the user with the issue from an AD group while I was testing and suddenly the issue disappeared. The funny thin was, that I had a shell running in the users context. In that shell I could not do:
    New-PSSession localhost
    but New-PSSession localhost -Credential $(Get-Credential)
    worked just fine.

    By running:
    whoami /groups in in both sessions it became clear, that groups were removed.

You must be logged in to reply to this topic.