Hi all I''ve managed to get a few features that I''d been struggling with working on FDS, however I''d appreciate any guidance with the following: Our service desk is outsourced and I''m looking to replace an existing NIS implementation with LDAP (probably Redhat, but until we prove it to be reliable I''m sticking with FDS for now). I''m trying to avoid using the Administrator accounts set up in O=NetscapeRoot and create user accounts within the main dc=example,dc=com schema and give them access to the relevant subtrees to be able to create user accounts, reset passwords etc - effectively delegating restricted admin access whilst still ensuring the security model. I thought i had achieved this by setting an Access Role on the target OU and specifying that a group I had already created would have full access to all attributes (I can refine this later to restrict down to the bare minimum). Below is the syntax obtained from the GUI console when setting up the restriction (targetattr = "*") (target = "ldap:///ou=Laser,dc=example,dc=com") (version 3.0; acl "Sdesk"; allow (all) (groupdn = "ldap:///cn=gpServiceDesk,ou=Groups, dc=example,dc=com") ;) however, when I attempt to add a user via the newuser.pl script I obtained from netauth, I get the following: failed to add entry: Insufficient ''write'' privilege to the ''userPassword'' attribute at ./newuser.pl line 232, <DATA> line 228. Has anyone implemented a security model like this and if so, would they be able to share any experiences. Thanks Darren -- Darren Paxton, European Midrange Systems Senior Engineer Centralised Operations | MMC Global Technology Infrastructure (MGTI) Mercer Human Resource Consulting | Mercury Court, Tithebarn Street, Liverpool, L2 2QH, Merseyside, UK +44 (0) 151 242 7216 | Mobile +44 (0) 7789 0 30027 | darren.paxton@mercer.com <file://''mailto:darren.paxton@mercer.com''> www.mmc.com <file://''http://www.mmc.com''> This e-mail and any attachments may be confidential or legally privileged.If you received this message in error or are not the intended recipient, you should destroy the email message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your co-operation. Mercer Human Resource Consulting Limited is authorised and regulated by the Financial Services Authority. Registered in England No. 984275. Registered Office: 1 Tower Place West, Tower Place, London, EC3R 5BU.
Richard Megginson
2007-Mar-05 17:30 UTC
Re: [Fedora-directory-users] User Account Management
Paxton, Darren wrote:> Hi all > > I''ve managed to get a few features that I''d been struggling with > working on FDS, however I''d appreciate any guidance with the following: > > Our service desk is outsourced and I''m looking to replace an existing > NIS implementation with LDAP (probably Redhat, but until we prove it > to be reliable I''m sticking with FDS for now). > > I''m trying to avoid using the Administrator accounts set up in > O=NetscapeRoot and create user accounts within the main > dc=example,dc=com schema and give them access to the relevant subtrees > to be able to create user accounts, reset passwords etc - effectively > delegating restricted admin access whilst still ensuring the security > model. > > I thought i had achieved this by setting an Access Role on the target > OU and specifying that a group I had already created would have full > access to all attributes (I can refine this later to restrict down to > the bare minimum). > > Below is the syntax obtained from the GUI console when setting up the > restriction > > (targetattr = "*") > (target = "ldap:///ou=Laser,dc=example,dc=com") > (version 3.0; > acl "Sdesk"; > allow (all) > (groupdn = "ldap:///cn=gpServiceDesk,ou=Groups, dc=example,dc=com") > ;) > > however, when I attempt to add a user via the newuser.pl script I > obtained from netauth, I get the following: > > failed to add entry: Insufficient ''write'' privilege to the > ''userPassword'' attribute at ./newuser.pl line 232, <DATA> line 228.If add an entry without the userPassword attribute, does it succeed? Do you have an ACI on dc=example,dc=com or ou=Laser that denies access to the userPassword attribute (e.g. (targetattr!=userPassword))?> > Has anyone implemented a security model like this and if so, would > they be able to share any experiences. > > Thanks > > Darren > > > > -- > *Darren Paxton*, European Midrange Systems Senior Engineer > Centralised Operations | MMC Global Technology Infrastructure (MGTI) > Mercer Human Resource Consulting | Mercury Court, Tithebarn Street, > Liverpool, L2 2QH, Merseyside, UK > +44 (0) 151 242 7216 | Mobile +44 (0) 7789 0 30027 | > _darren.paxton@mercer.com <file://%27mailto:darren.paxton@mercer.com%27>_ > _www.mmc.com <file://%27http://www.mmc.com%27>_ > > > > This e-mail and any attachments may be confidential or legally > privileged.If you received this message in error or are not the > intended recipient, you should destroy the email message and any > attachments or copies, and you are prohibited from retaining, > distributing, disclosing or using any information contained herein. > Please inform us of the erroneous delivery by return e-mail. Thank you > for your co-operation. > > Mercer Human Resource Consulting Limited is authorised and regulated > by the Financial Services Authority. Registered in England No. 984275. > Registered Office: 1 Tower Place West, Tower Place, London, EC3R 5BU. > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
Paxton, Darren wrote:> > failed to add entry: Insufficient ''write'' privilege to the > ''userPassword'' attribute at ./newuser.pl line 232, <DATA> line 228.Do you have a deny acl for userPassword - if so it will take precedence. -- Pete
Justin Crawford
2007-Mar-05 18:18 UTC
[Fedora-directory-users] slapd crash on replicate attempt
Hi- This morning a multi-master pair that has been running since Nov. 5 crashed. There is only one clue, in the error log of one of the directories: NSMMReplicationPlugin - agmt="cn=auth_ldap2 to auth_ldap1" (ldap:389): Unable to receive the response for a startReplication extended operation to consumer (Can''t contact LDAP server). Will retry later. That appears to be the last thing either process said before they both gave up, almost simultaneously. Can anyone help me understand what happened? It looks like the replication agreements survived; at least, in the replication configuration section of each directory''s console, there is a message with a current time saying "Incremental update succeeded." Thanks! Justin
Eddie C
2007-Mar-05 18:59 UTC
Re: [Fedora-directory-users] slapd crash on replicate attempt
Make sure that when you created an account for replication that the acount did not expire and lock out. On 3/5/07, Justin Crawford <Justin.Crawford@cusys.edu> wrote:> > Hi- > > This morning a multi-master pair that has been running since Nov. 5 > crashed. There is only one clue, in the error log of one of the > directories: > > NSMMReplicationPlugin - agmt="cn=auth_ldap2 to auth_ldap1" (ldap:389): > Unable to receive the response for a startReplication extended operation > to consumer (Can''t contact LDAP server). Will retry later. > > That appears to be the last thing either process said before they both > gave up, almost simultaneously. > > Can anyone help me understand what happened? > > It looks like the replication agreements survived; at least, in the > replication configuration section of each directory''s console, there is > a message with a current time saying "Incremental update succeeded." > > Thanks! > > Justin > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
Justin Crawford
2007-Mar-05 22:39 UTC
RE: [Fedora-directory-users] slapd crash on replicate attempt
I think the replication error may be a response to the crash, and not necessarily a clue to the the cause. One of the slapd processes just crashed again, and the logs on the second server show only the same replication error. I take it to mean the replication can''t continue, because the slapd process on the other server has crashed. Anyway, today is the first time in 5 months that either of these servers has had any issue whatsoever. Are there other documented instances of the fedora server crashing hard without generating errors? We''re running 1.0.2. $ uname -r -v -p -i -o 2.6.9-34.0.2.ELsmp #1 SMP Fri Jun 30 10:32:04 EDT 2006 x86_64 x86_64 GNU/Linux Thanks! Justin ________________________________ From: fedora-directory-users-bounces@redhat.com [mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Eddie C Sent: Monday, March 05, 2007 12:00 PM To: General discussion list for the Fedora Directory server project. Subject: Re: [Fedora-directory-users] slapd crash on replicate attempt Make sure that when you created an account for replication that the acount did not expire and lock out. On 3/5/07, Justin Crawford < Justin.Crawford@cusys.edu <mailto:Justin.Crawford@cusys.edu> > wrote: Hi- This morning a multi-master pair that has been running since Nov. 5 crashed. There is only one clue, in the error log of one of the directories: NSMMReplicationPlugin - agmt="cn=auth_ldap2 to auth_ldap1" (ldap:389): Unable to receive the response for a startReplication extended operation to consumer (Can''t contact LDAP server). Will retry later. That appears to be the last thing either process said before they both gave up, almost simultaneously. Can anyone help me understand what happened? It looks like the replication agreements survived; at least, in the replication configuration section of each directory''s console, there is a message with a current time saying "Incremental update succeeded." Thanks! Justin -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Richard Megginson
2007-Mar-07 03:55 UTC
Re: [Fedora-directory-users] slapd crash on replicate attempt
Justin Crawford wrote:> I think the replication error may be a response to the crash, and not > necessarily a clue to the the cause. > > One of the slapd processes just crashed again, and the logs on the > second server show only the same replication error. I take it to mean > the replication can''t continue, because the slapd process on the other > server has crashed. > > Anyway, today is the first time in 5 months that either of these > servers has had any issue whatsoever.Something must have changed. Even something that may appear at first glance to be innocuous. Are you using VLV (browsing index in the console)?> Are there other documented instances of the fedora server crashing > hard without generating errors? > We''re running 1.0.2. > > $ uname -r -v -p -i -o > 2.6.9-34.0.2.ELsmp #1 SMP Fri Jun 30 10:32:04 EDT 2006 x86_64 x86_64 > GNU/Linux > > Thanks! > Justin > > ------------------------------------------------------------------------ > *From:* fedora-directory-users-bounces@redhat.com > [mailto:fedora-directory-users-bounces@redhat.com] *On Behalf Of > *Eddie C > *Sent:* Monday, March 05, 2007 12:00 PM > *To:* General discussion list for the Fedora Directory server project. > *Subject:* Re: [Fedora-directory-users] slapd crash on replicate > attempt > > Make sure that when you created an account for replication that > the acount did not expire and lock out. > > On 3/5/07, *Justin Crawford* < Justin.Crawford@cusys.edu > <mailto:Justin.Crawford@cusys.edu>> wrote: > > Hi- > > This morning a multi-master pair that has been running since > Nov. 5 > crashed. There is only one clue, in the error log of one of the > directories: > > NSMMReplicationPlugin - agmt="cn=auth_ldap2 to auth_ldap1" > (ldap:389): > Unable to receive the response for a startReplication extended > operation > to consumer (Can''t contact LDAP server). Will retry later. > > That appears to be the last thing either process said before > they both > gave up, almost simultaneously. > > Can anyone help me understand what happened? > > It looks like the replication agreements survived; at least, > in the > replication configuration section of each directory''s console, > there is > a message with a current time saying "Incremental update > succeeded." > > Thanks! > > Justin > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
Justin Crawford
2007-Mar-07 04:06 UTC
RE: [Fedora-directory-users] slapd crash on replicate attempt
> > One of the slapd processes just crashed again, and the logs on the > > second server show only the same replication error. I take > it to mean > > the replication can''t continue, because the slapd process > on the other > > server has crashed. > > > > Anyway, today is the first time in 5 months that either of these > > servers has had any issue whatsoever. > Something must have changed. Even something that may appear at first > glance to be innocuous.Agreed. The servers themselves were not patched immediately prior to the change; they did get some patches in the week before, but nothing that appears to have a direct connection. We did implement a new authenticating client application during the previous week. But I keep thinking that no client should be able to cause a slapd server crash (at least not without some evidence of intense load); therefore, a change to client applications does not strike me as a likely culprit.> > Are you using VLV (browsing index in the console)?Yes, on a few subtrees, but these tend to be created on the spot by administrators, and not managed strictly (should they be?). I suppose one of those could''ve been created on a subtree at any time, but I don''t believe one was created in the days immediately prior to the crash. Why do you ask? FYI, we rebooted the host machines last night and restared slapd with debug 1. Neither slapd process crashed today. Justin
Richard Megginson
2007-Mar-07 21:03 UTC
Re: [Fedora-directory-users] slapd crash on replicate attempt
Justin Crawford wrote:>>> One of the slapd processes just crashed again, and the logs on the >>> second server show only the same replication error. I take >>> >> it to mean >> >>> the replication can''t continue, because the slapd process >>> >> on the other >> >>> server has crashed. >>> >>> Anyway, today is the first time in 5 months that either of these >>> servers has had any issue whatsoever. >>> >> Something must have changed. Even something that may appear at first >> glance to be innocuous. >> > > Agreed. The servers themselves were not patched immediately prior to > the change; they did get some patches in the week before, but nothing > that appears to have a direct connection. > > We did implement a new authenticating client application during the > previous week. But I keep thinking that no client should be able to > cause a slapd server crash (at least not without some evidence of > intense load); therefore, a change to client applications does not > strike me as a likely culprit. >> >> Are you using VLV (browsing index in the console)? >> > > Yes, on a few subtrees, but these tend to be created on the spot by > administrators, and not managed strictly (should they be?). I suppose > one of those could''ve been created on a subtree at any time, but I don''t > believe one was created in the days immediately prior to the crash. Why > do you ask? >We''ve seen problems with VLV before.> FYI, we rebooted the host machines last night and restared slapd with > debug 1. Neither slapd process crashed today. >Please let us know if you can reproduce the crash. Running with debug 1 should help immensly, if you can afford the slowdown - running in debug mode can really slow down production machines. http://directory.fedora.redhat.com/wiki/FAQ#Troubleshooting However, we do have a tool available that would allow you to run with full debugging in a production environment. It buffers the log output into a circular buffer of the last N lines, and you tell it how many N is (e.g. 10,000). However, the server may perform well enough even with debug 1, in which case you probably don''t need it.> Justin > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
Hi again Thanks for the suggestions re the ACI - I managed to resolve that part, but now have hit yet another wall with the "interesting" way in which our accounts are set up. As I stated, we have a service desk that manage all the user accounts, however, I''ve just been reliably informed that they are only going to be managing the password resets of any user accounts, and that a subgroup of the department I''m building the directory for, will actually be creating the user accounts. Here''s where it gets interesting - although the subgroup will be creating the accounts, they will not be permitted to reset any passwords hence I''m now in a confusing place. I''ve looked at the ACIs and the service desk part was easy enough to achieve, I thought the other part would be as simple as denying write permission to the userpassword attribute, but this doesnt work as I''m assuming setting the password at user creation is effectively a form of write to the attribute. The question therefore, is can you allow a person/group to be able to create user accounts, but not have the ability to modify the password attribute after its created. I''d like to trust the users not to be resetting passwords on their own, however we need to have an auditable trail of the user permissions that details this. Thanks in advance for any help (and for the help supplied so far!) Darren This e-mail and any attachments may be confidential or legally privileged.If you received this message in error or are not the intended recipient, you should destroy the email message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your co-operation. Mercer Human Resource Consulting Limited is authorised and regulated by the Financial Services Authority. Registered in England No. 984275. Registered Office: 1 Tower Place West, Tower Place, London, EC3R 5BU.