Re: On removing a duplicated ppolicy overlay

[Daniel Howard]

On Mon, Dec 3, 2018 at 2:11 PM Quanah Gibson-Mount  wrote:

> --On Monday, December 03, 2018 1:57 PM -0800 Daniel Howard
>  wrote:
>
>
> > A potentially minor improvement along these lines could be a very nice
> > feature enhancement for OpenLDAP. Thank you for your consideration.
>
> You're talking about two things:  a) slapmodify, which is slated for
> release with OpenLDAP 2.5, which allows offline modifications of
> cn=config,
> and b) delete support in cn=config, also slated for release with OpenLDAP
> 2.5.
>

I love these features already. ;)

-- 
http://dannyman.toldme.com

Re: On removing a duplicated ppolicy overlay

[Daniel Howard]

On Wed, Nov 28, 2018 at 11:05 AM Quanah Gibson-Mount 
wrote:

> --On Wednesday, November 28, 2018 10:16 AM -0800 Daniel Howard
>  wrote:
>
> ># This file MUST be edited with the 'visudo' command as root.
> >
> > Perhaps this is a consideration that is already on the roadmap?
>
> You mean like it already does? :)
>
> head -1 cn\=config.ldif
> # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
>

Quanah, (and Howard)

That is certainly a warning. It would be more easily noticed with a bit
more whitespace around it, as you find in the sudoers file. This warning is
not as helpful as the visudo warning, as it does not give the user a way to
edit the file. A wrapper script, or a link to a good document on managing
configurations, would be more useful.

For example, if I follow the advice in sudoers, and I type "visudo" then I
get to edit /etc/sudoers, with a validation before the file can go live.
This is fantastic!

If I follow the advice here, and type "ldapmodify" then I get an error
message. If I research the correct command line, then, in my experience, I
manage to import multiple conflicting configs into the system that crash
the server. I then research some more, and find that ldapmodify can not
delete the conflicting configs. I research some more, and learn that I
could just remove them from the filesystem. As I wish to be a good citizen,
I share this knowledge, and I am told that this is wrong, and I need to use
slapcat to export, delete my config files, then slapadd to import, using a
different set of flags than ldapmodify. Perhaps, you can spare a moment of
empathy to acknowledge how frustrating this must be for a user.

I appreciate your warnings, but given the cumbersome and, in my experience,
dangerous nature of managing config files through ldapmodify, I am inclined
to very carefully tweak the config files in the config directory. If,
however, there was a convenient, safe wrapper, like visudo, or a reference
to a reassuring doc that explains the right way to do things, then I would
preach the good news.

A potentially minor improvement along these lines could be a very nice
feature enhancement for OpenLDAP. Thank you for your consideration.

Sincerely,
-danny

-- 
http://dannyman.toldme.com

Re: On removing a duplicated ppolicy overlay

[Daniel Howard]

On Tue, Nov 27, 2018 at 3:17 PM Quanah Gibson-Mount 
wrote:

> --On Tuesday, November 27, 2018 2:22 PM -0800 Daniel Howard
>  wrote:
>


> > I had been yearning for a config file, and it turns out I had them all
> > along!
>
> It's a database, not configuration files.  Removing files from underneath
> a
> database is generally not a good idea, although YMMV.
>
> > I am sharing my experience here, for the next person who finds themselves
> > googling around, trying to figure out how to remove or tweak a config in
> > OpenLDAP. It is nowhere near as complicated as what I had read.
>
> This is the wrong advice.  It is also fairly trivial to do what you
> avoided.
>
> a) slapcat -n 0 -l /tmp/config.ldif
> b) Remove the duplicate entries from /tmp/config.ldif
> c) mv /path/to/current/config /path/to/current/config.old;mkdir -p
> /path/to/current/config
> d) slapadd -n 0 -l /tmp/config.ldif
>

I can see how a naive sysadmin might interpret the various text files in
/etc/ldap/slapd.d/cn=config/ as configuration files ... that could be
carefully edited by hand ... or managed programatically through the local
configuration management system.

I appreciate your admonition that this interpretation is wrong, and that
these would-be "config" files in the system configuration file hierarchy
are in fact a software-managed database, so we should not edit what appear
to be plain text configuration files, but simply export them to a text
file, carefully edit the export of the database, delete the entire config
file hierarchy, and then reimport the database.

