Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >
article

[Basics] Understanding how Active Directory Functional Levels affect Centrified Systems

11 April,19 at 11:50 AM

What are Active Directory Functional Levels?

When Microsoft introduces new versions of Windows Server, they may add new capabilities to Active Directory. These new capabilities impact the environment and require planning, the “functional levels (or FLs)” can be introduced by the organization as they become ready. There are two types of functional level upgrade: domain (DFL) and forest (FFL); the scope of forest functional levels affect the whole subtree, and domain-level changes only affect the target domain. A very common misconception is that all features are enabled. A functional upgrade may make a new capability or schema objects available, but it does not mean that your organization is ready or will use those capabilities.

 

Why should I know this, I only deal with UNIX | Linux | Mac OS X and upper-layer apps (Apache, Java, SAP, DB2)?

When your organization committed to use Active Directory on non-Windows platforms, they gained efficiencies and improved security capabilities, however, AD becomes an integral piece of infrastructure just like power, cooling, switching/routing, etc. All systems relying on AD must be aware of “functional-level” major changes.

 

What will be the impact to my UNIX, Linux or Mac systems when the Functional level goes up?

The answer to this question really depends on how well you manage your environment.

The rule of thumb is this. If you deployed Centrify in your UNIX, Linux or Mac environment a few years ago and time constraints have kept you from maintaining it (or because it just works), you’ll have a tougher time. If you’ve been keeping-up with the software lifecycle (upgrades) and are listening-in your AD planning calls; you may be so ready that your impact could be close to nothing.

To level-set here, this is not a “Centrify-only” consideration; this affects software and hardware that integrates to Active Directory. This article is to deep-dive into Centrify Server Suite and Identity Service Mac Edition (on-premises client).

 

You caught my interest. Can you tell me more about Active Directory functional levels?

The best source of information is this Microsoft TechNet article: https://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels%28v=ws.10%29.aspx. If you want to be better informed, see the reading list below.

 

What happens when I raise the AD Functional Level as it relates to Centrify?

The answer depends on what your current functional level is and what functional you're raising it to.

Let’s focus on 3-key aspects of going from FL 2003 and FL 2012 (conveniently how I set up my lab Smiley Happy).

 

Kerberos

Centrify DirectControl (centrifydc/adclient), just like any other Active Directory client, uses Kerberos as the authentication protocol. In Kerberos session tickets encrypted using cyphers (algorithms).

As time passes-by both computers have more power and mathematicians grow smarter or find issues with existing algorithms. A very good example is the Data Encryption Standard (DES), it has been around since the 70s and it was broken in the late 90s; therefore DES became phased out by algorithms like TripleDES (or its variant AES).  One of the changes introduced by a DFL is better encryption algorithms.

 

  • Raising the DFL to Windows Server 2008 implements AES 128 and AES 256 for Kerberos.

 

This is why Microsoft's first guidance is to perform an inventory of your AD real estate. When this change happened, many older systems could not authenticate as illustrated in this example. In some instances, even a non-DFL change like adding a “newer OS” to perform the domain controller role can introduce side effects. For example, introducing a Windows Server 2012 Domain Controller to a Windows 2003 DFL Domain will immediately will disallow older crypto algorithms.

 

Summary – stronger cryptography is good, however, raising the DFL to Windows 2008+ OR introducing a Windows 2008+ domain controller in a 2003 forest requires at a minimum Server Suite 2014.1 (5.2.x).
Introducing newer domain controllers happens to be a best-practice when upgrading functional levels, so you must be ready for it.

 

 

KRBTGT Password Change

Active Directory has a built-in account called “krbtgt” (Kerberos TGT). This account has a complex password that is only known to low-level services; However, this is a very important account because every Ticket Granting Ticket (TGT) generated by users and computers is encrypted with a key that is derived from this password. As you probably can infer from the previous topic, once you switch the cypher, the secret is updated as well.

 

  • Raising the DFL will change the password of the KRBTGT account; this makes older secrets invalid.

Microsoft, as part of their strategy to mitigate advanced attacks like Pass-the-Hash (PtH) and others has established new best practices around the krbtgt account, but that’s the topic for another post.

 

Summary: When using stronger crypto, the passwords for the krbtgt will change.

 

SID Compression

The Windows Security Identifier (SID) is the unique and immutable identifier for an AD principal (user, group, etc.). Microsoft Kerberos implements methods that use the Privilege Attribute Certificate (PAC), in an over-simplistic way, the PAC contains information about the group membership and authorization information for the corresponding security principal.

Active Directory clients often need to make decisions about access control with information contained in the PAC; however when principals belong to large numbers of groups the information can't fit inside the data structure and that's why SID compression was implemented. Within Centrify Server Suite, this is very important especially in the context of Zones and DirectAuthorize.

 

  • Windows 2012 Domain Controllers implement SID compression and is turned on by default.  If an AD client can't decompress the SID to view the PAC, it will have functionality issues.

This has caused many known issues, however there's flexibility given that you can disable SID compression at the object  level or at the DC level.  Centrify DirectControl 5.2 and up are compatible with the SID compression feature.

 

Summary: SID compression is enabled on Windows 2012 DCs.  This is important for group enumeration and authorization.

 

