Problem with "force user to password reset at first login
by Rajagopal Rc
Hi,
I am trying to force users to change their password at first login or
after
password reset by administrator.
Tried following:
1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non
of the
users get prompt to change their password at first login.
2) used the 'pwdReset TRUE' attribute in users attributes, and it won't
prompt
to change the password and didn't allow to login
i observe below messages in log
"slapd[12684]: connection restricted to password changing only
slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are
restricted to bind/unbind/abandon/StartTLS/modify password"
slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0
text=Operations are restricted to bind/unbind/abandon/StartTLS/modify
password"
Please help me configure the option to force all users to change their
password
at first login or after pwd reset by administrator.
Thanks & Regards
Raj
Tata Consultancy Services
Mailto: rajagopal.rc(a)tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
1 month
dynamic config replication
by Gerard Ranke
Hello list,
Openldap 2.4.45 here, on 1 producer and 4 consumers. ( I'll attach
relevant parts of the configuration at the end of this message. )
Following the scripts from test059, I configured the producer to serve
up a cn=config backend for the consumers. This seems to work nicely at
first: When you start a consumer from a minimal config, it loads the
producers schemafiles and the cn=config, and replication of the main
database is fine. Also, when fi. changing the loglevel on the producers
cn=config,cn=slave, the consumers pick up this change in their cn=config.
However, when I modify an olcAccess line on the producers
cn=config,cn=slave database, I get these errors on the consumer:
slapd[26324]: syncrepl_message_to_entry: rid=002 DN:
olcDatabase={1}mdb,cn=config,cn=slave, UUID:
7cff5ef6-90b1-1037-9d95-6dfd3149c2dc
slapd[26324]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
slapd[26324]: syncrepl_entry: rid=002 inserted UUID
7cff5ef6-90b1-1037-9d95-6dfd3149c2dc
slapd[26324]: syncrepl_entry: rid=002 be_search (0)
slapd[26324]: syncrepl_entry: rid=002 olcDatabase={1}mdb,cn=config
slapd[26324]: null_callback : error code 0x43
slapd[26324]: syncrepl_entry: rid=002 be_modify
olcDatabase={1}mdb,cn=config (67)
slapd[26324]: syncrepl_entry: rid=002 be_modify failed (67)
slapd[26324]: do_syncrepl: rid=002 rc 67 retrying
>From the error code ox43, it seems that the replication is somehow
trying to change the rdn, olcDatabase{1}mdb, on the consumer, which
makes no sense to me.
>From the producer, cn=config,cn=slave:
( This is identical to the consumer's cn=config )
dn: cn=config,cn=slave
objectClass: olcGlobal
objectClass: olcConfig
objectClass: top
cn: slaveconfig
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcAttributeOptions: lang-
olcAuthzPolicy: none
olcConcurrency: 0
olcConfigDir: slapd.d/
olcConnMaxPending: 100
olcConnMaxPendingAuth: 1000
olcGentleHUP: FALSE
olcIdleTimeout: 0
olcIndexIntLen: 4
olcIndexSubstrAnyLen: 4
olcIndexSubstrAnyStep: 2
olcIndexSubstrIfMaxLen: 4
olcIndexSubstrIfMinLen: 2
olcLocalSSF: 71
olcLogFile: none
olcLogLevel: none
olcPidFile: /var/run/slapd/slapd.pid
olcReadOnly: FALSE
olcSaslSecProps: noplain,noanonymous
olcSizeLimit: 20000
olcSockbufMaxIncoming: 262143
olcSockbufMaxIncomingAuth: 16777215
olcThreads: 16
olcTLSCACertificatePath: /etc/ssl/certs
olcTLSCertificateFile: /etc/ssl/certs/hkuwildcardcacert.cert
olcTLSCertificateKeyFile: /etc/ssl/private/hkuwildcardcacert.key
olcTLSCRLCheck: none
olcTLSVerifyClient: never
olcToolThreads: 2
I'll leave the rest PM, except for:
dn: olcDatabase={0}config,cn=config,cn=slave
objectClass: olcDatabaseConfig
objectClass: olcConfig
objectClass: top
olcDatabase: {0}config
olcRootDN: cn=root,cn=config
olcRootPW: xxxxxxxxxxxxxx
olcSyncrepl: {0}rid=002 provider=ldap://xxx.xx.xx bindmethod=simple
binddn="cn=config,cn=slave" credentials="xxxx"
tls_cert="/etc/ssl/certs/xxx.cert" tls_key="/etc/ssl/private/xxx.key"
tls_cacertdir="/etc/ssl/certs" tls_reqcert=demand tls_crlcheck=none
searchbase="cn=config,cn=slave" schemachecking=off
type=refreshAndPersist retry="5 5 10 +" suffixmassage="cn=config"
olcSyncUseSubentry: FALSE
This is identical to the consumers olcDatabase={0}config,cn=config entry.
Hopefully somebody can point me in the right direction!
Many thanks in advance,
gerard
5 years, 9 months
Acl on a replicated tree: unable to bind as user
by Giuseppe Civitella
Hi all,
I've got a master / slave replica setup. I did use this tutorial to set
up the replica:
https://wiki.debian.org/LDAP/OpenLDAPSetup
My ldap tree is something like: Root -> o=(first level local branch),
o=(first level replicated branch).
The local branch is just a cut and paste of the replicated branch.
On the slave server I can use the replicated branch to authenticate
against a Radius server.
On the master server I realized I cannot let web users authenticate
against the replicated branch.
If I try to bind as a user from the replicated branch, on both the
master and the slave, I get:
ldapwhoami -H ldap://localhost -D
"uid=gcivitella,ou=users,o=isiline,dc=who,dc=is" -W
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
On the master, on the local branch, I get:
ldapwhoami -H ldap://localhost -D
"cn=gcivitella,ou=users,o=area51,dc=who,dc=is" -W
Enter LDAP Password:
dn:cn=gcivitella,ou=users,o=area51,dc=who,dc=is
I did try to configure the acl on the server to disallow anonymous bind.
And, once found this problem, I did try to create a bind user
(uid=read_only) able to read the replicated branch, userPassword attrs
included.
Unfortunately this did not solve the problem.
My acl on the master are:
dn: olcDatabase={1}mdb
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=who,dc=is
olcAccess: {0}to dn.subtree="o=isiline,dc=who,dc=is" by dn="uid=read_only,ou
=binds,dc=who,dc=is" read
olcAccess: {1}to dn.subtree="o=isiline,dc=who,dc=is" by dn="uid=isi_replica,
ou=binds,dc=who,dc=is" read
olcAccess: {2}to attrs=userPassword by self write by anonymous auth by * non
e
olcAccess: {3}to attrs=shadowLastChange by self write by * read
olcAccess: {4}to * by users read
I'm quite new to this kind of setup, is this something to be expected?
Is there a way to bind directly on the replicated branch?
Regards,
Giuseppe
5 years, 9 months
Re: Syncrepl and multipe values
by Quanah Gibson-Mount
--On Friday, January 06, 2017 6:50 PM +0000 Matheus Eduardo Bonifacio
Morais <matheus_morais(a)sicredi.com.br> wrote:
>
>
>
> Issue 8559 opened.
>
>
>
> I'm trying to work on a patch but I'm not sure if the best solution is to
> fix accesslog to avoid duplicated values or if the sample LDIF (in its
> description) should result in a constraint violation. What do you think?
The accesslog should never write an operation that can't be replicated. If
the MOD is a valid LDAP operation (which I think it is), then it should be
accepted at the frontend. The issue may be more in delta-syncrepl's
handling of the write op than anything else.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
5 years, 9 months
consumer abort with chain overlay
by Michael Wandel
hallo ,
i'm not sure if I it is a configuration failure or a openldap error.
I have tested this with centos 7 , original RPM, SLES12SP3 and the
ltb-project binäries. Every enviroment failed.
this is a setup consumer / provider with chain overlay and proxyauth.
a minimized slapd.conf global section
...
authz-policy to
overlay chain
chain-uri "ldap://ldap1.example.test"
chain-rebind-as-user FALSE
chain-idassert-bind bindmethod="simple"
binddn="cn=chainadmin,dc=example,dc=test"
credentials="secret"
mode=legacy
flags=override
chain-return-error TRUE
...
the java code snipplet which makes a connection and then switch the
proxyauth and make a password change.
---
try {
LDAPConnection connection = openLDAPConnection();
BindRequest bindRequest = new SimpleBindRequest(modDN, oldPwd,
new DraftBeheraLDAPPasswordPolicy10RequestControl());
BindResult bindResult = connection.bind(bindRequest);
DraftBeheraLDAPPasswordPolicy10ResponseControl pwpResponse =
DraftBeheraLDAPPasswordPolicy10ResponseControl.get(bindResult);
DraftBeheraLDAPPasswordPolicy10WarningType warningType =
pwpResponse.getWarningType();
System.out.println("Bind Result " + bindResult.toString());
System.out.println("PwdResponse " + pwpResponse.toString());
connection.close();
connection = openLDAPConnection();
Control[] controls = { new
ProxiedAuthorizationV2RequestControl("dn:" + modDN) };
PasswordModifyExtendedRequest passwordModifyRequest = new
PasswordModifyExtendedRequest(modDN, oldPwd, newPwd, controls);
PasswordModifyExtendedResult passwordModifyResult =
(PasswordModifyExtendedResult) connection
.processExtendedOperation(passwordModifyRequest);
System.out.println("passwordModifyResult " +
passwordModifyResult.toString());
connection.close();
connection = openLDAPConnection();
bindRequest = new SimpleBindRequest(modDN, newPwd, new
DraftBeheraLDAPPasswordPolicy10RequestControl());
bindResult = connection.bind(bindRequest);
pwpResponse =
DraftBeheraLDAPPasswordPolicy10ResponseControl.get(bindResult);
warningType = pwpResponse.getWarningType();
System.out.println("Bind Result " + bindResult.toString());
System.out.println("PwdResponse " + pwpResponse.toString());
}
the gdb output of the crash is here:
5a8c6d3d conn=1001 op=1 RESULT oid= err=123 text=not authorized to
assume identity
*** Error in `/usr/local/openldap/libexec/slapd': munmap_chunk():
invalid pointer: 0x00007f2b14100986 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7ada4)[0x7f2d8a9d7da4]
/usr/local/openldap/libexec/slapd(ldap_back_controls_free+0xc1)[0x5181a1]
/usr/local/openldap/libexec/slapd[0x522ba8]
/usr/local/openldap/libexec/slapd[0x51a959]
/usr/local/openldap/libexec/slapd[0x51c193]
/usr/local/openldap/libexec/slapd[0x4a5118]
/usr/local/openldap/libexec/slapd[0x44f286]
/usr/local/openldap/libexec/slapd[0x44f787]
/usr/local/openldap/libexec/slapd(slap_send_ldap_extended+0xc0)[0x450880]
/usr/local/openldap/libexec/slapd(fe_extended+0xba)[0x46f26a]
/usr/local/openldap/libexec/slapd(overlay_op_walk+0x92)[0x4a5c42]
/usr/local/openldap/libexec/slapd[0x4a5d7e]
/usr/local/openldap/libexec/slapd(do_extended+0x24e)[0x46efbe]
/usr/local/openldap/libexec/slapd[0x4407ee]
/usr/local/openldap/libexec/slapd[0x440aca]
/usr/local/openldap/libexec/slapd[0x590769]
/lib64/libpthread.so.0(+0x7dc5)[0x7f2d8be00dc5]
/lib64/libc.so.6(clone+0x6d)[0x7f2d8aa5473d]
======= Memory map: ========
00400000-00683000 r-xp 00000000 fd:00 68054818
/usr/local/openldap/libexec/slapd
00882000-00883000 r--p 00282000 fd:00 68054818
/usr/local/openldap/libexec/slapd
00883000-00893000 rw-p 00283000 fd:00 68054818
/usr/local/openldap/libexec/slapd
00893000-00939000 rw-p 00000000 00:00 0
022d2000-02768000 rw-p 00000000 00:00 0
[heap]
7f2b14000000-7f2b1411f000 rw-p 00000000 00:00 0
7f2b1411f000-7f2b18000000 ---p 00000000 00:00 0
7f2b1afff000-7f2b1c000000 rw-p 00000000 00:00 0
7f2b1c000000-7f2b1c021000 rw-p 00000000 00:00 0
7f2b1c021000-7f2b20000000 ---p 00000000 00:00 0
7f2b20000000-7f2b20117000 rw-p 00000000 00:00 0
7f2b20117000-7f2b24000000 ---p 00000000 00:00 0
7f2b24000000-7f2b24021000 rw-p 00000000 00:00 0
I'm not sure if it is a known bug or misconfiguration. If someone wants
the java testprogram i'll can send it per pm or give a download link.
best regards
Michael
--
Michael Wandel
Braakstraße 43
33647 Bielefeld
5 years, 9 months
contextCSN not found on consumer!
by Sam Culley
I have recently set up a provider/consumer using OpenLDAP 2.4.40,
everything appears to be working. Changes made on the provider are
replicated to the consumer but when querying the contextCSN I am only able
to retrieve results for the provider.
[root@prod-mail-ldap-master ~]# ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:///
-s base -b dc=domain,dc=cp, contextCSN
dn: dc=domain,dc=com
contextCSN: 20180222075803.816626Z#000000#000#000000
[root@prod-mail-ldap-slave-1 ~]# ldapsearch -z1 -LLLQY EXTERNAL -H
ldapi:/// -s base -b dc=domain,dc=cp, contextCSN
dn: dc=domain,dc=com
As you can see from the command outputs above when running the same
commands on both provider/consumer only the provider returns the contextCSN.
Why is this happening, what do I need to do to retrieve the contextCSN from
the consumer?
Regards,
Sam
5 years, 9 months
Re: placeholder problems
by Côme Chilliet
Le jeudi 8 février 2018, 09:59:03 CET Joeri Casteels a écrit :
> Now i would like to assign them directly to the correct unix group depending on the base you start from or Primary group you select.
> If i use this placeholder:Home directory*: /home/%primaryGroup%/%uid% i get the option in the template to select my primary group but it does not fill in the Home Directory correct nor it fills in the correct group.
Hum primaryGroup is not an LDAP field so I don’t think you can use it like that. You can use %gidNumber% but I’m not sure it will help.
You can open an issue to make the primary group name available as %primaryGroup% in templates but I can’t guarantee it will be added.
> Also setting the passord expiration does not work correctly with the info on the website under placeholder i tried epoch time and it does not work at all to fetch the day of today and add 4years on top for example. Even just fetching the day of today does not work under unix Password Expiration data:
The epoch modifier was added in FusionDirectory 1.2.1 which is not out yet.
> Then there is another small matter i would like to know if there is an easy change for this. My users are allowed to change some info on their own but non of them find the edit button since it’s in the bottom right corner where nobody looks. Is it possible to make these buttons directly under the last frame? Can i edit this myself in de code?
You can create you own CSS theme in which you can change the button display. See https://fusiondirectory-developer-documentation.readthedocs.io/en/latest/...
Côme
5 years, 9 months