If I may make a minor feature suggestion: whenever I get a file into /etc
that needs a special workflow, I like to put warnings  in the comments at
the top of such files, advising that the file(s) shouldn't be edited by
hand, and explaining the proper workflow. (The visudo command is a golden
standard in this regard.)

djh@djh-p5510 ~> sudo head -3 /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#

Perhaps this is a consideration that is already on the roadmap?

Thanks,
-danny

-- 
http://dannyman.toldme.com

On removing a duplicated ppolicy overlay

[Daniel Howard]

Hello,

Back in April or May, I was trying to add and tweak a password policy,
invoking a command like this multiple times:

sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -a -f ppolicy-overlay.ldif

This created multiple password policy overlays, and the LDAP server started
to crash with some frequency.

Of course, you can not use this interface to DELETE a policy overlay, so I
went about researching "hot to remove a ppolicy overlay" and go into some
complicated process where you have to export the database, remove olc*
entries, delete your database and re-import. My attention shifted to other
priorities.

Yesterday, I turned back to the question of how to remove the duplicated
ppolicy overlays and started exporting the database, but I couldn't find
the ppolicy stuff in my slapcat output.

Another trip to the search mines and I discovered this gem:
https://serverfault.com/a/280836/72839

While you are asked to configure stuff using an LDAP command that cannot
delete duplicate policy overlays, the config data doesn't get written into
the database, but just placed in plain-text files in a directory structure.
Removing duplicated overlays is as simple as stop slapd, remove the files,
start slapd. Similarly, you could tweak your ppolicy overlay or possibly
even bootstrap new servers by merely editing the right config files in the
right place.

I had been yearning for a config file, and it turns out I had them all
along!

I am sharing my experience here, for the next person who finds themselves
googling around, trying to figure out how to remove or tweak a config in
OpenLDAP. It is nowhere near as complicated as what I had read.

Thanks,
-danny

-- 
http://dannyman.toldme.com

Duplicate Password Policies and Can Not Rest User Password

[Daniel Howard]

Hello,

I have two issues. One is I gave myself redundant *ppolicy* overlays I
can't delete. The other is I don't know why I can not reset a user's
password.

The first is that in a rush, late at night, I ended up with multiple
(duplicate) Password Policy Overlays. I went back and tried to delete
these, but:

$ *sudo ldapmodify -Q -Y EXTERNAL -H ldapi:///*
dn: olcOverlay={5}ppolicy,olcDatabase={1}hdb,cn=config
changetype: delete
deleting entry "olcOverlay={5}ppolicy,olcDatabase={1}hdb,cn=config"
ldap_delete: Server is unwilling to perform (53)

It looks like this is a known consideration, per
http://www.zytrax.com/books/ldap/ch6/slapd-config.html#use-overlays and
that I'll have to cowboy the server config to get the redundant overlays
removed.

