We have all been there.
You are elbow deep in an Exchange deployment, and time is of the
essence. The environment is mid or small-size,
and you may be thinking to yourself… “Self, let’s just get this deployment done
and do it as easily and painlessly as possible”. With that line of thinking, enabling
Kerberos falls into the category of It
can be done after the fact. While
that may be true, let’s look at some of the pros and cons of enabling Kerberos,
or leaving things as is with NTLM. We
can begin with NTLM (NT Lan Manager).
Pros:
It’s Easy! By
default, it’s ready to go out of the box.
No fuss, and you’re up and running quickly.
It’s the default!
Enough said on that.
It can be used outside of the immediate domain. Kerberos is limited to clients and servers
within the domain it’s in, unless third party smartcard is utilized.
Cons:
It’s a heavier load on Active Directory. Authentication check for every connection to
every server client connects to.
It’s less secure then Kerberos. NTLM uses an 8 byte sequence that can be
sniffed internally.
It’s doesn’t pass authentication between servers. This means that your credentials and passwords
are going everywhere on the network, using only the default encryption
mentioned above.
In large scale deployments, NTLM can cause bottlenecks at
the CAS servers, causing intermittent authentication failures.
There is no getting around it, NTLM is definitely easier to
configure from startup perspective. If you’re
looking to roll out an environment with less headache, and the client is OK
with the default, then NTLM is a viable option.
Security of the Authentication
mechanism on the network usually doesn’t become a high priority, until
something happens. Now on to Kerberos:
Pros:
It’s more secure.
Token based security. (Three
points of contact – KDC, Server, Client)
Your password is not making rounds through the
environment.
Less load on Domain Controllers. When coupled with other Microsoft applications
(SP, Lync, etc..)
Ideal for large scale deployments where NTLM scalability
is an issue.
Cons:
It’s a more time consuming to configure. Involves use and knowledge of SPN records.
It can’t be utilized outside the domain without a
smartcard etc...
Client knowledge of Kerberos may be limited. A thorough understanding of SPN records and
their usage is required.
Kerberos, while normally not the go to authentication
method, could be making its presence felt as companies continue to add
Microsoft applications to their environments.
Think of the authentication traffic going to and from the domain
controllers in environments that utilize the full suite of Microsoft products
on a daily basis. All of that server
utilization has to be handled by the domain controllers to facilitate those
requests. Rather than build or add additional
DC’s as companies hopefully continue to grow and expand, wouldn’t it be easier
in the long run to bite the bullet now, and configure the application for the
long run? I encourage you to take a
second look at enabling this Authentication method. Below are some tips and tricks for getting Kerberos
enabled in a Microsoft Exchange environment.
Configure the Alternate Service
Account Credential
If you’re not familiar with this beauty, I encourage you get
familiar with her. This account (Either
computer or user, I prefer computer) will make the creation and utilization of
SPN records needed much easier and faster than without. The ASA account is the account that will be
utilized whenever an Authentication needs to be make for a CAS connection
within the domain. This account is
created and associated with all of your relevant SPN’s needed and utilized by
Exchange. Below are some quick instructions
for configuring it:
1.
Create a Computer account in the Active
Directory domain that will be used as the ASA credential. For example, EXCASASA.
(Note: Because it is a computer account, the actual account name will be Contoso.com\EXCASASA$.)
Next, run the following script to configure your SPN’s for
your ASA account. Substitute Contoso entries
with your environment names. Delete what’s
not needed based on your particular environment. Please note, this script is written for a Load
balancer scenario. Each line space is a separate
entry into PowerShell:
1. $acct="Contoso.com\excasasa`$"
$spnlist=@("http/owa.Contoso.com”,"http/autodiscover.Contoso.com","http/failback.Contoso.com”,"exchangeMDB/CASARRAY.Contoso.com","exchangeRFR/CASARRAY.Contoso.com","exchangeAB/CASARRAY.Contoso.com")
foreach ($spn in $spnlist) {setspn -F -S $spn $acct}
Lastly, we need to associate our new ASA account to the
existing CAS array servers.
2. From
the \program files\Microsoft\Exchange
Server\v14\scripts folder run :
.\RollAlternateServiceAccountPassword.ps1 -ToArrayMembers CASARRAY.Contoso.com -GenerateNewPasswordFor
Contoso\Excasasa$ -verbose
Please, please, please remember. Do not run the above script against different
CAS servers at different times. Make sure
the scope you set above grabs all of the servers at the same time. Running the above script against a single CAS
will break Kerberos authentication against all others. Remember, its all or nothing when running
this script, it can’t be done piecemeal. You can also utilize the –ToSpecificServers parameter to select multiple servers who
may not be in the CAS array. Anytime you add a new CAS server, you will
have to run the above PowerShell script in step 2. (.\RollAlternateServiceAccountPassword.ps1
) to reset the password and apply it to all servers in your environment.
The
script gives one prompt for changing the password on the account. Answer Y. When ok, script is exiting with “The script
has succeeded”
3.
To verify the script execute:
Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialstatus
|fl name,alternateserviceaccountconfiguration
Well, that’s it.
Kerberos for Exchange in a nutshell.
Hopefully this article adds to your knowledge of Kerberos and SPN’s and
their utilization.
Labels: AD, exchange 2010, Exchange 2013, Kerberos, powershell, Scripts