Re: Antw: openldap 2.4.40 ppolicy module and shadowInactive equivalent

2016-10-31 Thread Real, Elizabeth (392K) 
Ulrich,
Yes, I already have nis.ldif loaded. What else do you suggest?
Thank you,
Liz

From: Ulrich Windl 
Date: Monday, October 24, 2016 at 11:17 PM
To: "Real, Elizabeth (392K)" , 
"openldap-technical@openldap.org" 
Subject: Antw: openldap 2.4.40 ppolicy module and shadowInactive equivalent

"Real, Elizabeth (392K)" 
> schrieb am 
24.10.2016 um
20:43 in Nachricht 
<0c90a104-2ef4-4aa6-8748-05b07154a...@jpl.nasa.gov>:
Hello,
I setup a password policy overlay on my openldap 2.4.40 servers running
RHEL7. I need to enforce the following: disable accounts that have been
inactive for 180 days. In the past we were able to do this by simply adding
the shadowInactive attribute to each account: shadowInactive 180. But with
the new openldap, it appears there is no equivalent attribute??

Why didn't you "grep shadowInactive /etc/openldap/schema/*"?
It appears in nis.ldif, nis.schema, and rfc2307bis.schema.
(I only have SLES11 SP4 here, but there shouldn't be a big difference)

Ulrich

http://www.openldap.org/doc/admin24/
http://www.zytrax.com/books/ldap/ch6/ppolicy.html
Thank you,
Liz

Re: Syncrepl only partially working

2016-10-31 Thread Quanah Gibson-Mount 
--On Sunday, October 30, 2016 11:16 AM +0100 Dieter Klünter 
 wrote:



It is a bit more complicated than that.
syncrepl is a client operation, which requires ldap client
configuration, specified in ldap.conf(5).


You can set these specifically for the syncrepl client as a part of your 
syncrepl configuration stanza, rather than ldap.conf.  See slapd.conf(5) or 
slapd-config(5), the section on syncrepl/olcSyncRepl, the sizelimit and 
timelimit parameters.


But, regardless, the server limits on the master trump any client settings 
that are higher than the defaults, so as Dieter noted, they must be 
increased on the master to "unlimited" for at least the replicator DN.


This is of course covered in the admin guide.  For example, in section 
18.3.2, we find:


# Let the replica DN have limitless searches
limits dn.exact="cn=replicator,dc=symas,dc=com" time.soft=unlimited 
time.hard=unlimited size.soft=unlimited size.hard=unlimited


as one example.

etc.

Regards,
Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: some memberUid in my database are hashed

2016-10-31 Thread Giovanni Biscuolo 
Dear all,

now I've understood the meaning of "memberUid::" attributes: stupid me I
was not able to sort this out by myself and contributed generating more
noise on this list

**thank you very much** to the ones that helped me understand this

now that all things are clear, **please consider this solved** :-)

I'm not going to reply to any further message in this thread unless they
bring something new or interesting on the topic

for those who are interested in details about the last messages I read
in this thread, below are my *last* comments

ciao
Giovanni

* Johannes Löthberg [2016-10-27 14:32:05 +0200]:

> On 26/10, Giovanni Biscuolo wrote:

[...]

> >to be a little more clear: "getent group" does not show the base64 encoded
> >users (aka listed as "memberUid:: ..." in LDIF)
> >
> >on the other side, "groups " correctly lists all the groups the user
> >is member of, despite the base64 encoding of its memberUid attribute

[...]

> First of all, which version of nss_ldap are you using,

the one from libnss-ldapd ver. 0.8.13-3ubuntu1

> and could you post your config?

no thanks, it would not add useful infos (beleave me, it's pretty
default)

> (Though I'd also recommend switching to nss-pam-ldapd instead, which
> is actually maintained.)

I agree :-)

* Michael Ströder [2016-10-27 16:06:04 +0200]:

[...]


> IGFyaWFubmE= is simply ' arianna' with space as first character (hence the
> base64-encoding of the attribute value in the LDIF output).

OK thank you, now it's pretty clear that it's a base64 encoded
memberUid value, it's encoded because the user name has one ledaing
space [1]

> No wonder why the
> group membership of user arianna is not correct. It must match exactly.
> Computers are like that.

beleave me or not: "groups arianna" returns me a complete list of
groups for arianna, included the ones in which arianna is enumerated as
a base64 memberUid attribute value (with one leading space)

same story for unix permissions and nfsv4 ACLs (and CIFS via SAMBA via
nfsv4 too)

> => fix the attribute value

no thanks: they are too much **and** group membership (so permissions
too) are working fine in my infrastructure

I've also managed to write a simple ldapsearch wrapper script to list
the members of specific (or all) groups

ciao a tutti
Giovanni


[1] still not cleat to me what tool (sure it was not manually done) did
that, but this is OT **for sure**

-- 
Giovanni Biscuolo
Xelera - IT infrastructures
http://xelera.eu/contact-us/

**per favore** Quota Bene: http://wiki.news.nic.it/QuotarBene
**please** use Inline Reply: 
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style


signature.asc
Description: Digital signature

Defining timeouts in slapd-ldap Backend

2016-10-31 Thread Daniel Betz 
Hi List,

i have an problem with slapd-ldap backend and the timeouts.

There are many timeouts to configure, but i think they dont work in the tls 
handshake phase.

