Upgrade from NTLM to Kerberos

I need a solution

Hi,

On my proxy SG, I have already configured NTLM authentication with BCAAA. I need now to upgrade to Kerberos.

I saw here how to implemnet kerberos :

https://support.symantec.com/en_US/article.TECH250…

But my question is : do I have to do all steps even if NTLM is already configured ?

Example : 

  • Create a DNS “A” record
  • Create a domain user account for the BCAAA
  • In the Local Security Policy of the server on which BCAAA is running, modify
  • the user rights assignment for the BCAAA domain
  • Enter the following case-sensitive command:
  • setspn -A HTTP/<FQDN_of_Proxy> <AD_Account_Name>

Or is there some steps already done with NTLM configuration and no need to do it again ?

0

1534853089

Related:

7021626: Third-Party Kerberos Software for Reflection Security Features

Kerberized Software and Servers

The companies listed below supply Kerberos server software and kerberized application servers. These products provide a complete solution for use with kerberized Reflection products.

MIT Public Domain Reference Implementation

MIT develops Kerberos 5 KDC and kerberized application servers. Reflection Kerberos provides support for the MIT Kerberos 5 reference releases, which are academic demonstration UNIX software with very limited support. Attachmate has tested and approved the krb5-1.0.x, through 1.8 releases of MIT’s Kerberos implementations. For more information, visit the MIT Kerberos web site:

Microsoft Corporation

Microsoft’s Windows 2000, 2003, and 2008 Active Directory servers use Kerberos for authentication of users on Windows operating systems and thus may be used as Kerberos KDCs. Currently, Microsoft does not provide kerberized Telnet or FTP servers. For information about Microsoft’s Kerberos implementations, visit the Microsoft web site:

Microsoft also provides information about configuring Microsoft and MIT KDCs and servers for interoperability on the following web page:

Centrify DirectControl

Centrify DirectControl provides a service that allows Kerberos applications to work transparently with Microsoft Active Directory. The Centrify site offers more information:

Quest Authentication Services

Quest Software offers Quest Authentication Services (formerly Vintela Authentication Services – VAS) for Microsoft Active Directory, integrating Unix/Linux platforms with Microsoft Active Directory. Quest Authentication Services uses Kerberos to protect user credentials. For more information, visit the Quest Software site:

CyberSafe Corporation

CyberSave offers a wide range of Kerberos products and services. The products known as TrustBroker™, previously known as Challenger and ActiveTRUST, are Attachmate tested and approved. For more information, visit the CyberSafe Corporation web site:

Hewlett-Packard Company

HP supports Kerberos and offers Kerberos Server Version 2.0 for HP-UX 11i, based on MIT Kerberos v5 Release 1.2.2. For more information, visit the HP web site:

In addition, HP offers Kerberos version 2.0 for OpenVMS Alpha version 7.2-2 and higher, based on the MIT Kerberos v5 Release 1.2.6 (plus security patches provided in Release 1.2.7 and 1.2.8). For more information, visit the HP web site:

Sun Microsystems

Sun supports Kerberos 5 and kerberized application servers with the Sun Enterprise Authentication Mechanism (SEAM) product. This is delivered with Solaris 8, 9, or 10 but can be retrofitted to Solaris 2.6 and 7 operating systems. For more information, visit the Sun web site:

IBM

IBM supports Kerberos 5 and kerberized application servers for AIX 4.3.3, and 5.x and 6.x with the Network Authentication Service version 1.x. It comes packaged with the AIX 4.3.3 Bonus Packs. For more information, visit the IBM web site:

Cygnus Solutions KerbNet

Cygnus produced Kerberos 5 KDC and kerberized application servers. Reflection Kerberos provides support for the KerbNet version 1.2 release, which was a short-lived commercial implementation of the MIT 1.0.2 reference-level UNIX software. This product is no longer available, and there is no support for it. Attachmate has tested and approved the 1.2 release of the KerbNet Kerberos implementation. Cygnus Solution has since merged with RedHat. Source and binary distributions are no longer available for download.

DCE Security Environments

