Then ask any questions that you ay have afterwards.
On Jul 20, 2013, at 3:50 AM, تدريبك - دورات -شبكات - حاسبات <hus.shabeeb(a)gmail.com>
wrote:
we need your help in creating the ACLs not the structure we know how
to create the structure.
Can you send me photos for this process , or step by step commands .
From: 389-users-bounces(a)lists.fedoraproject.org
[mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Dan Lavu
Sent: Friday, July 19, 2013 10:54 PM
To: General discussion list for the 389 Directory server project.
Subject: Re: [389-users] Manual & help step by step
Just create the structure and follow the instructions in the following url,
http://directory.fedoraproject.org/wiki/Howto:AccessControl
and please read the admin guide for instructions on how to use the idm console to setup
your tree.
https://access.redhat.com/site/documentation/Red_Hat_Directory_Server/
On Jul 19, 2013, at 1:34 PM, تدريبك - دورات -شبكات - حاسبات <hus.shabeeb(a)gmail.com>
wrote:
Dear Dan ,
Many thanks for your help ..
we want use number one option as it is the most flexible and least headache.
Let fox on it ,
Can you give more information on that .
Best regards ,
Husam
From: 389-users-bounces(a)lists.fedoraproject.org
[mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Dan Lavu
Sent: Friday, July 19, 2013 11:18 AM
To: General discussion list for the 389 Directory server project.
Subject: Re: [389-users] Manual & help step by step
I can think of two ways to do this but I will propose the way that I think is best…. so
It will not be one ACI it will be several.
Please keep in mind that ACI do get inherited and do not travel up the directory
structure, they only effect their child objects. So one ACI at the top level of your root
suffix o=X that permits users to change their own attributes. For each OU you create, you
will need to create an ACI for the group of users who can administer the
"domain".
So
O=X (ACI that permits any user to write to their own attributes)
|--------dc=domain (ACI that permits administrators to manage their users)
|---------------ou=people
|---------------ou-group
|-------dc=domain1 (ACI that permits the administrators to manage their users)
etc etc
So the nice thing about this is you have one database, one replication agreement but
without writing proper ACIs there is a change that domain1 can have visibility into
domain.
You can do
O=domain (All ACIs can go here)
|------------ou=people
O=domain1
|------------ou=poeple
The only thing I don't like about this method is, for each domain you add you will
have to create a replication agreement but you can have separate memory allocations,
pagesize per domain so it depends on your implementation and how its going to be used.
I hope this helps.
Dan
This will be the easiest way to manage it and administer it, if you require that each
domain be an entirely separate directory with no visibility into other domains, you will
want to read up on multiple databases, but this will make it an administrative hassle. For
each database
On Jul 18, 2013, at 6:22 PM, تدريبك - دورات -شبكات - حاسبات <hus.shabeeb(a)gmail.com>
wrote:
Dear Dan ,
Please read this :
we need to run multi domain ldap where each domain will have an admin group who can do
everything and the user can change only passwords. We need to know how to write the ACL
for such scenario. Each domain will be represented by O=domain and then we will have
ou=people and we will have admin group under the groups. Each domain will have this
structure.
Best regards ,
Husam
From: 389-users-bounces(a)lists.fedoraproject.org
[mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Dan Lavu
Sent: Thursday, July 18, 2013 3:31 AM
To: 'General discussion list for the 389 Directory server project.'
Subject: Re: [389-users] Manual & help step by step
They are plenty of step by step instructions to do what you are trying to do. You can
refer to the Red Hat documentation or the 389 documentation.
http://directory.fedoraproject.org/wiki/Howto:SSL
Also it is normal for the CA certificate to show up in the server tab if you generated
the CA certificate on the LDAP server, any certificate with the private key in the
database will appear as a server certificate. For example when you export the CA and move
it to a second server it will not show up in the server tab then.
In addition, when generating a CSR using the GUI (idm console) you must stick with it,
because the CSR will create the key in the db. If you are pursuing the command line using
certutil, you must convert the x509 certificates (three files usually, private, public and
ca into pkcs12 format.
Here is a link to understand and configure ACIs.
http://directory.fedoraproject.org/wiki/Howto:AccessControl
I hope this helps.
Dan
From: 389-users-bounces(a)lists.fedoraproject.org
[mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of ?????? - ????? -????? -
??????
Sent: Wednesday, July 17, 2013 7:38 PM
To: 389-users(a)lists.fedoraproject.org
Subject: [389-users] Manual & help step by step
Dear friends,
Anyone can help me ?
I have install the directory , on centos
I want to make certs and install it on the server
I have tried many ways but all not working , one way with p12 , when uploading the
certificates it's both appear in the server tab even the CA .
The other way with openssl in this case I can't upload the certificate on server tab
its only appear on the CA tab .
Also I want some help setting Acyls
Like I want to have many admins each one can control his group no access for the other
groups
Many thanks in advance .
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users