none
JEA and GMSA RRS feed

  • Question

  • I have a service management application that can run powershell scripts.  Our plan is to use this application to run powershell scripts that will create and modify user accounts.  Our application connects to Windows servers using WinRM - so most of the time I'm experiencing the 'second-hop' problem.  JEA to the rescue for that problem.  So I created a non-admin, user account and use that account as my JEA RunAsVirtualAccount.  This all is working for me; I can create an AD account and Exchange email.  My problem is I cannot modify the ACL for my newly created user's home drive - a network share.

    I have given my RunAs account proper permissions to create and modify home drives,  I can test all this by logging into the server with my RunAS account and running my script - so I know I have the script and permissions set properly.  However, as my JEA is configured presently using a virtual account, when it runs the same script, the account cannot modify the share ACL because it is created as a local system account.

    It appears to me that I need to use a GMSA to be able to modify the network share, the user's home drive.  According to JEA Security Considerations, Group managed service accounts (gMSAs) are useful when a member server needs to have access to network resources in the JEA session.

    I don't know how to set this up in my JEA configuration.  I have successfully created my GMSA account and allowed servers, but I don't understand

    how to use this account within JEA
    how do I test it all
    I've created my JEA configuration using examples in:

    Just Enough Administration (JEA) - Part 1: Overview
    Just Enough Administration (JEA) - Part 2: An example
    Using this method and my RunAs account, I can test by entering the session using a command such as:

    Enter-PSSession -ComputerName <targetcomputer> -ConfigurationName JEA_DNS_OperatorSession -Credential $credential
    If I were to use my GMSA account, how can I Enter-PSSession?  The Get-Credential cmdlt prompts for username & password.  A GMSA account has an automated, system generated password.
    Thursday, March 28, 2019 4:32 PM

All replies

  • The answer is that a gMSA account is not designed to work the way you want and JEA is designed to work with any standard user account to allow you to grant users access to limited capabilities with PS and remoting.


    \_(ツ)_/

    Thursday, March 28, 2019 6:56 PM
    Moderator
  • Thank you for your reply. 

    Outside of making my JEA RunAs account a member of a higher admin level account, is there another way to set the ACL on my newly created user's home drive?

    Here's the portion of my script that I can get to work from server where I'm logged in as my RunAs account

    $user = Get-ADUser -Identity $loginID
    $fileSystemRights = "FullControl" #Can be comma seperated list for more control
    $InheritSettings = "Containerinherit, ObjectInherit" #Controls how permissions are inherited by children
    $PropogationSettings = "None" #Usually set to none but can setup rules that only apply to children.
    $RuleType = "Allow" #Allow or Deny.
    $acl = Get-Acl $homeDirPath
    $perm = $user.SID, $fileSystemRights, $InheritSettings, $PropogationSettings, $RuleType #Can use either $user.SID or $user.samAccountName
    $rule = New-Object -TypeName System.Security.AccessControl.FileSystemAccessRule -ArgumentList $perm
    $acl.AddAccessRule($rule)
    $acl | Set-Acl -Path $homeDirPath
    When I run this through a JEA session, it does not set the ACL because is cannot find the share location, i.e $homeDirPath



    • Edited by blwallace Thursday, March 28, 2019 8:36 PM
    Thursday, March 28, 2019 8:28 PM
  • No idea what you are trying to ask.  No ACL will allow use of a gMSA account as connection account.  It may be able to be used as the proxy account.  In all cases the gMSA account is just like a user account except that the password is managed and hidden.

    The remote system has only as much access as the proxy account and has no access to the local users local resources.  That would be a security violation and would require reconfiguring the network for all users needing to do that.

    When a user needs to access a remote system through remoting  and access the local file system then using a session becomes a problem.

    We would need to know the exact case that you are trying to address to show you how to do it if it is possible.

    Setting an ACL cannot make this possible.

    If the user folder is on a share then you can do this if the share is on the same system as the remote endpoint.  It will not work if the share is on a different system.

    All of this requires advanced training in Windows networking and security. That training would make it easier for you to understand the hows and whys of this. If there is someone in your organization with network and security certification they would be the best resource to help you set this up.

    Again - if we had some idea of the purpose for this we might be able to supply an easy answer.  Most things I have seen over the years are an issue because the solution design is based on an incomplete understanding and experience with advanced windows networking or advanced windows capabilities.  Most techs are not rained in networking beyond the desktop support level.  That is because this is not needed in a stable network.  Once we start looking into things like complex remote access to resources then the skills needed are not available.  In larger corps there are usually specialists or external consultants that work with the user community and desktop support groups to resolve these issues.

    The issue is more a deployment and provisioning issue than a usage issue. Most elements have little to do with scripting.  WsRM is not a scripting system but is a broad remoting protocol and engine.  PowerShell just has access to this underlying system but is not part of PowerShell.  It should be deployed with the assistance of network and domain engineering.

    If you are in a small organization without these resources then you will have to take the time to get up to speed on the requisite engineering knowledge. 

    Giving a more specific example of what you need to do may well allow us to show you a simpler way to do it. You are trying to choose a solution without a specific requirement.  This is usually the backward way to approach an issue.


    \_(ツ)_/

    Thursday, March 28, 2019 9:17 PM
    Moderator
  • I thought I stated what I was trying to do in the first two sentences of my post.

    I have a service management application that can run powershell scripts.  Our plan is to use this application to run powershell scripts that will create and modify user accounts. 

    When creating a new AD account, I also want to create a home drive for this new user and setup proper permissions for that shared folder.  I can't load all necessary PS modules onto my application server, so I have to use remote connections to resources that hold the proper PS modules.  My application server uses WinRM as the remote connector.  I am using JEA as a way to allow a regular user account to connect to these remote systems and run whatever PS scripts, cmdlets, etc. are needed.  This is all working for us.  The JEA account can create and modify the AD and Exchange accounts.

    My specific requirement is to extend this working solution to enable modification of permissions on the newly created home share.


    Thursday, March 28, 2019 11:02 PM
  • Again it states how you want to do something and not what you need to do.

    To remotely mange local accounts you can use ADSI remotely and give the users who manage these accounts permissions on the account objects.

    There is no need for gMSA in any case.  A constrained endpoint can provide access to only the CmdLets that manage a user account.  This only requires JEA an the user logins in with their own credentials.  That is the purpose of JEA - give regular users some admin access that is highly restricted to the task.


    \_(ツ)_/


    Thursday, March 28, 2019 11:10 PM
    Moderator
  • Here's what I need to do:
    A non-admin level account from my application server, ServerA, starts a WinRM connection to run a PowerShell script on ServerB - a member server
    From ServerB, the script calls/runs PowerShell commands on ServerC (my DC) and ServerD (my Exchange)

    The script needs to:
    create an AD account with attributes
    attach an Exchange mailbox to the new account and set a retention policy
    create a home drive for the new account
    set the permissions on the home drive

    How can I do this?

    I have a developed a script which does all of this, with my non-admin level account, from ServerB.  When I initiate this from ServerA, it fails because the credentials are not passed through from ServerA to ServerC via ServerB.  

    I'm looking to JEA because:
    One of the solutions to the second-hop is JEA (See Making the second hop in PowerShell Remoting)
    The first sentence of the JEA overview is: "Just Enough Administration (JEA) is a security technology that enables delegated administration for anything that can be managed with PowerShell."

    Friday, March 29, 2019 4:39 PM
  • Here's what I need to do:
    A non-admin level account from my application server, ServerA, starts a WinRM connection to run a PowerShell script on ServerB - a member server
    From ServerB, the script calls/runs PowerShell commands on ServerC (my DC) and ServerD (my Exchange)

    The script needs to:
    create an AD account with attributes
    attach an Exchange mailbox to the new account and set a retention policy
    create a home drive for the new account
    set the permissions on the home drive

    How can I do this?

    I have a developed a script which does all of this, with my non-admin level account, from ServerB.  When I initiate this from ServerA, it fails because the credentials are not passed through from ServerA to ServerC via ServerB.  

    I'm looking to JEA because:
    One of the solutions to the second-hop is JEA (See Making the second hop in PowerShell Remoting)
    The first sentence of the JEA overview is: "Just Enough Administration (JEA) is a security technology that enables delegated administration for anything that can be managed with PowerShell."

    Can't be done unless you enable CredSSP on the client and server and configure the endpoint to use CredSSP.


    \_(ツ)_/

    Friday, March 29, 2019 5:06 PM
    Moderator
  • Isn't CredSSP a big security risk/hole?
    Friday, March 29, 2019 5:52 PM
  • Isn't CredSSP a big security risk/hole?

    Yes if it is not set up correctly and carefully.  JEA can limit this.  Be sure the servers do not allow CredSSP through the firewall.

    It is more of a headache to maintain if it is more than just two or three systems.


    \_(ツ)_/

    Friday, March 29, 2019 6:09 PM
    Moderator
  • We wouldn't have a large system to create a CredSSP environment so I'll look into it.  The main reason I went with JEA was the security risks of CredSSP.  But if JEA and remote connections can't work with network resources, then I may be forced into it.
    Friday, March 29, 2019 6:52 PM
  • Can you offer a scenario where GMSA and JEA would or could be used?  Or any further documentation other than on https://docs.microsoft.com/en-us/powershell/jea/session-configurations?
    Monday, April 8, 2019 4:21 PM
  • You issue has nothing to do with either of those things.  The issue is a blanket Windows security boundary.  Only CredSSP will resolve your issue.

    What you are trying to do is likely unnecessary as you can use permissions on any resource to grant a user direct access.  JEA is only good for targeted local access to a broad set of local resources.  It is not a replacement for other forms of delegation of rights and permissions.

    I recommend taking some time to learn the basics of Windows network, resource and process security.  Once this is clear you will be more capable of designing a solution for an issue.

    Your question is very hard to answer because it is too broad.  The simple answer is that JEA is used to grant access to specific local resources at a specific level on a specific system.  It is not a way to grant broad administrative rights to a network.  The admin account and Windows permissions are the correct way to grant access to diverse network resources.

    Once you learn the security model of Windows most of this will become clear.  There is no shortcut to managing Windows short of learning how the Windows OS and networking system are designed and how they are intended to be used.

    When a company has a complex technical requirement and they do not have in-house trained people the company will hire specialists to help.  There are many companies that can provide consultants to help you sort out your needs and design a solution.


    \_(ツ)_/

    Monday, April 8, 2019 4:38 PM
    Moderator
  • Sorry if this is a little late, had the issue with this myself. 

    What you want to do in the .pssc of the file is specify what GMSA you would like to use, like this:

    # Group managed service account name under which the configuration will run

    # GroupManagedServiceAccount = 'CONTOSO\MyGMSA'


    Microsoft specifies that in order to access network resources in a JEA session, a GMSA is recommended. If the JEA session isn't being created on a domain controller when running as a virtual account, then the session will only inherit local admin privilege. Other than a GMSA, a quick fix would be to elevate the Endpoint privilege such as adding the computer to a privileged security group but this isn't the best practice security wise. 

    Things to note:

    -If using the GMSA config on the PS Session, make sure to remove any run as virtual account settings as they will not allow the session to run as a GMSA.

    -Permissions depend upon the Role Capabilities file. It is perfectly secure to have sessions running as a GMSA, but remember to review the cmdlets, functions, external scripts and what not to make sure the session you need to be running under the GMSA is not susceptible to inherent weakness. 

    Tuesday, July 16, 2019 10:36 PM