Cloud Web Security (formerly Scansafe) ldap resultCode: 49 Invalid Credentials. Default usergroup ap...

Joe Lourenco · ‎08-28-2013

I have a serious problem with LDAP, for the purpose of Scansafe, on a 3945 ISR with IOS 15 (C3900-UNIVERSALK9-M). LDAP binding to the LDAP Server (Active Directory on Win Srv 2008 R2) when authenticating any domain user, except for the default Scansafe Bind Root-DN user, is failing.

The testing of any user's sAMAccount name, is failing, and it defaults to the default Scansafe usergroup.

# test aaa group <ldap group name> <userid> <pwd> new-code

User Rejected

# sh ldap server all (the output is correct when checking to see if any LDAP server exists)

My config is exactly as Scansafe's configuration guide:

http://www.cisco.com/en/US/docs/security/web_security/ISR_SS/ISR_ScanSafe_SolutionGuide.pdf

I am using NTLM ACTIVE AUTHENTICATION and I have the LDAP attribute map for mapping the sAMAccount name to the user's username.

In that PDF, on the bottom of page 12, there is this paragraph that describes exactly what is happening to my Scansafe.

"Configuring a Default User Group

You can configure a default user group to assign to each client when the ISR cannot determine the

credentials for a user. Define a default user group using the following CLI command:

[no] user-group default <name>

The ISR uses the default user group name here to identify all clients connected to a specific interface on the ISR when it cannot determine the user’s credentials. You might want to define a default user group so that all traffic redirected to the ScanSafe proxy servers are assigned a user group so particular ScanSafe policies can be applied appropriately. For example, you might want to create a default user group for guest users on the wireless network.Only one user group can be defined per interface."

Now, what does this problem affect? I cannot enforce the application of filters from the Scansafe site to specific user groups. Users can use the internet under the default usergroup. Everyone defaults to the default filter. I have a filter established for say Purchasing, allowing them extra leeway on what they can access, but the members of that group cannot authenticate, and thus their filter is not applied.

Application of filters is essential to Scansafe, without, it defeats the purpose

I appreciate all the help I can get on this.

Here is what my logs show regarding LDAP BINDING OPERATION, from # debug ldap all:

-- Testing with jltestuser (this is just any random user, as all users are failing anyway)

barra-gate#

051646: Aug 23 23:10:34.983 BRST: LDAP: LDAP: Queuing AAA request 0 for processing

051647: Aug 23 23:10:34.983 BRST: LDAP: Received queue event, new AAA request

051648: Aug 23 23:10:34.983 BRST: LDAP: LDAP authentication request

051649: Aug 23 23:10:34.983 BRST: LDAP: Invalid hash index 512, nothing to remove

051650: Aug 23 23:10:34.983 BRST: LDAP: New LDAP request

051651: Aug 23 23:10:34.983 BRST: LDAP: Attempting first next available LDAP server

051652: Aug 23 23:10:34.983 BRST: LDAP: Got next LDAP server :<Removed server name...>

051653: Aug 23 23:10:34.983 BRST: LDAP: First Task: Send bind req

051654: Aug 23 23:10:34.983 BRST: LDAP: Authentication policy: bind-first

051655: Aug 23 23:10:34.983 BRST: LDAP: Bind: User-DN=cn=jltestuser,CN=Users,DC=<removed>,DC=<removed>,DC=com ldap_req_encode

Doing socket write

051656: Aug 23 23:10:34.983 BRST: LDAP: LDAP bind request sent successfully (reqid=92)

051657: Aug 23 23:10:34.983 BRST: LDAP: Sent transit request to server

051658: Aug 23 23:10:34.983 BRST: LDAP: LDAP request successfully processed

051659: Aug 23 23:10:35.539 BRST: LDAP: Received socket event

051660: Aug 23 23:10:35.539 BRST: LDAP: Process socket event for socket = 0

051661: Aug 23 23:10:35.539 BRST: LDAP: Conn Status = 4

051662: Aug 23 23:10:35.539 BRST: LDAP: Non-TLS read event on socket 0

051663: Aug 23 23:10:35.539 BRST: LDAP: Found socket ctx

051664: Aug 23 23:10:35.539 BRST: LDAP: Receive event: read=1, errno=11 (Resource temporarily unavailable)

051665: Aug 23 23:10:35.539 BRST: LDAP: Passing the client ctx=1855243Cldap_result

wait4msg (timeout 0 sec, 1 usec)

ldap_select_fd_wait (select)

ldap_read_activity lc 0x1AADABD8

Doing socket read

LDAP-TCP:Bytes read = 110

ldap_match_request succeeded for msgid 7 h 0

changing lr 0x11A14BFC to COMPLETE as no continuations

removing request 0x11A14BFC from list as lm 0x1AAB8494 all 0

ldap_msgfree

051666: Aug 23 23:10:35.539 BRST: LDAP: LDAP Messages to be processed: 1

051667: Aug 23 23:10:35.539 BRST: LDAP: LDAP Message type: 97

051668: Aug 23 23:10:35.539 BRST: LDAP: Got ldap transaction context from reqid 92ldap_parse_result

051669: Aug 23 23:10:35.539 BRST: LDAP: resultCode: 49 (Invalid credentials)

051670: Aug 23 23:10:35.539 BRST: LDAP: Received Bind Responseldap_parse_result

ldap_err2string

051671: Aug 23 23:10:35.539 BRST: LDAP: Ldap Result Msg: FAILED:Invalid credentials, Result code =49

051672: Aug 23 23:10:35.539 BRST: LDAP: LDAP Bind operation result : failed <<<<<<<<<<-----------------------LOOK!!!!!

051673: Aug 23 23:10:35.539 BRST: LDAP: Connection <REMOVED...>0 already exist for reuseldap_msgfree

051674: Aug 23 23:10:35.539 BRST: LDAP: Closing transaction and reporting error to AAA

051675: Aug 23 23:10:35.539 BRST: LDAP: Transaction context removed from list [ldap reqid=92]

051676: Aug 23 23:10:35.539 BRST: LDAP: Notifying AAA: REQUEST FAILED

051677: Aug 23 23:10:35.539 BRST: LDAP: Received socket event

--- Testing with the scansafe assigned user that binds to the Bind DN. This is the only user that succeeds authentication!!!!

barra-gate#

051684: Aug 23 23:13:57.664 BRST: LDAP: LDAP: Queuing AAA request 0 for processing

051685: Aug 23 23:13:57.664 BRST: LDAP: Received queue event, new AAA request

051686: Aug 23 23:13:57.664 BRST: LDAP: LDAP authentication request

051687: Aug 23 23:13:57.664 BRST: LDAP: Invalid hash index 512, nothing to remove

051688: Aug 23 23:13:57.664 BRST: LDAP: New LDAP request

051689: Aug 23 23:13:57.664 BRST: LDAP: Attempting first next available LDAP server

051690: Aug 23 23:13:57.664 BRST: LDAP: Got next LDAP server :<Removed server name...>

051691: Aug 23 23:13:57.664 BRST: LDAP: First Task: Send bind req

051692: Aug 23 23:13:57.664 BRST: LDAP: Authentication policy: bind-first

051693: Aug 23 23:13:57.664 BRST: LDAP: Bind: User-DN=cn=<Userid removed>,CN=Users,DC=<removed>,<removed>,DC=comldap_req_encode

Doing socket write

051694: Aug 23 23:13:57.664 BRST: LDAP: LDAP bind request sent successfully (reqid=93)

051695: Aug 23 23:13:57.664 BRST: LDAP: Sent transit request to server

051696: Aug 23 23:13:57.664 BRST: LDAP: LDAP request successfully processed

051697: Aug 23 23:13:58.164 BRST: LDAP: Received socket event

051698: Aug 23 23:13:58.164 BRST: LDAP: Process socket event for socket = 0

051699: Aug 23 23:13:58.164 BRST: LDAP: Conn Status = 4

051700: Aug 23 23:13:58.164 BRST: LDAP: Non-TLS read event on socket 0

051701: Aug 23 23:13:58.164 BRST: LDAP: Found socket ctx

051702: Aug 23 23:13:58.164 BRST: LDAP: Receive event: read=1, errno=11 (Resource temporarily unavailable)

051703: Aug 23 23:13:58.164 BRST: LDAP: Passing the client ctx=1855243Cldap_result

wait4msg (timeout 0 sec, 1 usec)

ldap_select_fd_wait (select)

ldap_read_activity lc 0x1AADABD8

Doing socket read

LDAP-TCP:Bytes read = 22

ldap_match_request succeeded for msgid 8 h 0

changing lr 0x11A14BFC to COMPLETE as no continuations

removing request 0x11A14BFC from list as lm 0x1AAB9D14 all 0

ldap_msgfree

051704: Aug 23 23:13:58.164 BRST: LDAP: LDAP Messages to be processed: 1

051705: Aug 23 23:13:58.164 BRST: LDAP: LDAP Message type: 97

051706: Aug 23 23:13:58.164 BRST: LDAP: Got ldap transaction context from reqid 93ldap_parse_result

051707: Aug 23 23:13:58.164 BRST: LDAP: resultCode: 0 (Success)

051708: Aug 23 23:13:58.168 BRST: LDAP: Received Bind Responseldap_parse_result

051709: Aug 23 23:13:58.168 BRST: LDAP: Ldap Result Msg: SUCCESS, Result code =0

051710: Aug 23 23:13:58.168 BRST: LDAP: LDAP Bind successful for DN:cn=<removed>CN=Users,DC=<removed>,DC=<removed>,DC=com

Thank You!

kussriva · ‎08-30-2013

Hi Joe,

I would like to point out few things regarding the configuration:

- Please make sure you are running code: 15.3(3)M as that is the current stable release for ISR Connector.

- Could you please provide the relevant LDAP config as well for verification?

Also I had seen this issue once when in the LDAP configuration. In that case, the base-dn was configured as the domain and it was not working. We changed the configuration and specified the OU in which the users resided in the base-dn and it started to work fine.

Regards,

Kush

Cisco PDI Help Desk

http://www.cisco.com/go/pdihelpdesk

Joe Lourenco · ‎08-30-2013

Hi Kush,

Thank you for your reply.

Basically, Scansafe, in "theory", is working. But in "practicality", it is not. A twist here, is that when it was first implemented in October of 2012, it worked just fine.

Here is the information you requested.

- This ISR is running Version 15.2(4)M1

.

- Scansafe LDAP code (with confidential content omitted in (bold)). I have also underlined some code and show outputs to emphasize the problem.

aaa group server ldap BarraAD

server (fqdn omitted)

aaa authentication login default group BarraAD

aaa authentication login local_auth local

aaa authentication login ss-aaa group BarraAD

aaa authorization network default group BarraAD

aaa authorization network ss-aaa group BarraAD

aaa accounting network ss-aaa none

ip admission virtual-ip 1.1.1.1 virtual-host webproxy

ip admission name NTLM-Active-Admission ntlm list authlist

ip admission name NTLM-Active-Admission order ntlm

ip admission name NTLM-Active-Admission method-list authentication ss-aaa authorization ss-aaa accounting ss-aaa

ldap attribute-map ldap-username-map

map type sAMAccountName username

!

ldap server (fqdn omitted)

ipv4 (IP omitted)

attribute map ldap-username-map

transport port 3268

bind authenticate root-dn CN=(omitted),CN=Users,DC=(x),DC=(x),DC=(x) password 7 (password omitted)

base-dn CN=Users,DC=(x),DC=(x),DC=(x)

search-filter user-object-type top

authentication bind-first

!

I am adding the following Scansafe parameter map and the output of the following show command:

# sh content-scan session active

I believe it may provide some clues, especially the output of the show command as it shows that Scansafe defaults to the username/user-group created in the parameter-map type content-scan global.

(Scansafe parameter-map, with tower and license omitted)

parameter-map type content-scan global

server scansafe primary ipv4 (omitted) port http 8080 https 8080

server scansafe secondary ipv4 (omitted) port http 8080 https 8080

license (omitted)

source interface GigabitEthernet0/1

timeout session-inactivity 60

user-group (omitted) username (omitted) <<-- Default user-group and username

server scansafe on-failure allow-all

The output of #sh content-scan session active

Username/usergroup(s): (default username/user-group) << -- This should be any user and its group

HTTP 10.3.1.124:64262 199.168.174.140:80 (7361:240452) 00:01:29

URI: www.chelseaclock.com

Username/usergroup(s): (default username/user-group) << --This should be any user and its group

HTTP 10.3.1.90:51787 201.20.43.170:80 (871:15255) 1w0d

URI: box.zap.com.br

Note: The output of this show command should be showing usernames and usergroups of our AD server, not the default. Therefore, filters can not be applied per user/group, and default to the default filter.

I really appreciate help in this issue. I need to get Scansafe working in order to justify its purpose, its investment.

Joe

Joe Lourenco · ‎08-31-2013

Hi Kush,

Wanted to point out a couple of more things.

Based on what you said "We changed the configuration and specified the OU in which the users resided in the base-dn and it started to work fine", as you can see in the config,the base-dn has CN=Users, where our users do reside.

In #sh ldap attributes, I saw an alternative option as cn == username to try but that did not work.

In our AD, running > dsquery, yields:

PS C:\> dsquery user -samid

"CN=userid,CN=Users,DC=x,DC=x,DC=com"

In our Linux systems, kinit and wbinfo for our users, returns just fine.

I have read about a possible caveats regarding ldap authentication in which if both the ISR and AD are running NTLMv2, and therefore a workaround is to use NTLM ACTIVE, which I am.

I have tried a monitor capture with ACLs to capture traffic just from the ISR to the AD to see what what the LDAP protocol is sending to authenticate as the DN, but I get 0 packets. In the capture I only get traffic from the AD. Anyway, the debug ldap above shows it anyway.

After picking through debug ldap, I can assume that depending on the user's DN, wether its DN is two words, like "John Smith", or one word like "test", it will dictate wether it will fail or succeed bind. After going through a number of userids, the one's with one word DN successfuly binds and returns groups. Userids who have two words, like "john smith", even though their sAMAcountname is jsmith, fails.

I may be wrong, but its the only difference that I could find between users that do bind and those that do not.

It seems that the root-dn to bind to Active Directory is not being used accordingly to the ldap config and its attribute map for Scansafe.

Please read this thread: thread/2076997.

IOS LDAP authenication against sAMAccountName

The reply by Peter Koltl to 2044418Puts post, at the bottom, states a probable cause to what may be happening.

Here is the output of #sh ldap server (omitted) summary

barra-gate#sh ldap server (omitted) summary

Server Information for (omitted)

================================

Server name : (omitted)

Server IP : (omitted)

Server listening Port :3268

Bind Root-dn :CN=(omitted),CN=Users,DC=(omitted),DC=(omitted),DC=com

Server mode :Non-Secure

Cipher Suite :0x00

Authentication Seq :Bind/Compare password first. Search next

Authentication Procedure:Bind with user password

Base-Dn :CN=Users,DC=(omitted),DC=(omitted),DC=com

Object Class :top

Attribute map :ldap-username-map

Request timeout :30

No. of active connections :10

I appreciate the help in resolving this.

kussriva · ‎09-02-2013

Hi,

As I can see above you are using an older code of the ISR ScanSafe connector 15.0 however our engineering team recommends using the code 15.15.3(3)M as it is the current stable release for ISR/ScanSafe Connector. Could you please upgrade to this code and check the behavior. If it's still the same, I would recommend you contact TAC for further analysis.

Regards,

Kush

Joe Lourenco · ‎09-02-2013

Hello Kushagra,

Will do.

Please take a look into this TAC document 113689, titled:

LDAP on IOS Devices Using Dynamic Attribute Maps Configuration Example

Regards,

Joe

Joe Lourenco · ‎09-02-2013

Hi Kushagra,

I upgraded the image, still the same behavior.

Will contact TAC again.

Thanks,

Joe

Peter Koltl · ‎09-07-2013

Hi Joe,

I'm delighted that you've dug up such an old story of mine. (-: As I went through the logs I noticed the difference between your and my config. You use authentication bind-first command which results in:

051653: Aug 23 23:10:34.983 BRST: LDAP: First Task: Send bind req

051654: Aug 23 23:10:34.983 BRST: LDAP: Authentication policy: bind-first

while my log is:

*Oct 28 09:40:25.903: LDAP: First Task: Send search req

So you should try to remove that setting as described in

http://www.cisco.com/en/US/partner/tech/tk367/technologies_configuration_example09186a0080becd1a.shtml

Will you please edit your post to correct my name spelling? (To help web search engines)

Joe Lourenco · ‎09-10-2013

Hi Peter,

My apologies for the mispelling, it has been corrected.

I came across that very same document and jumped with joy "I found a solution!"

After upgrading the IOS and removing authentication bind-first, it still failed.

What could possibly be happening? I have gone through your document in your site, Cisco documents, tons of captures, and still cannot get it to work. The strange thing is, it used to work.

I appreciate any help!

Thanks.

Peter Koltl · ‎09-11-2013

Then please copy here the new debugs.

You may also want to contact Scansafe center to check the account permissions and their logs.

Have you tried to connect with a graphical LDAP browser?

Joe Lourenco · ‎10-25-2013

Hello Peter,

Output of sh ldap server summary and debug outpout of ldap debug all with authentication bind-first removed.

Content removed in bold face.

#sh ldap server fqdn summary

Server Information for fqdn

================================

Server name :fqdn

Server Address : x.x.x.x

Server listening Port :3268

Bind Root-dn :CN=x,CN=Users,DC=x,DC=x,DC=com

Server mode :Non-Secure

Cipher Suite :0x00

Authentication Seq :Search first. Then Bind/Compare password next

Authentication Procedure:Bind with user password

Base-Dn :CN=Users,DC=x,DC=x,DC=com

Object Class :top

Attribute map :ldap-username-map

Request timeout :30

No. of active connections :2

Debug output:

resultCode 1 (Operations Error) underlined.

107934: Oct 25 10:30:18.586 BRST: LDAP: LDAP: Queuing AAA request 0 for processing

107935: Oct 25 10:30:18.586 BRST: LDAP: Received queue event, new AAA request

107936: Oct 25 10:30:18.586 BRST: LDAP: LDAP authentication request

107937: Oct 25 10:30:18.586 BRST: LDAP: Invalid hash index 512, nothing to remove

107938: Oct 25 10:30:18.586 BRST: LDAP: New LDAP request

107939: Oct 25 10:30:18.586 BRST: LDAP: Attempting first next available LDAP server

107940: Oct 25 10:30:18.586 BRST: LDAP: Got next LDAP server: fqdn

107941: Oct 25 10:30:18.586 BRST: LDAP: Free connection not available. Open a new one.

107942: Oct 25 10:30:18.586 BRST: LDAP: Opening ldap connection ( x.x.x.x, 3268 )ldap_open

ldap_init libldap 4.5 18-FEB-2000

open_ldap_connection

ldap_connect_to_host: x.x.x.x:3268

107943: Oct 25 10:30:18.586 BRST: LDAP: socket open success 3

107944: Oct 25 10:30:18.586 BRST: LDAP: socket 3 - connecting to x.x.x.x (3268)

107945: Oct 25 10:30:18.586 BRST: LDAP: socket 3 - connection in progress

107946: Oct 25 10:30:18.586 BRST: LDAP: socket 3 - got local address x.x.x.x

107947: Oct 25 10:30:18.586 BRST: LDAP: Connection on socket 3

107948: Oct 25 10:30:18.586 BRST: LDAP: Connection to LDAP server (fqdn , x.x.x.x) attempted

107949: Oct 25 10:30:18.586 BRST: LDAP: Connection state: DOWN => CONNECTING

107950: Oct 25 10:30:18.586 BRST: LDAP: LDAP request saved. Will be served after Root Bind is done.

107951: Oct 25 10:30:18.586 BRST: LDAP: LDAP request successfully processed

107952: Oct 25 10:30:18.586 BRST: LDAP: Received socket event

107953: Oct 25 10:30:18.586 BRST: LDAP: Process socket event for socket = 3

107954: Oct 25 10:30:18.586 BRST: LDAP: Conn Status = 1

107955: Oct 25 10:30:18.586 BRST: LDAP: Non-TLS read event on socket 3

107956: Oct 25 10:30:18.586 BRST: LDAP: Found socket ctx

107957: Oct 25 10:30:18.586 BRST: LDAP: Making socket conn up

107958: Oct 25 10:30:18.586 BRST: LDAP: Notify the protocol codeldap_open successful

Notify LDAP main if it has to initiate any bind requests

107959: Oct 25 10:30:18.586 BRST: LDAP: Protocol received transport up notication

107960: Oct 25 10:30:18.586 BRST: LDAP: Transport UP notification for fqdn/3

107961: Oct 25 10:30:18.586 BRST: LDAP: Connection state: CONNECTING => UP

107962: Oct 25 10:30:18.586 BRST: LDAP: Set socket=3 to non blocking mode

107963: Oct 25 10:30:18.586 BRST: LDAP: Performing Root-Dn bind operationldap_req_encode

Doing socket write

107964: Oct 25 10:30:18.586 BRST: LDAP: Root Bind on CN=x,CN=Users,DC=x,DC=x,DC=com initiated.

107965: Oct 25 10:30:18.586 BRST: LDAP: Received socket event

107966: Oct 25 10:30:19.130 BRST: LDAP: Received socket event

107967: Oct 25 10:30:19.130 BRST: LDAP: Process socket event for socket = 3

107968: Oct 25 10:30:19.130 BRST: LDAP: Conn Status = 4

107969: Oct 25 10:30:19.130 BRST: LDAP: Non-TLS read event on socket 3

107970: Oct 25 10:30:19.130 BRST: LDAP: Found socket ctx

107971: Oct 25 10:30:19.130 BRST: LDAP: Receive event: read=1, errno=11 (Resource temporarily unavailable)

107972: Oct 25 10:30:19.130 BRST: LDAP: Passing the client ctx=18646C08ldap_result

wait4msg (timeout 0 sec, 1 usec)

ldap_select_fd_wait (select)

ldap_read_activity lc 0x186CE1B8

Doing socket read

LDAP-TCP:Bytes read = 110

ldap_match_request succeeded for msgid 1 h 0

changing lr 0x112281A0 to COMPLETE as no continuations

removing request 0x112281A0 from list as lm 0x18638280 all 0

ldap_msgfree

107973: Oct 25 10:30:19.130 BRST: LDAP: LDAP Messages to be processed: 1

107974: Oct 25 10:30:19.130 BRST: LDAP: LDAP Message type: 97

107975: Oct 25 10:30:19.130 BRST: LDAP: Got ldap transaction context from reqid 32ldap_parse_result

107976: Oct 25 10:30:19.130 BRST: LDAP: resultCode: 49 (Invalid credentials)

107977: Oct 25 10:30:19.130 BRST: LDAP: Received Bind Response

107978: Oct 25 10:30:19.130 BRST: LDAP: Received Root Bind Response ldap_parse_result

ldap_err2string

107979: Oct 25 10:30:19.130 BRST: LDAP: Ldap Result Msg: FAILED:Invalid credentials, Result code =49

107980: Oct 25 10:30:19.130 BRST: LDAP: Failed to do Root Bind on CN=x,CN=Users,DC=x,DC=x,DC=com. Bind anonymous

107981: Oct 25 10:30:19.130 BRST: LDAP: Transaction context removed from list [ldap reqid=32]

107982: Oct 25 10:30:19.130 BRST: LDAP: LDAP authentication request in ldap_transitQ

107983: Oct 25 10:30:19.130 BRST: LDAP: First Task: Send search req

107984: Oct 25 10:30:19.130 BRST: LDAP: Dynamic map configured

107985: Oct 25 10:30:19.130 BRST: LDAP: Dynamic map found for aaa type=username

107986: Oct 25 10:30:19.130 BRST: LDAP: Ldap Search Req sent

ld 409234440

base dn CN=Users,DC=x,DC=x,DC=com

scope 2

filter (&(objectclass=top)(sAMAccountName=userid))ldap_req_encode

put_filter "(&(objectclass=top)(sAMAccountName=userid))"

put_filter: AND

put_filter_list "(objectclass=top)(sAMAccountName=userid)"

put_filter "(objectclass=top)"

put_filter: simple

put_filter "(sAMAccountName=userid)"

put_filter: simple

Doing socket write

107987: Oct 25 10:30:19.130 BRST: LDAP: lctx conn index = 3

107988: Oct 25 10:30:19.130 BRST: LDAP: LDAP search request sent successfully (reqid:33)

107989: Oct 25 10:30:19.130 BRST: LDAP: Sent transit request to serverldap_msgfree

ldap_result

wait4msg (timeout 0 sec, 1 usec)

ldap_select_fd_wait (select)

ldap_err2string

107990: Oct 25 10:30:19.130 BRST: LDAP: Finished processing ldap msg, Result:Success

107991: Oct 25 10:30:19.130 BRST: LDAP: Received socket event

107992: Oct 25 10:30:19.634 BRST: LDAP: Received socket event

107993: Oct 25 10:30:19.634 BRST: LDAP: Process socket event for socket = 3

107994: Oct 25 10:30:19.634 BRST: LDAP: Conn Status = 4

107995: Oct 25 10:30:19.634 BRST: LDAP: Non-TLS read event on socket 3

107996: Oct 25 10:30:19.634 BRST: LDAP: Found socket ctx

107997: Oct 25 10:30:19.634 BRST: LDAP: Receive event: read=1, errno=11 (Resource temporarily unavailable)

107998: Oct 25 10:30:19.634 BRST: LDAP: Passing the client ctx=18646C08ldap_result

wait4msg (timeout 0 sec, 1 usec)

ldap_select_fd_wait (select)

ldap_read_activity lc 0x186CE1B8

Doing socket read

LDAP-TCP:Bytes read = 174

ldap_match_request succeeded for msgid 2 h 0

changing lr 0x11619AE8 to COMPLETE as no continuations

removing request 0x11619AE8 from list as lm 0x18638280 all 0

ldap_msgfree

107999: Oct 25 10:30:19.634 BRST: LDAP: LDAP Messages to be processed: 1

108000: Oct 25 10:30:19.634 BRST: LDAP: LDAP Message type: 101

108001: Oct 25 10:30:19.634 BRST: LDAP: Got ldap transaction context from reqid 33ldap_parse_result

108002: Oct 25 10:30:19.634 BRST: LDAP: resultCode: 1 (Operations error)

108003: Oct 25 10:30:19.634 BRST: LDAP: Received Search Response resultldap_parse_result

ldap_err2string

108004: Oct 25 10:30:19.634 BRST: LDAP: Ldap Result Msg: FAILED:Operations error, Result code =1

108005: Oct 25 10:30:19.634 BRST: LDAP: LDAP Search operation result : failedldap_msgfree

108006: Oct 25 10:30:19.634 BRST: LDAP: Closing transaction and reporting error to AAA

108007: Oct 25 10:30:19.634 BRST: LDAP: Transaction context removed from list [ldap reqid=33]

108008: Oct 25 10:30:19.634 BRST: LDAP: Notifying AAA: REQUEST FAILED

108009: Oct 25 10:30:19.634 BRST: LDAP: Received socket event

Thank You!

Joe Lourenco · ‎10-25-2013

Hello Peter,

I had updated the IOS to the latest version, and removed the bind authenticate root-dn and authenticate bind-first, now my test userid is not being rejected and yielding all the groups my test userid belongs to.

As you can see from the debug log above, it was first yielding a bind error.

However, according to SS Solution Guide, it goes against what should be configured. Even though there is no rejection, still it is incorrect, right?

The ldap server for SS summary:

#sh ldap server fqdn summary

Server Information for fqdn

================================

Server name :fqdn

Server Address :x.x.x.x

Server listening Port :3268

Server mode :Non-Secure

Cipher Suite :0x00

Authentication Seq :Search first. Then Bind/Compare password next

Authentication Procedure:Bind with user password

Base-Dn :CN=Users,DC=x,DC=x,DC=com

Object Class :top

Attribute map :ldap-username-map

Request timeout :30

No. of active connections : 0

---------------------------------

The debug log is too big to add here, but it is not doing the root binding.

Thanks!

Joe

Peter Koltl · ‎10-27-2013

Ok, and what does Scansafe center say? This seems to be a bind/auth error due to bad credentials.

Can you connect with a graphical LDAP browser?

Joe Lourenco · ‎10-28-2013

I have used ldapadmin and phpldapadmin successfully. I connected with the scansafe specific user created just for scansafe purposes and successfully ran queries.

Now, I noticed an odd behavior in the ISR. Today, the "test aaa group ...userid..." is failing, but I made an observation and conclusion.

I added back the bind authenticate root-dn and authenticate bind-first code back into the ldap server. Bringing the SS code back to the default config. I concluded that userids that have a CN in AD that consists of First Name Last Name (such as "John Doe") , fail. Those that consist of only 1 word (such as "test"), succeed.

So, then I removed them again, like I did on the Oct. 25th, and the tests return successfully. And that is even for those with 2 names in their CN. But, after running several successful tests, it begans to reject!

And note, the attribute map is there.

ldap attribute-map ldap-username-map

map type sAMAccountName username

I had a case open with TAC LDAP but my work travel schedule this year was very demanding and kept elongating the open status of the case. Plus, simulating the problem was rather perplexing because the code itself is nearly identical to the SS recommended config. The engineer was excellent and helpful, but me being overseas took a toll on time.

inderpalsogi · ‎12-17-2013

I had this issue but managed to resolve it.

The issue was with

bind authenticate root-dn CN=,CN=Users,DC=mydomain,DC=com password

The is the Display Name i.e. (FirstName and Last Name) of the user in AD, and this has to have NO SPACES. For example I created a user with a Display Name called ScansafeAdmin.

Oncre the binding takes place, you can use the following test:for any other user in your LDAP/AD.

test aaa group new-code

where is the User Login Name in AD not the Display Name i.e. in my case the Login Name was scansafe

I also removed the following command authentication bind-first

Cloud Web Security (formerly Scansafe) ldap resultCode: 49 Invalid Credentials. Default usergroup applied after user's sAMAccount authentication fails after BINDING

IOS LDAP authenication against sAMAccountName

LDAP on IOS Devices Using Dynamic Attribute Maps Configuration Example