2.7 User Source Authentication

By default, a user is automatically authenticated to the Management Zone when he or she logs in to an LDAP directory (Novell eDirectory or Microsoft Active Directory) that has been defined as a user source in the Management Zone. User authentication to ZENworks can occur only if the user’s LDAP directory (or the user’s LDAP directory context) is defined as a user source in ZENworks.

The ZENworks Adaptive Agent integrates with the Windows Login or Novell Login client to provide a single login experience for users. When users enter their eDirectory or Active Directory credentials in the Windows or Novell client, they are logged in to the Management Zone if the credentials match the ones in a ZENworks user source. Otherwise, a separate ZENworks login screen prompts the user for the correct credentials.

For example, assume that a user has accounts in two eDirectory trees: Tree1 and Tree2. Tree1 is defined as a user source in the Management Zone, but Tree2 is not. If the user logs in to Tree1, he or she is automatically logged in to the Management Zone. However, if the user logs in to Tree2, the Adaptive Agent login screen appears and prompts the user for the Tree1 credentials.

Review the following sections:

Enabling Seamless Authentication on a Device

The first time a user logs in to a device that has more than one user source enabled, the user is prompted to select the user source and specify the user source credentials. During subsequent logins, the user is automatically logged in to the user source selected during the first login. However, if you do not want the user to be prompted to select the user source during the first login, perform the following steps to enable seamless login on the device:

  1. Open the Registry Editor.

  2. Go to HKLM/Software/Novell/ZCM/ZenLgn/.

  3. Create a DWORD called EnableSeamlessLogin and set the value to 1.

If seamless login is enabled, a user's first login to a device might be slow. This is because all the existing user sources are searched and the user is logged in to the first user source that matches the user account. If many users use the same device, subsequent logins might also be slow because the user information might not be cached on the device.

Reducing Device Login Time by Specifying the Default User Source

To reduce the login time, specify the default user source for the user to seamlessly log in to the device:

  1. Open the Registry Editor.

  2. Go to HKLM/Software/Novell/ZCM/ZenLgn/.

  3. Create a String called DefaultRealm and set its value to the desired user source.

    For example, if all the users should log in to a user source named POLICY-TREE, create a String called DefaultRealm and set its value to POLICY-TREE.

If the login to the specified default user source fails, the other existing user sources are searched, then the user is logged in to the user source that matches the user account.

Identifying the LDAP Directory That the User Has Logged In To

If the Novell Client is installed on a device, the HKLM\Software\Novell\ZCM\ZenLgn registry key that has DWORDS, DomainLogin and eDIRLogin is added by default on the device. The value of DomainLogin and eDIRLogin helps you identify whether a logged-in user has logged into Novell eDirectory or Microsoft Active Directory.

For example:

  • If DomainLogin is set to 1, the user has logged in to Microsoft Active Directory.

  • If eDIRLogin is set to 1, the user has logged in to Novell eDirectory.

  • If both DomainLogin and eDIRLogin are set to 1, the user has logged in to both Microsoft Active Directory and Novell eDirectory.

This login information might be useful in the following scenarios:

Scenario 1: If a user has logged in to Microsoft Active Directory, a DLU policy does not need to be enforced on a device. Even if you choose to enforce a DLU policy on the device, the policy is not effective on the device. Consequently, you can add a system requirement that the DLU policy must be effective on the device only when the user has logged in to Novell eDirectory.

Scenario 2: If a user has not logged in to Novell eDirectory, any bundle that must access content from a Netware shared location fails. Consequently, you can add a system requirement that the bundle must be effective on the device only when the user has logged in to Novell eDirectory.

Logging Directly in to a Workstation That has Both Novell Client and ZENworks Agent Installed

If you log into a device that has both Novell Client and ZENworks Agent installed, you are automatically logged in to ZENworks eDirectory, even if you have chosen to log in to the workstation only.

In the Novell Client dialog box, if you choose to log in to workstation only, then you must perform the following steps on the managed device to directly log in to the workstation:

