cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3720
Views
0
Helpful
12
Replies

ACS authentication to Win2K

Does the ACS services actually need to use the domain administrator account or an account with admin privliges?

I can get ACS to authenticate with the local user database on the member server but can't seem to get it to authenticate to the domain. Using a user form the ACS database works fine as well.

12 Replies 12

giadmu
Level 1
Level 1

Hi Anthony

It seems that we have the same problem. I don't have a solution till now. But please have a look at the csauth log file. You find the csauth log file under x:\Program Files\CiscoSecure ACS v3.0\CSAuth\Logs. I have there some logs like:

*******************************************************************************

AUTH 06/04/2002 11:08:12 E 0266 1688 External DB [NTAuthenDLL.dll]: RasAdminUserGetInfo returned error 0x5

AUTH 06/04/2002 11:08:12 E 0266 1688 External DB [NTAuthenDLL.dll]: Failed to get RAS information for user giadmu

*******************************************************************************

Do you have this logs also?

Actually I went through my logs and found this.

*****************************************************************************

AUTH 06/03/2002 13:11:51 I 0266 2012 External DB [NTAuthenDLL.dll]: Starting authentication for user [anthonyc]

AUTH 06/03/2002 13:11:51 I 0266 2012 External DB [NTAuthenDLL.dll]: Attempting NT/2000 authentication

AUTH 06/03/2002 13:11:51 I 0266 2012 External DB [NTAuthenDLL.dll]: NT/2000 authentication SUCCESSFUL (by GNBDC02)

AUTH 06/03/2002 13:11:51 I 0266 2012 External DB [NTAuthenDLL.dll]: Obtaining RAS information for user anthonyc from GNBDC02

AUTH 06/03/2002 13:11:51 E 0266 2012 External DB [NTAuthenDLL.dll]: RasAdminUserGetInfo returned error 0x5

AUTH 06/03/2002 13:11:51 E 0266 2012 External DB [NTAuthenDLL.dll]: Failed to get RAS information for user anthonyc from GNBDC02

AUTH 06/03/2002 13:11:51 I 1311 2012 Unknown User 'anthonyc' was not authenticated

*******************************************************************************

So my userid is getting authenticated but can't get the RAS info. My account is setup for dial-in. Not sure what is going on but at least this helps.

So - We have the same error. I have still open a TAC Case (C730737) about this problem. I will send you the whole Case content. Perhaps it will help you:

Problem Description: Situation:

We have a ACS Server to authenticate the RAS Users.

I configured the ACS to authenticate unknown users by the 'Windows NT/2000' Database (Unknown User Policy). The ACS is a member server in a Windows 2000 Domain called 'giaintra.net'. The Users are in a Windows NT Domain called 'MM'. There is a two way trust between this domains.

I configured the 'Windows NT/2000 User Database' in the ACS to verify the 'Grant dialin permission' setting and also configure the Domain List with all needed domains (MM, giaintra.net).

Problem:

The authentication allways fails for user that are not in the ACS database. In the 'Failed Attempts' Log the Authentication Failure Code is 'Unknown'

investigations:

I capture the network traffic from and to the ACS Server and see, that there is no traffic to any Domaincontroller. So I turn the ACS logging to the maximum and check the csauth service log file for any debug messages beginning with [External DB]. The following messages were logged:

****************************************************************

AUTH 05/23/2002 15:56:30 I 4562 1676 Attempting authentication for Unknown User 'MM\giadmu'

AUTH 05/23/2002 15:56:30 I 0266 1676 External DB [NTAuthenDLL.dll]: Starting authentication for user [MM\giadmu]

AUTH 05/23/2002 15:56:30 I 0266 1676 External DB [NTAuthenDLL.dll]: Attempting NT/2000 authentication

AUTH 05/23/2002 15:56:30 E 0266 1676 External DB [NTAuthenDLL.dll]: NT/2000 authentication FAILED (error 1300L)

AUTH 05/23/2002 15:56:30 I 1311 1676 Unknown User 'MM\giadmu' was not authenticated

****************************************************************

Please contact customer via email: daniel.mueller@gia.ch

Email: daniel.mueller@gia.ch

Phone: 41-62-789-71-71

Urls shown to the user :

http://www.cisco.com/warp/public/cc/pd/sqsw/sq/prodlit/exatu_wp.htm

http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/csacs4nt/csnt26/usergd26/userdb.htm

http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/csacs4nt/csnt26/usergd26/unknown.htm

http://www.cisco.com/warp/public/cc/pd/sqsw/sq/prodlit/ldcsa_wp.htm

http://www.cisco.com/warp/customer/480/csntsdi.html

*** NOTES LOG 23-MAY-2002 07:58:54 PST, ciscodotcom, Action Type: Action ***

Notes logged DANIEL MUELLER (giadmu) daniel.mueller@gia.ch

CC list updated by DANIEL MUELLER (giadmu) daniel.mueller@gia.ch:

OLD:

NEW: giaaaj@gia.ch,

*** EMAIL OUT 23-MAY-2002 08:25:03 PST, kpintus, Action Type: Email Out ***

Send to: [daniel.mueller@gia.ch]

Daniel,

Good afternoon. My name is Kirk with Cisco Systems and I will be assisting you with this case.

It sounds to me like the problem is that ACS is installed on a Member Server. If this was installed on a Domain Controller you probably wouldnt have this issue. If you follow the instructions below, it should fix the problem. The 1300L error you are getting is defined here:

Code Name Description -------1300L ERROR_NOT_ALL_ASSIGNED

Indicates not all privileges referenced are assigned to the caller. This allows, for example, all privileges to be disabled without having to know exactly which privileges are assigned.

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q155012

Try these instructions below and let me know how that goes and if I can be of further assistance.

*****************************************************************************

First ensure that any trusts that will be followed are 2-way.

One-way trusts are problematic for ACS.

- On the domain controller serving the ACS server:

-- Create a user

-- Make the user a member of Domain Admins group.

-- Make the user a member of Administrators group.

- Log onto ACS server.

-- Add the domain user to the local Administrators group.

-- Assign special rights with following instructions:

-- If ACS server is NT:

--- Run the User Manager program.

--- Choose "User Rights" from the "Policies" menu.

--- Check "Show Advanced User Rights."

--- Find "Act as part of the operating system" in the list.

--- Click "Add."

--- Choose the domain from the "List Names From" box.

--- Click "Show Users."

--- Double-click the user created earlier to add it.

--- Click OK.

--- Find "Log on as a Service" in the list.

--- Click "Add."

--- Choose the domain from the "List Names From" box.

--- Click "Show Users."

--- Double-click the user created earlier to add it.

--- Click OK.

-- If ACS server is Windows 2000:

--- Open "Administrative Tools" from the control panel.

--- Open "Local Security Policy."

--- Open "Local Policies."

--- Open "User Rights Assignment."

--- Double-click on "Act as part of the operating system."

--- Click "Add."

--- Choose the domain from the "Look in" box.

--- Double-click the user created earlier to add it.

--- Click OK.

--- Double-click on "Log on as a service."

--- Click "Add."

--- Choose the domain from the "Look in" box.

--- Double-click the user created earlier to add it.

--- Click OK.

- Set the ACS services to run as the created user.

-- If ACS server is NT:

--- Open "Services" from the control panel.

--- Click the CSADMIN entry once.

--- Click "Startup."

--- Click "This Account" and then the "..." button.

--- Choose the domain, double-click the user created earlier.

--- Click "Add," then "OK," then "OK" again.

--- Repeat for the rest of the CS services.

--- Stop and then start CSADMIN.

-- If ACS server is Windows 2000:

--- Open "Services" from "Administrative Tools."

--- Double-click the CSADMIN entry.

--- Click the "Log On" tab.

--- Click "This Account" and then the "Browse" button.

--- Choose the domain, double-click the user created earlier.

--- Click "OK."

--- Repeat for the rest of the CS services.

--- Stop and then start CSADMIN.

- Open the ACS GUI.

- Click on System Config.

- Click on Service Control.

- Click "Restart."

Thanks,

Kirk Pintus

Tech Support

SLC TAC-Security

Cisco Systems Inc.

M-F 7-3:00pm MST

801-736-3939 x55455

kpintus@cisco.com <>kpintus@cisco.com>

*** STATUS CHANGE 23-MAY-2002 08:25:03 PST, kpintus, Action Type: ***

*** NOTES LOG 24-MAY-2002 10:09:18 PST, kpintus, Action Type: Action ***

email from customer:

Hi Kirk

I implemented the task you described below and now I can logon with the

accounts from the Domain 'MM'. But I still can't logon with a account in the

Domain 'giaintra.net'. The debug messages in the csauth Logfile is:

**************************************

AUTH 05/24/2002 09:19:59 I 4562 1684 Attempting authentication for Unknown

User 'GIAINTRA.NET\giadmu'

