ACS 4.2 - LDAP TCP Keepalive

Hello
I have an ACS 4.2.1.15 patch 3 and Novell Netware LDAP Server separated by a Firewall. The Firewall's default tcp session timeout is 3600 seconds.
When no LDAP-Request is made for over one hour, the Firewall drops the connection from its table. The Problem is, that the ACS-Server thinks the connection is still open. When it tries to send an LDAP-Query this results in retransmissions and finally a RST... On the User side the Authentication attempt fails (timeout).
I tried to enable TCP Keepalives on the Windows-Server side, but this has no effect on the LDAP-Connections used by ACS.
Is there any possibility to enable Keepalives in ACS?
Thanks in advance for any help!

I'm seeing this issue too on 5.2.0.26.1, running LDAP auth through a F5 Load Balancer to a pair of Sun directory servers.
Did you make any progress with your TAC case?
Without using the root patch, this command is useful for finding out what is going on (it's just netstat):
# show tech-support | i ldap | i tcp
ldap            389/tcp
ldaps           636/tcp                         # LDAP over SSL
tcp        0      0 exc2-acscor-1401:53892      acs.ldapunix.co:ldap ESTABLISHED
tcp        0      0 exc2-acscor-1401:53893      acs.ldapunix.co:ldap ESTABLISHED
tcp        0      0 exc2-acscor-1401:53890      acs.ldapunix.co:ldap ESTABLISHED
tcp        0      0 exc2-acscor-1401:53891      acs.ldapunix.co:ldap ESTABLISHED
tcp        0      0 exc2-acscor-1401:53889      acs.ldapunix..co:ldap ESTABLISHED
Also try adjusting "Max. Admin Connections" for LDAP.
From the admin guide:
LDAP Connection Management
ACS 5.1 supports multiple concurrent LDAP connections. Connections are opened on demand at the time of the first LDAP authentication. The maximum number of connections is configured for each LDAP server. Opening connections in advance shortens the authentication time. You can set the maximum number of connections to use for concurrent binding connections. The number of opened connections can be different for each LDAP server (primary or secondary) and is determined according to the maximum number of administration connections configured for each server.
ACS retains a list of open LDAP connections (including the bind information) for each LDAP server that is configured in ACS. During the authentication process, the connection manager attempts to find an open connection from the pool. If an open connection does not exist, a new one is opened.
If the LDAP server closed the connection, the connection manager reports an error during the first call to search the directory, and tries to renew the connection.
After the authentication process is complete, the connection manager releases the connection to the connection manager.
I'd be interested to hear if you have fixed your issue, or if anyone else is facing similar problems load balancing LDAP servers for the ACS.
Cheers
R.

Similar Messages

ACS - LDAP TCP Keepalive (v5.2)

reposting as with subject including v5.2:
Hello
I have an ACS 4.2.1.15 patch 3 and Novell Netware LDAP Server separated by a Firewall. The Firewall's default tcp session timeout is 3600 seconds.
When no LDAP-Request is made for over one hour, the Firewall drops the connection from its table. The Problem is, that the ACS-Server thinks the connection is still open. When it tries to send an LDAP-Query this results in retransmissions and finally a RST... On the User side the Authentication attempt fails (timeout).
I tried to enable TCP Keepalives on the Windows-Server side, but this has no effect on the LDAP-Connections used by ACS.
Is there any possibility to enable Keepalives in ACS?
Thanks in advance for any help!
Average Rating: 0 (0 Votes)
Reply
Outline View
Javier Henderson
159 posts sinceMar 12, 2010
1. Dec 28, 2010 5:54 PM in response to: Zentraler Informatikdienst
Re: ACS 4.2 - LDAP TCP Keepalive
You are seeing the effects of bug CSCti03338 which I filed a few months ago, though it is supposed to be fixed on 4.2.1(15) patch 3. Please open a TAC case so we can look into this in detail.
ACS 4.2 - LDAP TCP KeepaliveACS 4.2 - LDAP TCP KeepaliveACS 4.2 - LDAP TCP KeepaliveACS 4.2 - LDAP TCP KeepaliveACS 4.2 - LDAP TCP Keepalive
Average Rating: 0 (0 Votes)
Report Abuse
Reply
Juergen Meier
2 posts sinceSep 28, 2010
2. Jan 17, 2011 5:46 AM in response to: Javier Henderson
Also ACS 5.2 (was: ACS 4.2 - LDAP TCP Keepalive)
Apparently this bug has re-appeared in ACS 5.2 (5.2.0.26). ACS re-uses stale TCP connections many hours after the last TCP packet was sent.
It also uses different TCP connections for LDAP search queries and the subsequent authentication bind requests, so sometimes the search query and sometimes the bind request fails due to the TCP connection been timed-out long ago on all network devices (stateful firewalls, IDS/IPS, load balancers) between the ACS and the LDAP servers.
Further ACS fails to detect stale TCP connections and reports bogus authentication failures back to the NAS.
A new ticket will be filed with TAC today.
ACS 4.2 - LDAP TCP KeepaliveACS 4.2 - LDAP TCP KeepaliveACS 4.2 - LDAP TCP KeepaliveACS 4.2 - LDAP TCP KeepaliveACS 4.2 - LDAP TCP Keepalive
Average Rating: 0 (0 Votes)
Report Abuse
Reply
ROB SCHIERON
5 posts sinceOct 20, 2010
3. Feb 14, 2011 10:29 PM in response to: Juergen Meier
Re: Also ACS 5.2 (was: ACS 4.2 - LDAP TCP Keepalive)
I'm seeing this issue too on 5.2.0.26.1, running LDAP auth through a F5 Load Balancer to a pair of Sun directory servers.
Did you make any progress with your TAC case?
Without using the root patch, this command is useful for finding out what is going on (it's just netstat):
# show tech-support | i ldap | i tcp
ldap            389/tcp
ldaps           636/tcp                         # LDAP over SSL
tcp        0      0 exc2-acscor-1401:53892      acs.ldapunix.co:ldap ESTABLISHED
tcp        0      0 exc2-acscor-1401:53893      acs.ldapunix.co:ldap ESTABLISHED
tcp        0      0 exc2-acscor-1401:53890      acs.ldapunix.co:ldap ESTABLISHED
tcp        0      0 exc2-acscor-1401:53891      acs.ldapunix.co:ldap ESTABLISHED
tcp        0      0 exc2-acscor-1401:53889      acs.ldapunix..co:ldap ESTABLISHED
Also try adjusting "Max. Admin Connections" for LDAP.
From the admin guide:
LDAP Connection Management
ACS 5.1 supports multiple concurrent LDAP connections. Connections are opened on demand at the time of the first LDAP authentication. The maximum number of connections is configured for each LDAP server. Opening connections in advance shortens the authentication time. You can set the maximum number of connections to use for concurrent binding connections. The number of opened connections can be different for each LDAP server (primary or secondary) and is determined according to the maximum number of administration connections configured for each server.
ACS retains a list of open LDAP connections (including the bind information) for each LDAP server that is configured in ACS. During the authentication process, the connection manager attempts to find an open connection from the pool. If an open connection does not exist, a new one is opened.
If the LDAP server closed the connection, the connection manager reports an error during the first call to search the directory, and tries to renew the connection.
After the authentication process is complete, the connection manager releases the connection to the connection manager.
I'd be interested to hear if you have fixed your issue, or if anyone else is facing similar problems load balancing LDAP servers for the ACS.
Cheers
R.

reposting as with subject including v5.2:
Hello
I have an ACS 4.2.1.15 patch 3 and Novell Netware LDAP Server separated by a Firewall. The Firewall's default tcp session timeout is 3600 seconds.
When no LDAP-Request is made for over one hour, the Firewall drops the connection from its table. The Problem is, that the ACS-Server thinks the connection is still open. When it tries to send an LDAP-Query this results in retransmissions and finally a RST... On the User side the Authentication attempt fails (timeout).
I tried to enable TCP Keepalives on the Windows-Server side, but this has no effect on the LDAP-Connections used by ACS.
Is there any possibility to enable Keepalives in ACS?
Thanks in advance for any help!
Average Rating: 0 (0 Votes)
Reply
Outline View
Javier Henderson
159 posts sinceMar 12, 2010
1. Dec 28, 2010 5:54 PM in response to: Zentraler Informatikdienst
Re: ACS 4.2 - LDAP TCP Keepalive
You are seeing the effects of bug CSCti03338 which I filed a few months ago, though it is supposed to be fixed on 4.2.1(15) patch 3. Please open a TAC case so we can look into this in detail.
ACS 4.2 - LDAP TCP KeepaliveACS 4.2 - LDAP TCP KeepaliveACS 4.2 - LDAP TCP KeepaliveACS 4.2 - LDAP TCP KeepaliveACS 4.2 - LDAP TCP Keepalive
Average Rating: 0 (0 Votes)
Report Abuse
Reply
Juergen Meier
2 posts sinceSep 28, 2010
2. Jan 17, 2011 5:46 AM in response to: Javier Henderson
Also ACS 5.2 (was: ACS 4.2 - LDAP TCP Keepalive)
Apparently this bug has re-appeared in ACS 5.2 (5.2.0.26). ACS re-uses stale TCP connections many hours after the last TCP packet was sent.
It also uses different TCP connections for LDAP search queries and the subsequent authentication bind requests, so sometimes the search query and sometimes the bind request fails due to the TCP connection been timed-out long ago on all network devices (stateful firewalls, IDS/IPS, load balancers) between the ACS and the LDAP servers.
Further ACS fails to detect stale TCP connections and reports bogus authentication failures back to the NAS.
A new ticket will be filed with TAC today.
ACS 4.2 - LDAP TCP KeepaliveACS 4.2 - LDAP TCP KeepaliveACS 4.2 - LDAP TCP KeepaliveACS 4.2 - LDAP TCP KeepaliveACS 4.2 - LDAP TCP Keepalive
Average Rating: 0 (0 Votes)
Report Abuse
Reply
ROB SCHIERON
5 posts sinceOct 20, 2010
3. Feb 14, 2011 10:29 PM in response to: Juergen Meier
Re: Also ACS 5.2 (was: ACS 4.2 - LDAP TCP Keepalive)
I'm seeing this issue too on 5.2.0.26.1, running LDAP auth through a F5 Load Balancer to a pair of Sun directory servers.
Did you make any progress with your TAC case?
Without using the root patch, this command is useful for finding out what is going on (it's just netstat):
# show tech-support | i ldap | i tcp
ldap            389/tcp
ldaps           636/tcp                         # LDAP over SSL
tcp        0      0 exc2-acscor-1401:53892      acs.ldapunix.co:ldap ESTABLISHED
tcp        0      0 exc2-acscor-1401:53893      acs.ldapunix.co:ldap ESTABLISHED
tcp        0      0 exc2-acscor-1401:53890      acs.ldapunix.co:ldap ESTABLISHED
tcp        0      0 exc2-acscor-1401:53891      acs.ldapunix.co:ldap ESTABLISHED
tcp        0      0 exc2-acscor-1401:53889      acs.ldapunix..co:ldap ESTABLISHED
Also try adjusting "Max. Admin Connections" for LDAP.
From the admin guide:
LDAP Connection Management
ACS 5.1 supports multiple concurrent LDAP connections. Connections are opened on demand at the time of the first LDAP authentication. The maximum number of connections is configured for each LDAP server. Opening connections in advance shortens the authentication time. You can set the maximum number of connections to use for concurrent binding connections. The number of opened connections can be different for each LDAP server (primary or secondary) and is determined according to the maximum number of administration connections configured for each server.
ACS retains a list of open LDAP connections (including the bind information) for each LDAP server that is configured in ACS. During the authentication process, the connection manager attempts to find an open connection from the pool. If an open connection does not exist, a new one is opened.
If the LDAP server closed the connection, the connection manager reports an error during the first call to search the directory, and tries to renew the connection.
After the authentication process is complete, the connection manager releases the connection to the connection manager.
I'd be interested to hear if you have fixed your issue, or if anyone else is facing similar problems load balancing LDAP servers for the ACS.
Cheers
R.

Lack of TCP keepalive parameter in Microsoft SQL Server ODBC Driver for Linux

Hello,
the problem in the
aforementioned driver is the lack of TCP keepalive parameter that results in hanged threads because of closed connections on the SQL Server side, but not closed
sockets on the client side. This could happen due to network-related problems.
The driver is used in mission critical 24/7 uptime application and due to hanged threads the application cannot continue it's work and it needs to be restarted.
This is observed in the latest version of the driver on RHEL 5.6.
If you need clarification please ask.
Does anybody know any workaround to this situation or a solution that I'm not aware of?
Thank you for your help,
luk.s

Find the TCP socket of the ODBC connection in your process and set the keep-alive option and keep-alive timeout on it.
You can do that by interposing socket system call.
Or use libkeepalive: http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/#libkeepalive

TCP keepalives sent too early and terminates connection

I'm trying to implement an persistent TCP connection between an Android phone and a desktop server.
I've got heartbeat threads on both ends which are sending keepalive-packets on application level successfully.
The problem is that after a while (varies between 5-20min) the phone is starting to send TCP keepalives to the server, which the server does not seem to respond to. (I'm using Wireshark to monitor this).
This results in an exception on the server thread which is reading from the phone:java.net.SocketException: Connection reset
Why are the phone sending TCP keepalives so early? Even when there's constantly activity on application level? And why doesn't the desktop server respond to this keepalives?
I've checked my Android phone's settings with "sysctl -A | grep net.ipv4" and "net.ipv4.tcp_keepalive_time" is set to 7200 (2 hours).
Thanks.

shuwo wrote:
I'm holding both a wakelock and a wifilock, so that shouldn't be the problem. I also tried it without putting my phone to sleep at all. I want a persistent connection because I need live data to be transmitted over the network, is there any other method for that?
If it isn't keep alive packets, what could it be? What causes a connection reset on server side?I wouldn't rely on a persistent connection. Mobile phones and bad network conditions/lost connections is bound to happen, and can happen frequently.
What do you mean by live data? Are you e.g streaming data? Polling (e.g. once per minute) could otherwise be better, that is how gmail works.
I doubt that the battery will last more than 6-7 hours if the phone never goes down to sleep mode. You can easily test it. Create an app, that just aquires a wakelock and then run it on your phone without doing any else like accessing network etc. Constantly using the network will also reduce the battery time even more.

What is tcp-keepalives-in and tcp-keepalives-out

Can anyone help me out by telling the both things and the differences between
tcp-keepalives-in and tcp-keepalives-out
Thanks
Irshad

Irshad,
If you have already not read this link...
http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a00801365f3.shtml

ACS v5.1 - LDAP and PEAP

Hi!
I'm trying to authenticate a WinXP client with PEAP.
And since it is only possible to define only one Active Directory in ACS v5.1 ( why on earth is that???), I had to define my other AD domain through LDAP.
But when I try to authenticate, this is what happens:
11001 Received RADIUS Access-Request
11017 RADIUS created a new session
Evaluating Service Selection Policy
15004 Matched rule
15012 Selected Access Service - Policy-SwitchAccess-Testdomain
11507 Extracted EAP-Response/Identity
12500 Prepared EAP-Request proposing EAP-TLS with challenge
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing session
12301 Extracted EAP-Response/NAK requesting to use PEAP instead
12300 Prepared EAP-Request proposing PEAP with challenge
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing session
12302 Extracted EAP-Response containing PEAP challenge-response and accepting PEAP as negotiated
12318 Successfully negotiated PEAP version 0
12800 Extracted first TLS record; TLS handshake started.
12805 Extracted TLS ClientHello message.
12806 Prepared TLS ServerHello message.
12807 Prepared TLS Certificate message.
12810 Prepared TLS ServerDone message.
12305 Prepared EAP-Request with another PEAP challenge
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing session
12304 Extracted EAP-Response containing PEAP challenge-response
12305 Prepared EAP-Request with another PEAP challenge
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing session
12304 Extracted EAP-Response containing PEAP challenge-response
12318 Successfully negotiated PEAP version 0
12812 Extracted TLS ClientKeyExchange message.
12804 Extracted TLS Finished message.
12801 Prepared TLS ChangeCipherSpec message.
12802 Prepared TLS Finished message.
12816 TLS handshake succeeded.
12310 PEAP full handshake finished successfully
12305 Prepared EAP-Request with another PEAP challenge
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing session
12304 Extracted EAP-Response containing PEAP challenge-response
12313 PEAP inner method started
11521 Prepared EAP-Request/Identity for inner EAP method
12305 Prepared EAP-Request with another PEAP challenge
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing session
12304 Extracted EAP-Response containing PEAP challenge-response
11522 Extracted EAP-Response/Identity for inner EAP method
11806 Prepared EAP-Request for inner method proposing EAP-MSCHAP with challenge
12305 Prepared EAP-Request with another PEAP challenge
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing session
12304 Extracted EAP-Response containing PEAP challenge-response
11808 Extracted EAP-Response containing EAP-MSCHAP challenge-response for inner method and accepting EAP-MSCHAP as negotiated
Evaluating Identity Policy
15006 Matched Default Rule
15013 Selected Identity Store -
22043 Current Identity Store does not support the authentication method; Skipping it.
22056 Subject not found in the applicable identity store(s).
22058 The advanced option that is configured for an unknown user is used.
22061 The 'Reject' advanced option is configured in case of a failed authentication request.
11815 Inner EAP-MSCHAP authentication failed
11520 Prepared EAP-Failure for inner EAP method
22028 Authentication failed and the advanced options are ignored.
12305 Prepared EAP-Request with another PEAP challenge
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing session
12304 Extracted EAP-Response containing PEAP challenge-response
12307 PEAP authentication failed
11504 Prepared EAP-Failure
11003 Returned RADIUS Access-Reject
What does this mean? Is it possible that ACS *STILL* does not support PEAP authentication agains LDAP??
The other thing that bothers me, is that the matching rule is Default.
But when I go into the matching Policy to see the hit count, none of the rules (including Default) has increased its Hit Count.. very strange.
Thanks.

LDAP as an external database never supports PEAP with Mschap. The client should be installed with the EAP-GTC supplicant.
Peap Mschapv2 only works with Active Directory.
Its an LDAP limitation, not ACS- there is no LDAP API to do it.
Supported LDAP server and 802.1x clients:
http://www.cisco.com/en/US/partner/docs/net_mgmt/cisco_secure_access_control_system/5.1/de
vice_support/sdt51.html#wp71123
You may check PEAP FAQ's, please take a look under EAP TYPE comparison chart:
http://www.cisco.biz/en/US/prod/collateral/wireless/ps5678/ps430/prod_qas0900aecd801764fa_
ps2706_Products_Q_and_A_Item.html
Regds,
JK
Do rate helpful posts-

ACS 5.2 LDAP authentication through groupMembership

Hi all,
I've succesfully configured ACS to authenticate users against our Novell DB through LDAP External Identity Store . With this setup all users having Novell account are authenticated.
There's an extra requirement that only users belong to group "Internet Access Users" can be authenticated. Running debugging on the ACS (5.2), I've been able to see that ACS can extract the user's group properties as bellow:
LDAP-response-search-entry-attr-value=groupMembership=cn=Internet Access Users\,ou=App Groups\,ou=ZENINTH\,o=Company
but I unable to create mapping/rules that filter this extra value. What I did is :
- Under External Identity Stores --> LDAP --> LDAP_Connection --> Directory Attributes, I added Attribute Name = "groupMembership", Type: "String", Policy Condition Name: "LDAP_Connection:groupMembership"
- Under Access Policies --> Internet Access --> Authorization, I create Rule-1 stated that "LDAP-LDAP_Connection:groupMembership contains cn=Internet Access Users", it will permitAccess. The default rules is denyAccess
But it seems it didn't work (never hit Rule-1)
Could anybody shed some lights ?
Thank you very much,

Ok All is working, consider this as solved.
A restart of the ACS service magically fixed whatever was going on.
Cheers

ACS 4.1 LDAP configuration

Does anyone have examples of what to enter in the External User Database, Generic LDAP for Novell eDir? I can't seem to get the ACS to query eDir.

I also would like to see some design docs on Novell eDir.
thanks
roger....

ACS 4.x LDAP Group Order

Hello there.
A customer of mine is complaining about the LDAP groups order. When he needs to make group mappings to one of the many groups he have in his database, he face problems to find them, because they're not in alphabetical order. Is that a way to get it in this way?
There's a screenshot to illustrate what's going on.

Hi,
The LDAP Group set will populate the groups as defined in the AD.
I don't think it does take the pain to arrange them in an alphabetical order.
Regards,
Anisha
P.S.: please mark this thread resolved if you think your query is answered.

EAP-TLS Vista Machine Authentication to ACS integrated to non AD LDAP

Hello all,
I've been working on a scenario with ACS 4.2 (trial) for Proof of Concept to a customer of ACS's abilities.
His intended network plan is to use Vista Laptops doing Machine authentication only towards a ACS server integrated with a non-microsoft LDAP server. The mechanism of choice is EAP-TLS.
We've set up the PKI on the right places and it is all up. We do manage to get a user certificate on the PC, authenticate via ACS to the LDAP repository, and everything is good.
The problem that we are facing is when we want to move to do machine authentication, the behaviour is inconsistent. I'll explain:
When the first authentication is done, the EAP-Identity requests are always prepended with a "host/". What we see is that the CN of a certificate is TEST, and the Identity request appears as host/TEST. This is no problem to LDAP, as we can get rid of the "host/" part to do the user matching and in fact it does match. After TLS handshake (certificates are ok), ACS tries to check CSDB (the internal ACS db) and afterwards it will follow the unknown user policy and query LDAP.
All of this appears to be successful the first time.
If we disassociate the machine, the problems start. The accounting STOP message is never sent.
Any new authentication will fail with a message that CS user is invalid. The AUTH log shows that ACS will never try again to check LDAP, and invalidates the user right after CSDB check. In fact if we do see the reports for RADIUS, the authenticated user is host/TEST, but if we check the dynamic users, only TEST appears. Even disabling caching for dynamic users the problem remains.
Does anyone have an idea on how to proceed? If it was possible to handle the machine authentication without the "host/" part, that would be great, as it works.
My guess is that ACS is getting confused with the host/, as I'm seeing its AUTH logs and I do see some messages like UDB_HOST_DB_FAILURE, after UDB_USER_INVALID.
IF someone can give me a pointer on how to make this work, or if I'm hitting a bug in ACS.
Thanks
Gustavo

Assuming you're using the stock XP wifi client.
When running XPSP3, you need to set two things:
1) force one registry setting.
According to
http://technet.microsoft.com/en-us/library/cc755892%28WS.10%29.aspx#w2k3tr_wir_tools_uzps
You need to force usage of machine cert-store certificate:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EAPOL\Parameters\General\Global]
"AuthMode"=dword:00000002
2) add the ACS certificate signing CA to the specific SSID profile "trusted CA".
- show available wireless networks
- change advanced settings
- wireless networks tab
- select your SSID, and then hit the "properties" button
- select authentication tab, and then hit "properties" button
- search for your signing CA, and check the box.
I did with a not-so-simple autoIT script, using the "native wifi functions" addon.
Unfortunately I'm not allowed to share the script outside the company, but I'll be more than happy to review yours.
please cross reference to
https://supportforums.cisco.com/message/3280232
for a better description of the whole setup.
Ivan

Failed to authenticate user to ACS 5.1 with LDAP as external identity storage

Hi , I have an ACS and Open-LDAP server running on my company network.
Now, I 'm setting up a new linksys WAP-54G and choose WPA2-Enterprise option with ACS as the radius server.
first thing first, I created new internal user on ACS, and trying to join the wireless network from my computer. I made it....
then, I'm moving on external entity (LDAP Server). I've set up the LDAP configuration and identity sequence, also select it on access service. but when I tried to authenticate from my computer, an error was occurred. I received :
the following error 22056 Subject not found in the applicable identity store (s)
Wonder 'bout this thing, I set up a cisco 1841 router to become AAA client. and surprisingly... it works !!!
so, is there any problem to authenticate from windows platform to ACS (pointing to LDAP) ?
any suggestion ?
thanks

This is the log when using windows 7 as authentication client (Failed) :
Steps
11001 Received RADIUS Access-Request
11017 RADIUS created a new session
Evaluating Service Selection Policy
15004 Matched rule
15012 Selected Access Service - Default Network Access
11507 Extracted EAP-Response/Identity
12500 Prepared EAP-Request proposing EAP-TLS with challenge
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing session
12301 Extracted EAP-Response/NAK requesting to use PEAP instead
12300 Prepared EAP-Request proposing PEAP with challenge
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing session
12302 Extracted EAP-Response containing PEAP challenge-response and accepting PEAP as negotiated
12318 Successfully negotiated PEAP version 0
12800 Extracted first TLS record; TLS handshake started.
12805 Extracted TLS ClientHello message.
12806 Prepared TLS ServerHello message.
12807 Prepared TLS Certificate message.
12810 Prepared TLS ServerDone message.
12305 Prepared EAP-Request with another PEAP challenge
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing session
12304 Extracted EAP-Response containing PEAP challenge-response
12318 Successfully negotiated PEAP version 0
12812 Extracted TLS ClientKeyExchange message.
12804 Extracted TLS Finished message.
12801 Prepared TLS ChangeCipherSpec message.
12802 Prepared TLS Finished message.
12816 TLS handshake succeeded.
12310 PEAP full handshake finished successfully
12305 Prepared EAP-Request with another PEAP challenge
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing session
12304 Extracted EAP-Response containing PEAP challenge-response
12313 PEAP inner method started
11521 Prepared EAP-Request/Identity for inner EAP method
12305 Prepared EAP-Request with another PEAP challenge
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing session
12304 Extracted EAP-Response containing PEAP challenge-response
11522 Extracted EAP-Response/Identity for inner EAP method
11806 Prepared EAP-Request for inner method proposing EAP-MSCHAP with challenge
12305 Prepared EAP-Request with another PEAP challenge
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing session
12304 Extracted EAP-Response containing PEAP challenge-response
11808 Extracted EAP-Response containing EAP-MSCHAP challenge-response for inner method and accepting EAP-MSCHAP as negotiated
Evaluating Identity Policy
15006 Matched Default Rule
15013 Selected Identity Store -
22043 Current Identity Store does not support the authentication method; Skipping it.
24210 Looking up User in Internal Users IDStore - xxxxx
24216 The user is not found in the internal users identity store.
22016 Identity sequence completed iterating the IDStores
22056 Subject not found in the applicable identity store(s).
22058 The advanced option that is configured for an unknown user is used.
22061 The 'Reject' advanced option is configured in case of a failed authentication request.
11815 Inner EAP-MSCHAP authentication failed
11520 Prepared EAP-Failure for inner EAP method
22028 Authentication failed and the advanced options are ignored.
12305 Prepared EAP-Request with another PEAP challenge
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing session
12304 Extracted EAP-Response containing PEAP challenge-response
12307 PEAP authentication failed
11504 Prepared EAP-Failure
11003 Returned RADIUS Access-Reject
This is the log when using 1841 router as authentication client (succeded) :
Steps
11001 Received RADIUS Access-Request
11017 RADIUS created a new session
11049 Settings of RADIUS default network will be used
Evaluating Service Selection Policy
15004 Matched rule
15012 Selected Access Service - Default Network Access
Evaluating Identity Policy
15006 Matched Default Rule
15013 Selected Identity Store - LDAPyyyy
24031 Sending request to primary LDAP server
24015 Authenticating user against LDAP Server
24022 User authentication succeeded
22037 Authentication Passed
22023 Proceed to attribute retrieval
22038 Skipping the next IDStore for attribute retrieval because it is the one we authenticated against
24210 Looking up User in Internal Users IDStore - xxxxx
24216 The user is not found in the internal users identity store.
22016 Identity sequence completed iterating the IDStores
Evaluating Group Mapping Policy
Evaluating Exception Authorization Policy
15042 No rule was matched
Evaluating Authorization Policy
15006 Matched Default Rule
15016 Selected Authorization Profile - Permit Access
11002 Returned RADIUS Access-Accept
I realized that Windows is using PEAP-MSCHAPv2 while Router is using PAP-ASCII as it's protocol.
so now, why PEAP-MSCHAPv2 can't authenticate to LDAP ?
is there anything I can do to make it work ?

ACS With ldap Unix

Hi, I'm in a project security information and I'm think integration ACS software with ldap hosts in Unix machine: Samba
it's works??
there is a version trial of the ACS ? any version 4.2, 5.1 etc..
thank

Try this
ACS 4.2
http://www.cisco.com/cgi-bin/Software/Tablebuild/doftp.pl?ftpfile=cisco/crypto/3DES/ciscosecure/acs/win/90-dayeval/eval-ACS-4.2.0.124-SW.zip&app=Tablebuild&status=showC2A%3E
ACS 4.1
http://www.cisco.com/cgi-bin/tablebuild.pl/acs-win-eval
ACS 5.1
https://supportforums.cisco.com/thread/2024417

AAA acs 4.1 to generic ldap

Hi there
We've installed ACS 4.1 to use it for network access authentication (switches, routers) via Radius (IETF).
I setup ACS with generic ldap to verfy users from MS Active Directory.
Everything work well :-)
But how do I configure ldaps under Cisco ACS?
Thanx for help

