from:"Ervin Hegedüs"

Re: RE24 testing call #1 (OpenLDAP 2.4.54)

2020-10-14 Thread Ervin Hegedüs

hi,

On Tue, Oct 13, 2020 at 11:52:01AM -0700, Quanah Gibson-Mount wrote:
> 
> 
> --On Tuesday, October 13, 2020 7:50 PM +0200 Hegedüs Ervin
>  wrote:
> 
> > thanks, now I've tried:
> > 
> > $ export SLEEP1=10
> > $ make test
> 
> I would try with 30 seconds, Solaris is notoriously slow, and SPARC +
> Solaris even slower. ;)

I could't give up.

$ export SLEEP1=30
$ time make test
...

0 tests for mdb were skipped.
gmake[2]: Leaving directory 
'/export/home/airween/openldap-OPENLDAP_REL_ENG_2_4/tests'
gmake[1]: Leaving directory 
'/export/home/airween/openldap-OPENLDAP_REL_ENG_2_4/tests'

real320m20.971s
user12m9.195s
sys 11m40.302s

hth,

a.

Re: RE24 testing call #1 (OpenLDAP 2.4.54)

2020-10-13 Thread Ervin Hegedüs

hi,

On Tue, Oct 13, 2020 at 11:52:01AM -0700, Quanah Gibson-Mount wrote:
> 
> 
> --On Tuesday, October 13, 2020 7:50 PM +0200 Hegedüs Ervin
>  wrote:
> 
> > thanks, now I've tried:
> > 
> > $ export SLEEP1=10
> > $ make test
> 
> I would try with 30 seconds, Solaris is notoriously slow, and SPARC +
> Solaris even slower. ;)

I incremented that value to 12 - it runs since about 3 or 4
hours... (without problems)


a.

Re: RE24 testing call #1 (OpenLDAP 2.4.54)

2020-10-13 Thread Ervin Hegedüs

On Tue, Oct 13, 2020 at 09:00:55AM -0700, Quanah Gibson-Mount wrote:
> 
> 
> --On Tuesday, October 13, 2020 6:52 PM +0200 Ervin Hegedüs
>  wrote:
> 
> > checking db.h usability... yes
> > checking db.h presence... yes
> > checking for db.h... yes
> > checking for Berkeley DB major version in db.h... 5
> > checking for Berkeley DB minor version in db.h... 3
> > checking if Berkeley DB version supported by BDB/HDB backends... yes
> > checking for Berkeley DB link (-ldb-5.3)... yes
> > checking for Berkeley DB library and header version match... Berkeley DB
> > version mismatchheader: Berkeley DB 5.3.21: (May 11, 2012)
> > library: Berkeley DB 5.3.28: (September  9, 2013)
> 
> This would indicate a problem with your build environment, not an OpenLDAP
> issue.

yeah, the problem was the runtime library is installed on the
system, but the developing files aren't. So I grabbed the BDB
source here:

https://github.com/berkeleydb/libdb

and compiled.

The headers comes from this directory, but when the `configure`
script ran the conftest binary, then it loaded the system-wide
.so file - which is 5.3.28. (The GH repository contains 5.3.21)

Now it works as well:

$ uname -a
Linux 4.19.123 #10 SMP PREEMPT Wed May 20 14:28:59 CEST 2020 mips64 GNU/Linux
$ make test
...

0 tests for mdb were skipped.


thanks,


a.

Re: RE24 testing call #1 (OpenLDAP 2.4.54)

2020-10-13 Thread Ervin Hegedüs

Hi again

On Thu, Oct 01, 2020 at 09:18:47AM -0700, Quanah Gibson-Mount wrote:
> This is the first testing call for OpenLDAP 2.4.54.  Depending on the
> results, this may be the only testing call.
> 
> Generally, get the code for RE24:
> 
> 
> 
> Extract, configure, and build.
> 
> Execute the test suite (via make test) after it is built.  Optionally, cd
> tests && make its to run through the regression suite.

$ uname -a
Linux 4.19.123 #10 SMP PREEMPT Wed May 20 14:28:59 CEST 2020 mips64 GNU/Linux

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/mips64el-linux-gnuabi64/8/lto-wrapper
Target: mips64el-linux-gnuabi64
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6) 

$ ./configure
...
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for Berkeley DB major version in db.h... 5
checking for Berkeley DB minor version in db.h... 3
checking if Berkeley DB version supported by BDB/HDB backends... yes
checking for Berkeley DB link (-ldb-5.3)... yes
checking for Berkeley DB library and header version match... Berkeley DB 
version mismatch
header: Berkeley DB 5.3.21: (May 11, 2012)
library: Berkeley DB 5.3.28: (September  9, 2013)
no
configure: error: Berkeley DB version mismatch

hth,

a.

Re: RE24 testing call #1 (OpenLDAP 2.4.54)

2020-10-13 Thread Ervin Hegedüs

hi again,

On Thu, Oct 01, 2020 at 09:18:47AM -0700, Quanah Gibson-Mount wrote:
> This is the first testing call for OpenLDAP 2.4.54.  Depending on the
> results, this may be the only testing call.
> 
> Generally, get the code for RE24:
> 
> 
> 
> Extract, configure, and build.
> 
> Execute the test suite (via make test) after it is built.  Optionally, cd
> tests && make its to run through the regression suite.

$ uname -a
Linux 4.18.0-80.7.2.el7.ppc64le #1 SMP Thu Sep 12 15:45:05 UTC 2019 ppc64le 
ppc64le ppc64le GNU/Linux
$ make test
...
...
0 tests for mdb were skipped.
$ cd tests/
$ make test
...
0 tests for mdb were skipped.


hth,


a.

Re: RE24 testing call #1 (OpenLDAP 2.4.54)

2020-10-13 Thread Ervin Hegedüs

Hi all,

On Thu, Oct 01, 2020 at 09:18:47AM -0700, Quanah Gibson-Mount wrote:
> This is the first testing call for OpenLDAP 2.4.54.  Depending on the
> results, this may be the only testing call.
> 
> Generally, get the code for RE24:
> 
> 
> 
> Extract, configure, and build.
> 
> Execute the test suite (via make test) after it is built.  Optionally, cd
> tests && make its to run through the regression suite.

$ uname -a
SunOS gcc-solaris11 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise

$ ./configure ...
$ ...
$ make test
...
> Starting test018-syncreplication-persist for bdb...
running defines.sh
Starting provider slapd on TCP/IP port 9011...
Using ldapsearch to check that provider slapd is running...
Using ldapadd to create the context prefix entry in the provider...
Starting consumer slapd on TCP/IP port 9014...
Using ldapsearch to check that consumer slapd is running...
Using ldapadd to populate the provider directory...
Waiting 7 seconds for syncrepl to receive changes...
Using ldapsearch to read all the entries from the provider...
Using ldapsearch to read all the entries from the consumer...
Filtering provider results...
Filtering consumer results...
Comparing retrieved entries from provider and consumer...
test failed - provider and consumer databases differ
> test018-syncreplication-persist failed for bdb
(exit 1)
gmake[2]: *** [Makefile:293: bdb-yes] Error 1
gmake[2]: Leaving directory 
'/export/home/airween/openldap-OPENLDAP_REL_ENG_2_4/tests'
gmake[1]: *** [Makefile:278: test] Error 2
gmake[1]: Leaving directory 
'/export/home/airween/openldap-OPENLDAP_REL_ENG_2_4/tests'
gmake: *** [Makefile:290: test] Error 2


regards,


a.

Using unique overlay per OU

2018-11-14 Thread Ervin Hegedüs

Hi,

here is an OpenLDAP cluster, with few DC's, eg:

dc=service1,dc=company1,dc=hu
and
dc=company2,dc=hu.

All DC's containts few ten of OU, where few ten of user.

Now the uniq overlay is set for some attributes, eg. "mail",
which means an e-mail address can occures only once in all DB.

