I'm wondering why it is not possible to create more than one NTLM realm on a wsa.
Can you explain exactly what is the blocking point ?
Thanks in advance
You can't create more than one NTLM realm because you can't join the WSA to more than one domain.
NT domain trusts should work, though I haven't tested them myself.
Why can't I join my wsa with more than one domain, this is exactly what I'm trying to understand. Is there a good reason for such limitation ?
Its no different than not being able to join a Windows box to more than one domain at a time... At the root, its a Microsoft limitation.
I did aquick google, and there's a bit here about which trusts work: https://supportforums.cisco.com/thread/2091864
Well... there is something I don't understand here. Is there really a Microsoft limitation on this point ?
I mean, with Bluecoat proxies for example, you can interact with as many domains as you want through their BCAAA agent. Same thing with McAfee Web Gateway, there is no limitation at all.
What is exactly so different with wsa ?
Well, at this point (pre 7.5), there isn't an agent, the WSA is joined to the domain, just like a Windows box, it authenticates via that trust relationship. From that point it is all based on how NT/Active Directory domains work. As long as there is a trust between the domains, you can can auth users from as many domains as you like.
There is an agent in the works. The ADAgent will be released with 7.5. The code is already available, it was released with the ASA ver 8.4, and it will be used to pass authentication info to the WSA. At this point, current versions still require trust relationships between all of the domains touched.
Taken from the setup guide: http://www.cisco.com/en/US/docs/security/ibf/setup_guide/ibf10_install.html#wp1054011
Before you configure even a single domain controller machine using the
adacfg dc create
command, ensure that the AD Agent machine is first joined to a domain (for example, domain
) that has a trust relationship with each and every domain (for example, domain
) that it will monitor for user authentications (through the domain controller machines that you will be configuring on the AD Agent machine).
Depending on your Active Directory domain structure, the following scenarios are possible:
1. Single Forest, Single Domain—There is only one domain, D[i] for all domain controller machines, which is one and the same as domain J. The AD Agent machine must first be joined to this single domain, and since no other domains are involved, there is no need to configure any trust relationship with any other domain.
2. Single Forest, Multiple Domains—All the domains in a single forest already have an inherent two-way trust relationship with each other. Thus, the AD Agent must first be joined to one of the domains, J, in this forest, with this domain J not necessarily being identical to any of the domains D[i] corresponding to the domain controller machines. Because of the inherent trust relationship between domain J and each of the domains D[i], there is no need to explicitly configure any trust relationships.
3. Multiple Forests, Multiple Domains—It is possible that domain J might belong to a forest that is different than the forest to which one or more of the domains D[i] corresponding to the domain controller machines belong. In this case, you must explicitly ensure that each of the domains D[i] has an effective trust relationship with domain J, in at least one of the following two ways:
a. A two-way external trust relationship can be established between the two domains, D[i] and J
b. A two-way forest trust relationship can be established between the the forest corresponding to domain D[i] and the forest corresponding to domain J
Hello Ken and thanks for your last feedback.
I'm aware of this AD Agent but I think it still does not match my requirements.
Tell me if I'm wrong, this is what is new with the AD Agent :
- you can identify users by an authenticated user name transparently when using Active Directory with an NTLM authentication realm.
- previously (pre 7.5), you could only identify users by their source IP address (IP Address Surrogate) when using AD with an NTLM authentication realm. Surrogate by persistent or session cookies may also be an option too but with limitations for HTTPS / FTP and other applications like messengers, updaters, ...
As you said, the current version of the AD Agent still requires a trust relationship between all of the domains touched.
Now let's take the following example :
- customer A is authenticating its users through an AD (realm A) using NTLM authentication with Single Sign On.
- recently customer A acquired a new branch office (customer B) using its own AD (realm B) and also using NTLM SSO
- both AD do not have any relationship at all between them but the customer still wants to authenticate ALL the users from realms A & B through the same WSA using NTLM SSO.
Please note that this example is something that can be seen quite often. I can list at least 4-5 customers who required me such configuration in the past year.
-> If I understand well, this configuration is not possible with a Cisco WSA. As you said, at the root, this is a Windows limitation on client side, preventing a Windows box to authenticate against more than one domain.
But this limitation is ONLY on the client side. Some others products (Bluecoat proxy through BCAAA agent : no limitation at all, McAfee Web Gateway : limited to 10 realms) are able to answer these requirements but I guess this is because they developped this feature internally on their proxy appliances. Is there a chance to see this feature also on Cisco WSA in the future ?
I’m fairly confident that your use case is on the roadmap… (its FAR too common for it not to be), but I’m not a Cisco employee, so I don’t have roadmap in front of me to confirm that.
As Ken mentioned, the feature to add multiple NTLM domains to the WSA is currently implemented in the upcoming release which is currently tracking for release in early 2013. I hope this helps.
As always thanks for chiming in ken!!!
Hello Ken, Satish
Great news so if it is in the roadmap. Thanks a lot for your feedback