EVault Endpoint Protection 7.0 Single Sign-On Configuration

Transcription

1

2 Revision: This manual has been provided for Version 7.0 (July 2014). Software Version: EVault Inc. EVault, A Seagate Company, makes no representations or warranties with respect to the contents hereof and specifically disclaims any implied warranties of merchantability or fitness for any particular purpose. Furthermore, EVault reserves the right to revise this publication and to make changes from time to time in the content hereof without obligation of EVault to notify any person of such revision of changes. All companies, names and data used in examples herein are fictitious unless otherwise noted. No part of this document may be reproduced, transmitted, transcribed, stored in a retrieval System or translated into any language including computer language, in any form or by any means electronic, mechanic, magnetic, optical, chemical or otherwise without prior written permission of: EVault, A Seagate Company c/o Corporation Trust Center 1209 Orange Street Wilmington, New Castle Delaware EVault, EVault Software, EVault SaaS, and EVault DeltaPro, are registered trademarks of EVault, A Seagate Company. All other products or company names mentioned in this document are trademarks or registered trademarks of their respective owners. Acknowledgements: Two encryption methods, DES and TripleDES, include cryptographic software written by Eric Young. The Windows versions of these algorithms also include software written by Tim Hudson. Bruce Schneier designed Blowfish encryption. Part of the software embedded in this product is gsoap software. Portions created by gsoap are Copyright Robert A. van Engelen, Genivia Inc. All Rights Reserved. THE SOFTWARE IN THIS PRODUCT WAS IN PART PROVIDED BY GENIVIA INC., AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The EVault Software Agent, EVault Software CentralControl, and EVault Software Director applications provide encryption options for 128/256-bit AES (Advanced Encryption Standard). Advanced Encryption Standard algorithm (named Rijndael, pronounced Rain Doll ) was developed by cryptographers Dr. Joan Daemen and Dr. Vincent Rijmen. This algorithm has been chosen by the National Institute of Standards and Technology (NIST) of the U.S. Department of Commerce to be the Federal Information Processing Standard (FIPS). The EVault Software Agent and EVault Software Director applications include the security feature of over-the-wire (OTW) encryption.

3 Contents 1 Introduction Pre-login Page Session Timeout Cookies and Bypassing the Pre-login Page Prerequisites Installation and Configuration Configure the Service Provider Debugging a Single Sign-On Environment Chrome and Firefox Browser compatibility: i

4 1 Introduction Single sign-on allows a company to be set up so that users log in to the dashboard or access site using their company credentials rather than needing a new password. This is supported using the SAML 2.0 protocol. In SAML terms, the vault s dashboard is the Service Provider and the company s directory is an Identity provider and is accessed through a federation service such as Active Directory Federation Services (ADFS). If the user successfully logs in, the Identity Provider will redirect them back to our site to a pre-specified page. The Identity Provider will pass "assertions" back to the Service Provider (e.g. Dashboard) in a SAML token. These assertions are user attributes (e.g. , username, surname, given name, etc.). The Vault dashboard uses the address from the SAML token assertions to find the user in the database. The authorization within our system is determined by the access rights given to this user in the dashboard. We are not using any AD Group membership or other information from the Identity Provider to determine authorization. The identity provider needs to have the user in their system to authenticate the user, and the user must exist in our system for authorization, but the only attribute that needs to be the same in both systems is the address. Both the Identity Provider and the Service Provider need to be pre-configured to know about the other party. For security reasons, the SAML token should be signed with the Identity Provider's private key, and encrypted with the Service Providers public key. So the configuration, including the exchange of public keys, needs to be done before SSO will work. 1.1 Pre-login Page Since vaults can include many companies, some which support SSO and some which use database authentication, we need some information from the user to determine which authentication mechanism to use. The user's address provides this information. From the , we can look up the authentication mechanism used by the company and redirect them to the Login screen (for database authentication) or the Identity Provider's login page. 1.2 Session Timeout When a user's session times out, the user should be redirected back the authentication mechanism (SAML or database) used to authenticate the user. The user should not be presented with the Pre-login page again. After authentication, the user should be redirected back to the page they were trying to view. For database authenticated users, this is handled by adding the 1

