Troubleshooting Prepositioning on WAAS 4.1.1 and above

Document

Jan 24, 2015 6:24 PM
Jan 18th, 2011

Introduction

Prepositioning is a powerful tools on the WAAS platform but it is not always easy to figure out why your jobs are failing when trying to retrieve the files.

Here is a method that should help you to figure out the reason why they are not successful.

Throughout the whole document, X.X.X.X will represent the IP address of
the WAE interface while Y.Y.Y.Y will be the interface of the server you
are trying to preposition from.

Job stuck "In Progress" at 0 bytes

Here is what you can do if you are getting the following screen when you monitor the status of your preposition job:

Prepo0.jpg

a) Verify that the WAE has TCP access on ports 445 or 139 to the CIFS server

To make sure of this, you can use the telnet command on the WAE itself:

CDN-WAVE-474-1#telnet Y.Y.Y.Y 445
Trying Y.Y.Y.Y...
Connected to Y.Y.Y.Y.
Escape character is '^]'.
fff
Connection closed by foreign host.
CDN-WAVE-474-1#

CDN-WAVE-474-1#telnet Y.Y.Y.Y 139
Trying Y.Y.Y.Y...
Connected to Y.Y.Y.Y.
Escape character is '^]'.
ddd
Connection closed by foreign host.
CDN-WAVE-474-1#

If you see the "Connected to" message for one of the two tries, it should be ok. If you don't, please verify the connectivity between the WAE and the CIFS server on those ports.


b) Verify that the traffic is going through the Core WAE

If you have access to the server on the CIFS port, you need to verify that the traffic is at least going through another WAE before reaching the hosting server.

If you have the following setup:

NotOk.jpg

Your jobs will get stuck to 0 bytes, To have preposition working, you need to have the following setup:

Ok.jpg

With the way the new CIFSAO is working (Transparent CIFS compared to the tunneling that was used in the Legacy WAFS component), support for the first scenario could be added so the following enhancement request has been opened:

CSCsv12937 WAAS 4.1.1 edge preposition directly to the server

There are a couple of means to verify that the traffic is indeed going through another WAE;

Wireshark captures

You can use the following command on your WAE:

tethereal -w prepo -f "host Y.Y.Y.Y" -i eth1 -s 1600

Then start the preposition job. Once it is started, you can stop the capture by pressing CTRL+C then retrieve the file which has been created on the hard drive of your WAE under the name prepo_00001_XXXXXXXXXXXXXX where all the X are replaced by the timestamp of which the trace has been taken.

Open this file with Wireshark on your PC and check the TCP part of the SYN/ACK received when the WAE is establishing the 3WHS to the CIFS server:

WireReturnNo21.jpg

If you don't see option 0x21 there, it means that the traffic is not going through another WAE. If you do see it like shown in the following capture, you can move to the next step:

WireReturn21.jpg

Connection state

You can verify that the traffic is going through another WAE by looking at the output of "show statistics connection":

CDN-WAVE-474-1#sh statistics connection

Current Active Optimized Flows:                      0
   Current Active Optimized TCP Plus Flows:          0
   Current Active Optimized TCP Only Flows:          0
   Current Active Optimized TCP Preposition Flows:   0
Current Active Auto-Discovery Flows:                 1
Current Reserved Flows:                              10
Current Active Pass-Through Flows:                   1
Historical Flows:                                    103


O-ST: Origin State, T-ST: Terminal State
E: Established, S: Syn, A: Ack, F: Fin, R: Reset
s: sent, r: received, O: Options, P: Passthrough

Local IP:Port       Remote IP:Port      Peer ID           O-ST T-ST ConnType   
Y.Y.Y.Y:139      10.48.68.74:1813    N/A               Sr   Sso  EXTERNAL CLIENT

Local IP:Port         Remote IP:Port        Peer ID           ConnType         
X.X.X.X:1421       Y.Y.Y.Y:445        N/A               PT In Progress   
Y.Y.Y.Y:445        X.X.X.X:1421       N/A               PT In Progress   

