SMS PASSCODE 7.2 ADMINISTRATOR S GUIDE REV. 1.0 (JUNE 2014)

Transcription

1 SMS PASSCODE 7.2 ADMINISTRATOR S GUIDE REV. 1.0 (JUNE 2014)

2 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 2 OF 407 TABLE OF CONTENTS Table of Contents Introduction Notation New Features in Version Password Reset: Enhanced Support for Password Notifications Password Reset Web Site: Adaptive Layout Password Reset Web Site: Adaptive Authentication Flows User Integration Policies: Import of Personal Passcodes Cloud Application Protection: Adaptive Layout and More Languages Token Policies: Import of Token Seed Files Authentication Policies: Enhanced Password Brute-Force Protection New Features in Version Secure Device Provisioning (for ActiveSync Devices) Support for OATH Tokens Contextual Message Dispatching New License Management Geo-Mapping Persistent Column Selection Support for Windows Server 2012 R Support for Windows Support for Outlook Web Access Support for More Languages Support for Multiple Password Reset Web Sites on the Same Server Discontinued features Feature Overview Authentication Clients Security Password Reset Module Installation Administration Enterprise Environment Support Components Licensing Authentication Behavior: Authentication Clients Authentication Behavior: Password Reset System Requirements... 33

3 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 3 OF Requirements for Location and Behavior Aware Authentication Terminal Service / Remote Desktop Service Protection SharePoint Portal Server Protection Installing Web Sites on a Non-DB Server in the same Domain Hardware GSM Modems Infrastructure Component Communication Simple Installation Standard Installation Citrix Web Interface Standard Installation RADIUS Clients Standard Installation Enterprise Setup Standard Installation Total Distribution Pre-Installation Actions Check SIM Cards Check System Requirements Installation of IAS Installation of NPS Protection of TS/RD Web Access using IIS Web Site Protection Protection of TS/RD Session Hosts using Windows Logon Protection Protecting VMware View 4.x Protection of SharePoint Portal Server Upgrade First-time Installation Installation of Hardware Installation of the SMS PASSCODE Software Post-Installation Actions Overview: Location and Behavior Aware Authentication Web Administration Interface Starting the Web Administration Interface Overview of Policy Types Static Relationship between Policy Types Runtime Relationship between Policy Types General Settings Miscellaneous Settings Authentication Monitoring Globalization Options Signing Up for 3rd-party Web Services

4 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 4 OF Maintaining License Information Applying a License Key License Limits License Management User Integration Policies Single Versus Multi Sync Mode Single Sync Mode Multi Sync Mode User Group Policies Settings of a User Group Policy Passcode Policies Settings of a Passcode Policy Authentication Policies Authentication Rule Sequence Settings of an Authentication Policy Authentication Policy Examples Token Policies Creating a new Token Policy Settings of a Token Policy in Manual Entry Mode Settings of a Token Policy in Token Seed File Import Mode Users Settings of a User User IP History User Login History Adding and Deleting Users Using AD Integration Importing Users Importing and Synchronizing Users from other Data Sources Transmitter Hosts Maintaining Authorized Transmitter Servers Assigning Dispatchers to a Transmitter Load Balancing Hosts Maintaining Authorized Load Balancing Servers GSM Modems Settings of a GSM modem Removing Modems Dispatchers Settings of an Dispatcher

5 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 5 OF Web Service Dispatchers Settings of a Web Service Dispatcher GSM Modem Groups Maintaining a Modem Group Load Balancing Policies Load Balancing Rule Sequence Settings of a Load Balancing Policy Load Balancing Policy Examples Authentication Monitoring Column Filtering Row Filtering Exporting Data Switching Data Source Geo-mapping Modem Monitoring Self Service Web Site Examples of Usage Auto s Customizing Auto s Data Updates Security Concerns Authentication Configuring Authentication Delegation Localization Password Reset Module Licensing Best-Practice Setup of Password Reset Workflow for Performing a Password Reset Strict Flow Other Login Flows Password Reset Infrastructure Security Concerns Publishing the Password Reset Web Site Protecting the Password Reset Web Site with SSL/TLS Encryption of the Network Communication with the AD Controller Protecting the Password Reset Module against Attacks Configuring the Password Reset Web Site

6 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 6 OF Configure Communication with the Password Reset Backend Service Protect the Password Reset Web Site using SSL/TLS Configuring the Password Reset Backend Service Setting Up a Dedicated User Account for Password Reset Configure Settings of the Password Reset Backend Service Password Reset Event Log Localization Secure Device Provisioning Background Features Getting Started with Secure Device Provisioning Configuring Microsoft Exchange Server Setting External OWA URL Enabling Quarantine Mode Configurable Workflows Standard Workflow Other Workflows Configuration of Workflows Authentication Policy Interaction Auto-approving New ActiveSync Devices Event Logging Localization Customization of Localized Texts Configuring Authentication Clients Configuring Citrix Web Interface Protection Configuring RADIUS Protection Configuring RADIUS Protection on Windows Server Configuring RADIUS Protection on Windows Server 2008 / Advanced Configuration of the RADIUS Protection Component Configuring Cloud Application Protection Background AD FS 2.0 Infrastructure Configuring ISA/TMG Web Site Protection Excluding Specific URLs from Multi-Factor Authentication Configuring IIS Web Site Protection ISAPI Filter ISAPI Filter Configuration File

7 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 7 OF The IsapiAdmin Tool ISAPI Filter Configuration File Syntax Configuring Windows Logon Protection Windows Logon User Exclusion Groups Windows Logon Lock Time (GINA only) Remote Desktop Logon Timeout (CP only) RDP Listener Exclusion Credential Provider Filtering GINA Chaining Configuration Tool DB Encryption Collecting End-User IP Addresses Command Line Arguments Add/Remove Components Backup and Recovery Backup of Database Files Backup of Configuration Tool Settings Backup of Authentication Monitoring Archive Backup of Auto Templates Troubleshooting SMS Transmission Problems Error Message Unknown user during Authentication Component Communication Problems Active Directory Integration does not Work as Expected Self Service Web Site Password Reset Web Site Fatal Error when Accessing the Password Reset Web Site Access Denied when Accessing the Password Reset Web Site Secure Device Provisioning Ordinary Quarantine Received No Quarantine Received Token Authentication SMS PASSCODE A/S. SMS PASSCODE is a registered trademark of SMS PASSCODE A/S. All other trademarks are the property of their respective owners.

8 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 8 OF INTRODUCTION This document describes how to install, configure and administer SMS PASSCODE version NOTATION Shorthand ActiveSync AD Description Technology developed by Microsoft, used for synchronizing personal Outlook data to handheld devices. Active Directory AD FS 2.0 Active Directory Federation Services 2.0. Windows-based Federation Service that supports the WS-Trust, WS- Federation, and Security Assertion Markup Language 2.0 (SAML 2.0) protocols. CAE CAG CAS IAG IAS IIS ISA LBP Machine memopasscodes NPS OWA RD Reference: Citrix Access Essentials Citrix Access Gateway Client Access Server role of a Microsoft Exchange Server installation Microsoft Intelligent Application Gateway Internet Authentication Service: Optional component on a Windows Server This component is the Microsoft implementation of a RADIUS server. Internet Information Server: Optional component/role on a Windows Server. Internet Security and Acceleration Server. A Microsoft security gateway server. Load Balancing Policy This is a general term used to denote a server or a workstation. memopasscodes refers to an SMS PASSCODE innovation making codes easier to read and memorize during authentication. Network Policy Server: Optional Role on a Windows Server 2008/2012. This Role is the Microsoft implementation of a RADIUS server. Microsoft Outlook Web Access Remote Desktop

9 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 9 OF 407 Shorthand RDS PRBS PRWS SMS PASSCODE authentication client SMS PASSCODE core component SDP SSWS TMG TS UAG UGP UIP WAI Description Microsoft Remote Desktop Services SMS PASSCODE Password Reset Backend Service SMS PASSCODE Password Reset Web Site One of the SMS PASSCODE components Citrix Web Interface Protection, RADIUS Protection, Cloud Application Protection, IIS Web Site Protection, ISA/TMG Web Site Protection, Windows Logon Protection or Secure Device Provisioning, i.e. one of the components responsible for authentication for a specific type of client. One of the SMS PASSCODE components Database Service, Web Administration Interface, Self Service Web Site, Transmitter Service or Load Balancing Service. SMS PASSCODE Secure Device Provisioning SMS PASSCODE Self Service Web Site Threat Management Gateway. A Microsoft security gateway server (the successor of the Microsoft ISA Server) Microsoft Terminal Service Microsoft Unified Access Gateway (the successor of the Microsoft Intelligent Application Gateway) User Group Policy User Integration Policy SMS PASSCODE Web Administration Interface

10 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 10 OF NEW FEATURES IN VERSION 7.2 This section summarizes the most important new features introduced in SMS PASSCODE version Password Reset: Enhanced Support for Password Notifications Previously, SMS PASSCODE users could automatically receive a notification, whenever they were locked out in the SMS PASSCODE database. The notification system has been extended with three new types of notifications: AD lockout notification: Automatically send out a notification to users, when their AD account has been locked out Password pre-expiration notification: Automatically send out a notification to users, when their password is about to expire Password expiration notification: Automatically send out a notification to users, when their password has just expired Each notification type is optional, and the content of each notification type is customizable (per User Group Policy). By default, each notification message will contain the URL of the SMS PASSCODE Password Reset Web Site, thereby providing optimal assistance to users for handling password issues by themselves, in a convenient and effective way. Please note, that Password Reset CALs are a pre-requisite for using the three new types of notifications. Please read section (page 151) for more details. 3.2 Password Reset Web Site: Adaptive Layout The user interface of the SMS PASSCODE Password Reset Web Site (PRWS) has been re-designed completely, now providing a modern, adaptive layout. The web site is very responsive and automatically adapts to different screen resolutions, across desktop PCs, laptops, tablets and mobile devices. Combined with the three new password notification types listed above, this provides optimal password reset assistance, letting users reset their passwords directly on their smartphones, as they receive a notification containing the URL of the PRWS. Just a simple click on the URL is required to launch the PRWS directly on the device. Note: The enhanced PRWS requires the.net Framework 4.5 to be installed on the web server beforehand. Consequently, the PRWS is not supported on Windows Server 2003 anymore.

11 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 11 OF Password Reset Web Site: Adaptive Authentication Flows Previously, it was only possible to log in to the Password Reset Web Site in one way: Entering username, then personal passcode, then one-time passcode (OTP). Now it is optionally possible to configure different types of authentication flows depending on the login context. To allow this, the Authentication Policies have been extended with a new Password reset flow setting. For example, it is now possible to configure the system to adapt to more convenient authentication flows, when logging in from trusted environments. As an example, only requesting username and OTP, when logging in from the internal network. Please read sections (page 187) and 17.3 (page 289) for more details. 3.4 User Integration Policies: Import of Personal Passcodes The User Integration Policies have been extended to also allow import of personal passcodes from AD. This provides an easy way to maintain personal passcodes for password reset, in case an existing AD attribute can be used, such as for example an internal employee number stored in AD. Transformations are supported, in case only a part of each imported value should be used. Please read section (page 134) for more details.

12 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 12 OF Cloud Application Protection: Adaptive Layout and More Languages The SMS PASSCODE Cloud Application Protection component has been enhanced in two ways: The user interface of the SMS PASSCODE Cloud Application Protection (AD FS 2.0) component has been re-designed completely, now providing a modern, adaptive layout. The web site automatically adapts to different screen resolutions, across desktop PCs, laptops, tablets and mobile devices. The localization of the user interface has been extended with additional languages. The following 17 languages are now supported: o Czech o Danish o Dutch o English o Finnish o French o German o Hungarian o Italian o Korean o Norwegian o Polish o Romanian o Russian o Spanish o Swedish o Turkish 3.6 Token Policies: Import of Token Seed Files In SMS PASSCODE version 7.0, support for OATH tokens was introduced, allowing both OATH compliant hardware and software tokens to be used for authentication. In version 7.2, a feature for import of token seed files has been added to Token Policies. This allows to import one or more token seed files into a Token Policy, where after it is possible to assign tokens to users through the serial numbers of the tokens. The serial numbers can be entered by the administrator in the web administration interface, or alternatively by the users themselves in the SMS PASSCODE Self Service Web Site (if allowed to). Supported token seed file formats: CSV and PSKC. Please read section (page 213) for more details.

13 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 13 OF Authentication Policies: Enhanced Password Brute-Force Protection Previously, if a password brute-force attack was suspected, a user would be locked out from the SMS PASSCODE database permanently. It is now possible to configure the system to a more relaxed behavior, where the user is initially locked out temporarily, then eventually locked out permanently, if the attack continues. Please read section (page 181) for more details. 4 NEW FEATURES IN VERSION 7.0 This section summarizes the most important new features that were introduced in SMS PASSCODE version Secure Device Provisioning (for ActiveSync Devices) SMS PASSCODE version 7.0 introduced a completely new component, called SMS PASSCODE Secure Device Provisioning. This component provides a very secure, yet convenient way for end-users to approve an ActiveSync device for getting access to their Exchange mailbox. Background: Out-of-the-box, Microsoft Exchange Server 2010 and 2013 support selective approval of ActiveSync Devices. Any new, non-approved ActiveSync device can be put into quarantine mode automatically, until an administrator has approved the device. The problem with this approach, especially in bigger companies, is: How does the administrator know, whether to approve a quarantined device or not? How to distinguish between a valid user device and a hacker attempting to get access to a user s using the ActiveSync protocol? A traditional approach is to implement a manual approval procedure, that takes up extra time for internal IT, and blocks users from accessing their s until the devices have been approved. This causes unnecessary delays and loss of worker productivity. The best approach for solving the above problem is to enable the end-users to approve any new ActiveSync device by themselves. This supports a people-centric BYOD culture. When done securely, user-driven device provisioning is more convenient, more secure, and frees IT of the burden of being responsible for the approval process. SMS PASSCODE Secure Device Provisioning builds on top of the existing Microsoft Exchange Server functionality, extending it to allow endusers to easily approve new devices by themselves without compromising security. Security is maintained by leveraging SMS PASSCODE s renowned multi-factor authentication engine for approving a new device. This means among others that SMS PASSCODE s Authentication Policies can also be used in Device Provisioning scenarios for example you may configure the SMS

14 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 14 OF 407 PASSCODE system to use secure provisioning using multi-factor authentication in some contexts, while at the same time allowing simple auto-provisioning without requiring multi-factor authentication in other contexts, e.g. in case devices are connected to a trusted network like the internal WIFI within your organization. SMS PASSCODE s brute-force attack protection also applies to ActiveSync devices, preventing lockout of AD accounts due to password brute-force attacks. Please read section 18 (page 314) for more details about configuring and using the SMS PASSCODE Secure Device Provisioning component. 4.2 Support for OATH Tokens SMS PASSCODE version 7.0 introduced support for OATH compliant tokens. The token support is very flexible, allowing you to configure the exact types of tokens used in your organization: Support for OATH compliant hardware tokens and software tokens Support for event-based (HOTP) and time-based (TOTP) OATH tokens o Support for time-based tokens with any time-step size (e.g. 30 or 60 seconds between OTPs) Support for OATH tokens with 6, 7 or 8 digits Configuration of tokens is performed using Token Policies, a new type of policy added to the policy-driven administration of SMS PASSCODE. As an administrator, you may optionally allow end-users to select a Token Policy by themselves using the SMS PASSCODE Self-Service Web Site. This provides end-users the flexibility of choosing by themselves the type of token to use, e.g. choosing between Microsoft Authenticator and Google Authenticator. Optionally, Token Policies can be configured to allow end-users easy self-enrollment of software tokens, simply by logging in to the SMS PASSCODE Self-Service Web Site, generate a random token ID by the push of a button, and then finally perform a complete configuration of the software token by scanning a QR code that is presented automatically to the end-user. Please read section 15.9 (page 205) for more details about Token Policies.

15 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 15 OF Contextual Message Dispatching In version 6.1 SMS PASSCODE introduced Authentication Policies and introduced the patentpending technology of location and behavior aware authentication, in short contextual authentication. Since then it has been widely recognized that the principles of contextual authentication extends SMS PASSCODE to provide a much more secure, yet flexible authentication system than traditional MFA systems. From one perspective, Authentication Policies provide you the option of increasing security, using context aware protection rules, like geofencing; from another perspective, Authentication Policies give you full flexibility of balancing security and convenience at the level of your choice. E.g. you might enable SMS PASSCODE to intelligently skip MFA for logins from special contexts, like self-learned trusted IP addresses, e.g. home workplaces. In version 7.0, Authentication Policies were extended even more, introducing dynamic override of Load Balancing Policies and Passcode Policies. This means, that Authentication Policies can depending on the current authentication context, decide to override the Load Balancing Policy and/or Passcode Policy to use for the actual dispatching of a one-time-passcode. Once again, this increases flexibility, allowing you to configure the system according to your specific needs. As an example, you can configure the system to prefer SMS over voice call dispatching during logins from Europe, while preferring voice call over SMS dispatching during logins from North and South America. Yet another example is to send one-time-passcodes to your mobile phone by default, but perform a voice call to a fixed-line phone number, when you are logging in from a branch office. Please read section (page 187) for more details regarding contextual message dispatching.

16 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 16 OF New License Management Previously, there was no separation between creating a user in the SMS PASSCODE database and allocating a client access license (CAL) to the user. I.e. any user created in the database was automatically allocated a CAL. For greater flexibility, SMS PASSCODE version 7.0 introduced a new license management system, which makes it possible to create or import users into the SMS PASSCODE database, without taking licensing into account; license allocations are handled independent of this afterwards. This has several advantages, among others: It is possible to allocate MFA CALs and Password Reset CALs independent of each other. I.e. you can assign MFA CALs only, Password Reset CALs only, or both types of CALs to any subset of users. Previously, an AD sync would skip importing some users, if you ran out of CALs. With the new logic, the AD sync will import all users, allowing you to get a good overview in the Web Administration Interface, which users are missing a CAL. For more details about the new License Management logic and administering CAL allocations please read sections 7 (page 30), 15.4 (page 123) and (page 165). 4.5 Geo-Mapping The Authentication Monitoring page in the Web Administration Interface was enhanced with a new Geo-Mapping feature. This feature allows you to visualize any subset of the SMS PASSCODE authentication attempts collected in your system on a world map. E.g. you may activate a filter showing only failed authentication attempts within a specific period, and then plot these attempts on a world map, to get a geographic visualization of login attempts from unexpected locations.

17 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 17 OF 407 The world map is interactive, allowing you to click on any country to get detailed login statistics. For more details regarding Geo-mapping, please read section (page 272). 4.6 Persistent Column Selection Previously, when customizing the columns shown in data grids on different pages of the Web Administration interface, these column customizations were lost, whenever the browser was closed and re-opened. Starting from SMS PASSCODE version 7.0, column selections are persisted individually per user. 4.7 Support for Windows Server 2012 R2 In SMS PASSCODE version 7.0, most components were tailored to support Windows Server 2012 R2. This applied to: All SMS PASSCODE core components SMS PASSCODE RADIUS Protection SMS PASSCODE IIS Web Site Protection 1 SMS PASSCODE Windows Logon Protection 1 Please note, that protection of Remote Desktop Web Access sites is not supported anymore on Windows Server 2012 (R2) using the IIS Web Site Protection component. The Windows Logon Protection component must be used instead (cf. section 8.2, page 34).

18 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 18 OF Support for Windows 8.1 In SMS PASSCODE version 7.0, SMS PASSCODE Windows Logon Protection was enhanced to support Windows Support for Outlook Web Access 2013 In SMS PASSCODE version 7.0, the SMS PASSCODE IIS Web Site Protection component was enhanced to support protection of Outlook Web Access (OWA) It is a requirement, that the OWA 2013 site is configured to use form-based authentication (FBA) Support for More Languages In SMS PASSCODE version 7.0, end-user related content was localized to more languages. The SMS PASSCODE Self-Service Web Site, the SMS PASSCODE Password Reset Web Site, and the SMS PASSCODE Secure Device Provisioning Web Site were localized to the following 17 languages: Czech Danish Dutch English Finnish French German Hungarian Italian Korean Norwegian Polish Romanian Russian Spanish Swedish Turkish 4.11 Support for Multiple Password Reset Web Sites on the Same Server SMS PASSCODE version 7.0 introduced the possibility to host several SMS PASSCODE Password Reset Web Sites in the same IIS (on the same server), allowing each such web site to connect to a separate SMS PASSCODE Password Reset Backend Service. For more details, please read section (page 302).

19 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 19 OF Discontinued features The SMS PASSCODE Citrix Web Interface Protection component no more supports Citrix Web Interface versions 4.5, 5.0.x, 5.1.x and 5.2.x. Citrix Web Interface versions 4.6, 5.3.0, and are still supported.

20 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 20 OF FEATURE OVERVIEW SMS PASSCODE is a versatile multi-factor authentication system with an extensive list of great features. The most important of these features are described in the following subsections. 5.1 Authentication Clients SMS PASSCODE provides comprehensive protection for a broad range of authentication clients. The following clients are currently supported: Citrix Web Interface RADIUS clients Supported are: Checkpoint Cisco Citrix Access Gateway Juniper Microsoft Intelligent Application / Unified Access Gateway (IAG/UAG) Microsoft SharePoint Portal Server 2 Any other RADIUS client supporting PAP with challenge/response Any other RADIUS client supporting MS-CHAP v2 3 Cloud Applications protected by AD FS 2.0 Supports protection of any web applications that are using form-based authentication and are protected by AD FS 2.0 using SAML 2.0, WS-Federation or WS-Trust. Examples are: Microsoft Office 365 Web Clients Google Apps SalesForce ISA/TMG Web Sites Supports protection of web sites that have been published through a Microsoft ISA/TMG server using a Web Listener, e.g.: Outlook Web Access Terminal Service Web Access (Windows Server 2008) Microsoft SharePoint Portal Server IIS web sites using Basic or Integrated Windows Authentication Any web site not requiring any pass-through authentication (authentication delegation). 2 Protection of SharePoint Portal Server using RADIUS is only supported, if the SharePoint Portal server is published through an Application Gateway that will ensure that the user is only requested to authenticate once during the initial logon. E.g. using the Microsoft IAG/UAG, Citrix Access Gateway Enterprise Edition or Juniper SA, all configured to use persistent cookies. 3 For best user experience, the RADIUS client must support to show the challenge message returned by the SMS PASSCODE protected RADIUS server.

21 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 21 OF 407 Internet Information Server (IIS) Web Sites Supports protection of the following types of IIS web sites: Outlook Web Access 2007 / 2010 / 2013 Terminal Service Web Access (Windows Server 2008) Remote Desktop Web Access (Windows Server 2008 R2) IIS Web Sites using Basic or Integrated Windows Authentication Windows Logon Protection of: Terminal Service (RDP Connections) Windows servers Windows workstations Secure Device Provisioning (for ActiveSync Devices) Protection for secure provisioning of ActiveSync devices accessing the following versions of Exchange server: Exchange Server 2010 Exchange Server 2013 SMS PASSCODE is fully integrated into all supported authentication clients. No extra user actions are necessary to trigger the transmission of passcodes the authentication is very intuitive, which makes user training unnecessary. 5.2 Security SMS PASSCODE provides improved security from several aspects. From a technical point of view, SMS PASSCODE provides these important security features: Strong authentication security with protection against modern internet threats such as advanced Phishing-attacks, because passcodes are: o Session-specific (opposite to hardware-token based solutions!) o Randomly created in real-time without the usage of any pre-deterministic algorithm (opposite to hardware-token based solutions as well as many competing messagebased solutions) o Challenge-based o Time-constrained Patent pending location and behavior aware authentication for even stronger security, making it possible to prohibit access or alert users in case of advanced attacks like some cases of man-in-the-middle attacks Cryptographically strong random passcodes are generated using FIPS-140 validated crypto modules Configurable passcode length, complexity and lifetime Strong encryption o Build-in 256bit AES encryption of all network communication o Optional 256bit AES encryption of the database files

22 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 22 OF 407 Brute-force attack protection o Automatic lockout of users on consecutive incorrect password entries o Automatic lockout of users on consecutive incorrect passcode entries Denial-of-service attack protection Lockout Notification o Optional feature, immediately notifying a user in the event of a user lockout, thereby giving the user the chance to take immediate counteractions, in case the event is unexpected. From a user perspective, SMS PASSCODE provides increased security compared to e.g. traditional hardware-token based solutions due to: High user awareness of stolen or lost cell phone means shorter period before counteractions are taken High user awareness of the necessity to block SIM card of stolen or lost cell phone to prevent misuse, which implies lock down of access using SMS PASSCODE Users can lock their stolen or lost cell phone (SIM card) themselves meaning faster reaction and shorter period of security breach Users are automatically alerted in case their user credentials have been stolen, since they will start receiving passcode messages not requested by themselves Users are alerted by irregularities in the contextual message information, in case location and behavior aware authentication has been enabled 5.3 Password Reset Module Many IT helpdesks struggle with the burden of helping end users with password related issues. There are several reasons, why this happens. Some examples are: End users are requested to change their password frequently. It sometimes happens during this process that users forget the new password, they chose. When end users forget their password, they often try to guess it, attempting logins with different password entries. This usually results in user accounts becoming locked out. When end users are requested to change their password, they do not always perceive prior warnings about this, potentially resulting in blocked access to IT systems. In many cases, users will not be able to get access to relevant IT systems and continue work, before the IT helpdesk has been able to resolve the problem. The SMS PASSCODE Password Reset Module was introduced to lessen the burden on IT helpdesks related to password issues, while at the same time making it quicker and simpler for end users to reset their password, when needed. As a result, users can regain access to required IT systems and continue work immediately.

23 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 23 OF 407 Important characteristics of the SMS PASSCODE Password Reset module are: Convenient: The SMS PASSCODE Password Reset Module provides a web site, where users can reset their own Active Directory password. It is very intuitive to use. Several authentication flows are supported to let users reset their password, for example using their user ID and the personal passcode that was entered (during activation) in the SMS PASSCODE Self Service Web Site, followed by a one-time passcode (OTP). Hassle-free real-time notifications: An important part of a password reset system is to ensure that a user is aware of the possibility of resetting his / her password, when needed. The SMS PASSCODE Password Reset Module ensures this in a hassle-free way, without the need to install additional software on PCs or smartphones, by making intensive use of automated real-time notifications. Several types of notifications exist in SMS PASSCODE, each of which can be enabled or disabled as required. The idea is that a user will automatically receive a notification that reminds him about the possibility to reset his password, whenever it seems relevant. The following types of notifications are provided: SMS PASSCODE lockout notification o Notifies a user, whenever he is locked out from the SMS PASSCODE system due to several log in attempts with a wrong password AD lockout notification o Notifies a user, whenever he is locked out from AD Password pre-expiration notification o Notifies a user, whenever his AD password will expire soon (e.g. within the next 3 days) Password expiration notification o Notifies a user, whenever his AD password has just expired The content of each notification type is customizable. By default, each message contains the URL of the SMS PASSCODE Password Reset Web Site. This is a user-friendly, effective way to remind the user about the possibility to reset his password by himself; and additionally to inform where and how to do it. Note: If a user succeeds resetting his password, the SMS PASSCODE Password Reset module will automatically unlock the user, if he was locked out, whereby the user regains access to all relevant systems. 5.4 Installation Installation of SMS PASSCODE is very simple, since SMS PASSCODE is an out-of-the-box end-to-end solution containing all necessary software and hardware. Simply connect the included GSM modem(s) to your servers, install the software, and you are ready.

24 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 24 OF 407 The component architecture of SMS PASSCODE offers maximum flexibility of installation, allowing distribution of SMS PASSCODE components according to your specific needs. Unlike traditional hardware-token based solutions, SMS PASSCODE works without distribution of any hardware-tokens. As a result, the logistic overhead involved is minimal and roll-out is much faster. You can get SMS PASSCODE up and running with thousands of users within minutes. Just extract all cell phone numbers from your Active Directory, or import them from a comma-separated file, or even let the users enter the cell phone numbers themselves using the SMS PASSCODE Self Service Web Site. 5.5 Administration The daily administration of SMS PASSCODE is simple due to: No logistic overhead regarding administration and distribution of hardware-tokens. No need to involve IT personnel in the event of a lost cell phone, since users will quickly discover the loss and act on own impulse to block the SIM card. Smart policy-driven administration making it easy to maintain settings on a system wide level, user group level or individual user level. No need to involve IT personnel when end-users have to enter or change personal data like (mobile) phone numbers. The IT personnel can optionally allow end-users to maintain such data themselves using the SMS PASSCODE Self Service Web Site. No need to involve IT personnel when users have forgotten their AD password. The IT personnel can optionally allow end-users to reset their own AD password in a secure manner using the SMS PASSCODE Password Reset Module. Additionally SMS PASSCODE includes an excellent Active Directory Integration feature that allows administration of SMS PASSCODE users in your Active Directory. The list of AD Integration features are: Works out-of-the-box. No schema extension of your AD is needed! Supports both LDAP and Global Catalog lookups. Supports encrypted secure communication (for both LDAP and Global Catalog lookups) Supports extraction of users from multiple separate AD Domains. Supports nested groups including groups from child domains and trusted domains. Customizable extraction of several user attributes from the AD, like (mobile) phone numbers, addresses and token IDs. Even searching through a prioritized list of AD attributes is possible.

25 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 25 OF Enterprise Environment Support Failover and scalability is very important in enterprise environments. SMS PASSCODE provides failover and scalability on all levels thus providing unmatched support for enterprise environments: Database level: Each SMS Transmitter service and Load Balancing service cache all data locally meaning independence of backend database and high scalability. I.e. system operation is maintained even in the event that the backend database is down. Transmitter level: A load balancing service provides intelligent distribution of all incoming requests to many transmitter services, thereby providing full failover and load balancing between all transmitter services. I.e. system operation is maintained even in the event that a transmitter service is down. An unlimited number of transmitter services are supported. GSM Modem level: Each transmitter supports a modem pool containing up to 32 GSM modems, thereby providing full failover and load balancing between all modems in a pool. I.e. system operation is maintained even in the event of a GSM modem being down. If SIM cards from different carriers are used, then you can even obtain failover on the GSM service provider level. Authentication client level: Each authentication client may forward incoming requests to several transmitter services or load balancing services. I.e. system operation is maintained even in case some of the transmitter services or load balancing services are down. An unlimited number of transmitter services and load balancing services are supported. Authentication type level: Global diversities of messaging infrastructures can be a challenge for global enterprises. SMS PASSCODE addresses this issue by providing support for several passcode dispatching mechanisms and authentication mechanisms. Users with specific needs can be set to receive one-time-passcodes by , voice calls or web service SMS; or be allowed to authenticate using hardware tokens, software tokens or time-constrained personal passcodes. Additionally, using Load Balancing Policies it is possible to control the load balancing of passcode messages across all GSM modems or other passcode dispatchers at a granular level. Since the Load Balancing Policies are very flexible, the number of possibilities is enormous. Some examples of the usage are: Prefix load balancing: Group modems according to the country where they are located. Preferable send SMS messages from GSM modems with SIM cards having the same phone number prefix as the receiver. Additionally, users with specific mobile number prefixes can be set to receive passcodes by alternative dispatching mechanisms, i.e. by e- mail, voice call or web service SMS. GSM service provider failover: Group modems according to the GSM service provider of the SIM cards. Preferable send SMS messages using a selected GSM service provider, but use another one for failover (e.g. automatically send another passcode using a second

26 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 26 OF 407 service provider if the first passcode could not be sent or was not entered within a specified time limit). GSM receiver failover: Allocate both a primary and a secondary cell phone number to some users. Automatically send another passcode to the secondary cell phone if the first passcode could not be sent or was not entered within a specified time limit. This clearly demonstrates that SMS PASSCODE has been designed and built with even the most demanding enterprise environments in mind. 6 COMPONENTS SMS PASSCODE is composed of the following software components: SMS PASSCODE Core Components Authentication Clients Add-on modules 4 Database Service Citrix Web Interface Protection Password Reset Module Web Administration Interface RADIUS Protection Transmitter Service Cloud Application Protection Load Balancing Service IIS Web Site Protection Self Service Web Site ISA/TMG Web Site Protection Windows Logon Protection Secure Device Provisioning (for ActiveSync devices) Component Database Service Web Administration Interface Transmitter Service Load Balancing Service Description Database for storing all SMS PASSCODE user data and configuration data. Web site for maintaining SMS PASSCODE user data and configuration data. Service responsible for dispatching messages and validation of SMS PASSCODE logons. Handles load balancing and failover between all GSM modems connected to the service. Service responsible for handling load balancing and failover between all Transmitter services. This optional service is recommended for enterprise installations where multiple Transmitter services are present. It should be installed in the following cases: 1) Advanced failover and load balancing of SMS messages between all Transmitter services is required, or 2) The usage of Load Balancing Policies is required. 4 Please note that separate CALs are required to gain access to add-on modules

27 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 27 OF 407 Component Self Service Web Site Citrix Web Interface Protection Description Web site that allows end-users to maintain some of their personal SMS PASSCODE account settings themselves. Integrates SMS PASSCODE with Citrix Web Interface providing SMS PASSCODE authentication for Citrix Web Interface users. It is optionally possible to run the Citrix Web Interface protection side-by-side with hardware-token based two-factor authentication systems, e.g. RSA SecurID or SafeWord. Both AD and NDS authentication is supported. RADIUS Protection Integrates with RADIUS systems providing SMS PASSCODE authentication for RADIUS clients. It is optionally possible to run this integration side-by-side with other RADIUS authentication systems, e.g. hardware-token based two-factor authentication systems. When using Windows Server 2003, RADIUS protection is provided by means of an extension for the Microsoft Internet Authentication Service (IAS). When using Windows Server 2008 or 2012, RADIUS protection is provided by means of an extension for the Microsoft Network Policy Server (NPS). Besides VPN systems the RADIUS protection component is also useful for protecting access to Microsoft SharePoint Portal servers using application gateways, e.g. using Microsoft Intelligent Application Gateway, Microsoft Unified Access Gateway, Citrix Access Gateway Enterprise Edition or Juniper SA. Cloud Application Protection Integrates with Microsoft Active Directory Federation Services (AD FS) 2.0 providing SMS PASSCODE authentication for cloud applications protected by AD FS 2.0. Cloud applications are supported that use form-based authentication, and use any of the following protocols for authentication: SAML 2.0 WS-Federation WS-Trust

28 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 28 OF 407 Component ISA/TMG Web Site Protection Description Integrates SMS PASSCODE with Microsoft ISA/TMG Server, providing SMS PASSCODE authentication for web sites directly on an ISA/TMG Server. The web sites are required to be published through the ISA/TMG server using a Web Listener. Currently the following types of web sites are supported: Microsoft Outlook Web Access Microsoft Terminal Service Web Access (TS Web Access) Microsoft SharePoint Portal Server IIS web sites using authentication delegation Any web site not requiring any pass-through authentication (authentication delegation) SMS PASSCODE authentication can be enabled and disabled for each specific Web Listener in the ISA/TMG server. ISA/TMG Web Site protection is provided by means of an ISA/TMG filter. IIS Web Site Protection Integrates SMS PASSCODE with Microsoft Internet Information Server (IIS) providing SMS PASSCODE authentication for IIS Web Sites. Currently the following types of Web Sites are supported: Microsoft Outlook Web Access 2007, 2010 and IIS Web Sites using Basic or Integrated Windows Authentication 5 Microsoft Terminal Service Web Access (TS Web Access), Windows Server 2008 only. Microsoft Remote Desktop Web Access (RD Web Access), Windows Server 2008 R2 only. SMS PASSCODE authentication can be enabled/disabled for each specific IIS web site it is even possible to configure different settings for specific URL s and/or specific client IP addresses. IIS Web Site protection is provided by means of an ISAPI filter. Windows Logon Protection Integrates SMS PASSCODE with Windows Logon, thereby providing SMS PASSCODE authentication for users logging on Windows. This is for example useful for protecting Microsoft Terminal Service / Remote Desktop server environments, or VMware View virtual clients. SMS PASSCODE authentication can be enabled and disabled for each specific RDP Listener. Windows Logon integration is provided by means of a custom GINA (Windows XP and Windows Server 2003) and a custom Credential Provider (Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2). 5 Please note that when protecting an OWA 2013 site, only form-based authentication is supported

29 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 29 OF 407 Component Secure Device Provisioning (for ActiveSync devices) Description Integrates SMS PASSCODE with Microsoft Exchange Server s built-in functionality for provisioning of ActiveSync Devices, thereby providing secure, multi-factor authentication based selfprovisioning of such devices. The integration is provided by means of two components: The SMS PASSCODE Monitoring Module, which is an HTTP Module that monitors the ActiveSync traffic on each server with the Exchange CAS role. The SMS PASSCODE Secure Device Provisioning Web Site, to which users will be redirected for performing secure self-provisioning of new ActiveSync devices. Password Reset Module Password Reset Web Site Password Reset Backend Service Add-on module providing a web site where SMS PASSCODE users that have forgotten their AD password can reset this password in a secure way. The module actually consists of two components that can be installed on separate servers: The SMS PASSCODE Password Reset Web Site and the SMS PASSCODE Password Reset Backend Service. The Password Reset Web Site provides the user interface of the Password Reset module. It acts as a proxy for the actual Password Reset logic, which is performed by the Password Reset Backend Service. The components Database Service, Web Administration Interface and Transmitter Service are required components i.e. they must always be present in an SMS PASSCODE installation. The remaining components are optional. The term SMS PASSCODE core component is used in the subsequent sections of this documentation to denote one of the components: Database Service, Web Administration Interface, Transmitter Service, Load Balancing Service or Self Service Web Site. The term SMS PASSCODE Authentication client is used in the subsequent sections of this documentation to denote one of the components: Citrix Web Interface Protection, RADIUS Protection, Cloud Application Protection, ISA/TMG Web Site Protection, IIS Web Site Protection, Windows Logon Protection or Secure Device Provisioning

30 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 30 OF LICENSING This section describes how SMS PASSCODE licensing relates to the SMS PASSCODE components described in the previous section. When acquiring SMS PASSCODE software, you have to take different kinds of licenses into account: Starter Pack Acquisition of an SMS PASSCODE Starter Pack is required for any SMS PASSCODE installation. Client Access Licenses (CALs) Each CAL provides a single end-user the right to access specific types of clients. Modem Licenses Each modem license allows a single hardware modem to be attached to the SMS PASSCODE infrastructure. Please note that you may install every SMS PASSCODE component as many times as you like within your infrastructure, without acquiring extra licenses for this; the one exception being the SMS PASSCODE Database component, which is only allowed to be installed once per SMS PASSCODE Starter Pack acquired. The following types of CALs exist: MFA Standard CAL Each such CAL provides a single user the right to access any number of SMS PASSCODE Authentication Clients within a single SMS PASSCODE installation. Password Reset CAL Each such CAL provides a single user the right to access any number of SMS PASSCODE Password Reset Web Sites within a single SMS PASSCODE installation. The table below summarizes the licensing requirements: Component Number of installations allowed License requirements Database Service The Database Service is allowed to be installed once within a single SMS PASSCODE infrastructure (i.e. once per acquired SMS PASSCODE Starter Pack). - Web Administration Interface No limitation. - Transmitter Service No limitation. A modem license per modem Load Balancing Service No limitation. - Self Service Web Site No limitation. -

31 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 31 OF 407 Component Number of installations allowed License requirements Citrix Web Interface Protection No limitation. Each user needs to have a MFA Standard CAL allocated. RADIUS Protection No limitation. Each user needs to have a MFA Standard CAL allocated. Cloud Application Protection ISA/TMG Web Site Protection No limitation. No limitation. Each user needs to have a MFA Standard CAL allocated. Each user needs to have a MFA Standard CAL allocated. IIS Web Site Protection No limitation. Each user needs to have a MFA Standard CAL allocated. Windows Logon Protection Secure Device Provisioning (for ActiveSync devices) Password Reset Web Site No limitation. No limitation. No limitation. Each user needs to have a MFA Standard CAL allocated. Each user needs to have a MFA Standard CAL allocated. Each user needs to have a Password Reset CAL allocated. Password Reset Backend Service No limitation. - NOTE: Under specific circumstances, a user might be allowed to log in to an SMS PASSCODE Authentication client without an SMS PASSCODE Standard MFA CAL allocated, when bypassing multi-factor authentication. Please read section 7.1 below for details. 7.1 Authentication Behavior: Authentication Clients The table below summarizes authentication behavior for SMS PASSCODE protected authentication clients. Please note that the behavior can be affected by the Authentication Policy

32 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 32 OF 407 assigned to the user (cf. section 15.8) and by the fact whether Proof-of-Concept (PoC) mode has been enabled (cf. section ): User Exists in the SMS PASSCODE Database MFA Standard CAL allocated to the user Default behavior (PoC mode disabled) PoC mode enabled Yes Yes If the user attempts to log in to an SMS PASSCODE protected authentication client, authentication occurs according to the user s Authentication Policy. This typically means that multi-factor authentication occurs, unless explicitly defined otherwise by the Authentication Policy. Yes No If the user attempts to log in to an SMS PASSCODE protected authentication client, access is denied unless the user s Authentication Policy is set to bypass multifactor authentication. No - The user is not allowed to log in to any SMS PASSCODE protected authentication client. No change, i.e. default behavior as described in the column to the left. The user is allowed to log in to any SMS PASSCODE protected authentication client, bypassing multifactor authentication (i.e. the user s Authentication Policy is not applied) No change, i.e. default behavior as described in the column to the left. 7.2 Authentication Behavior: Password Reset The table below summarizes authentication behavior for the SMS PASSCODE Password Reset Web Site. Please note that the behavior can be affected by the Authentication Policy assigned to the user (cf. section 15.8), whereas Proof-of-Concept (PoC) mode (cf. section ) has no impact in this case: User Exists in the SMS PASSCODE Database Password Reset CAL allocated to the user Default behavior (PoC mode disabled) PoC mode enabled Yes Yes The user has access to the SMS PASSCODE Password Reset Web Site using multi-factor authentication, unless the user s Authentication Policy denies access. Bypassing multi-factor authentication can never occur. Yes No The user has no access to the SMS PASSCODE Password Reset Web Site. No - The user has no access to the SMS PASSCODE Password Reset Web Site. No change, i.e. default behavior as described in the column to the left. No change, i.e. default behavior as described in the column to the left. No change, i.e. default behavior as described in the column to the left.

33 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 33 OF SYSTEM REQUIREMENTS In this section, the system requirements are listed for each SMS PASSCODE software component (cf. section 6). Please note: All SMS PASSCODE components require the Microsoft.NET 3.5 SP1 Framework; except the Password Reset Web Site component, which requires the Microsoft.NET 4.5 Framework. The SMS PASSCODE Secure Device Provisioning component requires both the Microsoft.NET 3.5 SP1 and.net 4.5 Framework. Component Requirement Database Service Supported operating systems: o Windows Server 2003 (x86/x64) o Windows Server 2008 (x86/x64) o Windows Server 2008 R2 (x64) o Windows Server 2012 (x64) o Windows Server 2012 R2 (x64) Pre-requisite: Microsoft.NET Framework 3.5 SP1 installed beforehand If you are planning to enable the Active Directory Integration feature, it is recommended to install this component on a domain member server or a domain controller. Web Administration Interface Supported operating systems: o Windows Server 2003 (x86/x64) o Windows Server 2008 (x86/x64) o Windows Server 2008 R2 (x64) o Windows Server 2012 (x64) o Windows Server 2012 R2 (x64) IIS 6.0, 7.0, 7.5, 8.0 or 8.5 required Pre-requisite: Microsoft.NET Framework 3.5 SP1 installed beforehand It is recommended to install this component on the same server as the Database Service component. However, it is possible to install this component on a separate server (cf. section 8.4, page 40). Transmitter Service Supported operating systems: o Windows Server 2003 (x86/x64) o Windows Server 2008 (x86/x64) o Windows Server 2008 R2 (x64) o Windows Server 2012 (x64) o Windows Server 2012 R2 (x64) Pre-requisite: Microsoft.NET Framework 3.5 SP1 installed beforehand An unused serial port 6 (COM port) for each GSM modem. An active SIM card for each GSM modem in use. 6 If the server does not have a free serial port, you may use a serial port server instead. When using this solution, you map a virtual serial port on the computer to a serial port on a device, which is connected to the network. SMS PASSCODE has been tested with serial port servers ( Terminal Servers ) from Moxa ( It is recommended to use secure serial port servers,

34 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 34 OF 407 Component Requirement Load Balancing Service Supported operating systems: o Windows Server 2003 (x86/x64) o Windows Server 2008 (x86/x64) o Windows Server 2008 R2 (x64) o Windows Server 2012 (x64) o Windows Server 2012 R2 (x64) Pre-requisite: Microsoft.NET Framework 3.5 SP1 installed beforehand Self Service Web Site Supported operating systems: o Windows Server 2003 (x86/x64) o Windows Server 2008 (x86/x64) o Windows Server 2008 R2 (x64) o Windows Server 2012 (x64) o Windows Server 2012 R2 (x64) IIS 6.0, 7.0, 7.5, 8.0 or 8.5 required Pre-requisite: Microsoft.NET Framework 3.5 SP1 installed beforehand Must be installed on a domain member server or a domain controller. It is recommended to install this component on the same server as the Database Service component. However, it is possible to install this component on a separate server (cf. section 8.4, page 40). Citrix Web Interface Protection Supported operating systems: o Windows Server 2003 (x86/x64) o Windows Server 2008 (x86/x64) o Windows Server 2008 R2 (x64) Pre-requisite: Microsoft.NET Framework 3.5 SP1 installed beforehand You must install Citrix Web Interface on the server and publish at least one Web Interface before installing this component. The following Citrix Web Interface versions are supported on Windows Server 2003 (x86/x64): o Citrix Web Interface 4.6 o Citrix Web Interface 5.3.0, and o Citrix Access Essentials 2.0 The following Citrix Web Interface versions are supported on Windows Server 2008 (x86/x64) and Windows Server 2008 R2 x64: o Citrix Web Interface 5.3.0, and AD and NDS authentication is supported. which encrypt the network communication (e.g. Moxa Nport 6000 series). It is also advantageous to use serial port servers in case you need to connect a lot of GSM modems to the same computer, since serial port servers with many serial ports are available. IMPORTANT: In case of using any Moxa device, please ensure that the installed drivers are supported for the Windows operating system in use.

35 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 35 OF 407 Component Requirement RADIUS Protection Supported operating systems: o Windows Server 2003 (x86/x64) o Windows Server 2008 (x86/x64) o Windows Server 2008 R2 (x64) o Windows Server 2012 (x64) o Windows Server 2012 R2 (x64) Please note: Only Windows Server Editions including the Internet Authentication Service (IAS) or Network Policy Service (NPS) are supported. This means, that Windows Server 2003 Web Edition, Windows Server 2008 Web Edition, Windows Server 2012 Hyper-V Edition and Windows Server 2012 Storage Edition are not feasible. Windows Server 2003: Internet Authentication Service (IAS) must be installed before installing this component. Windows Server 2008 (R2) and Windows Server 2012 (R2): Network Policy Service (NPS) must be installed before installing this component. Pre-requisite: Microsoft.NET Framework 3.5 SP1 installed beforehand Supported RADIUS clients: All RADIUS clients that support the PAP or MS-CHAP v2 authentication protocol. The best user experience is achieved using RADIUS clients that support PAP with Challenge Response. Among others the following RADIUS clients support Challenge Response: o Juniper SSL VPN o o o Fortigate SSL VPN Cisco PIX 5XX min. Cisco VPN client (PC) min. Cisco VPN client 4.9 (MAC) Cisco ASA 5XXX min. Cisco VPN client 4.8 (PC) min. Cisco VPN client 4.9 (MAC) o Cisco VPN Concentrator 3000 min. Cisco VPN client 4.8 (PC) min. Cisco VPN client 4.9 (MAC) o Check Point FW-1/VPN-1 NG/FP3 Check Point VPN-1 SecuRemote Connection Client o Citrix Access Gateway 4.x 8 Standard Edition (min. ver. 4.5) Enterprise Edition o Citrix Access Gateway 5.0 o o Microsoft Intelligent Application / Unified Access Gateway (IAG/UAG) WatchGuard Firebox WatchGuard Windows VPN Client Please contact your SMS PASSCODE reseller or support@smspasscode.com for further information regarding supported RADIUS clients. 7 Please note, that versions x x had problems with the RADIUS challenge/response implementation. You must upgrade to a newer version of the Cisco VPN client 5.x. 8 Please note, that Citrix Access Gateway 4.x Advanced Edition does NOT support Challenge Response.

36 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 36 OF 407 Component Requirement Cloud Application Protection ISA/TMG Web Site Protection IIS Web Site Protection Windows Logon Protection Supported operating systems: o Windows Server 2008 (x86/x64) o Windows Server 2008 R2 (x64) o Windows Server (x64) Pre-requisite: Microsoft.NET Framework 3.5 SP1 installed beforehand Microsoft AD FS 2.0 must be installed before installing this component 10. Supported scenarios: o Windows Server 2003 x86 with Microsoft ISA Server 2006 SP1 installed. o Windows Server 2008 x64 with Microsoft TMG 2010 installed. o Windows Server 2008 R2 x64 with Microsoft TMG 2010 installed. Pre-requisite: Microsoft.NET Framework 3.5 SP1 installed beforehand Supported operating systems: o Windows Server 2003 (x86/x64) o Windows Server 2008 (x86/x64) o Windows Server 2008 R2 (x64) o Windows Server 2012 (x64) o Windows Server 2012 R2 (x64) Pre-requisite: Microsoft.NET Framework 3.5 SP1 installed beforehand IIS 6.0, 7.0, 7.5, 8.0 or 8.5 required Supported operating systems: o Windows XP (x86/x64) 11 o Windows Server 2003 (x86/x64) o Windows Vista (x86/x64) 11 o Windows 7 (x86/x64) 11 o Windows 8 (x86/x64) 11 o Windows 8.1 (x86/x64) 11 o Windows Server 2008 (x86/x64) o Windows Server 2008 R2 (x64) o Windows Server 2012 (x64) o Windows Server 2012 R2 (x64) Pre-requisite: Microsoft.NET Framework 3.5 SP1 installed beforehand Terminal Service / Remote Desktop is supported Secure Device Provisioning (for ActiveSync devices) Supported on Windows Servers with the Exchange Client Access Server (CAS) role installed beforehand. The following versions of Microsoft Exchange Server are supported: Exchange Server 2010 Exchange Server 2013 Pre-requisite: Microsoft.NET Framework 3.5 SP1 and Microsoft.NET Framework 4.5 installed beforehand.

37 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 37 OF 407 Component Requirement Password Reset Web Site Password Reset Backend Service Supported operating systems: o Windows Server 2008 (x86/x64) o Windows Server 2008 R2 (x64) o Windows Server 2012 (x64) o Windows Server 2012 R2 (x64) Pre-requisite: Microsoft.NET Framework 4.5 installed beforehand IIS 7.0, 7.5, 8.0 or 8.5 required A certificate is required to protect communication with the Password Reset Web Site using SSL/TLS. Supported operating systems: o Windows Server 2003 (x86/x64) o Windows Server 2008 (x86/x64) o Windows Server 2008 R2 (x64) o Windows Server 2012 (x64) o Windows Server 2012 R2 (x64) Pre-requisite: Microsoft.NET Framework 3.5 SP1 installed beforehand It is recommended to install a certificate on relevant domain controller(s) to encrypt the communication between the Password Reset Backend Service and the domain controller(s) using SSL/TLS. 8.1 Requirements for Location and Behavior Aware Authentication Location and behavior aware authentication 12 is the overall term for making use of Passcode Policies, Authentication Policies and User IP Histories to achieve a more advanced and secure authentication experience. The pre-requisite for this to work is that the SMS PASSCODE system must be able to collect the correct end-user IP address that an authentication attempt originates from. 9 Windows Server 2012 R2 is NOT supported yet 10 On Windows Server 2012 please note, that AD FS 2.0 is not supported on Hyper-V, Storage or MultiPoint Editions. 11 It is not recommended to install Windows Logon Protection on laptops because SMS PASSCODE logon is only possible when the laptop is able to connect to a SMS PASSCODE Transmitter Service. Since this connection is typically established via the network, the laptop may lose its connection to the Transmitter service when it is undocked and thereby prohibit user authentication. 12 Please read section 14.1 (page 105) for more details about location and behavior aware authentication

38 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 38 OF 407 The table below lists the pre-requisites for this with respect to the different types of authentication clients supported by SMS PASSCODE : Authentication Client Citrix Web Interface Protection IIS Web Site Protection Cloud Application Protection Secure Device Provisioning (for ActiveSync devices) Password Reset Module RADIUS Protection ISA/TMG Web Site Protection Pre-requisite for collection of end-user IP addresses The pre-requisites for all web-based authentication clients are the same. These clients are basically running on an Internet Information Server (IIS) that reports the end-user IP address of the web client to the SMS PASSCODE system. A problem might be that the IIS in question is located behind a reverse-proxy (e.g. Citrix Secure Gateway, Citrix Access Gateway or ISA/TMG) or other type of network device (e.g. network load balancer), that hides the real end-user IP address from the IIS. If this is the case, you have two options for regaining access to the real end-user IP address: Re-configure the network device to report the real end-user IP address to the IIS. Configure the network device to report the real enduser IP address as an HTTP header value. SMS PASSCODE can then be configured to retrieve enduser IP addresses from this specific HTTP header (cf. section 20.2, page 392). End-user IP addresses are collected from the Calling Station ID attribute of the RADIUS packets received from the RADIUS client. I.e. end-user IP addresses are collected successfully, only when the RADIUS client supports reporting of end-user IP addresses. In a typical setup, ISA/TMG Servers will receive real end-user IP addresses without any problems. However, a problem might be that an ISA/TMG Server is located behind a network device (e.g. network load balancer), that hides the real end-user IP address from the ISA/TMG. If this is the case, you must re-configure the network device to report the real end-user IP address to the ISA/TMG. Windows Logon Protection When accessing the SMS PASSCODE protected machine using RDP, the correct end-user IP address of the RDP client is collected. However, please note that when an RD Gateway is involved, the RD Gateway will act as the RDP client, i.e. the IP address of the RD Gateway will then be reported. If you still would like to get the correct end-user IP address in this case, consider providing external access only through an RD Web site protected by SMS PASSCODE multi-factor authentication. Collection of end-user IP addresses can then be enabled on the RD Web Site instead.

39 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 39 OF 407 Important: Collection of end-user IP addresses is disabled by default By default, collection of end-user IP addresses is disabled for all authentication clients installed. You must use the SMS PASSCODE Configuration Tool to enable collection of end-user IP addresses and this must be done explicitly for every authentication client where this is wanted. Please read section 20.2 (page 392) for more details. WARNING: Enabling collection of end-user IP addresses should only be done by network experts having a deep understanding whether the IP addresses are collected correctly in a trustworthy manner. 8.2 Terminal Service / Remote Desktop Service Protection Access to Terminal Services or Remote Desktop Services can be protected by SMS PASSCODE authentication in several ways. Windows Server 2003: When using Terminal Services on Windows Server 2003, please install the SMS PASSCODE Windows Logon Protection component on each Terminal Service host requiring SMS PASSCODE protection. Windows Server 2008 (R2): When using Terminal Services / Remote Desktop Services on Windows Server 2008 (R2) you have two options to implement SMS PASSCODE authentication: 1. Protecting a TS / RD Web Access site directly on the IIS: Install the SMS PASSCODE IIS Web Site Protection component on the server hosting the TS / RD Web Access site. It is mandatory, that the TS / RD Web Access site and the TS / RD Gateway site are installed on the same IIS. If the RD Web Access site is hosted on a Windows Server 2008 R2, then form-based authentication and single sign-on (SSO) is supported Protecting Windows Logon on all TS / RD session host servers: Install the SMS PASSCODE Windows Logon Protection component directly on each Terminal Service / Remote Desktop Service session host requiring SMS PASSCODE protection. Windows Server 2012 (R2): When using Remote Desktop Services on Windows Server 2012, please install the SMS PASSCODE Windows Logon Protection component on each RD Session host server requiring SMS PASSCODE protection. Please refer to sections and for details about setting up TS / RDS Protection. 8.3 SharePoint Portal Server Protection SMS PASSCODE supports protection of Microsoft SharePoint Portal Server (version 2003 and newer). Please refer to section (page 71) for more details regarding SharePoint Portal server protection. 13 If you experience any of the problems during single sign-on described in the MS support article then please contact support@smspasscode.com to get assistance.

40 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 40 OF Installing Web Sites on a Non-DB Server in the same Domain As mentioned in the system requirements table in section 7 it is recommended to install the SMS PASSCODE Web Administration Interface and SMS PASSCODE Self Service Web Site (if installed) on the same server as the SMS PASSCODE Database service. However, it is possible to install any of the web sites on a separate server. This section describes how to install any of the web sites on a separate server that is a member of the same domain as the DB server 14. The steps to install one of the web sites on a separate server in the same domain are described below. Please note that you need to create a dedicated domain user that is used for the connection between the site(s) and the DB service. 1. Create a new domain user that is dedicated for being used for remote access to the DB service. 2. Log on to the server where the SMS PASSCODE Database component is installed. Locate the folder containing the DB files. The default location is: C:\Program Files\SMS PASSCODE\Database Assign read and write permissions to this folder for the user created in step Restart the SMS PASSCODE Database service. Now the dedicated user will have read and write access to the SMS PASSCODE database from any other server. 4. Install the SMS PASSCODE web site (Web Administration Interface or Self Service Site) on a separate server (cf. section 13.2, page 76). This server is called the web site server below. 5. On the web site server, locate the secret.dat file in the SMS PASSCODE installation folder. The default location is: C:\Program Files\SMS PASSCODE\secret.dat Assign read permissions to this file for the user created in step If you need to install one of the web sites on a separate server outside the domain, then please contact support (support@smspasscode.com) for advice on this.

41 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 41 OF On the web site server, open the IIS manager and go to the Application Pools section: a. In case of the SMS PASSCODE Web Administration Interface: Select the Application Pool SMS PASSCODE AppPool, and then click the Advanced Settings link in the Actions pane: b. In case of the SMS PASSCODE Self Service Web Site: Select the Application Pool SMS PASSCODE Self Service AppPool, and then click the Advanced Settings link in the Actions pane.

42 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 42 OF In the Advanced Settings dialog, click the button to the right of the Identity setting: 8. In the Application Pool Identity dialog that appears, select the Custom account option and then click the Set button: 9. In the Set Credentials dialog that appears, enter the user name and password of the user created in step 1. Then click the OK button. 10. Click the OK button in the Application Pool Identity dialog. 11. Click the OK button in the Advanced Settings dialog. 12. This completes the setup. Start the web site and check that everything works as expected.

43 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 43 OF HARDWARE GSM MODEMS When acquiring an SMS PASSCODE license you always start with the acquisition of the SMS PASSCODE starter pack. This starter pack includes the first user licenses (CALs) and a modem license. If you would like to use more modems in your SMS PASSCODE solution to support failover or extended scalability, then you must acquire an additional modem license for each modem. Both, the SMS PASSCODE starter pack and each additional modem license, include a modem pack. Each modem pack includes the following hardware: A Cinterion 15 (former Siemens) GSM modem. Power supply for the modem. Serial cable for the modem. Antenna for the modem. In short: SMS PASSCODE includes all hardware necessary to send SMS from a server. IMPORTANT: SMS PASSCODE does NOT include an active SIM card for each GSM modem. You must acquire a SIM card for each GSM modem yourself. SIM cards protected by a PIN code are supported by SMS PASSCODE. 10 INFRASTRUCTURE SMS PASSCODE is composed of various software components (cf. section 6) which can communicate with each other across the network. This provides great flexibility regarding the distribution of the components on different servers which enables optimizing the SMS PASSCODE installation to your specific server infrastructure. Since you can distribute the SMS PASSCODE components in almost any way you like, there are a huge number of possible installation scenarios. The possibilities span from the very simple installation case, where all components are installed on the same server, to the advanced total distribution installation case, where all components are distributed onto different machines. A lot of other scenarios exist between these two extremes you can install some components together on a machine while other components are installed individually on other machines. The purpose of this section is to show selected network diagrams that illustrate different sample SMS PASSCODE installation scenarios. 15 SMS PASSCODE supports the Cinterion MC35i, MC52i, MC55i, TC63i, TC65, MC75, BGS2-W and EES3 modems. In case you need a modem with 3G support, this is also possible; please contact SMS PASSCODE support.

44 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 44 OF 407 Please note that if you do not need the flexibility of distributing components to multiple servers, but would rather prefer a very simple installation on a single server, you have the option of just installing all required components on a single server. Active Directory Integration / single sync mode When using Active Directory Integration in single sync mode, it is recommended to install the Database Service component on a server that is a member of the domain (installing on a domain controller is also allowed, but not necessary). I.e. when planning for an installation with some components being installed in a DMZ you will typically locate the Database Service on the LAN side of the firewall Component Communication Distributed SMS PASSCODE components communicate via the network. Communication takes place using the TCP/IP protocol all network messages are encrypted using strong 256-bit AES encryption. SMS PASSCODE uses several TCP ports as described below: Component Incoming Outgoing Database Service Listens by default on the two TCP ports 9090 and 9091 Communicates with all Transmitter services (TCP port 8989) Communicates with all Load Balancing services (TCP port 8988), if any installed Communicates with one or more Domain Controllers, in case Active Directory Integration has been enabled (using LDAP or Global Catalog, possibly using SSL) Web Administration Interface Listens by default on TCP port 2000 Communicates with the Database service (TCP port 9091) Communicates with Transmitter services (TCP port 8989), when sending any test messages and no Load Balancing service is in use Communicates with Load Balancing services (TCP port 8988), when sending any test messages and any Load Balancing service is in use Transmitter Service Listens by default on TCP port 8989 Communicates with the Database service (TCP port 9090) Load Balancing Service Listens by default on TCP port 8988 Communicates with the Database service (TCP port 9090) Communicates with all Transmitter services (TCP port 8989) Self Service Web Site Listens by default on TCP port 3000 Communicates with the Database service (TCP port 9091) Communicates with one or more Domain Controllers, in case Active Directory Integration has been enabled (using LDAP or LDAPS)

45 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 45 OF 407 Component Incoming Outgoing SMS PASSCODE Authentication clients - Depending on the configuration, communicates with either: a list of Transmitter services (TCP port 8989) -- or -- a list of Load Balancing services (TCP port 8988) Password Reset Web Site Listens by default on TCP port 5000 Communicates with the Password Reset Backend Service (TCP port 8888) Password Reset Backend Service Listens by default on TCP port 8888 Communicates with one or more Domain Controllers (using LDAP or LDAPS) Additionally uses same outgoing ports as the SMS PASSCODE Authentication clients (for transmission) The usage of the different TCP ports during component communication is also illustrated using network diagrams in the following sections (e.g. the network diagram in section 10.6, page 53, gives a good overview). Section 17.4 (page 296) contains Password Reset Module specific network diagrams illustrating the communication between the Password Reset Web Site and Password Reset Backend Service components. You can change the default TCP ports during an installation (or afterwards), in case they are in conflict with other applications.

46 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 46 OF Simple Installation The simplest form of SMS PASSCODE installation is to install all required components on a single server. The following (required) components must always be installed during this type of installation: Database Service Web Administration Interface Transmitter Service The remaining components are optional. LAN INTERNET CLIENT Active Directory Server Server can optionally be placed in DMZ GSM Modem(s) AD Sync. (optional) serial SMS PASSCODE Server Firewall SMS PASSCODE Database Service SMS PASSCODE Web Administration Interface SMS PASSCODE Transmitter Service SMS PASSCODE Self Service Web Site (optional) SMS PASSCODE Citrix Web Interface Protection (optional) SMS PASSCODE RADIUS Protection (optional) SMS PASSCODE Cloud Application Protection (optional) SMS PASSCODE ISA/TMG Web Site Protection (optional) SMS PASSCODE IIS Web Site Protection (optional) SMS PASSCODE Windows Logon Protection (optional)

47 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 47 OF Standard Installation Citrix Web Interface In this section an installation example with several Citrix Web Interface servers is shown. A possibility in this case is to install the Citrix Web Interface Protection component on each Citrix Web Interface server and to install the Database Service, Web Administration Interface and Transmitter Service components on a different server: LAN DMZ GSM Modem(s) Firewall TCP 8989 TCP 8989 SMS PASSCODE Server SMS PASSCODE Database Service SMS PASSCODE Web Administration Interface SMS PASSCODE Transmitter Service SMS PASSCODE Self Service Web Site (optional) Citrix Web Interface Server SMS PASSCODE Citrix Web Interface Protection AD Sync. (optional) Citrix Web Interface Server SMS PASSCODE Citrix Web Interface Protection Active Directory Server Citrix Web Interface Server SMS PASSCODE Citrix Web Interface Protection Citrix Presentation Server farm

48 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 48 OF 407 For failover reasons it would be better to have several Transmitter Service components installed. In this case, if any Transmitter service would become unavailable for some reason, then each Citrix Web Interface server can communicate with another Transmitter service. You can install as many Transmitter services as you like. The example below illustrates the usage of two Transmitter services: GSM Modem(s) LAN Firewall DMZ TCP 8989 SMS PASSCODE Failover server SMS PASSCODE Transmitter Service GSM Modem(s) TCP 8989 Citrix Web Interface Server SMS PASSCODE Citrix Web Interface Protection TCP 8989 TCP 9090 SMS PASSCODE Database Server SMS PASSCODE Database Service SMS PASSCODE Web Administration Interface SMS PASSCODE Transmitter Service SMS PASSCODE Self Service Web Site (optional) Citrix Web Interface Server SMS PASSCODE Citrix Web Interface Protection AD Sync. (optional) Citrix Web Interface Server SMS PASSCODE Citrix Web Interface Protection Active Directory Server Citrix Presentation Server farm

49 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 49 OF 407 When using several Transmitter services, each Citrix Web Interface server will communicate with the Transmitter services according to a prioritized list, i.e. failover without load balancing is provided. If you wish to have real load balancing between the Transmitter services (or if you wish to make use of Load Balancing Policies), then you must also install the optional Load Balancing service. You can install any number of Load Balancing services (to have failover on this level as well). The example below illustrates the usage of two Load Balancing services: GSM Modem(s) LAN Firewall DMZ TCP 8988 TCP 8989 SMS PASSCODE Failover server SMS PASSCODE Load Balancing Service SMS PASSCODE Transmitter Service GSM Modem(s) TCP 8988 Citrix Web Interface Server SMS PASSCODE Citrix Web Interface Protection TCP 8988 TCP 8989 TCP 9090 SMS PASSCODE Database Server SMS PASSCODE Database Service SMS PASSCODE Web Administration Interface SMS PASSCODE Load Balancing Service SMS PASSCODE Transmitter Service SMS PASSCODE Self Service Web Site (optional) Citrix Web Interface Server SMS PASSCODE Citrix Web Interface Protection AD Sync. (optional) Citrix Web Interface Server SMS PASSCODE Citrix Web Interface Protection Active Directory Server Citrix Presentation Server farm

50 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 50 OF Standard Installation RADIUS Clients In this section an installation example is shown with SMS PASSCODE being used for RADIUS authentication. Whereas a possibility is to install all necessary SMS PASSCODE components on the RADIUS server itself, the example below illustrates another scenario where the RADIUS Protection component is installed on the RADIUS server and the remaining components are installed on a separate server: LAN Internet GSM Modem(s) SMS PASSCODE Database Service SMS PASSCODE Web Administration Interface SMS PASSCODE Transmitter Service SMS PASSCODE Self Service Web Site (optional) AD Sync. (optional) SMS PASSCODE Server TCP 8989 Cisco Cisco VPN Client Active Directory Server Radius UDP 1812 UDP 1645 Juniper Juniper Client RADIUS Server MS IAS or MS NPS SMS PASSCODE RADIUS Protection Radius UDP 1812 UDP 1645 Citrix Access Gateway CAG Client

51 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 51 OF Standard Installation Enterprise Setup SMS PASSCODE supports enterprise environments with 24x7 uptime demands. This is achieved by supporting failover on all levels of the SMS PASSCODE infrastructure: Failover on the database level: The Database service continuously pushes all data changes to all Transmitter services and Load Balancing services. All data is cached locally which means that all Transmitter services and Load Balancing services have access to all data even in case the Database service becomes unavailable. Failover on the Transmitter service level: Failover on the transmitter level can be achieved in two different ways: o o Simple failover without Load Balancing service(s): On each server with one or more SMS PASSCODE authentication clients installed, you can just specify a prioritized list of Transmitter services to use. In this case, each authentication client will automatically switch to another Transmitter service in case the currently used Transmitter service becomes unavailable. Please note, that failover only occurs, when a Transmitter service itself is unavailable. There is no failover because of modems connected to a Transmitter being unavailable. If you wish a more intelligent and powerful failover, please consider the next option: Advanced failover failover with Load Balancing service(s): (recommended) If your concern is to have the most powerful failover and the best scalability (expecting heavy loads), or if you need to make use of Load Balancing Policies, the installation and use of Load Balancing services is required. In this case, each Load Balancing service will continuously monitor all Transmitter services and ensure an intelligent load balancing of all incoming authentication requests between all available Transmitter services and message dispatchers (i.e. GSM modems, SMTP servers etc.). The failover/load balancing algorithm is customizable using Load Balancing Policies. Using these policies it is possible to define in detail how incoming requests should be distributed according to customizable Load Balancing Rules. Please refer to section (page 251) for more information regarding this. Failover on the GSM modem level: Up to 32 GSM Modems may be connected to each Transmitter service in a modem pool. Each Transmitter service automatically performs intelligent load balancing between all available modems in its modem pool. In case a modem becomes unavailable, then the Transmitter directs incoming requests to other GSM Modems in the modem pool. By using SIM cards of different GSM service providers, you can even achieve failover on the carrier level. Failover on the message dispatching level: If you have users that cannot receive one-time-passcodes (OTPs) by SMS, you can define policies to allow authentication by other means (e.g. send OTPs by , or allow authentication using hardware tokens, software tokens or time-constrained personal passcodes).

52 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 52 OF 407 Failover on the authentication client level: Each SMS PASSCODE Authentication client can be configured to redirect its requests to either a list of several Transmitter services or a list of several Load Balancing services. In both cases, if any of the listed services becomes unavailable, then requests are automatically redirected to the services being available. Please notice that the list of services can be changed on-the-fly during operation without any downtime. For optimal failover your SMS PASSCODE installation should include: At least two Load Balancing services. At least two Transmitter services. At least two GSM Modems connected to each Transmitter service (i.e. at least 4 GSM modems in total). Each SMS PASSCODE Authentication client should redirect requests to at least two Load Balancing services. The following diagram illustrates an example of a minimum setup for optimal failover. In practice, you would most probably consolidate the four servers running Load Balancing Service and Transmitter Service on two servers, since a Load Balancing service and a Transmitter service may run on the same server. AD Sync. (optional) SMS PASSCODE Database Server SMS PASSCODE Database Service SMS PASSCODE Web Administration SMS PASSCODE Self Service Web Site (optional) Active Directory Server TCP 9090 GSM Modems TCP 8988 TCP 8988 TCP 8989 TCP 8989 GSM Modems Load Balancing Server 1 SMS PASSCODE Load Balancing Service Load Balancing Server 2 SMS PASSCODE Load Balancing Service TCP 8988 TCP 8988 SMS Gateway Server 1 SMS PASSCODE Transmitter Service SMS Gateway Server 2 SMS PASSCODE Transmitter Service Citrix Web Interface Server 1 SMS PASSCODE Citrix Web Interface Protection Citrix Web Interface Server 2 SMS PASSCODE Citrix Web Interface Protection

53 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 53 OF Standard Installation Total Distribution In this section, a last installation example is shown. This example illustrates how it is possible to completely distribute all components on separate servers. The first diagram shows a complete distribution without making use of the Load Balancing Service: LAN DMZ TCP 9091 Firewall SMS PASSCODE Database Server SMS PASSCODE Database Service SMS PASSCODE Web Administration Interface Citrix Advanced Access Control Server SMS PASSCODE Cloud App Protection TCP 9090 Web Server (IIS) SMS PASSCODE Self Service Web Site GSM Modems Web Server (IIS) e.g. OWA Server SMS PASSCODE IIS Web Site Protection AD Sync. (optional) TCP 8989 TCP 8989 Citrix Web Interface Server SMS PASSCODE Citrix Web Interface Protection (optional) SMS Gateway Servers SMS PASSCODE Transmitter Service TCP 8989 Terminal Server / Remote Desktop Server SMS PASSCODE Windows Logon Protection Security Gateway MS ISA/TMG Server SMS PASSCODE ISA/TMG Web Site Protection Active Directory Server Web Server (IIS) e.g. OWA Server RADIUS Server MS IAS or NPS SMS PASSCODE RADIUS Protection RADIUS client

54 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 54 OF 407 The second diagram below shows a complete distribution, including the Load Balancing Service: LAN GSM Modems DMZ SMS PASSCODE Database Server SMS PASSCODE Database Service SMS PASSCODE Web Administration Interface Firewall AD Sync. (optional) TCP 9091 TCP 9090 TCP 8989 SMS Gateway Servers SMS PASSCODE Transmitter Service TCP 8989 Citrix Advanced Access Control Server SMS PASSCODE Cloud App Protection Web Server (IIS) e.g. OWA Server SMS PASSCODE IIS Web Site Protection Active Directory Server TCP 8988 TCP 8988 Citrix Web Interface Server SMS PASSCODE Citrix Web Interface Protection (optional) Load Balancing Servers SMS PASSCODE Load Balancing Service TCP 8988 Web Server (IIS) SMS PASSCODE Self Service Web Site Terminal Server / Remote Desktop Server SMS PASSCODE Windows Logon Protection Security Gateway MS ISA/TMG Server SMS PASSCODE ISA/TMG Web Site Protection Web Server (IIS) e.g. OWA Server RADIUS Server MS IAS or NPS SMS PASSCODE RADIUS Protection RADIUS client

55 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 55 OF PRE-INSTALLATION ACTIONS This section describes the actions to perform BEFORE running the SMS PASSCODE installation program. Please read this section carefully Check SIM Cards Before running an SMS PASSCODE installation, please ensure that all SIM cards are working correctly. Important: It is strongly recommended to check each SIM card according to the instructions below BEFORE the SMS PASSCODE installation is started. It is our experience that more than 90% of all installation problems are related to SIM card problems. The procedure for checking a SIM card is described below. It is recommended to perform the check at the location where the GSM modem, for which the SIM card is intended, is located. For each SIM card perform the following actions: 1. Insert the SIM card into a cell phone. 2. Enter PIN code if the SIM card requires this. 3. Wait until the cell phone has been registered on the mobile network. 4. Enter a new SMS and send it to another cell phone. Check that the transmission succeeds and that the SMS is received correctly on the other cell phone. If the above check is not successful, it is usually caused by one of the following: The SIM card is not active or has been closed: Contact your cell phone operator and request activation of the SIM card. There is no GSM coverage at the location in question: You have the following possibilities in this case: o Move the server together with the GSM modem(s) to another location o Lengthen the antenna of the modem (e.g. to the roof of the building) o Move the GSM modem(s) to another location by installing the Transmitter Service on another server at a different location o Move the GSM modem(s) to another location by connecting them to a serial port server (e.g. Moxa NPort) connected to the network For further information regarding external modem antennas or serial port servers please contact your SMS PASSCODE reseller or support@smspasscode.com.

56 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 56 OF Check System Requirements Before running an SMS PASSCODE installation, please make sure that all system requirements are fulfilled for the components that you are planning to install. System requirements are listed in section 7 (page 30). Please remember: Citrix Web Interface Protection If you are planning to install the Citrix Web Interface Protection component, then a supported version of Citrix Web Interface must be installed on the Citrix Web Interface server beforehand and at least one Citrix Web Interface must have been published. RADIUS Protection o If you are planning to install the RADIUS Protection component on a Windows Server 2003, then the Internet Authentication Service (IAS) must be installed on this server beforehand. Installation of IAS is described in section o If you are planning to install the RADIUS Protection component on a Windows Server 2008 (R2) or Windows Server 2012 (R2), then the Network Policy Server (NPS) role must be added to this server beforehand. Installation of NPS is described in section Cloud Application Protection If you are planning to install the Cloud Application Protection component, then AD FS 2.0 must be installed on this server beforehand. It is also recommended to configure any cloud applications beforehand and ensure that standard authentication works without SMS PASSCODE. Please read section 19.3 (page 364) for more details. ISA/TMG Web Site Protection If you are planning to install the ISA/TMG Web Site Protection component on a server, then a Microsoft ISA Server 2006 SP1 or Microsoft TMG 2010 must be installed on this server beforehand. IMPORTANT: Before installing ISA/TMG Web Site Protection, it is recommended to create an Access Rule in the ISA/TMG management console allowing the ISA/TMG server (localhost) to communicate with the SMS PASSCODE Load Balancing server(s) or SMS PASSCODE Transmitter server(s), depending on your infrastructure setup. Please read section 10.1 (page 44) for details about the TCP ports used. IIS Web Site Protection If you are planning to install the IIS Web Site Protection component on a Windows Server 2003, then the Internet Information Server (IIS) must be installed on this server beforehand On Windows Server 2008 (R2) and Windows Server 2012 (R2) the IIS will be installed automatically if missing.

57 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 57 OF 407 Microsoft Terminal Services / Remote Desktop Services Protection If you are planning to protect Microsoft Remote Desktop Services, formerly called Microsoft Terminal Services, please notice that there are several ways to achieve this: o Windows Server 2008 (R2): Either protect the TS/RD Web Access site using the SMS PASSCODE IIS Web Site Protection component (cf. section , page 61), or protect each TS/RD Session host using the SMS PASSCODE Windows Logon Protection component (cf. section3, page 66). o Windows Server 2003/2012(R2): Protect each TS/RD Session host using the SMS PASSCODE Windows Logon Protection component (cf. section 3, page 66). Microsoft SharePoint Portal Server Protection If you are planning to protect Microsoft SharePoint Portal Server, please refer to section (page 71) before starting the SMS PASSCODE installation.

58 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 58 OF Installation of IAS This section describes how to install the Microsoft Internet Authentication Service (IAS) on a Windows Server You have to install IAS on a Windows Server 2003 only if you are planning to install the SMS PASSCODE RADIUS Protection component on this server. To install IAS, please follow the instructions below: 1. Click on Add/Remove Programs in the Control Panel:

59 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 59 OF Click on Add/Remove Windows Components: 3. A list of Windows Components appears. Scroll down to Networking Services. a. Mark Networking Services. b. Click the Details button

60 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 60 OF A list of Networking Services appears. a. Check Internet Authentication Service. b. Click the OK button. 5. Click the OK button. 6. Click the Next button. 7. Click the Finish button. IAS has now been installed.

61 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 61 OF Installation of NPS This section describes how to install the Microsoft Network Policy Server (NPS) role on a Windows Server 2008 (R2) or Windows Server You have to install NPS on a Windows Server 2008 (R2) or Windows Server 2012 only if you are planning to install the SMS PASSCODE RADIUS Protection component on this server. Windows Server 2008 (R2) To install NPS on a Windows Server 2008 (R2), please use the Server Manager or run the following command in a command prompt: ServerManagerCmd -i NPAS-Policy-Server Windows Server 2012 (R2) To install NPS on a Windows Server 2012 (R2), please use the Server Manager or run the following command in a PowerShell console: add-windowsfeature npas-policy-server Protection of TS/RD Web Access using IIS Web Site Protection This section describes how to protect the Terminal Services Web Access site on a Windows Server 2008, or the Remote Desktop Web Access Site on Windows Server 2008 R2. The term Remote Desktop Services (RDS) will be used to refer to both the former term Terminal Services and the newer term Remote Desktop Services.

62 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 62 OF 407 Please note that it is mandatory to access the RD session host servers through an RD Gateway when protecting access to RDS using an RD Web Access site. The following diagram illustrates the required infrastructure setup for performing SMS PASSCODE authentication on an RD Web Access server: Internal Network External Network Web Server MS Internet Information Server (IIS) RD Web Access + RD Gateway SMS PASSCODE IIS Web Site Protection RADIUS Server MS NPS Firewall (E.g. Cisco, CheckPoint, ISA/TMG) RD Session Host Servers SMS PASSCODE protected RD Web Access site with multi-factor authentication performed on the Web Server Please note: The SMS PASSCODE RADIUS protection component can NOT be installed on the RADIUS server. The Web Server and RADIUS server could be consolidated to a single server (installing both NPS and IIS 7.0/7.5 on the same server).

63 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 63 OF 407 The SMS PASSCODE IIS Web Site Protection component must be installed on the Web Server (i.e. the RD Web Access server). You may install any other SMS PASSCODE components on the Web Server as well. It is mandatory, that the RD Web Access site and RD Gateway site are hosted in the same site on the same IIS. Specific for Windows 2008 R2: o Single sign-on in the RD Web Access site is supported o Accessing Remote Applications through the RD Web Feed is not supported IMPORTANT: The SMS PASSCODE RD Web Access protection will ensure that all users MUST authenticate using the RD Web Access site before any remote applications can be accessed through the RD Gateway. In other words, any attempt to access remote applications through the RD Gateway, without any prior authentication in the RD Web Access site, will fail. Below follow detailed instructions regarding the required setup to protect your RD Web Access site, hosted on a Windows Server 2008 (R2), by performing SMS PASSCODE authentication on the Web Server, i.e. the IIS hosting the RD Web Access site. 1. Set up the Web Server if this has not been done yet. I.e. install IIS 7.0/7.5, RD Web Access site and RD Gateway site on the Web Server. Do NOT install SMS PASSCODE IIS Web Site Protection on the Web Server yet. 2. Test and verify that remote access (from the external network) to the MS Remote Desktop Server(s) through the RD Web Access site works as expected (using only AD credentials for authentication). If you are planning to use single sign-on (SSO): a. Test and verify that SSO works as expected. b. It is strongly recommended, when using SSO, to update the Render Scripts on the RD Web Access site. To do this, on the server hosting the RD Web Access site go to and click the Fix it button on this page. This will update the Render Scripts. 3. You are now ready to add SMS PASSCODE protection as described in the steps below.

64 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 64 OF Perform the following actions on each RD session host server: In the Server Manager rightclick the RemoteApp Manager and select RD Gateway Settings. a. Select the Custom RDP Settings tab.

65 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 65 OF 407 b. Enter the following two lines into the Custom RDP settings textbox: pre-authentication server address:s: require pre-authentication:i:1 where fqdn must be replaced with the fully qualified domain name of the SSL certificate used for publishing the RD Web Access site, and rdroot must be replaced with the RD Web Access URL ( TS and RDWeb by default on Windows Server 2008 and Windows Server 2008 R2, respectively). 5. Now, install SMS PASSCODE IIS Web Site Protection on the Web Server. During the installation, enable SMS PASSCODE protection of the RD Web Access site: 6. Test that SMS PASSCODE authentication works as expected. This completes the procedure for protecting the RD Web Access site using SMS PASSCODE multi-factor authentication.

66 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 66 OF Protection of RD Web Desktops using IIS Web Site Protection If you have protected the RD Web Access Site using SMS PASSCODE IIS Web Site Protection as described in the previous section, and you are making use of the RD Web Remote Desktop feature (accessing full desktops of internal machines through the RD Gateway) then please note, that you have to complete some additional steps to make access to the Remote Desktops work with SMS PASSCODE multi-factor authentication. Please follow the procedure below, performing the specified actions on the server hosting the RD Web Access Site: 1. Make a backup of the following file: C:\Windows\Web\RDWeb\en-US\desktops.aspx 2. Now edit the original desktops.aspx file, and search for the text authentication level. Replace the line RDPstr += "authentication level:i:2\n"; with the following two lines RDPstr += "require pre-authentication:i:1\n"; RDPstr += "pre-authentication server address: s: fqdn must be replaced with the fully qualified domain name of the SSL certificate used for publishing the RD Web Access site, and rdroot must be replaced with the RD Web Access URL ( TS and RDWeb by default on Windows Server 2008 and Windows Server 2008 R2, respectively). 3. Save the changes to the desktops.aspx file. 4. Test that Remote Desktops can be accessed through the SMS PASSCODE protected RD Web Access Site.

67 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 67 OF Protection of TS/RD Session Hosts using Windows Logon Protection On Windows Server 2003, Windows Server 2008 (R2) and Windows Server 2012 (R2), the RD Services infrastructure can be protected using SMS PASSCODE multi-factor authentication by installing the SMS PASSCODE Windows Logon Protection component on each TS/RD Session host (i.e. every server publishing remote applications and remote desktops). Protecting the RD Services infrastructure in this way has several advantages compared to protecting the TS/RD Web Access site: Multi-factor authentication is provided for the RD Session hosts, independent of the way the hosts are accessed. I.e. remote access will work independent of the type of browser used (e.g. Internet Explorer, Chrome, Safari), and independent of the type of remote access client used. Examples: o Clients using RD web feeds are supported o 3 rd party RDP clients running on ipads are supported o Direct access using RDP shortcuts are supported

68 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 68 OF 407 The following diagram illustrates the required infrastructure setup for performing SMS PASSCODE authentication on each RD Session host: Internal Network External Network Web Server MS Internet Information Server (IIS) RD Web Access (optional) + RD Gateway RADIUS Server MS NPS Firewall (E.g. Cisco, CheckPoint, ISA/TMG) RD Session Host Servers SMS PASSCODE Windows Logon Protection SMS PASSCODE protected RDS infrastructure with multi-factor authentication performed on the RD Session Host servers Please note: The SMS PASSCODE RADIUS protection component can NOT be installed on the RADIUS server. The Web Server and RADIUS server could be consolidated to a single server (installing both NPS and IIS on the same server).

69 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 69 OF 407 The SMS PASSCODE Windows Logon Protection component must be installed on each RD Session host Server. You may install any other SMS PASSCODE components on these servers as well (but this is not best practice). SMS PASSCODE multi-factor authentication will even work, if RD Session hosts are published for direct external access, bypassing the RD Gateway. However, for security reasons, this is not recommended. Below follow detailed instructions regarding the required setup to protect your RDS infrastructure using the SMS PASSCODE Windows Logon Protection component: 1. Set up the RDS infrastructure without installing any SMS PASSCODE components yet. 2. Test and verify that remote access (from the external network) to the RDS Server(s) works as expected (using only AD credentials for authentication). Ensure to test all relevant scenarios (relevant browser types, client types, internal/external access). 3. Ensure that external access is only allowed to the RD Session Hosts that you are planning to protect using SMS PASSCODE. This is configured in the Network Resources tab in the Resource Authorization Policy (please consult support@smspasscode.com, if you are in doubt about this). IMPORTANT: Any RD Session host without the SMS PASSCODE Windows Logon Protection component installed is accessible without multi-factor authentication. In other words, if any such server is externally accessible, then external access is provided without multi-factor authentication. 4. Now install the SMS PASSCODE Windows Logon Protection component on each RD Session host server. a. Applies only to Windows 2008 (R2) and Windows Server 2012 (R2): By default, the Remote Desktop Logon Timeout is set to 30 seconds. In case you expect SMS PASSCODE authentications to last longer in special cases (e.g. because of advanced load balancing policies with failover on expired OTPs), then it is recommended to extend the Remote Desktop Logon Timeout accordingly. This can be done in the SMS PASSCODE Configuration Tool on the Windows Logon Protection tab, either when the Configuration Tool pops up during installation of SMS PASSCODE Windows Logon Protection, or alternatively afterwards by starting the Configuration Tool manually. Please note, that you must restart the RD Session host before a new value of the Remote Desktop Logon Timeout setting takes effect.

70 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 70 OF If you would like to disable SMS PASSCODE multi-factor authentication for clients accessing the RD Session Hosts from the internal network (LAN), you have several options for this: a. Only require multi-factor authentication for requests originating from the RD Gateway. This can be configured using Authentication Policies by setting up a filter on the IP address of the RD Gateway. Please refer to section 15.8, page 177, for more details regarding Authentication Policies. b. Create an additional RDP Listener on the relevant RD Session host and configure the RD Gateway to use one of the RDP Listeners, and internal access to use the other RDP Listener. Configure SMS PASSCODE to only apply multi-factor authentication for the RDP Listener used by the RD Gateway. Please read section , page 385, for more details how to set up and configure RDP Listener exclusion Protecting VMware View 4.x SMS PASSCODE supports protection of VMware View 4.x virtual clients. To achieve this, please proceed as follows: Install SMS PASSCODE Windows Logon Protection on all virtual clients. Single sign-on works with Windows XP, Windows Vista and Windows 7 virtual clients. Configure VMware View users to access the virtual clients using RDP when SMS PASSCODE authentication is required, and using PCoIP when SMS PASSCODE authentication is not required (SMS PASSCODE authentication does not work using PCoIP). A recommended setup is to use RDP for remote access and PCoIP for access on the internal LAN. You can run the SMS PASSCODE Configuration Tool with command line arguments to distribute any necessary SMS PASSCODE settings to all VMware View clients (please read section 20.3, page 395, for more details).

71 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 71 OF Protection of SharePoint Portal Server SMS PASSCODE can efficiently protect SharePoint Portal Server (version 2003 and newer) and other application web sites. The general requirement for successful SMS PASSCODE protection is that the web application must only request a user authentication on the initial user log on, or alternatively, a security gateway that ensures this behavior must be used. SharePoint Portal server is an example of a web application that might request user authentication multiple times during a session, e.g. when a user is editing a Word document. Therefore, to make SMS PASSCODE protection of a SharePoint Portal server work properly it is mandatory to publish it through a security gateway that will prevent the additional user authentications during a session. Examples of scenarios for successful SMS PASSCODE protection of a SharePoint Portal server: Publish the SharePoint Portal server through a Microsoft Intelligent Application Gateway (IAG), a Microsoft Unified Access Gateway (UAG), a Citrix Access Gateway Enterprise Edition or a Juniper SA. Configure the gateway to use RADIUS authentication from a RADIUS server with SMS PASSCODE RADIUS Protection installed. The advantage of this setup is that the listed security gateways have built-in features for cleaning up the client machines, e.g. removing any documents downloaded from the SharePoint Portal. Publish the SharePoint Portal server through a Microsoft ISA/TMG server using a Web Listener with persistent cookies and enable SMS PASSCODE authentication on the Web Listener by installing SMS PASSCODE ISA/TMG Web Site Protection on the ISA/TMG server. The disadvantage of this setup is that the ISA/TMG server will not perform any clean up on the client machines. I.e. any downloaded documents might remain on the client machine afterwards. Recommendation Prior to installing SMS PASSCODE protection, please always test and verify that the published SharePoint Portal site works as required, i.e. that authentication occurs only once during the initial logon. The following section shows an example on how to publish a SharePoint Portal server using a Microsoft IAG.

72 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 72 OF Example: Protecting a SharePoint Portal server using IAG This section describes the necessary actions to apply SMS PASSCODE protection to a SharePoint Portal server published through a MS IAG. 1. Prepare an SMS PASSCODE RADIUS server by installing the SMS PASSCODE RADIUS protection component on a Windows server with IAS/NPS installed. 2. Add an Authentication Server in the IAG that uses the SMS PASSCODE RADIUS server for authentication: o In the Advanced Trunk Configuration dialog, click Add to create a new authentication server:

73 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 73 OF 407 o Select Type = RADIUS and configure the RADIUS settings to use the SMS PASSCODE RADIUS server. Remember to select the Support Challenge Response checkbox:

74 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 74 OF Configure each application within IAG that must be protected by SMS PASSCODE authentication, to use the credentials provided by the SMS PASSCODE authentication server. This is done by selecting the SMS PASSCODE authentication server on the Web Settings tab while editing the application: Please contact support@smspasscode.com if you need further information regarding SharePoint Portal server protection.

75 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 75 OF UPGRADE You can upgrade the following versions of SMS PASSCODE directly to version 7.2: SMS PASSCODE 5.0 SMS PASSCODE 6.0 SMS PASSCODE 6.0 SP1 SMS PASSCODE 6.1 SMS PASSCODE 6.2 SMS PASSCODE 6.2 SP1 SMS PASSCODE 7.0 To perform the upgrade you just have to run the SMS PASSCODE 7.2 installation like a Firsttime installation (cf. section 13). Do not uninstall any previous version of SMS PASSCODE before installing version 7.2. The installation package will automatically upgrade the previous version and convert the database to the new file format. You must upgrade SMS PASSCODE on all servers containing any SMS PASSCODE core components. SMS PASSCODE authentication clients only need to be upgraded if they are version 6.2 SP1 or older (i.e. SMS PASSCODE 7.0 authentication clients can communicate with SMS PASSCODE 7.2 core components). IMPORTANT: A new license key is required for SMS PASSCODE 7.2 if you are upgrading from a version prior to 7.0. If you have a valid Software Assurance agreement, you should already have received an by now, explaining how to proceed to get the new license key. If not, please request a new license key from support@smspasscode.com.

76 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 76 OF FIRST-TIME INSTALLATION To install SMS PASSCODE you have to complete 3 steps: 1. Install hardware, i.e. GSM modem(s) (section 13.1, page 76). 2. Install software (section 13.2, page 76). 3. Configure SMS PASSCODE (section 14, page 100). These 3 steps are described in the specified sections Installation of Hardware Before installing the SMS PASSCODE software, please connect all GSM modems. You should connect each modem to a server on which a Transmitter Service is going to be installed. In a typical scenario, you will distribute the modems evenly, i.e. connect the same number of modems to each server running a Transmitter Service. Please follow the instructions below when connecting each GSM modem: WARNING: Please follow the instructions below in strict order to avoid damage of the hardware. Please note, that the power cord is not connected until step Release the SIM card sledge of the GSM modem by sticking a peaked object into the small hole beside the sledge. 2. Insert a SIM card into the sledge. 3. Carefully push the sledge back into the GSM modem again. DO NOT USE FORCE. 4. Screw the antenna (included) onto the GSM modem. 5. Connect the GSM modem to a serial port using the serial cable (included). 6. Connect the GSM modem to the power supply (included). 7. Put the plug of the power supply in the socket. 8. Check that a green LED is flashing on the modem. You are now ready to install the SMS PASSCODE software Installation of the SMS PASSCODE Software When all GSM modems have been connected following the instructions above then you are ready to install the SMS PASSCODE software. The procedure for installation is described below. IMPORTANT You must have administrator rights to install any SMS PASSCODE components. IMPORTANT Close all other applications while installing SMS PASSCODE. It is especially important to close the Citrix Access Management Console while installing the SMS PASSCODE Citrix Web Interface Protection component.

77 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 77 OF 407 As explained in section 6 (page 26), SMS PASSCODE is composed of several software components. You can install each component by itself or together with other SMS PASSCODE components on a machine. You have complete control of how to distribute the components on several machines. However, a valid installation must fulfill the following requirements: A single Database Service must be installed on a server. At least one Web Administration interface must be installed preferably on the same server as the Database Service. At least one Transmitter Service must be installed on a server. At least one GSM modem must be connected to a Transmitter Service (or link an alternative dispatcher, like an dispatcher or web service dispatcher, to at least one Transmitter Service). It is optional to install the Load Balancing Service (cf. section 10.5, page 51). The procedure for an SMS PASSCODE installation is to run the installation package on each involved machine and select the components to be installed on this machine. The recommended order of actions is: 1. First install the Database Service component on a server (the database server). If other SMS PASSCODE components are planned to be installed on the same server, then also include these components during this installation. It is recommended to include the Web Administration interface component. 2. Configure SMS PASSCODE using the Web Administration Interface (cf. section 15). You should already at this time create all planned load balancing servers, transmitter servers and GSM modems in the database. 3. Now install the Transmitter Service component on all those servers where this component is planned for installation. If other SMS PASSCODE components are planned to be installed on some of these servers, then also include these components during installation. Please note: In case you have already installed the Transmitter Service component on a server during step 1, do not run the installation again on this server. 4. If you plan to use the Load Balancing Service, you should now install the Load Balancing Service component on all those servers where this component is planned for installation. If other SMS PASSCODE components are planned to be installed on some of these servers, then also include these components during installation. Please note: In case you have already installed the Load Balancing Service on some servers during step 1 or 3, do not run the installation again on these servers. 5. Finally install SMS PASSCODE Authentication clients on the machines where these are planned for installation. Please note: In case you have already installed some of these components during step 1, 3 or 4, do not run the installation again on these machines.

78 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 78 OF 407 The actions for installation on a machine are listed below. Please repeat these actions on each machine being part of the SMS PASSCODE installation. IMPORTANT: The sequence of dialogs is automatically tailored during an installation according to the components selected for installation. The work flow below describes all potential dialogs that may appear during an installation. You may not see all dialogs during your specific installation skip forward in the work flow in case a dialog is not shown. 1. Log on to the machine using a user account with local administrator rights. 2. Copy SmsPasscode-700-x86.exe (32-bit) or SmsPasscode-700-x64.exe (64-bit) to a local path on the machine. 3. Start the installation by double-clicking the setup file: (32-bit) or (64-bit) 4. If the Microsoft.NET 3.5 SP1 Framework is not installed yet, then it will be downloaded and installed automatically before the main SMS PASSCODE installation begins A Welcome dialog appears. Click the Next button. (During an upgrade from an earlier version of SMS PASSCODE a notice that an upgrade is about to occur will appear in this window) 16 Except on Windows Server 2008 R2 or Windows Server 2012, where it will not be installed automatically, because.net 3.5 is not allowed to be installed here. It must be added as a Feature in the Server Manager.

79 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 79 OF An End-User License Agreement (EULA) appears. Please read the agreement carefully. If you accept the EULA: a. Click on I accept the terms in the license agreement. b. Click the Next button.

80 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 80 OF A dialog for component selection appears. This is where you decide which components are to be installed on the current machine. a. Make your component selections. Please note: The selections you make are not permanent. You can always run the installation again afterwards and change your selections (cf. section 21). If you are planning to install SMS PASSCODE Authentication clients only, on the current machine, then please deselect all other components, i.e. your selection should look like this: b. Click the Next button.

81 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 81 OF If a dialog for entering license information appears: a. Enter the license code from the license . Use copy & paste. b. Click the Next button.

82 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 82 OF If a dialog for selecting the installation folder appears: a. It is recommended to use the proposed default installation folder. In case you want to change the path anyhow: Click the Change button and select a new path. b. Click the Next button.

83 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 83 OF If a dialog for specifying the default prefix appears. a. Specify the default prefix for phone numbers. All phone numbers without an explicit prefix will have this prefix automatically added. b. Click the Next button.

84 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 84 OF If a dialog for setting up the Web Administration Interface appears: a. It is recommended to use the proposed default path for the Web Administration Interface installation folder. If you want to change the path anyhow: Click the Change button and select a new path. b. It is recommended to use the proposed default TCP port for the Web Administration Interface site. If you want to change the TCP port anyhow, e.g. because of a port conflict with another application or another web site, then enter a different TCP port. c. Click the Next button.

85 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 85 OF If a dialog for setting up the Self Service Web Site appears: a. It is recommended to use the proposed default path for the Self Service Web Site installation folder. If you want to change the path anyhow: Click the Change button and select a new path. b. It is recommended to use the proposed default TCP port for the Self Service Web Site. If you want to change the TCP port anyhow, e.g. because of a port conflict with another application or another web site, then enter a different TCP port. c. Click the Next button.

86 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 86 OF If a dialog for setting up the Password Reset Web Site appears: a. It is recommended to use the proposed default path for the Password Reset Web Site installation folder. If you want to change the path anyhow: Click the Change button and select a new path. b. It is recommended to use the proposed default TCP port for the Password Reset Web Site. If you want to change the TCP port anyhow, e.g. because of a port conflict with another application or another web site, then enter a different TCP port. c. Click the Next button. 14. A dialog for selecting Authentication Clients appears. a. Select the optional components that you would like to install on this machine. Please read section 6 (page 26) for more details on each component. Just leave all checkboxes cleared if none of the components are to be installed on the current machine. You may also click the question mark buttons in the dialog window to get more information. Please note: The selection of Authentication Clients is NOT permanent. In case you

87 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 87 OF 407 would like to add or remove Authentication Clients you can always run the installation again afterwards (cf. section 21) PLEASE NOTE: If a component is disabled for selection, this is caused by system requirements not being fulfilled for this component (cf. section 7, page 30) b. Click the Next button.

88 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 88 OF If a dialog for selecting the Citrix Web Interface to protect using SMS PASSCODE appears: a. Please select the physical path for the Citrix Web Interface 17 to be protected by SMS PASSCODE authentication. b. Click the Next button. 17 Currently the installation program only supports activation of SMS PASSCODE protection only for a single Citrix Web Interface. If you need to protect several Citrix Web Interfaces on the same server, then this is also possible. Please contact support@smspasscode.com for instructions on how to do this.

89 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 89 OF If a dialog for selecting the scenario you would like to use for the protection of the Citrix Web Interface with SMS PASSCODE appears: a. Select one of the following three scenarios: i. Disabled: Select this option to disable SMS PASSCODE authentication for now and enable it manually afterwards (as described in section 19.1). ii. Standalone or Side-by-Side logon: Select this option (recommended) to activate standard SMS PASSCODE authentication. If no other kind of multifactor authentication system is activated, then all users must now authenticate using SMS PASSCODE to log on to the Citrix Web Interface this is called Standalone logon. If another kind of multi-factor authentication system is activated (e.g. RSA SecurID or SafeWord ), then the users can either authenticate using SMS PASSCODE or the other authentication system this is called Side-by-Side logon. iii. Dual logon: Select this option if you need extra high security. If no other kind of multi-factor authentication system is activated, then this option is identical with option (ii). I.e. all users are authenticated using SMS PASSCODE to log on to the Citrix Web Interface this is called Standalone logon. But if another multi-factor authentication system is activated (e.g. RSA SecurID or SafeWord ), then all users must now authenticate both using SMS PASSCODE and the other authentication system to log on this is called Dual logon. b. Click the Next button.

90 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 90 OF If a dialog for configuring SMS PASSCODE protection of an OWA site appears: a. Check this option if the OWA site on the server should be protected using SMS PASSCODE authentication. b. Check this option to allow ActiveSync clients to synchronize using the OWA site on this server. In this case, SMS PASSCODE authentication will be disabled for ActiveSync requests. Please maintain security by protecting the ActiveSync clients by other means, e.g. using the SMS PASSCODE Secure Device Provisioning component. c. Check this option to allow ActiveSync clients to send AutoDiscover requests to the OWA site. In this case, SMS PASSCODE authentication will be disabled for AutoDiscover requests. d. Check this option to allow RPC over HTTP/HTTPS connections using the OWA site on this server. In this case, SMS PASSCODE authentication will be disabled for RPC over HTTP/HTTPS requests. Please maintain security by protecting these clients by other means. e. Click the Next button.

91 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 91 OF If a dialog for configuring SMS PASSCODE protection of an RD Web Access site appears (only supported on Windows Server 2008 (R2), cf. section 8.2, page 39): a. Check this option if the RD Web Access site on the server should be protected using SMS PASSCODE authentication. b. Click the Next button. 19. You are now ready to perform the installation according to the choices you have made. Click the Install button.

92 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 92 OF A dialog appears showing the progress of the installation...

93 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 93 OF At some stage during the installation the SMS PASSCODE Configuration Tool is automatically started (except during an upgrade, because in this case the settings from the previous installation are preserved): This tool is used, among others, for configuring the SMS PASSCODE infrastructure, i.e. you use this tool to specify where the different SMS PASSCODE components are located and how they should communicate with each other. You may not see all the tabs shown in the picture above because the user interface of the SMS PASSCODE Configuration Tool is automatically adapted according to the components installed on the current machine.

94 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 94 OF 407 You must now configure the SMS PASSCODE infrastructure and save the settings before the SMS PASSCODE installation is complete. Please follow the instructions below. a. In case you have installed the Load Balancing Service, Transmitter Service, Web Administration Interface or Self Service Web Site on the current machine, and the Database Service component is not installed on the current machine, you must specify where the database server is located. To do this, please specify the host name of the database server in the field Database host on the Database tab: b. If you have installed the optional Password Reset Backend Service or an optional SMS PASSCODE Authentication Client on the current machine, you must specify where a transmitter server is located. You can either specify a list of one or more Transmitter services or a list one or more Load Balancing services. This is configured on the Transmission tab. To specify a list of Transmitter servers: Select Transmitter service (a) and enter the host name of the servers running the Transmitter Service. Specify the host name of each server (b) and add it to the list by clicking the Add button (c):

95 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 95 OF 407 In case you have installed one or more Load Balancing services: Select Load balancing service (a) and enter the host name of the servers running the Load Balancing Service. Specify the host name of each server (b) and add it to the list by clicking the Add button (c): The authentication client will always try to locate a Transmitter/Load Balancing server in the specified order, i.e. the order of the servers in the list is of importance. In case of communication problems with the higher prioritized servers the authentication client will automatically communicate with lower prioritized servers (failover). c. If you have installed the SMS PASSCODE Password Reset Web Site on the current machine, then you must specify where a Password Reset Backend Service is located. To do this, please specify the host name of the PRBS server in the field Password Reset Backend Service host on the Password Reset tab: d. The Network tab lists the TCP ports used for communication between the SMS PASSCODE components (cf. section 10.1, page 44). If some TCP port fields are disabled and cannot be changed, this is because they are not in use by the current machine. It is recommended to use the default TCP ports proposed. But in case of

96 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 96 OF 407 TCP port conflicts with other applications you may change some TCP ports on this tab. Important: The TCP ports must match each other on all machines having SMS PASSCODE components installed. If you plan to change one or more TCP ports, please change these TCP ports in the same manner on all machines. If this is not observed, then communication will fail. Finally you must enter a Shared Secret on the Network tab. This is a secret password that is used for encrypting all messages exchanged between the SMS PASSCODE components. To ensure that security is not compromised, a password with a minimum length of 15 characters is required. It is recommended to use letters, digits and special characters in the password: Important: Always remember to specify a Shared Secret. Please enter the same Shared Secret on all machines having SMS PASSCODE components installed. If this is not observed, then communication will fail.

97 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 97 OF 407 e. Click the Save button. In case a warning message appears regarding error prone entries: Please correct all errors and click the Save button again. f. Click the Close button. The installation will now continue.

98 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 98 OF 407 Please note: If you have entered incorrect data in the SMS PASSCODE Configuration Tool by accident or if you wish to change some settings later on (because of infrastructure changes), then you can always run the SMS PASSCODE Configuration Tool again manually. A shortcut to this tool is created in the Windows Start menu: Windows Server 2003/2008 Windows Server 2012

99 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 99 OF The dialog below appears when the installation has completed. Click the Finish button. 23. The installation of SMS PASSCODE is now complete on the current machine. You should now perform any necessary configurations of this machine (cf. section 14). This is especially important if you have just installed the Database Service and Web Administration Interface on the current machine. In this case, you should now start the Web Administration Interface and a) authorize all servers planned to run the Transmitter Service, b) authorize all servers planned to run the Load Balancing Service, and c) create all connected GSM modems in the database. 24. If more machines are part of this installation: Please go back to step 1 (page 78) and follow the same instructions for the next machine.

100 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 100 OF POST-INSTALLATION ACTIONS After having completed the SMS PASSCODE installation you should perform some configurations, before SMS PASSCODE is ready for use: 1) Use the Web Administration Interface for the following tasks: a. Configuring general SMS PASSCODE settings b. Configuring SMS PASSCODE policies c. Maintaining SMS PASSCODE user settings d. Maintaining the SMS PASSCODE dispatching and authentication infrastructure Please read section 15 for a detailed description of the SMS PASSCODE Web Administration Interface. NOTE: Remember to enable required General Settings It is recommended to review the options on all tabs of the General Settings page in the Web Administration Interface carefully after installation. Initially, the product is installed with all advanced options disabled. You might miss out important features that could be valuable to you (AD Integration, Authentication Monitoring, Geo-IP, Globalization, MFA bypassing, and more). General settings are described in section 15.3 (page 112). 2) Configuration of SMS PASSCODE Authentication Clients: a. Configuration of the Citrix Web Interface Protection component. Please read section 19.1 (page 342). b. Configuration of the RADIUS Protection component. Please read section 19.2 (page 343). c. Configuration of the Cloud Application Protection component. Please read section 19.3 (page 364). d. Configuration of the ISA/TMG Web Site Protection component. Please read section 19.4 (page 367). e. Configuration of the IIS Web Site Protection component. Please read section 19.5 (page 373). f. Configuration of the Windows Logon Protection component. Please read section 19.6 (page 382). g. Configuration of the Secure Device Provisioning component. Please read section 18 (page 314), in particular subsection ) Optionally configure the SMS PASSCODE Self Service Web Site to use form-based authentication. Please read section 16.5 (page 279).

101 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 101 OF 407 4) Complete setup of the SMS PASSCODE Password Reset Web Site. Additional steps are required after installation of the PRWS component before it is ready for use. Please read section 17.6 (page 301). 5) Complete setup of the SMS PASSCODE Password Reset Backend Service. Additional steps are required after installation of the PRBS component before it is ready for use. Please read section 17.7 (page 303). Additionally, the SMS PASSCODE Configuration Tool allows you to perform various tasks, like re-configuring the SMS PASSCODE infrastructure and changing settings for some authentication clients. Please read section 20 (page 388) for more details regarding the configuration tool. Finally, for enhanced security you might decide to enable location and behavior aware authentication. Please note, that this is an advanced topic, and the related features are disabled by default. If you are new to SMS PASSCODE, then it is recommended to get the SMS PASSCODE system up and running first, without location and behavior aware authentication enabled. Then afterwards, study the features related to location and behavior aware authentication and consider, whether and how to make use of them. The following subsection introduces the concept of location and behavior aware authentication and gives you an overview regarding the possibilities Overview: Location and Behavior Aware Authentication SMS PASSCODE contains patent-pending technology that optionally lets you enable advanced features for even stronger security. The common term for these features is location and behavior aware authentication. This section explains the purpose of these new features. Please note that these advanced features are disabled by default, thereby ensuring that the SMS PASSCODE system works out-of-the-box without the necessity to get familiar with the advanced settings, before you decide to. Location and behavior aware authentication actually refers to two different, but related features that can enhance security during authentication attempts: Location aware authentication: Refers to the fact that the SMS PASSCODE system can determine facts about the location that a user is attempting to perform a login from. These facts are determined from the end-user s IP address. Currently the SMS PASSCODE system is able to determine the country of the IP address and the name of the organization owning the IP address. Behavior aware authentication: Refers to the fact that the SMS PASSCODE system can remember the history of earlier used end-user IP addresses and thereby identify whether new log on attempts comply with earlier behavior or not. The pre-requisites for using location and behavior aware authentication are: The SMS PASSCODE authentication client used must support location and behavior aware authentication. Please check the requirements in section 8.1 (page 37). Collection of end-user IP addresses must have been enabled for the authentication client(s) in question. This is configured using the SMS PASSCODE Configuration Tool (cf. section 20.2, page 392). The setting Geo IP and IP history must have been enabled on the General Settings page of the SMS PASSCODE Web Administration interface (cf. section 15.3, page 112)

102 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 102 OF 407 When these pre-requisites are fulfilled, a lot of new features and possibilities for customization become available. In that case, you should understand the following concepts and terms: User IP History The SMS PASSCODE system will start recording an individual history of IP addresses used during authentication attempts by each user. The User IP History feature is described in more detail in (page 232). IP Trust Level Each end-user IP address listed in a user s User IP History is assigned a Trust Level. This level is zero initially, but can be configured to increase on each successful multi-factor authentication completed from the IP address. By default, the Trust Level increases by 1 on each successful multi-factor authentication, but this is customizable using the Authentication Policy assigned to the user. If you do not wish to make use of behavior aware authentication, then you should configure the Authentication Policy NOT to increase the Trust Level. Trusted IP address An IP address is treated as a Trusted IP when its Trust Level has reached a specific value, called the Trust Level Threshold. This threshold is defined by the Authentication Policy assigned to the user. An IP address is treated as Non-Trusted, until it becomes Trusted. Passcode Policy Using Passcode Policies you may define the exact content to be shown in the passcode messages sent to users during SMS PASSCODE multi-factor authentication. E.g. you may define whether location specific information should be shown in the messages (country and/or organization). This is the location aware part. Additionally, Passcode Policies let you define distinct message content for authentication requests originating from Trusted or Non- Trusted end-user IP addresses, respectively. This is the behavior aware part. All in all this makes more contextual information available for users during authentication, thereby giving them the chance to get alerted in case of any irregularities. Passcode Policies are described in more detail in section 15.7 (page 168). Learning mode Learning mode is an optional feature that lets you define an initial temporary period where specific message content is shown in the passcode messages sent to a user. This allows you to override the message content for an initial period, until the system has become aware of Trusted and Non-Trusted IP addresses of the user. Learning Mode is configured on the Authentication Policy assigned to the user. Authentication Policy As stated above, Authentication Policies allow you to define Trust Level Threshold, increase of IP address Trust Level during authentications, and Learning Mode activation. Additionally, Authentication Policies allow you to customize the authentication behavior itself using Authentication Rules, thereby making authentications location and behavior aware. An example could be to deny authentications from specific locations. Authentication Policies are described in more detail in section 15.8 (page 177).

103 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 103 OF WEB ADMINISTRATION INTERFACE Using the SMS PASSCODE Web Administration Interface (WAI) you can: Configure SMS PASSCODE settings o General settings o License information Configure SMS PASSCODE policies o User Integration Policies o User Group Policies o Authentication Policies o Passcode Policies o Load Balancing Policies o Token Policies Maintain SMS PASSCODE user settings Maintain SMS PASSCODE transmission settings o Maintain transmitter servers o Maintain load balancing servers o Maintain passcode dispatchers (GSM modems, dispatchers, web service dispatchers) o Maintain GSM modem groups Monitor current and past authentication attempts Monitor current status of all GSM modems In the following subsections WAI is used as a shorthand for Web Administration Interface, and WAI server designates the server on which WAI is installed. By default, only members of the Administrators group have permissions to access the WAI. Nonadministrators can be granted permission to access the WAI by adding them to the Windows user group SMS PASSCODE Administrators Starting the Web Administration Interface You can start WAI in three different ways: 1. You can start WAI using a shortcut created on the desktop of the WAI server:

104 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 104 OF You can start WAI using a shortcut created in the Windows Start Menu of the WAI server: Windows Server 2003/2008 Windows Server 2012

105 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 105 OF WAI is also available from any computer on the network using a web browser as long as this computer can connect to the WAI server on TCP port Connect to WAI using the URL where ip-address should be replaced with the IP address of the WAI server. By default, only administrators of the WAI server have access to the WAI using a web browser. The following user interface is shown on the first startup of WAI: The left part of the user interface is a navigation menu. Please notice, that this navigation menu is dynamically adapted according to the different data and settings in the WAI. The complete list of possible menu items is: Users Maintain users Maintain SMS PASSCODE users, i.e. create, edit and delete users. Please read section 15.7 (page 168) for details. Import users Import SMS PASSCODE users from a comma-separated file. Please read section (page 236) for details. Policies User Integration Policies Maintain policies for automatic synchronization of SMS PASSCODE users from one or more Active Directory data sources. This menu item is only available, when AD Integration has been enabled. Please read section 15.5 (page 127) for details. User Group Policies Maintain user settings on a user group basis. Please read section 15.6 (page 145) for details. Authentication Policies Maintain policies and rules affecting authentication behavior. Please read section 15.8 (page 177) for details. 18 Port 2000 is the default TCP port for the Web Administration Interface. The port may be changed during installation.

106 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 106 OF 407 Passcode Policies Maintain passcode specific settings, like passcode length, composition and lifetime; and maintain passcode message templates using the MessageDesigner. Please read section 15.7 (page 168) for details. Load Balancing Policies Maintain policies and rules for authentication load distribution and dispatching failover. This menu item is only available when at least one Load Balancing Host has been authorized. Please read section (page 251) for details. Token Policies Maintain policies describing the types of tokens allowed in your organization. This menu item is only available when Token authentication has been allowed in the general settings. Please read section 15.9 (page 205) for details. Transmission GSM Modems Maintain GSM modem settings. Please read section (page 243) for details. Modem Groups Maintain modem groups, which are used by Load Balancing Policies. Please read section (page 249) for details. This menu item is only available when at least one Load Balancing Host has been authorized. Load Balancing Hosts Maintain Load Balancing servers, e.g. authorize additional Load Balancing servers. Please read section (page 241) for details. Transmitter Hosts Maintain Transmitter servers, e.g. authorize additional Transmitter servers. Please read section (page 238) for details. Dispatchers Maintain settings for dispatching. Please read section (page 245) for details. Web Service Dispatchers Maintain settings for Web Service Dispatchers. Web Service Dispatching is used for Voicecall dial out and/or Web Service SMS dispatching. This menu item is only available when Voice Call or Web Service SMS dispatching has been allowed in the general settings. Please read section (page 246) for details.

107 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 107 OF 407 Monitoring Authentications Inspect current and past authentication attempts on any SMS PASSCODE protected authentication clients. Both live monitoring of current authentication attempts, as well as reporting and exporting of past authentication attempts is supported. This menu item is only available when Authentication monitoring has been enabled in the general settings. Please read section (page 264) for details. GSM Modems Inspect the current live status of all GSM modems. Please read section (page 274) for details. Settings General Maintain general settings, e.g. enable AD Integration. Please read section 15.3 (page 112) for details. License Maintain license information, e.g. when additional licenses have been acquired. Please read section 15.4 (page 123) for details. After installation of SMS PASSCODE the recommended order of actions is: 1. Configure the general settings. 2. AD Integration enabled in step 1? a. Yes: Configure User Integration Policies. b. No: Create users manually (or import from comma-separated file). 3. Configure User Group Policies 4. Configure your transmission infrastructure. a. Optionally authorize additional Transmitter servers, if failover is required. b. Optionally authorize Load Balancing servers, if failover and load balancing is required. c. Create required dispatching entities, e.g. create GSM modems, dispatchers and/or Web Service dispatchers, according to your message dispatching requirements d. Optionally create modem groups and/or Load Balancing Policies, if advanced load balancing and failover is required. When the SMS PASSCODE system is up and running, you may additionally decide to enable and configure location and behavior aware authentication for even stronger security. Please read section 14.1 (page 101) to get a short overview about this topic.

108 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 108 OF Overview of Policy Types SMS PASSCODE includes several types of Policies: User Integration Policies User Group Policies Authentication Policies Passcode Policies Load Balancing Policies Token Policies This section gives an overview regarding these policies and explains their intended usage and relationship to each other. A User Integration Policy (UIP) is used to define a periodic synchronization of users from a user group in an Active Directory into the SMS PASSCODE database. Each UIP keeps important user attributes up-to-date in the SMS PASSCODE database according to any changes in the underlying source Active Directory, like (mobile) phone number(s), address and full name. By creating several UIPs, you can synchronize users from several user groups, possibly from different Active Directories. Each user in the SMS PASSCODE database has a lot of individual settings and permissions that can be customized by administrators. However, to make it easier for administrators to manage these settings across large amounts of users, User Group Policies were introduced to make it possible to maintain common settings for groups of users. The methodology is simple: Each user is assigned a specific User Group Policy (UGP) and inherits all the settings defined by this policy. Most of the settings can additionally be overridden on individual users, if any deviations from the inherited settings are required. Any overridden setting can afterwards be reset again, to fall back to the inherited value. Among the settings of a UGP are the following sub-policies: Authentication Policy: Defines authentication behavior, e.g. whether and how a user is allowed to authenticate from specific locations. Passcode Policy: Defines settings regarding the random one-time-passcodes generated for a user, and also defines the content of passcode messages (using message templates). Load Balancing Policy: Defines prioritized rules for determining the dispatchers to use to transmit passcode messages to a user. Token Policy: Defines the types of tokens being used within your organization (in case token authentication has been allowed)

109 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 109 OF Static Relationship between Policy Types Each user belongs to exactly one policy of each policy type. The static relationship between the different types of policies defines how the different policies are assigned to a user. The static relationship between the different policies is as follows: Each User Integration Policy defines the User Group Policy to assign to the users being imported Each user is assigned a single, specific User Group Policy. Either automatically by a User Integration Policy, or manually. Each User Group Policy refers to a particular Authentication Policy, Passcode Policy, Load Balancing Policy and Token Policy. These 4 policies are inherited by all the users that the User Group Policy is assigned to. However, each of the policies can be overridden individually on any user.

110 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 110 OF 407 The static relationship of the policies is illustrated by the diagram below: AD User Integration Policy Override User User User User Override Inherit User Group Policy Authentication Policy Passcode Policy Load Balancing Policy Token Policy Each of the policies is explained in more detail in subsequent sections: User Integration Policies: Section 15.5 (page 127) User Group Policies: Section 15.6 (page 145) Passcode Policies: Section 15.7 (page 168) Authentication Policies: Section 15.8 (page 177) Load Balancing Policies: Section (page 251) Token Policies: Section 15.9 (page 205)

111 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 111 OF Runtime Relationship between Policy Types The runtime relationship between policy types defines how policies are actually used during a user s authentication attempt. User Integration Policies are not part of the runtime relationship, since they are not directly having any influence on an authentication attempt. Instead, User Integration Policies are, as part of the static relationship, defining which other policies belong to a user, and thereby indirectly influencing the authentication behavior (as described in the previous section). The authentication behavior for a specific user is determined in the following way: 1. First the Authentication Policy assigned to the user is determined. The Authentication Policy determines, whether the user is allowed to log in at all. If the user is allowed to log in, the outcome might either be to use or bypass multi-factor authentication. In case the user is denied access, or access is allowed with multi-factor authentication bypassed, the remaining policy types are ignored. Otherwise, multi-factor authentication is performed according to the remaining policy types as described below. 2. The Passcode Policy assigned to the user determines among others the format of the OTP to be sent to the user, and the content of the OTP message. Normally, the Passcode Policy is assigned statically to the user, i.e. either inherited from the user s User Group Policy, or overridden on the user itself. However, the Passcode Policy might also be determined dynamically at runtime by the authentication policy during step 1, allowing for contextual message dispatching (advanced feature). Please read section (page 187) for more details about this. 3. Finally the user s User Group Policy or Load Balancing Policy determines how OTP messages are actually transmitted to the user (which type of message to send, which dispatcher to use, which target to send to). In case a Load Balancing Policy is used to determine the dispatching logic, the Load Balancing Policy is normally assigned statically to the user, i.e. either inherited from the user s User Group Policy, or overridden on the user itself. However, the Load Balancing Policy might also be determined dynamically at runtime by the authentication policy during step 1, allowing for contextual message dispatching (advanced feature). Please read section (page 187) for more details about this.

112 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 112 OF General Settings The General settings page allows configuration of important system-wide settings: Changes do not take effect until you click the Save button. As shown in the screen shot above, the settings are divided into 3 tabs: Misc. settings This tab contains miscellaneous important system-wide settings. Please read section below for a detailed description of these settings. Authentication Monitoring This tab contains settings concerning authentication monitoring, e.g. whether to enable authentication monitoring at all. Please read section below for a detailed description of the Authentication Monitoring settings. Globalization options This tab contains system wide settings that indicate whether non-standard dispatching and/or authentication types are activated and allowed to be used. You should only enable any of these settings, in case standard SMS authentication is not sufficient. The nonstandard dispatching and authentication types make it possible to handle the diversities and challenges met in a global setup. Please read below for a detailed description of the different Globalization options. The subsections below describe the settings of all 3 tabs in more detail.

113 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 113 OF Miscellaneous Settings This section describes the settings available on the Misc. settings tab on the General settings page of the WAI. The settings are described in detail in the table below. Setting Default prefix for phone numbers Enable AD Integration Explanation This prefix is automatically added to the beginning of each user s phone number if no explicit international prefix is specified. You can always explicitly specify another prefix for individual users. This setting controls whether the AD Integration feature is enabled. You can enable the AD Integration in two different modes: Single sync mode: Users are imported from a single user group. Multi sync mode: Users are imported from several user groups, possibly from separate domains. Please read section (page 128) for more details regarding the difference of the AD Integration modes. Geo IP and IP history This setting controls whether location and behavior aware authentication should be enabled for strengthened security. When enabled, end-user IP address usage is recorded in the SMS PASSCODE database and Geo IP data is looked up for IP addresses to determine geo-location information. You should only enable this setting, if at least one of your authentication clients fulfills the requirements for collecting end-user IP addresses correctly (cf. section 8.1, page 37). IMPORTANT: Allow outgoing network HTTP/HTTPS traffic Please note that when Geo IP lookups are enabled, you must allow outgoing HTTP/HTTPS traffic from the SMS PASSCODE Database Service, Transmitter Service and Load Balancing Service. This is required, since these services will contact a 3 rd party Geo IP database during Geo IP data lookups, and additionally they will periodically contact an SMS PASSCODE web service to check for any required updates ensuring correct Geo IP lookups.

114 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 114 OF 407 Setting Multi-factor authentication bypassing Explanation This is a system wide setting that controls whether any users should be allowed to bypass SMS PASSCODE multi-factor authentication under specific circumstances. Allowing this must be done with great care, since it lowers the security level. When allowed, bypassing scenarios are defined using Authentication Rules (cf. section , page 187). Proof-of-Concept (PoC) Mode: When allowing multi-factor authentication bypassing, an additional checkbox appears on the General settings page allowing you to enable PoC mode. In this mode, users without any SMS PASSCODE license are allowed to log in using standard authentication, i.e. without using SMS PASSCODE multi-factor authentication. This provides the possibility to test the SMS PASSCODE product with only a few SMS PASSCODE licenses, without affecting the login behavior for the remaining users. NOTE: Even when PoC mode is enabled, any user must still be imported into the SMS PASSCODE database in order to be allowed to log in to any SMS PASSCODE protected authentication client. WARNING: For security reasons, please only enable PoC Mode during a product evaluation / Proof-of-Concept period. WARNING (Secure Device Provisioning): When using the SMS PASSCODE Secure Device Provisioning component, please take extra care when enabling PoC mode, since it might potentially lower security compared to your actual Exchange Server setup. Please read the details below. Only relevant when using SMS PASSCODE Secure Device Provisioning: When PoC mode is enabled, it affects authentication behavior as stated in section 7.1 (page 31). Specifically, MFA-bypassing occurs in this case for users without any MFA Standard license allocated. In relation to the SMS PASSCODE Secure Device Provisioning component, MFA-bypassing means auto-approving new ActiveSync devices. In other words, when PoC mode is enabled, all users without any MFA Standard CAL will get their ActiveSync devices auto-approved. This might be what you intend, if you did not make use of the quarantine functionality of Exchange Server previously. Conversely, if you were already making use of quarantine s beforehand, then autoapproving devices will lower security. In this case it is NOT recommended to enable PoC mode, but instead only import the required test users into the SMS PASSCODE database. All users not imported into the SMS PASSCODE database will be denied access to the SMS PASSCODE Secure Device Provisioning Web Site, meaning that the standard quarantine s from Exchange Server are forwarded, and auto-approval is prevented. Secondary phone numbers When this setting is enabled, you can optionally allocate a secondary phone number to each user. Secondary numbers can be used during configuration of Load Balancing Policies for failover scenarios.

115 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 115 OF Authentication Monitoring This section describes the settings available on the Authentication Monitoring tab on the General settings page of the WAI. These settings all relate to the SMS PASSCODE Authentication Monitoring feature. Please note, that authentication monitoring is disabled by default, i.e. you must enable it explicitly on this page, in case you would like to make use of it. When enabled, administrators can get access to the Authentication Monitoring page, which allows monitoring, reporting and exporting authentication attempts across all users and SMS PASSCODE protected authentication clients. Please read section (page 264) for more details regarding the Authentication Monitoring page.

116 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 116 OF 407 The settings are described in detail in the table below. Setting Authentication monitoring Explanation This setting controls, whether the SMS PASSCODE system should record every authentication attempt in the SMS PASSCODE database, across all users and SMS PASSCODE protected authentication clients, for reporting and monitoring afterwards. The setting is disabled by default, i.e. authentication attempts are not recorded in the SMS PASSCODE database by default. Enable the setting, in case you would like to make use of the advanced authentication monitoring features on the Authentication Monitoring page of the WAI (cf. section 15.19, page 264). NOTE: The remaining settings described in this table will only become visible in the WAI, when the Authentication monitoring setting is enabled. Archive destination When authentication monitoring is enabled, every authentication attempt is recorded and stored in the SMS PASSCODE database. Eventually, this will grow the SMS PASSCODE database unnecessary big and could reduce system responsiveness. To avoid this, SMS PASSCODE includes an auto-archiving feature that will automatically archive and remove the oldest authentication attempts from the SMS PASSCODE database. Please note, that archived authentication attempts remain available for reporting and export on the Authentication Monitoring page. The Archive destination setting allows you to specify, how archived data should be stored. The following options are available: CSV Archived data is stored as CSV files in a specific folder in the file system XML Archived data is stored as XML files in a specific folder in the file system SQL Archived data is inserted into a specific table in a specific database of an SQL Server. The SQL server must have been installed beforehand. Currently, Microsoft SQL Server 2005, 2008 and 2012 are supported for SQL archiving. Please read the notes following this table for additional information regarding the Archive destination setting.

117 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 117 OF 407 Setting Archiving threshold Explanation Specifies the number of authentication attempt records to keep in the internal SMS PASSCODE database. When the number of records in the database exceeds the specified threshold, then the auto-archiving feature will start to remove and archive the oldest authentication attempts, in order to keep the number of entries below the threshold. The default threshold is records. NOTE: The auto-archiving feature has a built-in rule, that it will never archive authentication attempts that have occurred within the recent week. I.e. even if the threshold setting is low compared to the number of logins per day in your organization, you are guaranteed to always have the recent week of authentication attempts readily available in the internal SMS PASSCODE database for monitoring and reporting. Statistics The Statistics table is for informative use only. It displays for both the internal SMS PASSCODE database and the archive: Number of entries Date and time of the oldest record Date and time of the newest record IMPORTANT: The SMS PASSCODE system supports one authentication archive at a time. I.e. if you change the type or destination of archive at any time, then all the data of the previous archive will not be available for retrieval on the Authentication Monitoring page anymore. Notes regarding Archive destination, type = CSV or XML Using CSV files or XML files for archiving is the easiest option. You only need to select a specific folder in the file system, which the SMS PASSCODE database has write access to, and you are done. If the folder does not exist, the SMS PASSCODE database will automatically create the folder, if allowed to. By default, the subfolder Database\Archive of the SMS PASSCODE installation folder is used for archiving. CSV or XML files are supported by many 3 rd party analysis systems, like e.g. Microsoft Excel, which allow you to perform further analysis of the archived authentication attempts. Please note, that if you wish to consolidate several of the files in the archive into one file, or wish to select only a subset of the attributes in the files, you can easily select and filter the archived data on the Authentication Monitoring page and export the filtered data into new consolidated CSV or XML files. Please remember to back up the files in the archive destination folder if you want to be able to recover them in case of data loss. Notes regarding Archive destination, type = SQL Archiving authentication attempts to an SQL Server is more complex than the CSV/XML files option, but might be advantageous to you, in case you already have an SQL Server running in your organization, and/or because you have special data analysis systems available for analyzing data in the SQL Server.

118 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 118 OF 407 The screen shot below shows the settings that must be specified, when SQL archiving is selected: Setting Explanation (a) SQL Server Name or IP address of the SQL Server to use for archiving. The SQL Server must have been installed beforehand. Currently, MS SQL Server 2005, 2008 and 2012 are supported. (b) Database name Name of the destination database within the selected SQL Server. The database must have been created beforehand. You can either create a new dedicated database, or use an existing database that the SMS PASSCODE system should add a new table to. You must also assign an SQL User Account or Windows User Account to the database. This account must have permissions to create a new table, as well as read/write access to this new table.

119 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 119 OF 407 Setting Explanation (c) Table name Name of a table within the selected SQL database, where authentication attempts should be stored. It is recommended to enter a name of a nonexisting table this will cause the SMS PASSCODE database service to create the table automatically, with the required data structure. (d) Authentication Type Specify, whether the SMS PASSCODE database service should make use of a dedicated SQL User Account or Windows User Account to access the SQL database. (e) Credentials Specify the credentials of the user account that the SMS PASSCODE database service should use for accessing the SQL database. Enter the credentials of either an SQL User Account or Windows User Account, depending on the selection of the previous setting (d). (f) Additional Connection String Parameters This option is only for advanced use. It allows you to specify additional parameters that should be appended to the connection string used for accessing the SQL Server. (g) Test Connection Click this button to test, whether all the previous settings have been entered correctly, and to verify, that the SMS PASSCODE database service is able and allowed to connect to the specified SQL database. Please remember to back up the SQL table used for archiving if you want to be able to recover in case of data loss Globalization Options To support the challenges met because of global diversities, e.g. differences in messaging infrastructures, SMS PASSCODE supports several ways to authenticate users.

120 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 120 OF 407 The following authentication types are supported: Authentication Type SMS OTP Explanation This is the recommended, well-recognized, default authentication type provided by SMS PASSCODE. Whenever an authentication is requested, a new random onetime-passcode (OTP) is generated for this specific authentication session. The passcode is sent directly to the user by SMS using the GSM network. This authentication type is always enabled. OTP Voice call OTP This authentication type is similar to SMS OTP, except the OTP is sent by using SMTP. The security rating of this authentication type strongly depends on the fact, how well-protected the user s access is. In the worst case, if the user can access the from anywhere using simple standard authentication, this authentication type is hardly better than ordinary non-multi-factor authentication. However, if the access to the passcode s is well-protected, e.g. if the is only accessible by a BlackBerry terminal or another mobile device, this authentication type provides high security. It is very useful in some Asian countries where the mobile messaging infrastructure is based. Actions should be taken to minimize the risk of unwanted forwarding by intruders. This authentication type is similar to SMS OTP, except the user will receive a voice call and the passcode will be read up by speech. This authentication type is very secure and useful in countries/areas without any GSM coverage, since landline phones can be called. However, the security is a level below SMS, as it is usually possible to forward a voice call to a different device. Actions should be taken to minimize the risk of unwanted voice call forwarding by intruders. Please note that this authentication type uses a 3 rd -party web service that you need to sign up for (cf. section , page 122). Communication with the web service is performed using HTTPS (SSL encrypted network traffic). Web Service SMS OTP This authentication type is very similar to SMS OTP, except a 3 rd -party web service is used for the SMS dispatching. This is the recommended authentication type in the United States. Please note that this authentication type uses a 3 rd -party web service that you need to sign up for (cf. section , page 122). Communication with the web service is performed using HTTPS (SSL encrypted network traffic).

121 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 121 OF 407 Authentication Type Token Explanation This authentication type is very different than the previously mentioned authentication types. All previous authentication types will not generate a random OTP, until a request has been made ( challenge based ), and will generate an OTP for the specific authentication ( session specific OTP ). Contrary to this, a token has a unique, but pre-determined sequence of OTPs. Token authentication is useful for users that cannot authenticate by any of the stronger authentication types mentioned above for any reason. SMS PASSCODE supports several types of tokens: All OATH compliant tokens Including both hardware and software tokens Including event-based tokens (HOTP) Including time-based tokens (TOTP) YubiKeys (proprietary USB Keys from a 3 rd -party provider called Yubico). This provider also hosts a web service that you need to sign up for (cf. section , page 122). Communication with the web service is performed using HTTPS (SSL encrypted network traffic). NOTE regarding RADIUS authentication using MS-CHAP v2: OATH token authentication works with MS-CHAP v2 as well USB Key authentication is not guaranteed to function properly with RADIUS clients using MS-CHAP v2. This depends on the specific RADIUS client implementation / manufacturer. The RADIUS client is required to return the passcode in clear text as a response to the challenge request. For more information regarding token authentication, please read section 15.9 (page 205). Temporary personal passcode (encrypted) Personal passcodes are meant to be used in case of emergency (ICE). They provide a last resort to allow users to authenticate using a temporary assigned personal passcode, if everything else should fail. The code can be set by the administrator, or by the user through the SMS PASSCODE Self Service Web Site. The personal passcode is stored encrypted and is not visible to the administrator or anyone else. Note: Personal passcodes are also used by the SMS PASSCODE Password Reset module. Therefore, you must enable personal passcodes if you are planning to make use of the Password Reset module (read section 17, page 286, for more details about the Password Reset module).

122 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 122 OF 407 The supported authentication types are compared in the table below: Authentication type Challenge based and session specific OTP End-to-end out-of-band dispatching Security Rating User-friendliness SMS OTP Yes Yes Support for flash SMS Support for memopasscodes Alternative dispatch types to augment the secure SMS OTP dispatching (the alternatives all provide a security level below the level of SMS OTP) Web Service SMS OTP Yes No OTP (secure/closed network) 19 Yes No Support for memopasscodes Voice call OTP Yes No 20 - Token OTP No - OTP entered automatically when using YubiKeys OTP (non-secure) 21 Yes No Support for memopasscodes Temporary personal passcode No Signing Up for 3rd-party Web Services SMS PASSCODE has partnered up with some selected 3 rd -party web service providers regarding some of the authentication mechanisms. Voice call OTP and Web Service SMS OTP If you intend to dispatch OTPs using voice calls and/or Web Service SMS, then you must sign up for an account at the service provider hosting a 3 rd -party web service for this. Please contact SMS PASSCODE support (support@smspasscode.com) to receive the document Dispatching passcodes using a web service. This document describes the steps necessary to sign up for an account. Token OTP (YubiKey) If you intend to make use of YubiKey authentication, then you must acquire USB Keys and sign up for an account at our selected 3 rd -party USB Key provider (Yubico). These USB Keys have a userfriendly feature that allows entering the complete OTP by a single push of a button on the USB Key. 19 When access is well-protected, e.g. only accessible by a personal device 20 A 3 rd -party web service is called using HTTPS, i.e. using SSL encrypted network traffic. 21 When access is not well-protected, e.g. accessible from anywhere using ordinary authentication with a user name and password

123 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 123 OF 407 Please contact SMS PASSCODE support (support@smspasscode.com) to receive the document USB Key Authentication. This document describes the steps necessary to acquire USB Keys and sign up for an account Maintaining License Information The WAI also has a page for inspecting and maintaining license information. Use the License page to inspect the current, overall license allocation status, e.g. to check whether you are running low on licenses. The In use column in the License statistics section indicates the current amount of licenses that have been allocated. In case you have run out of any licenses, this will be shown in the Missing column. You will typically only perform any changes on this page in the following cases: 1. When you have received a new license key, because you have acquired more CALs or modem licenses. Section below describes how to enter a new license key. 2. In case you wish to enable License limits (advanced feature). This is described in section below.

124 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 124 OF Applying a License Key To apply a (new) license key, please follow the instructions below: 1. Select the License page. 2. Edit the license information: a. Enter the License key. It is recommended to copy&paste the license key from the license . b. Click the Save button. c. Check, if the new license key was accepted. d. The License statistics section displays how many CALs and modem licenses are made available by the license key.

125 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 125 OF License Limits License limits is an advanced feature that allows defining maximum number of CALs to be allocated to users per User Group Policy (UGP). It is typically used by hosting providers wishing to limit CAL allocations per customer, to ensure that no customer gets more CALs allocated than acquired. However, you might use it for any other reasons, e.g. limiting CAL allocations per branch office, in case you have any such requirement. Advanced feature It is recommended to enable License limits, only in case you have a specific requirement for limiting CAL allocations for specific groups of users (i.e. per UGP). To enable/disable License limits, please proceed as follows: Select the License page. a. Select or clear the Enabled checkbox to enable or disable License limits, respectively. b. Click Save. Please read section (page 165) for details about setting the actual license limits on a UGP.

126 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 126 OF License Management In some cases, you might need different kind of overviews regarding the actual license allocations across users and user groups. Besides the total license overview shown on the License page itself, you also have several other options: On the Maintain Users page you can inspect license information across all users. You can (a) enable columns with license related information to be shown, and (b) use row filtering to filter on license related information. E.g. you may enable a filter that shows only users with Password Reset CALs granted, but not allocated. When maintaining the settings of a specific user, you may go to the License tab to inspect the license status of this particular user (cf. section , page 231).

127 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 127 OF 407 On the User Group Policies page you can inspect license information across all User Group Policies. You can (a) enable columns with license related information to be shown, and (b) use row filtering to filter on license related information. E.g. you may enable a filter that shows only User Group Policies granting Password Reset CALs. When maintaining the settings of a specific User Group Policy, you may go to the License tab to inspect the license status of this particular User Group Policy (cf. section , page 165) User Integration Policies User Integration Policies are used to configure how users in the SMS PASSCODE database are synchronized with users from one or more Active Directory stores. This makes it possible to maintain SMS PASSCODE users in one or more Active Directories. No schema extension of any of your ADs is necessary to make use of this functionality. You simply select a group of own choice in (each) AD to contain SMS PASSCODE users and the SMS PASSCODE database service will automatically synchronize all users, being members of this/these group(s), to the SMS PASSCODE user database. User Integration Policies support several advanced features: Multi domain support: It is possible to import users from one or several separate AD domains. Group nesting: The chosen AD group may contain other groups in a nested hierarchy, thereby making administration of SMS PASSCODE users even easier. Child domains and trusted domains: When using nested groups, all groups and/or users in the group hierarchy are allowed to be located in child domains and/or trusted domains. Configurable protocol: Synchronization can occur using either the LDAP or the Global Catalog (GC) protocol. Optionally, SSL/TLS encryption can also be enabled in order to encrypt the network communication between the SMS PASSCODE database service and the AD domain

128 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 128 OF 407 controller. Configurable import of user properties: Configure which user properties to import from the AD. You can decide to import any of the following user properties from the AD: o (Primary) phone number o Secondary phone number o address o Token ID o Personal passcode Any property NOT imported from the AD, can be maintained manually in the SMS PASSCODE database by the administrator. All properties, imported from AD or not, can be maintained by the user himself, using the SMS PASSCODE Self Service Web Site, if allowed by the administrator. Configurable LDAP attributes: Each imported user property is retrieved from an LDAP attribute of the corresponding AD user. You configure, exactly which LDAP attribute to use for every user property in your specific organization. You might even configure a prioritized list of LDAP attributes to search through multiple attributes of the AD user. Configurable user group: It is configurable which AD group contains your SMS PASSCODE users. Data transformations: Optionally apply data transformations to all imported user names, phone numbers, and/or personal passcodes. Using nested group from child domains / trusted domains Please note that in order to make use of nested groups from Child Domains and/or Trusted Domains, an AD user account that has read-access to all involved domains (or Global Catalog servers) must exist. If the SMS PASSCODE Database Service is not started using this user account, the credentials of this user account must be specified as part of the User Integration Policy. Alternatively, instead of using nested groups from child/trusted domains, you could enable Multi sync mode and create several User Integration Policies with settings (credentials) for each child/trusted domain explicitly Single Versus Multi Sync Mode Active Directory integration can be enabled in two different modes: Single sync mode and Multi sync mode. In Single sync mode you are allowed to maintain a single User Integration Policy (UIP) that defines a single user group in a single AD, and all users being member of this group are synchronized to the SMS PASSCODE database. Please note, that the synchronization might nevertheless span several AD domains, because the selected group might contain nested groups, including nested groups from child domains and trusted domains. All users from nested groups are synchronized as well. In Multi sync mode you are allowed to create any number of UIPs, each with its own settings and triggering its own synchronization in parallel.

129 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 129 OF 407 The Single sync mode is recommended for companies or organizations having one AD domain (tree/forest). The Multi sync mode is especially useful for hosting providers that are hosting multiple separate domains for different customers Single Sync Mode This section describes how to configure AD Integration in single sync mode. Simple setup In the simplest case, if the SMS PASSCODE database service is running on a domain member server (or domain controller), and no child or trusted domains are involved, you will typically need to do only the following to enable Active Directory Integration: 1. Select the General settings page. 2. Enable Active Directory Integration in single sync mode: a. Select the Enabled (single sync mode) option. b. Click the Save button. After this, Active Directory Integration is ready for use simply create a group called SMS PASSCODE USERS in your AD and add users or nested groups to this group. Note: The simple setup will import users (mobile) phone numbers from the default LDAP attribute mobile, and addresses from the default LDAP attribute mail. Please read the Advanced setup section below, in case you want to import other user attributes as well, or in case you want to import phone numbers or addresses from different, non-default LDAP attributes.

130 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 130 OF 407 Advanced setup In more complex cases, where a) the SMS PASSCODE database service is NOT running on a domain member server (e.g. because it is located in a DMZ), or b) nested groups from child domains or trusted domains are involved, or c) you wish to change some of the more advanced settings, please follow the instructions below to modify the settings of the UIP according to your requirements: 1. Enable AD Integration in single sync mode according to the instructions above ( Simple setup ) 2. You are now ready to configure the UIP according to your requirements. Go to the User Integration Policies page: The page contains 5 tabs, each containing different UIP settings: General settings Described in section , page 131. Data source Described in section , page 132. Data mapping Described in section , page 134. Data filtering Described in section , page 140 Data transformations Described in section , page 140 The settings of each tab are described in the subsections below. IMPORTANT: Changes do not take effect until you click the Save button.

131 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 131 OF UIP: General Settings The General settings tab contains various basic settings of the UIP: The settings are described in the table below: Setting Explanation (a) Refresh interval Enter into this field how often the AD synchronization engine should check for changes in the AD. The default value is every 5 minutes. (b) Default prefix Specify the international phone number prefix to add in front of all imported phone numbers NOT having an explicit prefix specified already. Select Use system default to use the default prefix specified on the General Settings page. (c) User Group Policy Select the User Group Policy to be assigned to all imported users by default. The User Group Policy determines several important settings for the users please read section 15.6 (page 145) for more details regarding User Group Policies. (d) AD lockout check interval Enter into this field how often to check for AD lockouts. This setting is only relevant, in case you have enabled AD Account Lockout notifications for some of the users imported by this UIP. Otherwise, the setting is ignored. It is recommended to keep the default setting of 15 seconds, since this will guarantee a fast response, resulting in fast notifications after AD lockouts. Note: The SMS PASSCODE system has intelligent logic for checking for AD lockouts. Consequently, even if you set the UIP to check for AD lockouts often, you should not see any heavy load on your domain controllers. Please read section (page 151) for more details regarding AD Account Lockout notifications.

132 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 132 OF UIP: Data Source The Data source tab of the UIP contains settings used to define, where and how to find the users to synchronize into the SMS PASSCODE database: The settings are described in the table below: Setting Explanation (a) Protocol Select the protocol for synchronization. LDAP is normally recommended, but the Global Catalog protocol might provide performance advantages in environments with one or more child domains, because all information can be collected from the Global Catalog server instead of contacting each child domain controller sequentially. Optionally select the Encrypt communication using SSL checkbox in order to encrypt the network communication between the SMS PASSCODE database service and the AD domain controller using SSL/TLS. IMORTANT (Global Catalog) When using Global Catalog, please note that you must ensure that the LDAP attributes specified on the Data mapping tab of the UIP are actually replicated 22 to the Global Catalog. E.g. the default LDAP attribute for mobile phone numbers ( mobile ) is in fact NOT replicated to the Global Catalog by default. 22 For more information about how to add attributes to the Global Catalog, please read

133 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 133 OF 407 Setting Explanation (b) Server name If the SMS PASSCODE database service is running on a domain member server (or domain controller), then you can leave this field empty. The database service will then automatically locate a domain controller of the domain, to which it belongs. You may specify the host name or IP address of a domain controller anyhow, if you would like the AD synchronization to always communicate with a specific domain controller. On the other hand, if the SMS PASSCODE database service is NOT running on a domain member server (or domain controller), then you must specify either the DNS name of a domain, or the host name or IP address of a domain controller that should be used for AD synchronization. (c) AD Credentials By default, the SMS PASSCODE database service will connect to a domain controller using the permissions of the user account executing the database service. If this is sufficient, e.g. because the database service is running on a domain member server or a domain controller, then you can leave this field empty. AD credentials are normally only necessary if the SMS PASSCODE database service is NOT running on a domain member server (or domain controller), or if a specific user account is needed for read access to child domains and/or trusted domains. In this case, you should specify AD credentials (user name and password) for a user account having read access to all involved Active Directories. (d) Group Name Enter the name of the AD group containing all SMS PASSCODE users into this field. The default name is SMS PASSCODE Users. (e) (f) Group search base DN Test AD authentication When searching for the group entered in (d), SMS PASSCODE will by default search from the root of the root domain naming context. If you wish to restrict the search (e.g. to a child domain), please specify a base DN. This base DN will then be used as the root of the search. Example of a base DN: OU=DepartmentEast,DC=testdomain,DC=com Finally, you can perform an AD authentication test by clicking the Test AD authentication button. This will perform an authentication test and verify whether your Data source settings are correct. The test verifies: If a domain controller can be located. If it is possible to authenticate and read data from the AD of the located domain controller. If the specified AD group can be located. and 175f f1033.mspx

134 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 134 OF UIP: Data Mapping The Data mapping tab of the UIP contains settings used to define the user properties to collect for each imported user, and where to import the properties from (which LDAP attributes): NOTE: LDAP Attribute names A list of valid LDAP attribute names can be found here:

135 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 135 OF 407 The settings are described in the table below: (a) Setting (Primary) phone number Explanation This setting specifies whether to extract (primary) phone numbers from the AD and assign them to the users imported from the AD. Import from AD: If you want to extract users (primary) phone numbers from the AD, then select Import from attribute(s) in the drop-down list. In this case, (primary) phone numbers are maintained in the AD and administrators are not allowed to change the imported phone numbers in the WAI. Users may, if allowed to, change the phone numbers using the SMS PASSCODE Self Service Web Site, but any changes are then written directly back to the AD. When Import from attribute(s) is selected, the textbox to the right of the dropdown list changes its border to a green color. Enter into this textbox the LDAP attribute name of the AD user attribute that contains the (primary) phone number to be extracted for each user. You can even specify multiple attributes separated by commas. In this case the synchronization engine will perform a prioritized search for the phone number. E.g. if you enter mobile,othermobile, then the synchronization engine will first look for each user s phone number in the user attribute mobile. If this field does not contain any phone number, then the field othermobile is searched. Do not import from AD: If you want to maintain users (primary) phone numbers in the SMS PASSCODE database only, then select Do not import in the drop-down list. In this case, users are imported from the AD without extracting any (primary) phone numbers. Instead, administrators can maintain the phone numbers manually in the WAI, or alternatively allow users to maintain the phone numbers themselves using the SMS PASSCODE Self Service Web Site. In either case, phone numbers are not written back to the AD, but stay in the SMS PASSCODE database only (which might be desirable due to privacy, e.g. in case private phone numbers are used). Default settings: By default, (primary) phone numbers are imported from the AD, and extracted from the LDAP attribute mobile.

136 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 136 OF 407 (b) Setting Secondary phone number Explanation This setting specifies whether to extract secondary phone numbers from the AD and assign them to the users imported from the AD. Assigning secondary phone numbers to users might be useful, e.g. to provide mobile phone (GSM receiver) failover using Load Balancing Policies. Note: This setting is only available, if Secondary phone numbers have been enabled on the General Settings page (cf. section 15.3, page 112). Import from AD: If you want to extract secondary phone numbers from the AD and assign to users, then select Import from attribute(s) in the drop-down list. In this case, secondary phone numbers are maintained in the AD and administrators are not allowed to change the imported secondary phone numbers in the WAI. Users may, if allowed to, change the secondary phone numbers using the SMS PASSCODE Self Service Web Site, but any changes are then written directly back to the AD. When Import from attribute(s) is selected, the textbox to the right of the dropdown list changes its border to a green color. Enter into this textbox the LDAP attribute name of the AD user attribute that contains the secondary phone number to be extracted for each user. You can even specify multiple attributes separated by commas. In this case the synchronization engine will perform a prioritized search for the phone number. E.g. if you enter pager,othermobile, then the synchronization engine will first look for each user s secondary phone number in the user attribute pager. If this field does not contain any phone number, then the field othermobile is searched. Do not import from AD: If you want to maintain users secondary phone numbers in the SMS PASSCODE database only, then select Do not import in the drop-down list. In this case, users are imported from the AD without extracting any secondary phone numbers. Instead, administrators can maintain the secondary phone numbers manually in the WAI, or alternatively allow users to maintain the secondary phone numbers themselves using the SMS PASSCODE Self Service Web Site. In either case, secondary phone numbers are not written back to the AD, but stay in the SMS PASSCODE database only (which might be desirable due to privacy, e.g. in case private phone numbers are used). Default settings: Secondary phone numbers are not imported from AD by default. If you enable the import, you must select an available LDAP attribute of own choice.

137 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 137 OF 407 Setting Explanation (c) This setting specifies whether to extract addresses from the AD and assign them to the users imported from the AD. Import from AD: If you want to extract users addresses from the AD, then select Import from attribute(s) in the drop-down list. In this case, addresses are maintained in the AD and administrators are not allowed to change the addresses in the WAI. Users may, if allowed to 23, change the addresses using the SMS PASSCODE Self Service Web Site, but any changes are then written directly back to the AD. When Import from attribute(s) is selected, the textbox to the right of the dropdown list changes its border to a green color. Enter into this textbox the LDAP attribute name of the AD user attribute that contains the address to be extracted for each user. You can even specify multiple attributes separated by commas. In this case the synchronization engine will perform a prioritized search for the address. E.g. if you enter mail,othermailbox, then the synchronization engine will first look for each user s address in the user attribute mail. If this field does not contain any address, then the field othermailbox is searched. Note: Since addresses can be imported from any LDAP attributes, this allows for the usage of external addresses, e.g. for the purpose of using e- mail messages for failover. Do not import from AD: If you want to maintain users addresses in the SMS PASSCODE database only, then select Do not import in the drop-down list. In this case, users are imported from the AD without extracting any addresses. Instead, administrators can maintain the addresses manually in the WAI, or alternatively allow users to maintain the addresses themselves using the SMS PASSCODE Self Service Web Site. In either case, addresses are not written back to the AD, but stay in the SMS PASSCODE database only (which might be desirable due to privacy, e.g. in case private addresses are used). Default settings: By default, addresses are imported from the AD, and extracted from the LDAP attribute mail. 23 A built-in rule will deny users to change their address in the SMS PASSCODE Self Service Web Site, in case the default LDAP attribute mail is used, even if an administrator allows users to change their address in the Self Service Web Site. It is mandatory to use a non-default LDAP attribute for the e- mail addresses, or alternatively disable import of addresses, if users should be allowed to maintain their address by themselves.

138 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 138 OF 407 Setting Explanation (d) Token ID This setting specifies whether to extract token IDs from the AD and assign them to the users imported from the AD. Note: This setting is only available, if token authentication has been allowed on the General Settings page (cf. section , page 119). Import from AD: If you want to extract token IDs 24 from the AD and assign to users, then select Import from attribute(s) in the drop-down list. In this case, token IDs are maintained in the AD and administrators are not allowed to change the imported token IDs in the WAI. Users may, if allowed to, change the token IDs using the SMS PASSCODE Self Service Web Site, but any changes are then written directly back to the AD. When Import from attribute(s) is selected, the textbox to the right of the dropdown list changes its border to a green color. Enter into this textbox the LDAP attribute name of the AD user attribute that contains the token ID to be extracted for each user. You can even specify multiple attributes separated by commas. In this case the synchronization engine will perform a prioritized search for the token ID. E.g. if you enter pager,otherpager, then the synchronization engine will first look for each user s token ID in the user attribute pager. If this field does not contain any token ID, then the field otherpager is searched. Do not import from AD: If you want to maintain users token IDs in the SMS PASSCODE database only, then select Do not import in the drop-down list. In this case, users are imported from the AD without extracting any token IDs. Instead, administrators can maintain the token IDs manually in the WAI, or alternatively allow users to maintain the token IDs themselves using the SMS PASSCODE Self Service Web Site. In either case, token IDs are not written back to the AD, but stay in the SMS PASSCODE database only. Default settings: Token IDs are not imported from AD by default. If you enable the import, you must select an available LDAP attribute of own choice. 24 If a user is assigned to a Token Policy that uses token seed files, then the UIP will not import the token ID from AD, but instead import the public token S/N, and then determine the private token ID via the imported token seed mapping.

139 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 139 OF 407 (e) Setting Personal Passcode Explanation This setting specifies whether to extract personal passcodes from the AD and assign them to the users imported from the AD. Note: This setting is only available, if the usage of personal passcodes has been allowed on the General Settings page (cf. section , page 119). Import from AD: If you want to extract personal passcodes from the AD and assign them to users, then select Import from attribute(s) in the drop-down list. In this case, personal passcodes are maintained in the AD and administrators are not allowed to change the imported personal passcodes in the WAI. Users may, if allowed to, change their personal passcodes using the SMS PASSCODE Self Service Web Site, but any changes are then written directly back to the AD. When Import from attribute(s) is selected, the textbox to the right of the dropdown list changes its border to a green color. Enter into this textbox the LDAP attribute name of the AD user attribute that contains the personal passcode to be extracted for each user. You can even specify multiple attributes separated by commas. In this case the synchronization engine will perform a prioritized search for the personal passcode. Do not import from AD: If you want to maintain users personal passcodes in the SMS PASSCODE database only, then select Do not import in the drop-down list. In this case, users are imported from the AD without extracting any personal passcodes. Instead, administrators can maintain the personal passcodes manually in the WAI, or alternatively allow users to maintain their personal passcodes themselves using the SMS PASSCODE Self Service Web Site. In either case, personal passcodes are not written back to the AD, but stay in the SMS PASSCODE database only. Default settings: Personal passcodes are not imported from AD by default. If you enable the import, you must select an available LDAP attribute of own choice. It is possible to apply transformations to the imported personal passcodes, e.g. only retrieving the last 4 digits of an employee number. Transformations are described in section , page 140. Please note: Users not having any valid phone number in any of the specified LDAP attributes, or not having any valid address in any of the specified LDAP attributes, might be skipped during AD synchronization due to Data filtering settings. This is described in the next section.

140 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 140 OF UIP: Data Filtering The Data filtering tab of the UIP contains settings defining whether some users should be skipped during import: The settings are described in the table below: (a) (b) Setting Phone number required required Explanation Select this option if only users having a valid phone number should be imported from the AD store, or clear this option to allow import of users not having any phone number. Importing users without any phone number might make sense in the following cases: You are planning to let the users enter their phone numbers by themselves, using the SMS PASSCODE Self Service Web Site (cf. section 16, page 275) The users without any phone numbers are going to authenticate using an authentication type not requiring any phone number, e.g. by OTP. Select this option, if only users having a valid address should be imported from the AD store, or clear this option to allow import of users not having any e- mail address. Importing users without any address might make sense in the following cases: You are planning to let the users enter their addresses by themselves, using the SMS PASSCODE Self Service Web Site (cf. section 16, page 275) The users without any address are going to authenticate using an authentication type not requiring any address, e.g. by SMS. If you are planning to use the SMS PASSCODE Self Service Web Site, then please notice that only users with a valid address will be able to receive automatic welcome s (cf. section 16.2, page 276) UIP: Data Transformations When importing users from AD (or custom CSV-files), it might sometimes be useful to apply some kind of data transformations. E.g. all phone numbers in an AD might be prefixed with a zero ( 0 ) due to some technical reasons for calling the number from the office. In this case, it would be useful to apply a data transformation that would remove any leading zeroes from all phone numbers. This is actually possibly using the data transformation feature of SMS PASSCODE. Data transformations can be applied to SAM logins (i.e. user names in SAM account format), phone numbers and personal passcodes imported into the SMS PASSCODE database.

141 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 141 OF 407 Transformations are specified using regular expression syntax (please read or for a detailed description of regular expressions). Data transformations are configured as part of a UIP. When maintaining a UIP, the data transformation settings are displayed on the Data transformations tab: The procedure for applying a data transformation to SAM logins, phone numbers or personal passcodes is the same. In any case, you enter a search pattern and a replacement string. During the import of new data, the search pattern will be applied to the data being imported, and in case any search pattern matches, the matching pattern will be replaced according to the replacement string. Any SAM login, phone number or personal passcode not matching the search pattern will be imported unaltered.

142 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 142 OF 407 Below are some data transformation examples: Example 1: Changing the domain name for imported users from mydomain to yourdomain : o Search pattern: ^mydomain\\(.*)$ o Replacement string: yourdomain\$1 o Transformation example: mydomain\alex yourdomain\alex Example 2: Removing any leading zeroes from phone numbers: o Search pattern: ^(0*)(.*)$ o Replacement string: $2 o Transformation examples: Example 3: Removing parentheses and dashes from phone numbers in the format (xxxx) xxxx-xxxxx : o Search pattern: ^(\((\d*)\))?\s*(\d*)\s*-?\s*(\d*)$ o Replacement string: $2 $3 $4 o Transformation examples: (461) Example 4: Removing parentheses, dashes or dots from phone numbers in the format (xxx)xxx-xxxx, xxx.xxx.xxxx or xxx-xxx-xxxx : o Search pattern: ^(\(?(\d*)\)?)?(-? \.?)\s*(\d*)\s*(-? \.?)\s*(\d*)$ o Replacement string: $2 $4 $6 o Transformation examples: (123)

143 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 143 OF Multi Sync Mode This section describes how to configure AD Integration in multi sync mode. Basically, in multi sync mode, you can create any number of UIPs. Each UIP represents an AD synchronization with its own settings which can be configured exactly like the settings of the single UIP in single sync mode. The procedure is as follows: 1. Select the General settings page. 2. Enable Active Directory Integration in multi sync mode: a. Select the Enabled (multi sync mode) option. b. Click the Save button. 3. Now go to the User Integration Policies page. The page will show an overview grid (the UIP grid) containing all existing UIPs. You can edit and delete existing policies, or add any number of new policies. a. To add a new UIP, click the Add new User Integration Policy button. b. To edit a UIP, click the Edit button on the policy. c. To delete a UIP, click the Delete button on the policy. WARNING: Deleting a UIP will also remove all users imported through this UIP from the SMS PASSCODE database. In general, when creating or editing a UIP, the settings of the policy are similar to the settings explained previously in single sync mode (cf. section above). However, some additional settings become available in multi sync mode; these are explained below.

144 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 144 OF UIP: General Settings In multi sync mode, the General settings tab of a UIP contains 3 additional settings, which are not available in single sync mode: The additional multi sync mode settings are described in the table below: Setting Explanation (a) Description You can assign a description to each UIP. This description is shown in the UIP grid and is useful for identification when you have a lot of UIPs. It can also be used when searching for specific UIPs using the Set filter button (located above the UIP grid). (b) Enabled Using this option you can enable or disable a UIP. When you disable a UIP, the users of the UIP stay in the SMS PASSCODE database, but no synchronizations will be performed anymore, until the policy is enabled again.

145 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 145 OF 407 Setting Explanation (c) Priority This setting is only relevant, in case you have created multiple UIPs importing users from user groups within the same AD tree. In this case you might have the potential issue, that the same AD user is a member of several of the user groups. This raises the question, which UIP will eventually import the user, and which settings will consequently be applied to the user? To resolve this issue, the Priority setting can be used to prioritize the UIPs. You just need to enter a number into the field, indicating the priority of the UIP. A higher number means higher priority. If a user could be imported using several UIPs, the UIP with the highest priority (i.e. highest number) will import the user. In case you assign the same priority to several conflicting UIPs, then the importing UIP is chosen in an unpredictable way. You can ignore this setting, if you have not created multiple UIPs importing users from the same AD. The remaining settings on the General settings tab have the same purpose as in single sync mode (cf. section , page 131) User Group Policies User Group Policies make it easy for administrators to manage user settings. The idea is that every user is assigned to a User Group Policy (UGP) and automatically inherits the settings specified by this policy. I.e. if the administrator would like to change a specific setting for all users assigned to a specific UGP, the administrator only needs to change this setting once on the UGP in question, and all users assigned to this UGP will instantly inherit the new setting. For example the administrator could change type of passcode dispatching, SMS type (Flash/normal) or Self Service Site permissions. At the same time maximum flexibility is preserved, since each setting of a UGP can be overridden on each individual user. This means if an exception should be defined for a specific user, the administrator can just override one or more settings on this specific user no need to create a new UGP for this specific case. All in all, this means you can manage user settings on a group basis using UGPs, or on an individual user basis by overriding UGP settings on any user. UGPs can be assigned to users either manually, or automatically during AD synchronization. Each User Integration Policy (UIP) specifies the UGP to assign to the imported users (cf. section 15.5, page 127). If you wish to assign different UGP s to users imported from an AD, you should proceed as follows: Group your AD users in several AD user groups (one AD group per UGP) Enable AD Integration in Multi sync mode on the General settings page (cf. section 15.3, page 112) Create a UIP for each AD Group. Each UIP should be set up to import users from a specific AD Group and assign a specific UGP.

146 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 146 OF 407 UGPs are maintained on the User Group Policies page. The first time you enter this page, it will look like this: Initially, the SMS PASSCODE database will only contain a single UGP called Default User Group Policy. This policy cannot be deleted and will always be assigned to users that are not assigned to any other UGP. You can add any number of additional UGPs. To maintain UGPs, proceed as follows: a. To add a new UGP, click the Add new User Group Policy... button. b. To edit a UGP, click the Edit button on the policy. c. To delete a UGP, click the Delete button on the policy. NOTE: The built-in Default User Group Policy is a special policy, which is assigned to users by default. You can edit, but not delete this policy. WARNING: When deleting a UGP, all users assigned to this UGP will be re-assigned to the Default User Group Policy. The subsection below explains the different settings of a UGP in detail. Please note that the available settings of a UGP are adapted dynamically depending on other settings in SMS PASSCODE. This means, you might not see all the settings described in the next section.

147 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 147 OF Settings of a User Group Policy When creating a new UGP or maintaining an existing UGP, a tab control is shown for configuring the different settings of the UGP. The settings are divided into 5 categories: a. Basic Settings The main settings of the UGP, among others defining authentication behavior. b. Notifications Settings defining whether to send out different types of user notifications automatically. c. Self Service Web Site Settings Settings defining permissions and requirements regarding the SMS PASSCODE Self Service Web Site. These settings are only relevant, if you intend to make use of the SMS PASSCODE Self Service Web Site. d. Auto Settings defining the behavior for automatic s, when the SMS PASSCODE Self Service Web Site is being used. These settings are only relevant, if you intend to make use of the SMS PASSCODE Self Service Web Site. e. License License management settings, i.e. settings defining which CALs to grant to the users of the UGP. The different settings are described in detail in the following subsections. When making changes to a UGP please remember to click the Save button to store the changes permanently.

148 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 148 OF User Group Policy: Basic Settings This section describes the settings available on the Basic Settings tab while maintaining a UGP. Setting Explanation (a) Name The name used to identify the UGP. Giving the UGP a unique name is mandatory. (b) Description Optional description explaining the purpose of the UGP. (c) Passcode Policy The Passcode Policy to assign to the users assigned to this UGP. Please read section 15.7 (page 168) for more details regarding Passcode Policies.

149 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 149 OF 407 (d) Setting Authentication Policy Explanation The Authentication Policy to assign to the users assigned to this UGP. Please read section 15.8 (page 177) for more details regarding Authentication Policies. (e) Token Policy The Token Policy to assign to the users assigned to this UGP. Please read section 15.9 (page 205) for more details regarding Token Policies. Note: This setting is only available, if Token Authentication has been allowed on the General Settings page (cf. section 15.3, page 112). (f) Passcode type The type of passcode to use for authenticating the users assigned to this UGP. One-time passcodes are strongly recommended (cf. section , page 119). Note: This setting is only available, if personal passcodes have been allowed on the General Settings page (cf. section 15.3, page 112). Otherwise one-time-passcodes (OTPs) are always used. IMPORTANT: Personal passcodes are only recommended in case of emergency. Selecting this option reduces the security from multi-factor to one-factor authentication. (g) Dispatch type This setting specifies how one-time passcodes should be dispatched to the users assigned to this UGP. If you are planning to make use of Load Balancing Policies for best support of failover (between different dispatching mechanisms), then it is recommended to select the option Send passcodes as determined by this Load Balancing Policy. Note: You may not see all the Dispatch type options displayed in the screen shot above. Only the options allowed on the General Settings page will be available for selection (cf. section 15.3, page 112). (h) SMS type This setting specifies the type of SMS message to send to the users assigned to this UGP in case one-time passcodes are sent by SMS using a GSM modem (Dispatch type = Send passcodes by SMS). Flash SMS has the advantage that on most mobile phones it will pop up automatically, and will not be stored on the phone after usage. Flash SMS is recommended, unless it is not supported by your mobile phone or Telco 25. Note: This setting is ignored when one-time passcodes are sent using a Web Service SMS (Dispatch type = Send passcodes by web service SMS). In this case messages are always sent as Standard SMS. 25 You may disable flash SMS on individual users (user settings override), in case any specific users experience problems (cf. section , page 205)

150 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 150 OF 407 (i) Setting Token authentication Explanation This setting specifies whether users assigned to this UGP are allowed to authenticate using a token. Please note that you must additionally allocate a unique token to each user to allow the user to authenticate successfully using a token. This is done by entering the ID of the user s token on the user s settings page (cf. section , page 222), or by granting the user permission to self-enroll by way of entering the token ID in the SMS PASSCODE Self Service Web Site. Note: This setting is only available, if Token authentication has been allowed on the General Settings page (cf. section 15.3, page 112). When Personal Passcodes are enabled for a UGP (Passcode type = Personal passcode), some additional settings appear on the page: (j) Setting Personal passcode Explanation Enter the passcode that the users assigned to this UGP must enter to perform a successful authentication. IMPORTANT: Please note that the personal passcode can be overridden by individual users. If you plan to make use of personal passcodes, then it is recommended to let the relevant users create a user-specific personal passcode beforehand using the SMS PASSCODE Self Service Web Site (this can be allowed on the Self Service Web Site Settings tab, cf. section below). In this way, a user-specific personal passcode will already be in place, in case you decide to switch the Passcode type from OTP to Personal Passcode for the UGP. (k) Personal passcode duration This option specifies for how long the personal passcode is valid for usage. When the personal passcode becomes invalid, the UGP will automatically switch back to Passcode type = One-time passcode. Please note that most settings on the Basic Settings tab can be overridden by individual settings for each user (cf. section , page 227).

151 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 151 OF User Group Policy: Notifications This section describes the settings available on the Notifications tab while maintaining a UGP. The Notifications tab is used to enable or disable different types of automatic user notifications: Notification type SMS PASSCODE Lockout AD Account Lockout Before Password Expiration On Password Expiration Description A notification is send to the user whenever he is locked out in the SMS PASSCODE system. A notification is send to the user whenever he is locked out in the AD. A notification is send to the user whenever his AD password will expire soon. A notification is send to the user whenever his AD password has just expired. The SMS PASSCODE Lockout and AD Account Lockout notifications both have two purposes: Strengthen security: Since the user is notified immediately about the lockout, he can take immediate counteractions, in case the lockout was unexpected, e.g. due to a hacker attempting to compromise the user s login credentials. Improve password reset convenience: A lockout may occur, because a user has forgotten his password and triggered a lockout in the process of guessing the forgotten password. A convenient feature is that the lockout notification text can be configured to contain the URL of the SMS PASSCODE Password Reset Web Site. Consequently, the user is automatically reminded about the possibility to reset the password by himself, thereby being able to continue work without interruptions. The Before Password Expiration and On Password Expiration notifications both have the purpose of reminding the user about the need of renewing the existing AD password. Again, the notification text can be configured to contain the URL of the SMS PASSCODE Password Reset Web Site, thereby providing a very convenient way of resetting the password immediately. If the notification is received on a smartphone, the password reset process can be performed right away on the smartphone itself, just by clicking the URL (hyperlink). The transmission logic is the same for all four types of notifications: Notification messages will be sent either by SMS or according to each user s Dispatch type setting. In case this setting is set to use a Load Balancing Policy, then any rule of that policy using voice call dispatching will be skipped since voice calls cannot be used for forwarding notification messages.

152 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 152 OF 407 The screen shot below shows the settings on the Notifications tab: (a) Setting Password Reset Web Site URL Explanation This setting specifies the URL that the users must use to access the Password Reset Web Site. By default, this URL is shown in auto s and notifications sent to users. Please enter in front of the URL. If the Password Reset Web Site has been published for external access, then please enter the public URL. Note: This setting is only available, in case any Password Reset CALs have been acquired. (b) Notifications A sub tab displays the individual settings for each of the four types of notifications. The settings of each tab are described below.

153 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 153 OF 407 SMS PASSCODE Lockout The SMS PASSCODE Lockout tab contains settings regarding SMS PASSCODE Lockout notifications: (a) Setting Notification enabled Explanation Select this checkbox to enable SMS PASSCODE Lockout notifications (recommended). When enabled, all users of the UGP will receive a notification whenever they are locked out by the SMS PASSCODE system. SMS PASSCODE Lockout notifications are enabled by default.

154 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 154 OF 407 (b) (c) (d) Setting Message content Estimated length of message subject Explanation Specifies the message content of the notification. You can enter static text, but also macros (placeholders) that will be substituted with relevant content when sending the notification. A list of allowed macros is shown at the bottom of the web page. Password Reset tip: Any text put between the characters { and } is treated as conditional text, that is only included in the lockout notification message, in case the following conditions are all fulfilled: The user was locked out due to a password brute-force attempt (i.e. a wrong password was entered several times in a row). A Password Reset CAL has been allocated to the user Note: The macros { } and [PRS URL] are only available, in case any Password Reset CALs have been acquired. Shows the estimated length of the notification content after macro substitutions. If the estimated length is more than 160 characters, then please take the information regarding Notification message length shown at the end of this section into consideration. This setting is only relevant when the notification is sent by . In this case, the setting specifies the content of the subject. Macros are allowed here, too.

155 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 155 OF 407 AD Account Lockout The AD Account Lockout tab contains settings regarding AD Account Lockout notifications:

156 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 156 OF 407 (a) Setting Notification enabled Explanation Select this checkbox to enable AD Account Lockout notifications. When enabled, any user assigned to the UGP will receive a notification whenever his account becomes locked out in AD. IMPORTANT: Password Reset CAL required Please note that a user will only receive an AD Account Lockout notification if a Password Reset CAL has been allocated to the user. IMPORTANT: UIP required AD Account Lockout notifications only work for users imported into the SMS PASSCODE database through a User Integration Policy (UIP). The UIP has a setting specifying how often to check for AD lockouts (AD lockout check interval, cf. section , page 131). AD Account Lockout notifications are disabled by default. It is recommended to enable them if you are using the SMS PASSCODE Password Reset module. (b) Message content Specifies the message content of the notification. You can enter static text, but also macros (placeholders) that will be substituted with relevant content when sending the notification. A list of allowed macros is shown at the bottom of the web page. (c) Estimated length of message Shows the estimated length of the notification content after macro substitutions. If the estimated length is more than 160 characters, then please take the information regarding Notification message length shown at the end of this section into consideration. (d) subject This setting is only relevant when the notification is sent by . In this case, the setting specifies the content of the subject. Macros are allowed here, too.

157 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 157 OF 407 Before Password Expiration The Before Password Expiration tab contains settings regarding Password Pre-expiration notifications:

158 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 158 OF 407 (a) Setting Notification enabled Explanation Select this checkbox to enable Password Pre-expiration notifications. When enabled, any user assigned to the UGP will receive a notification whenever his AD password will expire soon. IMPORTANT: Password Reset CAL required Please note that a user will only receive a password pre-expiration notification if a Password Reset CAL has been allocated to the user. (b) Pre-notification period IMPORTANT: UIP required Password pre-expiration notifications only work for users imported into the SMS PASSCODE database through a User Integration Policy (UIP). The pre-expiration check is done as part of every AD sync. Password Pre-expiration notifications are disabled by default. It is recommended to enable them if you are using the SMS PASSCODE Password Reset module. Specifies how early a user will be notified, before the AD password expires. E.g. if you enter a value of 3 days, then any user of the UGP is notified, when his password will expire within the next 3 days. After this, the same user will not receive another password pre-expiration notification again, before a new password has been set and expires. (c) Message content Specifies the message content of the notification. You can enter static text, but also macros (placeholders) that will be substituted with relevant content when sending the notification. A list of allowed macros is shown at the bottom of the web page. (d) Estimated length of message Shows the estimated length of the notification content after macro substitutions. If the estimated length is more than 160 characters, then please take the information regarding Notification message length shown at the end of this section into consideration. (e) subject This setting is only relevant when the notification is sent by . In this case, the setting specifies the content of the subject. Macros are allowed here, too.

159 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 159 OF 407 On Password Expiration The On Password Expiration tab contains settings regarding Password Expiration notifications:

160 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 160 OF 407 (a) Setting Notification enabled Explanation Select this checkbox to enable Password Expiration notifications. When enabled, any user assigned to the UGP will receive a notification whenever his AD password has just expired. IMPORTANT: Password Reset CAL required Please note that a user will only receive a password expiration notification if a Password Reset CAL has been allocated to the user. IMPORTANT: UIP required Password expiration notifications only work for users imported into the SMS PASSCODE database through a User Integration Policy (UIP). The expiration check is done as part of every AD sync. Password Expiration notifications are disabled by default. It is recommended to enable them if you are using the SMS PASSCODE Password Reset module. (b) Message content Specifies the message content of the notification. You can enter static text, but also macros (placeholders) that will be substituted with relevant content when sending the notification. A list of allowed macros is shown at the bottom of the web page. (c) Estimated length of message Shows the estimated length of the notification content after macro substitutions. If the estimated length is more than 160 characters, then please take the information regarding Notification message length shown below into consideration. (d) subject This setting is only relevant when the notification is sent by . In this case, the setting specifies the content of the subject. Macros are allowed here, too. WARNING: Consequences of long SMS message content (> 160 characters) If notifications are going to be sent by , then the length of the message content is not important. On the other hand, if the notifications are going to be sent by SMS, then please note the following consequences of long message content: One thing to notice is that longer message content generally means longer message transmission time as well. But more importantly, if the resulting content of a notification message exceeds 160 characters, this will have the following consequences: If the SMS message is sent using a GSM modem, the message will be split into several messages 26 that are sent sequentially and merged by the receiving mobile phone into a single message again. This means o Longer transmission time (because of several messages) o Possibly higher transmission cost (because of several messages) If the SMS message is sent as a web service SMS, then only the first 160 characters are forwarded. The remaining message content is cut off. 26 Each message containing up to 155 characters, because 5 characters are lost per message part due to some extra header data.

161 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 161 OF User Group Policy: Self Service Web Site Settings This section describes the settings available on the Self Service Web Site Settings tab while maintaining a UGP. You only need to maintain settings on this tab if you intend to make use of the SMS PASSCODE Self Service Web Site (described in section 16). Otherwise, just keep the standard settings that will deny access to the Self Service Web Site. Setting Explanation (a) Permissions The permission table specifies the rights for the users assigned to this UGP regarding the SMS PASSCODE Self Service Web Site. The following permissions can be set: Access to Self Service Specifies whether the user is allowed to log in to the SMS PASSCODE Self Service Web Site at all. If this setting is set to Deny, then all other settings on this tab are ignored.

162 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 162 OF 407 Setting Explanation Change dispatch type Specifies whether the user is allowed to override and change the Dispatch type for sending one-time passcodes. Note: This option is only available if at least one alternative dispatching type has been allowed on the General settings page (cf. section , page 119). Change SMS type Specifies whether the user is allowed to override and change the SMS type (Flash or Standard SMS) used when sending one-time passcodes using a GSM Modem. Change (primary/secondary) phone number Specifies whether the user is allowed to change his phone number(s). Note: The permission to change secondary phone number is only shown if secondary phone numbers have been enabled on the General settings page (cf. section , page 113). Change Specifies whether the user is allowed to change his address. Note: If a specific user has been imported into the SMS PASSCODE database by a User Integration Policy, and the user s address was determined by the default attribute in AD (LDAP attribute mail ), then the user will NOT be allowed to change his address in the Self Service Web Site, regardless of the permission set by the Change option. Change Personal passcode Specifies whether the user is allowed to override and set/change a personal passcode that can be used in case the administrator sets authentication to use personal passcodes. Note: This option is only available if Personal Passcodes have been allowed on the General settings page (cf. section , page 119). Change PIN Specifies whether the user is allowed to override and set/change a personal PIN code that can be used during authentication. Change Token Policy Specifies whether the user is allowed to override and select a Token Policy of own choice. In this way the user might decide by himself which kind of token to use which might make sense in case of software tokens. E.g. the user might choose between two Token Policies called MS Authenticator and Google authenticator. Note: This option is only available if Token authentication has been allowed on the General settings page (cf. section , page 119).

163 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 163 OF 407 Setting Explanation Assign token Specifies whether the user is allowed to set/change the token assigned to him. This is recommended, in case you would like users to self-enroll their tokens. Note: This option is only available if Token authentication has been allowed on the General settings page (cf. section , page 119). Resync token Specifies whether the user is allowed to perform a complete resynchronization of his token in case it has come out of sync. When allowed to, a button for resynchronizing the token appears in the Self Service Web Site. As an administrator, you may always perform a resynchronization of user s token (cf. section , page 222). Note: This option is only available if Token authentication has been allowed on the General settings page (cf. section , page 119). (b) Required data Specifies the data that the user is required to enter in the SMS PASSCODE Self Service Web Site. The user will not be able to save any changes in the Self Service Web Site before all required data has been entered. Please note that any data is only really required, if the user has also been granted the permission to change the data in question. E.g. if Personal Passcode is set to required, but the Change Personal Passcode permission has been set to Deny, then the user cannot enter any Personal Passcode in the Self Service Web Site, and therefore cannot be forced to do so. You can require the users to enter their (mobile) phone numbers. This is especially useful in case the phone numbers have not been collected yet at all just let the users do the job themselves. (c) Minimum length requirement This setting allows setting a minimum required length for the PIN code and/or personal passcode, in case the users have been allowed to change any of these. This ensures that the users will not enter too simple PIN codes or personal passcodes User Group Policy: Auto This section describes the settings available on the Auto tab while maintaining a UGP. A good way to get users started using the SMS PASSCODE Self Service Web Site is to send them an , informing them about how to access it. This is exactly what the Auto feature of SMS PASSCODE can do automatically for you. Auto s can be used for two purposes: Welcome s: Informing new SMS PASSCODE users, that they have access to the SMS PASSCODE Self Service Web Site; and how to access it. Reminder s: Sending periodic reminders to existing users in case they have forgotten to enter any required data in the SMS PASSCODE Self Service Web Site.

164 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 164 OF 407 The settings available for configuring the Auto feature are described below: (a) (b) (c) (d) Setting Auto enabled dispatcher Self Service Web Site URL Send welcome s to new users Explanation Specifies whether the auto feature is enabled at all. If this setting is not checked, then all other settings on this tab are ignored. Specifies the dispatcher to use for sending out auto s. The dispatcher determines the SMTP server to use (cf. section 15.15, page 245). Specifies the URL that the users should use to access the Self Service Web Site. This URL will be shown in the auto s sent to the users. Please enter or in front of the URL, depending on the fact whether the Self Service Web Site is protected with Windows Authentication or Form-based authentication, respectively (cf. section 16.5, page 279). Specifies when to send welcome s to new users. Two options are possible: Always: Send a welcome to all users When required data is missing: Only send a welcome to the users that have any of the data missing that has been set as required on the Self Service Web Site Settings tab. E.g. if the phone number has been set as required, then a welcome will be sent to all users that have no phone number set yet. Welcome s are only sent once to each user. However, in case you need to resend a welcome to a specific user, you can force this on the user maintenance page (cf. section , page 229).

165 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 165 OF 407 (e) Setting Reminder s Explanation Specifies whether to send reminder s periodically to the users that have not yet entered all of the data marked as required on the Self Service Web Site Settings tab. E.g. if the phone number has been set as required, then a reminder will be sent periodically to the users, that have omitted to log in to the Self Service Web Site and enter their phone number User Group Policy: License The license tab contains settings to control which types of Client Access Licenses (CALs) are assigned to the users of the UGP. Before describing the details on this tab, it is important first to understand the terms used for license management: License Grants: As an administrator you may grant CALs to users. Whenever you grant a specific CAL to a specific user, it means that you intend to allocate this particular type of CAL to this particular user. However, the CAL might or might not become allocated to the user, for different reasons to be described below. One reason could be, that you are granting more CALs than you have actually acquired. License Allocations: The SMS PASSCODE database service internally contains a License Manager process. This process continuously monitors data changes in the database affecting licensing. Whenever license grants are added or removed, the License Manager will (re-)allocate CALs in the most appropriate way. You can rely on the fact, that whenever a CAL was successfully allocated to a user, the License Manager will not remove the license allocation from this user again, unless you explicitly remove the license grant from this user, or otherwise explicitly decrease the number of available CALs. To conclude, as an administrator you have control of the license grants given to users, whereas the corresponding license allocations are handled internally by the License Manager process. Using the license tab, you can control license grants and inspect license allocations:

166 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 166 OF 407 (a) Setting Number of users assigned to this policy Explanation Shows the total number of users currently assigned to the UGP. (b) License type This column lists the types of CALs that have been acquired according to the license key entered on the License page (cf. section 15.4, page 123). (c) Granted For each row of license types, this column contains a checkbox that lets you control whether the corresponding license type should be granted to the users of the UGP. Select/clear a checkbox to grant or not grant the license type of the row to the users of the UGP, respectively. (d) Limit For each row of license types, this column contains a textbox that optionally lets you enter the maximum number of licenses to allocate to the users of the UGP. Leave the textbox empty to not define any explicit limit for the license type of the row. Enter a specific number, in case you would like to limit the number of license allocations for the license type of the row. This is useful, in case the number of users assigned to the UGP may change over time, outside your control. E.g. if you are a hosting partner, and the users of every customer are assigned to a customer-specific UGP, where the customer is in control of adding/removing users that are imported from AD through a User Integration Policy. Note (Advanced feature): The Limit column is not visible by default. You need to enable License limits on the License page in order to make it visible (cf. section 15.4, page 123).

167 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 167 OF 407 Setting Explanation (e) Actual For each row of license types, this column shows the total number of CALs that have actually been allocated to users of the UGP. Normally you would expect when granting a license type, that the license type will be allocated to all users of the UGP. This means that you would normally expect the number in this column to be identical to (a), i.e. the total number of users assigned to the UGP. However, the actual number of license allocations might differ due to several reasons: The license key does not contain enough CALs of the corresponding license type ( Out of licenses ). Resolution: Acquire more CALs of the license type in question, or remove some of the users from the UGP. A limit has been set for the license type in column (d), and the limit has been reached. Resolution: Increase the limit or remove some of the users from the UGP. The granting of the license type has been removed by an override on individual users of the UGP (cf. section , page 231). On the other hand, if a license type has NOT been granted, then you would normally expect the number in this column to be zero. The actual number of license allocations might in this case only differ, due to the license type being granted to selected users of the UGP via individual overrides (cf. section , page 231). (f) Missing For each row of license types, this column shows the total number of users of the UGP that have been granted the corresponding license type, but have not been allocated a corresponding CAL. Normally you would not expect any allocations to be missing, meaning the column should show a total number of zero missing allocations, and show a green light. On the other hand, if any CAL allocations are missing, due to missing CALs in the license key ( Out of licenses ), or due to an explicitly defined license limit (d), then the column will show a red light to warn about the issue.

168 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 168 OF 407 Note: In case any license allocations have failed, then the License tab will clearly indicate this using red text and an exclamation icon: In case you need to get a better overview of CAL grants and allocations across several UGPs, you have several options for achieving this: Go to the License page to see the overall statistics for license allocations (cf. section 15.4, page 123). Use other license management options (cf. section , page 126) Passcode Policies Passcode Policies are used to define basic settings related to the passcodes themselves, i.e. the length and composition of the random generated one-time-passcodes. Furthermore, Passcode Policies define the content of passcode messages using the MessageDesigner. Each user is assigned to a particular Passcode Policy, which then controls the generation of onetime-passcodes for the user during authentication attempts, and controls the content of the passcode messages sent to the user. The Passcode Policy is normally assigned to the user through the User Group Policy assigned to the user (since each User Group Policy specifies a Passcode Policy), but it is also possible to override this on the individual user and assign a specific Passcode Policy 27. You may create any number of Passcode Policies, thereby having required combinations of passcode settings ready for different groups of users. 27 As an advanced feature, it is also possible to define Authentication Policies that will dynamically override the Passcode Policy of a user during a login attempt; this is called contextual message dispatching. Please refer to section (page 166).

169 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 169 OF 407 Passcode Policies are maintained on the Passcode Policies page. The first time you enter this page, it will look like this: Initially, the SMS PASSCODE database will only contain a single Passcode Policy called Default Passcode Policy. This policy cannot be deleted and will always be assigned to users that are not assigned to any other Passcode Policy. You can add any number of additional Passcode Policies. To maintain Passcode Policies, proceed as follows: a. To add a new Passcode Policy, click the Add new Passcode Policy button. b. To edit a Passcode Policy, click the Edit button on the policy. c. To delete a Passcode Policy, click the Delete button on the policy. NOTE: The built-in Default Passcode Policy is a special policy, which is assigned to User Group Policies and users by default. You can edit, but not delete this policy. IMPORTANT: Please note when deleting a Passcode Policy that all User Group Policies, users and Authentication Policies referring to this Passcode Policy will be set to refer to the Default Passcode Policy instead. The subsection below explains the different settings of a Passcode Policy in detail.

170 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 170 OF Settings of a Passcode Policy When creating a new Passcode Policy or maintaining an existing Passcode Policy, a tab control is shown for configuring the different settings of the policy. The settings are divided into 2 tabs: a. Basic Settings The main settings, for example concerning the passcode generation. b. MessageDesigner Settings defining the content of the passcode messages using message templates and macro placeholders. The different settings are described in detail in the following subsections. When making changes to a Passcode Policy please remember to click the Save button to store the changes permanently.

171 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 171 OF Passcode Policy: Basic Settings This section describes the settings available on the Basic Settings tab while maintaining a Passcode Policy. Setting Explanation (a) Name The name used to identify the Passcode Policy. Giving the Passcode Policy a unique name is mandatory. (b) Description Optional description of the Passcode Policy, for your own records. Here you can describe the purpose of the Passcode Policy. (c) Passcode length This setting controls the length of the generated passcodes, i.e. the number of characters in each passcode. Longer passcodes mean higher security because the probability of guessing a passcode decreases. Shorter passcodes are easier to enter for the users, on the other hand. The default setting is: 6. Allowed range: 5-20.

172 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 172 OF 407 Setting Explanation (d) Passcode type This setting defines whether the generated passcodes are only allowed to contain digits, or a combination of digits and letters. Passcodes containing only digits are usually easier to enter for the users. Passcodes containing both digits and letters, on the other hand, are more secure because there are more combinations, meaning less probability of guessing a passcode. SMS PASSCODE offers a unique option called memopasscodes. memopasscodes are constructed in a special way, making them easier for users to memorize, thereby providing improved user convenience during authentication. At the same time, memopasscodes still offer maximum security by building the passcodes using random patterns. memopasscodes is the recommended passcode type. The default setting is: memopasscodes (e) Passcode lifetime This setting controls for how long a passcode is valid 28 after it has been sent to a user. The user must complete the logon within this time limit to be successfully authenticated using SMS PASSCODE. The default setting is 120 seconds = 2 minutes. Allowed range: seconds (30 seconds - 1 hour) IMPORTANT: Please note that the authentication type Voice call OTP ignores the settings Passcode length and Passcode type. During Voice call OTP authentications, the random passcodes are always generated with the settings Passcode length = 5 and Passcode type = digits only Passcode Policy: MessageDesigner This section describes the settings available on the MessageDesigner tab while maintaining a Passcode Policy. Using the MessageDesigner you can create your own message templates that define the content of passcode messages sent to your users during multi-factor authentication. Both the content of SMS and messages can be defined, independent of each other. IMPORTANT: The number of message templates available on the MessageDesigner tab depend on the fact whether the setting Geo IP and IP History has been enabled on the General Settings page (cf. section 15.3, page 112). 28 When using Load Balancing Policies, it is possible to overrule this setting and define different Passcode lifetimes for different cases.

173 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 173 OF 407 If the setting Geo IP and IP History is disabled on the General Settings page, then the MessageDesigner is in simple mode, allowing maintenance of a single message template. On the other hand, if the setting is enabled, then the MessageDesigner is in advanced mode, allowing maintenance of four different message templates. The difference between these modes is explained in the table below: Mode Simple Mode Advanced Mode Explanation In simple mode, each Passcode Policy defines a single message template defining the content of the passcode messages sent to users. You can define different content of messages sent by SMS and , respectively and you can define different message templates for different groups of users by assigning distinct Passcode Policies to them. However, it is not possible for a single user to receive different, contextual specific message content depending on the specific authentication context. Such location and behavior aware differentiation according to the exact context is only possible, when the MessageDesigner is in the advanced mode. In advanced mode, each Passcode Policy defines 4 different message templates, where each template is used in different contexts. The 4 available message templates are: Unknown IP: This message template is used whenever a user requests an authentication, and the end-user IP is unknown (either because the authentication client in question is not able to collect end-user IP addresses, or because collection of end-user addresses has not been enabled in the SMS PASSCODE Configuration Tool cf. section 20.2, page 392). Learning Mode: This message template is used whenever a user with Learning Mode activated requests an authentication (and the end-user IP is known). Please read section (page 183) for more details regarding Learning Mode. Trusted IP: This message template is used whenever a user requests an authentication from an IP recognized as a Trusted IP (and Learning Mode is not active). Please read section (page 183) for more details regarding the definition of a Trusted IP. Non-Trusted IP: This message template is used whenever a user requests an authentication from an IP recognized as a Non-Trusted IP (and Learning Mode is not active). Please read section (page 183) for more details regarding the definition of a Non- Trusted IP. Additionally, more types of dynamic content (macro placeholders) are available in advanced mode. For example, the message templates Learning Mode, Trusted IP and Non-Trusted IP allow having dynamic content like the name of the country that an authentication request originates from, or the name of the organization owning the end-user IP that the request originates from. The main idea of having different message templates is to give the user the opportunity during an authentication attempt to recognize irregularities and to become alerted in this case. E.g. if the user gets the content of the Non-trusted IP message template, when this was not expected, or a message template shows a country or organization name, that was not expected.

174 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 174 OF 407 The screen shot below shows how the MessageDesigner tab looks in simple mode: The different sections are explained in the table below: Setting Explanation (a) SMS Message Message template for passcode messages sent by SMS (b) Subject Template for the subject of passcode messages sent by (c) Body Template for the body of passcode messages sent by (d) Allowed macros List of macro placeholders permitted in the message templates Any static text entered into any of the message template fields is copied unchanged to the passcode messages sent to users. The section Allowed macros lists the placeholders that you may enter into the message templates for dynamic content. These placeholders will then be replaced with the correct contextual content whenever a message is generated. E.g. wherever you put the macro [USERNAME] in a message template, the name of the actual user receiving a message will appear.

175 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 175 OF 407 In advanced mode the MessageDesigner looks like this: In this case the MessageDesigner shows 4 tabs (Trusted IP, Non-Trusted IP, Unknown IP and Learning Mode). Each tab allows you to define message templates for both SMS and , in the same manner as in simple mode. The different message templates are used under different circumstances, as explained previously. Please note, that additional macro placeholders are available in advanced mode. On each of the 4 tabs the bottom section Allowed macros lists the placeholders that are permitted.

176 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 176 OF 407 Another important feature, only present in advanced mode, is the possibility of having conditional text: Any text between the characters { and } is displayed conditionally in messages sent to users. The text is displayed only, when the country determined from the international prefix of the user s phone number differs from the country determined from the end-user IP address that the authentication originates from. In case a user has no phone number assigned, or no country could be determined from the originating end-user IP address, the countries are assumed to differ; i.e. the conditional text is displayed in this case. You may ask what the purpose of having conditional text is. The idea is that most users will typically log in from an IP address located in their home country, i.e. the country corresponding to the international prefix of their phone number. Since this is the typical scenario, it might be undesired to show repetitive information in the passcode messages each time. Especially getting informed about the name of the originating country during every such authentication attempt might be irrelevant. We want the users to get alerted, in case of irregularities. Hence it makes more sense to display the name of the originating country only when it deviates from the home country. This is exactly what you may achieve using conditional text. Wrapping up the two different modes: Simple mode allows you to adapt the content of the passcode messages per Passcode Policy, e.g. to localize the content or add specific required data, like for example the phone number to the internal helpdesk. Whereas advanced mode additionally allows you to send more detailed contextual information to the user, both depending on location and behavior, thereby giving the user the chance to get alerted in case of any irregularities. WARNING: Consequences of long SMS message content (> 160 characters) When customizing the content of SMS messages (SMS Message templates) it is recommended to keep the message content relatively short and concise. One thing to notice is that longer message content generally means longer message transmission time as well. But more importantly, if the resulting content of an SMS passcode message exceeds 160 characters, this will have the following consequences: If the SMS message is sent using a GSM modem, the message will be split into several messages 29 that are sent sequentially and merged by the receiving mobile phone into a single message again. This means o Longer transmission time (because of several messages) o Possibly higher transmission cost (because of several messages) o No support for flash SMS, i.e. the message is sent as a standard SMS, even though the user was configured to receive a flash SMS If the SMS message is sent as a web service SMS, then only the first 160 characters are forwarded. The remaining message content is cut off. 29 Each message containing up to 155 characters, because 5 characters are lost per message part due to some extra header data.

177 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 177 OF Authentication Policies By default, all users created in the SMS PASSCODE database can log into any authentication client protected by SMS PASSCODE, unless access is denied natively by the authentication client itself. And every user must log in using strong, secure authentication, meaning SMS PASSCODE multi-factor authentication. Authentication Policies optionally allow you to customize this default authentication behavior 30, either making access more or less restrictive under certain circumstances. Examples could be: Deny users to log in from specific continents or countries (because this is not expected) Allow specific groups of users to only have access to a subset of the SMS PASSCODE protected authentication clients Allow users logging in from specific continents or countries to only have access to a subset of the SMS PASSCODE protected authentication clients Allow users logging in from specific trustworthy IP scopes (e.g. internal LAN or branch offices) to have simple access without requiring SMS PASSCODE multi-factor authentication. Additionally, Authentication Policies are used to define a number of other settings, like settings regarding brute-force attacks, and settings controlling Learning Mode and how quickly IP addresses become Trusted. This is all explained in more detail in the following subsections. Each user is assigned to a particular Authentication Policy. The policy is normally assigned to the user through the User Group Policy assigned to the user (since each User Group Policy specifies an Authentication Policy), but it is also possible to override this on the individual user and assign a specific Authentication Policy. You may create any number of Authentication Policies, thereby having different authentication behaviors ready for different groups of users. Authentication Policies are maintained on the Authentication Policies page. The first time you enter this page, it will look like this: 30 Besides Authentication Polices, default authentication behavior is also affected by the CALs allocated to a user, and whether proof-of-concept (PoC) mode is enabled. Please refer to section 7.1, page 26, for details.

178 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 178 OF 407 Initially, the SMS PASSCODE database will only contain a single Authentication Policy called Default Authentication Policy. This policy cannot be deleted and will always be assigned to users that are not assigned to any other Authentication Policy. You can add any number of additional Authentication Policies. To maintain Authentication Policies, proceed as follows: a. To add a new Authentication Policy, click the Add new Authentication Policy button. b. To edit an Authentication Policy, click the Edit button on the policy. c. To delete an Authentication Policy, click the Delete button on the policy. NOTE: The built-in Default Authentication Policy is a special policy, which is assigned to User Group Policies and users by default. You can edit, but not delete this policy. IMPORTANT: Please note when deleting an Authentication Policy that all User Group Policies and/or users referring to this Authentication Policy will be set to refer to the Default Authentication Policy instead. The configuration of Authentication Policies is very flexible and allows for many different setups. The following subsections describe in detail, how Authentication Policies are configured and maintained. First section explains the overall idea of having a sequence of Authentication Rules. Then section explains how to maintain Authentication Policies, i.e. create new ones or edit existing ones. In particular, subsection explains how to maintain the sequence of Authentication Rules of an Authentication Policy. At last, section lists some examples on the usage of Authentication Policies.

179 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 179 OF Authentication Rule Sequence Each Authentication Policy defines a sequence of prioritized Authentication Rules, e.g. a specific sequence could consist of Authentication Rules 1 to 5. Whenever an authentication request is received from a user, the SMS PASSCODE system will evaluate the sequence of Authentication Rules to determine the action to be taken. The sequence is always evaluated in strict order from the first to the last rule. I.e. if the sequence consists of n Authentication Rules, then the rules are evaluated in this order: Authentication Rule 1 Authentication Rule 2 Authentication Rule 3 Authentication Rule n-1 Authentication Rule n The evaluation of the sequence is stopped as soon as the first matching Authentication Rule is found. I.e. the Authentication Rule sequence can be seen as an if-then-else chain: IF Authentication Rule 1 applies THEN use Authentication Rule 1 ELSE IF Authentication Rule 2 applies THEN use Authentication Rule 2 ELSE IF Authentication Rule 3 applies THEN use Authentication Rule 3 ELSE IF Authentication Rule n-1 applies THEN use Authentication Rule n-1 ELSE use Authentication Rule n Please note, that the last Authentication Rule of the sequence will always be a built-in default Authentication Rule that applies to all authentication requests. This is to ensure, that every authentication request is handled even though no other Authentication Rule of the sequence would apply. The possibilities using Authentication Rules are very wide-ranging. You can create any number of Authentication Rules and you can re-arrange the order of them as needed afterwards.

180 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 180 OF Settings of an Authentication Policy When creating a new or editing an existing Authentication Policy in the SMS PASSCODE database, a tab control is shown for configuring the different settings of the Authentication Policy. The settings are divided into 4 tabs: a. Basic Settings Settings for identifying the Authentication Policy b. Brute-force attack protection Settings defining how to react to brute-force attack attempts c. IP Settings Settings regarding behavior aware authentication, i.e. settings regarding Trusted IPs and Learning mode d. Authentication Rules The sequence of Authentication Rules specifying the authentication behavior of the Authentication Policy The different settings are described in detail in the following subsections. When making changes to an Authentication Policy please remember to click the Save button at last to store the changes permanently. Otherwise, all changes will be lost.

181 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 181 OF Authentication Policy: Basic Settings This section describes the settings available on the Basic Settings tab while maintaining an Authentication Policy. The Basic Settings are only used for identifying and describing the Authentication Policy: Setting Explanation (a) Name The name used to identify the Authentication Policy. Giving the Authentication Policy a unique name is mandatory. (b) Description Optional description of the Authentication Policy, for your own records. Here you can describe the purpose of the Authentication Policy Authentication Policy: Brute-force Attack Protection This section describes the settings available on the Brute-force Attack Protection tab while maintaining an Authentication Policy. These settings are used to define, how the SMS PASSCODE system should react to brute-force attacks, i.e. attacks where a hacker tries to determine a user s password or passcode simply by performing a large number of authentication attempts with different guesses. The solution is to limit the number of brute-force attempts a hacker is allowed to perform, thereby making it very unlikely that a hacker would guess the right password or passcode:

182 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 182 OF 407 (a) Setting Max. attempts (Password) Explanation Specifies the number of consecutive incorrect password entries that will cause the SMS PASSCODE system to lock out the user. The first time a lockout happens, the user is locked out temporarily for a duration specified by setting (b). When this duration has expired, the user is allowed to attempt a single authentication again. If another incorrect password is entered this time, the user is locked out temporarily once more, this time for a doubled duration compared to the previous temporary lockout. The procedure continues like this, i.e. if the user keeps entering an incorrect password after each temporary lockout, a new temporary lockout occurs with a doubled duration compared to the previous one. However, setting (c) specifies a threshold for the maximum allowed duration of a temporary lockout. If this threshold is exceeded, the user is locked out permanently. In case the user is locked out, he will not be able to log in to any SMS PASSCODE protected authentication client 31, until an administrator has unlocked his SMS PASSCODE user account. Please note, that the user must enter incorrect passwords consecutively for the procedure above to apply. In case the user enters a correct password before the permanent lockout, then the procedure starts all over, i.e. the user is again allowed to enter incorrect passwords multiple times as specified by setting (a). IMPORTANT: The value of this setting should be calibrated with the lockout threshold setting of the AD Group Policy assigned to the user. It is recommended to set the lockout threshold in SMS PASSCODE to a value lower than the lockout threshold of the AD account. This will ensure that a password brute-force attack will lock out the SMS PASSCODE user account before the corresponding AD user account gets locked out. (b) Initial temporary lockout duration (Password) WARNING: This setting applies to all SMS PASSCODE authentication clients, except SMS PASSCODE IIS Web Site Protection. The ISAPI Filter implementing the IIS Web Site Protection client is not able to detect an SMS PASSCODE lockout before the user authentication has already happened. A work-around is to publish the web site through an ISA/TMG server and install SMS PASSCODE ISA/TMG Web Site protection on the ISA/TMG Server. Specifies the duration of the first temporary lockout period, in case the user has entered more consecutive incorrect passwords than allowed according to setting (a). 31 However, the user is still allowed to log in to the SMS PASSCODE Password Reset Web Site (PRWS) in this case. If the user succeeds logging in to the PRWS, then the user is automatically unlocked again, without any administrator required to take action.

183 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 183 OF 407 (c) (d) (e) (f) Setting Max. temporary lockout duration (Password) Max. attempts (Passcode) Initial temporary lockout duration Max. temporary lockout duration Explanation Specifies the maximum allowed duration of a temporary lockout caused by entering incorrect passwords. If a new temporary lockout period with a longer duration is about to start, the user is locked out permanently instead. In this case, the user cannot log in to any SMS PASSCODE protected authentication client anymore, until an administrator has unlocked the user s SMS PASSCODE account, or the user unlocks his account by logging in to the SMS PASSCODE Password Reset Web Site. Specifies the number of consecutive incorrect passcode entries that will cause the SMS PASSCODE system to lock out the user. The first time a lockout happens, the user is locked out temporarily for a duration specified by setting (e). When this duration has expired, the user is allowed to attempt a single authentication again. If another incorrect passcode is entered this time, the user is locked out temporarily once more, this time for a doubled duration compared to the previous temporary lockout. The procedure continues like this, i.e. if the user keeps entering an incorrect passcode after each temporary lockout, a new temporary lockout occurs with a doubled duration compared to the previous one. However, setting (f) specifies a threshold for the maximum allowed duration of a temporary lockout. If this threshold is exceeded, the user is locked out permanently. Please note, that the user must enter incorrect passcodes consecutively for the procedure above to apply. In case the user enters a correct passcode before the permanent lockout, then the procedure starts all over, i.e. the user is again allowed to enter incorrect passcodes multiple times as specified by setting (d). Furthermore, please note that a hacker will not be able to perform passcode brute-force attacks at all, unless he has stolen the user s password beforehand (since the correct password must be entered to trigger the transmission of a passcode). Specifies the duration of the first temporary lockout period, in case the user has entered more consecutive incorrect passcodes than allowed according to setting (d). Specifies the maximum allowed duration of a temporary lockout period caused by entering incorrect passcodes. If a new temporary lockout period with a longer duration is about to start, the user is locked out permanently instead. In this case, the user cannot log in to any SMS PASSCODE protected authentication client anymore, until an administrator has unlocked the user s SMS PASSCODE account again Authentication Policy: IP Settings This section describes the settings available on the IP Settings tab while maintaining an Authentication Policy. Please note that the IP Settings tab is only available when the setting Geo IP and IP history is enabled on the General Settings page. Otherwise, the settings on this tab are not relevant. The settings on this tab are only of importance if you would like to make use of behavior aware authentication. What this means is, whether you would like to have the SMS PASSCODE system learn by itself over time, which end-user IP addresses should be treated as Trusted and Non-

184 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 184 OF 407 Trusted, respectively. This distinction between the Trusted and Non-Trusted end-user IP address categories allows the SMS PASSCODE system to: Send out different types of passcodes messages depending on the category (cf. Passcode Policies, section , page 172) Define different authentication behavior depending on the category (cf. Authentication Rules, section , page 187) If you do not wish to make use of this type of distinction, then one possibility is to disable the setting Geo IP and IP history on the General Settings page. However, this will disable both location and behavior aware authentication. If you would like to make use of location aware authentication only, then you should ignore the settings on this tab, except disabling the Learning mode setting, and then ensure that no IP addresses will ever become Trusted. You can achieve this by ensuring that no Authentication Rules will ever increase the Trust Level of any end-user IP address (cf. section , page 187, regarding Authentication Rules). As a result, all passcode messages will then use the Non-Trusted message format of the Passcode Policy assigned to a user. On the other hand, if you would like to make use of behavior aware authentication, then an issue might be, that you would like users not to become concerned about passcode messages informing about authentication attempts that originate from end-user IP addresses categorized as Non- Trusted, simply due to the fact than the system has not learned yet, that a commonly used enduser IP address should be treated as Trusted. This is where the Learning Mode feature fits in. This feature allows the SMS PASSCODE system to put a user into a special state for a temporary period, during which the system can identify Trusted end-user IP addresses. During this Learning Period, the system will use the Learning Mode message template of a Passcode Policy instead of the Trusted and Non-Trusted message templates (cf. section , page 172).

185 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 185 OF 407 (a) Setting Trusted IP threshold Explanation Whenever a user performs an authentication from a new end-user IP address, i.e. an IP address not listed in the user s IP history yet, the IP address starts with a Trust Level of zero. By default, the Trust Level increases by 1 on every successful multi-factor authentication originating from the same end-user IP address. However, this behavior can be adapted using Authentication Rules, thereby suppressing the increase of the Trust Level in specific cases, or alternatively increase the Trust Level by more than 1 in specific cases. The setting, Trusted IP threshold, defines the Trust Level an end-user IP address must obtain at least, before it is treated as a Trusted end-user IP address. (b) User IP expiration Whenever a user performs an authentication from a new end-user IP address, i.e. an IP address not listed in the user s IP history yet, the IP address is recorded and added to the user s IP history, in case authentication succeeds. The time and date of the last usage of every such recorded end-user IP address is updated, whenever the user performs another successful authentication from it. However, if an end-user IP address is not used anymore for a long time, it is preferable to remove it completely from the user s IP history. The setting, User IP expiration, defines for how long an unused enduser IP address will stay in the user s IP history, before it is removed from the history. (c) Learning mode This setting defines whether Learning Mode should be enabled for the users assigned to this Authentication Policy. Please note, that this setting can be overridden individually while maintaining users (cf. section , page 229). (d) Learning mode threshold This setting defines the duration of the Learning Period, measured in number of successful multi-factor authentications that the user must complete, before the Learning Mode automatically ends (if Learning Mode was enabled).

186 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 186 OF Authentication Policy: Authentication Rules This section describes the Authentication Rules tab, where you can maintain the sequence of Authentication Rules of an Authentication Policy. a. Click the Add new rule button to add a new Authentication Rule to the sequence. b. Click the Edit button to edit the settings of an Authentication Rule. c. Click the Delete button to remove an Authentication Rule from the sequence. d. To re-arrange the order of the Authentication Rules: Click the title bar of an Authentication Rule without releasing the mouse button, and drag the Authentication Rule to a new position in the sequence. Release the mouse button to drop the Authentication Rule in the new position. Please note, that you can make any number of changes to the Authentication Rule sequence without affecting any current behavior. No changes will take effect until you click the Save button. I.e. as long as the Save button has not been clicked, you can undo all changes by leaving the page without clicking the Save button. However, when clicking the Save button, all changes are immediately pushed to all Load Balancing and Transmitter services on-the-fly and will take effect immediately.

187 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 187 OF Settings of an Authentication Rule This section describes how to maintain the settings of each individual Authentication Rule in the Authentication Rule sequence of an Authentication Policy. When creating a new or editing an existing Authentication Rule, the following dialog appears: The dialog contains 3 tabs: Basic: This tab contains two basic settings for the rule Conditions: This tab is used to define under which conditions this rule should apply. Result: This tab is used to define the outcome of the rule, in case it applies. The settings of the 3 tabs are described below.

188 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 188 OF 407 Basic: The Basic tab contains the following two settings: Setting Explanation (a) Enabled The checkbox Enable rule specifies whether the rule is currently enabled (active) or not. If the rule is disabled, it will be skipped during evaluation of the Authentication Rule sequence, i.e. it will then not affect authentication behavior in any way. This might be useful for temporary de-activation of an Authentication Rule. (b) Description A textbox for entering an optional informative text for your own records. You can use it to describe the purpose of the Authentication Rule. Conditions: The Conditions tab groups all the settings defining the conditions when the Authentication Rule should apply to an authentication attempt. By default, all settings are set to Any, meaning the Authentication Rule will apply to all authentication attempts. However, by changing one or more of the settings, you can customize the Authentication Rule to apply only under specific circumstances, according to your specific requirements. Please note that when several conditions are set, all of them must be fulfilled for the rule to apply. Evaluation of Authentication Rules in case of unknown data When evaluating the conditions of an Authentication Rule, sometimes it may occur that the data to be evaluated by a condition is not available ( unknown ). In such cases, the Authentication Rule will be skipped and evaluation will continue at the next rule in the Authentication Rule sequence. Below, the descriptions of the individual condition settings highlight, when unknown data can occur and what the consequences will be in each case.

189 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 189 OF 407 The table below explains the settings of the Conditions tab in more detail. Condition Explanation Authentication client IP The Authentication client IP setting allows you to define whether the Authentication Rule should only apply in case authentication is attempted through an authentication client with a specific IP address. Please note, that wildcards are also allowed, making it possible to define the restriction on an IP-scope instead of a single IP address. This condition is useful if you would like to define specific authentication behavior for a specific subset of your authentication clients (determined by IP address). Authentication client type The Authentication client type setting allows you to define whether the Authentication Rule should only apply in case authentication is attempted through an authentication client of one or more specific types. Checkboxes allow you to select the allowed types of authentication clients. This condition is useful if you would like to define specific authentication behavior for a specific subset of your authentication clients (determined by type).

190 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 190 OF 407 Condition Explanation End-user IP The End-user IP setting allows you to define whether the Authentication Rule should only apply in case authentication is attempted from a specific end-user IP address. Please note, that wildcards are also allowed, making it possible to define the restriction on an IP-scope instead of a single IP address. This condition is useful if you would like to define specific authentication behavior for a specific subset of end-user IP addresses, e.g. authentication attempts from the internal LAN or from connected branch office networks. Note regarding Secure Device Provisioning (SDP) In case of SDP the end-user IP address is the IP address of the ActiveSync device, not the IP address of the browser logging in to the SDP Web Site. These two IP addresses can be different, but will often be the same, since the user will most likely log in to the SDP Web Site from the ActiveSync device itself. If you need to audit the IP address for the browser accessing the SDP Web Site, then please inspect the Windows event log SMS PASSCODE Provisioning on the relevant Exchange CAS. This event log contains audit events with all relevant authentication information; including end-user IP addresses, in case end-user IP collection has been enabled for SDP in the SMS PASSCODE Configuration Tool on the CAS (cf. section 20.2, page 392). Note about unknown end-user IP The end-user IP address might not be available during an authentication request. Either because an authentication client is configured not to collect it or does not support collecting it. If the end-user IP address is unknown during an authentication attempt and the End-user IP condition is set, then the Authentication Rule will be skipped during evaluation of the Authentication Rule sequence, i.e. the Authentication Rule will NOT apply to the authentication attempt (you can create another Authentication Rule taking care of the unknown end-user IP cases, by setting the Category of end-user IP condition to Unknown, cf. next setting below).

191 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 191 OF 407 Condition Explanation Category of end-user IP Please note, that this condition is only available, if the setting Geo IP and IP history is enabled on the General Settings page. The Category of end-user IP setting allows you to define whether the Authentication Rule should only apply in case authentication is attempted from an unknown end-user IP address, or an end-user IP address that has been identified as Trusted or Non- Trusted, respectively. This condition is useful if you would like to define specific authentication behavior for authentications from Trusted or Non-Trusted end-user IP addresses. E.g. you may deny access to specific types of authentication clients from Non-Trusted IP addresses. Note about unknown end-user IP The end-user IP address might not be available during an authentication request. Either because an authentication client is configured not to collect it or does not support collecting it. If the end-user IP address is unknown during an authentication attempt and the Category of end-user IP condition is set to Trusted or Non-Trusted, then the Authentication Rule will be skipped during evaluation of the Authentication Rule sequence, i.e. the Authentication Rule will NOT apply to the authentication attempt.

192 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 192 OF 407 Condition Explanation Countries Please note, that this condition is only available, if the setting Geo IP and IP history is enabled on the General Settings page. The Countries tab allows you to define whether the Authentication Rule should only apply in case authentication is attempted from an end-user IP address located in one or more specific countries or continents. To define the condition, select the required countries/continents in the Available for selection list and click the Incl. button. This will move the selected countries/continents to the Selected as filter list. If you want to remove any countries/continents from the condition again, select the countries/continents in question in the Selected as filter list, then click the Excl. button. This condition is useful if you would like to define specific authentication behavior for authentications originating from specific countries or continents. E.g. from specific locations you may either deny access completely, or only allow restricted access to specific types of authentication clients. Note about unknown country of origin The country of origin might be unknown during an authentication request. Either because the end-user IP address is not available, due to the authentication client being configured not to collect it or not supporting collection of it; or because the end-user IP address is available, but it is not possible to determine the country of origin from the IP address; e.g. because the IP address is from a private IP scope. If the country of origin is unknown during an authentication attempt and the Countries condition is set, then the Authentication Rule will be skipped during evaluation of the Authentication Rule sequence, i.e. the Authentication Rule will NOT apply to the authentication attempt.

193 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 193 OF 407 Condition Explanation Organization Please note, that this condition is only available, if the setting Geo IP and IP history is enabled on the General Settings page The Organization setting allows you to define whether the Authentication Rule should only apply in case authentication is attempted from an end-user IP owned by a specific organization. If plain text is entered into the filter textbox, then the Authentication Rule will apply as long as the organization name contains the text anywhere. E.g. if you enter the text mycompany, then the rule will apply when authentication is attempted from an end-user IP address owned by for example MyCompany Ltd., MyCompany Industries or CorporationMyCompany. However, you can also enter a regular expression into the filter textbox in case you need to define the matching condition more exactly. E.g. entering ^MyCompany$ will only match IP addresses owned specifically by MyCompany. Please note, that the evaluation of a match is always performed using a case-insensitive comparison. This condition is useful if you would like to define specific authentication behavior for authentications originating from IP addresses owned by specific organizations. Note about unknown organization The name of the organization owning the end-user IP address might be unknown during an authentication request. Either because the end-user IP address is not available, due to the authentication client being configured not to collect it or not supporting collection of it; or because the end-user IP address is available, but it is not possible to determine the organization name from the IP address; e.g. because the IP address is from a private IP scope. If the organization name is unknown during an authentication attempt and the Organization condition is set, then the Authentication Rule will be skipped during evaluation of the Authentication Rule sequence, i.e. the Authentication Rule will NOT apply to the authentication attempt.

194 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 194 OF 407 Result: All the condition settings described above let you define, when an Authentication Rule should apply to an authentication attempt. As explained previously, the first applying Authentication Rule in the rule sequence of an Authentication Policy is the rule that is selected for controlling the authentication behavior of an authentication attempt. The behavior or outcome of the selected rule is controlled by the settings on the Result tab. Setting Explanation Access The Access setting defines how the authentication attempt should be handled under the circumstances defined by the conditions of the rule. You may choose between the following three options: Allow access, use MFA: This is the default behavior. The user is allowed to log in, but must authenticate using strong, secure SMS PASSCODE multifactor authentication. Allow access, bypass MFA: This option allows the user to log in using standard one-factor authentication, i.e. by only entering user name and password. Use of this option should be treated with great care, since it lowers security considerably. However, it might make sense during logins from trustworthy locations, e.g. logins from the internal LAN. Note: The option Allow access, bypass MFA is only available if Multi-factor authentication bypassing has been allowed on the General Settings page. Otherwise, you will not see this option in the drop-down list. WARNING (concerning Password Reset Web Site): Bypassing MFA also applies to logins to the SMS PASSCODE Password Reset Web Site (PRWS). This is a new behavior in SMS PASSCODE version 7.2. If you have upgraded from a previous version and have any authentication rules set to Allow access, bypass MFA, then please verify whether the login behavior for the PRWS is as expected. Otherwise, please create a distinct authentication rule for PRWS with the required behavior. Deny access: This option will deny access, i.e. authentication will always fail immediately, after user name and password has been entered. No passcode will be sent.

195 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 195 OF 407 Setting Explanation Influence on the Secure Device Provisioning (SDP) Web Site When making use of the SDP component for provisioning of ActiveSync devices, please note that the Access setting applies to the SDP Web Site, not to the ActiveSync traffic. In other words, the setting has the following meanings in this case: Allow access, use MFA: The user is granted access to the SDP Web Site and must perform a successful MFA here to provision a new ActiveSync device. Allow access, bypass MFA: The user does not need to access the SDP Web Site instead a new ActiveSync device is approved automatically, without any user actions. This might for example be useful for convenient provisioning of a new ActiveSync device, when the user is in a trusted environment, e.g. when the end-user IP address is within the internal WIFI network of your organization. Deny access: The user is denied access to the SDP Web Site. This means that SMS PASSCODE Secure Device Provisioning is disabled and the user will not be able to self-provision a new ActiveSync device. In this case, provisioning of a new ActiveSync device falls back to the standard logic of Microsoft Exchange Server. Change of IP trust level Please note, that this setting is only available, if the setting Geo IP and IP history is enabled on the General Settings page The setting Change of IP trust level lets you define, how much the Trust Level of the end-user IP address should increase, in case the authentication attempt succeeds. IMPORTANT: Please note that the Trust Level is only increased in case of a successful multifactor authentication. I.e. only when the Access setting is set to Allow access, use MFA and a real multi-factor authentication succeeds. Real means that an OTP from a passcode message or token was used during authentication, as opposed to using a Personal Passcode. It is recommended to either use the default setting of 1, or alternatively set it to zero, in case you have a specific authentication scenario that should not contribute to trusting IP addresses. For example you might not want end-user IP addresses in foreign countries to become trusted ever.

196 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 196 OF 407 Setting Password reset flow Explanation Password Reset only This setting is only relevant for the SMS PASSCODE Password Reset module and is hidden if you have not acquired any Password Reset CALs. You can just ignore this setting if you are not intending to make use of the Password Reset module. The Password reset flow setting affects the login behavior of the SMS PASSCODE Password Reset Web Site. The effective login behavior is determined by a combination of the Access and the Password reset flow setting. Please read section (page 293) for more details regarding the possible login flows. The most secure login flow is achieved by selecting Allow access, use MFA for the setting Access, and selecting Strict flow for the setting Password reset flow. However, by creating several authentication rules with different Password reset flow values depending on different login conditions (login context), you are able to create an adaptive login behavior, making the login less secure, but more convenient from trusted login contexts.

197 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 197 OF 407 Setting Explanation Load Balancing Policy & Passcode Policy By default, the Load Balancing Policy and Passcode Policy used during an authentication attempt are determined statically by the configuration of the actual user either by inheriting the Policies from the User Group Policy, or by specific policy overrides on the user itself (cf. section , page 109). However, when an Authentication Rule applies to a specific authentication attempt, you may optionally introduce a dynamic override of those policies, which takes highest precedence. This means, you may introduce context aware switching to a Load Balancing Policy and/or Passcode Policy that makes more sense in the specific context; also called contextual message dispatching. For example switching to a Load Balancing Policy that prefers voice calls before SMS, when logging in from specific countries, or switching to a Load Balancing Policy that calls a fixed line phone number in a branch office (as the secondary phone number), when logging in from the branch office. To introduce a dynamic policy override, i.e. perform contextual message dispatching, select the corresponding Override radio button, then select the policy of choice from the drop-down list. IMPORTANT: Load Balancing Policy override only takes effect when the Dispatch type of a user is set to a Load Balancing Policy. In other words, when a user is set to use a specific dispatch type, e.g. SMS, not taking into account any Load Balancing Policy, then the override will not take effect, since there is no LB Policy to override.

198 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 198 OF Authentication Rule Summaries When maintaining a sequence of Authentication Rules, the Authentication Rules tab will by default only display the Description of each rule: However, you may select the Show summaries checkbox to get a short summary of each Authentication Rule:

199 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 199 OF Authentication Policy Examples This section shows different examples on how Authentication Policies can be applied usefully. Example 1 (Limit access from specific countries): An enterprise is located in Germany and its employees usually perform logins from Germany only. Any login from Germany should have full access to all authentication clients. Logins from other countries of Europe should have access to all clients, except RADIUS. Logins from outside Europe should not have any access at all. To achieve this, you should create an Authentication Policy with the following 4 Authentication Rules (the last one being the built-in default Authentication Rule): Authentication Rule Configuration #1 The first rule will allow access to everything, but from Germany only. Hence, the Countries condition is set to Germany, and Access is set to Allow access, use MFA:

200 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 200 OF 407 Authentication Rule Configuration #2 The second rule will allow access to all clients, except RADIUS Protection, but only from countries within Europe. Hence the Authentication client type filter is set to all clients except RADIUS Protection, the Countries condition is set to all countries of Europe, and Access is set to Allow access, use MFA:

201 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 201 OF 407 Authentication Rule Configuration #3 Deny access in all other cases. I.e. create a rule without any conditions set, that has Access set to Deny access: Example 2 (Skip MFA for internal access to OWA): An enterprise has an Outlook Web Access (OWA) site that is protected using SMS PASSCODE IIS Web Site Protection, and hosted on a specific server with the IP address Any access to the OWA site from within the same network scope should be allowed without requiring SMS PASSCODE multi-factor authentication (MFA). However, any external access to the OWA site should still require MFA. To achieve this, you should create an Authentication Policy with two Authentication Rules (the last one being the built-in default Authentication Rule): Authentication Rule Configuration #1 The first rule will allow access without MFA, but only regarding access to the SMS PASSCODE IIS Web Site Protection component on the specific OWA server, and only regarding authentication requests coming from the same network scope. Hence, the Authentication client IP and Authentication client type conditions are set, and the End-user IP condition is set, and Access is set to Allow access, bypass MFA:

202 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 202 OF 407 Authentication Rule Configuration Example 3 (Convenient Provisioning of ActiveSync devices): An enterprise located in the US uses ActiveSync devices and would like users to self-provision new ActiveSync devices. When a new ActiveSync devices is connected to the internal WIFI of the organization, IP scope *, then the device should be approved without any MFA. Otherwise, self-provisioning of an ActiveSync device is allowed from anywhere in the US. Outside US, no self-

203 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 203 OF 407 provisioning should be allowed. To achieve this, you should create an Authentication Policy with four Authentication Rules (the last one being the built-in default Authentication Rule): Authentication Rule Configuration #1 The first rule will allow provisioning without MFA, when the authentication client type is ActiveSync Device Provisioning and the end-users IP address is within the scope of the internal WIFI network. Hence the Authentication client type and End-user IP conditions are set, and Access is set to Allow access, bypass MFA:

204 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 204 OF 407 Authentication Rule Configuration #2 The second rule will allow provisioning with MFA, when the authentication client type is ActiveSync Device Provisioning and the end-users IP address is within the US. Hence the Authentication client type and Country conditions are set, and Access is set to Allow access, use MFA:

205 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 205 OF 407 Authentication Rule Configuration #3 Finally deny access for all other Device Provisioning requests: 15.9 Token Policies While it is recommended to use session-specific, real-time authentication, some organizations nevertheless request support for token authentication as well. SMS PASSCODE supports sideby-side authentication using tokens, and even allows very flexible configuration of the actual types of tokens used by your organization; supporting both hardware and software tokens. If you do not plan to make use of tokens for authentication, then you may disregard this section. Token Policies are used in SMS PASSCODE to specify the actual types of tokens used in your organization. SMS PASSCODE supports the following types of tokens: All OATH compliant tokens, including time-based (TOTP) and event-based (HOTP) tokens Proprietary USB Keys from Yubico (YubiKeys)

206 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 206 OF 407 You can use any kind of OATH compliant token, including hardware and software tokens, since Token Policies let you specify the relevant token characteristics. Token Policies also support import of token seed files, which are typically used in case of hardware tokens to import mappings from token serial numbers to token seeds. Each user is assigned to exactly one Token Policy, which defines the characteristics of the token assigned to the user. If you allow different user groups to use tokens with different characteristics, then just create several Token Policies and assign them as needed, typically by assigning the different user groups to dedicated User Group Policies that assign the right Token Policy, or alternatively by permitting users to choose the right Token Policy by themselves using the SMS PASSCODE Self-Service Web Site (cf. section , page 161). IMPORTANT: Please ensure that all required Token Policies are configured correctly and assigned to the right users, BEFORE starting assignment of tokens to users. If you change the Token ID encoding setting of a Token Policy afterwards, this will most likely invalidate all existing token assignments. Token Policies are maintained on the Token Policies page. The first time you enter this page, it will look like this: NOTE: If you do not see the Token Policies menu item in the navigation menu, then you have not allowed Token authentication on the General Settings page (cf. section , page 119). Initially, the SMS PASSCODE database will only contain a single Token Policy called Default Token Policy. This policy cannot be deleted and will always be assigned to users that are not assigned to any other Token Policy. You can edit the Default Token Policy, and you can add any number of additional Token Policies. It is recommended to create additional Token Policies in the following two cases: Your organization is using several types of tokens with different characteristics. In this case, create a Token Policy per token type. Your organization is only using one type of tokens, but you need to import one or more token seed files for these tokens. In this case, you need to create an additional Token Policy, since the Default Token Policy does not support import of token seed files. In all other cases, it is recommended not to create any additional Token Policies, but instead just edit the Default Token Policy and configure it according to your requirements.

207 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 207 OF 407 To maintain Token Policies, proceed as follows: a. To add a new Token Policy, click the Add new Token Policy button. b. To edit a Token Policy, click the Edit button on the policy. c. To delete a Token Policy, click the Delete button on the policy. NOTE: The built-in Default Token Policy is a special policy, which is assigned to User Group Policies and users by default. You can edit, but not delete this policy. IMPORTANT: Please note when deleting a Token Policy that all User Group Policies and/or users referring to this Token Policy will be set to refer to the Default Token Policy instead Creating a new Token Policy When creating a new Token Policy, you have to make an important decision, how to maintain the token IDs (also called token seeds ) of the tokens of the users assigned to this Token Policy:

208 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 208 OF 407 The two options work as follows: Manual entry: This option means that token IDs have to be entered directly, when assigning a token to a user. This can be handled in two ways: o Administrator provisioning: An administrator can enter the token ID directly on a user, when provisioning the token for the user. o Self-provisioning: The end-user can enter the token ID in the SMS PASSCODE Self-Service Web Site, if allowed to. Manual entry is the most common choice for software tokens, where the token ID is not pre-loaded into the tokens by the token manufacturer, but can be chosen as desired. Token-sharing is not supported with this option. I.e. even if you enter the same token ID for two users, this will be treated as two independent tokens. Import from token seed file(s): This option means that token IDs are determined indirectly. In this case you will need to import so-called token seed files. Such a file defines the mappings from public token serial numbers to private token IDs. After having imported one or more relevant token seed files, token assignment can be handled in two ways: o Administrator provisioning: An administrator can enter the token serial number directly on a user, when provisioning the token for the user. o Self-provisioning: The end-user can enter the token serial number in the SMS PASSCODE Self-Service Web Site, if allowed to. In either case, the entered token serial number is used by the SMS PASSCODE system to determine the token ID via the imported token seed file mappings. Token-sharing is supported with this option. I.e. it is allowed to assign the same token serial number to several users, who can then share the corresponding token. Import of token seed files is typically used for hardware tokens, where token IDs are preloaded into the tokens by the token manufacturer, and the manufacturer provides a corresponding token seed file, when delivering the tokens. The token serial numbers are typically printed directly on each token. Requirements Please note that the following token seed file formats are supported: CSV and PSKC. Any other proprietary file formats are not supported. Additionally, only OATH tokens are supported, when importing token seed files. When using USB Keys ( YubiKeys ), please select the Manual entry option. IMPORTANT: Permanent decision The selected option for handling of token IDs is permanent. I.e. after creating a new Token Policy you will not be able to switch the option for this Token Policy. However, you can always delete the Token Policy and create a new one.

209 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 209 OF 407 The subsections below explain the different settings of a Token Policy in detail. First section describes the settings available in Manual entry mode, whereas section describes the settings available in Import from token seed file(s) mode Settings of a Token Policy in Manual Entry Mode When maintaining a Token Policy in Manual entry mode, the following page is shown: The different settings are described in detail below. When making changes to a Token Policy please remember to click the Save button to store the changes permanently. Setting Explanation (a) Name The name used to identify the Token Policy. Giving the Token Policy a unique name is mandatory. Note: If you are planning to permit end-users to select Token Policies in the SMS PASSCODE Self-Service Web Site, then it is recommended to give the Token Policies descriptive names, since end-users will have to select the policies by name. (b) Description Optional description of the Token Policy, for your own records. Here you can describe the purpose of the policy in more detail. (c) Token Mode This setting is used to specify the general type of the token. The following types are supported: USB Key: Proprietary YubiKey token. Note: As mentioned in section (page 122), you need to sign up for a 3 rd party web service in order to validate logins using this type of token. OATH / HOTP: Event-driven OATH compliant token. OATH / TOTP: Time-driven OATH compliant token.

210 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 210 OF 407 When Token Mode USB Key is selected, no additional settings are required. For the OATH Token modes, more settings will be shown that allow configuration of the specific OATH tokens in question: Token Policy settings available with Token Mode = OATH / HOTP Token Policy settings available with Token Mode = OATH / TOTP

211 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 211 OF 407 Setting Explanation (d) Token type Use this setting to specify the type of token, i.e. whether it is a hardware token or software token. The difference between these types of tokens is the way token IDs are assigned. For hardware tokens, the vendor has pre-loaded a unique token ID into each token. When assigning a specific token to a user, the administrator or user must ensure that the correct pre-loaded token ID is entered and assigned to the user. For software tokens, no token ID has been pre-loaded. The administrator or user may enter any token ID of own choice in this case. SMS PASSCODE provides a Generate button, which can be used optionally for generating a random token ID. When setting the token type to Software Token, an additional option Show QR code for generated token IDs appears: Select this option, in case you would like generated token IDs to be presented as QR codes. This applies not only to the Web Administration Interface, but also to the SMS PASSCODE Self-Service Web Site. I.e. in case a user has been allowed to set a token ID in the Self-Service Web Site, then the user might generate a token ID himself and scan the resulting QR code. This provides a convenient way for selfenrollment of software tokens. QR codes are supported by many popular software tokens. The QR code will contain the generated token ID, and additionally other relevant parameters corresponding to the user s Token Policy. The following attributes are provided by the QR code: Token ID Passcode length Hash function Time step IMPORTANT (Software Tokens ignoring QR code attributes) Please note that software tokens of some vendors may ignore one or more of the attributes provided by the QR code, because specific behavior is hardcoded into the software token. E.g. a specific passcode length or time step size might have been hardcoded. In such cases, it is important that the Token Policy is configured correctly according to the hardcoded attributes of the software token in question (please consult the specifications of the software token). (e) Passcode length Use this setting to specify the number of digits in the passcodes generated by the OATH token. A length of 6 digits is most common, but SMS PASSCODE also supports tokens with 7 or 8 digits.

212 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 212 OF 407 (f) Setting Hash function Explanation This setting is for time-based (TOTP) OATH tokens only. According to the OATH standard, TOTP tokens are allowed to use the HMAC-SHA-1, HMAC-SHA-256 or HMAC-SHA-512 function for passcode generation. Use this setting to specify the function used by your specific tokens, according to the token manufacturer s specification. If in doubt, please try the different settings by trial-anderror, until authentication succeeds. HMAC-SHA-1 is the most common choice. (g) Time step This setting is for time-based (TOTP) OATH tokens only. Use this setting to specify the validity period of each generated passcode. Please refer to the specification of your tokens to select the correct duration. Most commonly TOTP tokens generate a new passcode every 30 or 60 seconds. (h) Token ID encoding Use this setting to specify the format of the token IDs, when they are entered into either the Web Administration Interface (by administrators) or the Self-Service Web Site (by end-users). If in doubt about the token ID format, here are some hints: HEX (Base16) IDs may contain digits 0-9 and letters A-F (case insensitive). Base32 IDs may contain digits 2-7, letters A-Z (case insensitive) and the character = for padding. Base64 IDs may contain digits 0-9, letters A-Z and a-z (case sensitive), characters / and +, and the character = for padding. If still in doubt, please try the different settings by trial-and-error, until authentication succeeds. For software tokens, Base32 is the most common setting.

213 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 213 OF Settings of a Token Policy in Token Seed File Import Mode When maintaining a Token Policy in Import from token seed file(s) mode, the following page is shown: The settings available are the same as in Manual entry mode (cf. section above), except the following minor differences: Token mode: o Only OATH compliant tokens are supported in this mode. USB Keys ( YubiKeys ) are not supported. Token type: o This setting is not available in this mode, since it is not relevant. Token ID encoding: o This setting is not available in this mode, since the encoding is chosen during import of token seed files.

214 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 214 OF 407 The following additional features are available in Import from token seed file(s) mode: Feature Explanation (a) Import tokens from file Click this link to import a token seed file and store the imported mappings as part of this Token Policy. (b) Imported tokens Click this tab to inspect and maintain previously imported token seed mappings. For example, you can inspect current token assignments or remove previously imported token mappings. The following two subsections describe these features in more detail.

215 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 215 OF Importing Token Seed files To import a new token seed file into a Token Policy, proceed as follows: BEFORE importing a token seed file, please ensure that all settings of the Token Policy comply with the tokens that you are going to import. If you are going to import several token seed files for tokens with different characteristics, then you must create several Token Policies, each one having settings matching the corresponding tokens. To start an import, click the Import tokens from file link: A dialog appears. Select the appropriate format of the token seed file that you going to import, then click the Continue button:

216 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 216 OF 407 CSV file format: When importing a token seed file in CSV format, please note the following requirements: o Every line must describe the token seed mapping for exactly one token. o Every line must contain exactly two fields containing Token S/N and Token ID, in this order. Comma (, ) or semi-colon ( ; ) are allowed as field delimiters. o No field headers are expected, i.e. the first line contains the mapping of the first token. PSKC file Format: When importing a token seed file in PSKC format, please note the following requirements: o Both encrypted and non-encrypted PSKC files are supported o A PSKC file might in rare cases contain tokens with different characteristics, e.g. tokens with different time step sizes. The import routine will automatically detect the characteristics of the tokens in the PSKC file and only import the tokens with characteristics matching the settings of the Token Policy (the remaining ones are skipped). To import all tokens from a PSKC file containing tokens with different characteristics, create several, matching Token Policies, then import the same file into each such Token Policy. This will result in a correct distribution of the tokens into the matching Token Policies. A dialog appears for selecting the token seed file to import. CSV file format: In case of a CSV file, you need to specify the path of the file, and select the correct encoding of the token IDs: To import the file, click the Import button.

217 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 217 OF 407 PSKC file Format: In case of a PSKC file, you need to specify the path of the file. Additionally, you may specify the path of the file containing the encryption keys ( key file ). However, this is only required, when the token IDs in the PSKC file have been encrypted otherwise, just leave the path of the key file empty: When you are ready to import the file, click the Continue button. A message will appear, informing about the number of tokens in the file, and informing about the number of tokens being imported (with characteristics matching Token Policy) and being skipped (with characteristics not matching Token Policy). IMPORTANT Any newly imported tokens are NOT persisted to the SMS PASSCODE database, until you click the Save button on the Token Policy. I.e. just after the import has been completed, you can inspect the import result on the Imported tokens tab and still cancel the import, if the result is not as expected. The next section describes how to inspect or maintain the imported tokens.

218 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 218 OF Maintaining Imported Tokens The Imported tokens tab on a Token Policy in Import token seed file(s) mode lists all information regarding the token seed files imported into this Token Policy so far: The topmost table shows overall statistics for the imported tokens: Total: Total number of tokens imported In use: Number of imported tokens that have been assigned to at least one user (tokensharing is supported, i.e. a token is allowed to be assigned to one or more users). Available: Number of imported tokens that have not been assigned to any user yet. The table at the bottom lists the specific data for each imported token. By inspecting this data, you can for example get answers to the following questions: When was the token imported? ( Import date time ) What was the name of the file that the token was imported from? ( Import filename ) How many users have been assigned to this token? ( Assigned user count ) Which users have been assigned to this token? ( Assigned users ) The Set filter button allows you to filter the list of tokens, e.g. to find a specific token S/N, to list all tokens imported from a specific file, or to display available tokens only.

219 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 219 OF 407 If you want to delete any earlier imported tokens, e.g. because a token has been lost or has been damaged, please proceed as follows: a. Select the checkboxes to the left of the tokens to delete (select the checkbox in the header row to select all visible tokens at once). b. Then click the Delete selected button. Please note, that any deletions are not persisted, until you click the Save button on the Token Policy Users The Maintain users page is used for maintaining SMS PASSCODE users. Only users created in the SMS PASSCODE database will be granted access by SMS PASSCODE. Users can be maintained in two different ways manually or using User Integration Policies (i.e. Active Directory integration). You can use both ways at the same time. I.e. you can decide to maintain some users manually, while other users are imported automatically using User Integration Policies (cf. section 15.5, page 127). Active Directory Integration is disabled by default. You can enable it on the General settings page (cf. section 15.3, page 112).

220 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 220 OF 407 When entering the Maintain users page, it will look a bit different, depending on whether AD Integration is enabled or not. In case AD Integration is disabled, the page will look something like this: a. Click the Add new user button to manually create a new user. b. Click the Test button to send a test message to a specific user. This is useful for testing, whether the correct phone number or address has been assigned to the user, or to test whether message dispatching works in general. c. Click the Edit button to edit an existing user. d. Click the Delete button to delete an existing user. Note: The Delete button is disabled for users imported by a User Integration Policy because these users can only be deleted by removing them from the AD Group they originate from. If AD Integration is enabled, the Maintain users page will additionally show user synchronization information at the top of the page: Click the Sync now button to trigger a new user synchronization immediately Click the User Sync. Report button to get a detailed report about the last successful synchronization. E.g. use this report to inspect which users were skipped and why they were skipped. Please note, that you also can bulk import users from a comma-separated file (cf. section 15.11, page 236).

221 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 221 OF 407 The following subsections describe in detail the settings that can be maintained while creating a new user or editing an existing user Settings of a User When creating a new user or maintaining an existing user, a tab control is shown for configuring the different settings of the user. The settings are divided into 6 tabs: a. Basic Settings The main settings of the user, for example user name and (mobile) phone number. b. User Group Policy Settings The User Group Policy (UGP) assigned to the user, and all the settings inherited from this UGP. On this tab you can inspect the inherited settings and override them if necessary. c. Self Service Web Site Settings The Self Service Web Site settings inherited from the assigned UGP, i.e. permissions for the Self Service Web Site. On this tab you can inspect the inherited settings and override them if necessary. d. Auto Information about when automatic welcome and reminder s have been sent. e. Authentication Policy Settings Settings inherited from the Authentication Policy assigned to the user. On this tab you can inspect and control the current state of Learning Mode for the user. f. License Displays the license settings inherited from the assigned UGP, and the current license allocation status. Optionally, you may override the inherited license settings on this tab. The different settings are described in detail in the following subsections. When making changes to a user please remember to click the Save button at last to store the changes permanently.

222 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 222 OF User: Basic Settings This section describes the settings available on the Basic Settings tab while maintaining a user. Please note, that most entries are optional. However, it is mandatory to enter at least one login name (in either SAM or UPN format) that uniquely identifies the user. Setting Explanation (a) Data Source Specifies where the user originates from, i.e. whether the user has been created manually, or imported by a User Integration Policy. (b) Display Name Optional, descriptive name of the user -- to be used for searching or filtering. (c) Login (SAM) Login name of the user in SAM account format. If using a single domain for authentication, you can just enter the login name without any domain name prefix. However, if you are planning to create users from different domains, you should always enter the user name in the format domain\username to avoid name conflicts in case some users from different domains have identical user names. (d) Login (UPN) Login name of the user in UPN format (user@domain).

223 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 223 OF 407 (e) (f) Setting Phone number (primary) Phone number (secondary) Explanation (Primary) phone number to be used for receiving passcodes (by SMS or voice call). You may explicitly enter an international phone number prefix (e.g. +44). If no prefix is entered, then the default prefix is assumed. The default prefix is configured on the General Settings page (cf. section 15.3, page 112). Secondary phone number to be used for receiving passcodes (by SMS or voice call) in failover scenarios. Used by Load Balancing Policies (cf. section 15.18, page 251). You may explicitly enter an international phone number prefix (e.g. +44). If no prefix is entered, then the default prefix is assumed. The default prefix is configured on the General Settings page (cf. section 15.3, page 112). Note: This field is only available if secondary phone numbers have been enabled on the General Settings page. (g) address to be used for receiving passcodes by , or to be used for receiving auto s (cf. section , page 163).

224 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 224 OF 407 (h) Token ID The unique ID that identifies the token assigned to the user. Entering such an ID will allow the user to use the designated token for authentication, but only if token authentication has also been allowed (on the User Group Policy Settings tab). In case the user has been assigned an OATH software token, then a token ID of own choice can be used. The Generate button can be clicked in this case to generate a random token ID. Please enter such a random token ID into the software token immediately, since it cannot be displayed later again. If the option Show QR code for generated token IDs has been enabled on the user s Token Policy, then the generated token ID will be shown as a QR code, which provides a very convenient way for the user to enter the token ID into the software token simply by scanning the QR code (requires that the software token supports QR codes). If the token is a USB Key (YubiKey) and you have the USB Key at hand, then the easiest way to enter the ID is to place the cursor in the Token ID field, insert the USB Key into a USB port, and click the button on the USB Key. Note: This field is only available if token authentication has been allowed on the General Settings page, and the user is assigned to a Token Policy NOT using token seed file imports. Token Resync: When using OATH tokens, you may in some cases need to perform a Resync of the token, if it gets out of sync for some reason. One possible reason is that an existing, already used token is re-assigned from one user to another. When a token ID has been defined and the user is allowed to perform token authentication, a Resync button will appear beside the token ID field. Click the button to perform a resync. A dialog will pop up and ask you to enter two consecutive OTPs from the token. Using these two codes, the system will resynchronize its internal token state, and the token should work again. If allowed to, end-users can also perform a token resync by themselves using the SMS PASSCODE Self-Service Web Site. The resync permission is set on the Self Service Web Site Settings tab of the user s UGP (or overridden on the Self Service Web Site Settings tab of the user).

225 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 225 OF 407 Setting Explanation (h) Token S/N If the user has been assigned a Token Policy with token seed file imports, then you will not see the Token ID field, but instead a Token S/N field. Note: This field is only available if token authentication has been allowed on the General Settings page, and the user is assigned to a Token Policy using token seed file imports. This field allows you to enter the public token S/N of a token to assign it to the user. The token S/N is typically printed directly on the physical token itself. (i) PIN Optional code, typically consisting of 4 digits, that must be entered in front of each passcode during SMS PASSCODE authentication attempts. (j) Locked Out Specifies whether the user account has been locked out. You can manually lock out or unlock a user account. Furthermore, an account might also become locked out automatically by the system due to different types of authentication attacks. If this happens, a note is displayed below the checkbox explaining the reason of the lockout. The note might as well inform about the duration of the lockout, in case it is a temporary lockout set by the system.

226 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 226 OF 407 (k) Setting Date/Time restrictions Explanation Select this option if you would like to define date and/or time restrictions for the user, i.e. to define restrictions when the user is allowed to log in to any of the SMS PASSCODE protected authentication clients. The option is deselected by default. When selecting the option, additional options become available at the bottom of the Basic Settings tab: The section Time limited access contains settings that allow you to define, when the user account becomes active (l) and/or expires (m). You may set Valid from without setting Valid until, and vice versa. Also, it is optional to enter anything into the Time fields. If nothing is entered into a Time field, then the whole day of the entered date is included. o If setting (l) is set, then a user is not allowed to log in to any SMS PASSCODE protected authentication client, until the specified date (and time). o If setting (m) is set, then a user is not allowed to log in to any SMS PASSCODE protected authentication client after the specified data (and time). Among others, the settings are useful for defining a restricted period of remote access for an external consultant. The section Allowed logon hours allows you define a fixed schedule of allowed logon hours, i.e. define specific hours of each week day, where the user is allowed to log in to any SMS PASSCODE protected authentication client. To define the schedule, click on the button Edit (n) and select the allowed logon hours in the week-hour-matrix that appears. Afterwards, a summary of the selected schedule is displayed at the bottom of the section (o).

227 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 227 OF User: User Group Policy Settings This section describes the settings available on the User Group Policy Settings tab while maintaining a user. The main purpose of the User Group Policy Settings tab is to provide the option to select the User Group Policy (UGP) that should be assigned to the current user (a): As soon as a UGP has been selected, region (b) will show the settings that the user inherits from the UGP. In case you need to define a user specific exception, you can override any of the inherited settings by selecting the override checkbox of the setting in question. The override checkboxes are located in the override column, region (c). Please read section (page 148) for a detailed description of the various UGP settings User: Self Service Web Site Settings This section describes the settings available on the Self Service Web Site Settings tab while maintaining a user. You only need to maintain settings on this tab if you intend to make use of the

228 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 228 OF 407 SMS PASSCODE Self Service Web Site (cf. section 16, page 275), and you wish to override the Self Service Web Site permissions inherited from the UGP assigned to the user The Self Service Web Site Settings tab contains a permission table that shows the permissions of the user with respect to the SMS PASSCODE Self Service Web site. Initially, region (a) shows the permissions inherited by the UGP assigned to the user. The override checkboxes in region (b) allow you to override individual permissions and define user specific exceptions. Please read section , page 161, for a detailed description of the various Self Service Web site permissions.

229 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 229 OF User: Auto This section describes the content of the Auto tab while maintaining a user. Note: The Auto tab is only available when a user is assigned to a User Group Policy with the auto feature enabled. When the auto feature is enabled for a user, the Auto tab will show information about when a welcome and/or reminder was sent automatically to this user: Additionally, in case you would like to re-send the welcome to the user, you can select the checkbox Resend the welcome Afterwards, you must also click the Save button to actually trigger the resending of the welcome e- mail User: Authentication Policy Settings This section describes the content of the Authentication Policy Settings tab while maintaining a user. Note: The Authentication Policy Settings tab is only available when the setting Geo IP and IP history is enabled on the General Settings page. As explained in section (page 183), the Authentication Policy assigned to a user might define settings for the user regarding Learning Mode. While maintaining a user, the

230 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 230 OF 407 Authentication Policy Settings tab is used to control and display current state information regarding the Learning Mode: (a) (b) (c) (d) Setting Learning Mode Enabled Learning Mode State Learning Mode Termination Explanation By default, checkbox (b) displays whether Learning Mode is enabled according to the Authentication Policy assigned to the user (inherited setting). However, the inherited setting can be overridden by selecting checkbox (a) and hereafter selecting/clearing checkbox (b) as required. This row displays whether Learning Mode is currently active or not for the user. It might be deactivated because Learning Mode has not been enabled. If Learning Mode is enabled, it could be deactivated due to the fact, that the learning mode period has terminated (since the learning mode threshold has been exceeded) If Learning Mode is currently active, then this row displays the number of remaining multi-factor authentications that the user must still complete successfully, before the learning mode terminates (e) Reset Counter Click the Reset Counter button, if you would like the Learning Mode to start all over again for the user. The number of remaining successful authentications will be reset to the Learning Mode Threshold defined by the Authentication Policy currently assigned to the user.

231 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 231 OF User: License This section describes the content of the License tab while maintaining a user. The tab allows you both to inspect the license status of the user, and optionally also to override license grants: For a description of License Grants vs. License Allocations, please read section (page 165). Column Explanation (a) Granted By default, this column shows the CAL grants inherited from the User Group Policy assigned to the user. A selected checkbox indicates that the corresponding type of CAL has been granted to the user. (b) License allocation state This column shows the actual license allocation state. Only if the column shows a green light and the text Allocated, then the granted type of CAL was allocated successfully to the user. A CAL might not become allocated due to missing licenses or license limits (cf. section , page 165). (c) Override This column allows you to override the inherited CAL grants. When selecting a checkbox in this column, the checkbox in the Granted column becomes enabled, allowing you to select or clear that checkbox to grant or remove the corresponding type of CAL, respectively. Overriding CAL grants is normally not recommended, but might be useful in exceptional cases. For example it could be useful for temporarily releasing a specific type of CAL from a user, because it is urgently missing for another user due to lack of licenses. In case you need to get an overview of CAL grants and allocations across users, you have several options for achieving this: Go to the License page to see the overall statistics for license allocations (cf. section 15.4, page 123). Use other license management options (cf. section , page 126).

232 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 232 OF User IP History If the setting Geo IP and IP history has been enabled on the General Settings page, the SMS PASSCODE database will automatically record a history of the end-user IP addresses used by each individual user. While maintaining a user, you gain access to the IP history of the user by clicking the Show IP History link in the right pane: NOTE: The Show IP History link is only available if the Geo IP and IP history setting has been enabled on the General Settings page. When clicking the link, a new window is opened, showing the end-user IP addresses that the user recently has authenticated from successfully. Recently means, that the user has authenticated from the IP address within the IP expiration period defined by the Authentication Policy assigned to the user (cf. section , page 183). The IP history shows the following information for each IP address: (a) Item Trusted IP threshold Explanation Informative text showing the currently required Trust Level that an end-user IP address must reach before it becomes an Trusted IP according to the Authentication Policy currently assigned to the user (b) Refresh If the User IP History window is kept open for a while, the IP history might become outdated, e.g. because the user has performed new authentications in the meantime. Please click the Refresh button to update the list and make it display the most recent data. (c) Add new entry This button lets you add a new end-user IP address manually to the user s IP history. This could for example be useful, if you have configured the SMS PASSCODE system NOT to identify Trusted IP addresses, but prefer to add Trusted IPs manually by yourself.

233 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 233 OF 407 Item Explanation (d) Delete all This button lets your clear the whole IP history of the user. A confirmation dialog will ask you to confirm this action. If confirmed, the user s IP history is deleted permanently. (e) Edit You may edit any individual IP entry in the user s IP History by clicking the Edit button in the corresponding row. This might be useful, e.g. if you would like to change the Trust Level of an entry manually. (f) Delete You may delete any individual IP entry in the user s IP History by clicking the Delete button in the corresponding row. (g) Close Click the Close button to close the window. The user s IP History list displays valuable information about each entry: Column Explanation (a) IP Specifies an end-user IP address that the user has authenticated successfully from. (b) Last usage Specifies the time and date of the last occurrence when the user authenticated successfully from the IP address. (c) Trusted Specifies whether the IP address is currently treated as a Trusted IP. This depends on the fact whether the current Trust Level of the IP address has reached the current Trusted IP threshold, which is displayed at the top of the User IP History window. (d) Country Name Displays the name of the country, where the IP address is located. (e) Organization Displays the name of the organization owning the IP address. (f) Trust Level Displays the current Trust Level of the IP address. The Trust Level is updated on every successful multi-factor authentication according to the Authentication Rules of the Authentication Policy currently assigned to the user (cf. section , page 187). In case you would like to sort the entries in the list according to the values of a specific column, please click the header of the column.

234 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 234 OF User Login History If Authentication Monitoring has been enabled on the General Settings page, the SMS PASSCODE database will automatically record every attempt of any user trying to log in to any SMS PASSCODE protected authentication client. All recorded authentication attempts can be monitored on the Authentications Monitoring page (cf. section 15.19, page 264). However, while maintaining a user, there is a shortcut to gain immediate access to this specific user s login attempts ( Login History ) by clicking the Show Login History link in the right pane: NOTE: The Show Login History link is only available if Authentication Monitoring has been enabled on the General Settings page. Clicking the link Show Login History will redirect the WAI directly to the Authentications Monitoring page (described in section 15.19, page 264) and automatically configure a row filter that only displays the authentication attempts of the user in question. Immediate access to the user s current login history might for example be useful for an internal helpdesk, in case a user has problems with performing a successful login. The helpdesk can immediately inspect the most recent login attempts and inspect the reasons for failed login attempts.

235 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 235 OF Adding and Deleting Users Using AD Integration When Active Directory Integration has been enabled you can also maintain users using one or more selected groups in Active Directory. All users belonging to these AD groups are automatically added to the SMS PASSCODE user grid on the Maintain users page. When a user is removed from one of the selected AD groups, then the user is automatically removed from the SMS PASSCODE user grid. Please note that when users are added or removed from a selected AD group, then these changes will not occur immediately in the SMS PASSCODE user grid because SMS PASSCODE checks for AD changes only periodically. If you wish to force a change in the Active Directory to take effect in SMS PASSCODE immediately, you can manually force an instant refresh. To force a refresh, click the Sync now button on the Maintain users page: If some users are not imported into the SMS PASSCODE user list from the Active Directory, even though they are member of a selected AD group, then these users will be displayed as skipped : Users might be skipped due to the following reasons: A phone number is required according to the UIP, but it is missing or is incorrect. Please check the content of the field in Active Directory containing the phone number. An address is required according to the UIP, but it is missing or is incorrect. Please check the content of the field in Active Directory containing the address. The same user is being imported multiple times (only possible when multi sync mode is enabled and several UIPs have been set up to import users from the same domain).

236 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 236 OF 407 Please click the User sync. report button to get the exact details regarding any skipped users: You can also inspect the Windows event viewer to get the exact details regarding any skipped users. The AD synchronization event entry will contain the details Importing Users Instead of creating each user manually you can also bulk import users into SMS PASSCODE. To perform an import, you need a comma-separated (CSV) file containing the user data. To start the import process, select Import users in the navigation menu: The Import users page contains information regarding the expected syntax of the commaseparated file. You decide yourself which data is contained in the CSV file; the first row of the file is used to define the content, i.e. this row must contain header names of the columns in the file. The remaining rows must contain data in the exact order defined by the header row.

237 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 237 OF 407 Please note, that it is also possible to initiate the import of users using a command line tool. This is especially useful if you would like to schedule an automated periodic import or synchronization of users from a comma-separated file. Please read section for more details regarding this Importing and Synchronizing Users from other Data Sources If you need to import users into the SMS PASSCODE database from another source than Microsoft Active Directory, this is possible using comma-separated files. I.e. you should export all users from your data source to a comma-separated file, and afterwards import this file into the SMS PASSCODE database. If the user export/import is a one-time task, you can simply import the comma-separated file using the SMS PASSCODE Web Administration interface (cf. section 15.11, page 236). However, if you wish to set up an automated periodic import or synchronization from a commaseparated file, you should make use of the DbAdmin command line tool. The DbAdmin tool is installed on the server hosting the SMS PASSCODE Database Service. The default path is: C:\Program Files\SMS PASSCODE\DbAdmin.exe If you run this tool without any arguments, it will display the expected syntax and valid arguments. To import users from a comma-separated file, use this syntax: DbAdmin user import csv file name Replace csv file name with the path to your comma-separated file. You can add additional arguments to obtain different behaviors. Different examples are listed below: Add new users: Import users from a comma-separated file. Any users already present in the database are not overwritten. No users are removed from the database: DbAdmin user import csv file name Add new users, overwriting existing users: Import users from a comma-separated file. Any users already present in the database are overwritten with possibly new data. No users are removed from the database: DbAdmin user import csv file name -replaceexistingusers Synchronize users: Import users from a comma-separated file. Any users already present in the database are overwritten with possibly new data. Any users present in the database, but NOT present in the comma-separated file, are removed from the database: DbAdmin user import csv file name replaceexistingusers removeusers

238 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 238 OF 407 Using the DbAdmin tool it is possible to set up a periodic custom synchronization of users from your specific data source to SMS PASSCODE. This custom synchronization will work exactly as the built-in AD Integration. To configure a custom synchronization, please proceed as follows: Schedule a periodic task, e.g. using the Windows Task Scheduler. This task should perform the following actions: a. Export the required users from the data source to a comma-separated file. b. Call DbAdmin with the generated comma-separated file as input and with the arguments shown above at Synchronize users. You can even set up multiple custom synchronizations that will work in parallel on their own subset of users, analogously to the built-in AD integration running in multi sync mode. And you can have several custom synchronizations and several AD-integrations run simultaneously. Please contact support@smspasscode.com if you would like to receive more information about this Transmitter Hosts If you plan to make use of several Transmitter services, you must authorize each such Transmitter service. Authorization is carried out by specifying the host name of each server allowed to run the Transmitter service. The procedure for this is described in the following subsection. IMPORTANT authorize before installation: Remember to authorize each Transmitter service BEFORE it is installed. If this is not observed, then the Transmitter service will shut down after installation because of missing authorization. You will then need to manually restart the Transmitter service after it has been authorized Maintaining Authorized Transmitter Servers To authorize a Transmitter server, please follow the instructions below: 1. Select the Transmitter Hosts page. 2. Click the Add new transmitter host button

239 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 239 OF On the Create a new Transmitter Host page: a. Enter the host name (or IP-address) of the server to be authorized. b. Optionally, add one or more dispatchers, such as GSM modems or dispatchers, to the new transmitter (cf. section below) you can also postpone this action until later. c. Click the Save button. 4. Now the host has been authorized and appears in the grid of authorized Transmitter servers:

240 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 240 OF 407 If you need to correct the name of the server afterwards, then click the Edit button to the right of the authorized Transmitter server. If you need to remove the authorization, then click the Delete button to the right of the authorized Transmitter server Assigning Dispatchers to a Transmitter Each authorized Transmitter server is allowed to run a single instance of the SMS PASSCODE Transmitter service, which is responsible for dispatching passcode messages to users. Each Transmitter service needs to know, which dispatching methods it is allowed to use and how it can connect to required external services and devices. E.g. it needs to know, on which COM ports GSM modems are located or where SMTP servers are located. There are two ways to assign dispatchers to a Transmitter: 1) When maintaining a dispatcher, assign it to the Transmitters allowed to use it. This is done on the respective pages for maintaining dispatchers, i.e. the pages GSM Modems, Dispatchers and Web Service Dispatchers. 2) When maintaining a Transmitter, assign the relevant dispatchers to it. This is done by clicking the Add dispatcher button while maintaining the details of a Transmitter server:

241 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 241 OF 407 A dialog will pop up, where you can select the type of dispatcher to assign: Please note that the actual choices presented to you might differ because only the dispatch types allowed according to the settings on the General settings page will be shown. By default, only SMS dispatching is allowed in this case, the popup will jump directly to the dialog for creating settings for a new GSM modem Load Balancing Hosts If you have installed any Load Balancing service on a server, you must authorize each such Load Balancing service. Authorization is carried out by specifying the host name of each server allowed to run the Load Balancing service. The procedure for this is described in the following subsection. IMPORTANT authorize before installation: Remember to authorize each Load Balancing service BEFORE it is installed. If this is not observed, then the Load Balancing service will shut down after installation because of missing authorization. You will then need to manually restart the Load Balancing service after it has been authorized.

242 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 242 OF Maintaining Authorized Load Balancing Servers To authorize a Load Balancing server, please follow the instructions below: 1. Select the Load Balancing Hosts page. 2. Click the Add new load balancing host button 3. A dialog appears where you can enter the host name (or IP-address) of the server to be authorized. Afterwards, click the Create button. 4. Now the host has been authorized and appears in the grid of authorized Load Balancing servers:

243 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 243 OF 407 If you need to correct the name of the server afterwards, then click the Edit button to the right of the authorized Load Balancing server. If you need to remove the authorization, then click the Delete button to the right of the authorized Load Balancing server GSM Modems You can connect up to 32 GSM Modems to each Transmitter service. To inform each Transmitter service which modems to initialize and use, you must add each modem to the database. Please note, that you can add and remove modems on-the-fly, e.g. you can connect more modems and create them in the database without restarting any Transmitter service which means zero downtime while reconfiguring modems. To maintain GSM Modems, go to the GSM Modems page. a. Click the Add new modem button to create a new modem. b. Click the Test button to send a test message using a specific modem. In this way you can test whether the selected modem is able to send an SMS successfully. c. Click the Edit button to edit the settings of an existing modem. d. Click the Delete button to remove a modem. The following subsection describes how to maintain the settings of a modem while creating a new one or editing an existing one.

244 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 244 OF Settings of a GSM modem When creating a new GSM Modem or editing an existing GSM Modem in the SMS PASSCODE database, the following dialog will appear: To maintain the settings of the modem, proceed as follows: a. Leave the Enabled checkbox selected if you want the modem to be active. Clear the checkbox to put the modem in a deactivated standby mode, where it will not be used for any transmissions, until it is enabled again. b. Select the Transmitter server to which the modem has been connected. c. Select the serial port to which the modem has been connected. d. Enter the PIN code for the SIM card in the GSM modem. Leave this field empty if the SIM card is not protected by a PIN code. Finally click the Ok button to commit the changes. When you create a new modem or move an existing modem to a new Transmitter or serial port, the modem will automatically be initialized on-the-fly if the Transmitter service is up and running on the specified server and the modem has been connected to the specified serial port. If you would like to verify this, then inspect the SMS PASSCODE Transmission event log on the Transmitter server, or inspect the modem monitoring page (cf. section 15.20, page 274) Removing Modems Whenever you are planning to disconnect a GSM modem from a Transmitter service, you should remove this modem from the database beforehand. This allows the Transmitter service to terminate the modem gracefully before it is disconnected. To remove a GSM modem, please follow the instructions below: 1. Select the GSM Modems page. 2. Click the Delete button to the right of the modem to be deleted. 3. Confirm the deletion. 4. If the modem has not already been disconnected, then the modem is now automatically terminated on-the-fly (if the Transmitter service is up and running on the specified server).

245 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 245 OF 407 The modem is terminated gracefully, i.e. any queued SMS messages will be sent before the modem is terminated. If you would like to verify the modem termination, then inspect the SMS PASSCODE Transmission event log on the Transmitter server, or inspect the modem monitoring page (cf. section 15.20, page 274) Dispatchers If you are planning to send passcodes by , or to send automatic welcome s to new SMS PASSCODE users (cf. section , page 163), then you need to specify how transmission can occur. To do this, you must create one or more Dispatchers. Each Dispatcher indicates an SMTP server to use for transmission, and optionally also specifies any required authentication data. You can define any number of Dispatchers, and each Dispatcher can be assigned to any number of Transmitters. Assigning an Dispatcher to a Transmitter simply means, that the Transmitter is allowed to send s as defined by the Dispatcher in question. To maintain Dispatchers, go to the Dispatchers page: a. Click the Add new dispatcher button to create a new Dispatcher. b. Click the Test button to send a test message using a specific Dispatcher. In this way you can test whether the selected dispatcher is able to send an successfully. c. Click the Edit button to edit the settings of an existing Dispatcher. d. Click the Delete button to remove an Dispatcher. The following subsection describes how to maintain the settings of an Dispatcher while creating a new one or editing an existing one.

246 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 246 OF Settings of an Dispatcher When creating a new or editing an existing Dispatcher in the SMS PASSCODE database, the following page will appear: To maintain the settings of the Dispatcher, proceed as follows: a. Enter the IP address or host name of an SMTP server to use for sending s. b. Enter the address to be shown as the sender of all s sent by SMS PASSCODE using this dispatcher. c. Select the Transmitters that this dispatcher should be assigned to, i.e. the Transmitter servers allowed to send s using the specified SMTP server. d. Optional: Select the Explicit credentials checkbox if credentials for authentication are required to send s using the specified SMTP server. Credentials are entered as e) Username and f) Password. Finally click the Save button to commit the changes. When you create a new or edit an existing Dispatcher, the new or updated Dispatcher will be available for dispatching immediately. Use the Test button on the E- mail Dispatchers page to verify whether an Dispatcher is functioning as expected Web Service Dispatchers SMS PASSCODE A/S has chosen a specific 3 rd party web service provider as a business partner. This allows all SMS PASSCODE customers to make use of this 3 rd party web service to either send passcodes by SMS (without using a GSM modem) or to distribute passcodes by voice calls. To make use of the 3 rd party web service, you need to sign up for an account at the service provider (cf. section , page 122). If you are planning to send passcodes by web service SMS or distribute passcodes by voice calls, then you need to specify the account details provided to you by the web service provider. To do

247 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 247 OF 407 this, you must create a Web Service Dispatcher, which basically defines the account details necessary for contacting the 3 rd party web service and being authorized to use it. Normally you will only create one Web Service Dispatcher, however you are allowed to create more, in case you have signed up for multiple web service provider accounts (e.g. if you are a hosting partner). Each Web Service Dispatcher can be assigned to any number of Transmitters. Assigning a Web Service Dispatcher to a Transmitter simply means, that the Transmitter is allowed to dispatch passcodes using the 3 rd party web service using the specified account details. To maintain Web Service Dispatchers, go to the Web Service Dispatchers page. This page is only available if you have allowed voice calls or Web Service SMS on the General Settings page. a. Click the Add new Web Service dispatcher button to create a new Web Service Dispatcher. b. Click the Test button to send a test SMS message using a specific Web Service Dispatcher. In this way you can test whether the selected dispatcher is able to connect to the web service successfully. Voice calls cannot be tested, but should work when the SMS dispatching works. c. Click the Edit button to edit the settings of an existing Web Service Dispatcher. d. Click the Delete button to remove a Web Service Dispatcher. The following subsection describes how to maintain the settings of a Web Service Dispatcher while creating a new one or editing an existing one.

248 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 248 OF Settings of a Web Service Dispatcher When creating a new or editing an existing Web Service Dispatcher in the SMS PASSCODE database, the following page will appear: To maintain the settings of a Web Service Dispatcher, you must have the account details available provided to you by the web service provider. Proceed as follows: a. Enter a unique name of own choice to identify the Web Service Dispatcher. b. Enter the Customer ID assigned to you from the web service provider. c. Enter the Authentication ID assigned to you from the web service provider. d. Select the Transmitters that this dispatcher should be assigned to, i.e. the Transmitter servers that are allowed to use the 3 rd party web service using the specified web service account details. Finally click the Save button to commit the changes. When you create a new or edit an existing Web Service Dispatcher, the new or updated Web Service Dispatcher will be available immediately for sending web service SMS or performing voice calls. Use the Test button on the Web Service Dispatchers page to verify whether a Web Service Dispatcher is functioning as expected.

249 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 249 OF GSM Modem Groups All GSM modems created in the database can be grouped into modem groups. The modem groups are maintained on the Modem Groups page. Please notice, that this page is only available when at least one Load Balancing Host has been authorized. This is due to the fact that modem groups are only useful when using Load Balancing servers and Load Balancing Policies, because modem groups are used by Load Balancing Rules to restrict the load balancing to subsets of all modems in specific circumstances. E.g. you can group the modems according to country location or GSM service provider. To maintain modem groups, go to the Modem Groups page: a. Click the Add new modem group button to create a new modem group. b. Click the Edit button to edit a modem group. c. Click the Delete button to delete a modem group. NOTE: The built-in modem group All modems is a dynamic group which will always contain all modems currently created in the database. You cannot edit or delete this modem group. IMPORTANT: Please note when deleting a modem group that all Load Balancing Rules referring to this modem group will be deleted as well. The following subsection describes how to maintain a modem group while creating a new one or editing an existing one.

250 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 250 OF Maintaining a Modem Group When creating a new or editing an existing modem group in the SMS PASSCODE database, the following dialog appears: To maintain the modem group, proceed as follows: a. Enter a unique name identifying the modem group. b. Select the checkboxes next to all the modems that should be members of the modem group. Finally click the Create or Save button to commit the changes. Any changes to an existing modem group will immediately be pushed to all Load Balancing services, thereby being taken into account on-the-fly.

251 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 251 OF Load Balancing Policies Load Balancing Policies (LB Policies) allow for advanced load balancing and failover of passcode messages. You can create any number of independent LB Policies, thereby assigning different sequences of LB Rules to different users. LB Policies are usually statically assigned to users via User Group Policies (UGPs), but it is also possible dynamically to allocate different LB Policies depending on the context of a specific user login this is an advanced feature called Contextual Message Dispatching (cf. section , page 187 ). A LB Rule specifies the type of dispatching to use for transferring a message to a user. E.g. a LB Policy could first send a passcode by SMS to a user, but if not entered within an expected time limit, perform a voice call instead and read the passcode aloud. Another example could be to send passcodes by for users having a specific mobile number prefix. LB Policies are maintained on the Load Balancing Policies page. This menu item is only available when at least one Load Balancing Host has been authorized (since LB Policies are used by Load Balancing services only): a. Click the Add new Load Balancing Policy button to create a new LB Policy. b. Click the Edit button to edit a LB Policy. c. Click the Delete button to delete a LB Policy. NOTE: The built-in Default Load Balancing Policy is a special policy, which is assigned to User Group Policies and users by default. You can edit, but not delete this policy. IMPORTANT: Please note when deleting a LB Policy that all User Group Policies, users and Authentication Policies referring to this LB Policy will be set to refer to the Default Load Balancing Policy instead. The configuration of LB Policies is very flexible and allows for many different setups. The following subsections describe in detail, how LB Policies are configured and maintained. First section explains the overall idea of having a sequence of LB Rules. Then section explains how to maintain LB Policies, i.e. create new ones or edit existing ones. In

252 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 252 OF 407 particular, subsection explains how to maintain the sequence of LB Rules of a LB Policy. At last, section lists some examples on the usage of LB Policies Load Balancing Rule Sequence Each LB Policy defines a sequence of prioritized LB Rules, e.g. a specific sequence could consist of LB Rules 1 to 5. Whenever a Load Balancing service is receiving an authentication request, it will evaluate the sequence of LB Rules to determine the action to be taken. The sequence is always evaluated in strict order from the first to the last rule. I.e. if the sequence consists of n LB Rules, then the rules are evaluated in this order: LB Rule 1 LB Rule 2 LB Rule 3 LB Rule n-1 LB Rule n The Load Balancing service will stop the evaluation of the sequence as soon as the first matching LB Rule is found. I.e. the LB Rule sequence can be seen as an if-then-else chain: IF LB Rule 1 applies THEN use LB Rule 1 ELSE IF LB Rule 2 applies THEN use LB Rule 2 ELSE IF LB Rule 3 applies THEN use LB Rule 3 ELSE IF LB Rule n-1 applies THEN use LB Rule n-1 ELSE use LB Rule n Please note, that the last LB Rule of the sequence will always be a built-in default LB Rule that applies to all authentication requests. This is to ensure, that every authentication request is handled even though no other LB Rule of the sequence would apply. The possibilities using LB Rules are very wide-ranging. You can create any number of LB Rules and you can re-arrange the order of them as needed afterwards.

253 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 253 OF Settings of a Load Balancing Policy When creating a new or editing an existing LB Policy in the SMS PASSCODE database, a tab control is shown for configuring the different settings of the LB Policy. The settings are divided into 2 tabs: a. Basic Settings Settings for identifying the LB Policy b. Load Balancing Rules The sequence of LB Rules specifying the Load Balancing behavior of the LB Policy. The different settings are described in detail in the following subsections. When making changes to a LB Policy please remember to click the Save button at last to store the changes permanently. Otherwise, all changes will be lost.

254 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 254 OF LB Policy: Basic Settings This section describes the settings available on the Basic Settings tab while maintaining a LB Policy. The Basic Settings are only used for identifying and describing the LB Policy: Setting (a) Name (b) Description Explanation A unique name identifying the LB Policy. This entry is mandatory. Optional description of the LB Policy, for your own records. Here you can describe the purpose of the LB Policy.

255 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 255 OF LB Policy: Load Balancing Rules This section describes the Load Balancing Rules tab, where you can maintain the sequence of Load Balancing Rules of a LB Policy. a. Click the Add new rule button to add a new LB Rule to the sequence. b. Click the Edit button to edit the settings of a LB Rule. c. Click the Delete button to remove a LB Rule from the sequence. d. To re-arrange the order of the LB Rules: Click the title bar of a LB Rule without releasing the mouse button, and drag the LB Rule to a new position in the sequence. Release the mouse button to drop the LB Rule in the new position. Please note, that you can make any number of changes to the LB Rule sequence without affecting any current behavior. No changes will take effect until you click the Save button. I.e. as long as the Save button has not been clicked, you can undo all changes by leaving the page without clicking the Save button. However, when clicking the Save button, all changes are immediately pushed to all Load Balancing services on-the-fly and will take effect immediately.

256 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 256 OF Settings of a LB Rule This section describes how to maintain the settings of each individual LB Rule in the LB Rule sequence of a LB Policy. When creating a new or editing an existing LB Rule, the following dialog appears: Setting Explanation (a) Enabled This checkbox specifies whether the LB Rule is enabled (active). If you clear this setting, the LB Rule will be skipped during evaluation. This might be useful for temporary de-activation of the LB Rule. (b) Description Optional informative text for your own records. You can use it to describe the purpose of the LB Rule.

257 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 257 OF 407 Setting Explanation (c) Pre-condition This setting specifies whether the LB Rule should be applied to an incoming authentication request. The following options are available: i. Always apply this rule: Select this option if the LB Rule should be valid for all incoming authentication requests. ii. Only apply this rule, if the phone number: Select this option if the LB Rule should only be valid for authentication requests from users having a phone number matching the specified condition. E.g. you can specify a LB Rule, which will only be applied to users with phone numbers starting with a specific international phone number prefix, e.g. +1. If secondary phone numbers have been enabled on the General Settings page, then the phone number used for matching the pre-condition is determined by the value of option (g) below. I.e. if option (g) is set to the primary phone number, then the user s primary phone number is used for matching, and if option (g) is set to the secondary phone number, then the user s secondary phone number is used for matching. Please note, that although an authentication request passes the specified precondition, the LB Rule might still be skipped due to other settings of the LB Rule. (d) (e) Dispatcher target Dispatcher target (advanced settings) Specifies the dispatchers allowed for sending the passcode to the user. If the dispatching type is set to SMS, then you can furthermore select a modem group, thereby restricting the actual modems allowed to be used for the transmission. If you are selecting a different dispatching type, then you can select the specific dispatcher allowed for sending the passcode, i.e. a specific Dispatcher or Web Service Dispatcher. The selected dispatcher will then be allowed for transmission from any Transmitter service that it has been assigned to. Use next rule that applies, if dispatch fails: When this option is checked, and all allowed dispatchers are unavailable for some reason, the Load Balancing service will skip this LB Rule, continue the evaluation of the LB Rule sequence and look for the next LB Rule that applies to the current authentication request. In this way, you can select a prioritized dispatch target (e.g. modem group or SMTP server) to be used by default, but still have a different dispatch target in another LB Rule for failover. When this option is NOT checked, and all allowed dispatchers are unavailable for some reason, authentication will fail and logging on will not be possible. Use next rule that applies, if the shortest queue length exceeds: When selecting this option, you must also enter the longest acceptable queue length. The Load Balancing service will skip this LB Rule, continue the evaluation of the LB Rule sequence and look for the next LB Rule that applies to the current authentication request, whenever the current queue length of all allowed dispatchers exceeds the specified longest acceptable queue length. In this way, you can select a prioritized dispatcher target to be used by default, but still have a different one in another LB Rule for periods of high loads on the default dispatcher. When this option is NOT checked, the allowed dispatchers according to the selected dispatch target will always be used, irrespective of the current queue lengths.

258 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 258 OF 407 (f) Setting If passcode expires Explanation This setting specifies the behavior when a passcode has expired. i. Authentication fails (default): Select this option if the authentication should fail when the passcode has expired. This is the default behavior. ii. Send new passcode using the next rule that applies: When this option is selected and a passcode expires during an authentication attempt, the Load Balancing service will continue the evaluation of the LB Rule sequence and look for the next LB Rule that applies to the current authentication request. When the next valid LB Rule has been determined, a new passcode is generated for the same authentication session. This might be useful for automatic failover in the rare event of transmission problems or e.g. if the user uses two (mobile) phones for different purposes. E.g. if a passcode expires, a new passcode could automatically be sent using a different dispatch target or a new passcode could be sent to the user s secondary phone number. (g) Phone number Select, whether the OTP should be sent to the user s primary or secondary phone number. If the secondary phone number is selected, then the LB Rule will be skipped for all users, who have not been assigned a secondary phone number. Please note: This option is only available if secondary phone numbers have been enabled on the General Settings page. (h) Passcode lifetime This setting specifies the lifetime of the passcode (i.e. the duration before the passcode expires). i. Determined by passcode policy: Select this option to use the default passcode lifetime defined by the Passcode Policy assigned to the user. ii. Use custom duration: Select this option if you would like to override the default passcode lifetime and enter a passcode lifetime of own choice (allowed range: seconds). E.g. when configuring a second passcode to be sent when the first passcode expires, it might be desirable to lower the lifetime of the first passcode. (i) Use the arrow buttons to step to the previous or next LB Rule in the LB Rule sequence (the arrow buttons are only available when editing an existing LB Rule, not when creating a new one). Click Ok to apply the changes to the LB Rule, or Cancel to undo any changes. Please remember, that you still need to click the Save button to commit all changes to the database.

259 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 259 OF LB Rule Summaries When maintaining a sequence of LB Rules, the Load Balancing Rules tab will by default only display the Description of each rule:

260 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 260 OF 407 However, you may select the Show summaries checkbox to get a short summary of each LB Rule: Load Balancing Policy Examples This section shows different examples on how LB Policies can be applied usefully. Example 1 (Prefix Load Balancing): A large enterprise has acquired 8 GSM modems which are distributed between 4 different countries (2 modems at each location): United States, United Kingdom, Germany and France. A SIM card from a national GSM service provider has been inserted into each GSM modem. Users from all 4 countries are logging into a Citrix Web Interface. To provide the most efficient SMS transmission and to lower the SMS transmission costs, it is desirable, that a modem is selected for each transmission that uses a SIM card with the same international mobile number prefix as the SIM card of the user requesting the SMS. This is also called prefix load balancing. To achieve this, you should proceed as follows: 1. Create 4 modems groups, one for each Country. E.g. you could call the modem groups US, UK, DE and FR. For each modem group, assign the two modems located in the corresponding country. 2. Create a LB Policy containing a sequence of 5 LB Rules (the last one being the built-in default LB Rule):

261 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 261 OF 407 Load Balancing Rule #1 Configuration #2

262 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 262 OF 407 Load Balancing Rule #3 Configuration #4

263 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 263 OF 407 With these LB Rules in place, each SMS passcode will be sent using a modem from the same country as the user, as long as both modems of the country are available and have a short queue with 5 pending messages at most. Otherwise, the built-in default LB Rule will take over, i.e. the message will be load balanced between all available modems, including the modems located in the other countries. Example 2 (GSM service provider failover): A company has acquired 4 GSM modems. Two of the modems are equipped with SIM cards from GSM service provider A, while the other two modems are equipped with SIM cards from GSM service provider B. Below, the modems are called Provider A and Provider B modems, respectively. By default, all passcodes should be sent using the Provider A modems and all users have been assigned mobile phones with SIM cards from GSM service provider A. However, in case of any problems with Provider A, the Provider B modems should be used instead. This means that if the Provider A modems are unavailable or cannot send any SMS, or if the users do not receive any SMS from Provider A, then the system should failover to the Provider B modems. Selected important users have also been given SIM cards from GSM service provider B. The SMS passcodes should be sent to the Provider B mobile number in the failover situation. In this way, GSM network failover is realized at both the sending and receiving end. To achieve this, you should proceed as follows: 1. Create 2 modem groups, one called Provider A and one called Provider B. For each modem group, allocate the two modems with SIM cards from the corresponding GSM service provider. 2. Create a LB Policy containing a sequence of 3 LB Rules (the last one being the built-in default LB Rule): Load Balancing Rule #1 Configuration

264 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 264 OF 407 Load Balancing Rule #2 Configuration Authentication Monitoring The Authentication Monitoring page is used to monitor all authentication attempts, i.e. any attempts of any SMS PASSCODE user to authenticate against any SMS PASSCODE protected authentication client. The page can be used for several purposes: Retrospective inspection of past authentication attempts, e.g. for purposes of reporting, analysis or security review. Extensive filtering options provide many ways to inspect the registered attempts. Live inspection of current authentication attempts, e.g. in case of troubleshooting. Export of authentication attempts to CSV or XML files, e.g. for further analysis by 3 rd party analysis systems. Again, the extensive filtering options let you export exactly the data needed. NOTE: The Authentication Monitoring page is only available when Authentication Monitoring has been enabled on the General Settings page (cf. section , page 115).

265 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 265 OF 407 Initially, when entering the Authentication Monitoring page, it will show all Live Data in a grid ordered descending by date and time, i.e. showing the most recent authentication attempts at the top: Live Data means authentication attempts stored in the internal SMS PASSCODE database, i.e. not including any archived authentication attempts. The monitoring page provides several useful features: a. Click the Select columns button to change the actual columns shown in the monitoring grid. E.g. add the Note column, if you would like to see the reasons of failed authentication attempts. b. Click the Set filter button to define row filtering conditions. E.g. define a filter only showing rows of failed attempts, only rows for a specific user, only rows for a specific date interval or only rows with attempts originating from a specific country (in case Geo-IP has been enabled). c. Click the Export button to export all data currently shown in the grid to a CSV or XML file, e.g. for purposes of reporting or further analysis.

266 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 266 OF 407 d. Click the Data Source drop-down to switch between displaying Live Data or Archived Data in the monitoring grid. e. Click the Refresh now button to update the monitoring grid, displaying any new data that might have appeared in the meantime. f. Select the Auto-Refresh checkbox to make the grid refresh its data automatically by a fixed time interval. This might be useful in case of troubleshooting. g. Click the Show link of any authentication attempt to display the full details of the entry. h. Click the Show logins on map button to plot all data currently shown in the grid on a world map ( geo mapping ). Some of these features are described in more detail in the following subsections Column Filtering Whenever a new authentication attempt is recorded in the SMS PASSCODE database, many useful details about the attempt are stored. The authentication monitoring grid only shows a small subset of these details. You can see all details of any authentication attempt by clicking on the Show link to the left of the row in question.

267 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 267 OF 407 Alternatively, you have the option of customizing which columns to show in the grid. To achieve this, click the Select columns button at the top of the page: A dialog for selecting the columns to show in the grid will appear: Select or clear the checkbox to the left of an attribute to make it appear or disappear in the grid, respectively. Select the checkbox All to make all columns appear in the grid. The individual attributes are described in the table below: Attribute Login Successful When Explanation Specifies whether the authentication attempt succeeded or failed. In case of a failed authentication attempt, inspect the Note attribute to realize the exact reason of failure. Specifies the date and time of the authentication attempt.

268 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 268 OF 407 Attribute User ID User (Display Name) User (SAM) User (UPN) User (Full name) Authentication server IP Client type Client IP End-user IP Explanation Specifies the unique ID of the end-user that attempted authentication. The unique ID is used internally by the SMS PASSCODE database. In case a user has been imported into the SMS PASSCODE database from an AD using a User Integration Policy, then the ID will be equal to the user s Security ID (SID) in the AD. Shows the most exact name of the end-user that attempted authentication, depending on the fact which part of the user s name is known by the SMS PASSCODE database (full name, SAM, UPN). Shows the SAM account name of the end-user that attempted authentication. Empty, if the SAM account name of the user is not known. Shows the UPN of the end-user that attempted authentication. Empty, if the UPN of the user is not known. Shows the full name of the end-user that attempted authentication. Empty, if the full name of the user is not known. Specifies the IP address of the SMS PASSCODE server that actually determined, whether the authentication attempt was successful or not. Depending on your setup, this will either be the IP address of a server hosting an SMS PASSCODE Load Balancing Service, or the IP address of a server hosting an SMS PASSCODE Transmitter Service. Specifies the type of client that the end-user attempted to log in to. E.g. Citrix Web Interface, RADIUS or Windows Logon. Specifies the IP address of the SMS PASSCODE protected authentication client that the end-user attempted to log in to. For example, the IP address of an SMS PASSCODE protected RADIUS server, or the IP address of an SMS PASSCODE protected OWA site. Specifies the IP address of the end-user that attempted authentication. Note: This attribute is only available, if Geo-IP and IP history has been enabled on the General Settings page (cf. section , page 113). Country Specifies the country that the end-user attempted to log in from, determined from the end-user IP using Geo-IP. Note: This attribute is only available, if Geo-IP and IP history has been enabled on the General Settings page (cf. section , page 113). Organization Specifies the organization that the end-user attempted to log in from, determined from the end-user IP using Geo-IP. Note: This attribute is only available, if Geo-IP and IP history has been enabled on the General Settings page (cf. section , page 113).

269 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 269 OF 407 Attribute Passcode type OTP Dispatch Type OTP Dispatch Target Authentication policy Note Explanation Specifies the type of passcode that the end-user was using during the authentication attempt. Possibly values are: Session-specific OTP Token OTP Personal Passcode MFA bypassed 32 In case a one-time passcode was used during authentication, then this attribute specifies how the OTP was dispatched to the user. Otherwise, the attribute is empty. Possibly values are: GSM SMS Web Service SMS Voice call In case a one-time passcode was used during authentication, then this attribute specifies where the OTP was sent to. In case the OTP was dispatched as an SMS or voice call, then the attribute will show the actual phone number that the OTP was sent to; in case it was sent by , then the attribute will show the e- mail address that the OTP was sent to. Specifies the name of the Authentication Policy and the rule number of this policy that was applied during the authentication attempt. Specifies the reason for a failed authentication attempt, e.g. due to incorrect password or incorrect passcode, or because the user was locked out beforehand. Empty, if authentication succeeded Row Filtering Row filtering allows you to restrict the monitoring grid to only show a subset of all registered authentication attempts. The row filter is defined by one or more conditions only authentication attempts fulfilling these conditions will then be shown in the grid. If you specify several conditions in the row filter, then the conditions are combined into an AND-filter, meaning authentication attempts are hidden from the grid unless they fulfill all conditions of the filter. 32 Multi-factor authentication can be bypassed only if bypassing has been allowed on the General Settings page. In this case, bypassing might occur due to two different reasons: Either because PoC Mode has been enabled, or because bypassing was determined by an Authentication Policy.

270 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 270 OF 407 Conditions are set by clicking the Set filter button: Row filters can be used for many purposes. Here are a couple of examples: Show only authentication attempts that failed Show only authentication attempts of a specific user Show only authentication attempts from a specific period Show only attempts to log in to a specific type of client Show only attempts to log in to an authentication client with a specific IP address Show only attempts to log in from a specific end-user IP address (or IP address scope) Show only attempts to log in from a specific country or organization Show only authentication attempts using a specific type of passcode or a specific type of OTP dispatching And since these filter examples can be combined in any way you are given great flexibility for analyzing the authentication attempts in your organization Exporting Data As explained in the two previous sections about column and row filtering, you are able to customize the monitoring grid to show exactly the authentication attempts that you would like to inspect. When you have completed such filtering, you have the additional option to export the specific data shown in the grid, e.g. for further analysis in a 3 rd party tool like Microsoft Excel, where you could create pivot tables or pivot charts from the data. To initiate export of the current data of the grid, please click the Export button.

271 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 271 OF 407 The following dialog will appear: Fill out the settings in the dialog and click the Ok button, to execute the export. Otherwise, click the Cancel button to abort the export. The settings in the dialog are described in the table below: Setting Explanation (a) File format Select whether to export data to a CSV or XML file. (b) Filename Specify the name of the file containing the exported data. (c) Export limit Optionally enter a record limit. If a number x is entered, then only the x topmost rows of the grid are exported. Otherwise, all rows of the grid are exported Switching Data Source By default, the monitoring grid will display Live Data, i.e. authentication attempts stored internally in the SMS PASSCODE database, as opposed to archived data. Use the Data Source drop-down to switch between Live Data and Archived Data:

272 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 272 OF 407 When switching to Archived Data, the grid will instead display data from the current archive of authentication attempts, as defined by the current archiving settings on the General Settings page (cf. section , page 115). First, a dialog will appear, asking you to select the period of archived data to display: It is recommended not to import data of a longer period than really required, since importing a huge amount of archived authentication attempts can take a while. When you have selected the required period, the corresponding archived data is retrieved from the archive and displayed in the grid. You have now exactly the same options for performing column and row filtering, plotting data on a world map or exporting data, similar to the situation of displaying Live Data Geo-mapping The Geo-mapping feature allows you to visualize the authentication entries of the Authentication Monitoring page on a world map. When activating the feature, it will map the authentication entries currently shown on the Authentication Monitoring page. This means that you may apply row filtering and/or switch data source first, thereby allowing you to select the exact data to be visualized on the world map. For example you could visualize login attempts for a specific period, a specific user and/or a specific type of authentication client; furthermore you may visualize all attempts, or only failing attempts. Note: The geo-mapping feature only allows visualization of login attempts where the end-users IP address was collected. Otherwise, required geo-ip information is not available for mapping the entry.

273 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 273 OF 407 Once the desired login attempts for geo-mapping have been selected, click the Show logins on map button to actually perform the visualization of the entries on a world map: A world map will appear with each country colored according to the number of login attempts from the country (darker color means more login attempts). The following features are available on the world map: a. Click on any country to get the exact login statistics for this country. b. To navigate the map, you can click the +/- buttons at the upper left corner to zoom in and out, respectively. When zoomed in, you can drag the map by holding the mouse-button down. c. Alternatively, you can zoom into specific regions of the world map using the dropdown list in the upper left corner. The entry Fit will zoom in to the world map as much as possible, while still showing all countries with at least a single login attempt according to the currently selected data on the Authentication Monitoring page.

274 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 274 OF Modem Monitoring The Modem Monitoring page is used to monitor all GSM modems. The page is dynamically updated to show the live status of every GSM modem attached to the SMS PASSCODE infrastructure. The modem monitoring page displays 3 sections of information for each GSM modem: a. Modem device information: The COM port that the modem is attached to Modem description (modem type and revision number) The IMEI number of the GSM modem b. Modem state information: Status: Current status of the modem (should be Ready or Sending under normal circumstances) Queue length: The current number of queued messages for the modem. This number should be close to 0. If this number increases periodically, this could indicate that too few modems have been assigned to handle the load. Signal strength: The currently detected GSM signal strength. SIM ID: A unique identifier for the SIM card inserted into the modem. Operators: Click the hyperlink Show to display a list of detectable operators. Please note, that retrieval of the opeator list can take up to 1 minute and will delay any queued messages. c. Transmission statistics: Started: The date and time the modem thread was started the last time. # Successful transmissions: The number of successfully transmitted messages since the modem thread was started # Failed transmissions: The number of failed message transmissions since the modem thread was started

275 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 275 OF 407 # Modem initializations: The number of attempted modem initializations since the modem thread was started. Should be 1 under normal circumstances. If this number is large, then the modem is being re-initialized periodically which could indicate GSM network problems, e.g. a weak GSM signal strength. Avg. transmission time: The average time per transmission measured since the modem thread was started. 16 SELF SERVICE WEB SITE The SMS PASSCODE Self Service Web Site is an optional component. When installed, endusers can log into this web site to inspect or maintain settings regarding their own SMS PASSCODE user account. It is only recommended to install the Self Service Web Site, if you are planning to let some or all of your end-users maintain SMS PASSCODE user account data themselves Examples of Usage The SMS PASSCODE Self Service Web Site can be very useful in a number of different scenarios. For example: Initially, when installing SMS PASSCODE for the first time you will need to have access to the (mobile) phone numbers of your end-users. If these phone numbers are already stored in your AD, or in a CSV file, you can simply make use of SMS PASSCODE AD Integration, or import the data from the CSV file, respectively. However, if the phone numbers are not registered anywhere yet, you can decide to let the end-users enter their phone numbers by themselves using the SMS PASSCODE Self Service Web Site. Let new end-users register their phone numbers by themselves. Let end-users maintain their phone numbers in case they get a new phone number. Let end-users change the dispatch type by themselves. E.g. you can let your users select by themselves, whether they want to receive passcodes by SMS, or voice call. Let end-users enter a personal passcode. A personal passcode can be used for authentication in case of emergency or to reset the user s AD password using the SMS PASSCODE Password Reset Module. Let end-users enroll their tokens by themselves (in case you are making use of tokens, e.g. OATH software tokens or USB Keys). Let end-users maintain their private (secondary) mobile number or private address, in case these are used for failover scenarios. As can be seen, the Self Service Web Site allows for a lot of end-user flexibility. As an administrator you can control in detail, whether you want to provide this flexibility to your endusers, and what permissions you want to grant them. You can control in detail: Who is allowed to access the Self Service Web Site? What settings is each user allowed to change? This is controlled using User Group Policies settings (cf. section , page 161), but can also be set on each individual user by overriding the UGP settings (cf. section , page 227).

276 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 276 OF Auto s To access the SMS PASSCODE Self Service Web Site your end-users will need to know the URL to use. An easy way to provide this is to use the SMS PASSCODE auto feature. This feature allows sending welcome s automatically to any new end-users (cf. section , page 163). Among other, these s will include the URL that the users should use to log in to the Self Service Web Site. The auto feature also allows sending automatic reminder s to your end-users, if they should forget to log in to the Self Service Web Site and enter any data defined as required by the system administrator (cf. section , page 161) Customizing Auto s The automatic welcome s and reminder s sent by SMS PASSCODE can be customized, in case you have any specific requirements regarding their content or layout. To customize the auto s you need to edit the auto template files. Please note, that this is an advanced topic and requires knowledge about XML and HTML. The template files are located on the server where the SMS PASSCODE Database is installed. The default location of the folder containing the files is: The folder contains two files: C:\Program Files\SMS PASSCODE\Templates Welcome Template.xml Template file for welcome s Remainder Template.xml Template file for reminder s By editing any of these xml files using a text editor you can customize the layout and content of the auto s. You must restart the SMS PASSCODE Database service, before any changes to the template files takes effect. If you have any further questions regarding template file customization, please contact your SMS PASSCODE reseller or support@smspasscode.com.

277 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 277 OF Data Updates When a user changes any personal settings in the Self Service Web Site, the changes are either written back to the SMS PASSCODE database, or written directly back to the AD that the user belongs to. The following rules determine, where any update will be written to: If a user has been created manually in the SMS PASSCODE database, then any changes made by the user will be written to the SMS PASSCODE database, since the user is not part of any AD synchronization in this case. If a user has been imported from an AD by the SMS PASSCODE AD Integration feature, using User Integration Policies (cf. section 15.5, page 127), then the following rules apply: o Any data not imported from the AD, will be updated in the SMS PASSCODE database, in case the user changes any such data. Examples of this are: Dispatch type, SMS type and user attributes set to Do not import in the user s User Integration Policy (cf. section , page 134). o Any data imported from the AD, will be updated directly in the AD, in case the user changes any such data. The user attributes imported from AD, are the ones defined as Import from attribute(s) in the user s User Integration Policy (cf. section , page 134). When changes are saved directly to the AD please note that there might be a delay until the changes are reflected in the SMS PASSCODE database (the changes will be imported into the SMS PASSCODE database on the next synchronization run of the User Integration Policy in question) Security Concerns The SMS PASSCODE Self Service Web Site is installed on TCP port 3000 by default, but you can also select any other TCP port during the installation. You should NOT make the Self Service Web Site available from outside your firewall. It is only recommended to make the site available on your internal network, since you could otherwise compromise 33 the multi-factor authentication security provided by SMS PASSCODE. If you insist to make the Self Service Web Site available from outside your firewall, then please ensure that it is well-protected, e.g. by configuring it to use 33 The security could be compromised, in case a hacker would gain access to the Self Service Web Site and could change the phone number of a user. This would in fact eliminate the essential part of the multi-factor authentication of the user.

278 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 278 OF 407 Integrated Windows Authentication and protecting it with SMS PASSCODE multi-factor authentication using the SMS PASSCODE IIS Web Site Protection component. WARNING: It is NOT recommended to publish the SMS PASSCODE Self Service Web Site and make it public available. In case you follow the recommendation above and do not publish the SMS PASSCODE Self Service Site to be publicly available, you might not need to be concerned about the network communication to and from the Self Service Web Site, depending on your trust in the internal network. Nevertheless, in case you have any concerns regarding the network communication, you can take advantage of the following information: Referring to section 16.3 above, the Self Service Web Site will write any data updates either directly to the SMS PASSCODE database and/or to the AD. o Network communication with the SMS PASSCODE database is always encrypted (using strong AES 256bit encryption). o Network communication with the AD is encrypted using SSL/TLS, only if the corresponding user has been imported into the SMS PASSCODE database using a User Integration Policy with the setting Encrypt communication using SSL enabled (cf. section , page 132). Network communication between the end-user and the Self Service Site is only encrypted, in case you install an SSL certificate on the Self Service Web Site and enforce HTTPS for the site. It is definitely recommended to do so, in case you are planning to use form-based authentication (cf. next section).

279 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 279 OF Authentication The SMS PASSCODE Self Service Web Site uses Integrated Windows Authentication (IWA) by default, but can also be configured to use form-based authentication (FBA). IWA is required if you plan to protect the Self Service Web Site by SMS PASSCODE multi-factor authentication using the SMS PASSCODE IIS Web Site Protection component. When using IWA, depending on the web browser type and configuration, the browser will either show a built-in logon dialog, or log in the user automatically using single sign-on. When using FBA, a logon form is shown in the web browser for authentication: You must edit the web.config file of the Self Service Web Site to configure, whether the Self Service Web Site should use IWA or FBA. The default location of this file is: C:\Program Files\SMS PASSCODE\Web\SelfService\web.config

280 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 280 OF 407 In this file, search for the tag <system.web>. Within this tag another tag of type <authentication mode= > controls the type of authentication: Activating IWA: <authentication mode="windows" /> Activating FBA: <authentication mode="forms"> </authentication> <forms loginurl="login.aspx" protection="all" timeout="30" name="smspasscodeprotectionauth" enablecrossappredirects="false" defaulturl="main.aspx"/> You need to remove or comment out the part that should NOT be used. Commenting out is done by putting the characters <!-- and --> around the part to be commented out. IMPORTANT: When using IWA for the SMS PASSCODE Self Service Web Site, it is required to enable delegation from the server hosting the SMS PASSCODE Self Service Web Site to all domain controllers that the Self Service Web Site might communicate with. Please read section below for details, how to set up delegation. IMPORTANT: When using FBA for the SMS PASSCODE Self Service Web Site, it is recommended to protect the web site using an SSL certificate and only allow access to the site using SSL (HTTPS). This is to ensure that user names and passwords are always sent encrypted across the network. IMPORTANT (multi-domain infrastructure) Please note the following for multi-domain scenarios (using child domains and/or trusted domains): When using FBA, an SMS PASSCODE Self Service Web Site supports authentication of users from multiple domains. When using IWA, an SMS PASSCODE Self Service Web Site only supports authentication of users from the domain that the web site host is a member of.

281 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 281 OF Configuring Authentication Delegation When the Self Service Web Site is configured to use Integrated Windows Authentication (IWA), and users have been permitted to make changes that are written directly back to the AD, then the Self Service Web Site needs to be able to forward the authentication context of the user to any of the domain controllers in question. To be able to do so, the server hosting the SMS PASSCODE Self Service Web Site must be authorized to allow delegation. Delegation is allowed by editing the computer account of the Self Service Web Site server in the AD: 1. In the AD locate the computer account of the server hosting the SMS PASSCODE Self Service Web Site. 2. Right-click the computer account and select Properties. 3. Select the Delegation tab 34 : 4. Select Trust this computer for delegation to specified services only, and select either Use Kerberos only (this will only allow domain members with Internet Explorer to access the Self Service Web Site) or Use any authentication protocol: 34 If the Delegation tab is missing, then the domain functional level needs to be upgraded to at least level Windows Server 2003 (please read for more details).

282 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 282 OF Now click the Add button to add all relevant domain controllers, that the server is allowed to delegate authenticated users to: 6. On the dialog Add Services, click the Users or Computers button:

283 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 283 OF On the Select Users and Computers dialog, enter all relevant domain controllers of the AD site, separated by semi-colons, and then click the OK button: 8. When returning to the Add Services dialog, select all ldap protocols of the servers in the list (there will be two entries per server), and click the OK button.

284 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 284 OF On the Properties dialog click the OK button: 10. Delegation has now been configured. NOTE: In order for the delegation changes to take effect on the Self Service Web Site server immediately, either reboot the Self Service Web Site server, or alternatively run the following command on the server: gpupdate /force

285 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 285 OF Localization When an end-user accesses the SMS PASSCODE Self Service Web Site, the site will be displayed in a localized language according to the current language settings of the end-user s web browser. Currently, the following localizations are supported: Czech Danish Dutch English Finnish French German Hungarian Italian Korean Norwegian Polish Romanian Russian Spanish Swedish Turkish English is used by default, if no matching localization is found.

286 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 286 OF PASSWORD RESET MODULE The SMS PASSCODE Password Reset Module allows end-users to log into a Password Reset Web Site (PRWS) to reset their own AD Password in a convenient and secure way. This makes it possible for end-users to regain access to applications or network resources, whenever they have forgotten their AD password without any need to involve internal IT personnel. In this way, the Password Reset Module can help to reduce the burden on the internal IT helpdesk. One of the strengths of the Password Reset Module is its ability to send out password reset relevant notifications. These notifications will both remind the user about the possibility to make use of the PRWS, and inform how to access it -- two very important factors for getting the most out of a password reset solution. As an administrator, you can optionally enable any of the following types of notifications: SMS PASSCODE lockout notification Notify users, when they are locked out from the SMS PASSCODE system, e.g. when they have entered a wrong password several times in a row during authentication in an SMS PASSCODE protected authentication client. AD account lockout notification Notify users, when they are locked out in AD, e.g. when they have entered a wrong password several times in a row during authentication in any non-sms PASSCODE protected application. Password pre-expiration notification Notify users a few days before their current AD password will expire. Password expiration notification Notify users when their AD password has just expired. The two first types of notifications, the lockout notifications, are especially useful, since they will be triggered in the event that a user enters a series of wrong passwords, which is a typical scenario, when a user has forgotten his password. Additionally, they increase security, since the user is informed about any unexpected lockout, e.g. in case of a brute-force-attack by a hacker. To preserve high security, access to the PRWS is protected by SMS PASSCODE multi-factor authentication by default. However, it is possible to customize the login flow of the PRWS in several ways, even allowing different login flows depending on the login context. For example, you can allow a more convenient login flow with lowered security, when the login occurs from a trusted context. Login flows are described in section 17.3 (page 289). The actual customization of login flows is accomplished on the Authentication Rules of an Authentication Policy (cf. section , page 187).

287 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 287 OF 407 Recommended User Group Policy for users accessing the Password Reset Web Site It is recommended that all users planned to make use of the SMS PASSCODE Password Reset Web Site are assigned to a UGP with the following settings: On the Notifications tab: o Specify the URL of the PRWS o Enable all notifications On the Self Service Web Site Settings tab of the UGP: o Allow access to the Self Service Web Site (SSWS) o Allow users to change their Personal Passcode in the SSWS, and set it as required data (i.e. the user is forced to set it) On the Auto tab of the UGP: o Enable auto s (to distribute the URLs of the PRWS and SSWS) o Specify the URL of the SSWS On the License tab of the UGP: o Grant Password Reset CAL Such a UGP will ensure that the users assigned to it will have a Personal Passcode ready for use, whenever they will need it to log in to the PRWS to reset their AD Password. Additionally, the notifications will remind the users about the possibility to use the PRWS, and how to access it. The SMS PASSCODE Password Reset Module consists of two components: The SMS PASSCODE Password Reset Web Site (PRWS) and the SMS PASSCODE Password Reset Backend Service (PRBS). These two components can be installed on the same server or on separate servers. The infrastructure of the Password Reset Module is described in more detail in section 17.4 (page 296) Licensing The SMS PASSCODE Password Reset Module requires separate client access licenses (CALs). IMPORTANT: Password Reset CALs required Please note, that a user must have been allocated a Password Reset CAL in order to: Access the PRWS Receive an AD account lockout notification, password pre-expiration notification or password expiration notification. The table in section 7.2, page 32, shows the exact authentication behavior for Password Reset.

288 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 288 OF Best-Practice Setup of Password Reset This section describes the best practice for setting up SMS PASSCODE when using the Password Reset module. The recommended order of actions is: 1. Open the Web Administration Interface 2. Go to the General Settings page and allow usage of Personal Passcodes (cf. section , page 119). 3. For each User Group Policy (UGP) assigned to users that should have access to Password Reset, ensure the following configuration of the UGP: a. On the Notifications tab of the UGP: i. Specify the URL of the PRWS ii. Enable relevant notifications. It is recommended to enable all of them. b. On the Self Service Web Site Settings tab of the UGP 35 : i. Allow access to the Self Service Web Site (SSWS) ii. Allow users to change their Personal Passcode in the SSWS, and set it as required data (i.e. the user is forced to set it) c. On the Auto tab of the UGP: i. Enable auto s (to distribute the URLs of the PRWS and SSWS) ii. Specify the URL of the SSWS d. On the License tab of the UGP: i. Grant Password Reset CAL Each such UGP will ensure that the users assigned to it will have a Personal Passcode ready for use, whenever they will need it to log in to the PRWS to reset their AD Password. Additionally, the enabled notifications will remind the users about the possibility to use the PRWS, and how to access it. 4. In case you enabled AD Account Lockout notifications in step 3.a above, then consider to lower the lockout threshold in the password policy of your AD 36. With AD Account Lockout notifications enabled it is actually useful that a user is locked out relatively quickly in AD, in order for the user to receive the notification. 35 You may skip this step, if you are only planning to make use of the Simple password reset flow, since personal passcodes are not required in this case (cf. section , page 298). 36 However, do not lower the lockout threshold in AD below the lockout threshold defined on the users Authentication Policies (cf. section , page 181), in case you are protecting authentication clients with SMS PASSCODE multi-factor authentication.

289 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 289 OF Workflow for Performing a Password Reset This section describes the possible login flows when accessing the SMS PASSCODE Password Reset Web Site (PRWS). Essentially, there are two different types of scenarios, when a user would like to access the PRWS: The user has forgotten his existing password (and has possibly received a lockout notification). The user has received a password pre-expiration notification or password expiration notification, and would like to renew his existing password. The user has been locked out and would like to unlock his account There is a fundamental difference between these scenarios. In the first scenario, the user has forgotten his existing password, whereas in the second and third scenario the user has most likely not forgotten his existing password. This is relevant, because when accessing the PRWS, we would like to secure access using SMS PASSCODE multi-factor authentication, which means asking the user to enter his username, existing password and a one-time-passcode. As can be seen, we have a conflict in the first scenario, since the user must enter his existing password, which he has forgotten. Consequently, the user needs another way of proving his identity. The PRWS requires that the user must enter his personal passcode instead. Therefore, to make efficient use of the PRWS, all users should register their own personal passcode beforehand using the SMS PASSCODE Self Service Web Site (cf. section 16, page 275). This can be ensured by following the best-practice setup described in section 17.2 above. The default login flow of the PRWS, which is also called the strict flow, always requires the user to enter his personal passcode to access the PRWS. This means, even in the case of a renewal of the existing password, where the user remembers his existing password, the user must still use his personal passcode for accessing the PRWS. If you would prefer a different behavior, then read on. It is possible to customize the login flow in several ways, as described below. To understand the difference between the different login flows, let us first go through the default login flow, i.e. the strict flow, and examine how a user will proceed to reset his password. Afterwards, the other login flows are described, and the differences are pointed out Strict Flow When accessing the PRWS using the strict flow, the procedure for performing a password reset is as follows: 1. First, the user opens a web browser and navigates to the PRWS. To do this, the user must know the URL of the site. One way to distribute this knowledge is to enter the PRWS URL into the User Group Policy (cf. section , page 148) and then use the auto feature to distribute it (cf. section , page 163). Additionally, the user is reminded about the PRWS URL, whenever she receives any of the notifications enabled on the User Group Policy (cf. section , page 148). Note: If the user receives the notification containing the PRWS URL on a device with a browser, the easiest way to perform a password reset is just to click the URL and access the PRWS directly on the device. The PRWS has been designed with an adaptive layout, meaning that it will automatically adapt to the actual screen resolution, including small screen resolutions as seen on mobile devices.

290 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 290 OF The PRWS opens and shows the welcome page. The user enters her user name and clicks the Next button: 3. Now the user must enter her personal passcode to prove her identity, and then click the Next button:

291 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 291 OF A one-time passcode (OTP) is sent to the user according to the policy assigned (e.g. by SMS, voice call or secure ). The user receives the OTP and enters it to complete the multi-factor authentication, then clicks the Next button:

292 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 292 OF The user has now proven her identity and is allowed to reset her password, i.e. enter a new AD password. When the new password has been entered, the user clicks the Next button: Note: At this point, the user s account is unlocked in both SMS PASSCODE and in AD, in case it was locked. In other words, if the user just wanted to unlock her account, she can just close the browser without entering a new password.

293 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 293 OF Assuming that the new AD password fulfills all password policies, the user will get a success message: (In case the new password is rejected by the AD, e.g. due to password policy restrictions, the user will be given the chance to enter a new password again, until the password reset succeeds) 7. The password has now been reset. The user can close the browser and use the new AD password Other Login Flows The previous section described the default login flow of the PRWS, called the strict flow. As an administrator you may configure the PRWS to use a different login flow. The possible flows are: Strict flow Flexible flow Simple flow

294 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 294 OF 407 In addition to this, if MFA bypassing has been allowed on the General Settings page, then you may also enable MFA bypassing on the PRWS 37. In total, this offers five different login flows to choose among: Access Strict Flow Flexible Flow Simple Flow Allow access, use MFA To authenticate, the user must enter: Username Personal passcode OTP To authenticate, the user must enter: Username Existing password or personal passcode OTP To authenticate, the user must enter: Username OTP Allow access, bypass MFA To authenticate, the user must enter: Username Personal passcode To authenticate, the user must enter: Username Existing password or personal passcode - (this combination is not allowed) Deny access Access is denied The Access and Password reset flow settings are set on the Authentication Rules of the user s Authentication Policy (cf. section , page 187). This means that you can define different login flows for different login contexts. As an example, you could use the simple flow when a user accesses the PRWS from a trusted location (e.g. internal LAN or trusted IP), and use the Strict or Flexible flow otherwise. 37 This is a new feature in SMS PASSCODE version 7.2. Previously, it was not possible to enable bypassing of MFA in the PRWS.

295 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 295 OF 407 When Flexible flow is enabled, the user will see the following page, after having entered her username on the initial welcome page: As shown, the user can in this case either enter her existing password, or alternatively click the I have forgotten my password link. If the link is clicked, then the user will jump to the page requesting the user to enter her personal passcode, similar to the strict flow. Consequently, it only makes sense to use the flexible flow, if you are expecting your users to access the PRWS using their existing password in some cases. This will normally only be the case, if you have enabled password pre-expiration or password expiration notifications. In case of the simple flow, the user can access the PRWS without entering any password or personal passcode at all, which is very convenient. However, please note that this comes at the cost of lowered security. If a user loses her device to a malicious person, this person now only needs to know the user s username to reset the password, thereby gaining access to all applications that the user has access to! SECURITY WARNING! Lowering the security for accessing the PRWS lowers the security for accessing all other applications protected by the user s AD password!

296 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 296 OF Password Reset Infrastructure As mentioned previously, the SMS PASSCODE Password Reset Module consists of two components: The SMS PASSCODE Password Reset Web Site (PRWS) and the SMS PASSCODE Password Reset Backend Service (PRBS). The PRWS is a web site that provides the frontend of the Password Reset module; i.e. it provides a user interface that allows users to walk through the workflow of changing their own AD password. Since the PRWS will typically be installed in a DMZ, at least if users are allowed to perform a password reset remotely, it makes sense to separate the web site from the actual password reset logic, which should be as well-protected as possible. Therefore, the actual password reset logic is implemented by a separate service: The SMS PASSCODE Password Reset Backend Service (PRBS). This service is responsible for performing the actual password reset actions, including communication with the relevant domain controllers.

297 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 297 OF 407 The separation of the PRWS and PRBS allows you to install the PRWS in a DMZ, while the PRBS can be installed behind the firewall (on the LAN side). An example of such a multi-server setup is shown in the following diagram: LAN DMZ GSM Modem(s) Firewall Transmission Servers SMS PASSCODE Load Balancing Service SMS PASSCODE Transmitter Service TCP 8988 TCP 8989 TCP 8888 Password Reset Backend Server SMS PASSCODE Password Reset Backend Service Password Reset Frontend Server (IIS) SMS PASSCODE Password Reset Web Site LDAP/LDAPS Active Directory Server Password Reset multi-server setup (best practice) As can be seen from this diagram, the PRWS communicates with the PRBS on a single TCP port (TCP port 8888 by default, but configurable), which must be opened from the DMZ to the LAN. The PRBS communicates with the SMS PASSCODE transmission infrastructure, either communicating directly with SMS PASSCODE Transmitter Services (TCP port 8989 by default) or

298 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 298 OF 407 through SMS PASSCODE Load Balancing Services (TCP port 8988 by default). Additionally, the PRBS is responsible for the communication with the relevant domain controllers, when performing the actual password resets, using either LDAP or secure LDAP (LDAPS), depending on the configuration in the SMS PASSCODE Configuration Tool (cf. section , page 310). The remaining part of the SMS PASSCODE backend infrastructure, e.g. the SMS PASSCODE Database service and SMS PASSCODE Web Administration Interface, is not shown in the diagram, since the PRBS does not depend directly on these components (please read section 10, page 43, for an overview regarding the complete SMS PASSCODE backend infrastructure). The diagram above illustrates the recommended setup of the SMS PASSCODE Password Reset Module. It is not required to install the PRBS on a dedicated server, i.e. you can just as well install it on one of the servers hosting any SMS PASSCODE core components. The SMS PASSCODE Password Reset Module provides full flexibility regarding the infrastructure needed, i.e. you can install it in a lot of different ways. E.g. if you wish, you can without any problems install the PRWS and PRBS components on the same server. You may also install the PRWS and PRBS components multiple times on several servers. Each PRBS can handle requests

299 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 299 OF 407 from several Password Reset Web Sites, but each PRWS can point to one dedicated PRBS only 38. The diagram below illustrates a single-server setup of the Password Reset Module: LAN DMZ GSM Modem(s) Firewall TCP 8988 TCP 8989 Transmission Servers SMS PASSCODE Load Balancing Service SMS PASSCODE Transmitter Service Password Reset Server (IIS) SMS PASSCODE Password Reset Web Site SMS PASSCODE Password Reset Backend Service LDAP/LDAPS Active Directory Server Password Reset single-server setup (not recommended) The single-server setup is not recommended, except if you place the Password Reset Server on the LAN side, in case you only want internal users to have access to the Password Reset functionality. Configuration of the Password Reset components, PRWS and PRBS, is performed using the SMS PASSCODE Configuration Tool. This is described in more detail in sections 17.6 (page 301) and 17.7 (page 303). 38 However, it is possible to host several PRWS within the same IIS, with each PRWS pointing to a different PRBS (cf. section , page 274)

300 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 300 OF Security Concerns The subsections below address a number of security concerns regarding the Password Reset Module. Please read these sections carefully Publishing the Password Reset Web Site Since the PRWS is protected by SMS PASSCODE multi-factor authentication, it is safe to publish the site for external access. The advantage of doing so is that users will even be able to reset their password during remote access. An important pre-requisite is of course, that all users Personal Passcodes are well-protected and kept private. Note: Unlike the PRWS, it is not recommended to publish the Self Service Web Site for public access, cf. section 16.4, page 277. It is recommended to install the PRWS in a DMZ, and to install the PRBS behind the firewall (on the LAN side), cf. section 17.4 (page 296) Protecting the Password Reset Web Site with SSL/TLS Since the PRWS uses form-based authentication, it is very important that the site is protected using SSL/TLS to ensure, that all credentials are transferred encrypted. Always remember to install an SSL certificate for the PRWS before making use of the site. IMPORTANT For security reasons the PRWS has been designed to require SSL/TLS encryption. Therefore the PRWS will NOT work before an SSL certificate has been installed for the site and HTTPS has been enabled successfully Encryption of the Network Communication with the AD Controller Whenever a user requests a password reset, the actual action of resetting the password is performed by sending an LDAP request from the PRBS to an AD Controller. It is recommended to protect this network communication using SSL/TLS. SSL/TLS encryption is enabled using the SMS PASSCODE Configuration Tool as described in section below Protecting the Password Reset Module against Attacks The PRWS might be a target for Brute-force or Denial-of-Service attacks. To protect against such attacks, both the PRWS and PRBS will continuously monitor all attempts to access the site and will take appropriate actions, whenever any unusual behavior is observed. These defensive actions are either to restrict the access to the PRWS and/or to send alerts to selected administrators. The configuration of these actions is performed using the SMS PASSCODE Configuration Tool as described in section below.

301 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 301 OF Configuring the Password Reset Web Site Before taking the PRWS into use, please complete the following actions in the specified order: 1. Configure communication with the PRBS in the SMS PASSCODE Configuration Tool. This is described in section below. 2. Protect the PRWS using an SSL certificate. This is described in section , page Configure Communication with the Password Reset Backend Service For the PRWS to work, communication with a PRBS must be configured. This is configured using the SMS PASSCODE Configuration Tool; either when it pops up during installation of the PRWS, or alternatively by starting it manually afterwards (cf. section 20, page 388). The Configuration Tool contains two tabs that are relevant for setting up the PRBS communication: 1. On the Network tab, specify the TCP port and Shared Secret to use for communication with the PRBS: IMPORTANT: The TCP port and Shared Secret must match the entries entered in the Configuration Tool on the PRBS host, otherwise communication with the PRBS will fail (cf. section , page 312).

302 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 302 OF On the Password Reset tab, specify the name or IP address of the server hosting the PRBS: In case the PRBS is already installed and configured on the target host, you can click the Test connection button to verify whether the PRWS is able to communicate with the PRBS Hosting Multiple Password Reset Web Sites within the Same IIS If you need to host several Password Reset Web Sites within the same IIS (advanced feature), then this is also possible. The required steps are: 1. Manually copy the folder of the original PRWS (with all content, including subfolders) to a new location. The default path of the folder is: C:\Program Files\SMS PASSCODE\Web\PasswordReset 2. Create a new web application within the IIS, setting the physical path to the target path of the copy made in step 1. The web application must either use the same application pool as the original PRWS, or alternatively another application pool with the same settings. 3. Most likely, you would like the new PRWS two connect to a different PRBS than the original PRWS. This can be achieved by overriding the settings of the SMS PASSCODE Configuration Tool in the web.config file of the new web site. In the web.config file locate the following section: <appsettings> <add key="backendhost" value="" /> <add key="backendtcpport" value="" /> <add key="requirehttps" value="true" /> </appsettings> 39 The Test connection button is not available, if the Configuration Tool was started automatically during installation of the PRWS, and the PRBS is installed on the same host; this is because the Configuration Tool knows in this case, that the PRBS has not been started yet, i.e. the connection test is known to fail.

303 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 303 OF 407 Using the two settings BackendHost and BackendTcpPort, you may override the hostname and the TCP port that the new PRWS should use to connect to a PRBS. E.g. if the PRBS is located on a server with hostname MyServer on TCP port 4254, then change the section to: <appsettings> <add key="backendhost" value="myserver" /> <add key="backendtcpport" value="4254" /> <add key="requirehttps" value="true" /> </appsettings> The overridden settings will take effect, as soon as the modified web.config file has been saved Protect the Password Reset Web Site using SSL/TLS To protect the PRWS using SSL/TLS, you must install an SSL certificate on the SMS PASSCODE Password Reset Web Site in the IIS Manager. This is a standard IIS management task. Several guides for this exist on the internet, e.g. or After having installed the SSL certificate successfully, please check that you can access the home page of the PRWS using HTTPS. It might only be the home page itself that will work at this stage. To make the PRWS fully functional, you must also ensure that the PRBS has been installed and configured as described in the next section Configuring the Password Reset Backend Service Before taking the PRBS into use, please complete the following actions in the specified order: 1. Set up a dedicated user account in your AD to be used for performing password resets. This is described in section below. 2. Configure Password Reset settings in the SMS PASSCODE Configuration Tool. This is described in section , page Setting Up a Dedicated User Account for Password Reset To be able to perform password resets on your behalf, the SMS PASSCODE Password Reset Module must be given the credentials of a user who has been delegated password reset rights. It is recommended that you create a dedicated user account for this. Please proceed as follows: 1. Create a new user account in your AD. E.g. call it SMSPC Password Reset User. This user is called the Password Reset Account below. 2. Configure the Password Reset Account to have permission to reset the password of all users that are granted access to any PRWS connected to the PRBS. To do so, you must open the Active Directory Users and Computers management console for your AD and then locate the nodes (OUs) that contain the relevant users. For each such node the Password Reset Account must be assigned the permission to reset passwords of the users contained in the node. Due to inheritance, you do not need to assign this permission explicitly to each node. You can either assign the permission to the top level node of the domain, or for better control assign the permission to the topmost OUs containing the

304 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 304 OF 407 relevant users directly or indirectly. Either way, to assign the permission to the relevant node(s), repeat the following actions for each such node: a. Right click the node and select Delegate Control b. The Delegation of Control Wizard dialog appears. Click Next.

305 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 305 OF 407 c. A list appears where you must add the user that was created in step 1. Click the Add button, add the user, and then click Next. d. Now select the option Reset user passwords and force password change at next logon and click Next. e. On the final dialog click Finish. f. The Password Reset Account has now been assigned the right to reset passwords of all users in the selected node. By default, the user will have this right for the node itself and the complete sub tree (all child OUs) as well, except branches where inheritance has been disabled.

306 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 306 OF 407 If you have allowed locked out users to log in to a PRWS, then the Password Reset Account must additionally have the right to unlock users. To delegate this permission, continue the procedure as follows: g. Right click the same AD node and select Delegate Control again: h. The Delegation of Control Wizard dialog appears. Click Next.

307 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 307 OF 407 i. A list appears where you must add the user that was created in step 1. Click the Add button, add the user, and then click Next. j. Now select the option Create a custom task to delegate and click Next.

308 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 308 OF 407 k. Select the Only the following objects in the folder option, then select the User objects checkbox only, and finally click Next. l. Clear the General checkbox and select the Property-specific checkbox instead. In the Permissions section, select the Read lockouttime and Write lockouttime permissions. Click Next. m. On the final dialog click Finish.

309 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 309 OF 407 n. The Password Reset Account has now been assigned the right to unlock users in the selected node. By default, the user will have this right for the node itself and the complete sub tree (all child OUs) as well, except branches where inheritance has been disabled Configure Settings of the Password Reset Backend Service Before using the PRBS, some settings must be set in the SMS PASSCODE Configuration Tool. You can either specify these settings when the Configuration Tool pops up during installation of the PRBS, or alternatively start the Configuration Tool manually afterwards on the server where the PRBS has been installed. Please read section 20 (page 388) for instructions about starting the Configuration Tool manually. When the SMS PASSCODE Configuration Tool has been started on the PRBS server, please select the Password Reset tab: The Password Reset tab contains the two sub-tabs AD Settings and Attack Protection, which are described in the following two subsections.

310 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 310 OF Configuring AD Settings On the AD Settings tab you can specify the settings that instruct the PRBS, which AD Controller it should contact to perform a Password Reset, and how it should contact the AD Controller: a. Server name Please enter here the name or IP address of the AD Controller that the PRBS should contact whenever a user requests a password reset. You can also specify the DNS name of a domain to let the PRBS contact any AD Controller of the domain. If you leave the field empty, the PRBS will try to reach any AD Controller that the PRBS server itself is a member of. b. SSL/TLS Check this option to enable SSL/TLS encryption of all communication (LDAP requests) between the PRBS and the specified AD Controller(s). It is strongly recommended to enable this option 40. To make SSL/TLS encryption work you must install an SSL certificate on every relevant AD Controller. I.e. if the Server name option has been set to a specific server name or IP address, then you must install a certificate on this specific server, and the certificate must have been issued to the exact same server name or IP address, respectively. If you have entered a domain name into the Server name field, then you must install a certificate on every AD Controller that the PRBS might contact, and the certificate must have been issued 40 If you do not enable this option, PRBS might fail to reset passwords with the error message A device attached to the system is not functioning in the Password Reset event log. In case this happens, please enable the SSL/TLS option to solve the problem.

311 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 311 OF 407 to the domain name. c. Password reset account Please enter here the credentials of the dedicated password reset user account used for contacting the AD Controller(s). If you have not yet created a dedicated password reset user account, then please read section (page 303). d. Test button When all the settings above have been specified, please click the Test button. This will execute a test that checks the settings and reports whether everything works as expected. E.g. whether the AD Controller can be reached, whether SSL encryption works and whether the credentials for the password reset account are valid. In case any problems are reported, please correct the settings and retry the test, until it succeeds. Remember to click the Save button to commit any changes Configuring Attack Protection On the Attack Protection tab you can specify settings that instruct how the PRBS should react to brute-force and Denial-of-Service attacks: a. Brute Force Attack Protection Here you can specify how many login attempts are allowed per user within a specific period. If the number of allowed attempts is exceeded within the specified monitoring period, then the user will be denied access for a period (until the monitoring period again contains less attempts than allowed). b. Alerting You can set up the PRBS to send an alert whenever a specified number of login attempts have failed within a specified monitoring period. You can define any number of alert receivers. Each receiver name must match the SAM account name or UPN of a user in the SMS PASSCODE database. The settings of each matching user in the database determine how alerts will be sent, e.g. whether the alerts are sent by SMS or . Sending alerts by voice call is not supported. If you would

312 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 312 OF 407 like to have specific transmission rules for alerts (e.g. sending alerts to a specific public folder address), then it is recommended to manually create one or more dedicated alert users in the SMS PASSCODE database, and define mobile number, address and/or dispatch type as required on each such user Network Communication By default, the PRBS listens to incoming requests from SMS PASSCODE Password Reset Web Site(s) on TCP port It is recommended to use this default port, unless it conflicts with another application in your network. If this is the case, you may change the TCP port on the Network tab of the SMS PASSCODE Configuration Tool: IMPORTANT: The TCP port and Shared Secret must match the entries entered in the Configuration Tool on each PRWS host, otherwise communication from a PRWS to the PRBS will fail. When the PRBS has been installed and configured, it is recommended to verify on the/each PRWS host, whether communication with the PRBS works as expected (cf. section , page 301).

313 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 313 OF Password Reset Event Log When installing the PRBS on a server, a new Windows Event Log called SMS PASSCODE Password Reset is automatically created. Please open the Event Viewer management console and inspect the Password Reset event log, whenever you would like to get an overview, which users have reset or attempted to reset their password, and when. Please also inspect the Password Reset event log on the PRBS server, in case a user is denied access to any PRWS connected to the PRBS in question: The event log will contain an entry that tells you the exact reason, why the user was denied access.

314 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 314 OF Localization When an end-user accesses the SMS PASSCODE Password Reset Web Site, the site will be displayed in a localized language according to the current language settings of the end-user s web browser. Currently, the following localizations are supported: Czech Danish Dutch English Finnish French German Hungarian Italian Korean Norwegian Polish Romanian Russian Spanish Swedish Turkish English is used by default, if no matching localization is found. 18 SECURE DEVICE PROVISIONING SMS PASSCODE Secure Device Provisioning (SDP) is a new component in SMS PASSCODE version 7. This component integrates with Microsoft Exchange Server in order to let end-users perform secure, multi-factor authentication based provisioning of their own ActiveSync devices Background Microsoft Exchange Server 2010 and 2013 can be configured to automatically put any new ActiveSync device that is requesting access to a user s mailbox into quarantine mode. Whenever a device is put into quarantine mode, the end-user will receive a quarantine about this event. Additionally, the Exchange Server can be configured to send a copy of each such quarantine to other internal personnel (e.g. internal IT helpdesk), to allow inspection of the ActiveSync request. From the content of the quarantine someone has to decide, whether the device should be granted access or not, and finally manually update the state of the device to Access Granted or Access Blocked in the Exchange Server s database. The problem with this approach, especially in bigger companies, is: How does the system administrator (or other selected personnel) know, whether to approve a quarantined device or not? How to distinguish between a valid user device and a hacker attempting to get access to a user s using the ActiveSync protocol?

315 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 315 OF 407 A traditional approach is to implement a manual approval procedure, that takes up extra time for internal IT, and blocks users from accessing their s until the devices have been approved. This causes unnecessary delays and loss of worker productivity. The best approach for solving the above problem is to enable the end-users to approve any new ActiveSync device by themselves. This is exactly, what the SMS PASSCODE Secure Device Provisioning (SDP) component allows; building on top of Microsoft Exchange Server s built-in quarantine functionality, it extends the standard workflow in a convenient and intuitive way, letting end-users provision their new ActiveSync devices by themselves, using a secure, multi-factor authentication based approach. The procedure for self-provisioning is very easy: Whenever the Exchange Server is going to send a quarantine to an end-user, the SDP component automatically detects this, and modifies the content of the by inserting a hyperlink into the quarantine . When the end-user receives the quarantine , self-provisioning is activated by a simple click of the inserted hyperlink. This will redirect the user to the SMS PASSCODE Secure Device Provisioning Web Site, which allows the user to perform a multi-factor authentication to validate his identity. On successful validation, the new ActiveSync device is automatically approved, allowing it to synchronize data with the Exchange Server. IMPORTANT: Since the provisioning workflow is based on modification of quarantine s, self-provisioning will not work for devices that do NOT synchronize s. E.g. if a device synchronizes calendar data only or contact persons only, then self-provisioning will not work. In this case, e- mail synchronization must be enabled as well (at least temporarily); otherwise provisioning has to occur in the ordinary, manual way by the administrator Features This section summarizes the features of the SDP component. The provided features are: Secure Provisioning: The SDP component allows end-users to approve (provision) new ActiveSync devices by themselves. The process is convenient, since the user automatically receives a link to start the provisioning process, yet also secure, since validation of the user is performed using multi-factor authentication. The provisioning workflow is described in detail in section 18.5 (page 327). Configurable Provisioning: The SDP component allows you to configure the balance between end-user convenience and security. This is achieved by providing different types of workflows, spanning from simple to more secure workflows. Configuration of provisioning workflows is described in detail in section 18.5 (page 327).

316 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 316 OF 407 Auto-provisioning: The SDP component integrates with the SMS PASSCODE backend, taking full advantage of the policy-driven engine of SMS PASSCODE. Among others, this means that Authentication Policies can also be used for the SDP component to control the level of access and authentication. For example it is possible to define multi-factor authentication bypassing under specific circumstances, resulting in auto-provisioning of new devices in such cases. A good example is to allow auto-provisioning of new ActiveSync devices when they are connected to a specific, trusted internal network, like an internal WIFI network. Configuration of Authentication Policies for auto-approval is described in detail in section (page 338). AD Lockout Protection: The SDP component also protects against password brute-force attacks, in accordance to the rules defined by a user s Authentication Policy. This means, that if an ActiveSync device keeps requesting access with wrong credentials, the SMS PASSCODE account will become locked out instead of the AD account. This provides protection both against hacking attempts, but also in case of old user devices, that have not been disconnected properly and keep requesting access with expired, incorrect credentials. In both cases, the authentication monitor in the SMS PASSCODE Web Administration Interface can be used to detect the problem, where after the administrator can inspect the Windows event log of the SDP component to get even more details about the ActiveSync requests causing the lockout. Configuration of password brute-force protection in Authentication Policies is described in detail in section (page 181). Extensive logging: The SDP component provides extensive logging of all ActiveSync requests (success/failure), as well as logging of all provisioning attempts. The log entries contain detailed device information, in addition to Geo-IP information (in case Geo-IP functionality has been enabled). Event logging is described in more detail in section 18.7 (page 340) Getting Started with Secure Device Provisioning As mentioned above, SMS PASSCODE Secure Device Provisioning (SDP) is building on top of Microsoft Exchange Server s built-in functionality. This means, that your Microsoft Exchange Server needs to be configured in a required way for SDP to work properly. This section describes important considerations and actions to take, before installing SDP. IMPORTANT: Please read this section carefully before installing SMS PASSCODE Secure Device Provisioning. Not following the guidelines of this section might result in an undesired change of access state of all ActiveSync devices within your organization. The order of actions, before installing SDP, depends on the way your Microsoft Exchange Server is configured beforehand. Please compare the scenarios below to your configuration, then select the best fit and perform the corresponding actions.

317 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 317 OF 407 Scenario Required Actions You have already configured your Microsoft Exchange Server to put new ActiveSync devices into quarantine mode. Quarantined devices have been approved or blocked manually. Any new devices in the future must be approved using SMS PASSCODE Secure Device Provisioning. You have not previously configured your Microsoft Exchange Server to put new ActiveSync devices into quarantine mode. You feel uncomfortable about the ActiveSync devices currently connecting to your Exchange Server and would like all current ActiveSync devices to go through an approval procedure, by letting end-users approve their existing devices using SMS PASSCODE Secure Device Provisioning. You have not previously configured your Microsoft Exchange Server to put new ActiveSync devices into quarantine mode. You feel comfortable about the ActiveSync devices currently connecting to your Exchange Server and would like to avoid that end-users must approve existing devices. However, any new devices in the future must be approved using SMS PASSCODE Secure Device Provisioning. This is the simplest scenario. In this case, you simply need to install SMS PASSCODE Secure Device Provision on every Exchange Client Access Server (CAS). Please ensure that the external OWA URL has been set in Exchange Server, before performing the first provisioning attempts. Section (page 318) describes how to configure/check this. First, install SMS PASSCODE Secure Device Provisioning on every Exchange Client Access Server (CAS). Ensure that the external OWA URL has been set in Exchange Server, before performing the first provisioning attempts. Section (page 318) describes how to configure/check this. Finally, configure your Microsoft Exchange Server to put devices into quarantine mode. The procedure for this is described in section (page 322). First, install SMS PASSCODE Secure Device Provisioning on every Exchange Client Access Server (CAS). Now, set up an Authentication Policy that will autoapprove existing ActiveSync devices. The procedure for this is described in section (page 338). Please also ensure that the external OWA URL has been set in Exchange Server, before performing the first provisioning attempts. Section (page 318) describes how to configure/check this. Finally, configure your Microsoft Exchange Server to put devices into quarantine mode. The procedure for this is described in section (page 322). After a couple of days, when all existing devices have been auto-approved, disable or delete the Authentication rule for auto-approval Configuring Microsoft Exchange Server In order for SMS PASSCODE Secure Device Provisioning (SDP) to operate correctly, your Microsoft Exchange Server must be configured appropriately: The external URL of your Outlook Web Access (OWA) Site must have been set Quarantine mode must have been enabled for new ActiveSync devices

318 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 318 OF 407 In case your Exchange Server configuration does not already fulfill these two requirements, please follow the following two subsections for instructions on how to configure your Exchange Server. Furthermore, as described in section 18.3 above, it is important that configuration of your Exchange Server and installation of SMS PASSCODE Secure Device Provisioning is done in the right order Setting External OWA URL For the SMS PASSCODE Secure Device Provisioning (SDP) component to insert a useable hyperlink in modified quarantine s, for accessing the SDP Web Site, the SDP component needs to know the external URL of your Outlook Web Access (OWA) site. The SDP component is able to retrieve this external URL from your Exchange Server, as long as it has been defined there. If not, this section describes how to set the external OWA URL in your Exchange Server. You only need to follow the steps below, if you have not already set the external OWA URL in your Exchange Server previously. The procedure for setting the external OWA URL depends on the version of your Exchange Server. The next two subsections describe the required steps on an Exchange Server 2010 and 2013, respectively Setting External OWA URL on Exchange Server 2010 To set the external OWA URL in Exchange Server 2010, follow the steps below: 1. Log in to the Exchange Management Console (EMC) and select the Client Access node on the left side:

319 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 319 OF On the Client Access page, click the Configure External Client Access Domain link on the right side: 3. On the Configure External Client Access Domain dialog that pops up: a. Enter the external URL of your OWA site into the textbox. (this must be the URL that your end-users can use from outside your organization to connect to your published OWA site) b. Click the Add button to assign the external URL to every public available Exchange CAS. Note: The SDP component must be installed on every such CAS. c. Finally, click the Configure button.

320 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 320 OF This completes the procedure for setting the external OWA URL Setting External OWA URL on Exchange Server 2013 To set the external OWA URL in Exchange Server 2013, follow the steps below: 1. Log in to the Exchange Admin Center (EAC) and select the servers tab on the left side:

321 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 321 OF On the servers tab, click the configure external access domain icon on the right side:

322 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 322 OF On the configure external access domain dialog that pops up: a. Enter the external URL of your OWA site into the textbox. (this must be the URL that your end-users can use from outside your organization to connect to your published OWA site) b. Click the + icon to assign the external URL to every public available Exchange CAS. Note: The SDP component must be installed on every such CAS. c. Finally, click the save button. 4. This completes the procedure for setting the external OWA URL Enabling Quarantine Mode By default, your Microsoft Exchange Server will allow any new ActiveSync device to connect. This section describes how to configure your Exchange Server to set any new ActiveSync device into quarantine mode and send a quarantine to the device, when it attempts to connect. This configuration is required, because the SDP component builds on top of the built-in quarantine functionality of the Microsoft Exchange Server. You only need to follow the steps below, if you have not already enabled quarantine mode in your Exchange Server previously.

323 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 323 OF 407 RECOMMENDATION: When configuring quarantine s in your Exchange Server, it is recommended to also set up administrators to receive copies of all quarantine s. Such administrators will receive copies of the original, unmodified Exchange Server quarantine s, whenever a user receives an SDP modified quarantine . Normally administrators will not need to take any actions on those copies of quarantine s, but it is still a best-practice to receive them, to ensure administrators have the possibility of performing a manual device approval, in case selfprovisioning by an end-user does not work for any reason. There are several reasons, why an end-user might receive an unmodified quarantine without the option for self-provisioning. Examples are: - The user has not been created in the SMS PASSCODE Database - The user has not been allocated any SMS PASSCODE Standard MFA CAL - The user is explicitly denied access to the SDP Web Site due to an Authentication Policy - Required SDP components have been shut down The procedure for enabling quarantine s depends on the version of your Exchange Server. The next two subsections describe the required steps on an Exchange Server 2010 and 2013, respectively Enabling quarantine mode on Exchange Server 2010 To enable quarantine mode on an Exchange Server 2010, follow the steps below: 1. Log in to the Exchange Control Panel (ECP) and select the Mobile & Voice tab on the left side:

324 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 324 OF On the Mobile & Voice tab, click the Edit button on the right side:

325 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 325 OF On the Exchange ActiveSync Settings dialog that pops up: a. Select the Quarantine radio button b. Click the Add button to add administrators to receive copies of quarantine e- mails. c. Finally, click the Save button. 4. This completes configuration of quarantine mode.

326 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 326 OF Enabling quarantine mode on Exchange Server 2013 To enable quarantine mode on an Exchange Server 2013, follow the steps below: 2. Log in to the Exchange Admin Center (EAC) and select the mobile tab on the left side: 3. On the mobile tab, click the edit button on the right side:

327 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 327 OF On the Exchange ActiveSync access settings dialog that pops up: a. Select the Quarantine radio button b. Click the + icon to add administrators to receive copies of quarantine s. c. Finally, click the save button. 5. This completes configuration of quarantine mode Configurable Workflows SMS PASSCODE Secure Device Provisioning (SDP) supports different types of provisioning workflows. This section describes the differences between these workflows, and how to configure them. By default, SDP uses the Standard workflow, which is the most secure workflow. However, you may configure SDP to use a simpler workflow with improved end-user convenience, at the cost of lower security.

328 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 328 OF 407 To understand the differences, section below first describes the standard workflow step-bystep. Hereafter, section describes the differences between the alternative workflows. Finally, section describes how to set up an SDP Web Site to use a specific workflow Standard Workflow This section describes the standard workflow of SDP. Whenever a user is going to connect a new ActiveSync device to the Exchange server of your organization, the standard flow goes like this: 1. First the user sets up his account on the ActiveSync device in the usual manner, among others entering required credentials for accessing the mailbox. 2. The Exchange server detects, that a new ActiveSync device is requesting access, puts the device into Quarantined state, and then sends out a quarantine to the user. 3. The SDP component installed on the Exchange CAS detects the outgoing quarantine e- mail and modifies its content 41 to contain instructions about SMS PASSCODE Secure Device Provisioning, among others providing a hyperlink for accessing the SDP Web Site. The modified quarantine is sent out to the user s ActiveSync device. 4. The user receives the modified quarantine on his ActiveSync device and reads the instructions inserted by the SDP component. He then clicks the hyperlink in the , which redirects the user to the SDP Web Site. Note: The SDP Web Site uses adaptive layout, meaning it is user-friendly across different devices independent of the actual screen resolution. 41 You can optionally customize the text to be inserted into the modified quarantine . Please read section , page 314, for details.

329 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 329 OF When arriving at the SDP Web Site, the site will automatically request the user to perform an SMS PASSCODE multi-factor authentication to validate his identity:

330 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 330 OF The user validates his identity by entering the received one-time passcode, and then clicking the Login button:

331 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 331 OF Now the SDP Web Site will show a device information page, where the user can decide to grant access or block access for the new ActiveSync device. On this page, the user can perform the following actions: a. Inspect the details about the ActiveSync device requesting access. Among others, the name, model and type of the device are shown. The user can use all this information to verify that he is granting access to the right device. b. Inspect the details about other ActiveSync devices, that have requested access to the user s mailbox previously, and have either been granted access or blocked for access. The user may click on the arrows to the right to expand the sections and show all the details about these devices as well. Inspecting previous devices might be helpful for the user, in case he suspects something is wrong and he already has granted access for the needed devices previously. c. If everything looks alright, the user finally grants access for the device by clicking the button Grant Access. d. Otherwise, if the user suspects an unwanted access to his mailbox was attempted, e.g. from an unknown device by a hacker, then the user might block further access from such device by clicking the Block Access button.

332 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 332 OF 407 Note: In case Geo-IP functionality has been enabled, the SDP Web Site makes an extra check before showing the device information page. It will check, whether the ActiveSync device was requesting access from a different country than the country where the user is accessing the SDP Web Site from. If this is the case, this is suspicious and might indicate that a hacker is trying to fool the user to grant access to the hacker s ActiveSync device. A warning will be displayed on the device information page in this case: 8. After the user has either granted access or blocked access, the user arrives at the final page, which confirms the selected action: Confirmation page when access was granted

333 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 333 OF 407 Confirmation page when access was blocked This completes the standard flow.

334 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 334 OF Other Workflows This section describes the additional possible workflows that the SDP Web Site can be configured to use, besides the standard workflow described in the previous section. The SDP Web Site can be configured to use one of the following 3 workflows: Workflow Standard Simple Description The standard workflow is described in detail in the previous section (section ). In summary, the user must validate his identity using multi-factor authentication, then inspect device information, and then finally explicitly grant access to the device. The simple workflow is similar to the standard workflow, except in this case the user must only validate his identity using multi-factor authentication. As soon as the user has entered a correct passcode on the login page of the SDP Web Site, the ActiveSync device is automatically granted access, and the user will immediately see a confirmation page regarding this. In other words, the device information page of the standard workflow is skipped in this case. While this workflow is more convenient for the end-user, since he only needs to enter a passcode and not verify any device information, it lowers security. A hacker might forward a quarantine to the user and fool him to log in to the SDP Web Site to approve the device. Nonetheless, the simple workflow is still a reasonable step-up compared to not having any protection of ActiveSync devices at all. Mixed The mixed workflow is a combination of the two workflows above. To take advantage of this workflow, collection of end-user IP addresses must have been enabled for ActiveSync Provisioning in the SMS PASSCODE Configuration Tool (cf. 20.2, page 392). In this case, the SDP Component will compare the IP addresses of the new ActiveSync device requesting access and of the browser accessing the SDP Web Site. If these IP addresses are equal, it is reasonable to assume, that the provisioning attempt is trustable, and therefore the simple workflow will be applied. Otherwise, if the IP addresses differ, then the standard workflow is applied. In this way the mixed workflow balances convenience versus security.

335 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 335 OF Configuration of Workflows This section describes how to configure the SDP Web Site to use one of the workflows described in the previous section. The standard workflow is used by default, i.e. you only need to change the configuration in case you would like to use an alternative workflow. To apply a specific workflow to the SDP Web Site, please log in to the server with the site installed, and follow the steps below: 1. Open the IIS Manager and select the DeviceProvision application on the left side: 2. Double-click the Application Settings icon to open the settings of the SDP Web Site:

336 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 336 OF On the Application Settings page, right-click the WorkFlowMode setting and select Edit

337 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 337 OF Now enter a value between 1 and 3 into the textbox that appears, and click OK. The table below shows the value to enter for the different workflows (higher value means higher security): Workflow Standard 3 Mixed 2 Simple 1 Value of WorkFlowMode setting It is not necessary to restart any services for the new workflow mode to take effect. If you have installed the SDP Web Site on several CAS servers, then it is recommended to apply the same workflow mode to all of them Authentication Policy Interaction This section describes how Authentication Policies relate to the SMS PASSCODE Secure Device Provisioning (SDP) component. Authentication Policies are described in detail in section 15.8 (page 177). The two main things of interest in relation to the SDP component are: Password brute-force protection (section , page 181) Access result of the Authentication Rules (section , page 187) Password brute-force protection The password brute-force protection settings of an Authentication Policy define, how many consecutive authentication attempts are allowed with incorrect credentials, before SMS PASSCODE will lock out the SMS PASSCODE user account. This setting applies to authentication attempts from ActiveSync devices as well.

338 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 338 OF 407 Access result Each rule of an Authentication Policy defines an Access result setting. In relation to SDP, this access result does NOT apply to the ActiveSync traffic itself, but instead it applies to the access to the SDP Web Site. This means: Access = Allow access, use MFA: The user is granted access to the SDP Web Site and must perform a successful MFA here to provision a new ActiveSync device. Access = Allow access, bypass MFA: The user does not need to access the SDP Web Site instead a new ActiveSync device is approved automatically, without any user actions. This might be useful in some specific scenarios (cf. section below). Access = Deny access: The user is denied access to the SDP Web Site. This means that SMS PASSCODE Secure Device Provisioning is disabled and the user will not be able to self-provision a new ActiveSync device. In this case, provisioning of a new ActiveSync device falls back to the standard logic of Microsoft Exchange Server, e.g. a default quarantine is sent, in case this has been enabled Auto-approving New ActiveSync Devices As stated in the previous section, an Authentication Rule with the Access setting set to Allow access, bypass MFA will result in bypassing of the SDP Web Site and auto-approval of a new device immediately. This might be useful in several scenarios; some examples are given later below. To create an Authentication Rule for auto-approval of ActiveSync devices, you must create the rule according to the following steps: 1. Set the rule to apply to ActiveSync Device Provisioning only:

339 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 339 OF Set the rule to bypass multi-factor authentication: When is it useful to enable auto-approval of new ActiveSync devices? Here are some examples: Example 1: You have not previously used the quarantine functionality of Exchange Server, and when you enable it, you would like to avoid all end-users to go through self-provisioning of their existing devices. To achieve this, you can temporarily add an Authentication Rule as described above to each relevant Authentication Policy that will bypass MFA specifically for ActiveSync provisioning requests. You should add this rule as the very first rule to each relevant Authentication Policy. After a while, you should then either disable or remove this rule, to allow secure device provisioning using multi-factor authentication to occur. Example 2: For improved convenience, you would like your end-uses to provision new ActiveSync devices very easily, when the end-user is in a trusted environment. Examples of a trusted environment could be: o The ActiveSync request must originate from a trusted IP, i.e. an IP address that the system is used to receive requests from regarding the specific user in question. In this case, add the following condition to the Authentication Rule:

340 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 340 OF 407 o The ActiveSync request must originate from an explicitly selected IP address scope, e.g. the scope of an internal WIFI within your organization. In this case, add the following condition to the Authentication Rule, entering an appropriate IP address scope: For more details about Authentication Policies in general, please read section 15.8 (page 177) Event Logging On any Exchange CAS with SMS PASSCODE Secure Device Provisioning (SDP) installed, a separate Windows event log with the name SMS PASSCODE Provisioning is created. This event log contains among others an audit about all ActiveSync connection attempts and all login attempts to the SDP Web Site.

341 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 341 OF 407 The event log also contains error entries in case any issues regarding the SMS PASSCODE Secure Device Provisioning component occur. Hence, the event log is a good starting point for troubleshooting the SDP component Localization SMS PASSCODE Secure Device Provisioning supports localization for end-user related content: When a modified quarantine is sent to an end-user, the content of the quarantine e- mail will be localized. When the ActiveSync device reports a preferred language, then this language will be used. Otherwise, the language set on the end-user s Exchange mailbox is used. When an end-user accesses the SMS PASSCODE Secure Device Provisioning Web Site, the site will be displayed in a localized language according to the current language settings of the end-user s web browser. In both cases, the following localizations are currently supported: Czech Danish Dutch English Finnish French German Hungarian Italian Korean Norwegian Polish Romanian Russian Spanish Swedish Turkish English is used by default, if no matching localization is found Customization of Localized Texts It is possible to modify the localized texts, in case you wish to customize them. In particular, you might wish to customize the content of the modified quarantine s sent out by the SMS PASSCODE Secure Device Provisioning component. In order to do so, you need to edit the content of the resource files (resx files) located in the Resources folder of the SMS PASSCODE Secure Device Provisioning background service. The default location of this folder is: C:\Program Files\SMS PASSCODE\ActiveSyncProv\Resources In case of any customizations, please make a backup of the modified resx files, since they might be overwritten during a future upgrade of SMS PASSCODE.

342 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 342 OF CONFIGURING AUTHENTICATION CLIENTS 19.1 Configuring Citrix Web Interface Protection If you have installed the optional Citrix Web Interface Protection component, you will normally not need to perform any further configuration of this. Manual configuration of the Citrix Web Interface scenario is only necessary if you decide to change the scenario to a different setting than selected during installation. This might, for example, be the case if the scenario Disabled was selected during installation, and you would like to activate SMS PASSCODE authentication for the Citrix Web Interface afterwards. The procedure for changing the Citrix Web Interface Protection scenario is: 1. Open the file WebInterface.conf using Notepad. This file is located in the subfolder Conf of the root folder of the Citrix Web Interface. The default path is: Citrix Web Interface 4.6: C:\Inetpub\wwwroot\Citrix\AccessPlatform\conf\WebInterface.conf Citrix Web Interface 5.x: C:\Inetpub\wwwroot\Citrix\XenApp\conf\WebInterface.conf 2. Edit the line containing SMSPASSCODE=xxxx. Change it to: SMSPASSCODE=Off SMS PASSCODE is disabled. SMSPASSCODE=On SMS PASSCODE is enabled (Standalone or Side-By-Side logon). SMSPASSCODE=Both SMS PASSCODE is enabled (Standalone or Dual logon). 3. Save the WebInterface.conf file. IMPORTANT If you have enabled Active Directory Integration, and you are receiving the error message Unknown user, please contact your administrator during Citrix Web Interface logon, please read section 23.2 (page 402) for solving this problem.

343 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 343 OF Configuring RADIUS Protection If you have installed the optional RADIUS Protection component, you should configure your RADIUS clients and your RADIUS server (IAS/NPS server). Below IAS/NPS server designates the server that the SMS PASSCODE RADIUS Protection component is installed on. The configuration procedure is slightly different on Windows Server 2003 and Windows Server 2008/2012. Please follow the instructions in section for Windows Server 2003 and the instructions in section for Windows Server 2008 or Configuring RADIUS Protection on Windows Server 2003 The procedure for configuring RADIUS authentication using SMS PASSCODE on a Windows Server 2003 is: 1. Configure all RADIUS clients in the usual way by specifying the IAS server as the RADIUS server. If you are in doubt how to perform the configuration, please refer to the configuration guide of the specific RADIUS client in question. Important: The user experience is best for RADIUS clients supporting Challenge Response. If Challenge Response support is configurable on the RADIUS client, please enable it. 2. Start the IAS Management Console: a. Select Run in the Windows Start menu b. Enter ias.msc c. Click OK 3. The IAS Management Console is shown. 4. Now you must create all your RADIUS Clients in the IAS Management Console. If these have already been created beforehand, you can skip to step 10.

344 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 344 OF To create a RADIUS Client: a. Right-click the RADIUS Clients node. b. Select New RADIUS Client. 6. The New RADIUS Client dialog appears. a. Enter a friendly name of the RADIUS Client. b. Enter the IP address of the RADIUS Client. c. Click Next.

345 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 345 OF New fields appear in the New RADIUS Client dialog. a. Enter and confirm the Shared Secret. It must match the shared secret configured on the RADIUS Client. b. Click Finish. 8. The RADIUS Client that you have created will appear in the right-hand pane: 9. Repeat steps 5-8 if you need to create more RADIUS Clients.

346 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 346 OF This completes the configuration of RADIUS authentication using SMS PASSCODE. Please test each RADIUS client to make sure that RADIUS authentication works as expected. Note: By default, settings of Connection Request Policies (CRP) and Remote Access Policies (RAP) are ignored during SMS PASSCODE authentication. However, you can enable internal IAS/NPS logic to apply CRP/RAP settings (cf. section , page 352) Configuring RADIUS Protection on Windows Server 2008 / 2012 The procedure for configuring RADIUS authentication using SMS PASSCODE on a Windows Server 2008 (R2) or Windows Server 2012 (R2) is: 1. Configure all RADIUS clients in the usual way by specifying the NPS server as the RADIUS server. If you are in doubt how to perform the configuration, please refer to the configuration guide of the specific RADIUS client in question. Important: The user experience is best for RADIUS clients supporting Challenge Response. If Challenge Response support is configurable on the RADIUS client, please enable it. 2. Start the NPS Management Console: a. Select Run in the Windows Start menu b. Enter nps.msc c. Click OK 3. The NPS Management Console is shown. 4. Now you must create all your RADIUS Clients in the NPS Management Console. If these have already been created beforehand, you can skip to step 9.

347 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 347 OF To create a RADIUS Client: a. Right-click the RADIUS Clients node. b. Select New RADIUS Client.

348 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 348 OF The New RADIUS Client dialog appears. a. Enter a friendly name of the RADIUS Client. b. Enter the IP address of the RADIUS Client. c. Enter and confirm the Shared Secret. It must match the shared secret configured on the RADIUS Client. d. Click OK.

349 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 349 OF The RADIUS Client that you have created will appear in the right-hand pane: 8. Repeat steps 5-7 if you need to create more RADIUS Clients. 9. This completes the configuration of RADIUS authentication using SMS PASSCODE. Please test each RADIUS client to make sure that RADIUS authentication works as expected. Note: By default, settings of Connection Request Policies (CRP) and Remote Access Policies (RAP) are ignored during SMS PASSCODE authentication. However, you can enable internal IAS/NPS logic to apply CRP/RAP settings (cf. section , page 352).

350 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 350 OF Advanced Configuration of the RADIUS Protection Component The sections above describe the standard configuration of SMS PASSCODE RADIUS Protection. This is usually sufficient. However, the SMS PASSCODE Configuration Tool located in the Windows Start Menu offers a graphical user interface for maintaining a number of advanced RADIUS settings which can be configured to tailor the RADIUS Protection component to your specific RADIUS authentication requirements. After opening the SMS PASSCODE Configuration Tool from the Windows Start Menu the application will display a number of tabs. Select the RADIUS Client Protection tab to configure the advanced RADIUS settings:

351 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 351 OF 407 The RADIUS Client Protection tab contains three sub-tabs: Authentication: This tab contains settings that affect the authentication behavior of the RADIUS Protection component. Please read section (page 352) for further details. Authorization: This tab allows to enable/disable the inclusion of a RADIUS authorization attribute in each RADIUS accept packet being sent to the RADIUS client on successful authentication, and to configure the authorization attribute. Please read section (page 358) for further details. Miscellaneous: This tab contains miscellaneous settings of the RADIUS Protection component regarding text encoding, challenge/response behavior and more. Please read section (page 362) for further details. The different tabs and settings are described in detail in the subsequent sections. IMPORTANT: Whenever you change any of the RADIUS Client Protection settings, you must restart the Internet Authentication Service (Windows Server 2003) or the Network Policy Server service (Windows Server 2008 and Windows Server 2012), before the changes take effect. The SMS PASSCODE Configuration Tool will automatically suggest performing this action for you when the changed settings are saved.

352 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 352 OF RADIUS Authentication Settings The Authentication tab contains several settings that allow modifying the standard authentication flow of the SMS PASSCODE RADIUS protection component. The standard authentication flow, defining the flow with all settings set to their default values, is defined as follows: SMS PASSCODE RADIUS Protection component Standard Authentication Flow 1. An Access Request packet containing a user name and a password is received from a RADIUS client. 2. The user origin is resolved. I.e. it is determined, whether the user is a local Windows user on the RADIUS server or an AD user in any available AD. In the latter case, both the local AD and any trusted ADs are searched. If the user origin cannot be resolved, then access is denied. Otherwise, the user account is found, and thereby the authentication provider is determined (either the local Windows authority or some AD controller). 3. Initial validation is performed, ensuring that: a. The user exists in the SMS PASSCODE database b. The user has not been locked out by SMS PASSCODE Access is denied, if any of these validations fail. 4. The password is verified against the authentication provider determined in step 2. Access is denied, if any of the following conditions are true: a. The user password is incorrect b. The user is locked out or denied access by the authentication provider c. The user password has expired d. The user password has been flagged Must change at next logon. 5. Internal IAS/NPS logic is skipped (i.e. all settings of the active Connection Request Policy and Remote Access Policy are ignored) 6. Now multi-factor authentication is performed according to the user s settings in the SMS PASSCODE database. Normally this will mean that a random OTP is generated and send by SMS to the user, and a Challenge Request is sent back to the RADIUS client. 7. The user receives the passcode and enters it. The RADIUS client forwards the passcode as a Challenge Response to the RADIUS server. 8. The RADIUS server verifies, whether the passcode received is valid or not, resulting in either an Access Accept or Access Reject packet being sent back to the RADIUS client, respectively. It is described below how you can modify the individual steps of the Standard Authentication Flow.

353 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 353 OF 407 The Authentication tab on the RADIUS Client Protection tab contains the following settings: The settings have the following purposes: a. Allow login when This setting controls the behavior of steps 4c and 4d of the Standard Authentication Flow. By default, the SMS PASSCODE RADIUS Protection component will reject an authentication attempt from a user using an expired password or using a password that has been flagged must be changed at next logon. However, you can change this behavior. This might make sense when a user is requesting remote access using a VPN connection. In this case it might

354 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 354 OF 407 be acceptable to give the user network access and in this way allow the user to renew/change the password. Password has expired: Check this setting to allow successful authentication with a password that has expired. Password must change: Check this setting to allow successful authentication with a password that has been flagged must change at next logon. b. Side-by-side This section contains settings that define how the SMS PASSCODE RADIUS Protection component will interact with the internal IAS/NPS logic. Changing these settings is typically required, if you need to set up a side-by-side scenario, where users can log in either using SMS PASSCODE or another RADIUS authentication system. However, changing the settings can also be required in other cases, where the internal IAS/NPS logic is required, e.g. if you would like to make use of the functionality provided by IAS/NPS through Connection Request Policies or Remote Access Policies / Network Policies. The following abbreviations are used below: CRP: Connection Request Policy RAP: Remote Access Policy (the term used in IAS) or Network Policy (the term used in NPS). IAS/NPS IL setting: The setting called Enable IAS/NPS internal Connection Request Policies execution in the Side-by-Side section. IL is an abbreviation for Internal Logic. SPV/type setting: The setting called Skip password validation for the following type of passwords in the Side-by-Side section. SPV is an abbreviation for Skip Password Validation. SPV/client setting: Setting e) SPV settings: The two settings SPV/type and SPV/client.

355 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 355 OF 407 The possible options for the IAS/NPS IL setting are: IAS/NPS IL setting Never Description The SMS PASSCODE RADIUS component takes full control of the authentication and performs a standard SMS PASSCODE multi-factor authentication. All internal IAS/NPS logic is skipped (as described in step 5 of the Standard Authentication Flow). This means that any settings of CRPs and/or RAPs will be ignored. This is the default setting. Always Step 5 of the Standard Authentication Flow is changed. Instead of skipping, authentication is now forwarded to the internal IAS/NPS logic. I.e. CRP and RAP settings will be applied. This means, that if the CRP is set to perform an authentication or is set to forward authentication to another RADIUS server, then this will be executed. Access is denied, if any CRP/RAP logic denies access, e.g. because authentication according to the CRP fails, or because access is not allowed according to the RAP. Otherwise, authentication will continue at step 6 of the Standard Authentication Flow. On failure only First steps 1-4 of the Standard Authentication Flow are executed normally. If the user has not been denied access so far, then the Standard Authentication Flow continues as defined by default. I.e. the same behavior as when the IAS/NPS IL setting is set to Never. However, if the user is denied access during any of the steps 2-4, then the internal IAS/NPS logic will be executed, and the remaining part of the Standard Authentication Flow will be skipped. In other words, CRP and RAP settings will be applied. Access is denied, if any CRP/RAP logic denies access, e.g. because authentication according to the CRP fails, or because access is not allowed according to the RAP. On the other hand, if the user is allowed to log in according to the CRP/RAP settings, then the user is granted access immediately (no multi-factor authentication by SMS PASSCODE in this case). IMPORTANT: If password validation according to step 4 of the Standard Authentication Flow is skipped due to the SPV/type setting or SPV/client setting, then steps 2-4 are treated as failed. WARNING: When using this setting, never set the CRP to allow access without validating credentials. This would grant access to users without any validation at all.

356 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 356 OF 407 The behavior can be modified additionally using the SPV/type setting: i. Empty (default): This setting has no effect. ii. Non-empty (password filtering): If you enter a regular expression into this field, SMS PASSCODE will check, on each authentication attempt, whether the regular expression matches the password entered 42. If it does not match, then the authentication continues normally. On the other hand, if there is a match, then step 4 of the Standard Authentication Flow is skipped altogether, meaning no password validation is performed. Instead, the password validation is immediately treated as failed. As a result, the following behavior is achieved with a matching password: IAS/NPS IL setting set to Never: The user is denied access. IAS/NPS IL setting set to Always: The user is denied access. IAS/NPS IL setting set to On Failure Only: The internal IAS/NPS logic will be applied, CRP and RAP settings are applied, and no multi-factor authentication is performed by SMS PASSCODE. Below, a number of use case scenarios are listed, and it is described how to set settings accordingly: Use case Required settings Standard SMS PASSCODE multifactor authentication should be performed for all users. Set the IAS/NPS IL setting to Never. No need for Remote Access Policy support Standard SMS PASSCODE multifactor authentication should be performed for all users. Support for Remote Access Policies is needed Set the IAS/NPS IL setting to Always. Set the CRP authentication setting to Authenticate on this server. 42 This is only supported, when the RADIUS client uses the PAP protocol. MS-CHAP v2 is not supported, since the password is not available in clear text for comparison in this case.

357 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 357 OF 407 Use case Required settings You have two different RADIUS authentication systems (SMS PASSCODE and another one). Set the IAS/NPS IL setting to On Failure Only Set the CRP authentication setting to forward requests to the other RADIUS system. Some users will only use one type of authentication, whereas some users might use both types of authentication. Optional: If the password for the other authentication system is NOT the user s AD password, and this authentication system is used often by users which are also created in the SMS PASSCODE database, then it can be a problem that AD password validation is attempted often with a wrong password. It could lead to a lockout of AD user accounts. To avoid this, you should enter a regular expression into the SPV/type setting that will identify the passwords of the other authentication system. On the other hand, if the users using the other authentication system are NOT created in the SMS PASSCODE database, then there is no problem, since SMS PASSCODE will not perform any AD password validations for non- SMS PASSCODE users. Standard SMS PASSCODE multifactor authentication should be performed for all users, except the users passwords should not be validated by AD, but by another RADIUS authentication system. This is useful, if you would like to use SMS PASSCODE for authentication of non-ad users Set the IAS/NPS IL setting to Always. Set the CRP authentication setting to forward requests to the other RADIUS system. Use the SPV/client setting to skip the initial validation of the password for all requests from the RADIUS client(s) in question c. Password validation In step 4 of the Standard Authentication Flow, SMS PASSCODE will by default validate user passwords using the WinNT provider (i.e. validating the user s Windows password). This will work for both AD users and local Windows users created on the RADIUS server. You can select Custom LDAP if you wish to validate user passwords against some specific LDAP attribute in the AD instead. Please specify the name of an existing LDAP attribute in the AD in this case. Custom LDAP validation will only work for AD users. When using Custom LDAP password validation, the IAS/NPS IL setting must be set to Never. NOTE: Custom LDAP password validation requires the RADIUS client to use the PAP protocol. MS-CHAP v2 is NOT supported.

358 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 358 OF 407 d. Default domains The Default domains setting is useful if you need to authenticate users from different domains, but do not wish to force the users to enter or select the domain explicitly during authentication. In case SMS PASSCODE RADIUS protection is authenticating a user with a user name that explicitly contains a domain using SAM (domain\username) or UPN format (username@domain), then the user is always authenticated in the domain specified. If no domain is specified explicitly, then SMS PASSCODE RADIUS protection will try to authenticate the user using the list of domains specified in the Default domains setting. Authentication is attempted according to the prioritized order of the domains in the list. Please note, that you can also specify the name of the RADIUS server itself in the list. This entry will cause the RADIUS server to authenticate the user as a local Windows user on the RADIUS server itself. Eventually, if authentication fails in all the specified domains or if the Default domains setting list is empty, SMS PASSCODE RADIUS protection will always make a last attempt to authenticate the user in the local domain, i.e. the domain that the RADIUS server is a member of. If the RADIUS server is a standalone server, then this last authentication attempt is performed using the local Windows user storage. e. Skip password validation This setting allows adding a list of RADIUS clients, specified by NAS IP, for which step 4 of the Standard Authentication Flow should be skipped during authentication. I.e. no password validation will be performed, unless internal IAS/NPS logic is enabled (cf. item b above). WARNING: Use this setting with great caution. It is only recommended to skip password validation for RADIUS clients that will check the user password by themselves, before the RADIUS request is sent to the RADIUS server, or if internal IAS/NPS logic is enabled and set to validate the password. NOTE: The RADIUS client is required to use the PAP protocol for this setting to work. MS-CHAP v2 is NOT supported RADIUS Authorization Settings When a user has been authenticated successfully by SMS PASSCODE RADIUS protection, a RADIUS Access-Accept packet is returned to the RADIUS client. This packet does NOT contain any authorization information by default. However, if your RADIUS client supports authorization, then you have two options for adding authorization information to the RADIUS Access-Accept packet: Enable the authorization feature of the SMS PASSCODE RADIUS protection component Enable the internal IAS/NPS logic during authentication and set the Remote Access Policy used to add authorization data. It is possible to use both features together, in which case both features will add authorization information as defined.

359 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 359 OF 407 This section describes how to configure the authorization feature of the SMS PASSCODE RADIUS protection component. When this authorization feature is enabled, SMS PASSCODE RADIUS protection will automatically determine the names of all AD groups that the authenticated user is a member of. All or some of these group names are then added to the RADIUS authorization attribute and sent along with the RADIUS Access-Accept packet to the RADIUS client. The RADIUS client can subsequently retrieve all these group names from the attribute and allocate permissions depending on the AD group memberships of the user. It is even possible to apply transformations to the AD group names if the RADIUS client expects specific group names that you do not wish to create in your AD. Authorization is configured on the Authorization tab on the RADIUS Client Protection tab:

360 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 360 OF 407 The settings have the following purposes: a. Authorization enabled This is the main setting to enable or disable authorization. i. Cleared (default): Authorization is disabled, i.e. no authorization attribute is included in any RADIUS accept packet. ii. Selected: Authorization is enabled, i.e. each RADIUS accept packet will contain an authorization attribute. The properties and content of the authorization attribute are defined using the settings below. b. Authorization attribute properties This group of settings defines the main characteristics of the authorization attribute. The default settings are the settings expected by a Citrix Access Gateway with default settings. Max size of attribute: Defines the maximum allowed size of the content of the authorization attribute in multiples of 249 bytes. I.e. a value of 4 (the default value) means 4 x 249 = 996 bytes. The content of the authorization attribute will be cut off if it exceeds the specified maximum size. Vendor code: Use this setting to specify a vendor code in case your RADIUS client expects a specific vendor code in the authorization attribute. Attribute number: Use this setting to specify an attribute number in case your RADIUS client expects a specific attribute number in the authorization attribute. Prefix/Separator: The content of the authorization attribute will have a format like this: [Prefix][Group1][Separator][Group2][Separator].[GroupN][Separator] Where [Group1], [Group2],,[GroupN] are the names of the AD groups that the authenticated user is a member of, and [Prefix] and [Separator] contain customizable content to be configured using the settings Prefix and Separator, respectively. E.g. if you set Prefix to CTXSUserGroups= and Separator to ; and the user is a member of 3 groups called OwaAccess, CitrixAccess and SharePointAccess, then the content of the authorization attribute will be like this: CTXSUserGroups=OwaAccess;CitrixAccess;SharePointAccess; c. Active Directory resolve provider This setting defines whether the Global catalog or LDAP should be used for retrieving the AD groups that the authenticating user is a member of. Please note, that only direct group memberships are retrieved. When using Global catalog, a single GC server will be contacted. When using LDAP, all necessary domain controllers that are available will be contacted even including child domains and trusted domains.

361 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 361 OF 407 d. Restrict groups collected into the authorization attribute SMS PASSCODE RADIUS protection will collect all direct group memberships by default and put the names of the groups into the authorization attribute. If your users have a lot of group memberships, the total length of the group names might exceed the maximum size of the RADIUS attribute, which will cause some of the group names to be cut off. Since you cannot predict which groups will be cut off, it might be better to select a restricted number of group names that you will actually need in your authorization attribute. This is just what the setting Restrict groups collected into the authorization attribute allows you to define. You can add a number of group names to the list which will cause SMS PASSCODE RADIUS protection to only collect group names from this list into the authorization attribute. Group name transformation: When entering group names into the restriction list, you may enter the group names in a special format to perform transformation of the group names. The entry is case sensitive, and the syntax is: [AD Group Name];[RADIUS Client Group Name] For example, if you have an AD group called Sales People and you would like to report the group OwaAccess to the RADIUS Client in this case, then you should add the following entry to the restriction list: Sales People;OwaAccess Only collect first matching group: If you check this setting, then SMS PASSCODE RADIUS protection will at most put one single group name into the authorization attribute. This will be the first group in the restriction list that the authenticated user is a member of. Restricting to a single group is useful if your RADIUS client will only accept a single value in the authorization attribute.

362 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 362 OF Miscellaneous RADIUS settings The remaining RADIUS settings are collected on the Miscellaneous tab on the RADIUS Client Protection tab:

363 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 363 OF 407 The settings have the following purposes: a. Text settings Code Page used for encoding: This setting specifies the Windows Code Page used for encoding input texts, i.e. user names, passwords and passcodes. If the RADIUS client uses a specific code page, please ensure to enter the same code page here. E.g. many Cisco VPN clients use code page If the code page of the RADIUS client and RADIUS server do not match, you might experience authentication problems for users using special characters in the user name or password. Custom challenge message: By default SMS PASSCODE RADIUS protection will send the message Enter PASSCODE when the user should enter the SMS PASSCODE on the RADIUS challenge. Using this setting you can change this message to a different text. This is useful for localization of the message or in case your RADIUS client will only accept specific text(s) in the RADIUS challenge. b. Only apply SMS PASSCODE authentication to the following Connection Request Policies By default SMS PASSCODE RADIUS protection will apply to all incoming RADIUS requests. However, if you wish to apply SMS PASSCODE authentication only to specific requests, you have the option to restrict SMS PASSCODE authentication to incoming requests matching specific Connection Request Policies defined in the IAS/NPS manager. c. Forced Challenge Response Clients / Clients not supporting challenge packets SMS PASSCODE RADIUS protection supports both RADIUS clients that support or do not support challenge/response. When the first request is received from a RADIUS client after the IAS/NPS service has started, the IAS/NPS service will auto-detect whether the RADIUS client supports challenge/response or not. If the client does not support challenge/response, then SMS PASSCODE authentication is performed in two steps, first validating the user password in a first RADIUS authentication and then validating the SMS PASSCODE in a second RADIUS authentication. This means a non-session-specific multifactor authentication is performed, opposite to a challenge/response multi-factor authentication, which will always be session-specific. If you do not wish to allow the auto-detection mechanism described above, you can enter the host names or IP addresses of RADIUS clients either into the Forced Challenge Response Clients list or into the Clients not supporting challenge packets list. RADIUS clients in these two lists will be forced to always or never use challenge/response, respectively. d. Do not send the state attribute to the following clients According to the RADIUS RFC, all RADIUS challenge packets should contain a state attribute (which is a session identifier). However, some RADIUS clients seem not to support this state attribute. In this case, you can add the host name or IP address of the RADIUS client to the Do not send the state attribute to the following clients list which will force SMS PASSCODE protection not to insert the state attribute. This is not recommended unless it is really required.

364 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 364 OF Configuring Cloud Application Protection The SMS PASSCODE Cloud Application Protection component allows you to apply SMS PASSCODE multi-factor authentication to cloud applications that have been configured to validate users by means of form-based authentication through AD FS 2.0. If you have already, before installing the SMS PASSCODE Cloud Application Protection component, successfully configured one or more cloud applications to use AD FS 2.0 form-based authentication, then you simply need to install the SMS PASSCODE Cloud Application Protection component on your AD FS 2.0 server(s), and SMS PASSCODE multi-factor authentication will be added to your cloud application(s) without any need of further actions. On the other hand, if you have not configured your cloud applications to use AD FS 2.0 form-based authentication yet, then it is recommended to do so, before installing the SMS PASSCODE Cloud Application Protection component, and to ensure that standard authentication works as expected Background It is becoming more and more common that cloud applications, also known as Service Providers, do not perform user authentication by themselves, but instead delegate the authentication to a 3 rd party authentication service, also known as an Identity Provider. To ensure that Service Providers and Identity Providers from different vendors can communicate with each other, different standards have been introduced for exchanging authentication and authorization data. Some of the most important of such standards are: SAML 2.0 WS-Trust WS-Federation Well-known examples of cloud applications using one of these standards are: Microsoft Office 365 Web Clients Google Apps SalesForce Microsoft has released a product called Active Directory Federation Services 2.0 (AD FS 2.0), which is a concrete example of an Identity Provider that supports all 3 of the standards mentioned above. AD FS 2.0 is useful for companies and organizations already relying on a Microsoft AD infrastructure, because it makes it possible to use the existing AD user accounts for authentication when accessing cloud applications. Windows Server 2008: AD FS 2.0 is available for download for free from Microsoft. It is supported on Windows Server 2008 (please look up current system requirements as specified by Microsoft). Windows Server 2012: AD FS 2.0 is a built-in feature in the Windows Server 2012 Standard and Datacenter editions. You must install the feature using the Server Manager.

365 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 365 OF AD FS 2.0 Infrastructure This section describes on which servers you should install the SMS PASSCODE Cloud Application Protection component. When deploying AD FS 2.0 you have several options, ranging from a single server configuration to an AD FS 2.0 server farm, possibly even including AD FS 2.0 Proxy servers for remote users. The typical scenario is: AD FS 2.0 Proxy servers are located in your perimeter network (DMZ) and will allow remote users to access cloud applications using form-based authentication. You should install the SMS PASSCODE Cloud Application Protection component on any of these proxy servers that supports authentication of a cloud application that you would like to protect with SMS PASSCODE multi-factor authentication. AD FS 2.0 servers on your internal network will be used for easy single sign-on to cloud applications for users already authenticated on your internal network. You will normally NOT install SMS PASSCODE Cloud Application Protection on these servers, unless you want to enforce multi-factor authentication in this case as well, or because you have no AD FS 2.0 Proxy servers in your infrastructure.

366 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 366 OF 407 An example of an installation setup is shown below: GSM Modem(s) LAN Firewall DMZ TCP 8988 TCP 8989 SMS PASSCODE Failover server SMS PASSCODE Load Balancing Service SMS PASSCODE Transmitter Service GSM Modem(s) TCP 8988 AD FS 2.0 Proxy Server SMS PASSCODE Cloud Application Protection TCP 8988 TCP 8989 TCP 9090 SMS PASSCODE Database Server SMS PASSCODE Database Service SMS PASSCODE Web Administration Interface SMS PASSCODE Load Balancing Service SMS PASSCODE Transmitter Service SMS PASSCODE Self Service Web Site (optional) AD FS 2.0 Proxy Server SMS PASSCODE Cloud Application Protection AD Sync. (optional) AD FS 2.0 Proxy Server SMS PASSCODE Cloud Application Protection Active Directory Server TCP 443 AD FS 2.0 Farm

367 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 367 OF 407 Another scenario is to make use of the Microsoft Unified Access Gateway (UAG) and let it act as an AD FS 2.0 Proxy server. In this case you must not use the SMS PASSCODE Cloud Application Protection component, but instead configure the UAG to authenticate using a RADIUS server protected by the SMS PASSCODE RADIUS Protection component (this component is described in section 19.2, page 343) Configuring ISA/TMG Web Site Protection The SMS PASSCODE ISA/TMG Web Site Protection component allows you to apply SMS PASSCODE multi-factor authentication to web sites that have been published through a Microsoft ISA Server 2006 or Microsoft Forefront TMG The following requirements must be fulfilled to apply SMS PASSCODE ISA/TMG Web Site Protection to a web site successfully: The web site has to be published using a Web Listener. The Web Listener used must be configured like this: i. Client Authentication Method = HTML Form Authentication. ii. Authentication Validation Method = Windows (Active Directory), LDAP (Active Directory) or RADIUS. iii. A Cookie Name must be specified for the Form Authentication. iv. SMS PASSCODE authentication must be enabled. The necessary actions to apply SMS PASSCODE ISA/TMG Web Site Protection to a web site are described in more detail below: 1. Open the ISA/TMG Management Console. 2. Create a new Web Site Publishing Rule to publish your web site through the ISA/TMG Server (if this has not been done yet). 3. Open the Properties dialog for the Web Listener assigned to the Web Site Publishing Rule.

368 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 368 OF Select the Authentication tab and ensure that a. The Client Authentication Method is set to HTML Form Authentication b. The Authentication Validation Method is set to either Windows (Active Directory), LDAP (Active Directory) or RADIUS. (It is not of importance whether the SMS PASSCODE tab is displayed or not in your case)

369 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 369 OF Select the Forms tab and click the Advanced button: 6. On the Advanced Form Options tab, enter a Cookie Name of your own choice and then click OK. 7. Save the new Web Listener settings and apply the changes to the ISA/TMG server configuration.

370 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 370 OF Ensure that the published web site is accessible (from the external network) with standard authentication (i.e. without SMS PASSCODE authentication). 9. Now enable SMS PASSCODE ISA/TMG Web Site Protection. To do this, open the Web Listener Properties dialog again. It is mandatory this time that the Properties dialog is opened through the Toolbox of the ISA/TMG Management Console 43 : IMPORTANT: Always access the Properties dialog of a Web Listener through the ISA/TMG Toolbox when you want to enable or disable SMS PASSCODE authentication for a Web Listener. The SMS PASSCODE tab will only appear if the Properties tab is accessed in this way. 43 This is required, because the ISA/TMG Management Console does not show custom tabs on the Properties dialog of a Web Listener if this dialog is opened from a Web Publishing Rule.

371 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 371 OF Select the SMS PASSCODE tab. a. Ensure that the SMS Passcode Compatibility text box shows the text Ok. This should be the case if all the preceding steps have been completed properly. If not, then the text box will contain a message describing which actions are missing. b. Select the Enable SMSPASSCODE authentication for the listener option. c. Optionally exclude specific URLs from multi-factor authentication. This is described in more detail in section below. d. Click the OK button 11. Apply the changes to the ISA/TMG server configuration. 12. Now check that the published web site is accessible (from the external network) with SMS PASSCODE authentication. This completes the procedure for applying SMS PASSCODE authentication to a web site published through an ISA/TMG server.

372 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 372 OF Excluding Specific URLs from Multi-Factor Authentication A site that is commonly published through an ISA/TMG server is the Exchange Client Access Server web site. This site gives users access to Outlook Web Access, but is also used for other related services like Outlook Anywhere (RPC over HTTP), ActiveSync and AutoDiscover. These related services do not support form-based multi-factor authentication. Therefore, if you intend to publish any of these services, you must disable SMS PASSCODE multi-factor authentication for the specific URLs used by these services. You can disable SMS PASSCODE multi-factor authentication for: a. RPC over HTTP This will disable SMS PASSCODE multi-factor authentication for any requests within the /rpc branch of the site b. Microsoft Server ActiveSync This will disable SMS PASSCODE multi -factor authentication for any requests within the /Microsoft-Server-ActiveSync branch of the site, thereby allowing ActiveSync devices to synchronize data. Since this opens a door for hackers to retrieve users s without the increased security provided by MFA, it is recommended to protect ActiveSync access by other means, e.g. using SMS PASSCODE Secure Device Provisioning (cf. section 18, page 314). c. AutoDiscover This will disable SMS PASSCODE multi -factor authentication for any requests within the /AutoDiscover branch of the site. d. Custom This section lets you disable SMS PASSCODE multi -factor authentication for any URLs of your own choice. Just enter a URL into the topmost textbox and click the Add button, to add the URL to the exclusion list. To remove an excluded URL from the list again, select the entry in the exclusion list and click the Remove button.

373 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 373 OF Configuring IIS Web Site Protection If you have installed the optional IIS Web Site Protection component on a server hosting Microsoft Outlook Web Access (OWA) or Microsoft RD Web Access, you will normally enable protection of the OWA or RD Web Access site during installation and will not have to make any further configuration changes afterwards. However, you may decide to perform further configuration of the IIS Web Site Protection component in the following cases: a. If a new web site is added to the IIS, then access to this site will by default be disallowed by the SMS PASSCODE IIS Web Site Protection component. In this case you have to refresh the IIS Web Site Protection configuration file to allow access to this web site. b. If you wish to protect other web sites than OWA or RD Web Access by SMS PASSCODE authentication, then you have to enable this manually. Please note, that the SMS PASSCODE IIS Web Site Protection component currently only supports protection of OWA sites, RD Web Access sites (Windows 2008 (R2) only) and web sites using Basic or Integrated Windows Authentication. c. If you wish to disable SMS PASSCODE authentication for specific web sites, then you can do this manually. d. The SMS PASSCODE IIS Web Site Protection component also offers advanced configuration options. E.g. it is possible to configure authentication rules depending on e.g. the clients source IP-addresses ISAPI Filter The SMS PASSCODE IIS Web Site Protection component is implemented using an ISAPI filter. This ISAPI filter is added to the IIS running on the server and extends the behavior of the IIS. The default path of the ISAPI filter is: C:\Program Files\SMS PASSCODE\ISAPI\SMSPasscodeISAPIFilter.dll ISAPI Filter Configuration File The behavior of the ISAPI filter is controlled by a XML configuration file. The default path of this configuration file is: C:\Program Files\SMS PASSCODE\ISAPI\Config.xml You can control the behavior of the ISAPI filter by making changes to this configuration file. The most common configuration changes are made easiest using the command line tool called IsapiAdmin. This tool is by default located here: C:\Program Files\SMS PASSCODE\ISAPI\IsapiAdmin.exe The syntax and usage of the IsapiAdmin tool is described in section below. Another way to change the configuration file is by making changes to this file manually using a text editor (e.g. Notepad). This allows for more advanced configuration changes. The syntax of the configuration file is described in detail in section

374 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 374 OF 407 IMPORTANT: Whenever changes are made to the ISAPI filter configuration file using the IsapiAdmin tool, these changes take effect immediately. Whenever changes are made to the ISAPI filter configuration file manually, these changes do not take effect until the SMS PASSCODE ISAPI Service has been restarted The IsapiAdmin Tool The default path of the command line tool IsapiAdmin is: C:\Program Files\SMS PASSCODE\ISAPI\IsapiAdmin.exe This tool has four main features: a. Enable SMS PASSCODE authentication for a specific web site on the local IIS. b. Disable SMS PASSCODE authentication for a specific web site on the local IIS. c. Refresh the ISAPI filter configuration file, allowing access to all newly added web sites on the local IIS. d. List the web sites on the local IIS. The following sub-sections describe the syntax of the IsapiAdmin tool Enable Protection of a Web Site To enable SMS PASSCODE authentication for a specific web site, use the -protect option in one of the following two ways: - or - IsapiAdmin -protect -name Web Site Name [-DirName Virtual Dir Name ] [-owa [-allowactivesync] [-allowautodiscover] [-allowrpcoverhttps] -rdweb] IsapiAdmin -protect -siteid Web Site ID [-DirName Virtual Dir Name ] [-owa [-allowactivesync] [-allowautodiscover] [-allowrpcoverhttps] -rdweb]

375 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 375 OF 407 The different arguments of the command are described in the table below. Argument -protect -name Description This argument instructs the tool to protect a web site. This argument is used to specify the name of the web site to protect. Example: IsapiAdmin -protect -name Default Web Site -siteid This argument is used to specify the ID of the web site to protect. The default web site always has ID 1. Example: IsapiAdmin -protect -siteid 1 Use IsapiAdmin list to get a list of the IDs of the different web sites (described in section , page 378). -DirName (optional) This optional argument is used to specify the name of the virtual directory that is created within the web site that is being protected. This virtual directory contains files needed by the ISAPI filter. If the argument is not present, the default name SmsPasscodeLogon is used. Example: IsapiAdmin -protect -name Default Web Site -DirName MyName" -owa (optional) -allowactivesync (optional) -allowautodiscover (optional) -allowrpcoverhttps (optional) -rdweb This argument is required if the web site is an OWA Web Site using formbased authentication. For web sites using Basic or Integrated Windows Authentication, please omit this argument. This argument is only allowed together with the -owa argument. It instructs the ISAPI filter to disable SMS PASSCODE authentication for ActiveSync connections. This argument is only allowed together with the -owa argument. It instructs the ISAPI filter to disable SMS PASSCODE authentication for ActiveSync AutoDiscover requests. This argument is only allowed together with the -owa argument. It instructs the ISAPI filter to disable SMS PASSCODE authentication for RPC over HTTP/HTTPS connections. This argument is required if the web site is an RD Web Access site using form-based authentication. For web sites using Basic or Integrated Windows Authentication, please omit this argument. Please note that in order to protect an RD Web Access site, additional actions are required (cf. section , page 61).

376 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 376 OF 407 Examples: Enable SMS PASSCODE authentication for an OWA site using form-based authentication, allow ActiveSync, disallow RPC over HTTP/HTTPS connections: IsapiAdmin -protect name Default Web Site -owa -allowactivesync...or since the Default Web Site always has ID 1, you could also enter: IsapiAdmin -protect siteid 1 -owa -allowactivesync Enable SMS PASSCODE authentication for the SMS PASSCODE Web Administration Interface: IsapiAdmin protect name SMS PASSCODE Admin Enable SMS PASSCODE authentication for an OWA site using Basic or Integrated Windows Authentication: IsapiAdmin protect name Default Web Site Disable Protection of a Web Site To disable SMS PASSCODE authentication for a specific web site, use the -unprotect option in one of the following two ways: - or - IsapiAdmin -unprotect -name Web Site Name IsapiAdmin -unprotect -siteid Web Site ID The different arguments of the command are described in the table below. Argument -unprotect -name Description This argument instructs the tool to disable protection of a web site. This argument is used to specify the name of the web site to unprotect. Example: IsapiAdmin unprotect name Default Web Site -siteid This argument is used to specify the ID of the web site to unprotect. The default web site always has ID 1. Example: IsapiAdmin unprotect siteid 1 Use IsapiAdmin list to get a list of the IDs of the different web sites (described in section , page 378).

377 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 377 OF 407 Examples: Disable SMS PASSCODE authentication for an OWA site: IsapiAdmin unprotect name Default Web Site...or since the Default Web Site always has ID 1, you could also enter: IsapiAdmin unprotect siteid 1 Disable SMS PASSCODE authentication for the SMS PASSCODE Web Administration Interface: IsapiAdmin unprotect name SMS PASSCODE Admin Refresh the Configuration File The ISAPI filter configuration file specifies, for each web site, whether SMS PASSCODE authentication is enabled or disabled. However, if a new web site is added to the local IIS, and this web site is not listed in the ISAPI filter Configuration file, then the ISAPI filter will disallow access to this site. If you try to access the web site, then you will see the following error message: To allow access to the web site, you must either enable or disable SMS PASSCODE authentication as described above in section or , respectively. Another possibility is to use the refresh option using the following syntax: IsapiAdmin refresh Executing this command will automatically detect all web sites present in the local IIS and add all missing web sites to the ISAPI filter configuration file. All missing web sites are added with SMS PASSCODE authentication disabled.

378 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 378 OF List ID of Web Sites The IsapiAdmin command line tool also has a feature for showing a list of all web sites present in the local IIS. This list displays the name and ID of each site. The syntax for showing the list of web sites is: IsapiAdmin list ISAPI Filter Configuration File Syntax The configuration of the ISAPI filter is stored in a XML configuration file. The default path of this file is: C:\Program Files\SMS PASSCODE\ISAPI\Config.xml The following subsections describe the anatomy (syntax) of this file in detail. IMPORTANT: Whenever changes are made to the ISAPI filter configuration file manually, these changes do not take effect until the SMS PASSCODE ISAPI Service has been restarted <CONFIG> Element At the top level, the configuration file contains one <CONFIG> element, which again contains one or more <SITE> elements. <CONFIG> <SITE />... <SITE /> </CONFIG> The configuration file must contain a <SITE> element for each web site in the local IIS <SITE> Element Each site element of the configuration file contains the settings for a specific web site in the local IIS: <SITE name= Web Site Name smspasscodedir= virtual dir name > <URL />... <URL /> </SITE> Each SITE element contains the following attributes: name: Specifies the name of the web site that is configured by this <SITE> element. smspasscodedir: Specifies the URL of the virtual directory containing the files that are needed by the SMS PASSCODE ISAPI filter during SMS PASSCODE authentication. Recommended value is /SmsPasscodeLogon/. It is recommended to enable SMS PASSCODE authentication for a web site using the IsapiAdmin tool because this tool will

379 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 379 OF 407 automatically create the required virtual directory and configure it correctly (please read section , page 374). SMS PASSCODE authentication is enabled by default for each web site that is named by a SITE element. However, each SITE element may contain one or more <URL> elements that configure authentication behavior of the web site <URL> Element The <URL> elements within a <SITE> element define the authentication behavior of the web site. The syntax is: <URL path= URL path smspasscode= true false type= authentication type credentials= credentials source > <HOST />... <HOST /> </URL> Each <URL> element contains the following attributes: path: Specifies the URL that this element applies to. Please note, that the configuration of this element applies to all sub-urls as well, unless these are overruled by another, more specific <URL> element. smspasscode: Boolean attribute defining whether SMS PASSCODE authentication should be enabled (smspasscode= true ) or disabled (smspasscode= false ) for the specified URL. type / credentials: These are optional attributes. These attributes should not be specified for web sites or virtual directories that are using Basic or Integrated Windows Authentication. For OWA sites using form-based authentication, type= FormAuthentication and credentials= OWA should be specified for the following virtual directories: o /exchange o /exchweb o /owa For RD Web Access sites using form-based authentication, type= FormAuthentication and credentials= rdweb should be specified for the following virtual directories: o /rdweb Normally, you will not set the attributes type and credentials manually. Use the tool IsapiAdmin with the -owa or -rdweb option to protect an OWA site or RD Web access site, respectively (please read section , page 374) <HOST> Element Each <URL> element may contain one or more <HOST> elements. Using a <HOST> element you can override the configuration of the parent <URL> element depending on the client s source IP address. The syntax is: <HOST ip= x.x.x.x smspasscode= true false />

380 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 380 OF 407 I.e. each <HOST> element contains the following attributes: ip: Specifies the source IP address of the client(s) that this element applies to. Wildcards are allowed, e.g. ip= *. Also, you may specify ip= localhost ; in this case the element applies to all requests from the local host, no matter if the requests are coming from IP address or from any other locally assigned IP address. smspasscode: Boolean attribute defining whether SMS PASSCODE authentication should be enabled (smspasscode= true ) or disabled (smspasscode= false ) for the specified client(s) Configuration Examples This section shows different examples for configuring web sites: Enable SMS PASSCODE authentication for the default web site: <CONFIG> <SITE name= Default Web Site smspasscodedir= /SmsPasscodeLogon/ > <URL path= / smspasscode= true /> <URL path= /SmsPasscodeLogon smspasscode= false /> </SITE> </CONFIG> Disable SMS PASSCODE authentication for the default web site: <CONFIG> <SITE name= Default Web Site smspasscodedir= /SmsPasscodeLogon/ > <URL path= / smspasscode= false /> </SITE> </CONFIG> Enable SMS PASSCODE authentication for the default web site, but only for the URL s starting with /secure : <CONFIG> <SITE name= Default Web Site smspasscodedir= /SmsPasscodeLogon/ > <URL path= / smspasscode= false /> <URL path= /secure smspasscode= true /> </SITE> </CONFIG> Enable SMS PASSCODE authentication for the default web site, but not for clients requesting from IP addresses *: <CONFIG> <SITE name= Default Web Site smspasscodedir= /SmsPasscodeLogon/ > <URL path= / smspasscode= true > <HOST ip= * smspasscode= false /> </URL> </SITE> </CONFIG>

381 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 381 OF 407 Enable SMS PASSCODE authentication for an OWA site using form-based authentication: <CONFIG> <SITE name= Default Web Site smspasscodedir= /SmsPasscodeLogon/ > <URL path= / smspasscode= false /> <URL path= /exchange smspasscode= true type= FormAuthentication credentials= OWA /> <URL path= /exchweb smspasscode= true type= FormAuthentication credentials= OWA /> <URL path= /OWA smspasscode= true type= FormAuthentication credentials= OWA /> <URL path= /rpc smspasscode= true > <host ip= localhost smspasscode= false > </URL > </SITE> </CONFIG>

382 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 382 OF Configuring Windows Logon Protection If you have installed the optional SMS PASSCODE Windows Logon Protection component, you will normally not have to perform any further configuration of this. The Windows Logon Protection component is implemented by means of a custom GINA for Windows XP and Windows Server 2003, and by means of a custom Credential Provider for Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows Server 2008 (R2) and Windows Server 2012 (R2). IMPORTANT (Windows XP / Windows Server 2003) When installing the Windows Logon Protection component on Windows XP or Windows Server 2003, please remember to restart the computer after installation. The new GINA will not work correctly before the system has been rebooted. Ensure that all necessary SMS PASSCODE users have been created BEFORE the system is rebooted. If the system is rebooted before any SMS PASSCODE users have been created, only local administrators will be able to log on, and only locally using the console not using remote access by RDP! Windows Logon User Exclusion Groups You may optionally configure users who should be excluded from SMS PASSCODE authentication during Windows Logon. To support this, two local 44 user groups have been created on the computer during installation: SMS PASSCODE console exclusion: All users being member of this group are subject to the following rules: o They must authenticate using SMS PASSCODE when they log on to the computer using Terminal Service (RDP). o They will not authenticate using SMS PASSCODE when they log on locally using the console. I.e. only user name and Windows password is required to log on in this case. SMS PASSCODE general exclusion: All users being member of this group will log on to the computer without SMS PASSCODE authentication whether they log on using Terminal Service (RDP) or locally using the console. By default, all users being member of the local Administrators group are automatically added during installation to the SMS PASSCODE console exclusion group. This ensures that local administrators will always be able to log on using the local console Windows Logon Lock Time (GINA only) By default, SMS PASSCODE authentication is activated on every Windows Logon and also every time the user s session has been locked and the user wishes to unlock it. On Windows XP and Windows Server 2003 (GINA only) you can change this behavior if you do not wish the SMS 44 The groups are created as AD groups when the SMS PASSCODE Windows Logon Protection component is installed on a Domain Controller. Still, the groups only have effect on Windows Logon on the local computer.

383 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 383 OF 407 PASSCODE authentication to become active immediately whenever the user s session has been locked. To do this, start the SMS PASSCODE Configuration Tool from the Windows Start Menu and select the Windows Logon Protection tab, where you can configure the time to pass after a session has been locked, before SMS PASSCODE authentication is required. A value of 0 will provide the default behavior, i.e. SMS PASSCODE authentication is required whenever a locked session is unlocked. If you select a value of e.g. 5, then the SMS PASSCODE authentication will not become active until 5 minutes after the user s session was locked. If the user tries to unlock his session before 5 minutes have passed, the user is allowed to unlock the session using user name and Windows password only i.e. without entering a passcode.

384 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 384 OF 407 IMPORTANT Whenever you change the Locked session re-authentication timeout setting, the new value does not take effect until the computer has been restarted Remote Desktop Logon Timeout (CP only) On machines using the SMS PASSCODE Credential Provider (all supported operating systems except Windows XP and Windows Server 2003), any RDP access to the machine will by default terminate within 30 seconds, if the Remote Desktop Logon has not completed within this time limit. This might be a problem when you are using SMS PASSCODE Windows Logon Protection, and you in some cases expect completion of SMS PASSCODE multi -factor authentications to take longer than 30 seconds; for example in case of using advanced Load Balancing Policies, where a second OTP is sent to the user, in case the first one expires. To extend the Remote Desktop Logon Timeout, select the Windows Logon Protection tab in the SMS PASSCODE Configuration tool, and select an appropriate timeout value in the top of the tab: IMPORTANT Whenever you change the Remote Desktop Logon Timeout setting, the new value does not take effect until the computer has been restarted.

385 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 385 OF RDP Listener Exclusion Whenever you log on to a Windows session on a Windows machine, your session is established through a specific WinStation. The most common WinStations are Console and Rdp-Tcp. The Console WinStation is used when logging on using the local console, whereas the Rdp-Tcp WinStation is used when logging on using an RDP connection (tcp port 3389 by default). The Rdp- Tcp Winstation is also called an RDP Listener. You can see which WinStation has been used to establish each session on a machine by inspecting the Users tab in the Task Manager. Each session will be named using the name of the corresponding WinStation. By default, when SMS PASSCODE Windows Logon Protection has been installed on a computer, all Windows sessions will be protected using SMS PASSCODE authentication, unless SMS PASSCODE authentication is skipped due to the rules of exclusion groups (cf. section , page 382). However, it is also possible to disable SMS PASSCODE Windows Logon Protection for individual WinStations. E.g. you can disable Windows Logon Protection for the Console WinStation to disable SMS PASSCODE authentication for all local console logons, independent of group exclusion membership; or you can disable Windows Logon Protection for individual RDP Listeners, in case you have created some custom RDP Listeners by yourself. WinStations / RDP Listeners exclusion is configured on the Windows Logon Protection tab of the SMS PASSCODE Configuration Tool:

386 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 386 OF Creating a custom RDP Listener You can create new custom RDP Listeners on a Windows machine. Why would you like to do this? It might, for example, be useful in the following scenario: A machine is accessible through RDP, but you only want users to be authenticated by SMS PASSCODE Windows Logon Protection when users are logging on from the external network. When logging on from the internal LAN, users should be allowed to log on using standard Windows authentication. This can be achieved using the following setup: On the target machine: Create a new RDP Listener and assign a non-standard RDP port to this listener, e.g. port Configure your firewall to allow access on port 4000 from the external network. Configure your firewall to use Network-Address-Translation (NAT) regarding all RDP requests on port 4000 from the external network. NAT should be configured to transfer all RDP requests from port 3389 to port This means that all external RDP requests will connect to the target machine using the new custom RDP Listener. Exclude the standard RDP Listener from SMS PASSCODE Windows Logon Protection. Using this setup all users on the internal LAN can make a standard RDP connection (using TCP port 3389) to the standard RDP Listener on the target machine and will be allowed to log in using standard Windows authentication, because the standard RDP Listener has been excluded from SMS PASSCODE Windows Logon Protection. All external requests will hit the target machine using the custom RDP Listener (on TCP port 4000), i.e. these users are required to perform SMS PASSCODE authentication to establish a Windows session on the target machine. The scenario above is also possible without configuring NAT in the firewall. But in this case, the external users will manually have to change the TCP port of the RDP connection to the TCP port of the custom RDP Listener. To create a custom RDP Listener, please follow this procedure: 1. Make a backup of your registry. 2. Open the registry using regedit.exe. 3. Locate the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp Right-click the key and export it to a file. 4. Open the exported file. Change the name of the key RDP-Tcp to a new name of own choice. This will be the name of the custom RDP Listener. Also change any other required settings, e.g. PortNumber. Save the file. 5. Import the modified file into the registry. The registry will now contain a new key with the name of the custom RDP Listener. This new key is located below the key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations

387 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 387 OF Credential Provider Filtering On Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows Server 2008 (R2) and Windows Server 2012 (R2), the SMS PASSCODE Windows Logon Protection component is implemented by means of a custom Credential Provider. Please notice, that the SMS PASSCODE installation will automatically disable all other installed credential providers 45 by default, restricting users to log on only using SMS PASSCODE authentication. If you wish to allow users to log on using other installed Credential Providers, you can enable these Credential providers on the Windows Logon Protection tab of the SMS PASSCODE Configuration Tool: 45 Actually the SMS PASSCODE installation might leave some specific 3rd party credential providers enabled that are known to co-exist with SMS PASSCODE without disabling or conflicting with SMS PASSCODE authentication during the Windows Logon. The VMware Credential Provider installed on VMware View 4.0 clients is an example of this.

388 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 388 OF GINA Chaining On Windows XP and Windows Server 2003, the SMS PASSCODE Windows Logon Protection component is implemented by means of a custom GINA. The SMS PASSCODE GINA supports GINA chaining i.e. you can install the SMS PASSCODE GINA together with other 3rd party GINAs on the same computer, thereby building a GINA chain. It is very important to keep track of the order of installation and uninstallation of the different GINAs when making use of GINA chaining. Please observe the following rules: GINAs are activated in opposite order of installation. I.e. the GINA installed last will be the GINA activated first when Windows Logon is requested. GINA s must always be uninstalled in opposite order of installation. I.e. the GINA installed last must be uninstalled first. The GINA chain is broken if this rule is not observed. All GINAs must support GINA chaining except the GINA installed first. The GINA chain is broken if this rule is not observed Please contact your SMS PASSCODE reseller or SMS PASSCODE A/S if you would like to get more information regarding GINA chaining. 20 CONFIGURATION TOOL The SMS PASSCODE Configuration Tool is used to configure machine specific SMS PASSCODE settings. It is located in the Windows Start Menu:

389 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 389 OF 407 When you start this tool, you will see a number of tabs: The actual number of tabs shown depends on the current configuration and the components that have been installed. The different tabs have the following purposes: Tab Database Explanation You can specify the server on this tab that the SMS PASSCODE database service is located on. This tab also contains a button Test Connection which will perform a test whether the connection to the specified database server operates properly. On the server with the SMS PASSCODE Database component installed, this tab also includes an option for enabling strong encryption of the SMS PASSCODE database (cf. section 20.1). Transmission This tab appears when an SMS PASSCODE authentication client or SMS PASSCODE Password Reset Backend Service has been installed. Using this tab, you can specify whether the authentication client(s) or PRBS on the local machine should communicate directly with SMS PASSCODE Transmitter hosts or with SMS PASSCODE Load Balancing hosts. Also, the priority is specified, i.e. in which order the authentication client(s) should attempt to communicate with the specified hosts. This tab also contains a button Test Connection which will perform a test whether the connections to the specified hosts operate properly.

390 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 390 OF 407 Tab Network End-user IP Password Reset Windows Logon Protection RADIUS Client Protection Import/Export Explanation On this tab you can specify which TCP ports should be used by the different SMS PASSCODE components, and specify a shared secret (password) that is used for encrypting all communication between the different machines with SMS PASSCODE components installed. Please ensure that the TCP ports and shared secret are configured identically on all involved SMS PASSCODE machines. If this is not observed, communication between the machines will fail. This tab appears only when at least one SMS PASSCODE authentication client or the SMS PASSCODE Password Reset Module has been installed on the local machine. The tab allows you optionally to enable collection of end-user IP addresses. Collection of end-user IP addresses is required if you would like to make use of location and behavior aware authentication. Please read section 20.2 (page 392) for more details. This tab appears only when the SMS PASSCODE Password Reset Web Site and/or SMS PASSCODE Password Reset Backend Service component has been installed on the local machine. The tab allows configuring different settings related to the PRWS and PRBS components. Please read sections (page 301) and (page 309), respectively, for more details. This tab appears only when SMS PASSCODE Windows Logon Protection has been installed on the local machine. The tab allows configuring different settings related to the Windows Logon Protection component. Please read section 19.6 (page 382) for more details. This tab appears only when SMS PASSCODE RADIUS Protection has been installed on the local server. The tab allows configuring different settings related to the RADIUS Protection component. Please read section (page 350) for more details. This tab allows importing and exporting all settings configured in the SMS PASSCODE Configuration Tool. You can either export all settings to a text file or import settings from a text file. This might be useful for backup purposes or for transferring settings from one machine to another one. When exporting settings that include a shared secret, you will be prompted to enter a password that is used for protecting (encrypting) the shared secret in the text file. This password will be requested, when you try to import the settings file. Please note, that it is possible to import and export settings from the command line (e.g. from a batch file or login script). This is useful, if you would like to mass-import SMS PASSCODE settings to a large number of machines, e.g. when protecting virtual machines like VMware View clients with SMS PASSCODE Windows Logon Protection, and you need to apply the same network settings including a shared secret to all these clients. The syntax for importing and exporting settings is described in section 20.3 (page 395).

391 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 391 OF DB Encryption On a server with the SMS PASSCODE Database component installed, the Database tab of the SMS PASSCODE Configuration Tool includes an option for enabling strong encryption of the SMS PASSCODE database files. To enable encryption, proceed as follows: a. Select the checkbox Encrypt database b. Enter an encryption password c. Click the Save button

392 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 392 OF 407 To disable encryption, clear the Encrypt database checkbox and click the Save button. You will be asked to enter the same encryption password again that was used when enabling the encryption. IMPORTANT: When enabling encryption of the SMS PASSCODE Database, please make sure to keep the encryption password in a safe place. Without this password, you will not be able to disable encryption again or to perform a disaster recovery afterwards. Encryption can be enabled, no matter if the SMS PASSCODE Database service is running or is stopped. If the database service is running, encryption will be enabled on-the-fly, i.e. there is no need to restart the database service. Disabling encryption is only possible while the SMS PASSCODE Database service is running. Decryption of the database files will occur on-the-fly, i.e. there is no need to restart the database service Collecting End-User IP Addresses The tab End-user IP of the SMS PASSCODE Configuration Tool allows you to configure, whether any locally installed SMS PASSCODE authentication clients or a locally installed SMS PASSCODE Password Reset Module should collect end-user IP addresses during authentication attempts. By default, collection of end-user IP addresses is disabled for all clients and the Password Reset Module. However, if you would like to make use of location and behavior aware authentication (cf. section 14.1, page 101) a pre-requisite is that end-user IP addresses must be collected and reported to the SMS PASSCODE backend. Enabling collection of end-user IP addresses can be done independently for any authentication client and Password Reset Module installed locally. WARNING: Enabling collection of end-user IP addresses should only be done by network experts having a deep understanding whether the IP addresses are collected correctly in a trustworthy manner.

393 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 393 OF 407 The End-user IP tab only appears, if at least one SMS PASSCODE authentication client or the SMS PASSCODE Password Reset module is installed locally. The tab will show a list of the clients available for configuration. For example, if SMS PASSCODE RADIUS protection, Windows Logon protection and Password Reset Module are installed locally, the tab will look like this: The drop-down boxes are used to select the End-user IP source independently per client. The possible options for selection are: End-user IP source option Do not collect Network connection Explanation This is the default option. In this case, the client will NOT collect any end-user IP addresses. Instead, all authentication attempts will have an unknown end-user IP. This option configures the client to report the end-user IP address according to the IP address of the source socket of the network connection. This is the recommended option, but only in case your network infrastructure is configured in such a way that the client recognizes the real end-user IP address. When selecting this option, it is recommended to perform some initial tests from different internal and external IP sources to ensure, that the correct IP addresses are reported.

394 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 394 OF 407 End-user IP source option HTTP Header Explanation This option is only available for the SMS PASSCODE authentication clients hosted by a Microsoft Internet Information Server (IIS), meaning: SMS PASSCODE Citrix Web Interface Protection SMS PASSCODE IIS Web Site Protection SMS PASSCODE Cloud Application Protection SMS PASSCODE Secure Device Provisioning (ActiveSync Provisioning) SMS PASSCODE Password Reset Module In this case, you may configure the authentication client to collect the end-user IP address from an HTTP header of your own choice. By default, the header X- forwarded-for is suggested, but you can enter any other name into the textbox, that appears: This option should be used, when the authentication client is located behind a reverse proxy that hides the real end-user IP address, but at the same time stores the original end-user IP address into an HTTP header. Examples of such reverse proxies are Citrix Secure Gateway/Citrix Access Gateway Standard 46, Bluecoat 47 and Netscaler 48. When selecting this option, it is recommended to perform some initial tests from different internal and external IP sources to ensure, that the correct IP addresses are reported. WARNING! Take great care, when using this option. Only use this option, when you have ensured that the specified HTTP header is always set by an internal network device under your control, e.g. a reverse proxy. If this is not ensured, a hacker might set the specified HTTP header value, thereby faking an incorrect end-user IP address. 46 HTTP header X-forwarded-For is hard-coded and enabled by default 47 Please read KB2996 on for how to enable 48 Please check for how to enable

395 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 395 OF Command Line Arguments The SMS PASSCODE Configuration Tool can be started from a command line. The executable is named Config.exe. It is located in the SMS PASSCODE installation folder, which by default is: C:\Program Files\SMS PASSCODE When starting the Configuration Tool from a command line, you may specify some optional arguments. To export all current settings, use the following syntax: Config.exe -export: filename [-password: password ] [-quiet] To import settings from a file, use this syntax: Config.exe -import: filename [-password: password ] [-quiet] The command line arguments are described in the table below: Argument -export: filename -import: filename -password -quiet Description This argument instructs the configuration tool to export all current settings to the file with the name filename. Please remember to use quotes if the filename contains spaces. This argument instructs the configuration tool to import settings from the file with the name filename. Please remember to use quotes if the filename contains spaces. This optional argument specifies the password for encrypting and decrypting the shared secret during export and import, respectively. The password must contain at least 5 characters. This argument is only required if the exported/imported settings contain a shared secret. This argument instructs the configuration tool to perform the requested action quietly, i.e. without any user interaction. Examples: Open the Configuration Tool and export all current settings to a file named mysettings.xml. Encrypt the shared secret using the password 12345: Config.exe -export: mysettings.xml -password: Export all current settings to a file named mysettings.xml. Encrypt the shared secret using the password Perform the action quietly, i.e. do not open the Configuration Tool: Config.exe -export: mysettings.xml -password: quiet

396 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 396 OF 407 Open the Configuration Tool and import settings from a file named mysettings.xml. Decrypt the shared secret using the password 12345: Config.exe -import: mysettings.xml -password: Please note, that this will import the settings to the Configuration Tool user interface without actually saving them. I.e. you will have the chance to inspect all the imported settings before clicking the Save button and applying the settings. Import settings from a file named mysettings.xml. Decrypt the shared secret using the password Perform the action quietly, i.e. do not open the Configuration Tool, but instead apply all imported settings right away: Config.exe -import: mysettings.xml -password: quiet 21 ADD/REMOVE COMPONENTS If you wish to add or remove some components from the SMS PASSCODE installation, you can always run the SMS PASSCODE installation again as often as you like. In this way you can add or remove core components and/or SMS PASSCODE Authentication Clients. To add/remove components, simply run the SMS PASSCODE installation program again just as you would do during a first-time installation. You will notice that a different dialog is shown in this case: Please select Modify in this dialog and click the Next button. After this, follow the same procedure as you did during first-time installation.

397 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 397 OF BACKUP AND RECOVERY This section describes what files to backup to be able to perform a recovery of an SMS PASSCODE installation Backup of Database Files The most important thing to backup is the SMS PASSCODE database. The database files are normally located on the server where the SMS PASSCODE Database component is installed (unless the database location has been moved to a file share). The default location of the folder containing the SMS PASSCODE database files is: C:\Program Files\SMS PASSCODE\Database You should backup all files located in this folder. The folder should contain at least two files: The main database file: SMSPASSCODE_DB.xml: The database transaction log file: SMSPASSCODE_DB_TRANSLOG.xml: The procedure for a database recovery depends on the fact, whether encryption was enabled for the backed up database files or not (cf. section 20.1, page 391). If the backed up database files are not encrypted, or if the backed up files are encrypted, but are being restored to the same server as they were backed up from (with the same encryption password still in place), then the procedure for a database recovery is quite simple: 1. Stop the SMS PASSCODE database service. 2. Restore both the main database file and the database transaction log file from your backup 3. Start the SMS PASSCODE Database service. On the other hand, if the backed up files were encrypted and should now be recovered to a new database server, then proceed as follows: 1. Install the SMS PASSCODE Database service on the new server (if not already done) 2. Stop the SMS PASSCODE database service. 3. Using the SMS PASSCODE Configuration Tool, enable database encryption and enter the same encryption password as used previously (i.e. the encryption password used, when the database files were backed up). 4. Restore both the main database file and the database transaction log file from your backup 5. Start the SMS PASSCODE Database service. IMPORTANT: If you have enabled encryption of your SMS PASSCODE Database using the SMS PASSCODE Configuration Tool (cf. section 20.1, page 391), then it is very important to keep the encryption password in a safe place. You might need it in case of a recovery.

398 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 398 OF Backup of Configuration Tool Settings On every server containing any SMS PASSCODE component you can use the SMS PASSCODE Configuration Tool to set server specific configuration settings. If you want a backup of these settings, you should use the Configuration Tool on each server to export the settings to a file, and then store these files in a safe place. In case of a recovery, the Configuration Tool must be used to import the previously exported files. Please read section 20 (page 388) for a description of the Configuration Tool export and import feature Backup of Authentication Monitoring Archive If you have enabled the Authentication Monitoring feature on the General Settings page of the WAI (cf. section , page 115), then it is recommended to back up the archive as well, in case the archived data is of importance to you. If the archiving feature is set to store archived data to either CSV or XML files, then you simply need to back up all files stored in the archive folder, which is defined on the General Settings page as part of the archiving setup. The default path to the archive folder is: C:\Program Files\SMS PASSCODE\Database\Archive Please note, that there is no automatic clean-up of the files in the archive folder. You should plan to remove the old files that are outdated according to the policy of your organization. If the archiving feature is set to store archived data to an SQL Server, then you must back up the destination table, which is defined on the General Settings page as part of the archiving setup. Please refer to the manual of your backup software regarding the procedure of backing up data from an SQL Server. Remember to ensure, that the SQL transaction log of the archive database is shrinked on a regular basis, preferable after each backup Backup of Auto Templates If you are using the SMS PASSCODE Self Service Web Site and have enabled the auto feature, you also have the opportunity to customize the content of these s (cf. section , page 276). If you have performed any such customization, then it is recommended to perform a backup of the customized template files. The template files are located on the server where the SMS PASSCODE Database component is installed. The default location of the folder containing the template files is: C:\Program Files\SMS PASSCODE\Templates You should backup all files located in this folder. In case of a recovery of the template files, please proceed as follows: 1. Stop the SMS PASSCODE database service. 2. Restore the backup of the template files. 3. Start the SMS PASSCODE Database service.

399 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 399 OF TROUBLESHOOTING This section describes some common errors and the corresponding solutions: No SMS is received during SMS PASSCODE authentication: Section 23.1 (page 400) Error message Unknown user is shown during authentication: Section 23.2 (page 402) Component communication problems: Section 23.3 (page 402) Active directory integration does not work as expected: Section 23.4 (page 403) Users cannot save changes in the Self-Service Web Site: Section 23.5 (page 405) Users cannot access the Password Reset Web Site: Section 23.6 (page 406) Users do not receive any quarantine or an incorrect quarantine when using the SMS PASSCODE Secure Device Provisioning component: Section 23.7 (page 406) Token Authentication does not work: Section 23.8 (page 407)

400 SMS PASSCODE 7.2 / ADMINISTRATOR S GUIDE 400 OF SMS Transmission Problems In case of SMS Transmission issues, please always start with opening the Windows Event Viewer and check the SMS PASSCODE Transmission event log (a) to verify whether any SMS was sent. Look for Transmission events (b). Also look, if any Initialization errors have occurred (c). In case of any error or warning events, please inspect these events for details. Problem SMS transmissions fail permanently Error message in the SMS PASSCODE Transmission event log ERROR (PDU1): Unable to send SMS Or Error during initialization of SMS Modem (COMx): Device not found on COMx. Event ID: 292 Possible reasons No connection to the GSM modem due to: GSM modem not powered on GSM modem not connected to the COM port specified in the SMS PASSCODE setup COM port is damaged GSM modem is damaged