AUTH 05/24/2002 09:19:59 I 0266 1684 External DB [NTAuthenDLL.dll]: Starting

authentication for user [GIAINTRA.NET\giadmu]

AUTH 05/24/2002 09:19:59 I 0266 1684 External DB [NTAuthenDLL.dll]:

Attempting NT/2000 authentication

AUTH 05/24/2002 09:19:59 I 0266 1684 External DB [NTAuthenDLL.dll]: NT/2000

authentication SUCCESSFUL (by GIAT056)

AUTH 05/24/2002 09:19:59 E 0266 1684 External DB [NTAuthenDLL.dll]: Local

account domain fallback not permitted

AUTH 05/24/2002 09:19:59 I 1311 1684 Unknown User 'GIAINTRA.NET\giadmu' was

not authenticated

**************************************

Do you have any idea about that?

Regards,

Dani

*** STATUS CHANGE 24-MAY-2002 10:09:19 PST, kpintus, Action Type: ***

*** EMAIL OUT 24-MAY-2002 10:35:19 PST, kpintus, Action Type: Email Out ***

Send to: [daniel.mueller@gia.ch]

Hi Daniel,

From the debugs it looks possibily like a permission issue. Which domain did you create the user on from the instructions before? You will need to create the user on the domain the ACS box is in. If that does not work for you, maybe try turning on security auditing/failure auditing for everything on the domain controller and send me the results from that.

Lets try that and see what happens. I will go over this with the team lead as well, and see what he thinks about this issue.

Cheers,

Kirk

*** NOTES LOG 28-MAY-2002 08:46:30 PST, kpintus, Action Type: Action ***

Hi Kirk

The user accounts were migrated from the 'MM' domain (Win NT) to the

'giaintra.net' domain (Win2000). To test the functionality of the acs I have

two user accounts:

- 'giadmu' in the Win NT domain MM

- 'giadmu' in the new Win2000 Domain ' giaintra.net' (this is the migrated

user from the MM Domain)

The acs is a windows 2000 member server in the 'giaintra.net' domain. I can

not install the acs on a domaincontroller, because of our internal security

regulations.

For the user account in the MM Domain all works properly after I implemented

your instructions. But for the user account in the 'giaintra.net' domain the

authentication still fails. First I try to logon with 'giaintra.net\giadmu'

(dot net extension for the domain). In this case the csauth services logs

the following:

****************************************************************************

*************************

AUTH 05/27/2002 10:22:04 I 4562 1752 Attempting authentication for Unknown

User 'GIAINTRA.NET\giadmu'

AUTH 05/27/2002 10:22:04 I 0266 1752 External DB [NTAuthenDLL.dll]: Starting

authentication for user [GIAINTRA.NET\giadmu]

AUTH 05/27/2002 10:22:04 I 0266 1752 External DB [NTAuthenDLL.dll]:

Attempting NT/2000 authentication

AUTH 05/27/2002 10:22:04 I 0266 1752 External DB [NTAuthenDLL.dll]: NT/2000

authentication SUCCESSFUL (by GIAT057)

AUTH 05/27/2002 10:22:04 E 0266 1752 External DB [NTAuthenDLL.dll]: Local

account domain fallback not permitted

AUTH 05/27/2002 10:22:04 I 1311 1752 Unknown User 'GIAINTRA.NET\giadmu' was

not authenticated

****************************************************************************

*************************

Then I try to logon with giaintra\giadmu and the csauth service logs this:

****************************************************************************

*************************

AUTH 05/27/2002 10:19:07 I 4562 1776 Attempting authentication for Unknown

User 'GIAINTRA\giadmu'

AUTH 05/27/2002 10:19:07 I 1172 1776 ReadSupplierRegistry: Windows NT/2000

loaded

AUTH 05/27/2002 10:19:07 I 0266 1776 External DB [NTAuthenDLL.dll]: Starting

authentication for user [GIAINTRA\giadmu]

AUTH 05/27/2002 10:19:07 I 0266 1776 External DB [NTAuthenDLL.dll]:

Attempting NT/2000 authentication

AUTH 05/27/2002 10:19:07 I 0266 1776 External DB [NTAuthenDLL.dll]: NT/2000

authentication SUCCESSFUL (by GIAT057)

AUTH 05/27/2002 10:19:07 I 0266 1776 External DB [NTAuthenDLL.dll]:

Obtaining RAS information for user giadmu from GIAT057

AUTH 05/27/2002 10:19:07 E 0266 1776 External DB [NTAuthenDLL.dll]:

RasAdminUserGetInfo returned error 0x5

AUTH 05/27/2002 10:19:07 E 0266 1776 External DB [NTAuthenDLL.dll]: Failed

to get RAS information for user giadmu from GIAT057

AUTH 05/27/2002 10:19:07 I 1311 1776 Unknown User 'GIAINTRA\giadmu' was not

authenticated

****************************************************************************

*************************

I also turn on auditing for

- account logon events

- account management

- object access

on the domaincontroller of the 'giaintra.net' domain. But in the event

viewer I just see, that the account logon from the acs server was

succesfully. The following message appears in the event viewer:

****************************************************************************

*************************

Account Used for Logon by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

Account Name:

giadmu

Workstation:

CISCO

****************************************************************************

*************************

regards

Dani

*** NOTES LOG 03-JUN-2002 10:04:22 PST, kpintus, Action Type: Action ***

Hi Kirk

As I told you in a mail before the csauth log file log the following

message:

RasAdminUserGetInfo returned error 0x5

The error code 0x5 is the code for a 'permission denied' error.

See the ErrorText.exe in the LS-Tool Collection on <http://www.losoft.de/>

I also search for the API Call 'RasAdminUserGetInfo' and found the following

article.

<http://msdn.microsoft.com/library/en-us/rras/rasadm_5e9b.asp>

There is a remark, that the 'RasAdminUserGetInfo' function is replaced by

the 'MprAdminUserGetInfo' function in Windows 2000. Is it possible, that the

'Grant Dialin setting' can't work because the acs server call a old API

function? In this case the acs 3.0 can't work in a Windows 2000 environment

(puh - big bug).

In further I make some tests with different combinations of Registry Key and

the 'Grant Dialin Perm' setting:

RegKey dialinPerm MM\giadmu (Win NT) GIAINTRA\giadmu

(W2K)

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

1 not set ok nok

1 set ok nok

0 not set ok ok

0 set ok nok

For the 'GIAINTRA\giadmu' account the last case is against your statement in

the mail before (If you set it to 0 then you can check Grant dial in perms).

I set the registry key to 0 and check the 'Grant Dialin Permission' but

can't logon with the Win2000 account GIAINTRA\giadmu.

On the W2K Domaincontroller (GIAT057) I audit 'logon events'. Allways when I

would logon with the GIAINTRA\giadmu account the Domaincontroller log the

following three events:

*********************************************************************

Event Type: Success Audit

Event Source: Security

Event Category: Account Logon

Event ID: 680

Date: 31.05.2002

Time: 18:11:33

User: NT AUTHORITY\SYSTEM

Computer: GIAT057

Description:

Account Used for Logon by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

Account Name:

giadmu

Workstation:

CISCO

*********************************************************************

Event Type: Failure Audit

Event Source: Security

Event Category: Directory Service Access

Event ID: 565

Date: 31.05.2002

Time: 18:11:33

User: NT AUTHORITY\ANONYMOUS LOGON

Computer: GIAT057

Description:

Object Open:

Object Server: Security Account Manager

Object Type: SAM_SERVER

Object Name: CN=Server,CN=System

New Handle ID: -

Operation ID: {0,125580714}

Process ID: 304

Primary User Name: GIAT057$

Primary Domain: GIAINTRA

Primary Logon ID: (0x0,0x3E7)

Client User Name: ANONYMOUS LOGON

Client Domain: NT AUTHORITY

Client Logon ID: (0x0,0x77C35A2)

Accesses MAX_ALLOWED

Privileges -

Properties:

**********************************************************************

Event Type: Failure Audit

Event Source: Security

Event Category: Directory Service Access

Event ID: 565

Date: 31.05.2002

Time: 18:11:33

User: NT AUTHORITY\ANONYMOUS LOGON

Computer: GIAT057

Description:

Object Open:

Object Server: Security Account Manager

Object Type: SAM_SERVER

Object Name: CN=Server,CN=System

New Handle ID: -

Operation ID: {0,125580717}

Process ID: 304

Primary User Name: GIAT057$

Primary Domain: GIAINTRA

Primary Logon ID: (0x0,0x3E7)

Client User Name: ANONYMOUS LOGON

Client Domain: NT AUTHORITY

Client Logon ID: (0x0,0x77C35A2)

Accesses MAX_ALLOWED

Privileges -

Properties:

*********************************************************************

The first event is a successfull message, but the following two events are

failure messages (anonymous logon)?! Hope you can help me?

regards

Dani

Hi Anthony

I found a solution for our problem. I take the everyone group to the "Pre-Windows 2000 Compatible Access" group. But I have to do this with a shell command because the everyone group isn't present in the gui:

net localgroup "Pre-Windows 2000 Compatible Access" everyone /add

After that the Everyone group was present in the Builtin group "Pre-Windows 2000 Compatible Access" and the login procedure works well.

Daniel,

This may work but opens up some security concerns with granting Everyone into this group. Please see below.

########################################################

Backwards Compatibility

When a Win 2000 machine is promoted to a domain controller, the Active Directory Installation Wizard (dcpromo.exe) asks several questions about the directory configuration. One of those questions is whether security should be relaxed on directory objects to permit access from downlevel systems like NT4 RAS servers and SQL machines. If you choose to relax security, the Everyone identity is added to the Pre-Windows 2000 Compatible Access group. Pre-Windows 2000 Compatible Access has read permissions on many critical directory objects, including the Users and Groups containers. Thus, by selecting legacy security, Everyone has permissions to enumerate user accounts and group names on the domain. You can alleviate this situation by removing Everyone from the Pre-Windows 2000 Compatible Access group like so:

net localgroup "Pre-Windows 2000 Compatible Access" everyone /delete

Remember that this will affect downlevel client access to certain directory objects. Thus, it's best to try and migrate NT4 RAS and SQL systems to Win 2000 first.

Pre-Windows 2000 Compatible Access

One of the well-known security principals is Pre-Windows 2000 Compatible Access. By default, this group has permissions for most of the objects in a domain.

The member list of Pre-Windows 2000 Compatible Access was determined when you installed Active Directory to create a new domain and chose the option for Permission.

• If you selected “Permissions compatible with pre-Windows 2000 servers,” Everyone will be a member.

• If you selected “Permissions compatible with only Windows 2000 servers,” there will be no members.

Remember that Everyone includes all authenticated and anonymous users.

If you want to change the choice you made at the time of installation, you can use one of the following commands (deletion is possible also with the Users and Computers snap-in):

NET LOCALGROUP “Pre-Windows 2000 Compatible Access” Everyone /ADD

NET LOCALGROUP “Pre-Windows 2000 Compatible Access” Everyone /DELETE

Security Principal Permissions Apply To

Administrators Full Control except Delete All Child Objects and Delete Subtree

Enterprise Admins Full Control

Pre-Windows 2000 Compatible Access List Contents

Pre-Windows 2000 Compatible Access Read Remote Access Information User

Pre-Windows 2000 Compatible Access Read General Information User

Pre-Windows 2000 Compatible Access Read Group Membership User

Pre-Windows 2000 Compatible Access Read Account Restrictions User

Pre-Windows 2000 Compatible Access Read Logon Information User

Pre-Windows 2000 Compatible Access Read, List Object Group

Pre-Windows 2000 Compatible Access Read, List Object User

########################################################

I am just thinking if you were concerned about putting ACS on a DC that this may also be an issue.

sconnolly
Level 1
Level 1

I was wondering if you were able to resolve this problem? I am also getting the "RasAdminUserGetInfo returned error 0x5" error. I am running ACS 3.0 on a win 2K member server. I have configured an administrative account that the services run as.

I am able to authenticate to a local user on the server, but I am not able to authenticate to an account in the AD.

I saw the previous post about adding everyone to the Pre-Windows 2000 Compatible Access group, but I don't think our server guys want to do this.

Thanks.

Still having the same problem. Since this was and still is only in testing I set up the local ACS database for authentication.

damerino
Level 1
Level 1

I too have the same exact problem when my client migrated to a homogenous Windows 2000 platform. We were forced to use the Pre-Windows 2000 Compatability work around. However, the client understands the extreme security risk and is very disappointed that Cisco hasn't released a patch to correct this problem. It's incorrect to state that the product is completely compatible with win2k domain controllers.

Did any of you guys find a solution for this problem yet?

This problem renders the NT domian functionality unusable. further more? why did this work on ACS 2.6 and most important how? any ideas?

Yesterday I upgrade my ACS to the version 3.1. In this Release you don't have to add the group 'everyone' to the Built-in group "Pre Windows 2000 Compatible Access". It seems that the ACS integration with Windows 2000 AD works fine with Version ACS Release 3.1!

grshaw
Level 1
Level 1

I had a similar issue with 3.0 and 3.1. I resolved this by disabling the "require kerberos pre-authentication" option under the user setup.