root@ldap0:~# *slapd -V*
@(#) $OpenLDAP: slapd  (Ubuntu) (May 31 2017 21:52:16) $
buildd@lgw01-30
:/build/openldap-tnOaja/openldap-2.4.31/debian/build/servers/slapd

Okay, so what is that overlay? Pretty simple stuff:

dn: olcOverlay={2}ppolicy,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {2}ppolicy
olcPPolicyDefault: cn=passwordDefault,ou=Policies,dc=qd,dc=com
olcPPolicyHashCleartext: FALSE
olcPPolicyUseLockout: FALSE
olcPPolicyForwardUpdates: FALSE

(But defined four times ... {2..5})

What is the problem, then? The problem is I can not set a user's password.

root@ldap0:~#
*/usr/bin/ldappasswd -y /etc/ldapscripts/ldapscripts.passwd -D
cn=admin,dc=qd,dc=com -x -H ldap://localhost -T /tmp/ldapsetpasswd
uid=zachary,ou=People,dc=qd,dc=com*
Result: No such attribute (16)

Say what?

​dn: uid=zachary,ou=People,dc=qd,dc=com
structuralObjectClass: account
entryUUID: cd55cc80-f8a5-1037-976e-9da738d41e24
creatorsName: cn=admin,dc=qd,dc=com
createTimestamp: 20180530223739Z
pwdFailureTime: 20180530223741Z
pwdFailureTime: 20180530224243Z
pwdFailureTime: 20180530224244Z
pwdFailureTime: 20180530224306Z
pwdFailureTime: 20180530224307Z
pwdFailureTime: 20180530224354Z
pwdFailureTime: 20180530224538Z
pwdFailureTime: 20180530224541Z
entryCSN: 20180530224541.157285Z#00#000#00
modifiersName: cn=admin,dc=qd,dc=com
modifyTimestamp: 20180530224541Z
entryDN: uid=zachary,ou=People,dc=qd,dc=com
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE

Maybe the user is locked out?

​root@ldap0:~# *ldapmodify -Q -Y EXTERNAL -H ldapi:/// -D
cn=admin,dc=qd,dc=com*
dn: uid=zachary,ou=People,dc=qd,dc=com
changetype: modify
delete: pwdFailureTime
modifying entry "uid=zachary,ou=People,dc=qd,dc=com"
ldap_modify: Constraint violation (19)
additional info: pwdFailureTime: no user modification allowed

Q1: Any bright idea on removing the redundant ppolicy overlays?

Q2: Any bright idea on what's up with resetting zachary's password?

Thanks,
-danny


-- 
http://dannyman.toldme.com

Re: removing ppolicy overlay

[Daniel Howard]

On Thu, Apr 19, 2018 at 5:12 AM, Frank Swasey  wrote:
>
> For future reference here's the procedure that I've worked up:
>
> shutdown slapd on all MMR members
> slapcat the database
> edit the database to remove all "pwd*" attributes and all entries that are
> pwd* objectClass
> edit the slapd.conf file (if you are using slapd.d you are on your own)
> replace the database (delete, and slapadd)
> Empty the accesslog database if you are using that
> start slapd
>
> Copy your edited database to the rest of your servers and use the tried
> and true "nuke & repave" process to delete the existing database, edit the
> config, slapadd the edited database


​Frank,

Thank you for outlining this process​. Does anyone have a preferred "hand
holding" walkthrough they could recommend for this type of procedure, for
those of us who are not as confident in our OpenLDAP prowess?

​Cheers,
-danny​


-- 
http://dannyman.toldme.com

Replication Broke

[Daniel Howard]

Hello,

He have OpenLDAP replication set up based on the docs at
https://help.ubuntu.com/lts/serverguide/openldap-server.html#openldap-server-replication

I noticed recently a symptom, whereby a new user exists only on the primary.

So, I started to debug:

Master: (ldap0)

0-16:23 djh@ldap0 ~$ ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base -b
dc=qd,dc=com contextCSN
dn: dc=qd,dc=com
contextCSN: 20180113002606.399160Z#00#000#00

Consumer: (ldap1)

0-16:23 djh@ldap1 ~$ ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base -b
dc=qd,dc=com contextCSN
dn: dc=qd,dc=com
contextCSN: 20171121212631.416502Z#00#000#00

Ooohhh, my!

I have a lot of messages like this on the consumer:

Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_message_to_entry: rid=317 DN:
uid=djh,ou=People,dc=qd,dc=com, UUID:
29f7fc06-7c2a-1035-83e5-9d6082b37970
Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_entry: rid=317
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_entry: rid=317 inserted UUID
29f7fc06-7c2a-1035-83e5-9d6082b37970
Jan 12 16:28:55 ldap1 slapd[5383]: dn_callback : entries have identical CSN
uid=djh,ou=People,dc=qd,dc=com
20180113002133.183992Z#00#000#00
Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_entry: rid=317 be_search (0)
Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_entry: rid=317
uid=djh,ou=People,dc=qd,dc=com
Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_entry: rid=317 entry unchanged,
ignored (uid=djh,ou=People,dc=qd,dc=com)
Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_message_to_entry: rid=317 DN:
uid=john,ou=People,dc=qd,dc=com, UUID:
ddaae880-7c2f-1035-83ed-9d6082b37970
Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_message_to_entry: rid=317 mods
check (pwdChangedTime: attribute type undefined)
Jan 12 16:28:55 ldap1 slapd[5383]: do_syncrepl: rid=317 rc 17 retrying

What is funny is I can, for example, change the loginshell on my account,
and that replicates.

Is the latter message about pwdChangedTime a clue that maybe I had a schema
change on Master that hasn't been applied to Consumer?

Please advise on where to look next? Thanks!

-danny

-- 
http://dannyman.toldme.com

Re: Replication Broke

[Daniel Howard]

Followup: I had added a ppolicy module to Master but not to Consumer. Thus
the message about pwdChangeTime. Adding the module to consumer fixed
replication.

-danny

On Fri, Jan 12, 2018 at 4:33 PM, Daniel Howard <danny...@toldme.com> wrote:

> Hello,
>
> He have OpenLDAP replication set up based on the docs at
> https://help.ubuntu.com/lts/serverguide/openldap-server.
> html#openldap-server-replication
>
> I noticed recently a symptom, whereby a new user exists only on the
> primary.
>
> So, I started to debug:
>
> Master: (ldap0)
>
> 0-16:23 djh@ldap0 ~$ ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base
> -b dc=qd,dc=com contextCSN
> dn: dc=qd,dc=com
> contextCSN: 20180113002606.399160Z#00#000#00
>
> Consumer: (ldap1)
>
> 0-16:23 djh@ldap1 ~$ ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base
> -b dc=qd,dc=com contextCSN
> dn: dc=qd,dc=com
> contextCSN: 20171121212631.416502Z#00#000#00
>
> Ooohhh, my!
>
> I have a lot of messages like this on the consumer:
>
> Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_message_to_entry: rid=317 DN:
> uid=djh,ou=People,dc=qd,dc=com, UUID: 29f7fc06-7c2a-1035-83e5-
> 9d6082b37970
> Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_entry: rid=317
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
> Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_entry: rid=317 inserted UUID
> 29f7fc06-7c2a-1035-83e5-9d6082b37970
> Jan 12 16:28:55 ldap1 slapd[5383]: dn_callback : entries have identical
> CSN uid=djh,ou=People,dc=qd,dc=com 20180113002133.183992Z#00#
> 000#00
> Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_entry: rid=317 be_search (0)
> Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_entry: rid=317
> uid=djh,ou=People,dc=qd,dc=com
> Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_entry: rid=317 entry
> unchanged, ignored (uid=djh,ou=People,dc=qd,dc=com)
> Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_message_to_entry: rid=317 DN:
> uid=john,ou=People,dc=qd,dc=com, UUID: ddaae880-7c2f-1035-83ed-
> 9d6082b37970
> Jan 12 16:28:55 ldap1 slapd[5383]: syncrepl_message_to_entry: rid=317 mods
> check (pwdChangedTime: attribute type undefined)
> Jan 12 16:28:55 ldap1 slapd[5383]: do_syncrepl: rid=317 rc 17 retrying
>
> What is funny is I can, for example, change the loginshell on my account,
> and that replicates.
>
> Is the latter message about pwdChangedTime a clue that maybe I had a
> schema change on Master that hasn't been applied to Consumer?
>
> Please advise on where to look next? Thanks!
>
> -danny
>
> --
> http://dannyman.toldme.com
>



-- 
http://dannyman.toldme.com

Re: Disable Linux commands for LDAP users

[Daniel Howard]

Unix doesn't really work that way but maybe you make your special ldap user
password script check if the user is in LDAP: if they are, do LDAP
password, if they are not, wrap around Unix password.

Easier lazy solution is to have a passwd-ldap and a passwd-unix command,
then replace passwd with a little script that tells the user to invoke the
appropriate command.

-danny

On Thu, Oct 20, 2016 at 9:15 AM, Bernard Fay  wrote:

> Hi,
>
> I would like to able to disable some Linux commands for LDAP users. One of
> those commands is passwd.  Because of some specific needs, when the LDAP
> users have to change their password a special script has been created for
> this purpose.  They MUST not use passwd but this command is still required
> by local users.
>
> Does one of you might have an idea to disable Linux commands for LDAP
> users only?
>
> Thanks,
> Bernard
>
>


-- 
http://dannyman.toldme.com

Re: Should I use OpenLDAP or PostgreSQL for this?

[Daniel Howard]

I reckon that either platform could give sufficient performance. Another
question to ask is which platform your technical contributors are going to
be most comfortable with. From what I have seen, developers are far more
likely to be comfortable with a traditional relational database like
postgres. Even at the systems level, you might have better luck sourcing a
DBA to figure out scaling / performance issues than an LDAP guru.

That said, in my experience, the OpenLDAP has fewer "moving parts" and if
your data can live in memory then there is very little tuning to do. LDAP
is also handier to query from command-line, FWIW, and you could use it as
an authentication mechanism for the contacts in your database if you wanted
to do such a thing.

-danny

On Fri, Aug 19, 2016 at 4:41 PM, John Lewis  wrote:

> I want to start a project to document my local government starting at
> the municipal level and going upwards from there. I want to build an
> interface to allow people to look up their representatives and their
> public servants by issue and geographic area or issue and get their
> contact information back.
>
> I want it to to have fast lookups so community organizers will come to
> my site first they want to find out who does what. I would also like it
> to be able to scale geographically so I can get local activist could
> have their own copy of the database on a local server that they can also
> delegate access to. I would like to delegate updates to a development
> version of the database to other people similar to Open Street Map, but
> I would still like to verify changes so there won't be a flood of bad
> data. The presentation and the data storage will be separate components.
>
> Knowing this information could you tell me what data management engine
> would be more appropriate for the task?
>
>
>
>


-- 
http://dannyman.toldme.com

Documentation

[Daniel Howard]

Hello,

Some thoughts I have had about OpenLDAP Documentation over the weekend 

My overarching concern is one of process. My day job is Ops, and especially
at scale a documentation process is critical to success. And what this
boils down to is that:

   - checking documentation is a part of the routine Ops process
   - refining that documentation so that it is on-point, concise, and
   relevant is part of the Ops process
   - when the documentation proves insufficient, the matter can quickly be
   escalated with Experts
   - review of documentation is a routine duty of the Experts, and is part
   of the process of deploying new infrastructure

With this framework (paraphrasing ITIL

and KCS ) in
mind, some reactions to my experiences with your community and the recent
thread:

*Efficient Knowledgebase*

This is always a tricky nut to crack ... people love Stack Overflow these
days ... there's an existing corpus in the mailing lists. One thing I have
done in the past is tie in resources with Google ... might be helpful
to if this
page  had a Google custom site search .. I
just tried setting one up

to search all of the mailing list archives, issue tracker, F-o-M,
stackexchange and serverfault "openldap" keywords ... I am underwhelmed at
the results but you folks might have some better idea of "hot topics" and
strong resources to try.

Howard Chu pointed out that he has configured F-o-M to show *him* dates ...
maybe this can be the default? ;)

If you can get something good running, it makes answering some dumb
questions on the list easier .. you can politely point them to the search
with the appropriate keywords .. a la "let me google that for you" and the
clever ones will catch on ... if you find the search mechanism less than
clear, then maybe some of the docs can be tweaked a bit for
keyword-matching, or be revised to cover a more general case or an example
... when a user asks me a dumb question, I try to step through how they
would get the answer ... sometimes that stepping needs some help on my
part, but on a good day I teach a user to fish ...

*Ease of Updating Documentation*

I had no idea but it looks like anyone can contribute to F-o-M.  Nice.  Let
us, say, however, I had questions or amendments or heck contributions to
the quick start guide?  http://www.openldap.org/doc/admin24/quickstart.html
There's a footer at the bottom that implies the content is five years old
and I'd bet $2 based on personal experience that I am not getting good
answers from i...@openldap.org.  A contrast I dealt with recently is, say, this
Ansible tutorial  ... at first, it
seemed weird to host documentation on github but there on the top page they
get to explaining that they are open to community contributions: fork, pull
request,   I made some modest contribution myself: one of the first pull
requests I ever made. Felt great. I then made some amendments to the GWM
project, as their documentation is similarly hosted in a format I already
know how to contribute to. :)

So, Howard Chu says OpenLDAP will never rely on github. Fair enough ... as
an aside, I have seen at least one project maintain a github repo as sort
of a managed two-way mirror to their traditional repo: this was done by
contributors who wanted to hack around on the code in a convenient tool,
and then patches are evaluated and brought into not-git core ... which is
to say you could, if you desired, use github without relying on it ... but
anyway ... this comprehensive document
 could have a section on engaging the
