directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Brooks (US)" <Brian.Bro...@datapath.com>
Subject RE: Using REST API to get user's locked and reset states
Date Wed, 14 Jun 2017 16:29:40 GMT
Hi Shawn,

In case it wasn't obvious from our pwdReset post, your hints last week about setting ldap.server.type=openldap
helped us get Fortress Rest 2.0.0-RC2 on ApacheDS 2.0.0-M23 to return the user's locked and
reset states.  

To get it working we performed these steps:
1. ApacheDS - deleted the JDBM partition and re-added.
2. ApacheDS - deleted relevant entries.  We found it strange that the entries still had to
be deleted after the partition was deleted.
3. Fortress - Changed ldap.server.type from apacheds to openldap in build.properties and re-ran
mvn install.  Hand-generated a final fortress.properties.  Copied this fortress.properties
to the appropriate locations under fortress-core, fortress-web, and fortress-enmasse.
4. Fortress - Reinstalled the Fortress components (mvn install -Dload.file calls) with the
updated fortress.properties.

It took a bit of time to re-install because we got stuck trying to understand "ApacheDS &
Fortress QUICKSTART", "SECTION 3. Apache Fortress Core Setup"  https://github.com/apache/directory-fortress-core/blob/master/README-QUICKSTART-APACHEDS.md#section-3-apache-fortress-core-setup.
 In particular, "README for Apache Fortress Configuration Subsystem" https://github.com/apache/directory-fortress-core/blob/master/README-CONFIG.md.
 Even though we had ldap.server.type=openldap in fortress.properties, we noticed the ldap.server.type
 getting loaded into cn=TOMCAT, ou=Config,@SUFFIX@ by directory-fortress-core\ldap\setup\refreshLDAPData.xml

            <addconfig>
                <config props="config.realm:TOMCAT"/>
                <config props="authn.type:realm"/>
                <config props="ldap.server.type:@SERVER_TYPE@"/>

and started noticing that our fortress.properties settings were getting overridden by cn=DEFAULT,
ou=Config,@SUFFIX@.

A couple of issues we dealt with specifically were:

1. Fortress Core - The relationship between directory-fortress-core\config\fortress.properties
and directory-fortress-core\config\bootstrap\fortress.properties is unclear.  We ended up
constructing a fortress.properties by appending most of the config\bootstrap\fortress.properties
contents to config\fortress.properties.

2.  Fortress Rest - Loading FortressRestServerPolicy.xml seems to require that the LDAP server
contain cn=DEFAULT, ou=Config,@SUFFIX@ even if the deployment plan is to rely only on fortress.properties.

We tried to reinstall Fortress without any ou=Config entries but kept getting failures during
Fortress Rest installation

C:\dev\directory-fortress-enmasse>mvn install -Dload.file=./src/main/resources/FortressRestServerPolicy.xml
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Apache Fortress Rest 2.0.0-RC2
[INFO] ------------------------------------------------------------------------
--snip--
[startAnt] BUILD FAILED
 [startAnt] C:\dev\directory-fortress-enmasse\src\main\resources\FortressRestServerPolicy.xml:26:
Could not create type FortressAdmin due to org.apache.directory.fortress.core.CfgRuntimeException:
static init: Error loading from remote config: SecurityException=org.apache.directory.fortress.core.FinderException:
getConfig dn [cn=DEFAULT,null] caught LdapException=ERR_04201 No more characters available
at position 15, errCode=127
 [startAnt]     at org.apache.directory.fortress.core.util.Config.loadRemoteConfig(Config.java:633)
 [startAnt]     at org.apache.directory.fortress.core.util.Config.getInstance(Config.java:101)
 [startAnt]     at org.apache.directory.fortress.core.ConfigMgrFactory.createInstance(ConfigMgrFactory.java:54)
 [startAnt]     at org.apache.directory.fortress.core.ant.FortressAntTask.<init>(FortressAntTask.java:380)
 [startAnt]     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 [startAnt]     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 [startAnt]     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 [startAnt]     at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
 [startAnt]     at org.apache.tools.ant.AntTypeDefinition.innerCreateAndSet(AntTypeDefinition.java:329)
 [startAnt]     at org.apache.tools.ant.AntTypeDefinition.createAndSet(AntTypeDefinition.java:274)
 [startAnt]     at org.apache.tools.ant.AntTypeDefinition.icreate(AntTypeDefinition.java:219)
 [startAnt]     at org.apache.tools.ant.AntTypeDefinition.create(AntTypeDefinition.java:206)
 [startAnt]     at org.apache.tools.ant.ComponentHelper.createComponent(ComponentHelper.java:285)
 [startAnt]     at org.apache.tools.ant.ComponentHelper.createComponent(ComponentHelper.java:263)
 [startAnt]     at org.apache.tools.ant.UnknownElement.makeObject(UnknownElement.java:430)
 [startAnt]     at org.apache.tools.ant.UnknownElement.maybeConfigure(UnknownElement.java:164)
 [startAnt]     at org.apache.tools.ant.Task.perform(Task.java:347)
 [startAnt]     at org.apache.tools.ant.Target.execute(Target.java:435)
 [startAnt]     at org.apache.tools.ant.Target.performTasks(Target.java:456)
 [startAnt]     at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1405)
 [startAnt]     at org.apache.tools.ant.Project.executeTarget(Project.java:1376)
 [startAnt]     at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
 [startAnt]     at org.apache.tools.ant.Project.executeTargets(Project.java:1260)
 [startAnt]     at org.apache.tools.ant.Main.runBuild(Main.java:854)
 [startAnt]     at org.apache.tools.ant.Main.startAnt(Main.java:236)
 [startAnt]     at org.apache.tools.ant.launch.Launcher.run(Launcher.java:285)
 [startAnt]     at org.apache.tools.ant.launch.Launcher.main(Launcher.java:112)
 [startAnt] Caused by: org.apache.directory.fortress.core.FinderException: getConfig dn [cn=DEFAULT,null]
caught LdapException=ERR_04201 No more characters available at position 15
 [startAnt]     at org.apache.directory.fortress.core.impl.ConfigDAO.getConfig(ConfigDAO.java:283)
 [startAnt]     at org.apache.directory.fortress.core.impl.ConfigP.read(ConfigP.java:158)
 [startAnt]     at org.apache.directory.fortress.core.impl.ConfigMgrImpl.read(ConfigMgrImpl.java:93)
 [startAnt]     at org.apache.directory.fortress.core.util.Config.getRemoteConfig(Config.java:335)
 [startAnt]     at org.apache.directory.fortress.core.util.Config.loadRemoteConfig(Config.java:592)
 [startAnt]     ... 26 more
 [startAnt] Caused by: org.apache.directory.api.ldap.model.exception.LdapInvalidDnException:
ERR_04201 No more characters available at position 15
 [startAnt]     at org.apache.directory.api.ldap.model.name.FastDnParser.nextChar(FastDnParser.java:601)
 [startAnt]     at org.apache.directory.api.ldap.model.name.FastDnParser.matchEquals(FastDnParser.java:525)
 [startAnt]     at org.apache.directory.api.ldap.model.name.FastDnParser.parseRdnInternal(FastDnParser.java:160)
 [startAnt]     at org.apache.directory.api.ldap.model.name.FastDnParser.parseDn(FastDnParser.java:91)
 [startAnt]     at org.apache.directory.api.ldap.model.name.Dn.parseInternal(Dn.java:1429)
 [startAnt]     at org.apache.directory.api.ldap.model.name.Dn.<init>(Dn.java:291)
 [startAnt]     at org.apache.directory.api.ldap.model.name.Dn.<init>(Dn.java:214)
 [startAnt]     at org.apache.directory.ldap.client.api.LdapNetworkConnection.lookup(LdapNetworkConnection.java:3468)
 [startAnt]     at org.apache.directory.ldap.client.api.LdapConnectionWrapper.lookup(LdapConnectionWrapper.java:497)
 [startAnt]     at org.apache.directory.fortress.core.ldap.LdapDataProvider.read(LdapDataProvider.java:167)
 [startAnt]     at org.apache.directory.fortress.core.impl.ConfigDAO.getConfig(ConfigDAO.java:272)
 [startAnt]     ... 30 more
 [startAnt]
 [startAnt] Total time: 1 second
 [startAnt] [FortressAdmin] 2017-06-12 12:04:34,488 (ERROR) static init: Error loading from
remote config: SecurityException=org.apache.directory.fortress.core.FinderException: getConfig
dn [cn=DEFAULT,null] caught LdapException=ERR_04201 No more characters available at position
15

Finally, we settled on running c:\dev\directory-fortress-core>mvn install -Dload.file=./ldap/setup/refreshLDAPData.xml
with a hand-modified refreshLDAPData.xml which creates a cn=DEFAULT, ou=Config,@SUFFIX@ with
no child entries:

<addconfig>
    <config props="config.realm:DEFAULT"/>
</addconfig>

Thanks for your help and all the quick responses!


Brian Brooks
Sr Software Engineer
brian.brooks@datapath.com
Office: +1 678 252 4498
2205 Northmont Pkwy, STE 100
Duluth, GA 30096

-----Original Message-----
From: Shawn McKinney [mailto:smckinney@apache.org] 
Sent: Thursday, June 08, 2017 1:06 PM
To: fortress@directory.apache.org
Subject: Re: Using REST API to get user's locked and reset states

Need to change core to support pw policies in apacheds formally.  Ticket open:
https://issues.apache.org/jira/browse/FC-211

Shawn


> On Jun 8, 2017, at 11:25 AM, Shawn McKinney <smckinney@apache.org> wrote:
> 
> I finally got around to trying this myself.  Changing the ldap.server.type prop as described
means fortress will process the pw policy ops.  I was able to verify on a test against apacheds,
new response pasted below.  I noticed before that you don’t have the pwpolicy attribute
set on your user which means the default policy for the server will be enforced.  
> 
> Let me know if you have any more questions.
> 
> 
> <FortResponse>
>  <errorCode>0</errorCode>
>  <entity xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="user">
>    <modId>18e5955f-90cf-420a-8580-fc47be245f0a</modId>
>    <sequenceId>0</sequenceId>
>    <userId>foo1</userId>
>    <description>foo fighters 1</description>
>    <name>foo1 fighters</name>
>    <internalId>d301b72a-916f-4419-94a4-df24fc8ac7ad</internalId>
>    <ou>dev1</ou>
>    <pwPolicy>cn=test1</pwPolicy>
>    <sn>fighters</sn>
>    <cn>foo1 fighters</cn>
>    <dn>uid=foo1,ou=People,dc=example,dc=com</dn>
>    <address/>
>    <props>
>      <modId>8e4f30a3-d452-4fc0-9ac6-fd73b298990f</modId>
>      <sequenceId>0</sequenceId>
>      <entry>
>        <key>initAttrArrays</key>
>        <value/>
>      </entry>
>    </props>
>    <locked>true</locked>
>    <reset>true</reset>
>    <timeout>0</timeout>
>  </entity>
> </FortResponse>
> 
> Shawn
> 
>> On Jun 5, 2017, at 9:56 PM, Shawn McKinney <smckinney@apache.org> wrote:
>> 
>> Hey Brian,
>> 
>> can you add/replace with this fortress.properties:
>> 
>> ldap.server.type=openldap
>> 
>> and tell me what happens.  Normally I'd try it myself first but am sort of busy right
now.  Will have more time in a couple of days.
>> 
>> Thanks,
>> Shawn
>> 
>>> On Jun 5, 2017, at 8:41 AM, Brian Brooks (US) <Brian.Brooks@datapath.com>
wrote:
>>> 
>>> Good Morning Shawn,
>>> 
>>>> How did you enable pw policies in apacheds, can you point me to the setup
instructions you used?
>>> 
>>> We just setup a vanilla install of ApacheDS on a Windows 10 virtual 
>>> machine using apacheds-2.0.0-M23.exe downloaded from
>>> 
>>> http://directory.apache.org/apacheds/download/download-windows.html
>>> 
>>> The ApacheDS instances is configured with default settings which includes enabling
a default password policy.
>>> 
>>> http://directory.apache.org/apacheds/advanced-ug/4.3-password-policy
>>> .html
>>> 
>>> Dave setup the ApacheDS, when he gets back in the office I can confirm whether
he customized anything.
>>> 
>>> Here's an LDIF export of
>>> 
>>> * ou=config
>>>  * ads-directoryServiceId=<default>
>>>      * ou=interceptors
>>>          * ads-interceptorId=authenticationInterceptor
>>>              * ou=passwordPolicies
>>> 
>>> from our ApacheDS installation of
>>> 
>>> 
>>> dn: 
>>> ads-pwdId=default,ou=passwordPolicies,ads-interceptorId=authenticati
>>> onIn 
>>> terceptor,ou=interceptors,ads-directoryServiceId=default,ou=config
>>> objectclass: ads-passwordPolicy
>>> objectclass: ads-base
>>> objectclass: top
>>> ads-pwdattribute: userPassword
>>> ads-pwdid: default
>>> ads-enabled: TRUE
>>> ads-pwdallowuserchange: TRUE
>>> ads-pwdcheckquality: 1
>>> ads-pwdexpirewarning: 600
>>> ads-pwdfailurecountinterval: 30
>>> ads-pwdgraceauthnlimit: 5
>>> ads-pwdgraceexpire: 0
>>> ads-pwdinhistory: 5
>>> ads-pwdlockout: TRUE
>>> ads-pwdlockoutduration: 0
>>> ads-pwdmaxage: 0
>>> ads-pwdmaxdelay: 0
>>> ads-pwdmaxfailure: 5
>>> ads-pwdmaxidle: 0
>>> ads-pwdmaxlength: 0
>>> ads-pwdminage: 0
>>> ads-pwdmindelay: 0
>>> ads-pwdminlength: 5
>>> ads-pwdmustchange: FALSE
>>> ads-pwdsafemodify: FALSE
>>> ads-pwdvalidator: 
>>> org.apache.directory.server.core.api.authn.ppolicy.Default
>>> PasswordValidator
>>> createtimestamp: 20170523201006.896Z
>>> creatorsname: uid=admin,ou=system
>>> entrycsn: 20170523201006.896000Z#000000#000#000000
>>> entryDN: 
>>> ads-pwdId=default,ou=passwordPolicies,ads-interceptorId=authenticat
>>> ionInterceptor,ou=interceptors,ads-directoryServiceId=default,ou=con
>>> fig
>>> entryParentId: 81135817-120c-4b89-81be-33f759cd5319
>>> entryuuid:: ZGYyYjI2OTctNzQ4OC00NzUzLWFiOGEtZWJhMmRhOTE1NmQ1
>>> nbChildren: 0
>>> nbSubordinates: 0
>>> subschemaSubentry: cn=schema
>>> 
>>> Brian Brooks
>>> Sr Software Engineer
>>> brian.brooks@datapath.com
>>> Office: +1 678 252 4498
>>> 2205 Northmont Pkwy, STE 100
>>> Duluth, GA 30096
>>> 
>>> -----Original Message-----
>>> From: Shawn McKinney [mailto:smckinney@apache.org]
>>> Sent: Monday, June 05, 2017 8:23 AM
>>> To: fortress@directory.apache.org
>>> Subject: Re: Using REST API to get user's locked and reset states
>>> 
>>> Hi Brian,
>>> 
>>> I’ll need to setup an apacheds instance locally that matches your config. 
  
>>> 
>>> How did you enable pw policies in apacheds, can you point me to the setup instructions
you used?
>>> 
>>> In the meantime, here is a response via enmasse of user who’s account is both
locked and reset.  
>>> 
>>> The policy attributes are being populated.  But again I’m using openldap, and
need to run the exact same test with ads.
>>> 
>>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
>>> <FortResponse>  <errorCode>0</errorCode>  <entity 
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
>>> xsi:type="user"> <modId>cb792bd1-c8fe-424f-a629-aad6c5572aa9</modId>
>>> <sequenceId>0</sequenceId>
>>> <userId>foo1</userId>
>>> <description>foo fighter</description> <name>foo1</name>

>>> <internalId>fdc4a7f3-62f7-47d4-aac4-bac4b7cdb551</internalId>
>>> <ou>dev1</ou>
>>> <pwPolicy>cn=test1</pwPolicy>
>>> <sn>fighter</sn>
>>> <cn>foo1</cn>
>>> <dn>uid=foo1,ou=People,dc=example,dc=com</dn>
>>> <address/>
>>> <props>
>>>   <modId>fc416338-69bd-46df-8b00-e1fd6be7ed9c</modId>
>>>   <sequenceId>0</sequenceId>
>>>   <entry>
>>>     <key>initAttrArrays</key>
>>>     <value/>
>>>   </entry>
>>> </props>
>>> <locked>true</locked>
>>> <reset>true</reset>
>>> <timeout>0</timeout>
>>> </entity>
>>> </FortResponse>
>>> 
>>> 
>>> Shawn
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On Jun 2, 2017, at 3:39 PM, Brian Brooks (US) <Brian.Brooks@datapath.com>
wrote:
>>>> 
>>>> Hi Shawn,
>>>> 
>>>> Dave and I work together.  He's on vacation for a couple days.
>>>> 
>>>>> Can you export that corresponding user entry into ldif and post it here?
>>>> 
>>>> Below is the dave user's entry exported to ldif (I omitted the jpegPhoto,
userPassword, and the 5 pwdHistory attributes). 
>>>> 
>>>> I don't see the policy attribute even though fotress-commander seems to successfully
commit the password policy assignment.  For example, I just tried to change another user's
password policy and tomcat recorded an HTTP 200 in it's access log.  I don't see any obvious
errors in the tomcat stdout/stderr/catalina logs.
>>>> 
>>>> 10.1.122.55 - test [02/Jun/2017:16:26:34 -0400] "POST 
>>>> /fortress-web/wicket/bookmarkable/org.apache.directory.fortress.web
>>>> .Us 
>>>> erPage?2-1.IBehaviorListener.0-layout-userdetailpanel-editFields-co
>>>> mmi 
>>>> t&wicket-ajax=true&wicket-ajax-baseurl=wicket%2Fbookmarkable%2Forg.
>>>> apa
>>>> che.directory.fortress.web.UserPage%3F2 HTTP/1.1" 200 261634
>>>> 
>>>> dn: uid=dave,ou=People,dc=example,dc=com
>>>> objectClass: extensibleObject
>>>> objectClass: ftMods
>>>> objectClass: ftProperties
>>>> objectClass: ftUserAttrs
>>>> objectClass: organizationalPerson
>>>> objectClass: person
>>>> objectClass: inetOrgPerson
>>>> objectClass: top
>>>> cn: dave
>>>> ftId: 8f35b947-6db5-4e4f-a73a-98b448b15874
>>>> sn: dave
>>>> displayName: dave
>>>> ftCstr: dave$0$$$$$$$
>>>> ftModCode: AdminMgrImpl.resetPassword
>>>> ftModId: e351aa19-aded-4a92-ab3b-725c5c75ec9b
>>>> ftModifier: 70e12de5-cbf5-4152-b98a-89d185667bda
>>>> ftProps: initAttrArrays:
>>>> ftRA: fortress-rest-super-user
>>>> ftRC: fortress-rest-super-user$0$$$$$$$
>>>> ftSystem: FALSE
>>>> ou: dev0
>>>> uid: dave
>>>> createTimestamp: 20170531211627.651Z
>>>> creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>>>> entryCSN: 20170601195338.392000Z#000000#001#000000
>>>> entryDN: uid=dave,ou=People,dc=example,dc=com
>>>> entryParentId: a59bdb1e-b9eb-40c1-acbc-6be60ee64b42
>>>> entryUUID:: M2MyNzc0YTctNWQzMy00ODdlLTk1ZWItMjZhNWNmMTJiYTkz
>>>> modifiersName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>>>> modifyTimestamp: 20170601195338.057Z
>>>> nbChildren: 0
>>>> nbSubordinates: 0
>>>> pwdAccountLockedTime: 000001010000Z
>>>> pwdReset: TRUE
>>>> subschemaSubentry: cn=schema
>>>> 
>>>> 
>>>> Brian Brooks
>>>> Sr Software Engineer
>>>> brian.brooks@datapath.com
>>>> Office: +1 678 252 4498
>>>> 2205 Northmont Pkwy, STE 100
>>>> Duluth, GA 30096
>>>> 
>>>> -----Original Message-----
>>>> From: Shawn McKinney [mailto:smckinney@apache.org]
>>>> Sent: Thursday, June 01, 2017 6:12 PM
>>>> To: fortress@directory.apache.org
>>>> Subject: Re: Using REST API to get user's locked and reset states
>>>> 
>>>> Welcome Dave,
>>>> 
>>>> Can you export that corresponding user entry into ldif and post it here?
  We’ll need to see the operational attributes before trying to figure out where the problem
is.  
>>>> 
>>>> For example, here’s an export I did of test user ‘foo1’.  You can see
that I’ve put that user’s account into both a locked and reset state (in openldap).
>>>> 
>>>> You can also see this user’s password policy is ‘test1’.
>>>> 
>>>> dn: uid=foo1,ou=People,dc=example,dc=com
>>>> objectClass: extensibleObject
>>>> objectClass: ftMods
>>>> objectClass: ftProperties
>>>> objectClass: ftUserAttrs
>>>> objectClass: inetOrgPerson
>>>> objectClass: top
>>>> cn: foo1
>>>> ftId: fdc4a7f3-62f7-47d4-aac4-bac4b7cdb551
>>>> sn: fighter
>>>> description: foo fighter
>>>> displayName: foo1
>>>> ftCstr: foo1$0$$$$$$$
>>>> ftProps: initAttrArrays:
>>>> ou: dev1
>>>> uid: foo1
>>>> userPassword:: e1NTSEF9UVQ0K21NdE5lYTBwckFRTC96QlQ2akZrK1ZESTIxd3E=
>>>> createTimestamp: 20170601212713Z
>>>> creatorsName: cn=Manager,dc=example,dc=com
>>>> entryCSN: 20170601213012.870902Z#000000#000#000000
>>>> entryDN: uid=foo1,ou=People,dc=example,dc=com
>>>> entryUUID:: ZDJlMDE3YjItZGI1Yy0xMDM2LThlMzMtNTkzZmZmYzA1ODU4
>>>> hasSubordinates: FALSE
>>>> modifiersName: cn=Manager,dc=example,dc=com
>>>> modifyTimestamp: 20170601213012Z
>>>> pwdAccountLockedTime: 000001010000Z
>>>> pwdChangedTime: 20170601212844Z
>>>> pwdHistory:: 
>>>> MjAxNzA2MDEyMTI4NDRaIzEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjQwIzM
>>>> 4I3tTU0hBfXlSVm5jMjVUUThZN2libnVuVEpUR2VVY1pYeFBCdjFR
>>>> pwdPolicySubentry: cn=test1,ou=Policies,dc=example,dc=com
>>>> pwdReset: TRUE
>>>> structuralObjectClass: inetOrgPerson
>>>> subschemaSubentry: cn=Subschema
>>>> 
>>>> 
>>>> 
>>>> thanks
>>>> Shawn
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Jun 1, 2017, at 10:57 AM, David Erie (US) <David.Erie@datapath.com>
wrote:
>>>>> 
>>>>> Hello,
>>>>> We're evaluating Fortress with ApacheDS, and I'm trying to get a user's
account status (locked and reset, specifically) via the REST API for a user whose account
is locked and whose password has been reset.
>>>>> 
>>>>> What I get back is this:
>>>>> 
>>>>> <entity xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
>>>>> xsi:type="user"> ..
>>>>>           <userId>dave</userId>
>>>>>           <locked>false</locked>
>>>>>           <reset>false</reset>
>>>>> ..
>>>>> </entity>
>>>>> 
>>>>> How can I tell that a user's account has been locked or reset when these
Boolean properties don't seem to contain the correct information?
>>>>> 
>>>>> Thank you,
>>>>> Dave
>>>> 
>>> 
>> 
> 

Mime
View raw message