On Windows XP:

  1. Open the Registry Editor.

  2. Go to HKLM\Software\Novell\ZCM\ZenLgn\.

  3. Create a DWORD called HonorClient32WorkstationOnlyCheckbox and set its value to 1.

On Windows Vista/Windows 7/Windows 8:

  1. Open the Registry Editor.

  2. Go to HKLM\Software\Novell\ZCM.

  3. Create a DWORD called HonorWorkstationOnlyLogin and set its value to 1.

Authenticating in to a ZENworks Server That Has Novell SecretStore Configured

If you choose to log into a ZENworks Server that has Novell SecretStore configured, perform the following steps on the managed device:

  1. Open the Registry Editor.

  2. Go to HKLM/Software/Novell/ZCM/ZenLgn/.

  3. Create a DWORD called EnableSecretStore and set its value to 1. However, if the DWORD already exists, then ensure that its value is set to 1.

Enabling SecretStore on the device might increase the time to authenticate to the ZENworks Server, depending on the number of eDirectory servers that have been added to the Management Zone. For more information on SecretStore operations, see TID 10091039 in the Novell Support Knowledgebase.

For information on the various authentication mechanisms, credential storage, and disabling user authentication, review the following sections:

2.7.1 Authentication Mechanisms

The following mechanisms can be used to authenticate managed devices to the ZENworks Management Zone:

Kerberos (Active Directory or Domain Services for Windows)

Kerberos, an authentication protocol developed at MIT, requires entities (for example, a user and a network service) that need to communicate over an insecure network to prove their identity to one another so that secure authentication can take place.

Kerberos functionality is included natively in a Windows Active Directory environment.

Kerberos requires the use of a Key Distribution Center (KDC) to act as a trusted third party between these entities. All Kerberos server machines need a keytab file to authenticate to the Key Distribution Center (KDC). The keytab file is an encrypted, local, on-disk copy of the host's key.

When using Kerberos authentication, the Active Directory server generates a Kerberos ticket that Novell Common Authentication Services Adapter (CASA) uses to authenticate the user, rather than using a username and password for authentication.

Setting Up Kerberos in your ZENworks Environment

IMPORTANT:If the Active Directory or Domain Services for Windows user source is configured to use only Kerberos authentication mechanism, ensure that the managed device is added to the user source domain.

  1. Set up a Kerberos service principal account and generate a keytab file for that account.

    For more information, see the Microsoft TechNet Web site.

    For example, if you created a user called atsserver in your domain, you would run the following command from the command prompt:

    ktpass /princ host/atsserver.myserver.com@MYSERVER.COM -pass atsserver_password -mapuser domain\atsserver -out atsserver.keytab -mapOp set -ptype KRB5_NT_PRINCIPAL

    This command creates a keytab file and modifies the user atsserver to be a Kerberos principal.

  2. Import the keytab file into ZENworks Control Center.

    1. In ZENworks Control Center, click the Configuration tab, click Infrastructure Management, then click User Source Settings.

    2. Click Browse icon to browse to and select the keytab file.

    3. Click OK to import the file.

  3. Restart the ZENserver service.

Enabling Kerberos Authentication While Adding a User Source

You can enable Kerberos authentication while adding a user source. For more information see Section 2.2.1, Adding User Sources.

Enabling Kerberos Authentication on an Existing User Source

You can enable Kerberos authentication on an existing user source.

  1. In ZENworks Control Center, click the Configuration tab.

  2. In the User Sources panel, click the user source, then click Edit next to Authentication Mechanisms in the General section.

  3. Select the Kerberos check box, then click OK.

Understanding How Kerberos Authentication and the ZENworks Login Dialog Box Interact

The following table illustrates the ZENworks user experience using Kerberos authentication with Active Directory:

Table 2-1 ZENworks Kerberos Authentication with Active Directory

Windows login matches user source login?

ZENworks also uses Username/Password authentication?

Member of same domain?

Member of different domain?

Windows and ZENworks credentials match?

Can log in to Management Zone?

ZENworks login dialog box appears?

Checked icon

Checked icon

Checked icon

 

Checked icon

Yes

No

Checked icon

 

Checked icon

 

Checked icon

Yes

No

 

Checked icon

 

Checked icon

 

Yes

Yes

 

 

 

Checked icon

 

No

No

 

 

 

Checked icon

Checked icon

No

No

 

 

 

 

 

No

No

 

 

 

 

Checked icon

No

No

Checked icon

Checked icon

 

 

Checked icon

Yes

No

 

Checked icon

 

Checked icon

Checked icon

Yes

No

 

Checked icon

 

 

 

Yes

Yes

For example, in the second row, the user’s initial login, user source, and ZENworks login credentials match. As a result, the user can log in to the ZENworks Management Zone and the ZENworks login dialog box does not appear.

As another example, in the third row, the user’s initial login credentials are using credentials from a different domain and are different than the ZENworks login credentials. As a result, the user can log in to the ZENworks Management Zone, but the ZENworks login dialog box appears.

Configuring ZENworks for Performing Kerberos Authentication with Domain Services for Windows (DSfW) Server

This section provides information about the tasks that need to be performed on DSfW and ZENworks Servers to configure Kerberos authentication for ZENworks login. It also includes information about additional settings and workarounds that need to be performed on the DSfW Server to ensure smooth Kerberos authentication for all users.

Pre-requisites

Configuring DSfW Server and Windows Workstation

For example, you can use the credentials provided below to configure the DSfW Server and Windows Workstation.

  • Domain name : cit193.com

  • User name for creating key tab file : mcertuser

  • Users for verifying the setup : muser1, muser2

To configure DSfW Server and Windows Workstation, you need to first add the Windows Workstation to the DSfW domain:

  1. Add the DSfW Server as the DNS Server.

  2. Select My Computer > Properties, then change the domain for the workstation to the DSfW server's domain.

  3. Provide the required credentials to add the workstation to the domain.

  4. Restart the client.

  5. Install Admin tools and Support tools on the client machine.

  6. These tools facilitate the DSfW Server management to create the keytab file. You can find the download details at http://www.microsoft.com/download/en/details.aspx?id=6315.

  7. Install the ZENworks client on the same client by downloading the appropriate ZENworks client set-up from the http://<ZEN server>/zenworks-setup server.

  8. Create a user in DSfW server by using Microsoft Management Console (MMC), which can be associated to the DSfW service by creating a keytab file. In this case, the user for creating the keytab file is mcertuser. The expected result is as shown in figure below.

ZENworks Server Configuration

Adding DSfW as a User Source in ZENworks

To add a user source and choose Kerberos as the authentication mechanism, see http://www.novell.com/documentation/zenworks11/zen11_system_admin/?page=/documentation/zenworks11/zen11_system_admin/data/bafywtr.html.

To verify the result, click the user source enabled with Kerberos. The result appears as shown in figure.

Adding a Kerberos Keytab file

  1. Log in to ZENworks Control Center.

  2. In Infrastructure Management, select Configuration > User Source Settings.

  3. Add the Kerberos keytab file. After the keytab file is you can view the details as shown in the figure.

Kerberos Authentication for Windows Workstation

To verify the settings and to ensure the working of Kerberos authentication on the client machine, login to Windows as any user. For example, you can log in as either muser1 or muser2 created using MMC.

The same login credentials are passed on to the ZENworks client and login happens seamlessly to the Windows workstation with the same user.

NOTE:

  • The user used for creating the keytab file cannot login using ZENworks client as this user is associated with a Service Principal Name (SPN) rather than a User Principal Name (UPN).

  • The UPN attribute is mandatory for a successful ZENworks Configuration Management and DSfW integration. The UPN attribute is created when the user is created by using the MMC.

  • In case of ConsoleOne and iManager tools, the user created will not have the UPN attribute.

Troubleshooting Tips

Issue: A user created by using iManager cannot login seamlessly using the ZENworks client.

The login fails with the error message “Could not attempt login because either username or password is null” as shown in the figure.

Possible Cause 1: The User Principal Name (UPN) attribute is not set for the users created using iManager.

Workaround: Set the UPN attribute by selecting the user to be supported for Kerberos authentication.To set the UPN attribute:

  1. Log in to iManager.

  2. Select Directory Administration > Modify object. Also, set this attribute in the Others tab as shown in the figure.

Possible Cause 2: The dnsDomainName attribute is not set at the root level in the DSfW domain.

Workaround: Set the dnsDomainName attribute at the root level of the DSfW domain so that reflects at the user's level.

To set the dnsDomainName attribute:

  1. Log in to iManager and select the domain root object. For example you can select cit193.com.

  2. Modify the object and add the Description field.

  3. Add the attribute dnsDomainName=cit193.com.

  4. Restart the ndsd (Novell Directory) services on the DSfW server.

    The existing user once modified and any user objects that you create in future will automatically gets the UserPrincipalName attribute. For more information, see TID 7009221 from the Novell Support Knowledgebase http://www.novell.com/support/documentLink.do?externalID=7009221.

Useful Links

Shared Secret

When using Shared Secret authentication, you must install and configure the Novell Identity Assurance Solution Client. For more information, and for a list of supported smart card readers and smart cards, see the Identity Assurance Solution Client documentation on the Novell Documentation Web site.

Authentication in to ZENworks by using Smart Card is currently supported only on Windows XP and terminal sessions of Windows Server 2003 device.

When a user uses a smart card to log in to eDirectory, the user is automatically logged in to ZENworks provided the schema of the eDirectory specified when the user source is added has been extended using novell-zenworks-configure tool.

For more information on adding the user source, see Section 2.2.1, Adding User Sources.

For more information on extending the eDirectory schema, see Extending the eDirectory Schema to enable Shared Secret Authentication.

If the eDirectory schema is not extended, then Shared Secret is not available as an authentication mechanism. Consequently, a ZENworks login dialog box is displayed when the user on the managed device attempts to log in to eDirectory using a smart card. After the user specifies the eDirectory username and password, that password is stored in Novell SecretStore. The next time the user uses a smart card to log in to eDirectory, the password is retrieved from SecretStore and the user is logged in to the ZENworks without having to specify the password.

Extending the eDirectory Schema to enable Shared Secret Authentication

To authenticate in to ZENworks by using Shared Secret authentication mechanism, the schema of the eDirectory specified when the user source is added must have been extended using novell-zenworks-configure tool.

Perform the following steps to extend the eDirectory schema:

  1. Run the novell-zenworks-configure utility on a ZENworks Server:

    On Windows: At the command prompt, change to ZENworks_installation_path\bin and enter the following command:

    novell-zenworks-configure.bat -c ExtendSchemaForSmartCard

    On Linux: At the console prompt, change to /opt/novell/zenworks/bin and enter the following command:

    ./novell-zenworks-configure -c ExtendSchemaForSmartCard

  2. You are prompted to continue with the action of extending the Novell eDirectory schema and adding an optional zcmSharedSecret attribute to the user class. By default, 1 is selected. Press Enter.

  3. Enter the DNS name or IP address of the Novell eDirectory server to extend the schema.

  4. You are prompted to select Secure Socket Layer (SSL) or Clear Text communication for communicating with the eDirectory server. Enter 1 for SSL communication or 2 for Clear Text Communication, then press Enter again.

  5. Enter the port for communicating with the eDirectory server.

    The default port for SSL communication is 636 and for Clear Text communication is 389.

  6. Enter the fully distinguished name (FDN) of the Administrative User.

    For example, cn=admin,o=organization

  7. Enter the password for the Administrative User specified in Step 6.

  8. (Optional) Enter the fully distinguished name for the ZENworks user source admin for whom the ACL would be applied.

    The ZENworks user source admin is configured as a user in the ZENworks user source configuration for reading users from the user source and need not be the Administrative User specified in Step 6. If you specify the fully distinguished name of this user, the program sets ACLs at the specified containers to provide read access to zcmSharedSecret attribute for this user.

  9. Enter the user containers for which you want to extend the schema.

    Multiple containers can be given separated by + sign. For example, o=sales or o=sales + o=marketing.

  10. Press Enter to generate random secret for all the users within the above containers.

  11. (Conditional) If you have chosen SSL communication for communicating with the eDirectory server, the server presents a certificate. Enter y to accept the certificate.

