I currently have in place CS ACS Solution Engine v3.3.3 and the Remote Agent is installed on Windows Server 2003. I'm using a lab environment to test Authentication to network switches and routers using ACS as Radius with Windows A/D as the backend. I have had success with the authentication using the CiscoSecure DB but when I change it to Windows DB I get the follwing error in the log:
CSWinAgent 10/24/2005 14:42:34 A 0433 2004 RPC: NT_MSCHAPAuthenticateUser reply sent
CSWinAgent 10/24/2005 15:00:06 A 0254 3468 RPC: NT_ForAllNTTrustedDomains received
CSWinAgent 10/24/2005 15:00:06 A 0048 3468 NTLIB: Found 1 trusted domains
Basically we usually see this when the remote agent is installed on a member server and the user the services are running as does not have the correct privilege's set up.
Make sure that Domain Admin account has the "Act as part of Operating System" and "Logon as a Service" security Policy set. Normally no-one has this set, not even Administrator. You can add the policy for this username under the Local Security Policy menu, then under Local Policies - User Rights Policy.
Re: Windows A/D Authentication Failed (Error 1300L)
Looking into the CSWINAgent log file, I determined that the authentication request was being "forwarded" to a different Windows Server and failing. Talking to one of our Systems Admins, I determined that the Remote Agent was in fact installed on a Domain Controller, but its role might not provide the service needed to do the username query. Furthermore, he went on the explain that we have a number of DCs in our evnironment, but that they each act as different "roles." Apparently the Remote Agent is smart enough to recognize that the current DC in which the Remote Agent was installed on could not perform the task requested and looked for the DC that could (the log file gave me the name of the DC that could). The Systems Admin stated that the DC that the log file was pointing to was the "PDC emulator" in our native envirnoment. So in short, I installed it on the suspected DC and everything works great. I did have to that the Domain Admin to the security Policy that you stated. I have been doing 802.1X machine and user auth ever since without issue. Thanks for your help.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...