OpenSSH in Active Directory Environments

IN THIS ARTICLE:

 

Summary / Overview

This article discusses configuration and troubleshooting of Aspera Services when running on Windows Servers which are members of an Active Directory Domain.

The reasons why it may be necessary to run the services for Aspera Enterprise Server (or Point to Point) running on a Windows Server that is a member of an Active Directory Domain are:

  1. Domain Security Policies are overriding the required local policies for this server
  2. Desire to use Active Directory User accounts to initiate transfers
  3. Access to Network File shares that have permissions which are controlled by Active Directory User accounts are needed for transfers

Aspera installs and uses several services and the following services are candidates to use Active Directory Accounts:

  • OpenSSH Service
  • Aspera Central
  • Aspera Sync

OpenSSH on Windows does have the following requirements:

  • OpenSSH requires each user to be "enabled" individually. No group enablement.
  • OpenSSH only supports Interactive, doesn't support Network logins.

It is possible to use only local accounts, both for running services and for transfers, on an Active Directory member server but the ability to do this is dependent upon the security restrictions on that server. OpenSSH has some explicit requirements for local security policies and if these are not overridden Active Directory user accounts are not required. Even if an Active Directory user is required to run the services it is still possible to use only local users for Aspera transfers.

Environment

  • Operating System: Windows

 

Aspera Service user setup

Installing Aspera requires that a user account be identified or created to run the services created by Aspera. In a 32 bit Windows XP environment services can be run as the “local system account” but it is recommended that an explicit user always be used and the installer will prompt for this and suggest creating the user svcAspera.

Unlike with local accounts, the Aspera installer cannot create an Active Directory user. Whether the installer creates an account or an existing Active Directory or local account is used, the Aspera installer will set the necessary local security policies for the user. Because of this the best method for configuring Aspera services is to let the installer do this automatically. When using an AD account the installer will grant the required local security policies to the Active Directory Domain user account. Note that you must have a domain account already created, and know the password for the account.

Launch the Installer by clicking the executable that was downloaded from the Aspera website answering all prompts. At the Aspera Service Account screen specify the Active Directory account in the format username@domain and enter the password. To use an Active Directory account here you must be signed onto the server with an Active Directory account that has permission to query the Domain Controller to validate this account. You can use any Active Directory user but often it is a good practice to create an account specifically for this purpose in case the required local policies have to be explicitly granted. The purpose for the account may also be more clear and this can reduce the likelihood of changes being made to that user that will negatively impact Aspera. (Password is changed or permissions or access rights change. While it is not required that the account be set to have a password that doesn’t expire if password expiration policies will be applied to this user the Aspera services will need to be updated whenever the password is changed in Active Directory. They will continue to run even if the password is changed but they will not be able to be restarted and if the server is rebooted the services will not start until they new password is entered.)

?name=install_svcaccount_windows.png

 

Semi-Manual process

In some cases it may not be possible to specify the Active Directory account during the installation. You can try a semi-manual process by running a script after the installation has completed. If this does not work, you will have to move on to the fully manual process in the next section.

1. Click the Start button and type in Command Prompt in the search box. Right click Command Prompt and select Run as administrator.

2. Move to the bin directory of your product

64 bit Windows
cd "C:\Program Files (x86)\Aspera\your_product\bin"

32 bit Windows
cd "C:\Program Files\Aspera\your_product\bin"

3. Run the asuser-services batch file and supply the username, password and administrator group of the user to be used as your Aspera Service account.

For English installations the administrator group would be Administrators. If the user is an AD account it should be in the format user@full.domain.

asuser-services.bat username password administrator_group

Manual process

If the installer is unable to get the proper validation of the AD account it will be necessary to carry out the installation and specify a “local account” and then change it manually after installation using the following steps:

1. Create or obtain an Active Directory account and credentials as above
2. Add that Domain user account to the local Administrators group on the system where Aspera has been installed

?name=openssh2.png

3. Configure the following Local Security Policies for this user:

  • Act as part of the operating system
  • Adjust memory quotas
  • Create a token Object
  • Log on as a service
  • Replace a process level token
  • Allow Log On Locally

To access the Local Security Policies snap-in, go to Control Panel > Administrative Tools > Local Security Policies.

?name=openssh3.png

4. Configure Services to run as that user account.

Open up Services by going to Start > Run and typing in "Services.msc".

Scroll down the list of services, and find OpenSSH. Right click on OpenSSH and select Properties. In the properties dialog, go to the second tab, titled Log On. In this dialog, use the Browse button to select the new AD user account for this service, and provide the password. Go back to the General tab, and restart the service, using the Start and Stop buttons.

Access the Services control panel, and edit the Properties for each of the following services specifying the Active Directory account and the associated password on the Log On tab for the service.

  • OpenSSH Service
  • Aspera Central
  • Aspera Sync

The AD account can be specified in either format: DOMAIN\username or username@domain.

?name=openssh4.png

 

Advanced Service User configuration

