RE: referrals
thank you for the info, Stefan. what are the benefits of switching to M21 with respect to referrals? or are you simply suggesting because it is just better overall? > Subject: Re: referrals > To: users@directory.apache.org > From: m...@stefan-seelmann.de > Date: Wed, 27 Jan 2016 22:08:44 +0100 > > On 01/27/2016 06:31 PM, Michael Perelman wrote: > > i am running ads2.0.0-M17, and wondering if it supports referrals. the > > doc on your site is missing the section on referrals, so i was hoping > > that you would be able disclose info on how to use referrals in apache > > directory studio. thank you! > > Both, ApacheDS (the server) and Apache Directory Studio support > referrals and search continuations. > > On the server side you have to create entries with objectClass referral > and ref attribute which contains the LDAP URL to the other server. > ApacheDS then adds search continuations to the search result. > > In Studio you can define in the connection properties "Browser Options" > tab how referrals should be followed, and if the "ManageDsaIT" control > should be used to manage referral entries, see documentation [1]. > > Kind Regards, > Stefan > > PS: You should switch to the latest ApacheDS 2.0.0-M21 > > [1] > https://directory.apache.org/studio/users-guide/ldap_browser/tools_connection_properties.html >
custom interceptor's AdsBaseBean
hi. i am running 2.0.0M17 in regular (i.e. not embedded) mode, and i would like to introduce my own custom interceptor. i am trying to model it after the OOTB AuthenticationInterceptor, so mine will contain a password policy bearing several attributes that will be configurable via Apache Studio. after digging around through the source, i came across PasswordPolicyBean class that is apparently populated with the values from such attributes. the problem is that i am unable to determine as to how the attributes' values get propagated to this class. i noticed that each such attribute is represented with a respective variable tagged with @ConfigurationElement(attributeType = "attribute-name", isOptional = true, defaultValue = "some-val"). if i were to introduce my own MyPasswordPolicyBean class, would it be enough to just create variables with the same @ConfigurationElement tags, or do i need to perform additional steps in order for those variables to be populated with their respective attribute values? thanks!
RE: config partition as JdbmPartition
i agree that access to such file would indicate a much larger security problem. nevertheless, security files of such nature should not be sitting around on the disk. other partition do not since they are in the form of a JdbmPartition, and neither should this one. all the passwords are already hashed, so that is not my concern. my concern are all the password policies that are defined within it, both OOTB ones, as well as the additional custom ones i created for my own interceptor. so is there a way to load a config.ldif into a JdbmPartition BEFORE starting directory service? thank you! Date: Tue, 9 Jun 2015 11:21:46 +0800 Subject: Re: config partition as JdbmPartition From: kayyag...@apache.org To: users@directory.apache.org On Tue, Jun 9, 2015 at 5:24 AM, brock samson brock.sams...@hotmail.com wrote: i am running apacheds2-M19 as embedded with some custom interceptors. up to this point, i have been using SingleFileLdifPartition to load my config.ldif file. since it loads the config.ldif before DefaultDirectoryService.start(), i am also able to manually set the interceptors via DefaultDirectoryService.setInterceptors() before the start as well. what i do not like about it is that it requires the config.ldif file to be on the disk in clear text, which is a security risk in my opinion. what i would like is for the config partition to is your concern about clear text passwords in config.ldif? if yes, the just turn them into salted hashes other than this I don't see any other security issues with having config in plain text. (If someone managed to reach this far to access your config file then there is a much bigger hole in the network/system ;) look like all other partitions (i.e. system partition), which is a collection of .db and .lg files. i am able to accomplish that by using JdbmPartition class, but i cannot successfully load the config.ldif file via new LdifFileLoader(DefaultDirectoryService.getAdminSession(), config.ldif, null).execute() until after DefaultDirectoryService.start(), which makes it too late to set interceptors. is there a way to have config partition as JdbmPartition AND load its config.ldif before starting the service? or is there a another way to not have config.ldif on the disk in clear text? thanks! no, it is not possible to have this config loaded into any other partition type -- Kiran Ayyagari http://keydap.com
sources for Apache Directory Studio libraries
i have looked through your Apache Directory Studio and noticed two 3rd party libraries -- org.openoffice.odfdom (v0.6.16) and DocBook-XSL (v1.71.1) -- for which i am unable to locate sources. could you please point me to a location(s) where the sources reside? thanks!
RE: checking group membership during while binding
correct, right after user authentication i need to check which groups that user is a member of. if a user has access to its own attributes, would checking its member attribute do the trick? Date: Thu, 19 Mar 2015 07:29:20 +0100 From: elecha...@gmail.com To: users@directory.apache.org Subject: Re: checking group membership during while binding Le 19/03/15 00:50, Michael Perelman a écrit : While using Apache LDAP java APIs, is there a way to check for group membership during the binding process? Or is the only way to determine group membership is by doing a regular lookup, and only after binding? The latter approach may not work because the authenticated user may not have the access rights to perform any lookups, thereby forcing the use of an LDAP administrator. That means that its credentials need to be stored somewhere outside the LDAP server in order for the client code to use its account for the aforementioned lookup. What approach would you suggest? I'm not sure what you want to do here. What is your check for group membership in LDPA terms ? If you mean you want to look at the content of the 'member' attribute, then yes, a lookuo is the way. If you don't want to do that regularly, then using the persistentSearch contrl might be an option : you will be informed of any change done on this attribute. Obviously, you will depend on yoru LDAP server settings to have access to this attribute. If your server does not allow operations to be done without any binding (yes, you can do a search without doing any bind, this is allowed by the protocol, but most generally forbidden by some server configuration), then depending on the authorization, you might also have to pick the right user to complete such a lookup. All in all, it's really a server configuration problem...
checking group membership during while binding
While using Apache LDAP java APIs, is there a way to check for group membership during the binding process? Or is the only way to determine group membership is by doing a regular lookup, and only after binding? The latter approach may not work because the authenticated user may not have the access rights to perform any lookups, thereby forcing the use of an LDAP administrator. That means that its credentials need to be stored somewhere outside the LDAP server in order for the client code to use its account for the aforementioned lookup. What approach would you suggest?
RE: ldif import works in studio, fails with LdifFileLoader
So what am I doing wrong? Date: Wed, 25 Feb 2015 01:07:41 +0100 From: elecha...@gmail.com To: users@directory.apache.org Subject: Re: ldif import works in studio, fails with LdifFileLoader Le 24/02/15 22:32, Stefan Seelmann a écrit : On 02/24/2015 07:30 PM, Michael Perelman wrote: I looked at the issue that you have opened on this matter, and it seems to suggest that the workaround entails splitting the .ldif file into two .ldif files -- one for content and another for actions. I i went ahead and isolated the following entry into its own separate .ldif file: dn: dc=mycompany,dc=com changetype: modify add: administrativeRole administrativeRole: accessControlSpecificArea But that still does not add administrativeRole to my partition. Could you please provide a more detailed description of the workaround? Thanks! Please try to finish the change record with an - like this: dn: dc=mycompany,dc=com changetype: modify add: administrativeRole administrativeRole: accessControlSpecificArea - I guess the parser is a bit too strict here. It's not. The RFC mandates the final - followed by a NewLine : mod-spec = (add: / delete: / replace:) FILL AttributeDescription SEP *attrval-spec - SEP SEP = (CR LF / LF)
RE: ldif import works in studio, fails with LdifFileLoader
I do not see an error. Both .ldif files import without throwing an exception, but I do not see the administrativeRole entry under my partition in the Studio. I typically right-click on my partition entry and then select Fetch--Fetch Operational Attributes to expose its presence. When I add administrativeRole via Studio, it appears below my partition's existing attributes. But in this case it is not there. Furthermore, LdifFileLoader.execute() returns 0 when importing my actions .ldif, which indicates that no changes were introduced during the import. Date: Tue, 24 Feb 2015 19:54:07 +0100 From: elecha...@gmail.com To: users@directory.apache.org Subject: Re: ldif import works in studio, fails with LdifFileLoader Le 24/02/15 19:30, Michael Perelman a écrit : I looked at the issue that you have opened on this matter, and it seems to suggest that the workaround entails splitting the .ldif file into two .ldif files -- one for content and another for actions. I i went ahead and isolated the following entry into its own separate .ldif file: dn: dc=mycompany,dc=com changetype: modify add: administrativeRole administrativeRole: accessControlSpecificArea But that still does not add administrativeRole to my partition. Could you please provide a more detailed description of the workaround? Thanks! What's the error you get ? Or is it that you don't see the administrativeRole attribute ? If so, this is plain normal, it's an operational attribute, you have to specify that you want it back when you do a search.
RE: ldif import works in studio, fails with LdifFileLoader
I looked at the issue that you have opened on this matter, and it seems to
suggest that the workaround entails splitting the .ldif file into two .ldif
files -- one for content and another for actions. I i went ahead and isolated
the following entry into its own separate .ldif file:
dn: dc=mycompany,dc=com
changetype: modify
add: administrativeRole
administrativeRole: accessControlSpecificArea
But that still does not add administrativeRole to my partition. Could you
please provide a more detailed description of the workaround? Thanks!
Date: Tue, 24 Feb 2015 18:04:23 +0800
Subject: Re: ldif import works in studio, fails with LdifFileLoader
From: kayyag...@apache.org
To: users@directory.apache.org
On Tue, Feb 24, 2015 at 3:54 PM, Michael Perelman
mikhail_perel...@hotmail.com wrote:
Ok, I understand the need for proper order within an .ldif file when
loading one via LdifFileLoader, thanks!
What I am still not clear about is how to properly add administrativeRole
entry. I have modified my .ldif file to look like this:
dn: dc=mycompany,dc=com
objectclass: domain
objectclass: top
objectclass: extensibleObject
dc: mycompany
ou: mycompany
dn: dc=mycompany,dc=com
changetype: modify
add: administrativeRole
administrativeRole: accessControlSpecificArea
LDIF is not allowed to contain both entries and changesets, however Studio
allows this and we may support[1] this mode in
server as well.
For now, the workaround is to add this attribute during that entry
creation
[1] https://issues.apache.org/jira/browse/DIRAPI-222
dn: cn=allowUserSelfMod,dc=mycompany,dc=com
objectClass: subentry
objectClass: accessControlSubentry
objectClass: top
cn: allowUserSelfMod
prescriptiveACI: { identificationTag , precedence 0, authenticationLevel
s
imple, itemOrUserFirst userFirst: { userClasses { thisEntry },
userPermissi
ons { { protectedItems { entry }, grantsAndDenials { grantBrowse,
grantRetu
rnDN, grantModify, grantRead } }, { protectedItems { allAttributeValues {
u
serPassword } }, grantsAndDenials { grantRemove, grantAdd } } } } }
subtreeSpecification: { }
dn: ou=people,dc=mycompany,dc=com
objectClass: organizationalUnit
objectClass: top
ou: people
This is still not loading properly via LdifFileLoader. In your previous
response, you stated that administrativeRole must be added to the entry
immediately, yet I was still not able to make it work. Please show me the
proper way to configure it.
To answer your last question, I am using an admin session to import the
.ldif file.
Thanks!
On 11/02/15 19:26, Michael Perelman wrote :
Hi. My case involves an embedded instance of ADS-M17 where I load a
simple .ldif file
during start-up using LdifFileLoader instance. I always use the Studio to
perform initial
tests, and it works in this particular case. But when I use
LdifFileLoader, the security-related
entities are never created. Here is what the .ldif looks like:
LdapStudio will order the LDIF before injecting it. The LdifLoader wont.
Typically, here, the dc=myCompany,dc=com is not the first entry, and the
loader will yell at you because it's messing when it will try to load
the first entry (ou=people,dc=mycompany,dc=co).
Another thing : why are you modifying the entry you just injected before
(dc=mycompany,dc=com)? It's a better idea to add the administrativeRole
attribute to the entry immediately.
Last, not least: which user are you using to inject the entries ?
dn: ou=people,dc=mycompany,dc=com
objectClass: organizationalUnit
objectClass: top
ou: people
dn: dc=mycompany,dc=com
objectclass: domain
objectclass: top
objectclass: extensibleObject
dc: mycompany
ou: mycompany
dn: dc=mycompany,dc=com
changetype: modify
add: administrativeRole
administrativeRole: accessControlSpecificArea
dn: cn=allowUserSelfMod,dc=mycompany,dc=com
objectClass: subentry
objectClass: accessControlSubentry
objectClass: top
cn: allowUserSelfMod
prescriptiveACI: { identificationTag , precedence 0,
authenticationLevel s
imple, itemOrUserFirst userFirst: { userClasses { thisEntry },
userPermissi
ons { { protectedItems { entry }, grantsAndDenials { grantBrowse,
grantRetu
rnDN, grantModify, grantRead } }, { protectedItems { allAttributeValues
{ u
serPassword } }, grantsAndDenials { grantRemove, grantAdd } } } } }
subtreeSpecification: { }
The dc=mycompany,dc=com partition and its ou=people org unit are created
successfully
when using either the Studio or the LdifFileLoader. Yet partition's
administrativeRole and
accessControlSubentry are only created when using the Studio, while
importing via LdifFileLoader
does not! And no exceptions are thrown at any time.
Thanks!
--
Kiran Ayyagari
http://keydap.com
RE: ldif import works in studio, fails with LdifFileLoader
Still no success. I tried both with and without trailing blank line. Date: Tue, 24 Feb 2015 22:32:25 +0100 From: m...@stefan-seelmann.de To: users@directory.apache.org Subject: Re: ldif import works in studio, fails with LdifFileLoader On 02/24/2015 07:30 PM, Michael Perelman wrote: I looked at the issue that you have opened on this matter, and it seems to suggest that the workaround entails splitting the .ldif file into two .ldif files -- one for content and another for actions. I i went ahead and isolated the following entry into its own separate .ldif file: dn: dc=mycompany,dc=com changetype: modify add: administrativeRole administrativeRole: accessControlSpecificArea But that still does not add administrativeRole to my partition. Could you please provide a more detailed description of the workaround? Thanks! Please try to finish the change record with an - like this: dn: dc=mycompany,dc=com changetype: modify add: administrativeRole administrativeRole: accessControlSpecificArea - I guess the parser is a bit too strict here. Kind Regards, Stefan
ldif import works in studio, fails with LdifFileLoader
Hi. My case involves an embedded instance of ADS-M17 where I load a simple
.ldif file during start-up using LdifFileLoader instance. I always use the
Studio to perform initial tests, and it works in this particular case. But when
I use LdifFileLoader, the security-related entities are never created. Here is
what the .ldif looks like:
dn: ou=people,dc=mycompany,dc=com
objectClass: organizationalUnit
objectClass: top
ou: people
dn: dc=mycompany,dc=com
objectclass: domain
objectclass: top
objectclass: extensibleObject
dc: mycompany
ou: mycompany
dn: dc=mycompany,dc=com
changetype: modify
add: administrativeRole
administrativeRole: accessControlSpecificArea
dn: cn=allowUserSelfMod,dc=mycompany,dc=com
objectClass: subentry
objectClass: accessControlSubentry
objectClass: top
cn: allowUserSelfMod
prescriptiveACI: { identificationTag , precedence 0, authenticationLevel s
imple, itemOrUserFirst userFirst: { userClasses { thisEntry }, userPermissi
ons { { protectedItems { entry }, grantsAndDenials { grantBrowse, grantRetu
rnDN, grantModify, grantRead } }, { protectedItems { allAttributeValues { u
serPassword } }, grantsAndDenials { grantRemove, grantAdd } } } } }
subtreeSpecification: { }
The dc=mycompany,dc=com partition and its ou=people org unit are created
successfully when using either the Studio or the LdifFileLoader. Yet
partition's administrativeRole and accessControlSubentry are only created when
using the Studio, while importing via LdifFileLoader does not! And no
exceptions are thrown at any time.
Thanks!
ADS 2.0.0 password policy
i am attempting to implement a password policy in ADS 2.0.0-M17, and this is a two-part question. 1) i came across the same issue as described here: http://stackoverflow.com/questions/23550061/apacheds-password-policy-check-not-getting-enforced the poster all the way at the bottom stated that password policies are not enforced whenever an administrator is the one creating/editing a password. is that true? if so, is that a bug that will be rectified in the future, or was it implemented in such a way with a purpose? 2) is it possible to use a regex formula for a password policy? thank you!
official ApacheDS 2.0 release
hi. i was wondering if an official ApacheDS 2.0 release was ever created? the downloads for the 2.0 version seem to suggest that it was not, and that you are still working toward it. if such is the case, could you please tell me what the ETA for 2.0 is? thank you!