5816f773 send_ldap_result: conn=-1 op=0 p=0
5816f773 backend_startup_one: starting "sid=3092,sec=webhosting,o=xx,c=de"
5816f773 ldap_back_db_open: URI=ldaps://sid3092.int.webslave.xxx
ldap_create
ldap_url_parse_ext(ldaps://sid3092.int.webslave.)
5816f773 =>ldap_back_getconn: conn=-1 op=0: lc=0x37c2880 inserted refcnt=1 rc=0
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP sid3092.int.webslave.x:636
ldap_new_socket: 256
ldap_prepare_socket: 256
ldap_connect_to_host: Trying 10.xx.xx.xx:636
ldap_pvt_connect: fd: 256 tm: 5 async: 0
ldap_ndelay_on: 256
attempting to connect:
connect errno: 115
ldap_int_poll: fd: 256 tm: 5
ldap_is_sock_ready: 256
ldap_ndelay_off: 256
ldap_pvt_connect: 0
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A

And then the slapd hangs and hangs.

I know that the consumer ldap is running, but the server itself hangs with an 
error. In this slapd there are 250 more servers to serve via slapd-ldap, so 
this will cause an big problem when only one server hangs and the slapd stucks 
forever.
Are there any other timeouts to configure in slapd-ldap backend ?


Here´s the slapd.conf:

database ldap
hidden on
suffix "sid=3092,sec=webhosting,o=,c=de"
rootdn "cn=,sid=3092,sec=webhosting,o=x,c=de"
uri ldaps://sid3092.int.webslave.x
network-timeout 5
timeout bind=5
lastmod on
restrict all

acl-bindbindmethod=simple
binddn="cn=xx,sid=3092,sec=webhosting,o=xx,c=de"
credentials="PASSWORD"

syncreplrid=3092
provider=ldapi://%2Fvar%2Frun%2Fldapi
binddn="cn=Manager,o=xxx,c=de"
bindmethod=simple
credentials=PASSWORD
searchbase="sid=3092,sec=webhosting,o=xx,c=de"
type=refreshAndPersist
retry="10 6 30 +"

overlay syncprov


Regards,
Daniel



Freundliche Grüße,

Daniel Betz
System Design Engineer / Senior Systemadministration
___

domainfactory GmbH
Oskar-Messter-Str. 33
85737 Ismaning
Germany

Telefon:  +49 (0)89 / 55266-364
Telefax:  +49 (0)89 / 55266-222

E-Mail:   db...@df.eu
Internet: www.df.eu

Registergericht: Amtsgericht München
HRB-Nummer 150294, Geschäftsführer:
Tobias Mohr, Stephan Wolfram

Re: Provider-Consumer replication 2.4 OLC (second attempt)

2016-10-31 Thread Ted Hyde 

  
  
On 10/28/2016 8:00 AM,
  openldap-technical-requ...@openldap.org wrote:


  Message: 10
Date: Thu, 27 Oct 2016 11:45:46 -0700
From: Quanah Gibson-Mount 
To: Ted Hyde , openldap-technical@openldap.org
Subject: Re: Provider-Consumer replication 2.4 OLC (second attempt)
Message-ID: <2B151020D2CC5C1D45A0A2C9@[192.168.1.19]>
Content-Type: text/plain; charset=us-ascii; format=flowed

--On Tuesday, October 25, 2016 11:34 AM -0400 Ted Hyde  
wrote:


  
> Greets - (first post, second time. Don't know if it's being moderated or
> dropped, will keep trying).

  
  It ended up in my spam folder for some reason.


  
> After installation, I have two functioning standalone servers. During my
> research, I found two conflicting pieces of information. I prefer to
> perform "refreshOnly" instead of "refreshAndPersist", so some sources say
> ONLY the consumers need configuration, a couple said both sides need
> configuration AND a number of additional indices. This is likely where my
> problems arise.

  
  I strongly advise only using refreshAndPersist.  I'm not sure why you are 
referring to random how-not-to-do things on the interweb.  You should use 
the OpenLDAP admin guide:




  
> Any thoughts?

  
  Read the admin guide, as noted above.  The examples are still slapd.conf, 
but you can trivially translate those to what are necessary for cn=config.

--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:


Quanah - thanks for the response. Sorry to insult if I did - but
  thank you, I DID read the admin guide. Which as you have also
  pointed out uses slapd.conf examples. Since I am not knee-deep in
  commercial OpenLdap configuration every day (I am just a lowly IT
  admin, not a paid-to-openldap-person) I would disagree in that
  your comment that "conversion to cn=config" process isn't trivial,
  personally I get quite swamped by it, but push through as best I
  can. But if you're offering to convert my sample configs for me,
  I'd be happy to share them with you. Or perhaps you could help the
  community by providing some OLC config examples for the admin
  guide, that way us peons would be able to use that as our only
  official source instead of having to google to find "Random" help.
I *can* move to refreshAndPersist; but the service provides two
  documented options (information I got from reading the admin
  guide), the description for refreshOnly best fits my scenario and
  needs. I didn't read any reason as to *not* use - perhaps you're
  aware of a bug report that refreshOnly is broken?

Perhaps my research (which I'm sure isn't as broad as yours) just
  seemed to point to the fact that openldap will/may be depreciating
  the slapd.conf procedures, and that everyone should get on board
  with OLC as soon as possible. While I can perform the setup with
  slapd.conf (as noted in the admin guide), I was hoping to practice
  some useful technique I could use in the future.
So again thanks, but if it doesn't work out for me, perhaps I
  read on one of the last pages "check out 389 or ApacheDS instead".
Ted.

  



	
		
			

			
		
		
			
This email has been checked for viruses by Avast antivirus software.
www.avast.com