ACS 3.3 and W2K Security Update Rollup 1 for Service Pack 4

[anthonyhoar]

After applying the security update rollup 1 for Service Pack 4 of Windows 2000 Server, our ACS would no longer allow authentication of our VPN or RAS clients via the Windows AD external Database. Users from the ACS database worked as expected.

The Failed Attempts log reported the following:

External DB reports error condition.

The security rollup somehow kept ACS from checking in with AD.

I'm currently hitting the logs...curious if anyone else has encountered this issue.

[mchin345]

I think the issue is due to when the SafeWord Token Server is restarted, CiscoSecure ACS does not automatically reconnect to the SafeWord server for authentication. The Failed Attempts report displays the message External DB reports error condition. The workaround is to restart the CSAuth and CSTacacs services

[anthonyhoar]

Restarting services does not affect it. There is something going on between ACS and that Security Update Rollup 1 for Service Pack 4 from Microsoft.

Cisco has told me that ACS is JAVA based and it only talks in and out of itslef via TCP and UDP ports. Cisco at first, thought some ports were being shut off. Windows 2000 doesn't have a firewall so I can't see that as being the case. Perhaps its something on a COM level.

I have submitted a TAC Case to Cisco. They tell me that there is another customer who is also having this issue and they are currently working with Microsoft.

In any case, the problem is reproducible and eventually Microsoft and Cisco are going to have to get together on this.

Is there anyone out there who has ACS (external authentication to Windows) running on Win2K Server with Service Pack 4 and the Security Rollup 1 applied?

If so, is your ext_NT authentication working? Just curious.

[darpotter]

The message from the TAC was correct... internally the various ACS services use TCP/IP to communicate.

The failed attempts message is a generic one, the *actual* error will be the auth.log file.

You'll need to set logging to max (this will generate MBs of logs) and look in auth.log at the time ofthe failure.

You should see lots of "External DB [NTAuthenDLL]" messages including the actual return codes from Windows. eg 1326L for bad username/password.

Its most likely the MSFT patch some how side affects the win32 api's that ACS uses for authentication.

..or perhaps messes with the permissions that the server has within the domain.

Darran

[anthonyhoar]

(1326L) is the error in the AUTH log at the time of failure.

Cisco thought maybe the Msft patch forced our servers to use NTLM V2 authentication.

We have several Domain controllers all with the patch installed and none are using NTLM V2. I have been all over Group Policies looking for one Security Policy that would suggest the patch changed the authentication type but its just not the case.

Your assessment on the situation is great however its going to require Cisco and Msft to come to some sort of terms on this issue.

[darpotter]

As of 3.3 there is no specific support for Safeword. Not in the old sense.

Before we used a safeword supplied DLL for authentication. This was dropped in favour of using generic RADIUS.

So 3.3 uses connectionless RADIUS to perform Safeword authentication via the "RADIUS Token Server" authenticator.

Darran