Re: [389-users] 389-users Digest, Vol 125, Issue 8 in reply to rich megginson
by Karel Lang AFD
Hello Rich and all,
thanks for the extra work and concern.
In comment to your reply (see below your text):
On 10/08/2015 02:00 PM, 389-users-request(a)lists.fedoraproject.org wrote:
> Message: 2
> Date: Wed, 7 Oct 2015 08:56:25 -0400
> From: Rich Megginson<rmeggins(a)redhat.com>
> To:389-users@lists.fedoraproject.org
> Subject: Re: [389-users] 389-users Digest, Vol 125, Issue 3
> Message-ID:<56151679.40802(a)redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 10/07/2015 08:34 AM, Karel Lang AFD wrote:
>>
>> >It is solved, problem is the script, that is recommended by fedora
>> >wiki (setupssl2.sh) as a way for automatic SSL generation for 389-DS
>> >server, is not suitable for setting up multimaster, nor master/slave
>> >scenarios.
> Correct. It is for single server self signed scenarios (e.g. testing,
> not production). You really need a "real" CA in order to issue multiple
> certs for multiple servers.
>
> If that is not clear from the docs, please let us know.
Regarding howto on fedora wiki:
originally i went according to this wiki fedora doc:
http://directory.fedoraproject.org/wiki/Howto:SSL
but it was moved - i guess here:
http://directory.fedoraproject.org/docs/389ds/howto/howto-ssl.html
I got there by going here:
http://directory.fedoraproject.org/docs/389ds/documentation.html
and then
"FAQ’s, Tech Docs" -> and then "How To’s" -> "How to Setup TLS/SSL"
And there is the link on the setupssl2.sh script. But the description of
the script is just along the lines, that it will generate the SSL CA
cert and server certs for you.
So maybe it would be good to add a sentence there, about it's usability
only for single server and not in multimaster or master/slave scenarios.
Generally speaking, i think that the Docs on wiki are great, there is
lots 'howtos' there and all helpfull links to extensive RHEL
documentations etc...
But i think, all that docs can be (IMHO) overwhelming if LDAP newb comes
1st here and needs a 'quick' way to get 'overall picture' and to start
playing with it. There is so much detailed stuff here (which is good)
but where start 1st? :-)
But i dont want to criticize or something, as it is an 'easy road' and i
appreciate all the hardwork the community does!
I think, if we had a kind of 'learn by example' guide, where there would
be shown a fast way howto setup the 389-ds on Fedora or RHEL on *real
life-like scenario*, it would be very helpful for LDAP newbs (just like
me) :-).
There you would go through install/configure/ and 1st administrative
steps quickly with links to other extensive documents at wiki (for
detail reading in case ldap newb has no clue)...
Thank you guys, you all rock! :-)
Karel
>> So as conclusion, script is OK for testing purposes and quick server
>> >setups, but not really for live or more complicated scenarios.
>> >
>> >But anyway kudos to anyone who wrote it, because i 'gutted' it in
>> >order to better understand the whole proces.
> If the documentation needs to be made more clear that the intention of
> setupssl2.sh is for demo/testing purposes only, please let us know.
>
--
*Karel Lang*
*Unix/Linux Administration*
lang(a)afd.cz | +420 731 13 40 40
AUFEER DESIGN, s.r.o. | www.aufeerdesign.cz
8 years, 6 months
Easy to use web interface to 389-ds?
by Mark Hammons
Hi,
I've set up 389-ds, and so far it works well, but I'd like to let users be
able to change their own passwords/user info on the directory server on a
webpage, and hopefully in a simple manner (the users are biologists,
they don't need to know stuff like OU, DN, etc.) Is there a good web
interface for this or do I just need to write one myself?
Thanks,
Mark Hammons
8 years, 6 months
uid case sensitivity
by Juan Ramón Moral
Hi,
is it possible to change config to make uid case insensitive?
this search return no entries.
ldapsearch -x -D "uid=*U*ser01,cn=users,dc=XXX,dc=XXX" -w XXX -s base -b
"cn=users,dc=XXX,dc=XXX"
ldap_bind: No such object (32)
matched DN: cn=users,dc=ujaen,dc=es
but this return one entry
ldapsearch -x -D "uid=*u*ser01,cn=users,dc=XXX,dc=XXX" -w XXX -s base -b
"cn=users,dc=XXX,dc=XXX"
...
# numEntries: 1
In my case, what I want is both searches returning the exact same record.
in 00core.ldif
attributeTypes: ( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' )
EQUALITY *caseIgnore*Match
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN 'RFC 4519'
X-DEPRECATED 'userid' )
Using 389-ds-base-1.3.3.1-20.el7_1 in centos 7.
Regards
--
8 years, 6 months
Question RE: 389DS
by Paul Whitney
When SSL-enabling the directory server, am I allowed to use a wildcard certificate or is it mandatory the certificate include the FQHN?
Thanks,
Paul M. Whitney
E-mail: paul.whitney(a)mac.com
Sent from my browser.
8 years, 6 months
Re: [389-users] 389-users Digest, Vol 125, Issue 3
by Karel Lang AFD
hi,
In reply to my own question (presented as topic no. 1 in vol.125 -see
below- chainmail):
It is solved, problem is the script, that is recommended by fedora wiki
(setupssl2.sh) as a way for automatic SSL generation for 389-DS server,
is not suitable for setting up multimaster, nor master/slave scenarios.
It is Ok to use the script for SSL generation and enabling for single
389 sever, but not for replications, as servers do not trust each other
(even after importing the CA certificate to each other one), because
there is number of errors to deal with - like - same serialno. of
certifictes, parameters of generated CA cert etc.
I had to delete those script generated SSL certs on both servers,
manually create my own company CA key and then sign with this key my own
company CA certificate.
Then create CSR file from each 389-DS server, sign this CSR files with
the CA company cert and import the created *CRT keys to each server (for
directory server and administration dir server separately ofc).
After that, all worked without problems.
So as conclusion, script is OK for testing purposes and quick server
setups, but not really for live or more complicated scenarios.
But anyway kudos to anyone who wrote it, because i 'gutted' it in order
to better understand the whole proces.
cheers,
--
*Karel Lang*
*Unix/Linux Administration*
lang(a)afd.cz | +420 731 13 40 40
AUFEER DESIGN, s.r.o. | www.aufeerdesign.cz
On 10/02/2015 07:07 PM, 389-users-request(a)lists.fedoraproject.org wrote:
> Send 389-users mailing list submissions to
> 389-users(a)lists.fedoraproject.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://admin.fedoraproject.org/mailman/listinfo/389-users
> or, via email, send a message with subject or body 'help' to
> 389-users-request(a)lists.fedoraproject.org
>
> You can reach the person managing the list at
> 389-users-owner(a)lists.fedoraproject.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of 389-users digest..."
>
>
> Today's Topics:
>
> 1. help needed with multimaster replication setup (tls/ssl encr.
> with ldaps) (Karel Lang AFD)
> 2. Re: Random dirsrv freezes and high CLOSE_WAITs (Prashant Bapat)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 2 Oct 2015 18:35:36 +0200
> From: Karel Lang AFD <lang(a)afd.cz>
> To: 389-users(a)lists.fedoraproject.org
> Subject: [389-users] help needed with multimaster replication setup
> (tls/ssl encr. with ldaps)
> Message-ID: <560EB258.7070108(a)afd.cz>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
>
> Hello guys,
> i'd appreciate if you could spare some advice (for ldap newb) :-).
>
>
> What i'd like to achieve (and failed so far):
>
> Multimaster scenario, where, two 389-DS servers are suppliers/consumers
> at the same time.
>
>
> my scenario in my testing environment:
>
> 2x testing RHEL 6.6 server with 2x 389-DS server and 2x Samba server
>
> Both 389-DS standalone servers work fine (over LDAPS) and i can create
> users there directly over 389-console or through smbldap-tools, i can
> join computers authenticate users to windows domain through samba...
>
> So each 389-DS server can act as authentification backend to Samba
> server and SSSD damon (for unix authentications) over LDAPS (636 port).
>
>
>
> My Multimaster replication setup STEPS:
>
> 1. create user for replication authentication - in my case eg.:
> uid=repmandir1,cn=config (and uid=repmandir2,cn=config on other server)
>
> 2. via 389-console: configuration -> replication -> "enable changelog"
> with default database directory
>
> 3. via 389-console: configuration -> replication -> userRoot -> "enable
> replica" (i supply here all needed info, replica ID, Supplier DN)
>
> 4. (HERE I GOT STUCK):
>
> via 389-console: configuration -> replication -> userRoot -> New Repl.
> agreement
>
> i fill in:
> -supplier server port 636
> -consumer server port 636
>
> connection:
> use: TLS/SSL (tls/ssl encr. with ldaps)
>
> authentication mechanism:
> -simple (filled in with replication authentication user DN and credentials)
>
>
> Clicking the "Next" button ends:
> Consumer server unreachable or invalid credentials supplied...
>
>
> Now ...:
> 1.
> i'm sure servers are both interchangeably reachable on both ports 389
> and 636 (i can telnet there on those ports from each other, i can also
> verify samba users via ldaps etc)
>
> 2. also i can contine and go farther and setup replication - but only
> with 389 port with option "Use LDAP - no encryption), so it works - but
> not over the 636 ...
>
> 3.
> i'm almost sure that this has some connection with certificates - and
> this is my downfall, because certification procedures is not my 'strong
> suite'.
>
> I generated the SSL certificates for both 389-DS servers via this script
> (recommended by fedora wiki):
>
>
> https://github.com/richm/scripts/blob/master/setupssl2.sh
>
>
> So my question -is - how to make (in my case) the replication work (with
> ssl/tls)? I think i should somehow let each other server know of it's
> respective 'counterpart' certificates - but how?
>
> Sorry if my q. is trivial, but i searched web on and off for past 10
> days and cant come with clear directive.
>
>
> Thanks for any advice,
> best regards,
>
> Karel
>
>
8 years, 6 months
389 Server force user password expiry
by Bedorf, Paul
I am running a 389 Directory Server v1.2.9.9
We have enabled a password policy as follows:
However, I don't want to wait until tomorrow for my 'test' user to expire, as im doing some API testing and need the 'test'
user to expire at any time. How would I force a user password expiry on an individual account?
[cid:image001.png@01D0FF73.7BFEC340]
__________________________________________________
Paul Bedorf | Linux Administrator | Mosaic
O: 905.238.8058 x 6414 | M: 416.799.4028
mosaic.com
8 years, 6 months
Re: [389-users] memberOf pluging and multimaster replication
by ghiureai
Hi List ,Rich
Here is the URL for the doc mentioned in this email, please can you
confirm if this is the case for multimaster replication and memberOf
plugin , is this the last update doc version ?
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9....
Thank you
Isabella
On 10/01/2015 11:20 AM, Rich Megginson wrote:
> On 10/01/2015 12:06 PM, ghiureai wrote:
>> Hi Rich
> Unless the issue involves some sort of security problem that involves a
> potential CVE, or contains sensitive data internal to your organization
> that you cannot make public, I would prefer that you use the
> 389-users(a)lists.fedoraproject.org for questions such as this. Not only
> will this benefit the entire community, but there are others who can
> answer these sorts of questions.
>
>
>> Are you aware of any issues with MemberOf plugin and multimaster
>> replication, some of old documentation one of the developer mentioned
>> to me shows you can use full replication agreement ,
> Please provide the URL of the documentation.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9....
>
>> please see bellow and if you can advise if this is still the case :
>>
>> "......The memberOf attributes for user entries should not be
>> replicated in multi-master environments. Make sure that the memberOf
>> attribute is excluded from replication in the replication agreement.
>> (Fractional replication is described in Section 11.1.7, “Replicating a
>> Subset of Attributes with Fractional Replication”.)
>> Each server must maintain its own MemberOf Plug-in independently. To
>> make sure that the memberOf attributes for entries are the same across
>> servers, simply configure the MemberOf Plug-in the same on all servers.
>> With single-master replication, it is perfectly safe to replicate
>> memberOf attributes. Configure the MemberOf Plug-in for the supplier,
>> then replicate the memberOf attributes to the consumers. ....."
> Yes, in general it is better to replicate the group operations only, and
> let each directory server update the internal memberof data. This
> reduces the amount of replication traffic, and reduces the complexity
> and processing in the memberof plugin to know if it needs to include or
> exclude an operation.
>
>> Thank you
>> Isabella
>>
8 years, 6 months
help needed with multimaster replication setup (tls/ssl encr. with ldaps)
by Karel Lang AFD
Hello guys,
i'd appreciate if you could spare some advice (for ldap newb) :-).
What i'd like to achieve (and failed so far):
Multimaster scenario, where, two 389-DS servers are suppliers/consumers
at the same time.
my scenario in my testing environment:
2x testing RHEL 6.6 server with 2x 389-DS server and 2x Samba server
Both 389-DS standalone servers work fine (over LDAPS) and i can create
users there directly over 389-console or through smbldap-tools, i can
join computers authenticate users to windows domain through samba...
So each 389-DS server can act as authentification backend to Samba
server and SSSD damon (for unix authentications) over LDAPS (636 port).
My Multimaster replication setup STEPS:
1. create user for replication authentication - in my case eg.:
uid=repmandir1,cn=config (and uid=repmandir2,cn=config on other server)
2. via 389-console: configuration -> replication -> "enable changelog"
with default database directory
3. via 389-console: configuration -> replication -> userRoot -> "enable
replica" (i supply here all needed info, replica ID, Supplier DN)
4. (HERE I GOT STUCK):
via 389-console: configuration -> replication -> userRoot -> New Repl.
agreement
i fill in:
-supplier server port 636
-consumer server port 636
connection:
use: TLS/SSL (tls/ssl encr. with ldaps)
authentication mechanism:
-simple (filled in with replication authentication user DN and credentials)
Clicking the "Next" button ends:
Consumer server unreachable or invalid credentials supplied...
Now ...:
1.
i'm sure servers are both interchangeably reachable on both ports 389
and 636 (i can telnet there on those ports from each other, i can also
verify samba users via ldaps etc)
2. also i can contine and go farther and setup replication - but only
with 389 port with option "Use LDAP - no encryption), so it works - but
not over the 636 ...
3.
i'm almost sure that this has some connection with certificates - and
this is my downfall, because certification procedures is not my 'strong
suite'.
I generated the SSL certificates for both 389-DS servers via this script
(recommended by fedora wiki):
https://github.com/richm/scripts/blob/master/setupssl2.sh
So my question -is - how to make (in my case) the replication work (with
ssl/tls)? I think i should somehow let each other server know of it's
respective 'counterpart' certificates - but how?
Sorry if my q. is trivial, but i searched web on and off for past 10
days and cant come with clear directive.
Thanks for any advice,
best regards,
Karel
--
*Karel Lang*
*Unix/Linux Administration*
lang(a)afd.cz | +420 731 13 40 40
AUFEER DESIGN, s.r.o. | www.aufeerdesign.cz
8 years, 6 months
Performance with macro acis
by Adrian Damian
Hi There,
The scenario is simple: we have a subtree in the DIT with a few thousand
children node. The parent node of the subtree has a few acis including a
couple of macro acis that apply to each of the child nodes. We've
observed a significant performance degradation when trying to list all
the children in the presence of the macro acis.
Profiling on the client code show that although the first few child
nodes were fetched quite fast there is a clear delay buildup as the
retrieval progresses. The buildup is not present when the macro acis are
removed. Also, it is faster to split the list in chunks and retrieve
them sequentially.
Is it possible that as the macro acis are resolved they are added to the
list of acis of the parent node so that the last nodes are evaluated
against many more acis than the first ones and hence the observed delay
in their retrieval? Is there a workaround for this?
Thank you,
Adrian
8 years, 6 months
