mobile secure management platform automation/ma... · mobile secure management platform mobile...

Mobile Secure Management Platform

Mobile Automation Security Analysis White Paper

Document Revision 5.1 Document ID: MLMS security white paper 5.1.2.doc

July 2, 2003

Prepared by:

Revision History

VERSION/RELEASE DATE DESCRIPTIONS OF REVISIONS

5.1 5-12-03 Initial Draft

Copyright Information

THIS DOCUMENT CONTAINS DATA CLASSIFIED AS MOBILE AUTOMATION, INC. CONFIDENTIAL. ITS CONTENTS MAY NOT BE DISCLOSED, COPIED, OR DISTRIBUTED IN ANY MANNER, EITHER IN WHOLE OR IN PART, FOR ANY PURPOSE WITHOUT THE EXPRESS WRITTEN PERMISSION OF MOBILE AUTOMATION, INC.

PREPARED BY

Author: Mike Teplinsky

Product Manager

May 13, 2003 Copyright© 2003, Mobile Automation, Inc.,

Los Angeles, CA. All Rights Reserved.

Reproduction of any portion of this document is prohibited without express

written permission from Mobile Automation, Inc. Mobile Automation is a trademark of

Mobile Automation, Inc.

Other company and product names may be trademarks or registered trademarks of their

respective vendors or organizations.

Mobile Automation, Inc. 310 N. Westlake Blvd

Suite 200 Westlake Village, CA 91362

Phone:......................................(310) 914-9603 Fax:...........................................(310) 914-9703 Web:...................www.mobileautomation.com Email:[email protected]

TABLE OF CONTENTS

1 EXECUTIVE SUMMARY ..............................................................................................................................1

2 PROTECTING THE DATA STREAM USING SSL......................................................................................2 2.1 SSL OVERVIEW.......................................................................................................................................2 2.2 SSL SECURITY BASICS.............................................................................................................................3

2.2.1 An Introduction to Key Cryptography .............................................................................................3 2.2.2 Using Public Key Cryptography for Authentication.........................................................................4

2.3 WEB SERVER CERTIFICATE .......................................................................................................................5 2.3.1 Certificate validation .......................................................................................................................5

2.4 CONFIGURING MSMP AND MICROSOFT IIS FOR USE WITH AN SSL CERTIFICATE..........................................5 2.4.1 Generating a Certificate Signing Request (CSR)...........................................................................6 2.4.2 Apply Online...................................................................................................................................9 2.4.3 Installing your Certificate ................................................................................................................9

2.5 CONFIGURING AN MSMP CLIENT AGENT TO USE SSL...............................................................................10 2.6 CONFIGURING RELAY SERVERS TO USE SSL ...........................................................................................12 2.7 PORT SETTINGS .....................................................................................................................................13 2.8 CERTIFICATE AUTHORITIES.....................................................................................................................14

2.8.1 Home Grown Certificate Authorities.............................................................................................14 2.9 BIT LEVEL ENCRYPTION STRENGTH.........................................................................................................14

3 ESTABLISHING AUTHORIZED USER ACCESS USING MICROSOFT NTLM AND KERBEROS SECURITY...................................................................................................................................................16

3.1 MICROSOFT NTLM OVERVIEW ...............................................................................................................16 3.1.1 Credentials ...................................................................................................................................16 3.1.2 Authentication-- Challenge/Response..........................................................................................17

3.2 KERBEROS SECURITY OVERVIEW............................................................................................................17 3.3 MICROSOFT NEGOTIATE.........................................................................................................................18

3.3.1 Reasons MSMP may use the Negotiate Package.......................................................................19 3.4 LSA USER LOGON AUTHENTICATION ......................................................................................................19

3.4.1 Interactive Authentication .............................................................................................................19 3.4.2 Noninteractive Authentication.......................................................................................................20

3.5 CLIENT/SERVER ACCESS CONTROL IN MSMP.........................................................................................21 3.6 REMOTE ADMINISTRATION CONSOLE.......................................................................................................22

