1 User Account Management IAA Policies and Procedures: Identity, Authentication, Authorization Christian Isnard, Emmanuel Ormancey, Paolo Tedesco, Alexey Tselishchev CERN - IT/OIS Executive Summary The new User Account management project aims at designing a generic, maintainable solution, simplifying the account management tools and concepts, and handling the lifecycle of accounts and associated computing resources for the whole community of system and service managers. The overall concept is based on IAA Policies: Identity, Authentication and Authorization. Identity is provided by the user, answering the question Who are you? with some public assertion (username, ). This is managed by GS/AIS in the Foundation HR database for the personal information and by IT/OIS for the account (username) information. Authentication is also provided by the user, answering the question Ok, how can you prove it? with some private secret response (password, private keys, pins). This is handled by Active Directory (IT/OIS) through a set of standards (Kerberos, LDAP, SSO, etc.). Authorization is handled by the system, answering the question What can I do? by checking a token or ticket against an access control list. This is maintained by the use of E-Groups to manage access control lists (each application should have a dedicated E-Group containing the list of authorized users). Account Policy: Eligible Users (depending on their status in HR database) are entitled for a Primary account, whereas non- Eligible users can only request External accounts with restricted permissions (e.g. limited to accessing their personal administrative records like payslips). The Primary account is automatically created when the user s status becomes Eligible. The associated username is automatically generated by an algorithm based on first name and last name information. The user must enable his Primary account by calling the service desk to obtain a password. Then he can create Secondary accounts belonging to him (deleted when he leaves CERN) and/or Service accounts assigned to him (automatically reassigned to his Supervisor when he leaves CERN). External accounts will have different levels of trust: the default is address verification only, guaranteed External accounts will have a CERN user as guarantor of the identity, and Grid verified External accounts will be mapped to a digital certificate trusted by the EuGridPMA trust organisation (Grid). Mail Policy: A CERN Mailbox for the Primary account is created automatically for Personnel users, and on request for non- Personnel users (e.g. contractors who should use their home company ). A user has one main address and several aliases. A Web interface will be provided, for the end user, the Service Desk and the Security Team to manage every aspect of the accounts. The primary goals of the system are to empower the end-user and to maximize the self service features. Page 1
2 Introduction The goal of the CERN Identity Management project is to simplify the account and group management tools and concepts, designing a generic solution for the whole community. To make the system generic, maintainable and easy to support, the implementation will be based on a commercial solution, using out-of-the-box features whenever possible, thus minimizing custom coding. A set of tools addressing the needs of the CERN community will be provided. Specific needs will be reviewed to fit in the generic tools, or application owners will be helped to implement their own set of specific tools when needed. This document describes the Identity, Authentication and Authorization (IAA) concepts, defines their policies in the CERN Identity Management context and provides concrete objectives. 1 Definitions The definitions, concepts and conventions used in the rest of the document are defined in this paragraph. IAA stands for Identity, Authentication and Authorization: Identity: A user (typically you) wants to access a system. Because the system doesn t know you yet, you need to make a declaration of who you are. Your answer to the question Who are you? is the first thing you present to a system when you want to use it. Some common examples of identity are user IDs, digital certificates and credit cards. A notable characteristic of identity is that it is public, and it has to be this way: identity is your claim about yourself, and you make that claim using something that is publicly available. Authentication: This is the answer to the question OK, how can you prove it? When you present your identity to a system, the system wants you to prove that it is indeed you and not someone else. The system will challenge you, and you must respond in some way. Common authenticators include passwords, private keys, and PINs. Whereas identity is public, authentication is private: it is a secret known (presumably) only by you. In some cases, like passwords, the system also knows the secret. In other cases, like PKI, the system doesn t need to possess the secret, but can validate its authenticity. Your possession of this secret is what proves that you are who you claim to be. Authorization: Once you have successfully authenticated yourself to a system, the system controls which resources you are allowed to access. Typically this is done through the use of a token or ticket mechanism checked against an access control list maintained by the system administrators. Provided by Answer the questions: Attributes Identity user Who are you? Public assertion Authentication user OK, how can you prove it? Secret response Authorization system What can I do? Table 1: IAA summary Token or ticket Access control 1.1 Identity Identities are defined in HR databases which contain the personal information about the people at CERN. Based on that information are created accounts that represent these Identities in the CERN computing environment. Page 2
3 1.1.1 Accounts An account is a login and password credential pair, with some attributes. The login is used to answer the question Who are you? and the password is the secret response to OK, how can you prove it? (See Table 1: IAA summary). Several account types are available: Primary account: the main account of a user. It is automatically created. Secondary account: a test or administrative account, belonging and attached to a user. Service account: an account representing a service, assigned to a user (the service manager). Service accounts can be re-assigned to another user. External account: standalone account (not necessarily linked to a person in the HR database), obtained via a self-service registration based on address. External accounts have restricted permissions (e.g. payslips & tax certificates access only). Several levels of trust are available (see section 2.6). Reminder: Accounts usage is governed by Operational Circular nº 5. Operational Circular nº 5 requires that users comply with specific rules applicable to services that they use. Users must follow the operational procedures that are in force and the instructions of the service managers. Service managers may withdraw right of access to their service in order to resolve operational problems or in case of failure to comply with these subsidiary rules (http://www.cern.ch/computingrules/oc5_english.pdf) User status Personnel: a user with a CERN contract (staff, fellows, project associates, etc.) or registered as a CERN User. Non-Personnel: a user not member of the CERN personnel (e.g. employees of a CERN contractor, consultants, etc.). See the Table 2: CERN Class in section Eligible users Eligible users are entitled for a Primary account. Non-eligible users can only request an External account, e.g. to access their personal administrative records (payslips etc.). See the Table 2: CERN Class in section Mail addresses Mail address: main address of the user. Alias: convenience alternate address CERN Class The Table 2: CERN Class shows all the possible values for a person s class in the Foundation database (maintained by HR). The CERN Class column shows all the possible CERN Class values in Foundation database. The # column shows the number of entries for each CERN Class in Foundation database. The Eligible column shows which user classes represent eligible users according to the definition in section The Personnel column shows which user classes represent users belonging to the CERN personnel according to the definition in section Page 3
4 CERN Class # Description Eligible Personnel EXMP Ex-Member of Personnel N N USER 9280 User ( CERN User ) Y Y ENTC 3021 Employee of a CERN Y N contractor RETR 2683 Retired N N STAF 2379 Staff Member Y Y UPAS 453 Unpaid Associate Y Y FELL 369 Fellow Y Y PJAS 147 Project Associate Y Y DOCT 118 Doctoral Student Y Y TECH 94 Technical Student Y Y USAS 78 Unpaid Associate with Y Y Subsistence COMT 66 Committee Member N N PDAS 59 Paid Associate Y Y TEMC 35 Temporary Labour for CERN Y Y APPR 24 Apprentice Y Y FTMP 20 Future Member of the Y Y Personnel CASS 11 Corresponding Associate Y Y CNST 7 Consultant Y N ADMI 6 Administrative Stagiaire Y Y CHIL 3 Child Staff Y Y PART 2 Participant to an experiment N N Table 2: CERN Class Account enabling, blocking, unblocking Enabling an account: set the account state to enable and assign a new password (first account use). Blocking an account: Reset the password and set the account state to disabled to prevent alternative authentication methods. Unblocking an account: set the account state to enable and assign a new password. 1.2 Authentication Authentication is the answer to the question OK, how can you prove it? (see Table 1: IAA summary). When an identity is presented to a system, the system will challenge the user who must respond in some way. CERN authenticators include for example passwords and private keys with Digital Certificates through a variety of authentication systems like Kerberos, Single Sign-On or SSH. 1.3 Authorization Authorization is the answer to the question What can I do? (see Table 1: IAA summary). Once successfully authenticated to a system, the system controls which resources a user is allowed to access, usually through the use of a token or ticket mechanism checked against an access control list maintained by the system administrators. A wide range of CERN applications use E-Groups to maintain these access control lists: the token or ticket mechanism contains the list of the E-Groups the user is member of. The application simply compares the E- Group membership list with the access control list and the user is given access if a match is found. Page 4
5 1.4 Generalities Unless specifically mentioned, all operations are available to the end-user in self-service via the dedicated Web Portal (www.cern.ch/account). Some actions are specified to be available only through the ServiceDesk mostly for security reasons. 2 Policies 2.1 Accounts Only Eligible users are entitled for a Primary account (see section 1.1.3): The creation of Primary accounts is automatic. The events triggering the creation of a Primary account are: o The insertion, in Foundation HR database, of a new record having a CERN Class identifying the user as an Eligible user (see Table 2: CERN Class in section 1.1.5). This happens when a new user joins CERN. o The transition, in Foundation HR database, of an existing record from a CERN Class identifying the user as a Non-Eligible user to a CERN Class identifying the user as an Eligible user. This happens for example when an ex-employee gets a new contract. An eligible user can create Secondary accounts: o A Primary account is required to create a Secondary account. o The Secondary accounts are owned by the Primary account of the user. o Ownership of Secondary accounts cannot be transferred. An eligible user can create Service accounts: o A Primary account is required to create or own a Service account. o Ownership of Service accounts can be transferred. o A Service account is always assigned to a Primary account, it can never be stand-alone Account activation On the start day, the user shall contact the ServiceDesk by phone to enable his Primary account (see section 1.1.6) and obtain his login and a new password. In addition, the user s supervisor is also allowed to enable his Primary account, for the first account use Default account names (login) The maximum length for account names is 8 characters. Characters are normalized (removing all diacritic marks); spaces and non-alphanumeric characters are removed. The default account name for a new primary account is chosen as the first available proposal among the following, with a reduction to 8 characters when needed: 1) First letter of the first name + last name 2) First letter of the first name + first letter of the middle name if present, + last name. 3) Last name + first letter of the first name 4) First name + first letter of the last name 5) A number is added to proposal 1 until a unique value is generated. First name Last name Account names John Doe jdoe (no middle name, case 2 does not apply) doej johnd jdoe2 Page 5
6 jdoe3 Jane Mary Doe jdoe jmdoe Johannes Müller jmuller Table 3: Account name generation samples Primary account name change It is possible to change the primary account name (login) during the first week after the contract start date. 2.2 Password policy Primary, Secondary and Service accounts follow the same password policy: the password must be changed every year. Failure to comply will result in account blocking. Multiple reminders will be sent before the year expires and the account gets blocked. 2.3 Mail policies Every account has one main mail address and a number of aliases. Depending on the CERN mailbox existence the mail messages are either delivered to the CERN mailbox or redirected to another external mail address. Only the main address is valid for authentication. Aliases must be in the cern.ch domain (i.e. Each account has mandatory aliases and for technical reasons o Linux batch system, backward compatibility with many existing applications building addresses on the fly by to the current login Mail policy for primary accounts A CERN mailbox is created automatically for Personnel users (see section 1.1.2) o Main mail address o Aliases and Additional aliases can be added. No CERN mailbox is created for Non-Personnel users (e.g. contractors use their home company ) o Main mail address is external (provided by the user upon arrival) o Aliases and Additional aliases can be added. It is possible to create or delete the CERN mailbox: o Non-Personnel users (e.g. contractors, see section 1.1.2) are allowed to create a CERN mailbox if needed (e.g. ServiceDesk people). o Personnel users are allowed to delete their CERN mailbox and register an external primary address instead. In this case the previous primary address will be kept as an alias to ensure mail messages forwarding continuity to the new address Mail policy for secondary accounts Secondary accounts have no CERN mailbox and cannot create one. Main mail address is Alias is Main mail address cannot be changed, no alias can be added. All mail messages sent to the Secondary account are routed to the owner s Primary account main mail address. Page 6
7 2.3.3 Mail policy for service accounts A CERN mailbox is created, configured by default to forward all messages to the owner s Primary account mail address o Reason: to avoid messages accumulating in the service mailbox and ensure communication to the owner. Main mail address o The user will have the possibility to specify a different address when the account is being created. Alias o Additional aliases can be added. 2.4 Acceptance of Computing Rules Every user must follow the Security Quiz and sign the acceptance of computing rules document on the SIR portal (Safety Information Registration within 3 days from the Primary account enabling (start of the contract). If computing rules are not signed within that delay, all the user s accounts are blocked: o The account owner must call the ServiceDesk to have the account(s) re-enabled. o After that, the user has 3 additional days to sign the acceptance document. 2.5 User departure Two months before a user s contract with CERN terminates: The user and his supervisor are notified via mail: o Of the accounts owned by the user o Of the E-Groups the user is member of The user can contact the responsible of the E-Groups he is member of in case he wishes to be still member of them after his departure. When a user s contract with CERN terminates: Their Primary account is moved into a Recycle Bin. All their static E-Groups membership are deleted. All their Secondary accounts are moved into a Recycle Bin. All their Service accounts are transferred to the user s supervisor. A new External account, with the external address of the user is created. aliases are moved from the Primary account to this new External account. After a grace period of 6 months: Their Primary account is deleted. All their Secondary accounts are deleted. The grace period allows recovery if the user gets a new contract (e.g. affiliation renewal). 2.6 External accounts As defined in section 1.1.1, an External account is a standalone account registered manually and based on an address (not in the cern.ch domain). By default the only verified information of an External account is the address used for registration which must be valid and functional Standard External account The only verified information of a Standard External account is the address used for registration which must be valid and functional. A specific E-Group lists all the External accounts and can be used for Authorization. Unused External accounts are automatically deleted after 2 years of inactivity (no login for 2 years). Page 7
8 2.6.2 Guaranteed External accounts External accounts can have a guarantor o Any CERN Primary account holder can be the guarantor of an External account A specific E-Group will list all the guaranteed External accounts and will be used for Authorization. When the guarantor leaves CERN o Guaranteed accounts are reclassified as Standard External accounts. o A notification is sent to the External account . o A Specific guaranteed accounts page will be provided through the Accounts portal Guaranteed accounts will have to change password every year; failure to comply will result in account suspension and eventual deletion. o Password expiration will be enforced to 1 year Grid Verified External accounts A valid certificate can be mapped to the External account assuming: o The Grid certificate was issued by a trusted member of the EUGridPMA (www.eugridpma.org) o The address specified in the certificate matches the registered address of the external account If the checks above are successful the External account is marked as verified: a Grid certificate can only be issued after mandatory identity face to face verifications (following strict EUGridPMA rules). A specific E-Group will list all the Grid Verified External accounts and will be used for Authorization. 3 Interfaces and administrative tools A Web Portal (http://www.cern.ch/account) will provide all the necessary interfaces to manage the accounts, for the end user, the ServiceDesk but also the Computer Security Team. Various user rights will be managed using E-Groups. Figure 1: Web Portal sample Page 8
9 3.1 Standard Access Eligible users are granted access to the Web Portal allowing them to: View the details about themselves Create and manage their Secondary and Service accounts Re-assign the Service accounts they manage to another user o The new owner will have to approve the decision Manage their passwords Figure 2: Account management Figure 3: Password management Page 9
10 Figure 4: Services Management The Web Self Service Portal will present a global view of the computing resources owned by a user, the list of services he has subscribed to, and the available options for each of them. Service managers are encouraged to join the central system to ensure a consistent management perspective. 3.2 ServiceDesk Access Members of specific ServiceDesk E-Groups are granted additional rights to the identity management service through the Web Portal allowing them to: View the details of all the users o Necessary for identity verification Reset a user s password Enable a user s account 3.3 Computer Security team Access Members of specific Security Team E-Groups are granted additional rights to the identity management service through the Web Portal allowing them to: View the details of all the users Block and unblock an account 4 Authorization management Authorization Management is handled through E-Groups. Granting access to a specific resource is done by adding a user to a specific E-Group designed for this purpose. As an example: John Doe builds an application called ApplicationName and wants to restrict access to this application to a set of operators. He can simply create a dedicated E-Group ApplicationName-Authorized- Users filled with the accounts of the allowed operators. Then when accessing the ApplicationName application, the operators will authenticate and their E-Group membership will be verified by the application, allowing access only to the dedicated E-Group ApplicationName-Authorized-Users members. Page 10
11 In addition, each application should also use another specific E-Group to deny access to a list of users (e.g. ApplicationName-Denied-Users ) to allow granularity when blocking access to resources for an account (for security reasons, when a user changes status, etc.). Integration to the central Web Interface for Service Management is proposed to Application owners to provide a consistent End-User interface: see Figure 4: Services Management in section Roles There is no specific role concept and/or dedicated application in the new IAA Policy. A role is simply obtained by adding a user to a specific E-Group. Adding operator1 to the E-Group ApplicationName-Authorized- Users (see example above) creates a specific authorization role for the application ApplicationName. 4.2 Groups for AFS AFS can handle only a limited number of groups, with a limited number of characters for the group name, and a limited number of group memberships is allowed per user. It is proposed to address these restrictions allowing AFS to use the central E-Groups system in the following way: A specific E-Group will be created: e.g. AFS-Published-Groups, managed by the AFS team. This E-Group will be populated (only) with the E-Groups that will be available in AFS. AFS system will synchronize the user memberships and the list of E-Groups only for those listed in this specific AFS-Published-Groups E-Group. 4.3 Exceptions Some services might not be able to use the central E-Groups system to manage Authorizations; those services will have to continue using their internal Authorization systems with their own management tools. 5 Migration 5.1 Accounts Data will be migrated to the new Identity Management Service from: o HR database (Foundation) o Active Directory The migration process will not enforce compliancy to the policies described in this document. Noncompliant cases will be addressed manually. Policies will be enforced on resources created through the new Identity Management Service. Existing service provider accounts will be assigned to a primary account after the migration process. 5.2 Computing groups Computing groups will be migrated to E-Groups. o An will be sent to the computing group owners, indicating that the new computing group management interface is the E-Groups interface. The aim is to remove the unused computing groups if possible, but also to merge, simplify and enhance the use of computing groups by using the centralized standard E-Group system. 5.3 Service Transition Currently, the services provisioned by the legacy system are AFS, AIS, EDMS, MAILSERV, MISS, NICE, ORACLEDB, PARC, PLUS, REMEDY, TELECONF. Most of them are already based on Active Directory so the change will be transparent. Some like EDMS do not even need account provisioning anymore, following the Page 11
12 new model. Others like ORACLE will require a specific solution either transparent or with some minor adaptations. Page 12
13 Contents Executive Summary... 1 Introduction Definitions Identity Accounts User status Eligible users Mail addresses CERN Class Account enabling, blocking, unblocking Authentication Authorization Generalities Policies Accounts Account activation Default account names (login) Primary account name change Password policy Mail policies Mail policy for primary accounts Mail policy for secondary accounts Mail policy for service accounts Acceptance of Computing Rules User departure External accounts Standard External account Guaranteed External accounts Grid Verified External accounts Interfaces and administrative tools Standard Access ServiceDesk Access Computer Security team Access Authorization management Roles Groups for AFS Page 13
14 4.3 Exceptions Migration Accounts Computing groups Service Transition Page 14
OIS Operating Systems & Information Services Account Management Group Administrators with Extended Features November 5 th, 2010 Paolo Tedesco Alexey Tselishchev Emmanuel Ormancey OIS Contents What is Account
Operating Systems & Information Services CERN s Experience with Federated Single Sign-On Federated identity management workshop June 9-10, 2011 IT-OIS Definitions IAA: Identity, Authentication, Authorization
Identity Management Alberto Pace CERN, Information Technology Department firstname.lastname@example.org Computer Security The present of computer security Bugs, Vulnerabilities, Known exploits, Patches Desktop Management
CERN Single Sign On http://cern.ch/login Emmanuel Ormancey CERN IT/IS Agenda History CERN Authentication Main goals Authentication methods Demo overview Technical background Identity provider Service providers
CERN Single Sign On solution Emmanuel Ormancey System Architect, CERN IT/IS CERN, Route de Meyrin, CH-1211 Geneva 23, Switzerland E-mail: Emmanuel.Ormancey@cern.ch Abstract. The need for Single Sign On
INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES Participation in the InCommon Federation ( Federation ) enables a federation participating organization ("Participant") to use Shibboleth identity
INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES Participation in the InCommon Federation ( Federation ) enables a federation participating organization ("Participant") to use Shibboleth identity
INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES Participation in InCommon Federation ( Federation ) enables the participant to use Shibboleth identity attribute sharing technologies to manage access
E-Groups Training Carmen Barandela (GS/AIS) Pawel Grzywaczewski (IT/OIS) For support: email@example.com or 77777 Overview What are CERN e-groups? What can you do with e-groups? Static e-groups Dynamic
Table of Contents INTRODUCTION... 2 HOME PAGE... 3 Announcements... 7 Personalize & Change Password... 8 Reminders... 9 SERVICE CATALOG... 11 Raising a Service Request... 12 Edit the Service Request...
NCID User Guide Version 1.8 Office of Information Technology Services As of July 26, 2011 Document History Version Change Reference Date Author 1.0 Initial draft release 9/16/10 Heather Ferrie Update w/
Active Directory User Management System (ADUMS) Release 2.9.3 User Guide Revision History Version Author Date Comments (MM/DD/YYYY) i RMA 08/05/2009 Initial Draft Ii RMA 08/20/09 Addl functionality and
Oracle Identity Management Concepts and Architecture An Oracle White Paper December 2003 Oracle Identity Management Concepts and Architecture Introduction... 3 Identity management... 3 What is Identity
Single Sign-On (SSO) for Applications User Guide October 2008 1 Contents Introduction... 3 Overview... 3 Extra Information... 3 1. Registering for an SSO Account... 4 SSO Registration... 4 2. Configuring
Getting Started Getting Started with Time Warner Cable Business Class Voice Manager A Guide for Administrators and Users Table of Contents Table of Contents... 2 How to Use This Guide... 3 Administrators...
INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES Participation in the InCommon Federation ( Federation ) enables a federation participating organization ("Participant") to use Shibboleth identity
white paper The Benefits of an Industry Standard Platform for Enterprise Sign-On The need for scalable solutions to the growing concerns about enterprise security and regulatory compliance can be addressed
DocuSign Single Sign On Implementation Guide Published: March 17, 2016 Copyright Copyright 2003-2016 DocuSign, Inc. All rights reserved. For information about DocuSign trademarks, copyrights and patents
Table of Contents INTRODUCTION... 2 HOME PAGE... 3 Announcements... 7 Personalize & Change Password... 8 Reminders... 10 SERVICE CATALOG... 12 Raising a Service Request... 12 Edit the Service Request...
Volume Licensing User Guide Accessing the Microsoft Volume Licensing Center May 2015 1 Table of Contents Using This Guide... 4 Audience... 4 Purpose... 4 Introduction... 4 Step 1: Identify the Domain Administrator
How Board Members and State Employees Utilize the Security Portal to Access PDMP July 30, 2014 Version 2 Software Release Version 3.4.11 Table of Contents How to Access PDMP via the ADPH Security Portal...
1 Building an Identity Management Business Case Managing the User Lifecycle Across On-Premises and Cloud-Hosted Applications Justifying investment in identity management automation. 2 Agenda Business challenges
P-Synch by M-Tech Information Technology, Inc. ID-Synch by M-Tech Information Technology, Inc. Product Category: Password Management/Provisioning Validation Date: TBD Product Abstract M-Tech software streamlines
Authentication Integration VoiceThread provides multiple authentication frameworks allowing your organization to choose the optimal method to implement. This document details the various available authentication
Participant Name: McGill University Canadian Access Federation: Trust Assertion Document (TAD) 1. Purpose A fundamental requirement of Participants in the Canadian Access Federation is that they assert
Administration Guide BlackBerry Enterprise Service 12 Version 12.0 Published: 2015-01-16 SWD-20150116150104141 Contents Introduction... 9 About this guide...10 What is BES12?...11 Key features of BES12...
ManageEngine ADSelfService Plus Evaluator s Guide Table of Contents Document Summary:...3 ADSelfService Plus Overview:...3 Core Features & Benefits:...4 ADSelfService Plus Architecture:...5 Admin Portal:...
Business and Process Requirements Business Requirements mapped to downstream Process Requirements IAM UC Davis IAM-REQ-1 Authorization Capabilities The system shall enable authorization capabilities that
Oracle Enterprise Single Sign-on Technical Guide An Oracle White Paper June 2009 EXECUTIVE OVERVIEW Enterprises these days generally have Microsoft Windows desktop users accessing diverse enterprise applications
Table of Contents INTRODUCTION...2 HOME PAGE...3 Announcements... 6 Personalize... 7 Reminders... 9 Recent Items... 11 SERVICE CATALOG...12 REQUEST...14 Request List View... 15 Creating a New Incident...
Take Control of Identities & Data Loss Vipul Kumra Security Risks - Results Whom you should fear the most when it comes to securing your environment? 4. 3. 2. 1. Hackers / script kiddies Insiders Ex-employees
MailTrack How To Document 27 March 2014 Table of Contents 1. How to Register... 2 2. Forgot Password... 4 3. Login to MailTrack Webmail... 5 4. Accessing MailTrack message Centre... 6 5. Creating a MailTrack
Secure Access Management Services (SAMS) Electronic Authentication Process for the Inventory Management and Tracking System (IMATS) IMATS - SAMS User Registration Webinar Objective To provide information
CHAPTER 4 Sponsors are the people who use Cisco NAC Guest Server to create guest accounts. Sponsor authentication authenticates sponsor users to the Sponsor interface of the Guest Server. There are five
Chapter 1 Managing users The Users page in Cloud Manager lists all of the user accounts in the Centrify identity platform. This includes all of the users you create in the Centrify for Mobile user service
HP Software as a Service Federated SSO Guide Document Release Date: July 2014 Legal Notices Warranty The only warranties for HP products and services are set forth in the express warranty statements accompanying
Dell KACE K1000 System Management Appliance Version 5.4 Service Desk Administrator Guide October 2012 2004-2012 Dell Inc. All rights reserved. Reproduction of these materials in any manner whatsoever without
ACR Triad Web Client Version 2.5 20 October 2008 User s Guide American College of Radiology 2007 All rights reserved. CONTENTS ABOUT TRIAD...3 USER INTERFACE...4 LOGIN...4 REGISTER REQUEST...5 PASSWORD
User Guide for CDC s SAMS Partner Portal Document Version 1.0 Introduction If you are reading this guide, it probably means that you have been (or will be) invited to register with the SAMS Partner Portal.
Training Module : Administration (logical) (for Privia version.9) Copyright 0 by Privia LLC. All rights reserved. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval
is currently used by many large organizations including banks, health care organizations, educational institutions and government agencies. Thousands of organizations rely on File- Cloud for their file
GO!Enterprise MDM Device Application User Guide Installation and Configuration for Android GO!Enterprise MDM for Android, Version 3.x GO!Enterprise MDM for Android 1 Table of Contents GO!Enterprise MDM
IRS e-services Registration Process What is e-services? Suite of products designed for tax professionals and taxpayers to do business with IRS electronically Includes: Registration e-file Application Preparer
Experiences Using SNOW in IT Emmanuel Ormancey (IT/OIS) Maite Barroso Lopez (IT/PES) Massimo Lamanna (IT/DSS) CERN IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it Introduction ITIL, the process
IGI Portal architecture and interaction with a CA- online Abstract In the framework of the Italian Grid Infrastructure, we are designing a web portal for the grid and cloud services provisioning. In following
QualysGuard SAML 2.0 Single Sign-On Technical Brief Introduction Qualys provides its customer the option to use SAML 2.0 Single Sign On (SSO) authentication with their QualysGuard subscription. When implemented,
Single Sign-On Security and comfort can be friend. Arnd Langguth firstname.lastname@example.org September, 2006 Identity proliferation in the enterprise Password management problem How many passwords do you have?
BlackShield ID Best Practice Implementation Guide for a Complex Network Document Scope This document is designed to demonstrate best practice when implementing and rolling out a two-factor authentication
SWITCHpki long lived grid user certificates PKI meeting in Bern Bern, 15 June 2010 Alessandro Usai email@example.com Trust Link Interface! Long lived grid user certificates are now handled by the
Unifying Voice Administration Technical Brief Avaya Mailbox Manager and Unimax 2nd Nature A Comparison SUPPORT FOR MAILBOX MANAGER WILL END WITH M O D U L A R M E S S A G I N G 5. 1. U N D E R S TA N D
Advanced Configuration Steps After you have downloaded a trial, you can perform the following from the Setup menu in the MaaS360 portal: Configure additional services Configure device enrollment settings
SECURITY AND AUDITABILITY WITH SAGE ERP X3 Introduction An ERP contains usually a huge set of data concerning all the activities of a company or a group a company. As some of them are sensitive information
CHAPTER114 The window in Cisco Unified Communications Manager Administration allows the administrator to add, search, display, and maintain information about Cisco Unified Communications Manager end users.
GO!Enterprise MDM Device Application User Guide Installation and Configuration for Android with TouchDown GO!Enterprise MDM for Android, Version 3.x GO!Enterprise MDM for Android with TouchDown 1 Table
econtrol 3.5 for Active Directory & Exchange Administrator Guide This Guide Welcome to the econtrol 3.5 for Active Directory and Exchange Administrator Guide. This guide is for system administrators and
Administration Guide. All right reserved. For more information about Specops Password Sync and other Specops products, visit www.specopssoft.com Copyright and Trademarks Specops Password Sync is a trademark
Building Secure Applications James Tedrick What We re Covering Today: Accessing ArcGIS Resources ArcGIS Web App Topics covered: Using Token endpoints Using OAuth/SAML User login App login Portal ArcGIS
HP Service Manager Software Version: 9.40 For the supported Windows and Linux operating systems Application Setup help topics for printing Document Release Date: December 2014 Software Release Date: December
Release: v1.7 Date: 24.12.08 DET SINGLE SIGN-ON ACCOUNT... 2 USER VALIDATION QUESTION... 3 FORGOT MY PASSWORD... 4 CHANGING PASSWORDS... 5 CHANGING PASSWORDS (CONTINUED)... 6 v1.7.doc Page 1 of 6 DET Single
ACHieve Access 4.3 User Guide for Corporate Customers January 2015 Citizens Bank 1 February 2015 Table of Contents SECTION 1: OVERVIEW... 4 Chapter 1: Introduction... 5 How to Use This Manual... 5 Overview
BlackBerry Enterprise Service 10 Version: 10.2 Configuration Guide Published: 2015-02-27 SWD-20150227164548686 Contents 1 Introduction...7 About this guide...8 What is BlackBerry Enterprise Service 10?...9
Canadian Access Federation: Trust Assertion Document (TAD) Purpose A fundamental requirement of Participants in the Canadian Access Federation is that they assert authoritative and accurate identity attributes
Directory Integration with Okta An Architectural Overview Okta Inc. 301 Brannan Street San Francisco, CA 94107 firstname.lastname@example.org 1-888-722-7871 Contents 1 User Directories and the Cloud: An Overview 3 Okta
Guide Cisco ASA Adaptive Security Appliance Single Sign-On: Solution Brief October 2012 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 21 Contents
Foundation ACTIVE DIRECTORY AND MICROSOFT EXCHANGE PROVISIONING FOR HEALTHCARE PROVIDERS The promise of reduced administrative costs and improved caregiver satisfaction associated with user provisioning
Fixes for CrossTec ResQDesk Fixes in CrossTec ResQDesk 5.00.0006 December 2, 2014 Resolved issue where the list of Operators on Category was not saving correctly when adding multiple Operators. Fixed issue
Welcome Welcome to the website designed to facilitate completion of mandatory training that arriving personnel and units assigned to, rotating to, or in temporary duty status to USFK must complete prior
Integrating Hitachi ID Suite with WebSSO Systems 2015 Hitachi ID Systems, Inc. All rights reserved. Web single sign-on (WebSSO) systems are a widely deployed technology for managing user authentication
AT&T Voice DNA User Guide Page 1 Table of Contents GET STARTED... 4 Log In... 5 About the User Dashboard... 9 Manage Personal Profile... 15 Manage Messages... 17 View and Use Call Logs... 22 Search the
Set Up and Maintain Customer Support Tools Salesforce, Winter 16 @salesforcedocs Last updated: December 10, 2015 Copyright 2000 2015 salesforce.com, inc. All rights reserved. Salesforce is a registered
CMSGu2011-08 Mauritian Computer Emergency Response Team CERT-MU SECURITY GUIDELINE 2011-02 Enhancing Cyber Security in Mauritius Guideline on Access Control National Computer Board Mauritius Version 1.0
Offline Payment Methods STRONGVON Tournament Management System 1 Overview The STRONGVON Tournament Management System allows you to collect online registration, while arranging for offline payment methods
WEST VIRGINIA UNIVERSITY Office of Information Technology Service Desk Express (SDE) Self Service Rev. April, 2011 1 Table of Contents Table of Contents... 2 Using Service Desk Express (SDE) Self Service...
Fischer International Identity BUILT FOR BUSINESS YOURS PRODUCT OVERVIEW Fischer Password Manager The Case for Password Management Managing passwords is a common challenge that is shared from the smallest
SafeNet Authentication Client (Windows) Version 8.1 SP1 Revision A User s Guide Copyright 2011 SafeNet, Inc. All rights reserved. All attempts have been made to make the information in this document complete
Single Sign-On Portal User Reference (Okta Cloud SSO) Contents Okta Single Sign-on Portal... 3 Initial account creation and configuration... 3 First time manual login to the Okta Single Sign-on Portal...
Identity & Access Management (IAM) User Reference Guide What is IAM?... 3 Submitting an Alberta Netcare Access Request in IAM... 5 Modifying an Alberta Netcare Portal Account... 17 Removing Alberta Netcare