(The help came on this list:
http://www.openldap.org/lists/openldap-technical/201808/msg00016.html)


Now, is there any way that I can use the unique rule for every
OU, but not for all. I mean an e-mail address can be used under
several OU, but only once per OU.


Thanks,


a.

Re: Password policy messages - how can I pass back

2018-10-13 Thread Ervin Hegedüs

Hi,

On Fri, Oct 12, 2018 at 05:32:13PM +0200, Ervin Hegedüs wrote:
> Hi all,
> 
> On Thu, Oct 11, 2018 at 09:12:56AM +0200, Clément OUDOT wrote:
> > 
> > This should be possible in PHP 7.3, see
> > https://bugs.php.net/bug.php?id=69437
> 
> could anybody helps me, how can I catch the correct and accurate
> error message?
> 
> if (PHP_VERSION_ID >= 70300) {
> $ctrl1 = array('oid' => LDAP_CONTROL_PASSWORDPOLICYREQUEST, 'value' => 
> NULL, 'iscritical' => 0);
> $src = ldap_set_option($this->ldapconn, LDAP_OPT_SERVER_CONTROLS, 
> array($ctrl1));
> $option = (LDAP_OPT_DIAGNOSTIC_MESSAGE | LDAP_OPT_ERROR_STRING); 
> }
> else {
> $option = LDAP_OPT_DIAGNOSTIC_MESSAGE;
> }
> ldap_get_option($this->ldapconn, $option, $_err);

this is a wrong way, I've re-read the PHP docs, and I think I
have to follow this way:


$conn = ldap_connect("ldaps://host");

ldap_set_option($conn, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($conn, LDAP_OPT_REFERRALS, 0);
ldap_set_option($conn, LDAP_OPT_DEBUG_LEVEL, -1);

$ctrl = array(
'oid' => LDAP_CONTROL_PASSWORDPOLICYRESPONSE,
'iscritical' => FALSE,
'value' => NULL
);

ldap_set_option($conn, LDAP_OPT_SERVER_CONTROLS, array($ctrl));

ldap_bind($conn, $serviceuser, $servicepassw);

ldap_get_option($conn, LDAP_OPT_DIAGNOSTIC_MESSAGE | LDAP_OPT_ERROR_STRING, 
$_err);
var_dump($_err);

ldap_exop_passwd($conn, $userdn, "", $usernewpasswd);

ldap_get_option($conn, LDAP_OPT_DIAGNOSTIC_MESSAGE | LDAP_OPT_ERROR_STRING, 
$_err);

But the ldap_bind returns with FALSE, and the $_err will:

"passwordPolicyRequest control value not absent"


If I leave the 'value' key from $ctrl, the ldap_bind() returns
with TRUE, the ldap_exop_passwd() returns FALSE, and the error
just simple "Constraint error", the $_err string is empty.



I think this is a PHP bug, but if anybody have some expert/idea
about this, just let me know.


Thanks,

a.

Re: Password policy messages - how can I pass back

2018-10-12 Thread Ervin Hegedüs

Hi all,

On Thu, Oct 11, 2018 at 09:12:56AM +0200, Clément OUDOT wrote:
> 
> Le 10/10/2018 à 20:16, Ervin Hegedüs a écrit :
> > I mean:
> >
> > # /usr/bin/ldappasswd -H ldaps://dev-ldap-01 -w "secret" -D 
> > "UID="dminuser,dc=hu" -s "abcdefghijkl" "uid=airween,ou=Users,dc=hu" 
> > Result: Constraint violation (19)
> >
> 
> With LDAP clients like ldappasswd, you need to send the ppolicy client
> control with "-e ppolcy"

it works:
Result: Constraint violation (19)
Additional info: Password is not being changed from existing value
control: 1.3.6.1.4.1.42.2.27.8.5.1 false MAOBAQg=
ppolicy: error=8 (New password is in list of old passwords)

> > Note, that in PHP side I'm using:
> >
> > ldap_get_option($ldapconn, LDAP_OPT_DIAGNOSTIC_MESSAGE, $_err);
> >
> > and $_err variable is empty.
> 
> 
> This should be possible in PHP 7.3, see
> https://bugs.php.net/bug.php?id=69437

could anybody helps me, how can I catch the correct and accurate
error message?

if (PHP_VERSION_ID >= 70300) {
$ctrl1 = array('oid' => LDAP_CONTROL_PASSWORDPOLICYREQUEST, 'value' => 
NULL, 'iscritical' => 0);
$src = ldap_set_option($this->ldapconn, LDAP_OPT_SERVER_CONTROLS, 
array($ctrl1));
$option = (LDAP_OPT_DIAGNOSTIC_MESSAGE | LDAP_OPT_ERROR_STRING); 
}
else {
$option = LDAP_OPT_DIAGNOSTIC_MESSAGE;
}
ldap_get_option($this->ldapconn, $option, $_err);

but the $_err is a string:

string(49) "Password is not being changed from existing value"

There isn't the ppolicy error.

I've tried with values in ldap_set_option $ctrl:
value => 0, value => 0, iscritical => 1, and combinations of
these.



a.

Re: Password policy messages - how can I pass back

2018-10-11 Thread Ervin Hegedüs

Hi Jason,

thanks for reply,

On Wed, Oct 10, 2018 at 01:26:48PM -0500, Jason Trupp wrote:
> I looked at the slapo-ppolicy man page. It's a shame ppolicy doesn't have 
> something like the following from the chain overlay:
> 
> chain-return-error {FALSE|true}
>   In case referral chasing fails, the real error is returned 
> instead of the orig‐
>   inal referral.  In case multiple referral URIs  are  present, 
> only  the  first
>   error  is returned.  This behavior may not be always 
> appropriate nor desirable,
>   since failures in referral chasing might be better resolved by 
> the client (e.g.
>   when caused by distributed authentication issues).

shame or not, I can't use it :).

Looks like I can upgrade the webservers to 7.3, so with this my
problem solved :)


Thanks,


a.

Re: Password policy messages - how can I pass back

2018-10-11 Thread Ervin Hegedüs

Hi Clément,

thanks for feedback,

> > I mean:
> >
> > # /usr/bin/ldappasswd -H ldaps://dev-ldap-01 -w "secret" -D 
> > "UID="dminuser,dc=hu" -s "abcdefghijkl" "uid=airween,ou=Users,dc=hu" 
> > Result: Constraint violation (19)
> >
> > There isn't any detailed information, what's the reason why the
> > policy module drops the request, but I can see that in the logfile:
> >
> > Oct 10 20:05:21 dev-ldap-01 slapd[16312]: check_password_quality: module 
> > error: (pwdCheckModule-poc.so) Passwords less than 16 characters require at 
> > least 3 traits (upper case, lower case, digits, or special characters).[1]
> > Oct 10 20:05:21 dev-ldap-01 slapd[16312]: send_ldap_result: conn=1742 op=1 
> > p=3
> > Oct 10 20:05:21 dev-ldap-01 slapd[16312]: send_ldap_result: err=19 
> > matched="" text="Passwords less than 16 characters require at least 3 
> > traits (upper case, lower case, digits, or special characters)"
> 
> 
> With LDAP clients like ldappasswd, you need to send the ppolicy client
> control with "-e ppolcy"

right, thanks,
 
> > Note, that in PHP side I'm using:
> >
> > ldap_get_option($ldapconn, LDAP_OPT_DIAGNOSTIC_MESSAGE, $_err);
> >
> > and $_err variable is empty.
> 
> 
> This should be possible in PHP 7.3, see
> https://bugs.php.net/bug.php?id=69437

:(

I've fighted with customer for update to 7.2 to get the
ldap_exop_passwd(), now I can go back to fight for PHP 7.3.

Looks like it exists for Debian 9 (non-official):

https://packages.sury.org/php/pool/main/p/php7.3/


Thanks again,


a.

Password policy messages - how can I pass back

2018-10-10 Thread Ervin Hegedüs

Hi there,

there is a password policy external module with this config:

dn: cn=default,ou=pwpolicies,dc=hu
cn: default
objectClass: pwdPolicy
objectClass: pwdPolicyChecker
objectClass: device
pwdAllowUserChange: TRUE
pwdInHistory: 5
pwdMinLength: 10
pwdAttribute: userPassword
pwdCheckQuality: 1
pwdCheckModule: pwdCheckModule-poc.so

I've grabbed this source:

https://github.com/bindle/bofh-pwdCheckModules

Everything works as well: I can change the password with
ldappasswd tool, or ldap_exop() in PHP - the policy check works
in both cases.

I just have one question: is there any way to send back to the
client the error message?

I mean:

# /usr/bin/ldappasswd -H ldaps://dev-ldap-01 -w "secret" -D 
"UID="dminuser,dc=hu" -s "abcdefghijkl" "uid=airween,ou=Users,dc=hu" 
Result: Constraint violation (19)

There isn't any detailed information, what's the reason why the
policy module drops the request, but I can see that in the logfile:

Oct 10 20:05:21 dev-ldap-01 slapd[16312]: check_password_quality: module error: 
(pwdCheckModule-poc.so) Passwords less than 16 characters require at least 3 
traits (upper case, lower case, digits, or special characters).[1]
Oct 10 20:05:21 dev-ldap-01 slapd[16312]: send_ldap_result: conn=1742 op=1 p=3
Oct 10 20:05:21 dev-ldap-01 slapd[16312]: send_ldap_result: err=19 matched="" 
text="Passwords less than 16 characters require at least 3 traits (upper case, 
lower case, digits, or special characters)"


It would be very good to catch this message at client side.

Is it possible?

Note, that in PHP side I'm using:

ldap_get_option($ldapconn, LDAP_OPT_DIAGNOSTIC_MESSAGE, $_err);

and $_err variable is empty.



When I send the old password, which exists in history, I got:

ldappasswd -H ldaps://... ... ... -s "oldpasswd" "uid=airween,..."
Result: Constraint violation (19)
Additional info: Password is not being changed from existing value


in PHP:

"Password is not being changed from existing value"

In syslog I can see:

Oct 10 20:09:36 dev-ldap-01 slapd[16312]: send_ldap_result: err=19 matched="" 
text="Password is not being changed from existing value"
Oct 10 20:09:36 dev-ldap-01 slapd[16312]: send_ldap_extended: err=19 oid= len=0
Oct 10 20:09:36 dev-ldap-01 slapd[16312]: send_ldap_response: msgid=2 tag=120 
err=19
Oct 10 20:09:36 dev-ldap-01 slapd[16312]: conn=1743 op=1 RESULT oid= err=19 
text=Password is not being changed from existing value


Should I fill some member of Entry struct in 3rd argument in
policy module?

int check_password (char *pPasswd, char **ppErrStr, Entry *pEntry)
^^



Thanks,


a.

Re: Trigger-like function

2018-09-24 Thread Ervin Hegedüs

Hi,

thanks Clément,

On Sun, Sep 23, 2018 at 10:24:28PM +0200, Clément OUDOT wrote:
> Le 23/09/2018 à 21:22, Ervin Hegedüs a écrit :
> > On Thu, Sep 20, 2018 at 02:11:43PM +0100, Howard Chu wrote:
> >> Use the smbk5pwd overlay.
> >
> > I've tried it:
[...]

> > but when I changed the userPassword, the sambaNTPassword and
> > sambaLMPassword attributes doesn't changed.
> >
> > What did I missed?
> 
> smbk5pwd overlay only works if password change has been made with
> extended password modify operation (this operation is done with
> ldappasswd, not with ldapmodify).

meanwhile I found that, before I saw your e-mail.

Anyway, is that any solution to prevent that the users modify
their passwords with only ldappasswd (if it knows how does it
works), and deny the using of ldapmodify? I mean can I configure
OpenLDAP ACL rules for this?

Thanks,

a.

Re: Trigger-like function

2018-09-24 Thread Ervin Hegedüs

hi,

On Sun, Sep 23, 2018 at 09:22:59PM +0200, Ervin Hegedüs wrote:
> On Thu, Sep 20, 2018 at 02:11:43PM +0100, Howard Chu wrote:
> > Use the smbk5pwd overlay.
> 
> 
> I've tried it:
> 
> dn: cn=module,cn=config
> cn: module
> objectClass: olcModuleList
> olcModulePath: /usr/lib/ldap/
> olcModuleLoad: smbk5pwd
> 
> 
> dn: olcOverlay=smbk5pwd,olcDatabase={1}mdb,cn=config
> changetype: add
> objectClass: olcSmbK5PwdConfig
> objectClass: olcOverlayConfig
> objectClass: olcConfig
> objectClass: top
> olcOverlay: smbk5pwd
> olcSmbK5PwdEnable: samba
> 
> but when I changed the userPassword, the sambaNTPassword and
> sambaLMPassword attributes doesn't changed.
> 
> What did I missed?

ok, looks like it works also in case of PasswordModify Extended
Option, like ppolicy overlay.



thanks,


a.

Re: Trigger-like function

2018-09-23 Thread Ervin Hegedüs

Hi,

On Thu, Sep 20, 2018 at 02:11:43PM +0100, Howard Chu wrote:
> Ervin Hegedüs wrote:
> > Hi,
> > 
> > as I described in my previous thread[1], I have a web frontend
> > tool, where user can modify its own password - here the password
> > is a set of passwd attributes: userPassword, sambaNTPassword,
> > sambaLMPassword.
> > 
> > Is there any way that when I give access to users to modify its
> > own password, and the user wants to modify it through LDAP(S),
> > instead of out web frontend, the samba passwords also updated
> > (with correct hash algorithm)?
> 
> Use the smbk5pwd overlay.


I've tried it:

dn: cn=module,cn=config
cn: module
objectClass: olcModuleList
olcModulePath: /usr/lib/ldap/
olcModuleLoad: smbk5pwd


dn: olcOverlay=smbk5pwd,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcSmbK5PwdConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: smbk5pwd
olcSmbK5PwdEnable: samba

but when I changed the userPassword, the sambaNTPassword and
sambaLMPassword attributes doesn't changed.

What did I missed?


thanks,


a.

Re: Password policy questions

2018-09-20 Thread Ervin Hegedüs

Hi Ryan,

On Thu, Sep 20, 2018 at 10:18:35AM -0700, Ryan Tandy wrote:
> On Thu, Sep 20, 2018 at 05:49:11PM +0200, Ervin Hegedüs wrote:
> >but I can set up new password with less than 10 characters, eg
> >"abc". What em I missed?
> 
> You explicitly told it not to check quality:
> 
> >pwdCheckQuality: 0

right, then is it mean that the length of password is part of
quality, but the history isn't?


Thanks,


a.

Re: Password policy questions

2018-09-20 Thread Ervin Hegedüs

Hi Quanah,

thanks for reply,

On Thu, Sep 20, 2018 at 09:42:02AM -0700, Quanah Gibson-Mount wrote:
> --On Thursday, September 20, 2018 6:49 PM +0200 Ervin Hegedüs
>  wrote:
> 
> 
> >Is it right?
> 
> Yes.  ppolicy is only triggered by password changes that use the LDAPv3
> Password Modify (RFC 3062) extended operation.

so, it means that the users can bypass with a simple ldapmodify?


> >How can I validate the policy for all methods?
> 
> See above.

but then why history stored and evaulated, but length doesn't?


a.

Password policy questions

2018-09-20 Thread Ervin Hegedüs

Hi,

looks like I've successfully configured the ppolicy overlay, but
I have some questions.

The relevant config:

olcModuleLoad: {0}ppolicy
structuralObjectClass: olcModuleList

dn: olcOverlay={2}ppolicy,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {2}ppolicy
olcPPolicyDefault: cn=default,ou=pwpolicies,dc=hu
olcPPolicyHashCleartext: FALSE
olcPPolicyUseLockout: FALSE

dn: cn=default,ou=pwpolicies,dc=hu
cn: default
objectClass: pwdPolicy
objectClass: pwdPolicyChecker
objectClass: device
pwdAllowUserChange: TRUE
pwdInHistory: 5
pwdMinLength: 10
pwdAttribute: userPassword
pwdCheckQuality: 0


When I change my passwd with ldappasswd, the history check works:

ldappasswd -H ldaps://dev-ldap-01:636 -W -D 
uid=airween,ou=Users,ou=company,dc=comp,DC=hu -S
New password: 
Re-enter new password: 
Enter LDAP Password: 
Result: Constraint violation (19)
Additional info: Password is in history of old passwords

but I can set up new password with less than 10 characters, eg
"abc". What em I missed?


I've never read it, but looks like the policy has effect only
when I'm changing passwd with 'ldappasswd', but when I'm using
ldapmodify, then I can bypass the rules

ldapmodify -H ldaps://dev-ldap-01:636 -D 
'uid=airween,ou=Users,ou=company,dc=comp,dc=hu' -x -W -f file.ldif
modifying entry
"uid=airween,ou=Users,ou=company,dc=comp,DC=hu"

[DONE WITH PREV PASSWD]

Is it right?

How can I validate the policy for all methods?



Thanks,


a.

Re: Trigger-like function

2018-09-20 Thread Ervin Hegedüs

Hi Howard,

On Thu, Sep 20, 2018 at 02:11:43PM +0100, Howard Chu wrote:
> Ervin Hegedüs wrote:
> > Hi,
> > 
> > as I described in my previous thread[1], I have a web frontend
> > tool, where user can modify its own password - here the password
> > is a set of passwd attributes: userPassword, sambaNTPassword,
> > sambaLMPassword.
> > 
> > Is there any way that when I give access to users to modify its
> > own password, and the user wants to modify it through LDAP(S),
> > instead of out web frontend, the samba passwords also updated
> > (with correct hash algorithm)?
> 
> Use the smbk5pwd overlay.

thanks, I'll check it.


a.

Trigger-like function

2018-09-20 Thread Ervin Hegedüs

Hi,

as I described in my previous thread[1], I have a web frontend
tool, where user can modify its own password - here the password
is a set of passwd attributes: userPassword, sambaNTPassword,
sambaLMPassword.

Is there any way that when I give access to users to modify its
own password, and the user wants to modify it through LDAP(S),
instead of out web frontend, the samba passwords also updated
(with correct hash algorithm)?

I've found that the password policy and history should handle
inside of OpenLDAP, only this feature missing.

I've also found slapo-shell and slapo-sock overlays, but as I
interpret those mechanism, they sends the client request to an
external software, so when I want to change the userPassword, the
slapd send this request to the external tool, which sends a
modify request to slapd, which sends the request to external
tool, whcih Em I right?

Or should I use some filter to exclude, which requests sending to
external program and which not?


Is there any solution for this request?


Thanks,


a.



[1]: https://www.openldap.org/lists/openldap-technical/201809/msg00021.html

Re: Insufficient acces in some cases

2018-09-19 Thread Ervin Hegedüs

Hi,

On Tue, Sep 18, 2018 at 11:21:07PM +0200, Clément OUDOT wrote:
> 
> No, the olcAccess {3} deny all access inside dc=bigcompany,dc=hu, the
> rule {4} is never evaluated.

yep,

> > And as I wrote in first mail, the simple "ldapmodify" works as
> > well.
> 
> Do you test to modify only userPassword attribute? Or your modification
> is also on Samba attributes?

SMB attributes modification was denied when I tested today.

> > And more important, the other users under the same OU can change
> > their own userpassword/nt/lm password attributes through PHP.
> 
> I don't how, because your ACL allow only userPassword modification for
> 'self'.

so, you're right, Clément, and thanks for the clarification.

Our end customers desinformed me - today become clear that nobody
can modify their passwords (userPassword, NT/LM passwd) through
the webservice.

I've modified ACL rules, now it works as well - thanks again.

Anyway, it's very interesting, how and why slapd logs that
lines... they also misleaded me.

Thanks,

a.

Re: Insufficient acces in some cases

2018-09-18 Thread Ervin Hegedüs

Hi,

On Tue, Sep 18, 2018 at 11:21:07PM +0200, Clément OUDOT wrote:
> 
> 
> Le 18/09/2018 à 23:10, Ervin Hegedüs a écrit :
> > Hi,
> >
> > On Tue, Sep 18, 2018 at 10:34:55PM +0200, Clément OUDOT wrote:
> >>
> >> Le 18/09/2018 à 22:23, Ervin Hegedüs a écrit :
> >
> > olcAccess: {0}to attrs=userPassword,shadowLastChange
> >   by self write
> >   by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
> >   by anonymous auth
> >   by * none
> > olcAccess: {1}to dn.subtree="ou=OU1,dc=service1,dc=bigcompany,dc=hu"
> >   by dn="uid=_srvuser2,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" 
> > read
> >   by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" 
> > read
> >   by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" 
> > read
> >   by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" 
> > read
> >   by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
> >   by * none
> > olcAccess: {2}to 
> > dn.regex="ou=(comp1|comp2|comp3),dc=service1,dc=bigcompany,dc=hu"
> >   by dn="uid=_srvuser2,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" 
> > read
> >   by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" 
> > read
> >   by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" 
> > read
> >   by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" 
> > read
> >   by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
> >   by * none
> > olcAccess: {3}to dn.subtree="dc=bigcompany,dc=hu"
> >   by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" 
> > read
> >   by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" 
> > read
> >   by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" 
> > read
> >   by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
> >   by * none
> > olcAccess: {4}to *
> >   by self write
> >   by anonymous auth
> >   by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
> >   by * none
> >
> >
> >> Are you sure that a user can modify userPassword and sambaNT/LM password
> >> attributes?
> > yes, I'm sure.
> >
> > The NT/LM password attribures aren't named any place, the
> > userPassword is, but all user can modify its own - see ACL's above.
> 
> No, the olcAccess {3} deny all access inside dc=bigcompany,dc=hu, the
> rule {4} is never evaluated.

well, you're right - but then how does it works for other users?

It's too late here (.hu), I'll check it again tomorrow.

 
> > And as I wrote in first mail, the simple "ldapmodify" works as
> > well.
> 
> Do you test to modify only userPassword attribute? Or your modification
> is also on Samba attributes?

no, I just put the userPassword attribute,
 
> > And more important, the other users under the same OU can change
> > their own userpassword/nt/lm password attributes through PHP.
> 
> I don't how, because your ACL allow only userPassword modification for
> 'self'.

yes, that's very interesting.

and one important thing: if this issue is a "simple" ACL problem,
why logs slapd an interesting lines (one char in a line)? Why
just deny the access...?
 
> > The service user (_srvuser1) also can modify (through PHP), but I'ld
> > like to use as the logged user modify its own passwd.
> >
> 
> I think you should merge your ACL like this:
> 
> olcAccess: {3}to dn.subtree="dc=bigcompany,dc=hu"
>   by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu"
> read
>   by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu"
> read
>   by
> dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
>   by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
>   by self write
>   by * none

thanks, as I wrote, it's too late here to focus the problem, I'll
check it tomorrow with fresh brain :).