3.6.1 Site Scoping ................................................................................................................................. 22 3.7 IMPLEMENTING CONSOLE SITE SECURITY ................................................................................................23

3.7.1 Adding Users and Groups............................................................................................................24

Mobile Automation Security White Paper

Mobile Automation, Inc. Revision 5.1 Page 1 MLMS security WHITE PAPER 5.1.3.DOC 7/2/2003

1 Executive Summary The following document outlines the security structure of the Mobile Automation, Mobile Secure Management Platform (MSMP) as part of the overall technology underlying the Mobile Lifecycle Management Suite (MLMS).

This document can be used to better understand how Mobile Secure Management Platform (MSMP) operates in a way which helps prevents security breeches, and unauthorized access, and allows compliance with common security standards across corporate enterprises.

The security system is governed in two (2) basic categories:

1. Protecting the data stream to/from client agent and the server

2. Secure and restrict access to the console and system function

Any recommendations made within this document will aid in further securing the MSMP environment and architecture however may not necessarily improve performance. For assistance in understanding, improving performance, please see the “MLMS Architectural Recommendations Document”.

Some portions and material used in this white paper relating specifically to SSL technology and NTLM authentication were ascertained from publicly available sources and documents and are used to help explain the overall security structure that the Mobile Secure Management Platform is based on.



2 Protecting the Data Stream using SSL By default, the MSMP allows client agents to communicate with the command server over HTTP using standard port 80. In some situations, this may be an inadequate configuration for protecting the data being transmitted from server to client and vice versa even if a VPN is being used.

Without any loss in functionality, the MSMP servers can be configured to support Secure Socket Layer (SSL) for client/server public-and-private key encryption. SSL can be activated within the MSMP to achieve protection of data and validation of client systems. Implementation of SSL requires the installation of a valid ‘certificate’ on your IIS or Apache web server where the MSMP servers reside.

2.1 SSL Overview Secure Socket Layer (SSL) certificates provide three basic security services: confidentiality, authentication and integrity. When SSL is enabled for MSMP client/server communications, full cryptography services are supported including server level authentication, data encryption, and error detection. All inventory posted from client to server is protected. All packages and jobs and well as log results are fully protected in the secure data stream in both directions.

It is important to note which ‘level’ of security your SSL certificate provides. By implementing ‘high assurance’ certificates, such as those provided by ‘Verisign Inc.’ and ‘Geotrust’ you can be assured that all three (3) levels of protection are being provided.

Enabling SSL, a client agent will be forced to handle all communication with the MSMP server inside an SSL encrypted datastream. This includes data being sent from the server as well as all data being sent back to the server. The security of SSL will provide the following:

