Table of Contents Introduction Prerequisites Requirements Supported platforms Components Used Logical Flow Diagram Configuration Configure LDAP Configure AAA Configure IP Admission Enable IP admission Exempting Inside Hosts from Authentication Enable the HTTP server on the ISR Configure CWS Redirection Complete Sample Configuration: LDAP AAA IP Admission HTTP Server Content-Scan / CWS Determine the Distinguished Name Objects in Active Directory - ADSI Edit Authentication Methods Active NTLM Transparent NTLM Basic Authentication (via HTTP in clear text) Passive NTLM Complete Message Sequence for Active NTLM Authentication: Troubleshooting Show commands Debug commands Common Problems IP Admission is not Intercepting HTTP requests Users see a “404 Not Found” error in their browsers when redirected for authentication User is Prompted for Authentication but Authentication Always Fails Troubleshooting LDAP The High-Level Steps of LDAP Authentication LDAP Debug Output Analysis RFC 4511 - Lightweight Directory Access Protocol (LDAP): The Protocol Known Caveats #anc40CSCum57928 - Scansafe needs a way to authenicate with HTTPS connection. #anc41CSCul22010 - High CPU Utilization when ip http secure server is enabled with NLTM #anc42CSCuc91949 - Scansafe IOS - Redirected HTTP site generating Tracebacks #anc43CSCum76723 - ENH: CWS-LDAP/NTLM auth should support multiple domains and forests Introduction 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. Prerequisites 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. Requirements ISR must be running code version 15.2(1)T1 or later. Available in IOS (universal) images with security feature set (SEC) license. Supported platforms ISR G2 platforms: 800, 1900, 2900, and 3900 series ISRs. G1 platforms are not supported: 1800, 2800, 3800 series routers. Components Used Client workstation on Active Directory domain or capable of performing active authentication via web-browser Internet Explorer, Google Chrome, Mozilla Firefox (requires additional configuration for transparent NTLM authentication) Cisco ISR G2 router Windows Active Directory Domain Controller (AD DC) Cisco Cloud Web Security subscription Logical Flow Diagram Configuration Configure LDAP 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 14.36.104.150
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: base-dn OU=TestCompany,DC=kklous,DC=cisco,DC=com 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. Configure AAA 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.) Configure IP Admission 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 1.1.1.1 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 Enable IP admission 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 Exempting Inside Hosts from Authentication 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 14.36.104.150 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 14.36.104.150 any
kklous-881(config-ext-nacl)#permit ip any any
kklous-881(config)#ip admission name SCANSAFE_ADMISSION ntlm list NO_ADMISSION Enable the HTTP server on the ISR 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) Configure CWS Redirection 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 Complete Sample Configuration: LDAP aaa group server ldap LDAP_GROUP
server DC01
ldap attribute-map ldap-username-map
map type sAMAccountName username
ldap server DC01
ipv4 14.36.104.150
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 aaa new-model
aaa authentication login SCANSAFE_AUTH group LDAP_GROUP
aaa authorization network SCANSAFE_AUTH group LDAP_GROUP IP Admission ip admission virtual-ip 1.1.1.1 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 HTTP Server ip http server Content-Scan / CWS 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 Determine the Distinguished Name Objects in Active Directory - ADSI Edit 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: Authentication Methods 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: Active NTLM 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. Transparent NTLM 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. Basic Authentication (via HTTP in clear text) 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 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. Complete Message Sequence for Active NTLM Authentication: Browser --> ISR : GET / google.com Browser <-- ISR : 302 Page moved http://1.1.1.1/login.html Browser --> ISR : GET /login.html 1.1.1.1 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 1.1.1.1 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. Troubleshooting Show commands show ip admission cache
show ip admission status
show ip admission statistics
show ldap server all Debug commands debug ldap all
debug ip admission detail (very verbose)
debug ip admission httpd
debug ip http transaction
debug aaa authentication
debug aaa authorization Common Problems IP Admission is not Intercepting HTTP requests 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
… Possible Solutions: 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 - 14.36.104.152, dstaddr - 23.73.127.139
ip-srcaddr 14.38.104.1
pak-srcaddr 14.36.104.152 Check to verify that the user’s IP address is not exempt from the ACL in the IP Admission Configuration Users see a “404 Not Found” error in their browsers when redirected for authentication Possible Solution: Ensure that the name in the “ip admission virtual-ip 1.1.1.1 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: User is Prompted for Authentication but Authentication Always Fails 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 14.36.104.152, Port 56674, timeout 60, Time Remaining 2, state INIT Common causes for this symptom include the following: Invalid username/password entered by the user for active authentication Invalid base-dn in LDAP configuration which results in searches returning no results Invalid bind authentication root-dn username or password which causing the LDAP bind to fail Communication between the ISR and LDAP server is failing (Verify that the LDAP server is listening on the specified TCP port for LDAP communication and that all firewalls between the two are allowing the traffic as well) Invalid search filter causes no results for LDAP search Troubleshooting LDAP 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 14.36.104.150 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 14.36.104.150 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. The High-Level Steps of LDAP Authentication Open connection to LDAP server on specified port (Default: TCP 389) Bind to LDAP server using the bind authenticate root-dn user and password Perform LDAP search for user attempting to authenticate using the base-dn and search-filters as defined in the LDAP configuration Obtain LDAP results from LDAP server and create an IP Admission cache entry for the user if successful or re-prompt for credentials in the event of an authentication failure. LDAP Debug Output Analysis 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 ( 14.36.104.150, 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 RFC 4511 - Lightweight Directory Access Protocol (LDAP): The Protocol Result code messages for LDAP and other LDAP protocol-related information can be found at the IETF website: http://tools.ietf.org/html/rfc4511#section-4.1.9 Known Caveats CSCum57928 - Scansafe needs a way to authenicate with HTTPS connection. CSCul22010 - High CPU Utilization when ip http secure server is enabled with NLTM CSCuc91949 - Scansafe IOS - Redirected HTTP site generating Tracebacks CSCum76723 - ENH: CWS-LDAP/NTLM auth should support multiple domains and forests
... View more