Hi BB,
Please ensure the cert is installed correctly. Did you generate cert7.db file ?
How to generate "cert7.db" file :
1. Setup the LDAP with a certificate.
2. Install Netscape 4.x (this creates the cert7.db file, which is just a database of
certs)
3. Browse to https://servername:636 with the netscape browser.
4. Install the certificate selecting the option "accept this certificate forever"
5. Copy the cert7.db file to another directory (like the ACS folder)
The default location of the cert7.db file is C:\Program Files\Netscape\Users\default
6. Now just enter the path to the cert7.db file in the "Certificate DB Path" field in the
configuration for your LDAP DB in ACS.
Also let me know if you are using acs windows or acs appliance as we might need to look at the detailed logs.
Regards,
~JG

ACS can not access ADS-LDAP starting from "DC=..."

Hi
I have an ACS v4.2 from which I try to access an ADS LDAP directory. When I use "CN=Users,DC=Domain,DC=com" as the baseDN for the users and the groups everything works as it should. When I change the base DN to "DC=Domain,DC=com" only, then the ACS is not able to find any users or groups. Even when trying to configure the group mappings he claims: "LDAP Server NOT reachable. Please check the configuration.". Using an LDAP browser I don't have any issues accessing the directory from the shorter baseDN.
Is this a v4.2 related problem or a general ACS problem?
The point is that I need to find users in different OU's, which are based directly under the domain name, so that I need to search for them starting from "DC=Domain,DC=com". I know that with "Generic LDAP" I can make severeal "Databsae Configurations" to resolve the issue with the OU's. But not with a "RSA SecurID Token and LDAP Group Mapping" setup. There is only possible to have one LDAP group mapping configuration.
Any input would be greatly appreciated.

Hi
We invested a lot of time together with TAC and development. Short answer: No it's not solved. It was an ACS bug. But development didn't realy understand the problem. We went ahead and restructured the ADS.
The problem we had, is that a LDAP directory of a Windows is not fully accessible. Even if you connect as a Domain Administrator or to the Global Catalog. :-) And that's where the ACS fails. LDAP browsers just read over the unaccessible parts of a LDAP directory and show you all the accessible part. ACS doesn't. He stops and reports the failure. You can see that clearly when sniffing the access of the ACS and the LDAP browser to the directory. Unfortunately the unaccessible part is at the beginning of the ADS LDAP directory. :-(
Maybe they resolved the problem nowadays. Or if you have a Windows Guru who can help you in making the directory fully accessible I would be interessted in the How-To.
I wish you best luck with your issue.
Kind regards
Roberto

CSS keepalive TCP flags

CSS keepalive TCP flags
Hi. I have a problem with the way an application behaves in response to CSS tcp keepalives, I'd be grateful for any advice.
Using standard TCP keepalives, an application logs a broken connection for every keepalive, filling up the app logs, causing the administrators to complain. If I change the tcp-close type to FIN, the application doesn't log an error, but it still logs the connection, same complaint from the admins.
The application developers feel that it's not their problem, they're comparing the keepalives to nmap probes and indeed, it is possible to confirm that the service is up with nmap, without generating an error/connection log entry on the server.
According to some Wireshark captures, the TCP flags of a CSS keepalive, compared to an nmap probe, are as follows;
CSS
CSS --> Syn --> Server
CSS <-- Syn, Ack <-- Server
CSS --> Ack --> Server
CSS --> Rst, Ack --> Server
nmap -sS
NmapPC --> Syn --> Server
NmapPC <-- Syn, Ack <-- Server
NmapPC --> Rst --> Server
So, my question is, can the tcp behaviour of CSS keepalives be modified, to dispense with the arguably superfluous 'ack'ing that's illustrated above?
Thanks
Andy

Thanks for the replies.
I've tried tcp-close fin, it stops an error being logged, but the application still logs the connection.
I wouldn't be concerned, other than the fact it clearly is possible to both establish that the service is running on the server and not log the connection attempt, using Nmap's more abbreviated tcp behaviour.
I am curious, though. What is the CSS acknowledging when it sends an ACK in the RST packet?
Regards
Andy

ACS 4.2 - LDAP TCP Keepalive

Similar Messages

Maybe you are looking for