authors and the process of contributing amendments, maybe linked from the
footer, which could have a dynamic bit of code that shows the current year
(or last modified year?) so as not to scare anyone that the living
documentation is crazy stale.

*Documentation as Part of Deployment*

This struck me in my recent discussion around troubles with the Quickstart
guide: when I went to use the quickstart guide, the documentation did not
match the software, because the software had recently been changed. Best
practice would be to bundle documentation updates in to the release. If, in
my own Operations, I deployed changes to a service without reviewing and
amending the Operational documentation, the nicest word I could use to
describe that is "messy."

*Tone*

The attitude I have witnessed and experienced on the mailing list is
off-putting. For example, I recently needed to re-order ACL rules, but as
part of that I would be changing the order of rules I depended on to make
the modification. Classic "lock yourself out of the firewall" setup. So, I
used Google, dug around in the documentation, hoped that such a 

Re: Documentation

[Daniel Howard]

On Apr 30, 2016 1:03 PM, "Quanah Gibson-Mount" <qua...@zimbra.com> wrote:
>
> --On Saturday, April 30, 2016 11:41 AM -0700 Daniel Howard <
danny...@toldme.com> wrote:
>
>>
>> My recent experience is OpenLDAP on Ubuntu. I thought I would go with
>> OpenLDAP's guide because they should know better, but the quick start was
>> for older versions or something and hadn't been updated.
>
>
> Apparently you haven't read the quickstart guide in a while.

About March-April, if memory serves. Feels like longer.

-Danny

Re: Documentation

[Daniel Howard]

My recent experience is OpenLDAP on Ubuntu. I thought I would go with
OpenLDAP's guide because they should know better, but the quick start was
for older versions or something and hadn't been updated.

I like documentation systems that allow for user feedback, comments, or
patches via github. If you want community improvements then maybe low
hanging fruit is a link in the doc template on how to interact with the
documentation If the current docs platform has no mechanism for
feedback and comments on a specific document, the source code/ build
process is obscure ... Maybe consider porting even a "fork " to github and
solicit community feedback (you can file issues in a familiar mechanism,
and take in patches from dudes like me...)

For what it's worth, the Ubuntu OpenLDAP quick start guide and only a few
minor hiccups, and I would recommend that resource for anyone looking to
implement or update a quickstart guide.

The Faq-o-Matic ... Man a modern stack overflow site might be nice but a
question in the back of my mind is whether the advice is still useful. I
don't know if the FoM does this but if the answers showed dates then I
could evaluate an answer that's say 2-4 years old with greater confidence
than say something 12 years old ... One of the challenges of a venerable,
old and mature project like OpenLDAP.

I guess what I'm trying to say, from my mobile phone, is if the
documentation were more "agile" in engaging the community for identifying
issues and taking in corrections, we may all be happier.

I would be open to volunteering to port docs...

Thanks,
-Danny

-- 
Sent from my Western Electric Model 500
On Apr 29, 2016 5:01 PM, "Gavin Henry"  wrote:

Hi all,

List what you love about our docs:

List what you hate:

List what you'd love to see:

List what you can help with:

Thanks.

--
Kind Regards,
Gavin Henry.

Re: Safely Allow Users to Write self Attributes

[Daniel Howard]

I had to do it this way:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
delete: olcAccess
olcAccess: {2}to * by dn="cn=admin,dc=example,dc=com" write by * read
-
add: olcAccess
olcAccess: {2}to attrs=sshPublicKey,gecos by self write
-
add: olcAccess
olcAccess: {3}to * by dn="cn=admin,dc=example,dc=com" write by * read

You can not have, for example, multiple {2} so you have to delete and then
add.  In this case, I was using sudo to do the ldapmodify instead of admin,
so no risk of lockout.  What I am wondering is if this is at all like an
atomic transaction: either you can apply the whole LDIF at once or not ...
if it happens in one go you won't get locked out ...

In the mailing list archives I found a suggestion (no example) that you
could somehow insert a rule by number ...


On Mon, Mar 21, 2016 at 2:28 PM, Daniel Howard <danny...@toldme.com> wrote:

> I would like to allow users to ldapmodify a few of their attibutes ...
> sshPublicKey,gecos ..
>
> This does not appear to do the trick:
>
> 0-14:08 djh@ldap0 ~$
> *sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \> cn=config
> '(olcDatabase={1}hdb)' olcAccess*
> dn: olcDatabase={1}hdb,cn=config
> olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
> anonymou
>  s auth by dn="cn=admin,dc=example,dc=com" write by * none
> olcAccess: {1}to dn.base="" by * read
> olcAccess: {2}to * by dn="cn=admin,dc=example,dc=com" write by * read
> olcAccess: {3}to attrs=sshPublicKey,gecos by self write
>
> Why? I would guess the {2} rule "to * by * read" has precedence.
>
> As I understand it, if I wanted to re-order those rules, I would delete
> and rewrite the rules. This would require me to delete the rule that gives
> admin the access to write the rules in the first place ... sounds like a
> way to lock myself out of my LDAP database?
>
> So, my guess is that I want and LDIF like so:
>
> dn: olcDatabase={1}hdb,cn=config
> changetype: modify
> remove: olcAccess
> olcAccess: {3}to attrs=sshPublicKey,gecos by self write
> -
> add: olcAccess
> olcAccess: {2}to attrs=sshPublicKey,gecos by self write
> -
> add: olcAccess
> olcAccess: {3}to * by dn="cn=admin,dc=example,dc=com" write by * read
> -
> remove: olcAccess
> olcAccess: {2}to * by dn="cn=admin,dc=example,dc=com" write by * read
>
> If I run this as cn=admin then it should:
>
> 1) Remove ineffective {3}
> 2) Add an effective {2} (now there are two {2}s..)
> 3) Add a new {3} to match incumbent {2}
> 4) Remove incumbent {2}
>
> I shouldn't lock myself out because I add a new rule for admin access
> before deleting the old rule, and as far as LDAP is superficially
> concerned, all these olcAccess attributes are just unique records, so the
> conflicting number rules aren't going to be a problem .. ?
>
> Am I on the right track?
>
> Thanks,
> -danny
>
> --
> http://dannyman.toldme.com
>



-- 
http://dannyman.toldme.com

Safely Allow Users to Write self Attributes

[Daniel Howard]

I would like to allow users to ldapmodify a few of their attibutes ...
sshPublicKey,gecos ..

This does not appear to do the trick:

0-14:08 djh@ldap0 ~$
*sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \> cn=config
'(olcDatabase={1}hdb)' olcAccess*
dn: olcDatabase={1}hdb,cn=config
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
anonymou
 s auth by dn="cn=admin,dc=example,dc=com" write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by dn="cn=admin,dc=example,dc=com" write by * read
olcAccess: {3}to attrs=sshPublicKey,gecos by self write

Why? I would guess the {2} rule "to * by * read" has precedence.

As I understand it, if I wanted to re-order those rules, I would delete and
rewrite the rules. This would require me to delete the rule that gives
admin the access to write the rules in the first place ... sounds like a
way to lock myself out of my LDAP database?

So, my guess is that I want and LDIF like so:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
remove: olcAccess
olcAccess: {3}to attrs=sshPublicKey,gecos by self write
-
add: olcAccess
olcAccess: {2}to attrs=sshPublicKey,gecos by self write
-
add: olcAccess
olcAccess: {3}to * by dn="cn=admin,dc=example,dc=com" write by * read
-
remove: olcAccess
olcAccess: {2}to * by dn="cn=admin,dc=example,dc=com" write by * read

If I run this as cn=admin then it should:

1) Remove ineffective {3}
2) Add an effective {2} (now there are two {2}s..)
3) Add a new {3} to match incumbent {2}
4) Remove incumbent {2}

I shouldn't lock myself out because I add a new rule for admin access
before deleting the old rule, and as far as LDAP is superficially
concerned, all these olcAccess attributes are just unique records, so the
conflicting number rules aren't going to be a problem .. ?

Am I on the right track?

Thanks,
-danny

-- 
http://dannyman.toldme.com

Replication Failing with TLS ... Sneaky Little Config Error

[Daniel Howard]

I have set up OpenLDAP per the nice tutorial at
https://help.ubuntu.com/lts/serverguide/openldap-server.html and on my
previous run-throughs, I succeeded at setting up replication via TLS. But
now that I'm implementing on the dedicated hardware, I am not able to
replicate via TLS.

SOLUTION: It turns out the solution was to add a space to an LDIF file ...

On PROVIDER I will see, for example:

Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 fd=49 ACCEPT from IP=
10.10.3.117:60277 (IP=0.0.0.0:389)
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=0 BIND dn="" method=128
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=0 RESULT tag=97 err=0 text=
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=1 SRCH
base="dc=qd,dc=com" scope=2 deref=0
filter="(&(objectClass=posixAccount)(uidNumber=2043))"
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=1 SRCH attr=uid
userPassword uidNumber gidNumber cn homeDirectory loginShell gecos
description objectClass
Mar 14 16:13:15 ldap0 slapd[1536]: <= bdb_equality_candidates: (uidNumber)
not indexed
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=1 SEARCH RESULT tag=101
err=0 nentries=1 text=
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=2 SRCH
base="dc=qd,dc=com"
scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=djh))"
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=2 SRCH attr=uid
userPassword uidNumber gidNumber cn homeDirectory loginShell gecos
description objectClass
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=2 SEARCH RESULT tag=101
err=0 nentries=1 text=
Mar 14 16:13:16 ldap0 slapd[1536]: conn=1392 op=3 UNBIND

While on CONSUMER:

