Users unable to login the website, and as per smaccess logs are getting AuthReject error for users on SM policy server with below error message, Please advice to fix this issue.
*AuthReject ServeroneSM1 43 -0600] "10.53.170.31 CN=user2 ,OU=Non-Employees,OU=Users,OU=Normaluser,OU=US,OU=NA,OU=Test,OU=Users and Workstations,DC=SMUSER,DC=Net" "sm.in.com GET /index.jsp"   8009030C: LdapErr: DSID-0C09056D, comment: AcceptSecurityContext error, data 52e, v2580  
Please advice to fix this issue.
Hello Rajkumar :
This error in general is due configuration
1) LDAP search failing due config error on User Directory to find and match the user credentials. (AD does not match creds with Policy server USer Directory or You application User Directory)please,confirm if users password are the same as AD's user's password. Else, try to point the User Directory to the AD directory.
2) It can be due Invalid credentials results from a persistent connection to the user directory.
a. https://comm.support.ca.com/kb/ldap-error-code-49-with-microsoft-active-directory/kb000054575b. to discard a persistent connection to the user directory..Please restart Siteminder Policy Server after making changes to the authentication credentials of the User Directory.This will force all the connections to close and on restart Siteminder will establish new ones.
3) If problem continues, using an ldapsearch OR some other ldap tool, that we are able to bind using the new credentials (in case you changed the password using JXplorer). This at the least would confirm if user.changePassword method was successful or not.
thanks for your comments or results
One more additional piece that I'd check is the login page, are we using any custom login page and making sure the login page is submitting the correct credentials.
It does state AuthReject, which means AuthAttempt i.e. User Look Up worked - which means the directory connection and directory credentials defined within the user directory object looks to be correct.
AuthReject would happen on invalid password OR account has been disabled OR any password policies firing after successful authentication. So I'd also look at those conditions.
The best way is to enabled SMTRACEDEFAULT.log and investigate what the trace logs state. The smaccess.log is a audit log and hence is a one liner.