In some cases, Active Directory Domains policies can restrict configuration settings on local computers. More specifically, the Domain polices might prevent an Active Directory user from having the required local security permissions (Log on as a service, Create a token object, Act as part of the operating system, Adjust memory quotas, Replace a process level token) to run the various Aspera services (Open SSH, Aspera Central, Aspera Sync).

In order to address this situation, a Domain Administrator would need to specifically enable the Active Directory Domain computers to allow the Aspera service user (ie: DOMAIN\svcAspera) to have the required permissions. This can be done specifically for that user by creating an Active Directory OU and applying that to the user or computer. (http://technet.microsoft.com/en-us/library/cc785077%28WS.10%29.aspx)

The following steps explain how to enable an Active Directory Computer to remove the restrictions that are preventing Domain Accounts from running services on the Aspera server. Prior to following these steps, please be sure you have completed either the Manual Process or Installer steps outlined above.

1. Log onto the Active Directory Domain Controller as a Domain Administrator.

2. Open the Active Directory Users and Computers configuration snap-in.

3. Create a new Organizational Unit. Right click on the Domain Icon for the domain where the Aspera server is located and select New > Organizational Unit from the drop down menu. Specify the name AsperaService as the Organizational Unit, for convenience.

?name=openssh5.png

4. Right click on the new AsperaService Organizational unit, and select Properties from the drop down menu.

5. Select the Group Policy Tab, and click on New to create a new Group policy. In this example, the name Aspera Service Permissions was used.

?name=openssh6.png

6. Select the new group policy, and click on the Edit button.

7. Browse to Windows settings > Security Settings > Local Policies > User Rights Assignment.

8. Open the Adjust Memory Quotas policy, click on the Define these policy settings and add the Active Directory User account to that policy.

?name=openssh7.png

Repeat this for the following policies:

  • Act as part of the operating system
  • Log on as a service
  • Create a token object
  • Replace a process level token.
  • Allow Log On Locally

9. Add the Aspera Server Computer into the Organizational Unit using Drag and Drop.

10. Log onto the computer running Aspera Server as a Domain Administrator, and run the following command from the command line:

gpupdate /force

 

Then, run this same command on the Domain Controller. Run it once more on the Aspera Server.

Then, reboot the Aspera Server system, and run the command again on the Domain Controller and Aspera server. Then reboot the Aspera Server again. (We agree these multiple repetitive group policy updates and reboots seem odd but these instructions came from Microsoft directly).

11. To verify that these new policies work, from the Aspera Server system you can look at the permissions using the Resultant Set of Policy snap-in.

Go to Start >Run and type in "rsop.msc" to view the results:

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/rspoverview.mspx?mfr=true

?name=openssh8.png

12. Validate that the open SSH server can now authenticate Domain Users.

From a computer that has an SSH client, run the following:

On Windows shell
C:/> ssh DOMAIN\user@server-ip

On Unix-like shells
# ssh "DOMAIN\user"@server-ip

 

Troubleshooting

Here are the steps to enable additional account access logging:

1. On the Aspera Server system, open the Local Security Policy settings snap-in.

2. Navigate to Local Policies > Audit Policy.

3. Select each of the following Audit Account policy, and enable the event logging for Failure: Account Logon events, Logon Events, Privilege Use. (Note: Success auditing is not required.)

4. This will enable additional logging to the Event Viewer.

?name=openssh9.png

Other troubleshooting hints

In addition, you can use RSOP to verify/review if there are domain security polices overriding local policies.

The command gpresult is used to produce a list of domain and local privileges which apply to this user.

The reason we need to reboot and run gpupdate so many times is that:

  • AD User policies apply on Login event; ie: When user logs on.
  • AD Computer policies apply on boot; i.e. when a computer is rebooted.
  • The service control manager may start before the policies are applied the first time which requires a second reboot.

 

Alternatives

In some cases it may not be possible to use OpenSSH if your Domain Policies preclude the required local policies. There are alternate SSH servers available for Windows and Aspera works will with WinSSHD by bitvise. (http://www.bitvise.com/)

1. Open SSH requires each user to be "enabled" individually. One can't enable a group (Use bitvise for enabling a group such as Everyone or DOMAIN\AsperaUsers)
2. OpenSSH only supports Interactive, where Bitvise supports Network logins. Interactive logon requires more privileges.
3. OpenSSH requires that the user account running the service have more privileges (as described previously in this article.) Bitvise works without these additional privileges. Thus Bitvise can be a nice solution where an Active Directory environment is explicitly denying the required Windows policies for the domain computer or user.

Here is a short list of Bitvise WinSSHD server features, that are not supported in OpenSSH:

  • Support for accessing shares (via saved password)
  • Support for AD group based authentication and policies
  • Support for 'log on' without requiring local log-on privileges (local vs network log-on)
  • Support for "Virtual Users" (ie: Non OS user accounts)

Attachments

Have more questions? Submit a request

0 Comments

Article is closed for comments.
Powered by Zendesk