5 destination URL to the query string. However, since SAML requires pre-configuring of URLs between the Identity Provider and the Service Provider, this is not possible. Therefore, cookies are used to track the URL that the user should redirected to after successfully re-authenticating using SAML. 1.3 Cookies and Bypassing the Pre-login Page 1. After a SAML authenticated user is validated and authorized within our system, a persistent cookie (with a 30 day expiration) is given to the user. This cookie will be checked by the system before presenting the Pre-login Page. If the cookie exists, the user will be automatically. 2. When the user chooses to Logout of the application, the cookie is removed if they click the forget me button. 3. The pre-login will be skipped if SSO is not enabled on the vault, but it will be used if SSO is enabled, even if there are no companies configured to use it yet 4. Database authentication can always be supported by going directly to the URL for the login page (.../dashboard/login.aspx). Thus system admins should always have a means to access the dashboard. 5. NOTE: If the user authenticates against one SSO Identity Provider, in subsequent usage of our application, they will be redirected to the same Identity provider. To authenticate against a different Identity Provider, they must either clear cookies, authenticate and logout (forgetting the user), or force entry on the pre-login page: (e.g. navigate to Prerequisites Vault version 6.3 (or above) A SAML 2.0 identity provider such as ADFS 2.0 2

6 2 Installation and Configuration 1. Install the Identity Provider Certificate on the ADFS server by using MMC add Snap in for Certificates (local computer option) or IIS Manager. 2. Install ADFS 2.0 from Microsoft. (Do not enable ADFS using the Roles/Features as that is ADFS 1.0 and does not support SAML 2.0) a. Let installer run wizard when complete (choose default options) b. Choose Identity Provider certificate from the dropdown (will be bound to IIS port 443 [HTTPS] by the wizard) c. Run Add a trusted relying party wizard. (NOTE: Strings in ADFS, including URLs are case sensitive!) i. In Windows Administrative Tools, start: "AD FS 2.0 Management" ii. On the left pane, expand Trust Relationships, then Right click on Relying Party Trusts and select Add Relying Party Trust iii. Start the Wizard. Choose the option "Enter data about the relying party manually". 3

7 iv. Enter a display name for the Relying Party then Next. This is only used to manage ADFS, and is not referenced by the Service Provider. v. Choose AD FS 2.0 Profile then Next. vi. Select Browse, then choose the Service Providers exported certificate to encrypt the token. Once the certificate information populates the fields, click Next. 4

8 vii. Select Enable support for the Saml 2.0 WebSSO protocol. For the URL, it should be something like " viii. Add a relying party trust identifier. IMPORTANT: THIS MUST MATCH THE VALUE ENTERED AUTOMATICALLY BY THE VAULT INSTALLER. The value will be in the form ix. Permit all users to access this relying party. 5

9 x. Deselect Open the Edit Claim Rules dialog for this relying party trust when the wizard closes then Finish the wizard. 3. On the left pane of AD FS 2.0 Main Console, highlight Relying Party Trusts and in the middle pane, right click on your Relying Party Trusts Display Name and choose Properties. 6

10 a. Go to the advanced tab and choose secure hash algorithm SHA-1 7

11 b. Go to the Signature tab, click Add button, and add the exported certificate from the service provider (vault) c. Click OK to close the properties dialog 8

12 4. On the AD FS 2.0 Main Console, right click on your Relying Party Trust Display Name and choose Edit the Claim rules... a. On the dialog click the button Add Rule. b. On the new wizard, choose Send LDAP Attributes as Claims (Default) then Next. 9

13 c. Enter a Claim rule name (e.g. Send AD attributes.) Choose Active Directory as the Attribute Store. In the Grid, choose Addresses from the LDAP Attributes. On the Outgoing Claim Type, choose Address. d. Click Finish to end the wizard. e. Click OK to end the dialog. 10

14 5. Open PowerShell with elevated permissions (Run as administrator) and run the following commands: a. Add-PSSnapin Microsoft.Adfs.PowerShell b. Set-ADFSProperties -AutoCertificateRollover $false 6. Open AD FS 2.0 Management and Expand Service a. Right-click Certificates and choose Add Token-Signing Certificate... b. Choose the Identity Provider certificate and click OK c. Right-click the new token signing certificate and click Set as Primary 11

15 d. Right-click Certificates on the left Pane of the Main Console and choose Add Token- Decrypting Certificate... e. Choose the Identity Provider certificate and click OK f. Right-click the new token signing certificate and click Set as Primary 7. If not using DNS routing, modify the hosts file to include an entry for the ADFS server, as well as the IP for the Service Provider. 12

16 3 Configure the Service Provider 1. Modify hosts file, if necessary, to have an entry for the identity provider 2. Run Vault Installer v6.3 or above a. If Upgrading from a version prior to 6.3, then the following sub-steps must be performed after running the installer: i. Run Deployment Manager ii. iii. iv. From the Dashboard menu, select Update Single Sign-on Configuration Enter the vault identity name that will be used by the ADFS server (the default for a new install would be <protocol>://<hostname> so, for example, without any trailing slash and without the Dashboard/ part Add the certificate used for the vault 13

17 v. Enter the vault certificate password vi. Click Save b. If New Install of v6.3 or later, within SQL Management Studio, edit dashboard database's (usually DCDashboard) dbo.ssoconfiguration table so that the IsEnabled value is set to: True c. Close SQL Management Studio 14

18 3. Log onto Dashboard, load the company which will support SSO 4. Click on Single sign-on tab for the company loaded above 5. Click the Edit settings button a. Enter IdentityName--should be the name of the Identity provider. This MUST match the value in ADFS. On the ADFS machine, open AD FS Management, select the Service folder, right click and choose "Edit Federation Service properties...". Copy the value from FederationService identifier text box into the Identity Name text box. b. Enter the Url--should be (e.g. c. Choose the certificate exported (*.cer file) from Identity Provider d. Click Save button 3.1 Debugging a Single Sign-On Environment 1. If you aren't getting a response, ensure that you can reach the ADFS server. On the machine where you are running the browser, type this into the browser: qualified hostname>/adfs/ls/idpinitiatedsignon.aspx Make sure you are getting a sign-in page. If not this points to a network problem (e.g. you don't have a hosts entry), or an ADFS problem (e.g. the service is not set up). 2. If you are getting the login screen, but not able to log in, look at the event logs (run eventvwr)on the ADFS server. ADFS logs are not in the normal Windows Logs. They are in "Custom Views\Server Roles\Active Directory Federation Services. 3. To getting information from the 3rd party SAML components a. If the system.diagnostics section does not exist, add it to the bottom of the configuration section. b. Add this to the system.diagnostics section of the Dashboard web.config file: <trace autoflush="true"> <listeners> <add name="textwriter" /> </listeners> </trace> 15

19 <sources> <source name="componentspace.saml2" switchvalue="verbose"> <listeners> <add name="textwriter" /> </listeners> </source> </sources> <sharedlisteners> <add name="textwriter" type="system.diagnostics.textwritertracelistener" initializedata="c:\temp\saml\logs\sp.log" /> </sharedlisteners> c. Make sure the directory specified in the web.config file exists (in the example above it is the directory shown in red). You might need to modify permissions so the IIS user running the dashboard web site has permissions. d. Restart IIS. 3.2 Chrome and Firefox Browser compatibility: Chrome and Firefox do not support enhanced protection when using windows authentication. So what does this mean? It means that if you log in with ADFS from a non-ie browser, it will not work. You will see this authentication failure in the application log: An account failed to log on. Subject: Security ID: NULL SID Account Name: - Account Domain: -. To fix, simply turn off Enhanced Protection for Windows Authentication in IIS in the adfs\ls folder: Log in to your ADFS server. In IIS, expand adfs, then right click on the ls subfolder. 16

20 Double click on authentication, then in the advanced properties for windows authentication, turn off enhanced protection. More information can be found here: 17