Username/Password (eDirectory, Active Directory, Domain Service for Windows)

When using Username/Password authentication with a Novell eDirectory, Microsoft Active Directory, or Domain Service for Windows user source, if the credentials the user specifies to log in to the workstation or to the domain match the ZENworks login credentials, the ZENworks login dialog box does not display and the user is authenticated to the ZENworks Management Zone.

The username and password are also stored in Secret Store. If a user later logs in to ZENworks where no username or password is available (for example, the user logged in using a smart card), the stored credentials are used and the ZENworks login dialog box is bypassed.

Enabling Username/Password Authentication While Adding a User Source

You can enable Username/Password authentication while adding a user source. For more information see Section 2.2.1, Adding User Sources.

Enabling Username/Password Authentication on an Existing User Source

You can enable Username/Password authentication on an existing user source.

  1. In ZENworks Control Center, click the Configuration tab, click the user source, then click Edit next to Authentication Mechanisms in the General section.

  2. In the User Sources panel, click the user source, then click Edit next to Authentication Mechanisms in the General section.

  3. Select the Username/Password check box, then click OK.

Understanding How Username/Password Authentication and the ZENworks Login Dialog Box Interact

The following table illustrates the ZENworks user experience using Username/Password authentication with Active Directory:

Table 2-2 ZENworks Username/Password Authentication with Active Directory

Windows login matches user source login?

ZENworks also uses Kerberos authentication?

Member of same domain?

Member of different domain?

Windows and ZENworks credentials match?

Can log in to Management Zone?

ZENworks login dialog box appears?

Checked icon

Checked icon

 

 

Checked icon

Yes

No

 

Checked icon

 

Checked icon

Checked icon

Yes

No

 

Checked icon

 

 

 

Yes

Yes

Checked icon

 

Checked icon

 

Checked icon

Yes

No

 

 

 

Checked icon

Checked icon

Yes

No

 

 

 

 

Checked icon

Yes

No

 

 

 

 

 

Yes

Yes

Checked icon

 

Checked icon

 

 

Yes

Yes

Checked icon

 

 

Checked icon

 

Yes

Yes

For example, in the first row, the user’s initial login, user source, and ZENworks login credentials match. As a result, the user can log in to the ZENworks Management Zone and the ZENworks login dialog box does not appear.

As another example, in the second row, the user’s initial login credentials are using credentials from a different domain but match the ZENworks login credentials. As a result, the user can log in to the ZENworks Management Zone, and the ZENworks login dialog box does not appear.

2.7.2 Credential Storage

ZENworks uses Novell CASA (Common Authentication Services Adapter) to enable single sign-on. When the ZENworks Adaptive Agent authenticates a user to the Management Zone via the credentials entered in the Microsoft client, Novell client, or ZENworks login screen, the username and password is stored in the secure CASA vault on the user’s device.

CASA is installed with the ZENworks Adaptive Agent. It includes the CASA Manager, which is an interface used to manage the credentials in the storage vault. The CASA Manager is available from the Start > Program Files > Novell CASA menu. Generally, you or the device’s user should not need to use the CASA Manager. When a user’s credentials change in the LDAP directory, they are updated in the CASA storage vault the next time the user logs in. If you run the CASA Manager, you are prompted to install the GTK# Library. If you choose to install the library (which is necessary to run the CASA Manager), you are directed to a Novell Web site. However, the GTK# Library is currently unavailable at this site. You can choose to install the GTK# Library by downloading and installing the gtksharp-runtime-2.8.3-win32-0.0.exe file from the Google Code site.

Do not remove CASA from the managed device. If you do not want the CASA Manager displayed to users, you can remove the Novell CASA folder from the Start > Program Files menu.

2.7.3 Disabling ZENworks User Authentication