Mar 14 16:13:15 ldap1 slapd[3672]: @(#) $OpenLDAP: slapd  (Ubuntu) (Sep 15
2015 18:19:13) $#012#011buildd@lgw01-53
:/build/openldap-2QUgtL/openldap-2.4.31/debian/build/servers/slapd
Mar 14 16:13:16 ldap1 slapd[3673]: slapd starting
Mar 14 16:13:16 ldap1 slapd[3673]: do_syncrepl: rid=317 rc -1 retrying
Mar 14 16:13:16 ldap1 sudo: pam_unix(sudo:session): session closed for user
root
Mar 14 16:13:23 ldap1 slapd[3673]: conn=1000 fd=13 ACCEPT from IP=
10.10.5.3:15197 (IP=0.0.0.0:389)
Mar 14 16:13:23 ldap1 slapd[3673]: conn=1000 fd=13 closed (connection lost)

I *CAN* to TLS from consumer to master:

0-16:18 djh@ldap1 ~$ *ldapsearch -LLL -x -ZZ -H
ldap://ldap0.mtv.**qd.com
uid=djh cn*
dn: uid=djh,ou=People,dc=qd,dc=com
cn: djh

So, I increase olcLogLevel to add sync:

Mar 14 16:22:09 ldap1 slapd[4133]: @(#) $OpenLDAP: slapd  (Ubuntu) (Sep 15
2015 18:19:13) $#012#011buildd@lgw01-53
:/build/openldap-2QUgtL/openldap-2.4.31/debian/build/servers/slapd
Mar 14 16:22:10 ldap1 slapd[4134]: slapd starting
Mar 14 16:22:10 ldap1 sudo: pam_unix(sudo:session): session closed for user
root
Mar 14 16:22:10 ldap1 slapd[4134]: do_syncrep2: rid=317
cookie=rid=317,csn=20160314224255.836334Z#00#000#00
Mar 14 16:22:10 ldap1 slapd[4134]: slap_queue_csn: queing 0x7f0c5c114995
20160314224255.836334Z#00#000#00
Mar 14 16:22:10 ldap1 slapd[4134]: slap_graduate_commit_csn: removing
0x7f0c5c114d10 20160314224255.836334Z#00#000#00
Mar 14 16:22:10 ldap1 slapd[4134]: do_syncrepl: rid=317 rc -1 retrying

THAT is the contextCSN on the provider!

0-16:24 djh@ldap0 ~$ *ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base
-b dc=qd,dc=com contextCSN # provider*
dn: dc=qd,dc=com
contextCSN: 20160314224255.836334Z#00#000#00

0-16:22 djh@ldap1 ~$ *ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base
-b dc=qd,dc=com contextCSN # consumer*
dn: dc=qd,dc=com
contextCSN: 20160314224152.708568Z#00#000#00

As best I can tell, the connection works, the replication works, but the
consumer is not asking for TLS.

0-16:29 djh@ldap1 ~$
*sudo ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b cn=config
olcDatabase={1}hdb olcSyncRepldn: olcDatabase={1}hdb,cn=config*
olcSyncrepl: {0}rid=317 provider=ldap://ldap0.mtv.qd.com
bindmethod=si
 mple binddn="cn=admin,dc=qd,dc=com" credentials=secret searchbase
 ="dc=qd,dc=com" logbase="cn=accesslog"
logfilter="(&(objectClass=audi
 tWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist
retry="
 60 +" syncdata=accesslogstarttls=critical tls_reqcert=demand

If I rip out starttls=critical tls_reqcert=demand then sync works no
problem.

If I enable logging on the PROVIDER I see:

Mar 14 16:35:46 ldap0 slapd[6838]: @(#) $OpenLDAP: slapd  (Ubuntu) (Sep 15
2015 18:19:13) $#012#011buildd@lgw01-53
:/build/openldap-2QUgtL/openldap-2.4.31/debian/build/servers/slapd
Mar 14 16:35:46 ldap0 slapd[6839]: slapd starting
Mar 14 16:35:46 ldap0 sudo: pam_unix(sudo:session): session closed for user
root
Mar 14 16:35:49 ldap0 slapd[6839]: conn=1000 fd=27 ACCEPT from IP=
10.10.5.3:17876 (IP=0.0.0.0:389)
Mar 14 16:35:49 ldap0 slapd[6839]: conn=1000 fd=27 closed (connection lost)
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 fd=27 ACCEPT from IP=
10.10.3.117:60312 (IP=0.0.0.0:389)
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=0 BIND dn="cn=admin,dc=