Now you made me worried, What should I do?

 No need to be worried, there are plenty of resources available (see the reading list below); I think that by reading this article you should be informed and dangerous enough, however my advice is this:

 

  • Manage your Centrify Software lifecycle
    If you keep your Centrify software within the 3-year software lifecycle policy (for standard support, 5 years for premium), you should be fine. Keep in mind, you have to also be realistic. For example, Windows 2012 R2 was released in October of 2014 and Server Suite 2014.1 was released in August. In that case Centrify was ahead of the ball if organizations were looking to deploy that version of the software. In some instances we are behind and provide functionality based on the needs of our customer base.
  • Maintain your consoles and utilities up-to-date
    Consoles and PowerShell commandlets are backwards compatible. Tools like Deployment Report can be great tools to inventory clients. Make sure that you update those frequently.  You'll be pleasantly suprised.
  • Familiarize yourself with Microsoft’s methodology
    The methodology is outlined here: http://blogs.technet.com/b/askpfeplat/archive/2013/04/29/upgrading-or-migrating-active-directory-to-windows-server-2012-build-your-roadmap-now.aspx
    If you are working closely with your AD team, in the "assess" phase you should be providing an inventory of all your Centrify clients and inform them if the version installed will support these key things: AES Encryption, KRBTGT password changes and SID Compression.
  • Document  any exceptions
    You should also inventory if you have hardcoded certain parameters like adclient.krb5.permitted.encryption.types. Ideally you should let DCs negotiate with the client, they typically go for the maximum (AES256).

 

Any tools, tips or tricks to share?

You can use Centrify CLI tools, Consoles and Utilities to discover, diagnose and collect information for your Functional Upgrade project.  Here are some examples:

 

Determining the Centrify version (per system - see below for inventory)

$ adinfo -v
adinfo (CentrifyDC 5.2.3-429)

Determining the forest and domain functional levels (per forest/domain)

$ adinfo --diag | grep Functionality
    domainFunctionality:           5 = (DS_BEHAVIOR_WINSERVER_2012)
    forestFunctionality:           5 = (DS_BEHAVIOR_WINSERVER_2012)
    domainControllerFunctionality: 6
    domainFunctionality:           5 = (DS_BEHAVIOR_WINSERVER_2012)
    forestFunctionality:           5 = (DS_BEHAVIOR_WINSERVER_2012)
    domainControllerFunctionality: 6

Determining if the encryption types have been changed (per client exception)

$ grep encryption.types /etc/centrifydc/centrifydc.conf
# adclient.krb5.tkt.encryption.types: aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
# * the default encryption types permitted for Windows 2000 server and
#   adclient.krb5.permitted.encryption.types: arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
# * the default encryption types permitted for Windows Server 2008 domain
#   adclient.krb5.permitted.encryption.types: aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc

Determining the Kerberos system key table (keytab) encryption (per agent)

$ dzdo /usr/share/centrifydc/kerberos/bin/klist -ke /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   7 nfs/engcen6.centrify.vms@CENTRIFY.VMS (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   7 nfs/engcen6.centrify.vms@CENTRIFY.VMS (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   7 nfs/engcen6.centrify.vms@CENTRIFY.VMS (ArcFour with HMAC/md5)
[output truncated] 

For each ServicePrincipalName (SPN) you should see an AES256 entry for DFL 2008 and above.

 

Determining if the encryption type on the system's ticket cache

$ dzdo /usr/share/centrifydc/kerberos/bin/klist -fe /etc/krb5.ccache
Ticket cache: FILE:/etc/krb5.ccache
Default principal: engcen6$@CENTRIFY.VMS

Valid starting     Expires            Service principal
12/08/15 14:56:35  12/09/15 00:56:34  krbtgt/CENTRIFY.VMS@CENTRIFY.VMS
        renew until 12/09/15 14:56:35, Flags: FRIA
        Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC

Building an Inventory of Centrify agents and versions

Open Access Manager > Right Click "Centrify DirectManage Access Manager [dc]" > Select Deployment Report (Standard Edition)

DFL - Deployment Report.png

Stay in contact with your Centrify Team

The best practice is to meet at least twice a year with your Centrify leads (aligned with the feature/maintenance releases); they will educate you on new features, but this also gives you the opportunity to discuss your plans.  Here's an example:

Read-only Domain Controllers (AD 2008):  Although Centrify supported 2008FLs since version 4.2;  the adoption of RODCs started later, when customers communicated the plans to do this, the compatibility feature and deployment notes became available in version 5.1.

The future:  we are expecting customers to start looking into SMB3 and Kerberos armoring (AD 2012), however those are complex projects with huge impact for enterprises.  Given the large amounts of UNIX, Linux and OS X versions supported, it's a fairly complex endeavor for us as well.  The more of you communicate the plans via your tech leads or via the idea exchange, the more priority it gets.

 

 

What if I want to test this?

You'll need

a) A Windows Server 2003R2 acting as a DC at the low level.
To establish AD at the lower DFL level

b) A Windows Server 2008+ member server that you can promote to a DC
To test the introduction of a 2012 DC

c) A Centrify client in any mode (Express | Workstation | Zone) for UNIX, Linux or OS X.

 

Video

This video lab walks over the following scenario:

  1. Talks about the tools available for the assess phase and some basics about what happens in a Centrified system.
  2. Introduces a Windows 2012 DC in a 2003 Forest and Domain Functional level.
  3. Transfers all FSMO roles to the 2012 DC and decommissions the 2003 DC.
  4. Updates the Forest/Domain functional level from 2003 to 2012R2.

 

Reading List

Centrify KBs

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.