By default, if a user source is defined in the ZENworks Management Zone, the ZENworks Adaptive Agent attempts to authenticate a user to the zone whenever he or she logs in through the Microsoft or Novell client.

If necessary, you can disable user authentication to the zone. For example, you might have some users that only receive device-assigned content, so you don’t want the overhead of having them logged in to the zone.

To disable user authentication to the zone:

  1. Locate the following key in the registry on the user’s device:

    HKEY_LOCAL_MACHINE\SOFTWARE\Novell\ZCM\ZenLgn

  2. (Conditional) If you want to disable login, add the following DWORD value:

    Value name: DisablePassiveModeLogin

    Value data: Any non-zero value (for example, 1, 2, 3, 100)

    With login disabled, no attempt is made to authenticate to the Management Zone when the user logs in through the Microsoft or Novell client.

  3. (Conditional) If you want to disable the ZENworks login prompt that appears if login through the Microsoft client or Novell client fails, add the following DWORD value:

    Value name: DisablePassiveModeLoginPrompt

    Value data: Any non-zero value (for example, 1, 2, 3, 100)

    Normally, the Adaptive Agent attempts to authenticate the user to the zone by using the credentials entered in the Microsoft or Novell client. If login fails, the ZENworks login prompt is displayed in order to give the user an opportunity to authenticate with different credentials. This value setting disables the ZENworks login prompt.

2.7.4 Manually Disabling a DLU on a Workstation

You might need to disable a Dynamic Local User that is in a domain environment. Use the following procedure to disable or suppress a DLU:

  1. Create a DWORD named DLUAllowed under HKLM\Software\Novell\Workstation Manager.

  2. Set the value of DLUAllowed to 0x0.

Logging in to an Account When a User Is Excluded in the DLU Policy

The Dynamic Local User policy creates and manages local accounts on their computers. Excluding a user or device from the DLU policy prevents the creation or management of local accounts on their computers.

However, you can use other existing credentials such as a domain account to log in to the computer, even when the device or user is listed in the exclusion list for that DLU policy.

2.7.5 Using a DLU in a Domain Environment

Domain authentication is not possible when you do a local login based on the eDirectory credentials and not the domain credentials. Enabling a DLU policy forces the creation and use of a local account that does not have access to domain resources, even if you are logged in to the domain.

When a DLU policy is enforced on devices joined to a domain, it forces a local log in instead of a domain log in. Using a DLU is not supported on a domain controller, because the domain controller has no local Security Accounts Manager (SAM) to provide a local login.

You might want to use a DLU for certain reasons, even when the device is in a domain:

  • When only devices are in domain and not the users, users need a DLU to ease access to their computers or if the domain trust is broken

  • When the users are in the middle of a migration and do not want to flip a switch

  • When users require access to local personal computers while accessing certain devices versus their normal domain rights

To manage Windows user accounts in an eDirectory environment:

  • Use an NT or AD domain and then use Account Management or Identity Manager to synchronize AD and eDirectory accounts and passwords

  • Use a DLU policy to automatically create and manage the Windows account upon eDirectory login

Using a DLU in a domain environment might cause problems in some of the following circumstances:

  • When the user assigned to a DLU policy attempts to log in to eDirectory, the Windows authentication is done with a local user and not a domain user. This is because the Windows authentication settings to log in to the domain are ignored, when the DLU policy is in effect.

  • When the user is authenticated to Windows with a local account, domain access appears to be working if the local Windows account and the domain Windows account have the same username and password. The DLU user, although it is based on eDirectory credentials has the same username and password as the user in the Active Directory domain. However, account access depends on where the authentication request originates:

    • When you use a local Windows account to access a resource from a domain controller, the authentication attempts work and access is granted because the domain user account exists in the local Security Accounts Manager (SAM) of the domain controller.

    • When you use a local Windows account to access a resource from a member server using a local Windows account, the authentication attempt fails and access is not granted because it is a member server and the domain user account does not exist in its local SAM. The member server cannot access a domain controller to obtain authentication.