Many administrators who have installed ISR G2 routers that do not have ASAs in their networks choose to utilize the ISR’s Cloud Web Security (Also known as CWS and formerly ScanSafe) redirection functionality in order to take advantage of the CWS solution for web filtering. As part of that solution, most administrators also want to utilize their existing Active Directory infrastructure to send user identity information to the CWS towers for purposes of enforcing user or group-based policies in their web filtering policies in the CWS portal.
The overall concept is very much like the integration between the ASA and CDA with a few differences, the most notable being that the ISR does not actually maintain a user-to-IP mapping database and therefore users must pass through some type of authentication in order to transit the ISR and send user/group information to the CWS portal. Please refer to the “Authentication Methods” section for more information on differences between the various authentication methods available.
While the CWS redirection portion of the configuration is relatively straightforward, we have seen that many experience problems configuring the authentication piece of the solution which works using the ‘ip admission’ command that references LDAP servers and AAA authentication statements that also must be configured. The purpose of this guide is to provide network operators with a one-stop source to reference when configuring or troubleshooting the IP admissions and LDAP portions of this solution on ISR G2 routers.
While the IP admission and LDAP configuration could be used simply for authentication proxy on the ISR router, it is typically used in conjunction with the CWS redirection feature. As such, this guide is intended as a reference point to supplement other CWS redirection configuration/troubleshooting documentation on ISRs.
Configuring the Lightweight Directory Access Protocol (LDAP) properties of the AAA server(s):
1. Configure an LDAP attribute map to force the username entered by the user to match the
“sAMAccountName” property in Active Directory:
kklous-881(config)#ldap attribute-map ldap-username-map map type sAMAccountName username kklous-881(config-attr-map)#map type sAMAccountName username
Note: We configure it in this way since the sAMAccountName attribute is unique value in AD unlike the ‘cn’ or common name attribute which is otherwise used to match by default. For example, there can be multiple instances of “John Smith” in AD but there can only be one user with the sAMAccountName of “jsmith” which is also the user’s account logon. Other “John Smith” accounts would have sAMAccountNames of “jsmith1, jsmith2” etc.
You can use the ‘show ldap attributes’ command to view a list of LDAP attributes and their associated AAA attributes.
2. Configure the LDAP server group:
kklous-881(config)#aaa group server ldap LDAP_GROUP kklous-881(config-ldap-sg)#server DC01
3. Configure LDAP servers
kklous-881(config)#ldap server DC01 kklous-881(config-ldap-server)# ipv4 184.108.40.206 kklous-881(config-ldap-server)#attribute map ldap-username-map kklous-881(config-ldap-server)# bind authenticate root-dn CN=Csco_Service,CN=Users,DC=kklous,DC=cisco,DC=com password Cisco12345!
kklous-881(config-ldap-server)#base-dn DC=kklous,DC=cisco,DC=com kklous-881(config-ldap-server)#search-filter user-object-type top kklous-881(config-ldap-server)#authentication bind-first
This configuration generally should not be much different unless there is a need to implement a custom search-filter. Administrators that are well-versed in LDAP will typically perform this and thus should know how to properly input this information. If you do not know what to use as a search filter, simply use the above filter as it will locate users in a normal Active Directory environment.
The part of the LDAP configuration that is often troublesome is with the distinguished names (DNs) that are required in the ‘bind-authenticate-root-dn’ and ‘base-dn commands’ which must be entered exactly as they appear in the LDAP server or the LDAP queries will fail. In addition, the base-dn must be the lowest part of the LDAP tree where all the users being authenticated reside. In other words, if we modified the base-dn in the above configuration to the following:
Then our query for users that are in “CN=Users,DC=kklous,DC=cisco,DC=com” will return no results since we would only be searching the TestCompany organizational unit (OU) and the child objects within it. As a result, authentication would always fail for those users until they were either moved into the TestCompany OU, its subtree, or if the base-dn were changed to include that in the query. See the "Determine the Distinguished Name Objects in Active Directory" section for details on determining the proper DNs for their base and root commands.
Now that the LDAP servers are configured, we simply need to reference them in our AAA statements that will be used by the IP admission process:
kklous-881(config)#aaa authentication login SCANSAFE_AUTH group LDAP_GROUP kklous-881(config)#aaa authorization network SCANSAFE_AUTH group LDAP_GROUP
(Note: If the above commands are not available then you may need to enter the ‘aaa new-model’ command to enable this AAA functionality as it is not enabled by default.)
The IP admission piece triggers a process that prompts the user for authentication (or performs transparent authentication) and then performs LDAP queries based on the user credentials and AAA servers defined in the configuration. If the users are authenticated successfully, the user identity information is then pulled by the content-scan process and sent out to the CWS towers along with the redirected flow. The IP admission process is not activated until the ‘ip admission name’ command is entered on the ingress interface of the router. For that reason, this part can be implemented without any traffic impact.
kklous-881(config)#ip admission virtual-ip 220.127.116.11 virtual-host ISR_PROXY kklous-881(config)#ip admission name SCANSAFE_ADMISSION ntlm kklous-881(config)#ip admission name SCANSAFE_ADMISSION method-list authentication SCANSAFE_AUTH authorization SCANSAFE_AUTH
Note: This will force users to be authenticated which will cause traffic flow interruption if authentication fails.
kklous-881(config)#int vlan301 (internal LAN-facing interface) kklous-881(config-if)#ip admission SCANSAFE_ADMISSION
Some administrators may wish to exempt some inside hosts from being subjected to authentication for various reasons. For example, it may be undesirable for for internal servers or devices that are not capable of NTLM or basic authentication to be affected by the IP admissions process. In these instances, an ACL can be applied to the IP admission configuration to prevent specific host IPs or subnets from triggering IP admission.
In the example below, we exempt the inside host 18.104.22.168 from being required to authenticate while requiring authentication for all other hosts:
kklous-881(config)#ip access-list extended NO_ADMISSION kklous-881(config-ext-nacl)#deny ip host 22.214.171.124 any kklous-881(config-ext-nacl)#permit ip any any kklous-881(config)#ip admission name SCANSAFE_ADMISSION ntlm list NO_ADMISSION
This is required to intercept HTTP sessions and initiate the authentication process
Ip http server Ip http secure-server (only if redirection to HTTPS for authentication is required by customer)
Below is a basic summary configuration for CWS redirection.
parameter-map type content-scan global server scansafe primary name proxy139.scansafe.net port http 8080 https 8080 server scansafe secondary name proxy187.scansafe.net port http 8080 https 8080 license 0 DE749585HASDH83HGA94EA8C369 source interface Vlan302 user-group DEFAULT_GROUP username DEFAULT_USER server scansafe on-failure allow-all interface Vlan302 (egress interface towards internet) content-scan out
aaa group server ldap LDAP_GROUP server DC01 ldap attribute-map ldap-username-map map type sAMAccountName username ldap server DC01 ipv4 126.96.36.199 attribute map ldap-username-map bind authenticate root-dn CN=Csco_Service,CN=Users,DC=kklous,DC=cisco,DC=com password Cisco12345! base-dn dc=klous,dc=cisco,dc=com search-filter user-object-type top authentication bind-first
aaa new-model aaa authentication login SCANSAFE_AUTH group LDAP_GROUP aaa authorization network SCANSAFE_AUTH group LDAP_GROUP
ip admission virtual-ip 188.8.131.52 virtual-host ISR_PROXY ip admission name SCANSAFE_ADMISSION ntlm ip admission name SCANSAFE_ADMISSION method-list authentication SCANSAFE_AUTH authorization SCANSAFE_AUTH interface Vlan301 ip admission SCANSAFE_ADMISSION
ip http server
parameter-map type content-scan global server scansafe primary name proxy139.scansafe.net port http 8080 https 8080 server scansafe secondary name proxy187.scansafe.net port http 8080 https 8080 license 0 DE13621123456789607EA8C369 source interface Vlan302 user-group DEFAULT_GROUP username DEFAULT_USER server scansafe on-failure allow-all
interface Vlan302 content-scan out
If you need to browse your Active Directory structure in order to look up distinguished names to use for your User or Group search base, you can use a tool called ADSI Edit that is built into Active Directory Domain Controllers. In order to open ADSI Edit, choose Start > Run on your Active Directory Domain Controller and enter adsiedit.msc.
Once you are in ADSI Edit, right-click any object (such as an organizational unit (OU), group, or user) and choose Properties in order to view the distinguished name of that object. You can then easily copy and paste the string to your router configuration in order to avoid any typographical errors. See this screenshot for more specifics on this process:
There are four different types of authentication available using IP admission and these methods are often misunderstood, especially the difference between transparent and passive NTLM. Please see the following sections for specifics and differences between the different types of authentication:
Prompts users for authentication when transparent NTLM authentication fails. This is usually due to the fact that the client’s browser does not support integrated Windows authentication or because the user logged into the workstation with local (non-domain) credentials. Active NTLM authentication performs LDAP queries to the domain controller to ensure that the provided credentials are correct.
Note: With all types of NTLM authentication, credentials are not passed via clear text although NTLMv1 has well-documented vulnerabilities. The ISR is NTLMv2 capable although by default, older versions of Windows may negotiate via NTLMv1. This behavior is dependent upon Active Directory authentication policies.
NTLM authentication in which a user is logged into their workstation with domain credentials and those credentials are passed transparently by the browser to the IOS router which then performs an LDAP query to validate the user’s credentials. This is generally the most desired form of authentication for this feature.
This form of authentication is typically used as a fallback mechanism when NTLM authentication fails or is not possible for clients such as Macs, Linux-based devices, or mobile devices. In this scenario, if HTTP Secure server is not enabled then these credentials are passed via HTTP in clear text (very insecure).
Passive NTLM authentication requests credentials from users but does not actually authenticate the user against the domain controller. While this can avoid LDAP-related problems where the queries are failing against the DC, it also introduces a security risk. If transparent authentication fails or is not possible then the users are prompted for credentials, however the user can enter any credentials they choose and those will be passed on to the CWS tower. As a result, policies may not be applied appropriately. For example, User A could use Firefox (which by default does not allow transparent NTLM without additional configuration) and enter the username of User B with any password and the policies for user B would be applied to user A. The risk exposure can be mitigated if users are all forced to use browsers that support transparent NTLM authentication but in most cases the use of passive authentication is not recommended.
Browser --> ISR : GET / google.com
Browser <-- ISR : 302 Page moved http://184.108.40.206/login.html
Browser --> ISR : GET /login.html 220.127.116.11
Browser <-- ISR : 401 Unauthorized..Authenticate using NTLM
Browser --> ISR : GET /login.html + NTLM Type-1 msg
ISR --> AD : LDAP Bind Request + NTLM Type-1 msg
ISR copies the Type-1 msg from HTTP to the LDAP byte-by-byte without altering any data
ISR <-- AD : LDAP Bind Response + NTLM Type-2 msg
Browser <-- ISR : 401 Unauthorized + NTLM Type-2 msg
The Type-2 msg is also copied from byte-by-byte from LDAP to HTTP. So, in the pcap it appears to originate from 18.104.22.168 but the actual content is from AD.
Browser --> ISR : GET /login.html + NTLM Type-3 msg
ISR --> AD : LDAP Bind Request + NTLM Type-3 msg
ISR <-- AD : LDAP Bind response - Success
Browser <-- ISR : 200OK + redirect to google.com
When Active NTLM is configured the ISR does not interfere during NTLM exchange. However, if passive is configured then the ISR generates its own Type-2 msg.
show ip admission cache show ip admission status show ip admission statistics show ldap server all
debug ldap all debug ip admission detail (very verbose) debug ip admission httpd debug ip http transaction debug aaa authentication debug aaa authorization
This is evident by the output of ‘show ip admission statistics’ does not show any HTTP request being intercepted:
kklous-881#show ip admission statistics Webauth HTTPd statistics: HTTPd process 1 Intercepted HTTP requests: 0 …
Check to verify that ‘ip http server’ is enabled.
If the ISR's HTTP server is not enabled then IP admission will trigger but never actually intercept the HTTP session and therefore prompt for authentication. In this situation, there will be no output in the ‘show ip admission cache’ command but you will see many recurrences of the following in the output of ‘debug ip admission detail’
*Jan 30 20:49:35.726: ip_admission_det:proceed with process path authentication *Jan 30 20:49:35.726: AUTH-PROXY auth_proxy_find_conn_info : find srcaddr - 22.214.171.124, dstaddr - 126.96.36.199 ip-srcaddr 188.8.131.52 pak-srcaddr 184.108.40.206
Check to verify that the user’s IP address is not exempt from the ACL in the IP Admission Configuration
Ensure that the name in the “ip admission virtual-ip 220.127.116.11 virtual-host ISR_PROXY” can successfully resolve with the client’s DNS server. In this case, the client will perform a DNS query for “ISR_PROXY.kklous.cisco.com” since “kklous.cisco.com” is the fully-qualified domain name (FQDN) of the domain to which the workstation is joined. If the DNS query fails, the client will send out a Link-Local Multicast Name Resolution (LLMNR) query followed by a NETBIOS query that is broadcast to the local subnet.
If all of these resolution attempts fail then a “404 Not Found” or “Internet Explorer Cannot Display the webpage” error will be displayed in the browser. See the following Wireshark screenshot for what this situation looks like in a packet capture:
This can be caused by various reasons but is usually related to LDAP configuration on the ISR or communication between the ISR and the LDAP server. On the ISR, the symptom generally manifests itself by showing that users are stuck in the ‘INIT’ state once IP admission is triggered:
kklous-881(config)#do sh ip admi cac Authentication Proxy Cache Client Name N/A, Client IP 18.104.22.168, Port 56674, timeout 60, Time Remaining 2, state INIT
Common causes for this symptom include the following:
The best way to determine the underlying reason why authentication is failing is to utilize LDAP debug commands on the ISR. Keep in mind that debugs can be expensive and dangerous to run on an ISR if there is excessive output and can cause the router to hang and require a hard power cycle (this is especially true for the lower-end platforms).
For troubleshooting, I recommend applying an ACL to the IP Admission rule to only subject a single test workstation on any production network to authentication. That way you can enable debugs while minimizing any risk of negative impact to the router’s ability to pass traffic. To date, I have never seen a router crash nor have problems passing traffic while running all IP Admission/LDAP-related debugs with only one user triggering the debug output.
In the example below, we only subject the inside host with IP of 22.214.171.124 to authenticate while not requiring authentication for any other hosts:
kklous-881(config)#ip access-list extended TEST_ADMISSION kklous-881(config-ext-nacl)#permit ip host 126.96.36.199 any kklous-881(config-ext-nacl)#deny ip any any kklous-881(config)#ip admission name SCANSAFE_ADMISSION ntlm list TEST_ADMISSION
When troubleshooting LDAP-related problems. It is helpful to understand the steps in which LDAP processes requests from the ISR.
These processes can be seen in the output of “debug ldap all” Below is an example of LDAP debug output for an authentication that is failing due to an invalid base-dn. Review the debug output and associated bolded comments that highlight the output that shows where the above processes may be failing:
*Jan 30 20:51:50.818: LDAP: LDAP: Queuing AAA request 23 for processing *Jan 30 20:51:50.818: LDAP: Received queue event, new AAA request *Jan 30 20:51:50.818: LDAP: LDAP authentication request *Jan 30 20:51:50.818: LDAP: Username sanity check failed *Jan 30 20:51:50.818: LDAP: Invalid hash index 512, nothing to remove *Jan 30 20:51:50.818: LDAP: New LDAP request *Jan 30 20:51:50.818: LDAP: Attempting first next available LDAP server *Jan 30 20:51:50.818: LDAP: Got next LDAP server :DC01 *Jan 30 20:51:50.818: LDAP: Free connection not available. Open a new one. *Jan 30 20:51:50.818: LDAP: Opening ldap connection ( 188.8.131.52, 389 )ldap_open <-- This indicates that this is not a network layer issue since we have successfully opened the connection
*Jan 30 20:51:50.822: LDAP: Root Bind on CN=Csco_Service,CN=Users,DC=kklous,DC=cisco,DC=com initiated. … *Jan 30 20:51:51.330: LDAP: Ldap Result Msg: SUCCESS, Result code =0 *Jan 30 20:51:51.330: LDAP: Root DN bind Successful on :CN=Csco_Service,CN=Users,DC=kklous,DC=cisco,DC=com
The 'Bind authenticate-dn' looks good here. If the configuration was wrong for this then you'd see bind failures.
*Jan 30 20:51:51.846: LDAP: Received Bind Responseldap_parse_sasl_bind_result *Jan 30 20:51:51.846: LDAP: Ldap SASL Result Msg: SUCCESS, Result code =14 sasLres_code =14 *Jan 30 20:51:51.846: LDAP: SASL NTLM authentication do not require further tasks *Jan 30 20:51:51.846: LDAP: Next Task: All authentication task completed *Jan 30 20:51:51.846: LDAP: Transaction context removed from list [ldap reqid=14] *Jan 30 20:51:51.846: LDAP: * * AUTHENTICATION COMPLETED SUCCESSFULLY * * *Jan 30 20:51:51.846: LDAP: Notifying AAA: REQUEST CHALLENGED <-- This indicates that all bind operations were successful and we are now proceeding to search for the actual user
*Jan 30 20:51:51.854: LDAP: SASL NTLM authentication done..Execute search <-- LDAP Search debug output begins *Jan 30 20:51:51.854: LDAP: Next Task: Send search req *Jan 30 20:51:51.854: LDAP: Transaction context removed from list [ldap reqid=15] *Jan 30 20:51:51.854: LDAP: Dynamic map configured *Jan 30 20:51:51.854: LDAP: Dynamic map found for aaa type=username *Jan 30 20:51:51.854: LDAP: Ldap Search Req sent ld 2293572544 base dn dc=klous,dc=cisco,dc=com <--notice the base-dn should be “kklous” and not “klous” scope 2 filter (&(objectclass=top)(sAMAccountName=testuser5))ldap_req_encode put_filter "(&(objectclass=top)(sAMAccountName=testuser5))" put_filter: AND put_filter_list "(objectclass=top)(sAMAccountName=testuser5)" put_filter "(objectclass=top)" put_filter: simple put_filter "(sAMAccountName=testuser5)" put_filter: simple Doing socket write *Jan 30 20:51:51.854: LDAP: lctx conn index = 2
*Jan 30 20:51:52.374: LDAP: LDAP Messages to be processed: 1 *Jan 30 20:51:52.374: LDAP: LDAP Message type: 101 *Jan 30 20:51:52.374: LDAP: Got ldap transaction context from reqid 16ldap_parse_result *Jan 30 20:51:52.374: LDAP: resultCode: 10 (Referral) *Jan 30 20:51:52.374: LDAP: Received Search Response resultldap_parse_result ldap_err2string *Jan 30 20:51:52.374: LDAP: Ldap Result Msg: FAILED:Referral, Result code =10 <-- This incidates that the search returned no results (in this case due to an invalid base-dn)*Jan 30 20:51:52.374: LDAP: LDAP Search operation result : failedldap_msgfree *Jan 30 20:51:52.374: LDAP: Closing transaction and reporting error to AAA *Jan 30 20:51:52.374: LDAP: Transaction context removed from list [ldap reqid=16] *Jan 30 20:51:52.374: LDAP: Notifying AAA: REQUEST FAILED
Result code messages for LDAP and other LDAP protocol-related information can be found at the IETF website: