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 [email protected] Office: +1 678 252 4498 2205 Northmont Pkwy, STE 100 Duluth, GA 30096 -----Original Message----- From: Shawn McKinney [mailto:[email protected]] Sent: Thursday, June 08, 2017 1:06 PM To: [email protected] 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 <[email protected]> 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 <[email protected]> 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) <[email protected]> >>> 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 >>> [email protected] >>> Office: +1 678 252 4498 >>> 2205 Northmont Pkwy, STE 100 >>> Duluth, GA 30096 >>> >>> -----Original Message----- >>> From: Shawn McKinney [mailto:[email protected]] >>> Sent: Monday, June 05, 2017 8:23 AM >>> To: [email protected] >>> 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) <[email protected]> >>>> 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 >>>> [email protected] >>>> Office: +1 678 252 4498 >>>> 2205 Northmont Pkwy, STE 100 >>>> Duluth, GA 30096 >>>> >>>> -----Original Message----- >>>> From: Shawn McKinney [mailto:[email protected]] >>>> Sent: Thursday, June 01, 2017 6:12 PM >>>> To: [email protected] >>>> 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) <[email protected]> >>>>> 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 >>>> >>> >> >
