You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@syncope.apache.org by "justin.isenhour" <ju...@compass-usa.com> on 2017/12/20 13:45:32 UTC

Reset Password Not Resetting Must Change Password Flag

I am currently running v2.0.6 and have recently noticed that if we toggle on
the Must Change Password flag then go through the Password Reset process we
are seeing the password changed and is syncing with the ldap connector but I
do not see the Must Change Password flag getting reset back to false, it
remains true.  I recently upgraded from 2.0.4 to 2.0.6, I cannot be certain
but I believe this was working before.  Any areas I should look at
specifically for troubleshooting this?

Thanks,
Justin Isenhour

--
Sent from: http://syncope-user.1051894.n5.nabble.com/

Re: Reset Password Not Resetting Must Change Password Flag

Posted by Francesco Chicchiriccò <il...@apache.org>.
On 22/12/2017 00:10, justin.isenhour wrote:
> I checked the core-connid logs, it looks like at the time that the update is
> trigger the value is still set to true.
>
> Internal Attribute:  mustChangePassword
> External Attribute: pwdReset
> JXEL:  mustChangePassword == 1

After SYNCOPE-1249 [1], mustChangePassword (along with several other 
User, Group and Any Object's fields) shall be "naturally" mapped, hence 
no need for the JEXL above.

HTH
Regards.

[1] https://issues.apache.org/jira/browse/SYNCOPE-1249

-- 
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/


Re: Reset Password Not Resetting Must Change Password Flag

Posted by "justin.isenhour" <ju...@compass-usa.com>.
I checked the core-connid logs, it looks like at the time that the update is
trigger the value is still set to true.  

Internal Attribute:  mustChangePassword 
External Attribute: pwdReset
JXEL:  mustChangePassword == 1


17:56:42.080 DEBUG Enter: search(ObjectClass: __ACCOUNT__, EQUALS:
Attribute: {Name=aaimsKey, Value=[cc5567cb-2bf9-4e48-9567-cb2bf96e48c6]},
org.apache.syncope.core.provisioning.java.AsyncConnectorFacade$1@3d12b3c6,
OperationOptions:
{ATTRS_TO_GET:[aaimsKey,__PASSWORD__,mail,givenName,cn,__UID__,title,__ENABLE__,o,uid...]})       
Method: search
17:56:42.081 DEBUG Enter: executeQuery(ObjectClass: __ACCOUNT__,
LdapFilter[nativeFilter: (aaimsKey=cc5567cb-2bf9-4e48-9567-cb2bf96e48c6);
entryDN: null],
org.identityconnectors.framework.impl.api.local.operations.SearchImpl$1@50738e95,
OperationOptions:
{ATTRS_TO_GET:[aaimsKey,__PASSWORD__,mail,givenName,cn,__UID__,title,__ENABLE__,o,uid...]})  
Method: executeQuery
17:56:42.082 WARN  Reading passwords not supported      Method:
getAttributesToGet
17:56:42.082 WARN  Attribute __ENABLE__ of object class __ACCOUNT__ is not
mapped to an LDAP attribute  Method: getLdapAttribute
17:56:42.082 DEBUG Searching in
[ou=CommitedMembers,ou=people,dc=foodbuy,dc=com] with filter
(&(objectClass=foodbuyMemberAccount)(aaimsKey=cc5567cb-2bf9-4e48-9567-cb2bf96e48c6))
and SearchControls: {returningAttributes=[aaimsKey, cn, givenName, mail,
middleName, o, organizationDescription, organizationSourceSystemId,
pwdReset, sn, status, title, uid, userPassword], scope=SUBTREE}    Method:
doSearch
17:56:42.088 WARN  Attribute __ENABLE__ of object class __ACCOUNT__ is not
mapped to an LDAP attribute  Method: getLdapAttribute
17:56:42.088 DEBUG Enter: {Uid=Attribute: {Name=__UID__,
Value=[user20@place.com]}, ObjectClass=ObjectClass: __ACCOUNT__,
Attributes=[Attribute: {Name=__PASSWORD__,
Value=[org.identityconnectors.common.security.GuardedString@204e249b]},
Attribute: {Name=aaimsKey, Value=[cc5567cb-2bf9-4e48-9567-cb2bf96e48c6]},
Attribute: {Name=cn, Value=[20, user]}, Attribute:
{Name=organizationDescription, Value=[HMSHost]}, Attribute: {Name=__UID__,
Value=[user20@place.com]}, Attribute: {Name=__ENABLE__, Value=[]},
Attribute: {Name=o, Value=[SEC-2013-00090]}, Attribute: {Name=uid,
Value=[user20@place.com]}, Attribute: {Name=status, Value=[active]},
Attribute: {Name=middleName, Value=[]}, Attribute: {Name=mail,
Value=[user20@place.com]}, Attribute: {Name=organizationSourceSystemId,
Value=[5000]}, Attribute: {Name=__NAME__,
Value=[aaimsKey=cc5567cb-2bf9-4e48-9567-cb2bf96e48c6,ou=CommitedMembers,ou=people,dc=foodbuy,dc=com]},
Attribute: {Name=title, Value=[tester]}, Attribute: {Name=pwdReset,
Value=[true]}, Attribute: {Name=sn, Value=[20]}, Attribute: {Name=givenName,
Value=[user]}], Name=Attribute: {Name=__NAME__,
Value=[aaimsKey=cc5567cb-2bf9-4e48-9567-cb2bf96e48c6,ou=CommitedMembers,ou=people,dc=foodbuy,dc=com]}}      
Method: handle
17:56:42.089 DEBUG Return: true Method: handle
17:56:42.089 DEBUG Enter: {Uid=Attribute: {Name=__UID__,
Value=[user20@place.com]}, ObjectClass=ObjectClass: __ACCOUNT__,
Attributes=[Attribute: {Name=__PASSWORD__,
Value=[org.identityconnectors.common.security.GuardedString@204e249b]},
Attribute: {Name=aaimsKey, Value=[cc5567cb-2bf9-4e48-9567-cb2bf96e48c6]},
Attribute: {Name=cn, Value=[20, user]}, Attribute:
{Name=organizationDescription, Value=[HMSHost]}, Attribute: {Name=__UID__,
Value=[user20@place.com]}, Attribute: {Name=__ENABLE__, Value=[]},
Attribute: {Name=o, Value=[SEC-2013-00090]}, Attribute: {Name=uid,
Value=[user20@place.com]}, Attribute: {Name=status, Value=[active]},
Attribute: {Name=middleName, Value=[]}, Attribute: {Name=mail,
Value=[user20@place.com]}, Attribute: {Name=organizationSourceSystemId,
Value=[5000]}, Attribute: {Name=__NAME__,
Value=[aaimsKey=cc5567cb-2bf9-4e48-9567-cb2bf96e48c6,ou=CommitedMembers,ou=people,dc=foodbuy,dc=com]},
Attribute: {Name=title, Value=[tester]}, Attribute: {Name=pwdReset,
Value=[true]}, Attribute: {Name=sn, Value=[20]}, Attribute: {Name=givenName,
Value=[user]}], Name=Attribute: {Name=__NAME__,
Value=[aaimsKey=cc5567cb-2bf9-4e48-9567-cb2bf96e48c6,ou=CommitedMembers,ou=people,dc=foodbuy,dc=com]}}      
Method: handle
17:56:42.089 DEBUG Return: false        Method: handle
17:56:42.089 DEBUG Return       Method: executeQuery
17:56:42.090 DEBUG Return: null Method: search
17:56:42.101 DEBUG Enter: update(ObjectClass: __ACCOUNT__, Attribute:
{Name=__UID__, Value=[user20@place.com]}, [Attribute: {Name=__PASSWORD__,
Value=[org.identityconnectors.common.security.GuardedString@8ebfb676]},
Attribute: {Name=aaimsKey, Value=[cc5567cb-2bf9-4e48-9567-cb2bf96e48c6]},
Attribute: {Name=organizationDescription, Value=[HMSHost]}, Attribute:
{Name=cn, Value=[20, user]}, Attribute: {Name=__ENABLE__, Value=[true]},
Attribute: {Name=o, Value=[SEC-2013-00090]}, Attribute: {Name=uid,
Value=[user20@place.com]}, Attribute: {Name=status, Value=[active]},
Attribute: {Name=middleName, Value=[]}, Attribute: {Name=mail,
Value=[user20@place.com]}, Attribute: {Name=organizationSourceSystemId,
Value=[5000]}, Attribute: {Name=title, Value=[tester]}, Attribute:
{Name=pwdReset, Value=[true]}, Attribute: {Name=sn, Value=[20]}, Attribute:
{Name=givenName, Value=[user]}], null)      Method: update
17:56:42.102 DEBUG Enter: update(ObjectClass: __ACCOUNT__, Attribute:
{Name=__UID__, Value=[user20@place.com]}, [Attribute: {Name=__PASSWORD__,
Value=[org.identityconnectors.common.security.GuardedString@8ebfb676]},
Attribute: {Name=aaimsKey, Value=[cc5567cb-2bf9-4e48-9567-cb2bf96e48c6]},
Attribute: {Name=organizationDescription, Value=[HMSHost]}, Attribute:
{Name=cn, Value=[20, user]}, Attribute: {Name=__ENABLE__, Value=[true]},
Attribute: {Name=o, Value=[SEC-2013-00090]}, Attribute: {Name=uid,
Value=[user20@place.com]}, Attribute: {Name=status, Value=[active]},
Attribute: {Name=middleName, Value=[]}, Attribute: {Name=mail,
Value=[user20@place.com]}, Attribute: {Name=organizationSourceSystemId,
Value=[5000]}, Attribute: {Name=title, Value=[tester]}, Attribute:
{Name=pwdReset, Value=[true]}, Attribute: {Name=sn, Value=[20]}, Attribute:
{Name=givenName, Value=[user]}], OperationOptions: {})      Method: update
17:56:42.102 DEBUG Searching for object user20@place.com of class
__ACCOUNT__   Method: findEntryDN
17:56:42.103 DEBUG Searching in
[ou=CommitedMembers,ou=people,dc=foodbuy,dc=com] with filter
(&(objectClass=foodbuyMemberAccount)(uid=user20@place.com)) and
SearchControls: {returningAttributes=[uid], scope=SUBTREE}      Method:
doSearch
17:56:42.112 WARN  Attribute __ENABLE__ of object class __ACCOUNT__ is not
mapped to an LDAP attribute  Method: getLdapAttribute
17:56:42.118 DEBUG Modifying LDAP group memberships: removing [], adding []    
Method: modifyLdapGroupMemberships
17:56:42.119 DEBUG Modifying POSIX group memberships: removing [], adding []   
Method: modifyPosixGroupMemberships
17:56:42.120 DEBUG Return: Attribute: {Name=__UID__,
Value=[user20@place.com]}  Method: update
17:56:42.120 DEBUG Return: Attribute: {Name=__UID__,
Value=[user20@place.com]}  Method: update
17:56:42.126 DEBUG Enter: search(ObjectClass: __ACCOUNT__, EQUALS:
Attribute: {Name=aaimsKey, Value=[user20@place.com]},
org.apache.syncope.core.provisioning.java.AsyncConnectorFacade$1@40bdcc12,
OperationOptions:
{ATTRS_TO_GET:[aaimsKey,__PASSWORD__,mail,givenName,cn,__UID__,title,__ENABLE__,o,uid...]})   
Method: search
17:56:42.127 DEBUG Enter: executeQuery(ObjectClass: __ACCOUNT__,
LdapFilter[nativeFilter: (aaimsKey=user20@place.com); entryDN: null],
org.identityconnectors.framework.impl.api.local.operations.SearchImpl$1@547f4f54,
OperationOptions:
{ATTRS_TO_GET:[aaimsKey,__PASSWORD__,mail,givenName,cn,__UID__,title,__ENABLE__,o,uid...]})      
Method: executeQuery
17:56:42.128 WARN  Reading passwords not supported      Method:
getAttributesToGet
17:56:42.128 WARN  Attribute __ENABLE__ of object class __ACCOUNT__ is not
mapped to an LDAP attribute  Method: getLdapAttribute
17:56:42.128 DEBUG Searching in
[ou=CommitedMembers,ou=people,dc=foodbuy,dc=com] with filter
(&(objectClass=foodbuyMemberAccount)(aaimsKey=user20@place.com)) and
SearchControls: {returningAttributes=[aaimsKey, cn, givenName, mail,
middleName, o, organizationDescription, organizationSourceSystemId,
pwdReset, sn, status, title, uid, userPassword], scope=SUBTREE}   Method:
doSearch
17:56:42.134 DEBUG Return       Method: executeQuery
17:56:42.134 DEBUG Return: null Method: search


--
Sent from: http://syncope-user.1051894.n5.nabble.com/

Re: Reset Password Not Resetting Must Change Password Flag

Posted by "justin.isenhour" <ju...@compass-usa.com>.
Hey Francesco,

I took the code you committed, added it to my local 2.0.6 version and tested
it out.  I now see that the Must Change Password flag does get set back to
false after the password reset process is completed, however, this change
isn't getting sync'd back to the ldap that I have linked to the realm (the
password itself does).  Because of this when the user tries to login after
password reset it still tells them they must reset their password. HOw can I
get the Must Change Password flag to sync with the LDAP on Password Reset?

Thanks,
Justin Isenhour

--
Sent from: http://syncope-user.1051894.n5.nabble.com/

Re: Reset Password Not Resetting Must Change Password Flag

Posted by Francesco Chicchiriccò <il...@apache.org>.
On 21/12/2017 08:23, Francesco Chicchiriccò wrote:
> On 20/12/2017 14:45, justin.isenhour wrote:
>> I am currently running v2.0.6 and have recently noticed that if we 
>> toggle on
>> the Must Change Password flag then go through the Password Reset 
>> process we
>> are seeing the password changed and is syncing with the ldap 
>> connector but I
>> do not see the Must Change Password flag getting reset back to false, it
>> remains true.  I recently upgraded from 2.0.4 to 2.0.6, I cannot be 
>> certain
>> but I believe this was working before.  Any areas I should look at
>> specifically for troubleshooting this?
>
> Hi Justin,
> AFAICT there has been no change lately in the mustChangePassword user 
> flag management: the only place where this is explicitly set to false 
> is [1], e.g. when the password value is imported from an encoded value.
> FYI, this happens in both LDAPPasswordPullActions [2] and 
> DBPasswordPullActions [3], so I guess this is the reason why you 
> remember that in the past the reset described above was working when 
> pulling from LDAP.
>
> Currently, the password reset process does not take the 
> mustChangePassword flag into account: I was wondering if it would make 
> sense, for the sake of safety, to explicitly add a call like [1] right 
> afetr [4], e.g. every time that a password value is set.

All the tests went green with such change applied, hence I went out and 
commited [5]: expect such change wit upcoming 2.0.7.

Regards.

> [1] 
> https://github.com/apache/syncope/blob/2_0_X/core/persistence-jpa/src/main/java/org/apache/syncope/core/persistence/jpa/entity/user/JPAUser.java#L256
> [2] 
> https://github.com/apache/syncope/blob/2_0_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/LDAPPasswordPullActions.java#L114
> [3] 
> https://github.com/apache/syncope/blob/2_0_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/DBPasswordPullActions.java#L132
> [4] 
> https://github.com/apache/syncope/blob/2_0_X/core/persistence-jpa/src/main/java/org/apache/syncope/core/persistence/jpa/entity/user/JPAUser.java#L265
[5] 
https://github.com/apache/syncope/commit/199b66432bc835a715de0961bbd9cff12123745b

-- 
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/


Re: Reset Password Not Resetting Must Change Password Flag

Posted by Francesco Chicchiriccò <il...@apache.org>.
On 20/12/2017 14:45, justin.isenhour wrote:
> I am currently running v2.0.6 and have recently noticed that if we toggle on
> the Must Change Password flag then go through the Password Reset process we
> are seeing the password changed and is syncing with the ldap connector but I
> do not see the Must Change Password flag getting reset back to false, it
> remains true.  I recently upgraded from 2.0.4 to 2.0.6, I cannot be certain
> but I believe this was working before.  Any areas I should look at
> specifically for troubleshooting this?

Hi Justin,
AFAICT there has been no change lately in the mustChangePassword user 
flag management: the only place where this is explicitly set to false is 
[1], e.g. when the password value is imported from an encoded value.
FYI, this happens in both LDAPPasswordPullActions [2] and 
DBPasswordPullActions [3], so I guess this is the reason why you 
remember that in the past the reset described above was working when 
pulling from LDAP.

Currently, the password reset process does not take the 
mustChangePassword flag into account: I was wondering if it would make 
sense, for the sake of safety, to explicitly add a call like [1] right 
afetr [4], e.g. every time that a password value is set.

WDYT?
Regards.

[1] 
https://github.com/apache/syncope/blob/2_0_X/core/persistence-jpa/src/main/java/org/apache/syncope/core/persistence/jpa/entity/user/JPAUser.java#L256
[2] 
https://github.com/apache/syncope/blob/2_0_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/LDAPPasswordPullActions.java#L114
[3] 
https://github.com/apache/syncope/blob/2_0_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/DBPasswordPullActions.java#L132
[4] 
https://github.com/apache/syncope/blob/2_0_X/core/persistence-jpa/src/main/java/org/apache/syncope/core/persistence/jpa/entity/user/JPAUser.java#L265

-- 
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/