Thanks for all,


a.

Re: Insufficient acces in some cases

2018-09-18 Thread Ervin Hegedüs

Hi,

On Tue, Sep 18, 2018 at 10:34:55PM +0200, Clément OUDOT wrote:
> 
> 
> Le 18/09/2018 à 22:23, Ervin Hegedüs a écrit :
> >
> > But then I don't understand, why comes this error only few users
> > (total number of users is about 200 now, we know about 2-3
> > affected user).
> >
> > Anyway, I thought it also what you wrote, and switched back to
> > native LDAP (instead of LDAPS), and make a capture at LDAP side.
> >
> > There aren't any garbage in packets, all request contains
> > absolutely normal lines... If you interesting about it, I can
> > send you a cap file - but that contains sensitive datas, of
> > course.
> >
> > I just can share some screenshots about the traffic, hope it
> > seems that no other garbage:
> >
> > https://www.dropbox.com/sh/x8ol6cfc39zj7cp/AADCo3CgcHPQnvOre4hjuULpa
> 
> 
> It would be be interesting to see how your OpenLDAP ACL are configured.

the ACL system a little bit complicated (I guess), but I think it
works as well:

olcAccess: {0}to attrs=userPassword,shadowLastChange
  by self write
  by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
  by anonymous auth
  by * none
olcAccess: {1}to dn.subtree="ou=OU1,dc=service1,dc=bigcompany,dc=hu"
  by dn="uid=_srvuser2,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
  by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
  by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
  by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
  by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
  by * none
olcAccess: {2}to 
dn.regex="ou=(comp1|comp2|comp3),dc=service1,dc=bigcompany,dc=hu"
  by dn="uid=_srvuser2,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
  by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
  by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
  by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
  by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
  by * none
olcAccess: {3}to dn.subtree="dc=bigcompany,dc=hu"
  by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
  by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
  by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
  by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
  by * none
olcAccess: {4}to *
  by self write
  by anonymous auth
  by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
  by * none


> Are you sure that a user can modify userPassword and sambaNT/LM password
> attributes?
yes, I'm sure.

The NT/LM password attribures aren't named any place, the
userPassword is, but all user can modify its own - see ACL's above.

And as I wrote in first mail, the simple "ldapmodify" works as
well.

And more important, the other users under the same OU can change
their own userpassword/nt/lm password attributes through PHP.

The service user (_srvuser1) also can modify (through PHP), but I'ld
like to use as the logged user modify its own passwd.


Thanks,


a.

Re: Insufficient acces in some cases

2018-09-18 Thread Ervin Hegedüs

Hi,

thanks for reply,

On Tue, Sep 18, 2018 at 09:40:00PM +0200, Clément OUDOT wrote:
> Le 18/09/2018 à 18:11, Ervin Hegedüs a écrit :
> > Hi, there is an interesting insufficient access problem...
> >
> > There are 3 (in dev environment 2) multimaster ldap node.
> >
> > There is a simple web frontend, written in PHP, where user can
> > change its own password, or can get a link to set up a new pass
> > if old one had lost.
> >
> > In some cases (some users) the user can't change the own password
> > through PHP. When I change it from webserver with ldapmodify and
> > a simple ldif file, it works as well.
> >
> > But when I try to modify the passwd through PHP, I got
> > "Insufficient access" error, and these lines are in syslog:
> >
> >
> > Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => access_allowed: search access 
> > to "uid=comp1_user1,ou=Users,ou=COMP1,dc=wificloud,dc=company,dc=hu" 
> > "objectClass" requested
> > Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => dn: [2] 
> > ou=djp,dc=wificloud,dc=company,dc=hu
> > Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => dnpat: [3] 
> > ou=(AH|Delta|Comp1|Comp2|Comp3),dc=wificloud,dc=company,dc=hu nsub: 1
> > Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => acl_get: [3] matched
> > Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => acl_get: [3] attr objectClass
> > Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => match[dn0]: 26 60
> > Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o
> > Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u
...

> > Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d
> > Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c
> > Sep 18 17:48:13 dev-ldap-01 slapd[12125]: =
> > Sep 18 17:48:13 dev-ldap-01 slapd[12125]: h
> > Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u
> > Sep 18 17:48:13 dev-ldap-01 slapd[12125]: 
> >

> 
> I would say that the PHP application is sending some garbage to the
> directory. What application are you using for password change, is it LTB
> Self Service Password ?

no, that's a custom development, which will be extend with many
other features - no matter now.

But then I don't understand, why comes this error only few users
(total number of users is about 200 now, we know about 2-3
affected user).

Anyway, I thought it also what you wrote, and switched back to
native LDAP (instead of LDAPS), and make a capture at LDAP side.

There aren't any garbage in packets, all request contains
absolutely normal lines... If you interesting about it, I can
send you a cap file - but that contains sensitive datas, of
course.

I just can share some screenshots about the traffic, hope it
seems that no other garbage:

https://www.dropbox.com/sh/x8ol6cfc39zj7cp/AADCo3CgcHPQnvOre4hjuULpa


Thanks again,


a.

Insufficient acces in some cases

2018-09-18 Thread Ervin Hegedüs



Hi, there is an interesting insufficient access problem...

There are 3 (in dev environment 2) multimaster ldap node.

There is a simple web frontend, written in PHP, where user can
change its own password, or can get a link to set up a new pass
if old one had lost.

In some cases (some users) the user can't change the own password
through PHP. When I change it from webserver with ldapmodify and
a simple ldif file, it works as well.

But when I try to modify the passwd through PHP, I got
"Insufficient access" error, and these lines are in syslog:


Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => access_allowed: search access to 
"uid=comp1_user1,ou=Users,ou=COMP1,dc=wificloud,dc=company,dc=hu" "objectClass" 
requested
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => dn: [2] 
ou=djp,dc=wificloud,dc=company,dc=hu
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => dnpat: [3] 
ou=(AH|Delta|Comp1|Comp2|Comp3),dc=wificloud,dc=company,dc=hu nsub: 1
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => acl_get: [3] matched
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => acl_get: [3] attr objectClass
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => match[dn0]: 26 60
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: =
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: m
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: p
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: 1
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: ,
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: =
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: w
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: i
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: f
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: i
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: l
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: ,
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: =
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: m
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: p
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: a
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: n
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: y
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: ,
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: =
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: h
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: 

(I replaced names and chars, so the match[dn0] numbers are not
correct).


