I setup a RHDS server for authentication along with my a test client, and everything seems to working well. Before I deploy this solution into production I would like to know what I can do in regards to security. I got rid of my ldap.secret file, as I don''t think I need it. I do not mind if root cannot change other peoples passwords from anywhere. The next problem that I''m running into is that I currently have my binddn set to cn=Directory Manager, and thus my most important password is still writtent in clear text in ldap.conf. Can some one explain (or point to an article which shows) how to create another user to use for my binddn? Is it as simple as making a regular user, or do I need to adjust any particular permissions. I would prefer this user to be read-only. Any particular tools to scan and see what can be accessed anonomously and what can be access with a particular binddn? Any other recomendations?
On Tue, 2009-06-16 at 10:49 -0700, Dumbo Q wrote:> I setup a RHDS server for authentication along with my a test client, > and everything seems to working well. Before I deploy this solution > into production I would like to know what I can do in regards to > security. > > I got rid of my ldap.secret file, as I don''t think I need it. I do not > mind if root cannot change other peoples passwords from anywhere. > > The next problem that I''m running into is that I currently have my > binddn set to cn=Directory Manager, and thus my most important > password is still writtent in clear text in ldap.conf. Can some one > explain (or point to an article which shows) how to create another > user to use for my binddn? Is it as simple as making a regular user, > or do I need to adjust any particular permissions. I would prefer > this user to be read-only. > > > Any particular tools to scan and see what can be accessed anonomously > and what can be access with a particular binddn? > > Any other recomendations?<snip>>Yes, there are some alternatives. I recently posted a ridiculously long outline about how we set up our environment in response to someone''s request for steps to set up on CentOS. This included our security set up. In briefest summary, we create a separate user who has rights to see but not change the commonly needed fields for as much of the DIT as is needed for the various servers, e.g., some may need to see the entire tree whereas other may only need a small subset. The ACI''s are in that large post. We then use this user as the binddn in ldap.conf. We never use cn=Directory Manager and always remove anonymous browsing. In fact, we also change the cn for both Directory Manager and the admin user just to further obscure the setup. Hope this helps - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan@opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society
http://www.mail-archive.com/fedora-directory-users@redhat.com/msg09428.html On Tue, Jun 16, 2009 at 7:29 PM, John A. Sullivan III < jsullivan@opensourcedevel.com> wrote:> In briefest summary, we create a separate user who has rights to see but > not change the commonly needed fields for as much of the DIT as is > needed for the various servers, e.g., some may need to see the entire > tree whereas other may only need a small subset. The ACI''s are in that > large post. We then use this user as the binddn in ldap.conf. We never > use cn=Directory Manager and always remove anonymous browsing. In fact, > we also change the cn for both Directory Manager and the admin user just > to further obscure the setup. Hope this helps - JohnJohn, (and anyone else of course...) I read your mail that you referred to... http://www.mail-archive.com/fedora-directory-users@redhat.com/msg09428.html and don''t really see an answer to the question, or more honestly, the very similar question I was about to ask before I saw this. That was how to have a full administrative user that is not Directory Manager. I''m working in a very high profile confidential project and to our shame are still using this account for pretty much everything of note (despite my protestations from day 1, I assure you!!) including the IDM console which is our main tool for managing data in it. I''ve tried to work out the most formal and effective way to make my own normal user account able to do whatever Directory Manager can do with the console but without luck. I expect it''s an awful lot simpler than I think it is. In line with doing it "right" there''s a Directory Administrators (or nearly that) group which I tried adding users to but no change was seen, and I''d think there''s a difference between the access within the main directory and the Admin server config in o=NetscapeRoot. Is there an ACI that already exists and such? Also looking at your notes, it seems there may be better ways to manage a single directory (2 multimasters and 6 replicas) like bypassing the initial Admin section and going straight to the directory itself? Also if I do make my user account able to log in, would I then be faced with putting in the entire DN every single time? can I alias it etc..? Ideally I''d not want a dedicated account, unless there''s some real logic in not using the account - something I can imagine... Any pointers, especially those which are simple, elegant and non-invasive, would be *very* much appreciated. Thanks Chris
----- "Chris Phillips" <chris@untrepid.com> wrote:> http://www.mail-archive.com/fedora-directory-users@redhat.com/msg09428.html > > > On Tue, Jun 16, 2009 at 7:29 PM, John A. Sullivan III < > jsullivan@opensourcedevel.com > wrote: > > > In briefest summary, we create a separate user who has rights to see > but > not change the commonly needed fields for as much of the DIT as is > needed for the various servers, e.g., some may need to see the entire > tree whereas other may only need a small subset. The ACI''s are in that > large post. We then use this user as the binddn in ldap.conf. We never > use cn=Directory Manager and always remove anonymous browsing. In > fact, > we also change the cn for both Directory Manager and the admin user > just > to further obscure the setup. Hope this helps - John > > John, (and anyone else of course...) > > I read your mail that you referred to... > http://www.mail-archive.com/fedora-directory-users@redhat.com/msg09428.html > and don''t really see an answer to the question, or more honestly, the > very similar question I was about to ask before I saw this. > > That was how to have a full administrative user that is not Directory > Manager. I''m working in a very high profile confidential project and > to our shame are still using this account for pretty much everything > of note (despite my protestations from day 1, I assure you!!) > including the IDM console which is our main tool for managing data in > it. I''ve tried to work out the most formal and effective way to make > my own normal user account able to do whatever Directory Manager can > do with the console but without luck. I expect it''s an awful lot > simpler than I think it is. In line with doing it "right" there''s a > Directory Administrators (or nearly that) group which I tried adding > users to but no change was seen, and I''d think there''s a difference > between the access within the main directory and the Admin server > config in o=NetscapeRoot. Is there an ACI that already exists and > such?I would take a look at the ACIs that are created for the uid=admin user, the one created during setup-ds-admin.pl time. That user is a close as you can get to directory manager. The only thing we don''t have an ACI for is the ability to create the root entry for a top level suffix (e.g. if you create a new suffix dc=example,dc=com, only the directory manager can use LDAP ADD to create that entry, which is what the console does). You can work around this limitation by doing an import operation - create an ldif file which contains this entry, and do an import/ldif2db/database init with this file, as admin.> > Also looking at your notes, it seems there may be better ways to > manage a single directory (2 multimasters and 6 replicas) like > bypassing the initial Admin section and going straight to the > directory itself? > > Also if I do make my user account able to log in, would I then be > faced with putting in the entire DN every single time? can I alias it > etc..? Ideally I''d not want a dedicated account, unless there''s some > real logic in not using the account - something I can imagine...Authentication is supposed to lookup the user id first in o=NetscapeRoot (e.g. the default console admin) then in your default user&group suffix (e.g. dc=example,dc=com).> > Any pointers, especially those which are simple, elegant and > non-invasive, would be *very* much appreciated. > > Thanks > > Chris > > -- > 389 users mailing list > 389-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users
On Tue, 2009-06-16 at 20:13 +0100, Chris Phillips wrote:> http://www.mail-archive.com/fedora-directory-users@redhat.com/msg09428.html > > On Tue, Jun 16, 2009 at 7:29 PM, John A. Sullivan III > <jsullivan@opensourcedevel.com> wrote: > In briefest summary, we create a separate user who has rights > to see but > not change the commonly needed fields for as much of the DIT > as is > needed for the various servers, e.g., some may need to see the > entire > tree whereas other may only need a small subset. The ACI''s > are in that > large post. We then use this user as the binddn in > ldap.conf. We never > use cn=Directory Manager and always remove anonymous > browsing. In fact, > we also change the cn for both Directory Manager and the admin > user just > to further obscure the setup. Hope this helps - John > > John, (and anyone else of course...) > > I read your mail that you referred to... > http://www.mail-archive.com/fedora-directory-users@redhat.com/msg09428.html > and don''t really see an answer to the question, or more honestly, the > very similar question I was about to ask before I saw this. > > That was how to have a full administrative user that is not Directory > Manager. I''m working in a very high profile confidential project and > to our shame are still using this account for pretty much everything > of note (despite my protestations from day 1, I assure you!!) > including the IDM console which is our main tool for managing data in > it. I''ve tried to work out the most formal and effective way to make > my own normal user account able to do whatever Directory Manager can > do with the console but without luck. I expect it''s an awful lot > simpler than I think it is. In line with doing it "right" there''s a > Directory Administrators (or nearly that) group which I tried adding > users to but no change was seen, and I''d think there''s a difference > between the access within the main directory and the Admin server > config in o=NetscapeRoot. Is there an ACI that already exists and > such? > > Also looking at your notes, it seems there may be better ways to > manage a single directory (2 multimasters and 6 replicas) like > bypassing the initial Admin section and going straight to the > directory itself? > > Also if I do make my user account able to log in, would I then be > faced with putting in the entire DN every single time? can I alias it > etc..? Ideally I''d not want a dedicated account, unless there''s some > real logic in not using the account - something I can imagine... > > Any pointers, especially those which are simple, elegant and > non-invasive, would be *very* much appreciated.<snip> Hi, Chris. I suppose the first thing I should point out is that I am by no means any kind of expert whatsoever in any way shape or form (not sure if I can say that more emphatically:-) ). Someone like Rich Megginson will know much more than I. I''ve only learned enough to do what I have to do on my project which is still awaiting funding to hire an LDAP engineer. Before this, I hadn''t touched Directory Services since NetWare 4.x! There are a couple of options. I''ve not explored the difference between Directory Manager and uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot (or whatever the uid is, we''ve changed ours from the default proposed during installation). Even so, we do not use this user either for most of our functions (although our administrators are still logging in using Directory Manager in idm-console for administration). The magic, as you intimate, is the ACI. We created our own since we are a multi-tenant environment. Our admins do use Directory Manager (renamed) to oversee the entire tree but each of our clients have their own designated administrator for their part of the tree. We also break our tree into Internal and External sections (because of uniqueness requirements, e.g., all uids and cn must be unique across the clients in our environment but not for their address books of their external clients). I believe the ACIs we use to do this are: (targetattr = "*") (target = "ldap:///($dn),o=internal,dc=mycompany, dc=com") (version 3.0;acl "Client Administrators Internal";allow (all)(groupdn "ldap:///cn=*ldapadmins,ou=groups,[$dn],o=internal,dc=mycompany,dc=com");) (targetattr = "*") (target = "ldap:///($dn),o=external,dc=mycompany, dc=com") (version 3.0;acl "Client Administrators External";allow (all)(groupdn "ldap:///cn=*ldapadmins,ou=groups,[$dn],o=internal,dc=mycompany,dc=com");) We are having a problem in the last line. It does not look like DS likes wildcards in groupdn definitions (although I think they are OK in userdn) which we need because of our uniqueness constraints. We haven''t had time to fix this but have been testing with something like this where we use the same named group in different contexts in a section of the tree which is not uniqueness constrained: (targetattr = "*") (target = "ldap:///($dn),o=external,dc=mycompany, dc=com") (version 3.0;acl "Test Client Administrators External";allow (all)(groupdn "ldap:///cn=ldapadmins,[$dn],o=SysAccounts,dc=mycompany,dc=com");) I would think it would be trivial to adapt this to have a user oversee then entire tree. The trick for us was the variables to have one ACI (or two) for hopefully hundreds of clients. I may be missing your point as I''m honestly flying through this email on my way to building our PBX (until we hire our PBX engineer - ah the grief of delayed funding!) but hope this helps - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan@opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society