Quantcast
Channel: All Centrify Express posts
Viewing all articles
Browse latest Browse all 1833

Re: Error when user attempting to change their own password

$
0
0

,

 

Welcome to the Centrify community!

 

Remember that as a new member of the Centrify family you have access to the Centrify Support Center, this allows you to open cases, (24x7 or business hours), search the knowledgebase, download center and documentation.

Let us know if you don't have access and we can arrange that via your reps.

 

Assuming that you ruled-out the password's length, complexity, expiration and history as well as the minimum password age you should be able to change the password using the passwd command.

 

Other things that need to be ruled out are the following:

  • Do you have a 3rd party Identity Management solution that performs sync?
  • Do you have any 3rd party software that is used for things like Self-service password reset?
  • Are you connected to a Read-only domain controller? 
    Sometimes we have customers deployed in untrusted or DMZ environments.

Sometimes these factors can casuse issues changing passwords.

 

If you rule that out, here are some options:

  • open a ticket > our tech support will be happy to help.  [Like we used to say in a previous life.  Once you buy the car, the relationship is with the dealership, not the manufacturer]
  • try to change the password to a really complex one  (let's double the characters from 7 to 14 and add additional numbers and special characters); this is just to test that we are not reusing a password or pattern.  Tip: by default the last 24 passwords are remembered.
  • review the debug log.
    This requires that you open two sessions to a system

    - in the first session, run these commands
# note, you can sub dzdo for sudo

dzdo /usr/share/centrifydc/bin/addebug clear
# this clears the log
dzdo /usr/share/centrifydc/bin/addebug on
# this starts debug logging

#inspect the log dzdo tail -f /var/log/centrifydc.log

    - in the second session, you will try to change the password

$ passwd
Changing password for user <username>
Changing AD password for <username>
(current) password: 

# and so on until you reproduce the issue.

 

In the log, what you're looking for are the transactions called "PAMChangePassword"
- for example, this is a failure due to a reused password:

 

Change password result: return code = 0 , result code = 4 Password change rejected
Jul  6 12:17:37 engcen6 adclient[21689]: DEBUG <fd:25 PAMChangePassword > base.osutil Module=Base : password policy not matched (reference base/krb5keytab.cpp:1095 rc: 1013)
Jul  6 12:17:37 engcen6 adclient[21689]: WARN  <fd:25 PAMChangePassword > daemon.ipcclient2 Unable to change password for user '[username]': password policy not matched
Jul  6 12:17:37 engcen6 adclient[21689]: DEBUG <main> util.threadpool Pool size 3/4, busy size 1/20
Jul  6 12:17:37 engcen6 adclient[21689]: WARN  <fd:27 passwd(12664)> Change password for user 'dwirth': Password policy violation. Refusing to change password
Jul  6 12:17:37 engcen6 adclient[21689]: DEBUG <main> util.threadpool Pool size 3/4, busy size 1/20
Jul  6 12:17:37 engcen6 adclient[21689]: DEBUG <fd:27 passwd(12664)> Error message to user: 'The password change operation failed due to a policy restriction set by the#012Active Directory administrator. This may be due to the new password length,#012lack of complexity or a minimum age for the current password.'
Jul  6 12:17:37 engcen6 adclient[21689]: DEBUG <main> util.threadpool Pool size 3/4, busy size 1/20
Jul  6 12:17:37 engcen6 adclient[21689]: DEBUG <fd:27 passwd(12664)> PAMDisplayUserMessage returning PAM_SUCCESS(0)
Jul  6 12:17:37 engcen6 adclient[21689]: DEBUG <main> util.threadpool Pool size 3/4, busy size 1/20
Jul  6 12:17:37 engcen6 adclient[21689]: DEBUG <fd:27 passwd(12664)> Sending PAM audit trail event without DA_SESSION_ID_AUTH

-  A success looks like this with some other things added afterwards:

PAMChangePassword > base.kerberos.keytab Change password result: return code = 0 , result code = 0

Once you're done, in the first session, make sure you stop debugging.

dzdo /usr/share/centrifydc/bin/addebug off

 

There are other tools that we can do like a network trace as well, but this should be good for now.  There are also events in the Windows event log of DCs that can be traced like Security event IDs 4738 and 4723

event.png 

I hope this helps and welcome to Centrify.

 

R.P

 


Viewing all articles
Browse latest Browse all 1833

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>