Only few users can trigger this problem (don't know why), and
only through PHP.


What's the problem here?



Thanks,


a.

Re: Unique overlay confusing

2018-08-30 Thread Ervin Hegedüs

Hi Quanah,

On Thu, Aug 30, 2018 at 06:31:06AM -0700, Quanah Gibson-Mount wrote:
> --On Thursday, August 30, 2018 10:36 AM +0200 Ervin Hegedüs
>  wrote:
> 
> 
> >I'm using jXplorer, I didn't found any manageDsaIt settings, so I
> >assume that it doesn't support, perhaps I can't bypass the
> >enforcement - but may be I'm wrong.
> >
> >The unique key constraint still doesn't work.
> 
> Start with the command line ldapmodify binary instead.  jxplorer does in
> fact set the manageDSAIT flag on some operations.

so, many thanks for your helps, the native ldapmodify works as
well:


# ldapmodify -D "..." -w ... -f modify.ldif
modifying entry
"dn: uid=airween,ou=Users,ou=Administrator,dc=service,dc=customer,dc=hu"
ldap_modify: Constraint violation (19)
additional info: some attributes not unique

I'll check the PHP and Python API's, what do I need to check to
avoid the manageDsaIt.


Thanks for all folks,



a.

Re: Unique overlay confusing

2018-08-30 Thread Ervin Hegedüs

Hi Quanah,

On Thu, Aug 30, 2018 at 06:43:03AM -0700, Quanah Gibson-Mount wrote:
> --On Thursday, August 30, 2018 7:31 AM -0700 Quanah Gibson-Mount
>  wrote:
> 
> >--On Thursday, August 30, 2018 10:36 AM +0200 Ervin Hegedüs
> > wrote:
> >
> >
> >>I'm using jXplorer, I didn't found any manageDsaIt settings, so I
> >>assume that it doesn't support, perhaps I can't bypass the
> >>enforcement - but may be I'm wrong.
> >>
> >>The unique key constraint still doesn't work.
> >
> >Start with the command line ldapmodify binary instead.  jxplorer does in
> >fact set the manageDSAIT flag on some operations.
> 
> In fact, jxplorer causing problems with the unique overlay because it
> *always* sets manageDSAIT has been discussed in the past:
> 
> <http://www.openldap.org/lists/openldap-technical/201307/msg00213.html>

ah, thanks so much - I'll try the ldapmodify, and will refer.


Thanks,


a.

Re: Unique overlay confusing

2018-08-30 Thread Ervin Hegedüs

Hi Quanah,

thanks for your reply,

On Wed, Aug 29, 2018 at 09:17:25AM -0700, Quanah Gibson-Mount wrote:
> --On Thursday, August 09, 2018 9:51 AM +0200 Ervin Hegedüs
>  wrote:
> 
> 
> >>olcUniqueURI: ldap:///?uid?sub?
> >>olcUniqueURI: ldap:///?mail?sub?
> >>olcUniqueURI: ldap:///?uidNumber?sub?
> >>olcUniqueURI: ldap:///?sn?sub?
> >>olcUniqueURI: ldap:///?cn?sub?

I've removed these directives:

> >>olcUniqueURI: ldaps:///?uid?sub?
> >>olcUniqueURI: ldaps:///?mail?sub?
> >>olcUniqueURI: ldaps:///?uidNumber?sub?
> >>olcUniqueURI: ldaps:///?sn?sub?
> >>olcUniqueURI: ldaps:///?cn?sub?
> 
> Using "ldaps://" here is invalid.  These are internal searches that don't
> use the LDAP protocol.

thanks,
 
> One thing you've not shown in your configurations is whether or not the
> {1}mdb,cn=config DB has a rootdn configured for that database instance.  As
> noted in the man page, a rootdn is required on the specific database
> instance for the overlay to function:
> 
> "   The search is performed using the rootdn  of  the  database,  to avoid
>   issues with ACLs preventing the overlay from seeing all of the relevant
>   data. As such, the database must have a rootdn configured."

you think about this?

slapcat -b cn=config | less
...

dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=hu
...
olcRootDN: cn=admin,dc=hu
...


> Additionaly, you haven't noted how you are making the modifications to add
> the duplicate entries. Again, as noted in the man page:
> 
> "  Replication  and  operations  with  manageDsaIt  control are allowed to
>   bypass this enforcement. It is therefore  important  that  all servers
>   accepting  writes  have  this  overlay  configured in order to maintain
>   uniqueness in a replicated DIT.."
> 
> So it is possible the LDAP client you are using to make the modifications is
> setting the manageDsaIT control.

I'm using jXplorer, I didn't found any manageDsaIt settings, so I
assume that it doesn't support, perhaps I can't bypass the
enforcement - but may be I'm wrong.

The unique key constraint still doesn't work.




Thanks again for your help,


a.

Re: Unique overlay confusing

2018-08-27 Thread Ervin Hegedüs

Hi,

sorry for the re-post, but could anybody helps me, how can I
fix this problem?

On Wed, Aug 08, 2018 at 12:51:53PM +0200, Michael Ströder wrote:
> On 8/8/18 12:46 PM, Ervin Hegedüs wrote:
> >On Wed, Aug 08, 2018 at 12:36:06PM +0200, Michael Ströder wrote:
> >>*and*
> >>re-index the DB?
> >
> >no. (never)
> 
> Please check whether the search (mail=f...@example.com) really returns the
> existing entries.

# slapcat -b cn=config | grep -i olcdbindex
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: member,memberUid eq
olcDbIndex: mail eq
olcDbIndex: sn eq

# slapcat -b cn=config | grep -i overlay   
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
olcOverlay: {0}syncprov
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
olcOverlay: {0}syncprov
dn: olcOverlay={1}unique,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
olcOverlay: {1}unique

# ldapsearch -vvv -x -H ldaps://dev-ldap-01:636 -b "dc=hu" -D 
"UID=_srvcppm,OU=Users,ou=_srv,dc=hu" -W "(mail=airw...@company.hu)" 
...
# airween, Users, Administrator, service.customer.hu
dn: uid=airween,ou=Users,ou=Administrator,dc=service,dc=customer,dc=hu
uidNumber: 20001
gidNumber: 1
...
sn: airween
mail: airw...@company.hu

# dgw_airween, Users, Partner, othercustomer.hu
dn: uid=dgw_airween,ou=Users,ou=Partner,dc=othercustomer,dc=hu
uidNumber: 11297
gidNumber: 21297
...
sn: dgw_airween
mail: airw...@company.hu

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2


slapindex was finished (before I searched above...):

# service slapd stop
# slapindex -F /etc/ldap/slapd.d -n 1 mail sn cn uidNumber uid 

WARNING!
Runnig as root!
There's a fair chance slapd will fail to start.
Check file permissions!

# chown -R openldap:openldap /etc/ldap/slapd.d && chown -R openldap:openldap 
/var/lib/ldap
# service slapd start
...





Thanks,


a.

Re: Unique overlay confusing

2018-08-08 Thread Ervin Hegedüs

Hi there,

sorry for the reply,

On Wed, Aug 08, 2018 at 01:26:28PM +0200, Ervin Hegedüs wrote:
> Hi Michael,
> 
> On Wed, Aug 08, 2018 at 12:51:53PM +0200, Michael Ströder wrote:
> > On 8/8/18 12:46 PM, Ervin Hegedüs wrote:
> > >On Wed, Aug 08, 2018 at 12:36:06PM +0200, Michael Ströder wrote:
> > >>*and*
> > >>re-index the DB?
> > >
> > >no. (never)
> > 
> > Please check whether the search (mail=f...@example.com) really returns the
> > existing entries.
> 
> # slapindex -n 1
> ...
> 
> # ... modified the entry's mail to an existing one...
> 
> # ldapsearch -vvv -x -H ldaps://dev-ldap-01:636 -b "dc=hu" -D "admin..." -w 
> "mail=airw...@company.hu" | grep ^mail
> ldap_initialize( ldaps://dev-ldap-01:636/??base )
> Enter LDAP Password: 
> filter: mail=airw...@company.hu
> requesting: All userApplication attributes
> mail: airw...@company.hu
> mail: airw...@company.hu
> 
> (there are two entries)
> 
> # ... rollback the modification ...
> 
> # ldapsearch -vvv -x -H ldaps://dev-ldap-01:636 -b "dc=hu" -D "admin..." -w 
> "mail=airw...@company.hu" | grep ^mail
> ldap_initialize( ldaps://dev-ldap-01:636/??base )
> Enter LDAP Password: 
> filter: mail=airw...@company.hu
> requesting: All userApplication attributes
> mail: airw...@company.hu
> 
> (there is only one entry)
> 
> 
> relevant output of 'slapcat -b cn=config':
> 
> dn: cn=module{2},cn=config
> objectClass: olcModuleList
> cn: module{2}
> olcModulePath: /usr/lib/ldap/
> olcModuleLoad: {0}unique.la
> structuralObjectClass: olcModuleList
> 
> ...
> 
> dn: olcOverlay={1}unique,olcDatabase={1}mdb,cn=config
> objectClass: olcOverlayConfig
> objectClass: olcUniqueConfig
> olcOverlay: {1}unique
> olcUniqueURI: ldap:///?uid?sub?
> olcUniqueURI: ldap:///?mail?sub?
> olcUniqueURI: ldap:///?uidNumber?sub?
> olcUniqueURI: ldap:///?sn?sub?
> olcUniqueURI: ldap:///?cn?sub?
> olcUniqueURI: ldaps:///?uid?sub?
> olcUniqueURI: ldaps:///?mail?sub?
> olcUniqueURI: ldaps:///?uidNumber?sub?
> olcUniqueURI: ldaps:///?sn?sub?
> olcUniqueURI: ldaps:///?cn?sub?
> 
> ...
> 
> dn: olcDatabase={1}mdb,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcMdbConfig
> olcDatabase: {1}mdb
> olcDbDirectory: /var/lib/ldap
> olcSuffix: dc=hu
> ...
> olcDbIndex: objectClass eq
> olcDbIndex: cn,uid eq
> olcDbIndex: uidNumber,gidNumber eq
> olcDbIndex: member,memberUid eq
> olcDbIndex: mail eq
> olcDbIndex: sn eq
> 


any idea?


Thanks,

a.

Re: Unique overlay confusing

2018-08-08 Thread Ervin Hegedüs

Hi Michael,

On Wed, Aug 08, 2018 at 12:51:53PM +0200, Michael Ströder wrote:
> On 8/8/18 12:46 PM, Ervin Hegedüs wrote:
> >On Wed, Aug 08, 2018 at 12:36:06PM +0200, Michael Ströder wrote:
> >>*and*
> >>re-index the DB?
> >
> >no. (never)
> 
> Please check whether the search (mail=f...@example.com) really returns the
> existing entries.

# slapindex -n 1
...

# ... modified the entry's mail to an existing one...

# ldapsearch -vvv -x -H ldaps://dev-ldap-01:636 -b "dc=hu" -D "admin..." -w 
"mail=airw...@company.hu" | grep ^mail
ldap_initialize( ldaps://dev-ldap-01:636/??base )
Enter LDAP Password: 
filter: mail=airw...@company.hu
requesting: All userApplication attributes
mail: airw...@company.hu
mail: airw...@company.hu

(there are two entries)

# ... rollback the modification ...

# ldapsearch -vvv -x -H ldaps://dev-ldap-01:636 -b "dc=hu" -D "admin..." -w 
"mail=airw...@company.hu" | grep ^mail
ldap_initialize( ldaps://dev-ldap-01:636/??base )
Enter LDAP Password: 
filter: mail=airw...@company.hu
requesting: All userApplication attributes
mail: airw...@company.hu

(there is only one entry)

relevant output of 'slapcat -b cn=config':

dn: cn=module{2},cn=config
objectClass: olcModuleList
cn: module{2}
olcModulePath: /usr/lib/ldap/
olcModuleLoad: {0}unique.la
structuralObjectClass: olcModuleList

...

dn: olcOverlay={1}unique,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcUniqueConfig
olcOverlay: {1}unique
olcUniqueURI: ldap:///?uid?sub?
olcUniqueURI: ldap:///?mail?sub?
olcUniqueURI: ldap:///?uidNumber?sub?
olcUniqueURI: ldap:///?sn?sub?
olcUniqueURI: ldap:///?cn?sub?
olcUniqueURI: ldaps:///?uid?sub?
olcUniqueURI: ldaps:///?mail?sub?
olcUniqueURI: ldaps:///?uidNumber?sub?
olcUniqueURI: ldaps:///?sn?sub?
olcUniqueURI: ldaps:///?cn?sub?

...

dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=hu
...
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: member,memberUid eq
olcDbIndex: mail eq
olcDbIndex: sn eq

Thanks,

a.

Re: Unique overlay confusing

2018-08-08 Thread Ervin Hegedüs

Hi there,

On Wed, Aug 08, 2018 at 11:43:56AM +0100, Howard Chu wrote:
> Michael Ströder wrote:
> >On 8/8/18 11:25 AM, Ervin Hegedüs wrote:
> >>I've followed the docs (and some forums), and made these
> >>modifications:
> >>
> >>(OpenLDAP doc:
> >>http://www.openldap.org/doc/admin24/overlays.html#Attribute%20Uniqueness)
> >>
> >>but I still can set the mail attribute as same e-mail address
> >>for two different users.
> >
> >It should just work. Which OpenLDAP version and builds are you using?
> >
> >Wild guess: Did you also add an eq-index for the unique attributes *and* 
> >re-index the DB?
> 
> (Note - adding an index by LDAPmodify'ing cn=config automatically reindexes 
> the DB...)

so, I just need to add the index, like

dn: olcDatabase={1}mdb,cn=config
changetype: modify
delete: olcDbIndex
-
add: olcDbIndex
olcDbIndex: objectClass eq
-
... existing indexes...
-
add: olcDbIndex
olcDbIndex: mail eq
-
... other unique indexes...


?


thanks,


a.

Re: Unique overlay confusing

2018-08-08 Thread Ervin Hegedüs

Hi Michael,

thanks,

On Wed, Aug 08, 2018 at 12:36:06PM +0200, Michael Ströder wrote:
> On 8/8/18 11:25 AM, Ervin Hegedüs wrote:
> >I've followed the docs (and some forums), and made these
> >modifications:
> >
> >(OpenLDAP doc:
> >http://www.openldap.org/doc/admin24/overlays.html#Attribute%20Uniqueness)
> >
> >but I still can set the mail attribute as same e-mail address
> >for two different users.
> 
> It should just work. Which OpenLDAP version and builds are you using?

2.4.44 (Debian 9 - exactly: 2.4.44+dfsg-5+deb9u1)

> Wild guess: Did you also add an eq-index for the unique attributes

no,

(or yes, at my very first try)

> *and*
> re-index the DB?

no. (never)

Now I checked these infos in docs page and manual, but didn't
found... In documentation the essential info is that I have to
load the overlay, and set the olcUniqueURI(s).


I'll try to do these steps...


thanks again,


a.

Unique overlay confusing

2018-08-08 Thread Ervin Hegedüs

Hi there,

I've followed the docs (and some forums), and made these
modifications:

(OpenLDAP doc:
http://www.openldap.org/doc/admin24/overlays.html#Attribute%20Uniqueness)


dn: cn=module,cn=config
cn: module
objectClass: olcModuleList
olcModulePath: /usr/lib/ldap/
olcModuleLoad: unique.la


dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcUniqueConfig
olcOverlay: unique
olcUniqueAttribute: uid
olcUniqueAttribute: mail
olcUniqueAttribute: uidNumber
olcUniqueAttribute: sn
olcUniqueAttribute: cn


but I still can set the mail attribute as same e-mail address
for two different users.

I've tried this config too:

dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcUniqueConfig
olcOverlay: unique
olcUniqueUri: ldap:///?uid?sub?
olcUniqueUri: ldap:///?mail?sub?
olcUniqueUri: ldap:///?uidNumber?sub?
olcUniqueUri: ldap:///?sn?sub?
olcUniqueUri: ldap:///?cn?sub?


What em'I missing?


Thanks,


a.

Re: MDB_INVALID: File is not an LMDB file

2018-05-30 Thread Ervin Hegedüs

Hi,

On Wed, May 30, 2018 at 11:10:41AM -0400, Chris Trenkamp wrote:
> My program suddenly started returning this error, "MDB_INVALID: File
> is not an LMDB file" whenever it tries to open the database file.  It
> is running on Windows.
> 
> I made a copy of the database, compiled lmdb with MDB_DEBUG set to 2
> and ran this program:
> 
> #include 
> #include "lmdb.h"
> 
> int main(int argc, char* argv[]) {
>   int rc;
>   MDB_env *env;
>   rc = mdb_env_create(&env);
>   printf("%d\n", rc);
>   rc = mdb_env_open(env, "./brokedb", 0, 0644);
>   printf("%d\n", rc);
> }
> 
> And it gave this output:
> 0
> mdb_env_read_header:4040 page 0 not a meta page
> -30793
> 
> Does anyone know how this might have happened, and things to look for
> in my program that might have caused this?  Is there a way to recover
> the data from the file?

I think you should use this form of mdb_env_open:

mdb_env_open(env, "./brokedb", MDB_WRITEMAP | MDB_NOSUBDIR, 0664);

see:

http://www.lmdb.tech/doc/group__mdb.html
CTRL-F - mdb_env_open -> parameters -> flags



Regards,


a.

Re: Search only few subtrees under baseDN

2018-05-13 Thread Ervin Hegedüs

Hi Dieter,

thanks for the reply,

On Sun, May 13, 2018 at 06:17:08PM +0200, Dieter Klünter wrote:
> Am Sun, 13 May 2018 09:42:22 +0200
> schrieb Ervin Hegedüs :
> 
> > How can I add the OU alias, with all children?
> 
> Objectclasses aliasedObjectName and organizationalUnit are both
> structural Objectclasses, try to add auxiliary object classes, or
> create your own classes. Some documentation include extensibleObject
> class, but this would create additional security questions.

the solution:

dn: ou=collection1,dc=sub-company21,dc=company2,dc=hu
changetype: add
objectClass: organizationalUnit
objectClass: top
ou: collection1

dn: ou=orgunit1,ou=collection1,dc=sub-company21,dc=company2,dc=hu
changetype: add
aliasedObjectName: ou=orgunit1,dc=sub-company21,dc=company2,dc=hu
objectClass: alias
objectClass: top
objectClass: extensibleObject
ou: orgunit1


And one more thing: it must be pass the "-a always" argument to
ldapsearch to use that subtree. User needs access to
ou=collection1.


Thanks,


a.

Re: Search only few subtrees under baseDN

2018-05-13 Thread Ervin Hegedüs

Hi,

On Thu, May 10, 2018 at 06:02:48PM +0200, Ervin Hegedüs wrote:
> Hi again,
> 
> On Wed, May 09, 2018 at 01:00:05PM +0200, Ervin Hegedüs wrote:
> > Hi,
> > 
> [...]
>  
> > 
> > Is there any way to set up one or more ACL's, where admin1 user
> > can set up the dc=sub-company21,dc=company2,dc=hu as baseDN, and
> > can start to search from there, but he will see the entries only
> > from ou=orgunit1 and ou=orgunit2?
> 
> if there isn't any solution with ACL, can I make it some other
> way? I mean, back_meta, rewrite, or other overlay solutions...?
> 


I'm playing with aliases, thought I can make it with it.

The tree:

dn: ou=orgunit1,dc=sub-company21,dc=company2,dc=hu
dn: ou=orgunit2,dc=sub-company21,dc=company2,dc=hu
dn: ou=orgunit3,dc=sub-company21,dc=company2,dc=hu

and the new "collection":
dn: ou=collection1,dc=sub-company21,dc=company2,dc=hu

I'ld like to add an alias from ou=orgunit1 under ou=collection1:

dn: ou=orgunit1,dc=sub-company21,dc=company2,dc=hu
changetype: add
objectClass: alias
objectClass: top
objectClass: organizationalUnit
aliasedObjectName: ou=orgunit1,ou=collection1,dc=sub-company21,dc=company2,dc=hu

but the ldapadd gives:

invalid structural object class chain (alias/organizationalUnit)

I've tried to add the alias as dn=aliased_name, and
aliasedObjectName is the original, but same result.


How can I add the OU alias, with all children?


Thanks,


a.

Re: Search only few subtrees under baseDN

2018-05-10 Thread Ervin Hegedüs

Hi Philip,

thanks for the reply,

On Thu, May 10, 2018 at 09:12:18AM -0700, Philip Guenther wrote:
> On Thu, 10 May 2018, Ervin Hegedüs wrote:
> > On Wed, May 09, 2018 at 01:00:05PM +0200, Ervin Hegedüs wrote:
> > > Is there any way to set up one or more ACL's, where admin1 user
> > > can set up the dc=sub-company21,dc=company2,dc=hu as baseDN, and
> > > can start to search from there, but he will see the entries only
> > > from ou=orgunit1 and ou=orgunit2?
> > 
> > if there isn't any solution with ACL, can I make it some other
> > way? I mean, back_meta, rewrite, or other overlay solutions...?
> 
> An LDAP filter can test the components of an entry's DN with a clause such 
> as:
>(|(ou:dn:=orgunit1)(ou:dn:=orgunit2))
> 
> Note the ":dn" syntax there.

thanks - it doesn't work.

ldapsearch -H ldaps://ldap:636 -b "dc=sub-company21,dc=company,dc=hu" -D 
"cn=admin,dc=hu" -W "(ou:dn:=orgunit1)"

works, and the result reduced only for the OU=orgunit1,dc=sub-

so, the syntax (and idea :)) is right.


ldapsearch -H ldaps://ldap:636 -b 
"ou=orgunit1,dc=sub-company21,dc=company2,dc=hu" -D 
"uid=adminuser1,ou=Users,ou=_srv,dc=sub-company21,dc=company2,dc=hu" -W 
"(ou:dn:=orgunit1)"

also works, but the baseDN starts with "ou=orgunit1", which is
sets up exactly in ACL.


finally,

ldapsearch -H ldaps://ldap:636 -b "dc=sub-company21,dc=company2,dc=hu" -D 
"uid=adminuser1,ou=Users,ou=_srv,dc=sub-company21,dc=company2,dc=hu" -W 
"(ou:dn:=orgunit1)"

where the baseDN is the parent of allowed OU's, and filter
contains the allowed OU('s), then it doesn't work.

Note, that if it should worked, I'm not sure that this could be
usable, because in most LDAP GUI, the connection settings doesn't
contains any filter option, only the baseDN, what you can set up.


> Perhaps an ACL using an LDAP filter containing something like that would 
> be part of a solution.

could you show me any example?


Thanks for your help,


a.

Re: Search only few subtrees under baseDN

2018-05-10 Thread Ervin Hegedüs

Hi again,

On Wed, May 09, 2018 at 01:00:05PM +0200, Ervin Hegedüs wrote:
> Hi,
> 
[...]
 
> 
> Is there any way to set up one or more ACL's, where admin1 user
> can set up the dc=sub-company21,dc=company2,dc=hu as baseDN, and
> can start to search from there, but he will see the entries only
> from ou=orgunit1 and ou=orgunit2?

if there isn't any solution with ACL, can I make it some other
way? I mean, back_meta, rewrite, or other overlay solutions...?


Thanks,

a.

Search only few subtrees under baseDN

2018-05-09 Thread Ervin Hegedüs

Hi,

may be the subject doesn't give back my real quastion... and may
be this is a returned topic... sorry.

Scenario: there is a database with several DC's, all DC's divided to
several OU's, and most OU contains several other OU's.

dc=hu
+ dc=company1
+ dc=company2
  + dc = sub-company21
+ ou = orgunit1
+ ou = orgunit2
+ ou = orgunit3

and there are several users.

Take a look two examples:

uid=admin1,ou=some-org,dc=sub-company21,dc=company2,dc=hu needs to
read the ou=orgunit1 and ou=orgunit2.

uid=admin2,ou=some-org,dc=sub-company21,dc=company2,dc=hu needs
to read full dc=sub-company21 subtree.


All of them are WORKING now as well with ACL's.


But now, the admin1 user needs to set up two different connections
in GUI browser, because he can't set up the
dc=sub-company21,dc=company2,dc=hu as baseDN.

When he uses the search through API, then he needs to make 2
different lookup to collect all nodes from DB, and merge them.


Is there any way to set up one or more ACL's, where admin1 user
can set up the dc=sub-company21,dc=company2,dc=hu as baseDN, and
can start to search from there, but he will see the entries only
from ou=orgunit1 and ou=orgunit2?


Hope that's clear...


Thanks,


a.

Re: Incosistent config after schema modification

2018-01-11 Thread Ervin Hegedüs

Hi Michael,


On Thu, Jan 11, 2018 at 10:04:22AM +0100, Michael Ströder wrote:
> Ervin Hegedüs wrote:
> > Hi,
> > 
> > On Wed, Jan 10, 2018 at 12:17:47PM -0800, Quanah Gibson-Mount wrote:
> >> --On Wednesday, January 10, 2018 9:11 PM +0100 Ervin Hegedüs
> >>  wrote:
> >>
> >>> is there any relevant difference between the replace and
> >>> delete/add methods, which triggered this state in the DB?
> >>
> >> Jon already answered that.  When you use replace, it replaces *all* values
> >> with what you supply in the operation.
> > 
> > but he wrote the answer for MULTI-VALUE's attribute, but I'm
> > useing SINGLE-VALUE - or em I missing?
> 
> While the attribute types you're defining might be SINGE-VALUE the
> attribute 'olcAttributeTypes' you're adding the attribute type
> descriptions to is indeed multi-valued. Otherwise you could not add
> multiple values (here attribute type descriptions) to it.

meantime turned out to me, that in first answer Jon talked about
the more-that-one attributes, when he wrote "You cannot use a
replace operation to replace individual values of a multi-valued
attribute". I mixed out these concepts.

> >> Don't use replace.
> > 
> > right, after this issue I'll never use it :).
> > 
> > But I still don't understand, that when I replace the *all*
> > values to the supplied type(s), then why disappears the "other"
> > attributes, which weren't listed in transaction?
> 
> Because that's how LDAP modify operations with MOD_REPLACE work.
> 
> See description of "operation" herein:
> 
> https://tools.ietf.org/html/rfc4511#section-4.6

thanks, perhaps the relevant part is this:

replace: replace all existing values [...] A replace with no value
will delete the entire attribute if it exists.

> Also it's a good idea to take a look at Howard's draft about ordered
> entries and values because 'olcAttributeTypes' is declared with X-ORDERED:
> 
> https://tools.ietf.org/html/draft-chu-ldap-xordered
I'll check it out - thanks.

Anyway, I'm doing fine the modifications of schema :).


thanks for all,


a.

Re: Incosistent config after schema modification

2018-01-11 Thread Ervin Hegedüs

Hi Quanah,

On Wed, Jan 10, 2018 at 01:29:05PM -0800, Quanah Gibson-Mount wrote:
> --On Wednesday, January 10, 2018 10:23 PM +0100 Ervin Hegedüs
>  wrote:
> 
> >thanks - now it's clear.
> >
> >Just one question: is it possible to change its types with delete
> >and re-add again, instead of replace?
> 
> Generally you want to use delete/add and not replace, as noted.  I hope that
> answers the question, as I'm not 100% clear what you're asking. ;)

sure :) - and sorry, I meant that if I want to change the type of
few arguments, then I can do it with delete/add. Also I can do it
with all arguments.

And in case of all arguments, I can use replace (as I did it
today).

Thanks for your pation and help,

a.

Re: Incosistent config after schema modification

2018-01-11 Thread Ervin Hegedüs

Hi Quanah,

On Wed, Jan 10, 2018 at 01:03:42PM -0800, Quanah Gibson-Mount wrote:
> >but he wrote the answer for MULTI-VALUE's attribute, but I'm
> >useing SINGLE-VALUE - or em I missing?
> 
> This is clearly multiple values for the "olcAttributeTypes" attribute:
> 
> dn: cn={5}cppm,cn=schema,cn=config
> changetype: modify
> replace: olcAttributeTypes
> olcAttributeTypes: {0}( cppmAttrs:1 NAME 'cppmCreateTime' DESC 'Create time'
>  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE )
> olcAttributeTypes: {5}( cppmAttrs:6 NAME 'cppmExpireTime' DESC 'Expire time'
>  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE )
> olcAttributeTypes: {7}( cppmAttrs:8 NAME 'cppmActivationTime' DESC 'Activati
> on time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE )
> 
> You supplied 3 values for it with a replace operation.  Which means *only*
> those 3 values now exist for that object.

thanks - now it's clear.

Just one question: is it possible to change its types with delete
and re-add again, instead of replace?


a.

Re: Incosistent config after schema modification

2018-01-11 Thread Ervin Hegedüs

Hi,

On Wed, Jan 10, 2018 at 12:17:47PM -0800, Quanah Gibson-Mount wrote:
> --On Wednesday, January 10, 2018 9:11 PM +0100 Ervin Hegedüs
>  wrote:
> 
> >is there any relevant difference between the replace and
> >delete/add methods, which triggered this state in the DB?
> 
> Jon already answered that.  When you use replace, it replaces *all* values
> with what you supply in the operation.

but he wrote the answer for MULTI-VALUE's attribute, but I'm
useing SINGLE-VALUE - or em I missing?

> >What's the solution to avoid this?
> 
> Don't use replace.

right, after this issue I'll never use it :).

But I still don't understand, that when I replace the *all*
values to the supplied type(s), then why disappears the "other"
attributes, which weren't listed in transaction? And why allows
this transaction the DB, and then gone to a wrong state?

a.

Re: [EXTERNAL] Incosistent config after schema modification

2018-01-11 Thread Ervin Hegedüs

Hi Quanah,

thanks,

On Wed, Jan 10, 2018 at 10:24:22AM -0800, Quanah Gibson-Mount wrote:
> --On Wednesday, January 10, 2018 6:16 PM + Jon C Kidder
[...]
 
> As a side note, you can delete specific values by using their weight, as
> well.  For example:
> 
> dn: 
> changetype: modify
> delete: olcAttributeTypes
> olcAttributeTypes: {7}
> 
> Would delete the 8th attribute (since the weights are zero based)
> 
> You can also use the weight to insert a value, like:
> 
> dn: 
> changetype: modify
> add: olcAttributeTypes
> olcAttributeTypes: {7}( cppmAttrs:8 NAME 'cppmActivationTime' DESC 'Activati
> on time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE )
> 
> would insert cppmAttrs as the 8th value, and anything from what was the 8th
> value and up would be renumbered accordingly.

is there any relevant difference between the replace and
delete/add methods, which triggered this state in the DB?

What's the solution to avoid this?

Thanks,


a.

Re: [EXTERNAL] Incosistent config after schema modification

2018-01-11 Thread Ervin Hegedüs

Hi All,

Jon, thanks for the reply,

My first (off-topic) question: why did my e-mail came as
"EXTERNAL"? Before I sent it, I've checked myself, and looks like
I'm member of this list...

On Wed, Jan 10, 2018 at 06:16:59PM +, Jon C Kidder wrote:
> To replace individual values of a multi-valued attribute you must
> explicitly delete the old value and then add the new one in
> the same transaction.  You cannot use a replace operation to
> replace individual values of a multi-valued attribute.  The
> replace operation removes all pre-existing values.  After loading
> your ldif your custom schema will only contain the 3 attributes
> included in your ldif.   All of your other custom attributes will
> be gone.

those attribute types are SINGLE-VALUE's. I don't understand
this part of your answer.

> At this point you will need to create and load a new ldif that
> will add all of the missing attribute definitions.  When I
> modify a custom schema I use the replace operation but my ldif
> contains all of the object class and attribute type definitions
> related to that schema.  This way the schema can be maintained
> as a versioned artifact in my version control system.

yes, I've found the solution as you descibed here.

But I'm curious, why occured this state in the DB?

When I run the ldapmodify, the modification replicated
immediatelly to all nodes of cluster, and all db came as
incosistent.

IMHO the expected result would be an error, when I run the
ldapmodify command with these ldif.

Thanks again,

a.

Incosistent config after schema modification

2018-01-10 Thread Ervin Hegedüs

Hi there,

here are a 3 member multimaster config with OpenLDAP 2.4.44
(Debian 9.3).

We need a custom schema, so I've made that - everithing has
worked as well, but the customer said he needs to modify some
attribute type in the new custom schema.

I've made an ldif:

dn: cn={5}cppm,cn=schema,cn=config
changetype: modify
replace: olcAttributeTypes
olcAttributeTypes: {0}( cppmAttrs:1 NAME 'cppmCreateTime' DESC 'Create time'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE )
olcAttributeTypes: {5}( cppmAttrs:6 NAME 'cppmExpireTime' DESC 'Expire time'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE )
olcAttributeTypes: {7}( cppmAttrs:8 NAME 'cppmActivationTime' DESC 'Activati
 on time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE )

# ldapmodify -Y EXTERNAL -H ldapi:/// -f mod1.ldif 
SASL/EXTERNAL authentication started
SASL username:
gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn={5}cppm,cn=schema,cn=config"

Then I'ld liked to add this new objectclass to a member of tree,
but I got an error:

"cppmDomainName: attribute type undefined"

but - of corse - I've added this attribute to the original
schema.

So, I'ld like to backup the config database, but the slapcat
said:

# slapcat -b cn=config
5a562aa7 olcObjectClasses: value #0 olcObjectClasses: AttributeType not found: 
"cppmVisitorCompany"
5a562aa7 config error processing cn={5}cppm,cn=schema,cn=config: 
olcObjectClasses: AttributeType not found: "cppmVisitorCompany"
slapcat: bad configuration file!


What's happenned? What em'I wrong? And what should I do now?


Thanks,


a.

Database limit(s)

2017-12-16 Thread Ervin Hegedüs

Hi there,

I'ld like to ask, is there any hard or soft limit in database? I mean, how
many object canbe stored in the DB? Or how many children object could under
a parent?

I've read the docs about the limits (
http://www.openldap.org/doc/admin24/limits.html), but there are only the
sizelimit and timelimit (which aren't affected me now).

In other words, which parameters do I check before I start to design a
database (LDAP/non-LDAP (eg. OS) parameters)?

Thanks,


a.

Re: Admin roles by group membership per OU

2017-10-16 Thread Ervin Hegedüs

Hi Quanah,

On Mon, Oct 16, 2017 at 07:58:45AM -0700, Quanah Gibson-Mount wrote:
> --On Monday, October 16, 2017 5:55 PM +0200 Ervin Hegedüs
>  wrote:
> 
> 
> >without any real testing, I'm afraid that the rule{0} gives the
> >write access to cn=groupabcadmin to _all_ db, not just the ou=ABC
> >Cumstomer subtree.
> >
> >Em I right?
> 
> Hm, yes, that's correct.  You'll need to do something like utilize by *
> break appropriately, or have multiple "access to userPassword" ACLs by
> group, then a catchall after that.

I'm sorry - could you give me an example?

I just started to use the LDAP acl since few days... :)

I don't belive that this need is generated first time, but I
don't found any example, or case-study.



Thanks again,


a.

Re: Admin roles by group membership per OU

2017-10-16 Thread Ervin Hegedüs

Hi Quanah,

On Mon, Oct 16, 2017 at 07:42:39AM -0700, Quanah Gibson-Mount wrote:
> --On Monday, October 16, 2017 11:45 AM +0200 Ervin Hegedüs
> >and a member of cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu
> >can modify any attributes at any users under the ou=ABC Customer,
> >EXCEPT the userPassword - when I want to modify that, I get
> >permission error:
> 
> That would be expected, given your ACLs.

right,

> >How can I combine the attrs and group permissions? Should I list
> >all attributes in rule?
> 
> You need to add a rule in the userPassword ACL to allow the group to write
> to the attribute.  ACLs are processed in the order they are listed, and STOP
> at the first match.  This is clearly documented in the slapd.access(5) man
> page.
> 
> I.e., you would need:
> 
> dn: olcDatabase={1}mdb,cn=config
> olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by 
> anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by 
> group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write
> olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self 
> write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" 
> write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read
> olcAccess: {2}to * by * read

without any real testing, I'm afraid that the rule{0} gives the
write access to cn=groupabcadmin to _all_ db, not just the ou=ABC Cumstomer
subtree.

Em I right?

There will be several OU's, and all OU will have an admin group.
All member of _that_ group under the own OU will have write
permission.

Note, that the users will _not_ allow the LDAP directly, they
will be use a webapp. So, if this idea is too complax and/or too
dangerous, then there will be only one dedicated user (for
webapp), who will have the admin rights. But the users will
authenticated themselves from LDAP, and the group membership will
choose, which methods allowed on which subtree.

I think that the LDAP auth and group membership checking is
more clean solution - but it needs a good and stable access
hierarcy.

What do you think about it?

> I would note again that "by * none" is implicit on any ACL, there's no need
> to specifically list it.

right, that's clear.

Thanks,

a.

Re: Admin roles by group membership per OU

2017-10-16 Thread Ervin Hegedüs

Hi all,

On Thu, Oct 12, 2017 at 11:06:00AM -0700, Quanah Gibson-Mount wrote:
> 
> 
> So for your back-mdb database, what one would expect is more something like:
> 
> olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
> anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read
> olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self
> write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu"
> write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read
> olcAccess: {2}to * by * read

now the rules are:

dn: olcDatabase={1}mdb,cn=config
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous 
auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by * none
olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self 
write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" 
write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read
olcAccess: {2}to * by * read


and a member of cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu
can modify any attributes at any users under the ou=ABC Customer,
EXCEPT the userPassword - when I want to modify that, I get
permission error:

ldap_modify: Insufficient access (50)

Oct 16 10:42:05 open-ldap slapd[31421]: => access_allowed: result not in cache 
(userPassword)
Oct 16 10:42:05 open-ldap slapd[31421]: => access_allowed: delete access to 
"uid=abc_airween,ou=ABC Customer,dc=core,dc=hdt,dc=hu" "userPassword" requested
Oct 16 10:42:05 open-ldap slapd[31421]: => acl_get: [1] attr userPassword
Oct 16 10:42:05 open-ldap slapd[31421]: => acl_mask: access to entry 
"uid=abc_airween,ou=ABC Customer,dc=core,dc=hdt,dc=hu", attr "userPassword" 
requested
Oct 16 10:42:05 open-ldap slapd[31421]: => acl_mask: to all values by 
"uid=abc_user1,ou=abc customer,dc=core,dc=hdt,dc=hu", (=0)
Oct 16 10:42:05 open-ldap slapd[31421]: <= check a_dn_pat: self
Oct 16 10:42:05 open-ldap slapd[31421]: <= check a_dn_pat: anonymous
Oct 16 10:42:05 open-ldap slapd[31421]: <= check a_dn_pat: 
uid=repuser,dc=core,dc=hdt,dc=hu
Oct 16 10:42:05 open-ldap slapd[31421]: <= check a_dn_pat: *
Oct 16 10:42:05 open-ldap slapd[31421]: <= acl_mask: [4] applying none(=0) 
(stop)
Oct 16 10:42:05 open-ldap slapd[31421]: <= acl_mask: [4] mask: none(=0)
Oct 16 10:42:05 open-ldap slapd[31421]: => slap_access_allowed: delete access 
denied by none(=0)
Oct 16 10:42:05 open-ldap slapd[31421]: => access_allowed: no more rules


How can I combine the attrs and group permissions? Should I list
all attributes in rule?


Thanks,

a.

Re: Admin roles by group membership per OU

2017-10-12 Thread Ervin Hegedüs

Hi Michael,

On Thu, Oct 12, 2017 at 10:34:09PM +0200, Michael Ströder wrote:
> Ervin Hegedüs wrote:
> > olcAccess: {0}to attrs=userPassword,shadowLastChange by self write
> 
> Additional side notes regarding this ACL above (which is often used in
> tutorials):
> 
> 1. You should use slapo-ppolicy instead of deprecated 'shadowLastChange'
> attribute to enforce password expiry.

thanks - I'm relative "new" (recurrent after many years) in
OpenLDAP. Most concept is very new for me, especially this one
above (slapo-ppolicy).

I have to read the related documentation.

> 2. With this ACL the user can extend the password validity period
> himself which renders password expiry ineffective.

good catch, I'll review the rules again tomorrow.

Thanks again!

a.

Re: Admin roles by group membership per OU

2017-10-12 Thread Ervin Hegedüs

Hi folks,

many-many thanks for your helps,

On Thu, Oct 12, 2017 at 11:06:00AM -0700, Quanah Gibson-Mount wrote:
> --On Thursday, October 12, 2017 6:32 PM +0200 Ervin Hegedüs
>  wrote:
> 
> >rules:
> >
> >olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
> >anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by * none
> >olcAccess: {1}to dn.base="" by * read
> >olcAccess: {2}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by
> >self write by group.exact="cn=groupabcadmin,ou=ABC
> >Customer,dc=core,dc=hdt,dc=hu" write by self write by anonymous auth by
> >dn="uid=repuser,dc=mycompany,dc=hu" read olcAccess: {3}to * by * read
> 
> 
> Your olcAccess: {1} value does not belong in your back-MDB database.  That
> rule goes in the {-1}frontend,cn=config portion of the database as a global
> access rule. 
what does it reveal? This rule comes with the default
installation...

> You probably also want a rule that reads:
> 
> to dn.base="cn=subschema"  by * read

the frontend config is this:

dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by 
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * 
break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=Subschema" by * read

> in the {-1}frontend,cn=config database as well.
> 
> So for your back-mdb database, what one would expect is more something like:
> 
> olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
> anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read
> olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self
> write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu"
> write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read
> olcAccess: {2}to * by * read

well, at first look it works - many thanks again.

I'll check it all config tomorrow.


Regards,


a.

Re: Admin roles by group membership per OU

2017-10-12 Thread Ervin Hegedüs

Hi Clément,

On Thu, Oct 12, 2017 at 05:01:54PM +0200, Clément OUDOT wrote:
> >
> >So, I've modified your idea like this:
> >
> >
> >olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by 
> >anonymous auth by dn="uid=repuser,dc=mycompany,dc=hu" read by * none
> >olcAccess: {1}to dn.base="" by * read
> >olcAccess: {2}to dn.children="ou=ABC Customer,dc=mycompany,dc=hu" by self 
> >write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=mycompany,dc=hu" 
> >write by self write by anonymous auth
> >olcAccess: {3}to * by * read
> >
> >Whith this rules, I can modify the user attributes, except the
> >userPassword.
> >
> >But after the modificítion (on master node), de slave can't
> >replicates the new entries...
> >
> >Without rule {2}, the slave works as well with repuser dn.
> >
> >What did I made badly?
> 
> Just add by dn="uid=repuser,dc=mycompany,dc=hu" read in rule {2}

no luck - the replication doesn't work:

Oct 12 17:29:51 open-ldap slapd[31421]: => access_allowed: result not in cache 
(userPassword)
Oct 12 17:29:51 open-ldap slapd[31421]: => access_allowed: auth access to 
"uid=abc_user1,ou=ABC Customer,dc=mycompany,dc=hu" "userPassword" requested
Oct 12 17:29:51 open-ldap slapd[31421]: => acl_get: [1] attr userPassword
Oct 12 17:29:51 open-ldap slapd[31421]: => acl_mask: access to entry 
"uid=abc_user1,ou=ABC Customer,dc=mycompany,dc=hu", attr "userPassword" 
requested
Oct 12 17:29:51 open-ldap slapd[31421]: => acl_mask: to value by "", (=0)
Oct 12 17:29:51 open-ldap slapd[31421]: <= check a_dn_pat: self
Oct 12 17:29:51 open-ldap slapd[31421]: <= check a_dn_pat: anonymous
Oct 12 17:29:51 open-ldap slapd[31421]: <= acl_mask: [2] applying auth(=xd) 
(stop)
Oct 12 17:29:51 open-ldap slapd[31421]: <= acl_mask: [2] mask: auth(=xd)
Oct 12 17:29:51 open-ldap slapd[31421]: => slap_access_allowed: auth access 
granted by auth(=xd)
Oct 12 17:29:51 open-ldap slapd[31421]: => access_allowed: auth access granted 
by auth(=xd)
Oct 12 17:29:51 open-ldap slapd[31421]: => mdb_entry_get: found entry: 
"uid=abc_airween,ou=abc customer,dc=mycompany,dc=hu"
Oct 12 17:29:51 open-ldap slapd[31421]: => access_allowed: search access to 
"uid=abc_airween,ou=ABC Customer,dc=mycompany,dc=hu" "objectClass" requested
Oct 12 17:29:51 open-ldap slapd[31421]: => dn: [2]
Oct 12 17:29:51 open-ldap slapd[31421]: => dn: [3] ou=abc 
customer,dc=mycompany,dc=hu
Oct 12 17:29:51 open-ldap slapd[31421]: => acl_get: [3] matched
Oct 12 17:29:51 open-ldap slapd[31421]: => acl_get: [3] attr objectClass
Oct 12 17:29:51 open-ldap slapd[31421]: => acl_mask: access to entry 
"uid=abc_airween,ou=ABC Customer,dc=mycompany,dc=hu", attr "objectClass" 
requested
Oct 12 17:29:51 open-ldap slapd[31421]: => acl_mask: to all values by 
"uid=repuser,dc=mycompany,dc=hu", (=0)
Oct 12 17:29:51 open-ldap slapd[31421]: <= check a_dn_pat: self
Oct 12 17:29:51 open-ldap slapd[31421]: <= check a_group_pat: 
cn=groupabcadmin,ou=abc customer,dc=mycompany,dc=hu
Oct 12 17:29:51 open-ldap slapd[31421]: => mdb_entry_get: found entry: 
"cn=groupabcadmin,ou=abc customer,dc=mycompany,dc=hu"
Oct 12 17:29:51 open-ldap slapd[31421]: <= check a_dn_pat: self
Oct 12 17:29:51 open-ldap slapd[31421]: <= check a_dn_pat: anonymous
Oct 12 17:29:51 open-ldap slapd[31421]: <= check a_dn_pat: 
uid=repuser,dc=mycompany,dc=hu
Oct 12 17:29:51 open-ldap slapd[31421]: <= acl_mask: no more  clauses, 
returning =0 (stop)
Oct 12 17:29:51 open-ldap slapd[31421]: => slap_access_allowed: search access 
denied by =0
Oct 12 17:29:51 open-ldap slapd[31421]: => access_allowed: no more rules



rules:

olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous 
auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self 
write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" 
write by self write by anonymous auth by dn="uid=repuser,dc=mycompany,dc=hu" 
read
olcAccess: {3}to * by * read


Thanks,


a.

Re: Admin roles by group membership per OU

2017-10-12 Thread Ervin Hegedüs

Hi,

sorry for the late answer,

On Thu, Oct 12, 2017 at 04:39:45PM +0200, Ervin Hegedüs wrote:
> On Thu, Oct 12, 2017 at 09:16:24AM +0200, Clément OUDOT wrote:
[...]

> > 
> > You can do :
> > 
> > olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
> > anonymous auth by * none
> > olcAccess: {1}to dn.base="" by * read
> > olcAccess: {2}to dn.children="ou=ABC Customer,dc=mycompany,dc=hu" by self
> > write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=mycompany,dc=hu"
> > write by * none
> > olcAccess: {3}to * by * read
> 
[...]
 
> So, I've modified your idea like this:
> 
> 
> olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by 
> anonymous auth by dn="uid=repuser,dc=mycompany,dc=hu" read by * none
> olcAccess: {1}to dn.base="" by * read
> olcAccess: {2}to dn.children="ou=ABC Customer,dc=mycompany,dc=hu" by self 
> write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=mycompany,dc=hu" 
> write by self write by anonymous auth
> olcAccess: {3}to * by * read
> 
> Whith this rules, I can modify the user attributes, except the
> userPassword.
> 
> But after the modificítion (on master node), de slave can't
> replicates the new entries...

here are the loglines:

Oct 12 16:49:11 open-ldap slapd[31421]: => access_allowed: result not in cache 
(userPassword)
Oct 12 16:49:11 open-ldap slapd[31421]: => access_allowed: auth access to 
"uid=abc_user1,ou=ABC Customer,dc=mycompany,dc=hu" "userPassword" requested
Oct 12 16:49:11 open-ldap slapd[31421]: => acl_get: [1] attr userPassword
Oct 12 16:49:11 open-ldap slapd[31421]: => acl_mask: access to entry 
"uid=abc_user1,ou=ABC Customer,dc=mycompany,dc=hu", attr "userPassword" 
requested
Oct 12 16:49:11 open-ldap slapd[31421]: => acl_mask: to value by "", (=0)
Oct 12 16:49:11 open-ldap slapd[31421]: <= check a_dn_pat: self
Oct 12 16:49:11 open-ldap slapd[31421]: <= check a_dn_pat: anonymous
Oct 12 16:49:11 open-ldap slapd[31421]: <= acl_mask: [2] applying auth(=xd) 
(stop)
Oct 12 16:49:11 open-ldap slapd[31421]: <= acl_mask: [2] mask: auth(=xd)
Oct 12 16:49:11 open-ldap slapd[31421]: => slap_access_allowed: auth access 
granted by auth(=xd)
Oct 12 16:49:11 open-ldap slapd[31421]: => access_allowed: auth access granted 
by auth(=xd)
Oct 12 16:49:11 open-ldap slapd[31421]: => mdb_entry_get: found entry: 
"uid=abc_airween,ou=abc customer,dc=mycompany,dc=hu"
Oct 12 16:49:11 open-ldap slapd[31421]: => access_allowed: search access to 
"uid=abc_airween,ou=ABC Customer,dc=mycompany,dc=hu" "objectClass" requested
Oct 12 16:49:11 open-ldap slapd[31421]: => dn: [2]
Oct 12 16:49:11 open-ldap slapd[31421]: => dn: [3] ou=abc 
customer,dc=mycompany,dc=hu
Oct 12 16:49:11 open-ldap slapd[31421]: => acl_get: [3] matched
Oct 12 16:49:11 open-ldap slapd[31421]: => acl_get: [3] attr objectClass
Oct 12 16:49:11 open-ldap slapd[31421]: => acl_mask: access to entry 
"uid=abc_airween,ou=ABC Customer,dc=mycompany,dc=hu", attr "objectClass" 
requested
Oct 12 16:49:11 open-ldap slapd[31421]: => acl_mask: to all values by 
"uid=repuser,dc=mycompany,dc=hu", (=0)
Oct 12 16:49:11 open-ldap slapd[31421]: <= check a_dn_pat: self
Oct 12 16:49:11 open-ldap slapd[31421]: <= check a_group_pat: 
cn=groupabcadmin,ou=abc customer,dc=mycompany,dc=hu
Oct 12 16:49:11 open-ldap slapd[31421]: => mdb_entry_get: found entry: 
"cn=groupabcadmin,ou=abc customer,dc=mycompany,dc=hu"
Oct 12 16:49:11 open-ldap slapd[31421]: <= check a_dn_pat: self
Oct 12 16:49:11 open-ldap slapd[31421]: <= check a_dn_pat: anonymous
Oct 12 16:49:11 open-ldap slapd[31421]: <= acl_mask: no more  clauses, 
returning =0 (stop)
Oct 12 16:49:11 open-ldap slapd[31421]: => slap_access_allowed: search access 
denied by =0
Oct 12 16:49:11 open-ldap slapd[31421]: => access_allowed: no more rules

where:
* uid=abc_user1,ou=ABC Customer,dc=mycompany,dc=hu is the admin
  user, who wants to execute the request; it's member of
  cn=groupabcadmin,ou=abc customer,dc=mycompany,dc=hu
* uid=abc_airween,ou=abc customer,dc=mycompany,dc=hu is the OU
  user, they data could be modified
* uid=repuser,dc=mycompany,dc=hu is the replicator user





Thanks,

a.

Re: Admin roles by group membership per OU

2017-10-12 Thread Ervin Hegedüs

Hi Clément,

thanks for your help,

On Thu, Oct 12, 2017 at 09:16:24AM +0200, Clément OUDOT wrote:
> 
> 
> Le 11/10/2017 à 17:31, Ervin Hegedüs a écrit :
> >olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by 
> >anonymous auth by * none
> >olcAccess: {1}to dn.base="" by * read
> >olcAccess: {2}to * by * read
> >olcAccess: {3}to dn.children="ou=ABC Customer,dc=mycompany,dc=hu" by self 
> >write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=mycompany,dc=hu" 
> >write by * auth
> 
> The rule {2} catches all requests (to *  by *) so rule {3} is never applied.
> 
> You can do :
> 
> olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
> anonymous auth by * none
> olcAccess: {1}to dn.base="" by * read
> olcAccess: {2}to dn.children="ou=ABC Customer,dc=mycompany,dc=hu" by self
> write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=mycompany,dc=hu"
> write by * none
> olcAccess: {3}to * by * read

whit these rules, I could't read with anonymous nor authenticated
user from the DB, only the self record.

So, I've modified your idea like this:


olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous 
auth by dn="uid=repuser,dc=mycompany,dc=hu" read by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to dn.children="ou=ABC Customer,dc=mycompany,dc=hu" by self write 
by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=mycompany,dc=hu" write by 
self write by anonymous auth
olcAccess: {3}to * by * read

Whith this rules, I can modify the user attributes, except the
userPassword.

But after the modificítion (on master node), de slave can't
replicates the new entries...

Without rule {2}, the slave works as well with repuser dn.

What did I made badly?

Thanks,


a.

Re: Replication error

2017-10-12 Thread Ervin Hegedüs

Hi all,

On Thu, Oct 12, 2017 at 10:25:20AM +0200, Ervin Hegedüs wrote:
> On Wed, Oct 11, 2017 at 06:44:01PM -0700, Quanah Gibson-Mount wrote:
> > Your uid=repuser,dc=my,dc=domain,dc=hu user does not have "read" access on
> > the userPassword attribute.
> 
> what would be the expected form of olcAccess structure?
> 
> Now I configured these lines:
> 
[...]

> olcAccess: {0}to attrs=userPassword,shadowLastChange
>   by self write
>   by anonymous auth
>   by dn="uid=repuser,dc=my,dc=domain,dc=hu" read
>   by * none
> olcAccess: {1}to dn.children="ou=ABC Customer,dc=my,dc=domain,dc=hu"
>   by self write
>   by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=my,dc=domain,dc=hu" 
> write
>   by * auth
> olcAccess: {2}to dn.base="" by * read
> olcAccess: {3}to * by * read
> olcAccess: {4}to dn.children="ou=ABC Customer,dc=my,dc=domain,dc=hu"
>   by self write
>   by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=my,dc=domain,dc=hu" 
> write
>   by * auth

sorry, looks like these are wrong, I've configured this state:

dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=core,dc=hdt,dc=hu
olcAccess: {0}to attrs=userPassword,shadowLastChange
  by self write
  by anonymous auth
  by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read
  by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE


and it works as well.

Now I have to set up the admin rights to users who member of
special group (eg, groupabcadmins).


a.

Re: Replication error

2017-10-12 Thread Ervin Hegedüs

Hi Quanah,

thanks for your reply,

On Wed, Oct 11, 2017 at 06:44:01PM -0700, Quanah Gibson-Mount wrote:
> --On Tuesday, October 10, 2017 6:39 PM +0200 Ervin Hegedüs
>  wrote:
> 
> >  binddn="uid=repuser,dc=my,dc=domain,dc=hu"
> 
> >Anyway - how can I solve this problem?
> 
> Your uid=repuser,dc=my,dc=domain,dc=hu user does not have "read" access on
> the userPassword attribute.

what would be the expected form of olcAccess structure?

Now I configured these lines:

dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=my,dc=domain,dc=hu
olcAccess: {0}to attrs=userPassword,shadowLastChange
  by self write
  by anonymous auth
  by dn="uid=repuser,dc=my,dc=domain,dc=hu" read
  by * none
olcAccess: {1}to dn.children="ou=ABC Customer,dc=my,dc=domain,dc=hu"
  by self write
  by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=my,dc=domain,dc=hu" write
  by * auth
olcAccess: {2}to dn.base="" by * read
olcAccess: {3}to * by * read
olcAccess: {4}to dn.children="ou=ABC Customer,dc=my,dc=domain,dc=hu"
  by self write
  by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=my,dc=domain,dc=hu" write
  by * auth

but it doesn't work - the repuser can't read any part of db, only
the self record. Eg.

ldapsearch -D "uid=repuser,dc=my,dc=domain,dc=hu" -W -b dc=my,dc=domain,dc=hu 
"(uid=abc_user1)" uid


gives

# search result
search: 2
result: 0 Success


answer.

What did I make as wrong?


Thanks,

a.

Admin roles by group membership per OU

2017-10-11 Thread Ervin Hegedüs

Hi,

here is my scenario:

dn: dc=mycompany,dc=hu

dn: ou=ABC Customer,dc=mycompany,dc=hu
+- dn: cn=group1abc,ou=ABC Customer,dc=mycompany,dc=hu
+- dn: cn=group2abc,ou=ABC Customer,dc=mycompany,dc=hu
+- dn: cn=groupabcadmin,ou=ABC Customer,dc=mycompany,dc=hu
+- dn: uid=user1,ou=ABC Customer,dc=mycompany,dc=hu
+- dn: uid=user2,ou=ABC Customer,dc=mycompany,dc=hu

dn: ou=XYZ Customer,dc=mycompany,dc=hu
+- dn: cn=group1xyz,ou=XYZ Customer,dc=mycompany,dc=hu
+- dn: cn=group2xyz,ou=XYZ Customer,dc=mycompany,dc=hu
+- dn: uid=user1,ou=XYZ Customer,dc=mycompany,dc=hu
+- dn: uid=user2,ou=XYZ Customer,dc=mycompany,dc=hu
...


the cn=groupabcadmin,ou=ABC Customer node above looks like this:

dn: cn=groupabcadmin,ou=ABC Customer,dc=mycompany,dc=hu
objectClass: groupOfNames
cn: groupabcadmin
member: uid=user1,ou=ABC Customer,dc=mycompany,dc=hu

I'ld like to set up, that the all member of cn=groupabcadmin
group, now the "uid=user1,ou=ABC Customer",... user can write
the db (add, modify, delete) under his own OU, specially the
ou=ABC Customer,dc=mycompany,dc=hu.

I've found this example:
http://www.openldap.org/faq/data/cache/52.html

Now the config looks like this:

dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=mycompany,dc=hu
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous 
auth by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by * read
olcAccess: {3}to dn.children="ou=ABC Customer,dc=mycompany,dc=hu" by self write 
by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=mycompany,dc=hu" write by * 
auth
olcLastMod: TRUE

The uid=user1 user password is right, I can read with it from DB.
But when I would like to add a new user, I've got:

ldap_add: Insufficient access (50)
additional info: no write access to parent

and in log:

Oct 11 17:03:16 open-ldap slapd[25821]: mdb_dn2entry("uid=user2,ou=abc 
customer,dc=mycompany,dc=hu")
Oct 11 17:03:16 open-ldap slapd[25821]: => mdb_dn2id("uid=user2,ou=abc 
customer,dc=mycompany,dc=hu")
Oct 11 17:03:16 open-ldap slapd[25821]: <= mdb_dn2id: get failed: MDB_NOTFOUND: 
No matching key/data pair found (-30798)
Oct 11 17:03:16 open-ldap slapd[25821]: => mdb_entry_decode:
Oct 11 17:03:16 open-ldap slapd[25821]: <= mdb_entry_decode
Oct 11 17:03:16 open-ldap slapd[25821]: => access_allowed: add access to 
"ou=ABC Customer,dc=mycompany,dc=hu" "children" requested
Oct 11 17:03:16 open-ldap slapd[25821]: => dn: [2]
Oct 11 17:03:16 open-ldap slapd[25821]: => acl_get: [3] attr children
Oct 11 17:03:16 open-ldap slapd[25821]: => acl_mask: access to entry "ou=ABC 
Customer,dc=mycompany,dc=hu", attr "children" requested
Oct 11 17:03:16 open-ldap slapd[25821]: => acl_mask: to all values by 
"uid=user1,ou=abc customer,dc=mycompany,dc=hu", (=0)
Oct 11 17:03:16 open-ldap slapd[25821]: <= check a_dn_pat: *
Oct 11 17:03:16 open-ldap slapd[25821]: <= acl_mask: [1] applying read(=rscxd) 
(stop)
Oct 11 17:03:16 open-ldap slapd[25821]: <= acl_mask: [1] mask: read(=rscxd)
Oct 11 17:03:16 open-ldap slapd[25821]: => slap_access_allowed: add access 
denied by read(=rscxd)
Oct 11 17:03:16 open-ldap slapd[25821]: => access_allowed: no more rules
Oct 11 17:03:16 open-ldap slapd[25821]: mdb_add: no write access to parent
Oct 11 17:03:16 open-ldap slapd[25821]: send_ldap_result: conn=1208 op=1 p=3
Oct 11 17:03:16 open-ldap slapd[25821]: send_ldap_result: err=50 matched="" 
text="no write access to parent"
Oct 11 17:03:16 open-ldap slapd[25821]: send_ldap_response: msgid=2 tag=105 
err=50
Oct 11 17:03:16 open-ldap slapd[25821]: conn=1208 op=1 RESULT tag=105 err=50 
text=no write access to parent


What do I miss?


Thanks,


a.

Replication error

2017-10-11 Thread Ervin Hegedüs

Hi,

I (think I) setting up completly a master-slave replication.

The replication user can access from the slave (ldapsearch
works).

Here is the config, what I added on slave:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcSyncRepl
olcSyncRepl: rid=001
  provider=ldaps://master:636/
  bindmethod=simple
  binddn="uid=repuser,dc=my,dc=domain,dc=hu"
  credentials=SECRET
  searchbase="dc=my,dc=domain,dc=hu"
  scope=sub
  schemachecking=on
  type=refreshAndPersist
  retry="30 5 300 3"
  interval=00:00:05:00
  tls_cacert=/etc/ldap/CAcert.pem
  tls_cert=/etc/ldap/slave_cert.pem
  tls_key=/etc/ldap/slave_key.pem
  tls_reqcert=demand

And now I found these lines in syslog:

Oct 10 17:36:40 open-ldap2 slapd[4640]: Entry (cn=admin,dc=my,dc=domain,dc=hu): 
object class 'simpleSecurityObject' requires attribute 'userPassword'
Oct 10 17:36:40 open-ldap2 slapd[4640]: null_callback : error code 0x41
Oct 10 17:36:40 open-ldap2 slapd[4640]: syncrepl_entry: rid=001 be_add 
cn=admin,dc=my,dc=domain,dc=hu failed (65)
Oct 10 17:36:41 open-ldap2 slapd[4640]: do_syncrepl: rid=001 rc 65 retrying (4 
retries left)

I think this occures, because the cn=admin,dc=... user is a
simpleSecurityObject, and could't access the userPassword from
the ldapsearch - or not :).


Anyway - how can I solve this problem?

Thanks,

a.

Re: Multiple index for a node

2017-10-04 Thread Ervin Hegedüs

Hi Michael,

On Tue, Oct 03, 2017 at 05:32:29PM +0200, Michael Ströder wrote:
> Ervin Hegedüs wrote:
> > no, whit this index I got 0 result. Without this index I get 2
> > results.
> 
> Did you re-index after changing indexing config?
> 
> See also: http://www.openldap.org/faq/data/cache/136.html

yep' - I forgot it. After I did it, the search works as well.

Many thanks for your help!


a.

Re: Multiple index for a node

2017-10-04 Thread Ervin Hegedüs

Hi Michael,

thanks for your answers,

On Tue, Oct 03, 2017 at 01:06:59PM +0200, Michael Ströder wrote:
> Ervin Hegedüs wrote:
> > is there any way to use multiple keys for a node in a LPD tree?
> > 
> > I mean, there are several subtree-s:
> > ou=company2,dc=foo,dc=com
> > 
> > and I have to store the users under these subtrees.
> 
> Are these two subtrees within the same database?

yes,

> Or do you have separate databases with the suffixes above?

no, there are in same db,
 
> Which search base do your LDAP clients use?
> dc=foo,dc=com or ou=companyX,dc=foo,dc=com?

dc=foo,dc=com. The "clients" will be "black-box-like" devices,
like application level firewalls, access-points, etc... I just
acn set up only one search base dn for one uniq LDAP source.

> > Sometimes the users
> > have same names, eg. John Smith, and the nodes will be:
> > 
> > uid=jsmith,ou=company1,dc=foo,dc=com
> > uid=jsmith,ou=company2,dc=foo,dc=com
> > 
> > but the any other attributes (sn, cn, ...) also the same.
> > 
> > How do I set up the indexes?
> 
> I'm not sure whether I really understand your issue.
> 
> An index just speeds up a lookup for a small search candidate set.

yes, I thought it - the records (nodes) in db will be about
k*10.
 
> Example:
> 
> Assuming you have a single database with suffix dc=foo,dc=com and
> sub-trees ou=companyX,dc=foo,dc=com:
> 
> index uid eq

that was what I tried,
 
> Using search base dc=foo,dc=com there will be two results returned for
> filter "(uid=jsmith)". But indeed the lookup will be faster because uid
> is indexed.

no, whit this index I got 0 result. Without this index I get 2
results.

That was the reason why I asked this question.

Here are the search's:

# ldapsearch -Y EXTERNAL -H ldapi:/// -b dc=foo,dc=com "(&(uid=airween))"
...
# search result
search: 2
result: 0 Success

# numResponses: 1

[no entry]

# grep ^index /etc/ldap/slapd.conf
index   objectClass eq
index   cn  pres,sub,eq
index   sn  pres,sub,eq
index   uid eq
index   displayName pres,sub,eq
index   default sub
index   uidNumber   eq
index   gidNumber   eq
index   mail,givenName  eq,subinitial
index   dc  eq


Ok, now I turned off the uid index:

# grep ^index /etc/ldap/slapd.conf
index   objectClass eq
index   cn  pres,sub,eq
index   sn  pres,sub,eq
index   displayName pres,sub,eq
index   default sub
index   uidNumber   eq
index   gidNumber   eq
index   mail,givenName  eq,subinitial
index   dc  eq


# ldapsearch -Y EXTERNAL -H ldapi:/// -b dc=foo,dc=com "(&(uid=airween))"
...
# airween, ABC Customer, foo.com
dn: uid=airween,ou=ABC Customer,dc=foo,dc=com
cn: airween
sn: airween
uid: airween
uidNumber: 10001
...

# airween, XYZ Customer, foo.com
dn: uid=airween,ou=XYZ Customer,dc=foo,dc=com
uid: airween
uidNumber: 10001
cn: airween
sn: airween
...


> Off course a typical LDAP-based "login" will fail because there are two
> search results returned and therefore the uid->DN mapping is not unique.

sure, that's clear.
 
> In general indexes defined for several assertion attributes used in a
> filter are used. But note that search performance can be worse if you're
> indexing attributes with same values in many entries.

right - I just don't understand, why didn't I got the results
when the uid index had turned on.


Thanks again,


a.

Multiple index for a node

2017-10-03 Thread Ervin Hegedüs

Hi there,

is there any way to use multiple keys for a node in a LPD tree?

I mean, there are several subtree-s:

ou=company1,dc=foo,dc=com
ou=company2,dc=foo,dc=com

and I have to store the users under these subtrees. Sometimes the users
have same names, eg. John Smith, and the nodes will be:

uid=jsmith,ou=company1,dc=foo,dc=com
uid=jsmith,ou=company2,dc=foo,dc=com

but the any other attributes (sn, cn, ...) also the same.

How do I set up the indexes?

Thanks,

a.

Attribute map/substitution

2017-09-28 Thread Ervin Hegedüs

Hi folks,

here is a Captive Portal (from Aruba), and we would like to integrate it
with OpenLDAP tu authenticate users (for 802.1x).

The server is a Debian 8, with OpenLDAP 2.4.

I've set up the loglevel, and I see the query in the log:

Sep 27 09:56:50 srv slapd[19709]: filter:
(&(uid=airween)(objectClass=*))
Sep 27 09:56:50 srv slapd[19709]: attrs:
Sep 27 09:56:50 srv slapd[19709]:  ntPassword
Sep 27 09:56:50 srv slapd[19709]:  lmPassword
Sep 27 09:56:50 srv slapd[19709]:  radiusReplyMessage
Sep 27 09:56:50 srv slapd[19709]:  radiusFilterId
Sep 27 09:56:50 srv slapd[19709]:  userPassword
Sep 27 09:56:50 srv slapd[19709]:  userCertificate
Sep 27 09:56:50 srv slapd[19709]:  sAMAccountName
Sep 27 09:56:50 srv slapd[19709]:  objectSid
Sep 27 09:56:50 srv slapd[19709]:

The problem is, that (for example) ntPassword and lmPassword attributes are
doesn't exists (sAMAccountName and objectSid also...).

I thing that the ntPassword is the sambaNTPassword, which is part of the
samba.scheme.

But how can I configure the OpenLDAP to server these attributes?

I've found the slapo-rwm manpages, but nothing more useful informations...

Could anybody helps to explain, how rwm's works? What do I need to do with
this OpenLDAP (eg. modify the existing config) to solve that problem?

On CP side there isn't any way to change the attributes - as I saw.


Thanks,

a.

Openldap - ldap user can't add entry: Insufficient access (no write access to parent)

2015-10-18 Thread Ervin Hegedüs

Hello,

(I'm not an LDAP guru - sorry for lame question(s))

I'ld like to make an addressbook in LDAP (for mailing clients, in
first step for my RoundCube). Server is Debian 7.9, slapd 2.4.31
(OpenLDAP). After the successfully installation, I've created a
subtree for the addressbook:

dn: ou=rcabook,dc=mydomain,dc=com
ou: rcabook
objectClass: top
objectClass: organizationalUnit

dn: ou=public,ou=rcabook,dc=mydomain,dc=com
ou: public
objectClass: top
objectClass: organizationalUnit

dn: ou=private,ou=rcabook,dc=mydomain,dc=com
ou: private
objectClass: top
objectClass: organizationalUnit

and a regular user for RoundCube:

dn: cn=rcuser,ou=rcabook,dc=mydomain,dc=com
cn: rcuser
objectClass: organizationalRole
objectClass: simpleSecurityObject
userPassword:: e1f2g3x3y2z1

But when I want to make a new entry as rcuser, I've got this
error:

ldapadd -f entry.ldif -D cn=rcuser,ou=rcabook,dc=mydomain,dc=com -W
Enter LDAP Password: 
adding new entry "cn=DOMAIN IT,ou=public,ou=rcabook,dc=mydomain,dc=com"
ldap_add: Insufficient access (50)
additional info: no write access to parent

The ou=public,ou=rcabook subtree has a special access in config:

# slapcat -n0
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=mydomain,dc=com
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou
 s auth by dn="cn=admin,dc=mydomain,dc=com" write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by dn="cn=admin,dc=mydomain,dc=com" write by * read
olcAccess: {3}to dn.subtree="ou=public,ou=rcabook,dc=mydomain,dc=com" by users 
writ
 e
olcLastMod: TRUE
...

Which privileges do I need to add, for all user would add the
entries to subtree?

Thanks,

a.


-- 
I � UTF-8

65 matches

Mail list logo