The following companies provide DCE (Distributed Computing Environment) Security environments, which can provide Kerberos 5 credentials for use with Reflection Kerberos. However, these companies’ products rely on DCE RPC (Remote Procedure Call) technology alone, and do not include a kerberized Telnet or FTP server. To use these products with kerberized Reflection products, you must have a kerberized application server.

Note that only authentication is available with DCE implementations. Data stream encryption using Kerberos protocol is not supported by DCE servers.

SCO, Inc.

SCO produces Kerberos and DCE products. Their product, SCO DCE Security Server, can be used as a DCE cell security server and as a stand-alone Kerberos server. For more information, contact your local SCO channel partner or visit the SCO web site:

Evaluating Other Vendors

Other vendors provide support for DCE and Kerberos in their products. To use their products with the Reflection Kerberos client, ask for support of IETF RFC 1510 and 2942 compliant Kerberos 5 protocols, a credentials server (Key Distribution Center), and the availability of a kerberized Telnet and/or FTP server.

Related:

Follow on to: Active Directory configuration for UrbanCode Deploy

I am working on a project to convert from an outdated LDAP directory to Microsoft Active Directory. I have created the new “Authentication Realm” however, there is no option present to specify the address or domain name of the new server to use. I have checked the server.properties file and I don’s see the authentication server specified there either. Is there some place else on the server or within the interface that I should be looking? Doing this for both Deploy and Release. Searching through the forums and such only returned this result, so if there is an answer already, a pointer in that direction would be nice. Thank you.

Related:

DB2 Authentication Anomaly

Hi,
The following Configuration:
Client Userid-Password Plugin (CLNT_PW_PLUGIN) = IBMOSauthclient
Client Kerberos Plugin (CLNT_KRB_PLUGIN) =
Group Plugin (GROUP_PLUGIN) =
GSS Plugin for Local Authorization (LOCAL_GSSPLUGIN) =
Server Plugin Mode (SRV_PLUGIN_MODE) = UNFENCED
Server List of GSS Plugins (SRVCON_GSSPLUGIN_LIST) =
Server Userid-Password Plugin (SRVCON_PW_PLUGIN) = txtserver
Server Connection Authentication (SRVCON_AUTH) = CLIENT
Database manager authentication (AUTHENTICATION) = SERVER
Alternate authentication (ALTERNATE_AUTH_ENC) = NOT_SPECIFIED
Cataloging allowed without authority (CATALOG_NOAUTH) = NO
Trusted client authentication (TRUST_CLNTAUTH) = CLIENT
Bypass federated authentication (FED_NOAUTH) = NO

I have overridden SRVCON_AUTH as CLIENT. meaning I should not be able to activate the database by using txtserver plugin user name and password.
It should not have allowed me. I do not understand why it allows activation using server password plugin even after stating to use CLIENT as Authentication setting.

Any Inputs?

Related:

Event ID 4 — Kerberos Client Configuration

Event ID 4 — Kerberos Client Configuration

Updated: November 30, 2007

Applies To: Windows Server 2008

If the client computers are joined to an Active Directory domain, the Kerberos client is configured to request ticket-granting tickets (TGTs) from the Kerberos Key Distribution Center (KDC) automatically. On successful receipt of the ticket, the Kerberos client caches the ticket on the local computer.

Event Details

Product: Windows Operating System
ID: 4
Source: Microsoft-Windows-Security-Kerberos
Version: 6.0
Symbolic Name: KERBEVT_KRB_AP_ERR_MODIFIED
Message: The kerberos client received a KRB_AP_ERR_MODIFIED error from the server %1. The target name used was %3. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named server accounts in the target realm (%2), and the client realm (%4). Please contact your system administrator.

Resolve
Delete an unused computer account by using Active Directory Users and Computers

A Kerberos ticket is encrypted by using the client computer account’s password for the resulting encryption used on the ticket. If the computer account’s password changes during the authentication process, the ticket cannot be decrypted. This can happen if a computer account was moved to a different forest and the original computer account object was not deleted. To resolve this issue, you should use Active Directory Users and Computers to delete the original computer account that is no longer used.

Note: The computer account is identified in the event log message.

To perform this procedure, you must be a member of the Domain Admins group, or you must have been delegated the appropriate authority.

To delete a computer account by using Active Directory Users and Computers:

  1. Log on to a domain controller or another computer that has the Remote Server Adminstration Tools installed.
  2. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
  3. Locate the computer account in Active Directory Domain Services (AD DS).
  4. Right-click the computer account, and then click Delete.

Verify

To verify that the Kerberos client is correctly configured, you should ensure that a Kerberos ticket was received from the Key Distribution Center (KDC) and cached on the local computer. You can view cached Kerberos tickets on the local computer by using the Klist command-line tool.

Note: Klist.exe is not included with Windows Vista, Windows Server 2003, Windows XP, or Windows 2000. You must download and install the Windows Server Resource Kit before you can use Klist.exe.

To view cached Kerberos tickets by using Klist:

  1. Log on to the Kerberos client computer.
  2. Click Start, point to All Programs, click Accessories, and then click Command Prompt.
  3. Type klist tickets, and then press ENTER.
  4. Verify that a cached Kerberos ticket is available.
    • Ensure that the Client field displays the client on which you are running Klist.
    • Ensure that the Server field displays the domain in which you are connecting.
  5. Close the command prompt.

Related Management Information

Kerberos Client Configuration

Core Security

Related:

Event ID 637 — Trust Policy and Configuration

Event ID 637 — Trust Policy and Configuration

Updated: December 3, 2008

Applies To: Windows Server 2008 R2

The Active Directory Federation Services (AD FS) trust policy file defines the set of parameters that a Federation Service requires to identify partners, certificates, account stores, claims, and the various properties of these entities that are associated with the Federation Service.

Event Details

Product: Windows Operating System
ID: 637
Source: Microsoft-Windows-ADFS
Version: 6.1
Symbolic Name: LdapOptionNotSupportedForActiveDirectory
Message: The Federation Service encountered an error while loading the trust policy. The Active Directory Domain Services account store is configured improperly. The ‘%1’ field, which is configured on the Active Directory Domain Services store, is supported only on Active Directory Lightweight Directory Services (AD LDS) stores. Field: %1 If this error occurs during startup of the Federation Service, the Federation Service will be not be able to start, and all requests to the Federation Service will fail until the configuration is corrected. If this error occurs while the Federation Service is running, the Federation Service will continue to use the last trust policy that was loaded successfully. User Action This error should occur only if the trust policy file has been modified without use of the AD FS administrative tools. Remove the specified field from the trust policy file.

Resolve
Remove the LDAP option for the AD DS store in the trust policy file

This error occurs only if the trust policy file has been modified without the use of the Active Directory Federation Services snap-in.

The Lightweight Directory Access Protocol (LDAP) port and LDAP server name are specified only for the Active Directory Lightweight Directory Services (AD LDS) account store and not for the Active Directory Domain Services (AD DS) account store. Review your script (the parameter for your account store), and remove the specified field from the trust policy file.

To perform this procedure, you must be a member of the local Administrators group, or you must have been delegated the appropriate authority.

To locate the AD LDS settings:

  1. On the federation server, click Start, point to Administrative Tools, and then click Active Directory Federation Services.
  2. In the console tree, under Federation Service\Trust Policy\My Organization\Account Stores, right-click the AD LDS account store, and then click Properties.

Verify

Verify that you can access the Active Directory Federation Services (AD FS)-enabled application from a client browser and that the resource can be accessed.

Related Management Information

Trust Policy and Configuration

Active Directory Federation Services

Related:

Event ID 14 Kerberos Key Integrity

Event ID 14 — Kerberos Key Integrity

Updated: November 30, 2007

Applies To: Windows Server 2008

Kerberos keys are created by the Key Distribution Center (KDC) and derived from the password of the user account. These keys are used by the Kerberos client to communicate with the Kerberos KDC in a secure manner.

Event Details

Product: Windows Operating System
ID: 14
Source: Microsoft-Windows-Kerberos-Key-Distribution-Center
Version: 6.0
Symbolic Name: KDCEVENT_NO_KEY_INTERSECTION_AS
Message: While processing an AS request for target service %1, the account %2 did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of %3). The requested etypes : %4. The accounts available etypes : %5. Changing or resetting the password of %6 will generate a proper key.