CDN-WAVE-474-1#

If you see the connection twice (A to B and B to A) as "PT In Progress", this means that the traffic is not going through another WAE.

Logs

There are two files that you can monitor to get more info on the status of your preposition jobs: /local1/errorlog/cifs/cifs_err.log and /local1/errorlog/cifsao-errorlog.current.

If you check the entries which are added to those through the type-tail command when launching the preposition job, you will see the following:

type-tail /local1/errorlog/cifsao-errorlog.current follow
01/16/2011 11:32:30.637(Local)(19336) TRCE (637592) Preposition ID  14605 started on Y.Y.Y.Y\Shared folder\. [AoShellLog.cpp:19]
01/16/2011 11:32:30.789(Local)(17967) ERRO (789865) Cannot get connection version, status=-1. Return error status. [AoShellWrapper.cpp:543]
01/16/2011 11:32:30.941(Local)(17967) ERRO (941307) Cannot get connection version, status=-1. Return error status. [AoShellWrapper.cpp:543]
01/16/2011 11:32:30.941(Local)(17967) NTCE (941955) Preposition ID  14605 failed, reason: network initialization error, retrying in 30 seconds. [AoShellLog.cpp:22]

01/16/2011 11:33:01.099(Local)(17967) ERRO (99306) Cannot get connection version, status=-1. Return error status. [AoShellWrapper.cpp:543]
01/16/2011 11:33:01.250(Local)(17967) ERRO (250692) Cannot get connection version, status=-1. Return error status. [AoShellWrapper.cpp:543]
01/16/2011 11:33:01.251(Local)(17967) NTCE (251188) Preposition ID  14605 failed, reason: network initialization error, retrying in 30 seconds. [AoShellLog.cpp:22]

type-tail /local1/errorlog/cifs/cifs_err.log follow
2011-01-16 11:32:30,637  INFO (actona.preposition.PrepositionController:385) prepositionPool-4 - Prep task 14605  Preposition ID  14605 started on Y.Y.Y.Y\Shared folder\.
2011-01-16 11:32:30,789  INFO (actona.aosh_io.AoShellWrapper:140) Thread-2 -  Connect failed to [ server: Y.Y.Y.Y, port: 445 ]
2011-01-16 11:32:30,790  INFO (actona.preposition.PrepositionController:963) Thread-2 -  Connection failed to /Y.Y.Y.Y:445, falling back to port 139
2011-01-16 11:32:30,941  INFO (actona.aosh_io.AoShellWrapper:140) Thread-2 -  Connect failed to [ server: Y.Y.Y.Y, port: 139 ]
2011-01-16 11:32:30,942  WARN (actona.preposition.PrepositionController:983) Thread-2 -  Preposition ID  14605 failed, reason: network initialization error, retrying in 30 seconds.

2011-01-16 11:33:01,099  INFO (actona.aosh_io.AoShellWrapper:140) Thread-2 -  Connect failed to [ server: Y.Y.Y.Y, port: 445 ]
2011-01-16 11:33:01,099  INFO (actona.preposition.PrepositionController:963) Thread-2 -  Connection failed to /Y.Y.Y.Y:445, falling back to port 139
2011-01-16 11:33:01,250  INFO (actona.aosh_io.AoShellWrapper:140) Thread-2 -  Connect failed to [ server: Y.Y.Y.Y, port: 139 ]
2011-01-16 11:33:01,251  WARN (actona.preposition.PrepositionController:983) Thread-2 -  Preposition ID  14605 failed, reason: network initialization error, retrying in 30 seconds.
2011-01-16 11:33:31,406  INFO (actona.aosh_io.AoShellWrapper:140) Thread-2 -  Connect failed to [ server: Y.Y.Y.Y, port: 445 ]
2011-01-16 11:33:31,407  INFO (actona.preposition.PrepositionController:963) Thread-2 -  Connection failed to /Y.Y.Y.Y:445, falling back to port 139
2011-01-16 11:33:31,558  INFO (actona.aosh_io.AoShellWrapper:140) Thread-2 -  Connect failed to [ server: Y.Y.Y.Y, port: 139 ]
2011-01-16 11:33:31,558  WARN (actona.preposition.PrepositionController:983) Thread-2 -  Preposition ID  14605 failed, reason: network initialization error, retrying in 30 seconds.
2011-01-16 11:34:01,717  INFO (actona.aosh_io.AoShellWrapper:140) Thread-2 -  Connect failed to [ server: Y.Y.Y.Y, port: 445 ]
2011-01-16 11:34:01,717  INFO (actona.preposition.PrepositionController:963) Thread-2 -  Connection failed to /Y.Y.Y.Y:445, falling back to port 139
2011-01-16 11:34:01,869  INFO (actona.aosh_io.AoShellWrapper:140) Thread-2 -  Connect failed to [ server: Y.Y.Y.Y, port: 139 ]
2011-01-16 11:34:01,869  WARN (actona.preposition.PrepositionController:983) Thread-2 -  Preposition ID  14605 failed, reason: network initialization error, retrying in 30 seconds.
2011-01-16 11:34:32,026  INFO (actona.aosh_io.AoShellWrapper:140) Thread-2 -  Connect failed to [ server: Y.Y.Y.Y, port: 445 ]

If you are 100% positive that you are going through another WAE but you still see those symptoms, it might be due to a device on the path between the two devices which is clearing the option 0x21. If it is a PIX/ASA firewall, you might want to make sure that you have "inspect waas" configured or if you have an IPS, you should disable the following signatures: 1306, 1330.12, 1330.17, 1330.18, 1330.19, 3030, 5581.0

Verify that the traffic is handled by the CIFSAO on the core side

If you can confirm that the return traffic is also going through the Core WAE, there is one last item that needs to be checked: this traffic needs to be handled by the CIFSAO for the preposition to be successful.

For instance if you have the following configuration on your Core:

policy-engine application
   set-dscp copy
   name WAFS
   classifier CIFS
      match dst port eq 445
      match dst port eq 139
   exit
   map basic
      name WAFS classifier CIFS action optimize full
exit

Preposition will not work since the CIFS traffic will not be sent to the accelerator.

If you check the status of the connection on the Edge side, you will see the following:

CDN-WAVE-474-1#sh statistics connection

Current Active Optimized Flows:                      1
   Current Active Optimized TCP Plus Flows:          1
   Current Active Optimized TCP Only Flows:          0
   Current Active Optimized TCP Preposition Flows:   0
Current Active Auto-Discovery Flows:                 0
Current Reserved Flows:                              10
Current Active Pass-Through Flows:                   0
Historical Flows:                                    103


D:DRE,L:LZ,T:TCP Optimization RR:Total Reduction Ratio
A:AOIM,C:CIFS,E:EPM,G:GENERIC,H:HTTP,M:MAPI,N:NFS,S:SSL,V:VIDEO

ConnID        Source IP:Port          Dest IP:Port            PeerID Accel RR  
  1403      172.16.5.3:15779        Y.Y.Y.Y:445 00:22:64:96:eb:5c TDL   00.0%
CDN-WAVE-474-1#

As you can see the connection is seen as optimized but we won't see any traffic going through it.

To solve this problem, you just need to change the classifier config of the Core side so that the CIFS traffic is handled by the accelerator:

policy-engine application
   set-dscp copy
   name WAFS
   classifier CIFS
      match dst port eq 445
      match dst port eq 139
   exit
   map basic
      name WAFS classifier CIFS action optimize full  accelerate cifs
exit

Once this is done, your preposition job should start to retrieve files. If the Edge is also configured to handle the traffic via the accelerator (Not mandatory), the acceleration of the connection in the show statistics connection output will be changed from TDL to TCDL.

Job "Completed" but with errors

If you see the following status once you've launched your preposition job:

PrepoError.jpg

It is advised to check the /local1/errorlog/cifs/cifs_err.log and /local1/errorlog/cifsao-errorlog.current.files as they would contain the reason of those errors. For instance, in this case, I have entered a share name that did not exist on the CIFS server:

type-tail /local1/errorlog/cifsao-errorlog.current follow
01/16/2011 12:08:44.254(Local)(18961) TRCE (254057) Preposition ID  14605 started on Y.Y.Y.Y\Does Not Exist\. [AoShellLog.cpp:19]
01/16/2011 12:08:45.068(Local)(19336) TRCE (68614) Prpositioned files under \\Y.Y.Y.Y\Does Not Exist\ (task 14605): Source root directory does not exist(0 shares with errors) - scanned 0 files, updated 0 files, 0 bytes 0 directories. [AoShellLog.cpp:19]
01/16/2011 12:08:45.069(Local)(18484) TRCE (69736) Preposition ID  14605 finished,  0 files prepositioned successfully,  0 files with errors [AoShellLog.cpp:19]

type-tail /local1/errorlog/cifs/cifs_err.log follow
2011-01-16 12:08:44,889  INFO (actona.preposition.ProtocolAdapter:217) prepositionPool-5 - Prep task 14605  starting scan task 14605
2011-01-16 12:08:45,067  WARN (actona.preposition.PrepositionController:1095) prepositionPool-4 - Prep task 14605  Prep controller got an API error: File Not Found
2011-01-16 12:08:45,068  INFO (actona.preposition.TaskStatus:251) prepositionPool-4 - Prep task 14605  Prpositioned files under \\Y.Y.Y.Y\Does Not Exist\ (task 14605): Source root directory does not exist(0 shares with errors) - scanned 0 files, updated 0 files, 0 bytes 0 directories.
2011-01-16 12:08:45,068  INFO (actona.preposition.ProtocolAdapter:179) prepositionPool-4 - Prep task 14605  Closing preposition channel, task 14605

Corrective actions can be taken by either changing the parameters of the preposition or on the CIFS server itself.

Bu g

If you verified all of the above and still have problems with prepositioning, you might be hitting a software bug. Here is a list of all the bugs related to preposition which have been fixed since the 4.1.1 release. You might want to go through the list and see if one of those might apply to your setup:

Bug ID
TitleFixed In
Bug Tool
CSCsu25035Sitemap not working for PP & Dynamic shares when secure store open on CM4.1(1B)Here
CSCsu90033Sitemap won't work when enabled secure store on Core4.1(1C)Here
CSCsr95819CIFS AO: Not all the expected files are cached by preposition task4.1(3)Here
CSCsw37661Unable to browse directory with CIFS prepositioned content4.1(3)Here
CSCsw39896CIFS Preposition directive gets renamed when configured from CLI4.1(3)Here
CSCsw80798CIFS preposition tasks fail with NTLMv2 authentication4.1(3)Here
CSCsx54846Preposition task may not complete under specific stress scenario4.1(3A)Here
CSCsz01264Preposition tasks fail while multiple WAEs scan same high-volume root4.1(3A)Here
CSCsz78799Concurrent preposition tasks may not fetch all the data for large files4.1(3A)Here
CSCsw36112File preposition may not complete when very large files are transferred4.1(3A)Here
CSCsz53126Preposition with large number of files in a root share may not complete4.1(3B)Here
CSCsz84284Preposition task may not complete for root shares with many files4.1(5)Here
CSCsx96126Exception if no share or "/" used as root for CIFS preposition (CLI/CM)4.1(5C)Here
CSCtb89492WAAS: Preposition task may fail due to resources being unavailable4.1(5C)Here
CSCtb84428Concurrent preposition tasks through a DC WAE fail when size exceed 10GB4.1(7)Here
CSCta55041Preposition task may terminate early when preposition size > cache size4.1(7) 4.2(1)Here
CSCsz75060CIFS preposition startup-config may not be applied to running-config4.1(7A) 4.2(3B)Here
CSCsz79863Preposition task may fail to fetch all files after network disruption4.2(1)Here
CSCtb43432Under certain conditions prepositions tasks may be deleted and added4.2(1)Here
CSCsx66071Preposition task may start at incorrect time in specific conditions4.2(1)Here
CSCsz79863Preposition task may fail to fetch all files after network disruption4.2(1)Here
CSCsz77214CIFS preposition tasks does keep retrying if server FQDN is unreachable4.2(3B)Here
CSCte86102Rarely, preposition root share may get deleted without user intervention4.2(3B)Here
CSCti98840Preposition task may not restart in certain rare scenarios4.2(3B)Here
CSCti33775preposition not applied to devices if schedule set before assign devices4.3(1)Here

Related Information:

Common WAAS/WCCP issues on interactions with Security Devices

GRE Redirection in WCCP Creates new tunnel interfaces

Felix Arrieta Tue, 11/01/2011 - 10:19

great document I'd suggest this reading to anybody having trouble with preposition, thanks for sharing.

dbooth@oxspring.com Wed, 09/12/2012 - 05:00

I found this document very helpful but have an odd preposition scenario.  I get the 'Job completed but with errors' state and see the 'Source root directory does not exist(0 shares with errors)' error if the cifs_err.log, but host clients at the same site as the Edge WAE can access these shares without issue.  The File Server Settings have been checked and double-checked and different shares on the server have been tried but the same error is always produced.  The other symptom is that in the Preposition Definition tab, if the Browse button is clicked to select Root Share and Directories, the error 'Could not access cifs://x.x.x.x/' is shown in the browsing window.  Other prepositions on the same Edge WAE to another Core location work fine.  Any thoughts would be much appreciated.

Felix Arrieta Thu, 09/13/2012 - 07:30

WAASversion 5 now supports SMBv2 with digital signing,but  try to disable digital signing and test it to make sure that's actually your problem, there could be other isssues as well... I definitely suggest to open a TAC case.

good luck

dbooth@oxspring.com Thu, 09/13/2012 - 07:40

That's interesting about WAAS v5 Felix, thanks for that.  Would you just need the Core WAE (the one near the server doing the SMBv2 with DS) to be v5 or would the one at the client location need to be too?

expertadvisor20151 Sat, 01/24/2015 - 18:24

Search

 
Cisco

Cisco Support Community

Remote Access VPN on ASA - Authentication using LDAP Server

Document

May 3, 2013 12:54 PM
2 years ago

 

 

 

Introduction

This document provides an example on how to Configure Remote Access VPN on ASA and do the Authentication using LDAP server

Prerequisites

ASA and LDAP server both should be reachable.
 

Components Used

1. ASA 8.2

2. LDAP (Microsoft)

Configuration Remote Access VPN on ASA

interface configuration:

hostname(config)# interface ethernet0
hostname(config-if)# ip address 10.10.4.200 255.255.0.0
hostname(config-if)# nameif outside
hostname(config)# no shutdown

Configuring ISAKMP Policy and Enabling ISAKMP on the Outside Interface

hostname(config)# isakmp policy 1 authentication pre-share
hostname(config)# isakmp policy 1 encryption 3des
hostname(config)# isakmp policy 1 hash sha 
hostname(config)# isakmp policy 1 group 2
hostname(config)# isakmp policy 1 lifetime 43200
hostname(config)# isakmp enable outside

Configuring an Address Pool

hostname(config)# ip local pool testpool 192.168.0.10-192.168.0.15

Adding a User

hostname(config)# username testuser password 12345678

Creating a Transform Set

hostname(config)# crypto ipsec transform-set FirstSet esp-3des esp-md5-hmac

Creating a Tunnel group

hostname(config)# tunnel-group testgroup type ipsec-ra
hostname(config)# tunnel-group testgroup general-attributes
hostname(config-general)# address-pool testpool
hostname(config)# tunnel-group testgroup ipsec-attributes
hostname(config-ipsec)# pre-shared-key 44kkaol59636jnfx

Creating a Dynamic crypto map

hostname(config)# crypto dynamic-map dyn1 1 set transform-set FirstSet
hostname(config)# crypto dynamic-map dyn1 1 set reverse-route

Creating a Crypto Map Entry to Use the Dynamic Crypto Map

hostname(config)# crypto map mymap 1 ipsec-isakmp dynamic dyn1
hostname(config)# crypto map mymap interface outside

Configuring LDAP server on the ASA

ciscoasa(config-aaa-server-group)#aaa-server LDAP (inside) host 192.168.1.2
ciscoasa(config-aaa-server-host)#ldap-base-dn dc=ftwsecurity, dc=cisco, dc=com
ciscoasa(config-aaa-server-host)#ldap-login-dn cn=admin, cn=users, dc=ftwsecurity, dc=cisco, dc=com
ciscoasa(config-aaa-server-host)#ldap-login-password **********
ciscoasa(config-aaa-server-host)#ldap-naming-attribute sAMAccountName
ciscoasa(config-aaa-server-host)#ldap-scope subtree
ciscoasa(config-aaa-server-host)#server-type microsoft
ciscoasa(config-aaa-server-host)#exit

Assigning LDAP server under tunnel group

ciscoasa(config)#tunnel-group testgroup general-attributes
ciscoasa(config-tunnel-general)#authentication-server-group LDAP

Verifcation

Test with CLI:

You can use the test command on the command line in order to test your AAA setup. A test  request is sent to the AAA server, and the result appears on the command line.

ciscoasa#test aaa-server authentication LDAP host 192.168.1.2
   username cisco password cisco123INFO: Attempting Authentication test to IP address <192.168.1.2>
   (timeout: 12 seconds)
INFO: Authentication Successful

Troubleshoot

If unsure of the current DN string to use, you can issue the dsquery command on a Windows Active Driectory server from a command prompt in  order to verify the appropriate DN String of a user object.

C:\Documents and Settings\Administrator>dsquery user -samid cisco!--- Queries Active Directory for samid id "cisco""CN=cisco,CN=Users,DC=ftwsecurity,DC=cisco,DC=com"

The debug ldap 255 command can help to troubleshoot authentication problems in this  scenario. This command enables LDAP debugging and allows you to watch  the process that the ASA uses to connect to the LDAP server.

Debug - Successful authentication

ciscoasa#debug ldap 255[7] Session Start
[7] New request Session, context 0xd4b11730, reqType = 1
[7] Fiber started
[7] Creating LDAP context with uri=ldap://192.168.1.2:389
[7] Connect to LDAP server: ldap://192.168.1.2:389, status = Successful
[7] defaultNamingContext: value = DC=ftwsecurity,DC=cisco,DC=com
[7] supportedLDAPVersion: value = 3
[7] supportedLDAPVersion: value = 2
[7] supportedSASLMechanisms: value = GSSAPI
[7] supportedSASLMechanisms: value = GSS-SPNEGO
[7] supportedSASLMechanisms: value = EXTERNAL
[7] supportedSASLMechanisms: value = DIGEST-MD5

!--- The ASA connects to the LDAP server for admin bind and search for cisco.
[7] Binding as administrator
[7] Performing Simple authentication for admin to 192.168.1.2
[7] LDAP Search:
        Base DN = [dc=ftwsecurity, dc=cisco, dc=com]
        Filter  = [sAMAccountName=cisco]
        Scope   = [SUBTREE]
[7] User DN = [CN=cisco,CN=Users,DC=ftwsecurity,DC=cisco,DC=com][7] Talking to Active Directory server 192.168.1.2
[7] Reading password policy for cisco, dn:CN=cisco,CN=Users,
       DC=ftwsecurity,DC=cisco,DC=com

!--- The ASA binds to the LDAP server as cisco to test the password.
[7] Binding as user
[7] Performing Simple authentication for kate to 192.168.1.2
[7] Checking password policy for user cisco
[7] Binding as administrator
[7] Performing Simple authentication for admin to 192.168.1.2
[7] Authentication successful for kate to 192.168.1.2
[7] Retrieving user attributes from server 192.168.1.2[7] Retrieved Attributes:
[7]     objectClass: value = top
[7]     objectClass: value = person
[7]     objectClass: value = organizationalPerson
[7]     objectClass: value = user
[7]     cn: value = cisco
[7]     givenName: value = cisco
[7]     distinguishedName: value = CN=cisco,CN=Users,DC=ftwsecurity,
           DC=cisco,DC=com
[7]     instanceType: value = 4
[7]     whenCreated: value = 20070815155224.0Z
[7]     whenChanged: value = 20070815195813.0Z
[7]     displayName: value = cisco
[7]     uSNCreated: value = 16430
[7]     memberOf: value = CN=Castaways,CN=Users,DC=ftwsecurity,DC=cisco,DC=com
[7]     memberOf: value = CN=Employees,CN=Users,DC=ftwsecurity,DC=cisco,DC=com
[7]     uSNChanged: value = 20500
[7]     name: value = cisco
[7]     objectGUID: value = ..z...yC.q0.....
[7]     userAccountControl: value = 66048
[7]     badPwdCount: value = 1
[7]     codePage: value = 0
[7]     countryCode: value = 0
[7]     badPasswordTime: value = 128321799570937500
[7]     lastLogoff: value = 0
[7]     lastLogon: value = 128321798130468750
[7]     pwdLastSet: value = 128316667442656250
[7]     primaryGroupID: value = 513
[7]     objectSid: value = ............Q..p..*.p?E.Z...
[7]     accountExpires: value = 9223372036854775807
[7]     logonCount: value = 0
[7]     sAMAccountName: value = cisco
[7]     sAMAccountType: value = 805306368
[7]     userPrincipalName: value = cisco@ftwsecurity.cisco.com
[7]     objectCategory: value = CN=Person,CN=Schema,CN=Configuration,
           DC=ftwsecurity,DC=cisco,DC=com
[7]     dSCorePropagationData&colon; value = 20070815195237.0Z
[7]     dSCorePropagationData&colon; value = 20070815195237.0Z
[7]     dSCorePropagationData&colon; value = 20070815195237.0Z
[7]     dSCorePropagationData&colon; value = 16010108151056.0Z
[7] Fiber exit Tx=685 bytes Rx=2690 bytes, status=1
[7] Session End

Debug - Authentication fails - Incorrect Password

ciscoasa#debug ldap 255[8] Session Start
[8] New request Session, context 0xd4b11730, reqType = 1
[8] Fiber started
[8] Creating LDAP context with uri=ldap://192.168.1.2:389
[8] Connect to LDAP server: ldap://192.168.1.2:389, status = Successful
[8] defaultNamingContext: value = DC=ftwsecurity,DC=cisco,DC=com
[8] supportedLDAPVersion: value = 3
[8] supportedLDAPVersion: value = 2
[8] supportedSASLMechanisms: value = GSSAPI
[8] supportedSASLMechanisms: value = GSS-SPNEGO
[8] supportedSASLMechanisms: value = EXTERNAL
[8] supportedSASLMechanisms: value = DIGEST-MD5

!--- The ASA connects to the LDAP server as admin to search for cisco.
[8] Binding as administrator
[8] Performing Simple authentication for admin to 192.168.1.2
[8] LDAP Search:
        Base DN = [dc=ftwsecurity, dc=cisco, dc=com]
        Filter  = [sAMAccountName=kate]
        Scope   = [SUBTREE]
[8] User DN = [CN=cisco,CN=Users,DC=ftwsecurity,DC=cisco,DC=com][8] Talking to Active Directory server 192.168.1.2
[8] Reading password policy for cisco, dn:CN=cisco,CN=Users,
       DC=ftwsecurity,DC=cisco,DC=com
[8] Read bad password count 1

!--- The ASA attempts to bind as cisco, but the password is incorrect.
[8] Binding as user
[8] Performing Simple authentication for kate to 192.168.1.2
[8] Simple authentication for cisco returned code (49) Invalid credentials[8] Binding as administrator
[8] Performing Simple authentication for admin to 192.168.1.2
[8] Reading bad password count for cisco, dn: CN=cisco,CN=Users,
       DC=ftwsecurity,DC=cisco,DC=com
[8] Received badPwdCount=1 for user cisco
[8] badPwdCount=1 before, badPwdCount=1 after for cisco
[8] now: Tue, 28 Aug 2007 15:33:05 GMT, lastset: Wed, 15 Aug 2007 15:52:24 GMT,
       delta=1122041, maxage=3710851 secs
[8] Invalid password for cisco
[8] Fiber exit Tx=788 bytes Rx=2904 bytes, status=-1
[8] Session End

Debug - Authentication Fail - User not found on LDAP server

ciscoasa#debug ldap 255[9] Session Start
[9] New request Session, context 0xd4b11730, reqType = 1
[9] Fiber started
[9] Creating LDAP context with uri=ldap://192.168.1.2:389
[9] Connect to LDAP server: ldap://192.168.1.2:389, status = Successful
[9] defaultNamingContext: value = DC=ftwsecurity,DC=cisco,DC=com
[9] supportedLDAPVersion: value = 3
[9] supportedLDAPVersion: value = 2
[9] supportedSASLMechanisms: value = GSSAPI
[9] supportedSASLMechanisms: value = GSS-SPNEGO
[9] supportedSASLMechanisms: value = EXTERNAL
[9] supportedSASLMechanisms: value = DIGEST-MD5

!--- The user Minakshi is not found.
[9] Binding as administrator
[9] Performing Simple authentication for admin to 192.168.1.2
[9] LDAP Search:
        Base DN = [dc=ftwsecurity, dc=cisco, dc=com]
        Filter  = [sAMAccountName=minakshi]
        Scope   = [SUBTREE]
[9] Requested attributes not found[9] Fiber exit Tx=256 bytes Rx=607 bytes, status=-1
[9] Session End

Please post comments if there are any queries and rate if useful.

 

Scenario 2:

Problem:

Is it possible to strip the suffix from a username to authenticate against an active directory in ACS 5.4? I can find this when using an external proxy service, but not for network access.

Solution:

Username suffix/prefix stripping is possible when using:
LDAP
Radius Identity server
External Proxy
With AD, the option is unavailable.
Self proxy + AD is a workaround but that has some limitations and is a complex configuration.

 

Source Discussion:

CSC Discussion:

Average Rating: 5 (4 ratings)

 
 
expertadvisor20151 about 4 hours ago
 

To scale the performance of WAAS / WAE and to provide high reliability, Cisco has a new feature called ITD. Please see ITD (Intelligent Traffic Director) White Paper.

Also, recent blog : Intelligent Traffic Director @ Cisco Live Milan

 

ITD Provides CAPEX and OPEX Savings for Customers

ITD (Intelligent Traffic Director) is a hardware based multi-Tbps Layer 4 load-balancing, traffic steering and clustering solution on Nexus 5K/6K/7K series of switches. It supports IP-stickiness, resiliency, NAT, (EFT), VIP, health monitoring, sophisticated failure handling policies, N+M redundancy, IPv4, IPv6, VRF, weighted load-balancing, bi-directional flow-coherency, and IPSLA probes including DNS.

ITD is much superior than legacy solutions like PBR, WCCP, ECMP, port-channel, layer-4 load-balancer appliances.

 

Actions

This Document

Related Content