Enable Kerberos in an IWA BCAAA Deployment - pre-Windows 2000 format Considerations
Article ID: 374596
Updated On:
Products
Issue/Introduction
1. Should the Computer Account name in AD have domain name in the end? For example «.your_domain»?
The issue is that AD doesn't allow to create computer account names with "." (dots)
2. Can we use other different Computer Account name for pre-Windows 2000 format?
The issue is that AD makes pre-Windows 2000 format shorter. For example, we have 2 ProxySG with names "XX-YYY-ZZX-XX-01a" and "XX-YYY-ZZX-XX-01b". And AD makes its pre-Windows 2000 format as "XX-YYY-ZZX-XX-0" and "XX-YYY-ZZX-XX-0" which are equals
Environment
SG/ASG/ISG-Proxy
Resolution
For question 1, please see the documented response in the Tech. Doc. with the URL below.
Enable Kerberos in an IWA BCAAA Deployment
Note 1:
For the BCAAA service to participate in an IWA Kerberos authentication exchange, it must share a secret with the Kerberos server (called a KDC) and have registered an appropriate Service Principal Name (SPN).
Specifically, in step 6 of the shared doc., we have the below.
Register the Kerberos Service Principal Name (SPN) for the ProxySG appliance appliance:
- Log in to the Domain Controller using an account with administrative access and open a command prompt. So, this is NOT done in the AD application, but from the command prompt of the DC.
- Enter the following case-sensitive command:
setspn -A HTTP/<FQDN_of_ProxySG> <AD_Account_Name>
Where <FQDN_of_ProxySG> is the FQDN of the ProxySG appliance appliance as specified in the browser's explicit proxy configuration (explicit deployments) or in the Virtual URL setting in the IWA realm configuration (transparent deployments) and <AD_Account_Name> is the name of the BCAAA domain service account.
For example
setspn -A HTTP/bcaaaUser1.acme.com AcmeDomain\BCAAAuser
Note 2:
Do not assign the same SPN to multiple Active Directory accounts or the browser will fall back to NTLM without providing any warning or explanation. To list all SPNs that are currently registered on an account, use the setspn -L <AD Account Name> command. If you find a duplicate, use the setspn -D <SPN> command to remove the duplicate SPN.
For question 2, please find our response below.
In your scenario, when configuring Kerberos authentication in a Blue Coat Authentication and Authorization Agent (BCAAA) deployment for ProxySG, the issue arises due to the truncation of the computer names by Active Directory (AD) in the pre-Windows 2000 format (NetBIOS name). This truncation leads to identical names for both ProxySG appliances, which can cause conflicts and errors in Kerberos authentication.
Potential Solutions:
- Use Unique Computer Account Names:
- You can create unique computer account names for each ProxySG appliance in AD that will not be truncated to the same NetBIOS name. For example, instead of "XX-YYY-ZZX-XX-01a" and "XX-YYY-ZZX-XX-01b," you could use "XX-YYY-PRX01a" and "XX-YYY-PRX01b" as the computer names. This way, the pre-Windows 2000 names would be unique and would not conflict.
- You can create unique computer account names for each ProxySG appliance in AD that will not be truncated to the same NetBIOS name. For example, instead of "XX-YYY-ZZX-XX-01a" and "XX-YYY-ZZX-XX-01b," you could use "XX-YYY-PRX01a" and "XX-YYY-PRX01b" as the computer names. This way, the pre-Windows 2000 names would be unique and would not conflict.
- Manually Create SPNs:
- You can manually create Service Principal Names (SPNs) for each ProxySG appliance in AD using unique names. When you create the SPNs, ensure that they are associated with the correct fully qualified domain name (FQDN) of each ProxySG.
- You can manually create Service Principal Names (SPNs) for each ProxySG appliance in AD using unique names. When you create the SPNs, ensure that they are associated with the correct fully qualified domain name (FQDN) of each ProxySG.
- Use Different Organizational Units (OUs):
- Place each ProxySG appliance in different Organizational Units (OUs) within AD and ensure that the SPNs are configured with the appropriate OU path. This can sometimes help in avoiding conflicts due to name truncation.
- Place each ProxySG appliance in different Organizational Units (OUs) within AD and ensure that the SPNs are configured with the appropriate OU path. This can sometimes help in avoiding conflicts due to name truncation.
- Override Pre-Windows 2000 Name:
- If you have control over the AD environment, you may be able to override or extend the pre-Windows 2000 naming convention for these specific cases, though this might require advanced AD configuration or schema modifications, which should be done with caution.
Implementation Steps:
- Create Unique Computer Accounts in AD:
- For each ProxySG, create a unique computer account with a short enough name that it does not conflict with the other when truncated. Example:
- For "XX-YYY-ZZX-XX-01a" use "XX-ZZX01a"
- For "XX-YYY-ZZX-XX-01b" use "XX-ZZX01b"
- For each ProxySG, create a unique computer account with a short enough name that it does not conflict with the other when truncated. Example:
- Assign SPNs to the Computer Accounts:
- Use the 'setspn' command to assign the correct SPNs to these accounts. For example:
setspn -A HTTP/XX-ZZX01a.yourdomain.com XX-ZZX01a
setspn -A HTTP/XX-ZZX01b.yourdomain.com XX-ZZX01b
- Use the 'setspn' command to assign the correct SPNs to these accounts. For example:
- Configure BCAAA for Kerberos Authentication:
- In the BCAAA configuration for each ProxySG, ensure that you reference the correct computer account and SPN that you have set up in AD.
So, to avoid conflicts caused by the truncation of computer names to the same pre-Windows 2000 format, you should create unique and shorter computer account names in AD for each ProxySG appliance. This will ensure that each appliance has a distinct identity in AD, allowing Kerberos authentication to function correctly.
Feedback