? Confidentiality (data encryption: Information provided by the client agent cannot be intercepted in transit. This is handled via the 128-bit strong RSA standard key encryption system. The encryption level is determined by the encryption level of the WININET.DLL driver of the client system (the same as what IE provides on the client).

? Integrity (error detection): Information cannot be altered without detection.

? Authentication (Server level authentication): Verify that the client agent is actually posting to the valid MSMP command server and not a different server or unauthorized client agent (authentication)

Once a certificate is enabled at the web server, MSMP agents can be configured to use SSL. MSMP makes effective use of the SSL public key infrastructure (PKI) so agent configuration for SSL is simple a checkbox setting. Once a certificate is generated from a valid certificate authority (CA) and applied to the command and relay servers, our MSMP client agent will require authentication against this certificate by passing the public key from the server to the client for validation against the locally installed certificate.



If a ‘Verisign, Inc.’ or ‘Geotrust’ certificate is used, then no changes are required at the MSMP client other then to simply enable SSL in the agent configuration advanced section. In addition, you can be assured that your SSL implementation is ‘high assurance’ providing all three levels. Cryptography data streams will thus become active for all client agents, and the highest level of data stream protection and encryption will be supported

The diagram illustrates how every Internet Explorer Web browser already contains the client side Verisign Class 1 and Class 2 public keys. This menu is available from the Tools/Internet Options/Content tab.

2.2 SSL Security Basics

2.2.1 An Introduction to Key Cryptography

Rivest-Shamir-Adleman (RSA) public key cryptography is widely used for authentication and encryption in the computer industry. Public key encryption is a technique that uses a pair of asymmetric keys for

SSL Certificate Authority

SSL Encrypted Datastream



encryption and decryption. Each pair of keys consists of a public key and a private key. The public key is made public when it is distributed it widely. The private key is never distributed; it is always kept secret.

Data that is encrypted with the public key can only be decrypted with the private key. Conversely, data that is encrypted with the private key can be decrypted only with the public key. This asymmetry is the property that makes public key cryptography so useful.

2.2.2 Using Public Key Cryptography for Authentication

Authentication is the process of verifying identity so that one entity can be sure of the identity of another entity. In the following examples, User A and User B use public key cryptography to verify User B's identity. The following notation indicates that an item has been encrypted or decrypted using key cryptography

{something}key

where something is a description of the item that has been encrypted or decrypted, and key is the key that is used to encrypt or decrypt that item.

In the following example, User A wants to authenticate User B. User B has a pair of keys, one public and one private. User B discloses the public key to User A (this is discussed in the "Handing Out Public Keys" section of this article). User A generates a random message and sends it to User B as follows:

A->B random_message

User B uses the private key to encrypt the random message and returns the encrypted version to User A:

B->A {random_message}User_B's_private_key

User A receives this message and decrypts it by using the public key that User B previously published. User A compares the decrypted message with the message that User A originally sent to User B; if the messages match, User A knows that the later message came from User B, because an imposter presumably would not know User B's private key and so would be unable to properly encrypt the random message to send to User A.



2.3 Web server certificate In order to be able to generate an SSL link, a web server requires an SSL Certificate.

When you choose to activate SSL on your web server you will be prompted to complete a number of questions about the identity of your website (e.g. your website’s URL) and your company (e.g. your company’s name and location). Your web server then creates two cryptographic keys – a Private Key and a Public Key. Your Private Key is so called for a reason – it must remain private and secure. The Public Key does not need to be secret and is placed into a Certificate Signing Request (CSR) – a data file also containing your details. The Certification Authority (in most cases Verisign or Geotrust), will validate your details and issue an SSL Certificate containing your details and allowing you to use SSL.

Typically an SSL Certificate will contain your domain name, your company name, your address, your city, your state and your country. It will also contain the expiry date of the Certificate and details of the Certification Authority responsible for the issuance of the Certificate.

2.3.1 Certificate validation

Your web server will match your issued SSL Certificate to your Private Key. Your web server will then be able to establish an encrypted link between the website and your MSMP client agent.

When the MSMP client agent connects to a secure command or relay server, it will retrieve the site’s SSL Certificate and check that it has not expired, it has been issued by a Certification Authority the client agent trusts, and that it is being used by the website for which it has been issued. If it fails on any one of these checks the client agent will fail to make the connection and warnings will be entered into the client agent local connection logs.

2.4 Configuring MSMP and Microsoft IIS for use with an SSL certificate There are four stages to setting up SSL on your MSMP servers. This involves first configuring the Microsoft IIS web server:

1. Create a Certificate Signing Request (CSR)



2. Apply online

3. Installing your Certificate

2.4.1 Generating a Certificate Signing Request (CSR)

A CSR is a file containing your certificate application information, including your Public Key. Generate your CSR and then copy and paste the CSR file into the webform in the enrollment process:

Generate keys and Certificate Signing Request:

• Select Administrative Tools from the Start Menu

• Start Internet Services Manager

• Open the Properties window for the website the CSR is for. You can do this by right clicking on the Default Website and selecting Properties from the menu

• Open Directory Security by right clicking on the Directory Security tab



• Click Server Certificate. The following Wizard will appear:

• Click Create a new certificate and click Next.



• Select Prepare the request now, but send it later and click Next.

• Provide a name for the certificate, this needs to be easily identifiable if you are working with multiple domains. This is for your records only.

• If your server is 40 bit enabled, you will generate a 512 bit key. If your server is 128 bit you can generate up to 1024 bit keys. We recommend you stay with the default of 1024 bit key if the option is available. Click Next



• Enter Organization and Organization Unit, these are your company name and department respectively. Click Next.

• The Common Name field should be the Fully Qualified Domain Name (FQDN) or the web address for which you plan to use your Certificate, e.g. the area of your site you wish customers to connect to using SSL. For example, an SSL Certificate issued for mobileautomation.net will NOT be valid for secure.mobileautomation.net. If the web address to be used for SSL is secure.mobileautomation.net, ensure that the common name submitted in the CSR is secure.mobileautomation.net. Note that preceding the FQDN with https:// is NOT necessary. Click Next.

• Enter your Country, State and City. Click Next.

• Enter a filename and location to save your CSR. You will need this CSR to enroll for your Certificate. Click Next.

• Check the details you have entered. If you have made a mistake click Back and amend the details. Be especially sure to check the domain name the Certificate is to be Issued To. Your Certificate will only work on this domain. Click Next when you are happy the details are absolutely correct.

2.4.2 Apply Online

There are several ways to obtain a certificate. One of the easiest and most recommended is to simply visit www.verisign.com and apply for your certificates online. Or you can visit several other sites which provide SSL ‘root level’ certificate authority privileges such as Geotrust. Using these types of certificates, you will be assured that high assurance SSL security will be maintained. Depending on the site you chose, you may have to wait several days to receive validation on your certificate request.

Another way would be to generate a certificate from one of your own internal certificate authority (CA) servers. See ‘certificate authorities’ below.

2.4.3 Installing your Certificate

• Select Administrative Tools



• Start Internet Services Manager

• Open the properties window for the website. You can do this by right clicking on the Default Website and selecting Properties from the menu.

• Open Directory Security by right clicking on the Directory Security tab

• Click Server Certificate.

• Choose to Process the Pending Request and Install the Certificate. Click Next.

• Enter the location of your certificate (you may also browse to locate your certificate), and then click Next.

• Read the summary screen to be sure that you are processing the correct certificate, and then click Next.

• You will see a confirmation screen. When you have read this information, click Next.

• You now have a server certificate installed. Important: You must now restart the computer to complete the install

2.5 Configuring an MSMP client agent to use SSL The MSMP client agent can be configured to use SSL by enabling this option through the settings interface. The settings interface can be accessed from the agent system tray icon on each PC.

? Double click on the agent system tray icon



? Click on the ‘options’ button

? Click on the ‘advanced’ button of the ‘http server’ tab



? Check the box at the bottom to “connect using SSL”

? Click ‘OK’ to save settings

Mobile Automation allows you to make these changes globally as well by simply using a ‘change agent configuration’ package.

? Create a new ‘task’ package

? Add the package command ‘agent configuration’

? Double click on this command and make the same change as noted above.

? Save the package and send to all client agents

This will force all agents to inherit the settings you define.

2.6 Configuring Relay Servers to use SSL SSL level protection can also be enabled at the Relay Server level. This will ensure that all data transmitted between the Relay Servers and the Command Servers are also protected inside an SSL datastream.

Is is important to note that if SSL has been enabled on clients, it will need to be done on all servers since SSL configured agents will refuse to talk to non-SSL servers. So, if you have a mix of agent types, then you’ll either want to enable SSL support on all Relay Servers, or insure that the agents who do have SSL enabled are in fact pointing to the correct Server.



To configure a Relay server to use SSL, you would need to either visit the server and login locally, or you would need to use Mobile Automation’s ‘Live Support’ feature to remote control the server.

? Once connected, you will bring up the server settings dialog by double clicking on the Relay Server system tray icon

? Click on the Options tab

? Click on the ‘advanced’ button of the ‘http server’ tab

? Check the box at the bottom to “connect using SSL”

? Click ‘OK’ to save settings

2.7 Port settings Open the Properties of the default website and ensure that SSL port contains the number 443 (it should default to this number automatically). You may want to test the Web site to ensure that everything is working correctly. Be sure to use https:// when you test connectivity to the site.

Note: The SSL Port is grayed out in this diagram.

The MSMP client agent also contains a port setting configuration. This is located under the advanced button on the ‘HTTP server’ tab. When the SSL check box is checked, the client agent will attempt to communicate using SSL. The port setting window will automatically display port 443.

The port number is customizable both at the client agent and the web server. You are not expressly required to use port 443. As long as you change the port at both ends, SSL will still work just fine. You will need to verify and test however, that your intermediate routers between the client agents and the server, can support routing of SSL packets on ports other than 443.



2.8 Certificate Authorities The MSMP client agent initiates an SSL session with a command or relay server. The server responds by sending back its SSL certificate that includes its public key. The client agent examines this server certificate and verifies that it is valid and assigned by a recognized certificate authority (CA). For the key excahnge to work, the public key of this CA must already have been embedded in the local TCP/IP network configuration settings. This is true for of the larger Internet public CAs such as Verisign.

Recognized root CAs are configurable and available through the Internet Explorer advanced options. These options allow you to see and/or register new certificates from different CAs If the public key of the certificate authority that signed the server certificate is not embedded in the browser configuration settings here, your browser will display warning dialogs when a user attempts to browse an HTTPS page on that server.

While the MSMP client agent will not display warning dialogs to your users, it will fail to connect to a server configured with a certificate from an unregistered CA. The MSMP client agent leverages the same subsystem that IE uses when connecting over SSL The benefit is that any existing browser based security configurations and protocol or proxy configurations in effect are also used by the MSMP client agent. Thus any trusted root certificate authority which is already configured in Internet Explorer is available to the MSMP client agent.

However, since the client agent is designed to be ubiquitous to the end user, we cannot simply present the same message pop ups indicating valid or invalid site. Thus it is by design that the client agent defaults to simply only allow access to trusted sites, and automatically deny access to untrusted sites in which the client agent is directed. Connection logs are silently tracked locally and on the server for communication layer troubleshooting.

2.8.1 Home Grown Certificate Authorities

You may be in an organization which has installed its own Certificate Authority servers. In fact, you may even have these CA’s linked directly to your Active Directory tree. These might be in the form of either an intermediate certificate authority or a root certificate authority. In either case, great care should be taken to insure that you are using SSL with ‘high assurance’ certificates and 128-bit level (or highter) encryption to achieve the best possible levels of security in all three areas: confidentiality, authentication and integrity.

In addition, the local CA which you’ve chosen might not have its public certificate loaded and deployed to all the local client system certificate cache accessible from clients web browsers in advance. Without it, the client agent will not be able to validate the site whose certificates have been generate from these home grown CA’s. This may require additional network planning.

2.9 Bit Level Encryption Strength What strengths of SSL certificates are available? Generally two strengths of certificate are advertised - 40 bit & 128 bit. You can determine the strength of the encryption when accessing an SSL enable web site. The bit size indicates the length of the key size used for the encryption during a secure SSL session you’re your web browser, hovering your mouse over the gold padlock will tell you the current strength of encryption being used. Essentially, the bigger the number, the longer it takes for computers to crack.



? 40 bit: It is computationally feasible to crack a 40 bit key. For this reason 40 bit encryption is rarely used for highly secure systems, but often used for moderate security where speed is important.

? 128 bit: Thus far, it has not been proven to computationally crack a 128 bit key. All banking infrastructures use 128 bit encryption. We strongly recommend the use of 128 bit SSL encryption for your site. The MSMP client agent supports 128 bit encryption.



3 Establishing Authorized User Access using Microsoft NTLM and Kerberos Security To access and manage the Mobile Secure Management Platform (MSMP), a Remote Administration Console application is provided which supports all server management capabilities away from the server and database for administrators at remote client systems. To protect the MSMP environment from unauthorized access, Mobile Automation supports and integrates with both Microsoft NTLM and Kerberos Security subsystem built into the Windows operating system and Active Directory Services subsystem (ADS). MSMP leverages this interface to provide three (3) types of protection at a user level:

1. Authentication: Validation that the logged in user is a valid user account and is matched with credentials on the directory or domain controller

2. Access: Determination of MSMP that this account has valid rights granted to access the MSMP system

3. Privileges: Determination of MSMP as to which functions and operations are allowed within the MSMP environment based on granted access to this set of credentials.

User credentials are are integrated with the underlying Microsoft security subsystem and as such, it is unnecessary for an administrator to create new user accounts for the purpose of establishing security rights within MSMP. In addition, no additional logon is necessary when the Console is loaded since “Windows” has already validated the credentials using NTLM or Kerberos as a valid user account.

3.1 Microsoft NTLM Overview Windows NT Challenge/Response (NTLM) is the authentication protocol used on networks that include systems running the Windows NT operating system and on stand-alone systems. NTLM stands for Windows NT LAN Manager, a name chosen to distinguish this more advanced challenge/response-based protocol from its weaker predecessor LAN Manager (LM).

Beginning with Windows 2000, the Microsoft Kerberos security package adds greater security to networked systems than NTLM. Although Microsoft Kerberos is the protocol of choice for Windows 2000 networks, NTLM is still supported and must be used for network authentication if the network includes systems running versions of Windows NT earlier than Windows 2000. NTLM must also be used for logon authentication on stand-alone systems.

3.1.1 Credentials

NTLM credentials are based on data obtained during the interactive logon process and consist of a domain name, a user name, and a one-way hash of the user's password. NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user's password over the wire. Instead, the system requesting authentication must perform a calculation that proves it has access to the secured NTLM credentials.



3.1.2 Authentication-- Challenge/Response

Interactive NTLM authentication over a network typically involves two systems: a client system, where the user is requesting authentication, and a domain controller, where information related to the user's password is kept. Noninteractive authentication — which may be required to permit an already logged-on user to access a resource such as MSMP — typically involves three systems: a client, a server, and a domain controller that does the authentication calculations on behalf of MSMP.

The following steps present an outline of NTLM noninteractive authentication:

Note: The first item provides the user's NTLM credentials and occurs as part of the interactive authentication (logon) process.

1. (Interactive authentication only) A user accesses a client machine and provides a domain name, user name, and password. The client computes a cryptographic hash of the password and discards the actual password.

2. The client sends the user name to the server (in plaintext).

3. The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client.

4. The client encrypts this challenge with the hash of the user's password and returns the result to the server. This is called the response.

5. The server sends the following three items to the domain controller: the user name, the challenge sent to the client, and the response received from the client.

6. The domain controller uses the user name to retrieve the hash of the user's password from the Security Account Manager database. It uses this password hash to encrypt the challenge.

7. The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful.

3.2 Kerberos Security Overview The Kerberos protocol defines how clients interact with a network authentication service. Clients obtain tickets from the Kerberos Key Distribution Center (KDC), and they present these tickets to servers when connections are established. Kerberos tickets represent the client's network credentials.

The Kerberos authentication protocol provides a mechanism for mutual authentication between entities before a secure network connection is established. Throughout this documentation, the two entities are called the client and the server even though secure network connections can be made between servers. Both client and server can also be referred to as security principals.



The Kerberos protocol assumes that transactions between clients and servers take place on an open network where most clients and many servers are not physically secure, and packets traveling along the network can be monitored and modified at will. The assumed environment is like today's Internet where an attacker can easily pose as either a client or a server, and can readily eavesdrop on or tamper with communications between legitimate clients and servers.

3.3 Microsoft Negotiate Microsoft Negotiate is a security support provider (SSP) that acts as an application layer between Security Support Provider Interface (SSPI) and the other SSPs. When MSMP calls into SSPI to log on to a network, it can specify an SSP to process the request. If the application specifies Negotiate, Negotiate analyzes the request and picks the best SSP to handle the request based on customer-configured security policy.

Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos unless it cannot be used by one of the systems involved in the authentication or MSMP did not provide sufficient information to use Kerberos.



To allow Negotiate to select the Kerberos security provider, MSMP provides a service principal name (SPN), a user principal name (UPN), or a NetBIOS account name as the target name. Otherwise, Negotiate always selects the NTLM security provider.

A server that uses the Negotiate package is able to respond to MSMP requests that specifically select either the Kerberos or NTLM security provider. However, the application must know that a server supports the Negotiate package to request authentication using Negotiate. A server that does not support Negotiate cannot always respond to requests from clients that specify Negotiate as the SSP.

3.3.1 Reasons MSMP may use the Negotiate Package

1. Allows the system to use the strongest (most secure) available protocol.

2. Ensures forward compatibility.

3. Ensures that the network exhibits behavior that is in accordance with the security policy set by the customer.

3.4 LSA User Logon Authentication The LSA handles user logon and authentication on the local machine, and when the MSMP Remote Administration Console, which in this case is the authentication package processing the logon request, supports pass-through authentication, the LSA can also log users on to other machines on the network. This concept can also be applied to Remote Admin Consoles being allowed to logon to other Command Servers and sites. The LSA provides access to authentication packages for Graphical Identification and Authentication (GINA) DLLs and Security Support Providers (SSPs). Depending on which of these components calls the LSA, one of the two following types of authentication is performed.

3.4.1 Interactive Authentication

Authentication is interactive when a user is prompted to supply logon information. The LSA performs an interactive authentication when a user logs on through the GINA user interface. The following diagram shows the components involved in a typical interactive authentication.



A user signals the system to begin the logon sequence by typing the CTRL+ALT+DEL secure attention sequence (SAS). Winlogon receives the SAS and calls the GINA to display a user interface and obtain the user's logon data, such as a user name and password.

After obtaining the logon data, the GINA calls the LsaLogonUser function to authenticate the user, specifying which authentication package must be used to evaluate the logon data.

The LSA calls the specified authentication package and passes the logon data to it. The authentication package examines the data and determines whether or not the authentication is successful. The authentication result is returned to the LSA and from the LSA, to the GINA.

The GINA displays the success or failure of the authentication to the user and returns the result of the authentication to Winlogon. If the authentication succeeds, the user's logon session begins and a set of logon credentials are saved for future reference.

Once the logon credentials exist, MSMP can continually refer to these credentials to repeatedly validate the user against his “access level” and “privileges” designated within MSMP.

3.4.2 Noninteractive Authentication

Noninteractive authentication can only be used after an interactive authentication has taken place. During noninteractive authentication, the user does not input logon data, instead, previously established credentials are used.

Noninteractive authentication is performed when MSMP uses the Security Support Provider Interface (SSPI) and a security package to establish a secure network connection. Noninteractive authentication is the mechanism at work when a user connects to multiple machines on a network without having to re-enter logon information for each machine. For example, if an application needs to open a secure folder on a remote machine and the application user is already interactively logged on to a domain account, the application does not require the user to supply logon data again. Instead, the application can request a noninteractive authentication by using SSPI to pass the previously established security information to a security package. This process also happens when an MSMP remote administration console requests a connection to a remote command server after the user is logged in and the console is already running. The security package then uses LSA functions to check the credentials. The following diagram illustrates this procedure.



In the preceding diagram, the client application initiates a call to SSPI to request an authenticated network connection. SSPI passes the client's request to a security package for processing. The security package authenticates the user by calling the LSA and specifying an authentication package and providing the user's existing credentials.

The authentication result is passed from the authentication package, through the LSA, to the security package, and finally to SSPI. SSPI notifies MSMP Remote Administration Console about the outcome of the request.

3.5 Client/Server Access Control in MSMP MSMP provides services to client users. For example, MSMP performs the following services on behalf of a client user:

? Save and retrieve information from the central Command Server database

? Access network resources, databases, and site command servers

? Start processes in the client's security context on the server's computer

? A protected server controls access to its services. MSMP provides security support that enables the Remote Administration Console (RAC) to do the following:

o Impersonate a client's security context, which causes the system to perform most access and privilege checks against the client's access token (credentials)

o Log a client on to the server's computer (command server)

o Connect to network resources using the client's security context (database)



o Create security descriptors to protect private objects (MSMP privileges)

o Determine whether a security descriptor allows access to a client

o Determine whether a set of privileges are enabled in a client's token

o Generate audit messages in the security event log to record attempts by a client to access objects or use privileges

3.6 Remote Administration Console The Remote Administration Console is the tool used to provide administrators with access to the MSMP environment. This console is the primary application interface which validates user credentials and establishes the level of access a user has to administration tasks.

It’s important to understand that when the user first logs into the Windows operating system, credentials are established and stored. Once these credentials have been established, The MSMP Remote Administration Console can validate the user account automatically using the “non-interactive authentication” process and provide the appropriate level of access. No additional login is necessary as the request to the LSA provider makes this all transparent to the user.

However, if the user credentials do not match any accounts selected in the Site security database of MSMP, then the LSA provider will present the user with a logon dialogue box with which to provide an opportunity to initiate a login using “interactive authentication”. If the name and password are entered correctly, then access will be provided.

3.6.1 Site Scoping

The Remote Administration Console has the ability to connect to additional command servers and databases within the MSMP distributed architecture. Each command server and database pair governs it’s security separately thus it may be possible for a user to connect to one command server but not another.

If user A’s account has been added as an admin to command server X, but not command server Y, then the console will be able to be scoped and connected only to command server X since user A credentials are current saved on the local client system.

To gain access to Command Server Y, you may log out and re-login to Windows with the proper user account. Or, you may simply add User A to the Site security database of Command Server Y.



To connect the Console to a different Command Server:

1. On the File menu, click “Open Site”

2. In the Select Site Pop Up Window, click “New”

3. In the “Add Site Information Window”, type the IP address, DNS name, or Netbios name of the command server you wish to connect to.

4. Enter a common description. This command server will be saved in the connection list for future use from this console. You will not have to enter this information again.

5. Click OK.

6. Highlight the command server you wish to connect to. Click “Open”

At this point, if the credentials match a valid user account on the target command server, a connection will be made, and access granted.

3.7 Implementing Console Site Security You can restrict or grant access to the server by using a GUI interface which allows you to select user and group object from the Active Directory (ADS) server tree, or NT based SAM databases on stand alone servers, or domain controllers.



To reiterate, when the Console starts it verifies the saved credentials by making a call to the LSA provider and insures that this account is listed in the Site security database of MSMP.

3.7.1 Adding Users and Groups

You can add individuals, local groups, and global groups of users to the system. It is easier to create groups and specify settings for that group rather than adding each user individually. Groups are managed from the Active directory database. You select users from a variety of supported sources including domain controllers, active directory servers, and local Windows NT or 2000.

Initially, the security system is set up with a master admin account during server installation. This account is defaulted to the logged in administrator on the command server at the time of server installation. There is at least one master admin account. It cannot be removed, although it can be changed to another user. This account has all security policies assigned to it. You can change the account at the server in the server configuration utility. All accounts assigned rights to the MSMP environment must be selected from a valid SAM database, or ADS tree object.

Note: Security is designed for policy control from the remote management console and is not applied to the interactive context on the server itself.

To add a user or group:

1. On the File menu, click Modify Site Security.

2. Click Add.

3. Scroll or type the name of the user or group you want to add. Click or type the name and click OK.

4. Do one of the following:



a. To allow this person all rights, select the Master Administrator check box. This person has full rights to the entire Mobile Lifecycle Management Suite.

b. To limit the rights for this person, checkbox the activities you want this person to be able to perform.

5. Click OK. At the prompt, click OK again. The user has the new rights at the next log in.

To modify an existing user or group

1. On the File menu, click Modify Site Security.

2. Click the name of the user or group you want to modify and click Edit.

3. Make your changes. Click OK when you are done. At the prompt, click OK again. The user(s) sees the new rights at the next log in.

mobile secure management platform automation/ma... · mobile secure management platform mobile...

Documents