Resolve
Change the account password

To resolve this issue, you must reset the password of the user account referenced in the event log message. If the referenced user account is the service account for the Kerberos Key Distribution Center (KDC), use the section named “Reset the password of the KDC service account.” Otherwise, use the section named “Reset the password of the user account by using Active Directory Users and Computers.”

To perform these procedures, you must be a member of the Domain Admins group, or you must have been delegated the appropriate authority.

Reset the password of the user account by using Active Directory Users and Computers

To reset the password of the user account by using Active Directory Users and Computers:

  1. Log on to a computer that has Active Directory Users and Computers installed. It is installed by default on a domain controller.
  2. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
  3. Navigate to the organizational unit where the user account is stored. By default, this organizational unit is named Users.
  4. Right-click the user account, and then click Reset Password.
  5. In the New password box, type the new password.
  6. In the Confirm Password box, retype the password.
  7. Select the User must change password at next logon check box, and then click OK.
  8. Close Active Directory Users and Computers.

Reset the password of the KDC service account

You must reset the krbtgt account password by using Active Directory Users and Computers and then update the service account password information in the properties of the Kerberos KDC service.

To reset the krbtgt account password by using Active Directory Users and Computers:

  1. Log on to a computer that has Active Directory Users and Computers installed. It is installed by default on a domain controller.
  2. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
  3. Navigate to the organizational unit where the KDC service account is stored. By default, this organizational unit is named Users.
  4. Right-click krbtgt, and then click Reset Password.
  5. In the New password box, type the new password.
  6. In the Confirm Password box, retype the password.
  7. Clear the User must change password at next logon check box, and then click OK.
  8. Close Active Directory Users and Computers.
  9. Use the section named “Update the service account password information and restart the service” to update the password information in the properties of the Kerberos KDC service.

Update the service account password information and restart the service

To update the service account password information in the properties of the Kerberos KDC service:

  1. Log on to the domain controller in which the issue is occurring.
  2. Click Start, point to Administrative Tools, and then click Services.
  3. Right-click Kerberos Key Distribution Center, and then click Properties.
  4. Click the Log On tab.
  5. In the Password and Confirm password boxes, type the new password, and then click OK.
  6. Right-click Kerberos Key Distribution Center, and then click Restart.
  7. Close the Services snap-in console.

Verify

A valid Kerberos key is required to get a Kerberos ticket from the Kerberos Key Distribution Center (KDC). To verify that the Kerberos keys are valid and functioning correctly, you should ensure that a Kerberos ticket was received from the KDC and cached on the local computer. You can view cached Kerberos tickets on the local computer by using the Klist command-line tool.

Note: Klist.exe is not included with Windows Vista, Windows Server 2003, Windows XP, or Windows 2000. You must download and install the Windows Server Resource Kit before you can use Klist.exe.

To view cached Kerberos tickets by using Klist:

  1. Log on to a Kerberos client computer within your domain.
  2. Click Start, point to All Programs, click Accessories, and then click Command Prompt.
  3. Type klist tickets, and then press ENTER.
  4. Verify that a cached Kerberos ticket is available.
    • Ensure that the Client field displays the client on which you are running Klist.
    • Ensure that the Server field displays the domain in which you are connecting.
  5. Close the command prompt.

Related Management Information

Kerberos Key Integrity

Core Security

Related:

Could not connect over LDAP to . This domain controller is running . Please upgrade to Windows 2000 SP3 or later.

Details
Product: Exchange
Event ID: 8338
Source: MSExchangeADDXA
Version: 6.5.6940.0
Component: Microsoft Exchange Active Directory DXA Connector
Message: Could not connect over LDAP to <server name>. This domain controller is running <value> <value>. Please upgrade to Windows 2000 SP3 or later.<connection agreement name>
   
Explanation

Could not connect over Lightweight Directory Access Protocol (LDAP) using the version of Windows that the designated domain controller is running.

If you receive this event, this could indicate that the connection agreement is unable to function.

   
User Action

Upgrade to Windows 2000 SP3 or later.

Related: