Video Screencast Help

If you get a logon failure: unknown user or bad password error running AuditExpress in SecurityExpressions

Created: 04 Jun 2009
Language Translations
breas's picture
0 0 Votes
Login to vote

This is actually called the 1326 error if we want to get technically correct. The 1326 error is a Microsoft error. In this case, the credentials being used were a local account, not a domain account. SecurityExpressions assumes domain credentials unless the local account is specified. To specify the local credentials, use the system name or IP before the username when entering the credentials.

For example, if the username is jsmith and the system is testsystem then to use the local account the credentials would be entered as testsystem\jsmith.

Getting access denied when I run a UNIX policy file

First, SecurityExpressions will not automatically change anything on the target system—you must select the "fix" function to change a setting.

You do not have to change the group—you should be using the AuditOnlyGroup so that you can run scripts on UNIX systems. The group used has nothing to do with permissions on directories or files.

What happens is the agent software must be installed on the UNIX system by root so that it can run with privilege. The user you supply to the agent when you run an audit is only authenticated by the agent as the credentials that can run an audit. These credentials are not used to run the audit. If the authentication passes the agent, that had been installed with privilege, runs the audit and reports back the results.

If you are getting access denied when you run an audit, changing the group will not change the access denied results. It's suspected that the agent software was not installed correctly, so it does not have the necessary privileges to run the audit. This is the design of the agent, so in order for it to function correctly, it must be installed correctly.

Using AuditExpress behind an Internet Proxy

If you’reconfiguring Internet Explorer settings does not solve the problem, for now the only workaround with the proxy is to install AuditExpress outside the proxy and point this to the same database the AuditExpress that is inside the proxy is using so the outside system can get the updates and put them in the database. If both installs use the same database, then the inside console will see the updates.
There are no scripts for AuditExpress nor are there any configuration settings in the product that will allow it to update through the proxy.

Article Filed Under: