Fedora directory users - Aug 2005 - Account lockout replication

Hello,

I am trying to set up a global account lockout policy.  In the 
Deployment Guide, it says "Account lockout is enforced on the
replicas"
and "The password policy information ... such as password age, the 
account lockout counter ... are all replicated."  When I trigger the 
lockout on an account, I see the accountUnlockTime attribute get added 
to the account''s directory entry.

 From what I make of the text in the Deployment Guide, accountUnlockTime 
should be replicated to my other master and corresponding consumers, 
thus locking out the account everywhere.  This isn''t what I''m
seeing; I
am only locked out of the master on which it was originally triggered, I 
can still bind using the account on the other master and consumers.

I have applied the same password and lockout policy to all of my 
servers, so the configuration should be consistent.  Do I have the wrong 
expectations on how this should work?  Does "enforced on the replicas"
simply mean the replicas as an independant server will perform lockouts? 
  Anyone been able to solve this one?

--bryan

You need to enable global password policy.  You need to set the 
attribute "passwordIsGlobalPolicy" in cn=config to the value
"1".

Bryan Wann wrote:
> Hello,
>
> I am trying to set up a global account lockout policy.  In the 
> Deployment Guide, it says "Account lockout is enforced on the 
> replicas" and "The password policy information ... such as
password
> age, the account lockout counter ... are all replicated."  When I 
> trigger the lockout on an account, I see the accountUnlockTime 
> attribute get added to the account''s directory entry.
>
> From what I make of the text in the Deployment Guide, 
> accountUnlockTime should be replicated to my other master and 
> corresponding consumers, thus locking out the account everywhere.  
> This isn''t what I''m seeing; I am only locked out of the
master on
> which it was originally triggered, I can still bind using the account 
> on the other master and consumers.
>
> I have applied the same password and lockout policy to all of my 
> servers, so the configuration should be consistent.  Do I have the 
> wrong expectations on how this should work?  Does "enforced on the 
> replicas" simply mean the replicas as an independant server will 
> perform lockouts?  Anyone been able to solve this one?
>
> --bryan
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

Rich Megginson wrote:
> You need to enable global password policy.  You need to set the 
> attribute "passwordIsGlobalPolicy" in cn=config to the value
"1".
Awesome, that works beautifully for what I need.  Thanks for the reply.

Of course, now comes the problem if a user fails their auth on a replica 
it isn''t reflected in the master servers.  I assume this is due to the 
inherent one-way master-to-replica replication.  Having referrers 
doesn''t seem to help.  Is there a way around this, or is it a fact of
life?

--bryan

Bryan Wann wrote:
> Rich Megginson wrote:
>
>> You need to enable global password policy.  You need to set the 
>> attribute "passwordIsGlobalPolicy" in cn=config to the value
"1".
>
>
> Awesome, that works beautifully for what I need.  Thanks for the reply.
>
> Of course, now comes the problem if a user fails their auth on a 
> replica it isn''t reflected in the master servers.  I assume this
is
> due to the inherent one-way master-to-replica replication.  Having 
> referrers doesn''t seem to help.  Is there a way around this, or is
it
> a fact of life?
You can set up "chain on update".  This will allow bind and write 
operations to "pass through" the replica to a master.  Normally when
you
attempt a write operation to a read-only replica, your application will 
receive a referral to one of the masters.  With chain on update, the 
replica follows the referral for you.  Same with BINDs.  Then, all of 
the password policy history will be stored on the masters and propagated 
to all of your other masters and replicas.

However, this involves quite a bit more set up work.  Let me know if 
you''re interested.
>
> --bryan
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

I''m attempting to add a mail-routing draft schema 
(draft-lachman-laser-ldap-mail-routing-02.txt) to FDS.
The schema can be found here (among other places):
http://www.sendmail.org/m4/laser.txt

In an unusual and unfortunate coincidence, the mailRoutingAddress OID 
defined by the schema is the same as the OID for
''ntGroupType'', which is
defined in FDS'' 50ns-directory.ldif schema.

 From 50ns-directory.ldif:
( 2.16.840.1.113730.3.1.47
  NAME ''ntGroupType''
  DESC ''Netscape defined attribute type''
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  SINGLE-VALUE
  X-ORIGIN ''Netscape NT Synchronization''
)

 From draft-lachman-laser-ldap-mail-routing-02.txt:
( 2.16.840.1.113730.3.1.47

  NAME ''mailRoutingAddress''
  DESC ''RFC 822 address to use when routing messages to
        the SMTP MTA of this recipient''
  EQUALITY caseIgnoreIA5Match
  SYNTAX ''1.3.6.1.4.1.1466.115.121.1.26{256}''
  SINGLE-VALUE
)


The most obvious solution is to change the OID of one of these.  But 
which one should be changed, and to what?
There''s probably not really a single right answer, but if anyone else 
has happened to run into this, I''d be interested to hear how you 
resolved it.
Thanks a lot,
-- George

George Holbert wrote:
> I''m attempting to add a mail-routing draft schema 
> (draft-lachman-laser-ldap-mail-routing-02.txt) to FDS.
> The schema can be found here (among other places):
> http://www.sendmail.org/m4/laser.txt
> 
> In an unusual and unfortunate coincidence, the mailRoutingAddress OID 
> defined by the schema is the same as the OID for
''ntGroupType'', which is
> defined in FDS'' 50ns-directory.ldif schema.
> 
>  From 50ns-directory.ldif:
> ( 2.16.840.1.113730.3.1.47
>  NAME ''ntGroupType''
>  DESC ''Netscape defined attribute type''
>  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>  SINGLE-VALUE
>  X-ORIGIN ''Netscape NT Synchronization''
> )
The OID arc belongs to Netscape Directory server, and was submitted to 
alvestrand on Feb 11 1999:
	
	http://www.alvestrand.no/objectid/2.16.840.1.113730.3.html


>  From draft-lachman-laser-ldap-mail-routing-02.txt:
> ( 2.16.840.1.113730.3.1.47
> 
>  NAME ''mailRoutingAddress''
>  DESC ''RFC 822 address to use when routing messages to
>        the SMTP MTA of this recipient''
>  EQUALITY caseIgnoreIA5Match
>  SYNTAX ''1.3.6.1.4.1.1466.115.121.1.26{256}''
>  SINGLE-VALUE
> )
> 

  This expired draft was first written in May 1999 by H. Lachman at 
Netscape:

http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-lachman-laser-ldap-mail-routing-00.txt


  He was correct to use the Netscape ARC, and I don''t see a more 
appropriate section:

	http://www.alvestrand.no/objectid/2.16.840.1.113730.html



  I can''t say which came first, the draft, or the Netscape Messaging 
Server 4, which brought that schema, (as far as I can tell).

> The most obvious solution is to change the OID of one of these.  But 
> which one should be changed, and to what?
> There''s probably not really a single right answer, but if anyone
else
> has happened to run into this, I''d be interested to hear how you 
> resolved it.
I would say that the OID from the mail routing draft should be changed 
and you should file an "ITS" (bug report) at the OpenLDAP site. The 
conflicting OID is a company private OID, and is from an expired draft.


--
mike

George Holbert wrote:
> I''m attempting to add a mail-routing draft schema 
> (draft-lachman-laser-ldap-mail-routing-02.txt) to FDS.
> The schema can be found here (among other places):
> http://www.sendmail.org/m4/laser.txt
> 
> In an unusual and unfortunate coincidence, the mailRoutingAddress OID 
> defined by the schema is the same as the OID for
''ntGroupType'', which is
> defined in FDS'' 50ns-directory.ldif schema.
> 
Also:

A quick fix to this problem is not to change anything, just disable the 
50ns-mail.ldif if you are not using Netscape Mail Server:


# cd /opt/fedora-ds/slapd-`hostname`/config/schema
# mkdir disabled
# mv 50ns-mail.ldif disabled
# cp ~/mail-routing.ldif 80mail-routing.ldif
# cd ../..
# ./restart-slapd


--
mike

Mike Jackson wrote:
> George Holbert wrote:
> 
>> I''m attempting to add a mail-routing draft schema 
>> (draft-lachman-laser-ldap-mail-routing-02.txt) to FDS.
>> The schema can be found here (among other places):
>> http://www.sendmail.org/m4/laser.txt
>>
>> In an unusual and unfortunate coincidence, the mailRoutingAddress OID 
>> defined by the schema is the same as the OID for
''ntGroupType'', which
>> is defined in FDS'' 50ns-directory.ldif schema.
>>
> 
> Also:
> 
> A quick fix to this problem is not to change anything, just disable the 
> 50ns-mail.ldif if you are not using Netscape Mail Server:
> 
> 
> # cd /opt/fedora-ds/slapd-`hostname`/config/schema
> # mkdir disabled
> # mv 50ns-mail.ldif disabled
> # cp ~/mail-routing.ldif 80mail-routing.ldif
> # cd ../..
> # ./restart-slapd

Disregard that. I misread and thought the conflicting OID was in 
50ns-mail.ldif. You probably can''t disable the 50ns-directory.ldif...



--
mike

George Holbert wrote:
> I''m attempting to add a mail-routing draft schema 
> (draft-lachman-laser-ldap-mail-routing-02.txt) to FDS.
> The schema can be found here (among other places):
> http://www.sendmail.org/m4/laser.txt
>
> In an unusual and unfortunate coincidence, the mailRoutingAddress OID 
> defined by the schema is the same as the OID for
''ntGroupType'', which
> is defined in FDS'' 50ns-directory.ldif schema.
I believe that the ntGroupType
attribute definition has been in the server for a very long time (since 
DS3.x).
It''s certainly in DS6.21 and Sun DS 5.2.

Thinking more...perhaps this is a typo in 
draft-lachman-laser-ldap-mail-routing-02.txt ?
One would have thought that Hans would have tested the schema
in a real server. Possibly there is a valid OID assigned for
mailRoutingAddress and the doc is in error ?

Checking the schema in a server...I see 2.16.840.1.113730.3.1.24 for
mailRoutingAddress.

So possibly the document is wrong and the laser schema is already there
in your server (in 50ns-mail.ldif) ?

Hi Mike,
> Disregard that. I misread and thought the conflicting OID was in 
> 50ns-mail.ldif. You probably can''t disable the
50ns-directory.ldif...

Yes, there are actually some other conflicts in 50ns-mail.ldif as well, 
so I previously moved it aside to disable it.  50ns-directory.ldif is 
trickier since, as you say, it''s probably needed to run the directory 
server.

Thanks for the feedback!
-- George

Mike Jackson wrote:
> Mike Jackson wrote:
>
>> George Holbert wrote:
>>
>>> I''m attempting to add a mail-routing draft schema 
>>> (draft-lachman-laser-ldap-mail-routing-02.txt) to FDS.
>>> The schema can be found here (among other places):
>>> http://www.sendmail.org/m4/laser.txt
>>>
>>> In an unusual and unfortunate coincidence, the mailRoutingAddress 
>>> OID defined by the schema is the same as the OID for
''ntGroupType'',
>>> which is defined in FDS'' 50ns-directory.ldif schema.
>>>
>>
>> Also:
>>
>> A quick fix to this problem is not to change anything, just disable 
>> the 50ns-mail.ldif if you are not using Netscape Mail Server:
>>
>>
>> # cd /opt/fedora-ds/slapd-`hostname`/config/schema
>> # mkdir disabled
>> # mv 50ns-mail.ldif disabled
>> # cp ~/mail-routing.ldif 80mail-routing.ldif
>> # cd ../..
>> # ./restart-slapd
>
>
>
> Disregard that. I misread and thought the conflicting OID was in 
> 50ns-mail.ldif. You probably can''t disable the
50ns-directory.ldif...
>
>
>
> -- 
> mike
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Hi David,

Perhaps Hans abandoned the draft since Netscape came up with a 
replacement schema (as defined in 50ns-mail.ldif).
Some companies still use draft-lachman-laser-ldap-mail-routing-02.txt 
though.  In my case, I''m using it for support of a Mirapoint product.

I think what I might do is disable 50ns-mail.ldif, but change the 
mailRoutingAddress OID in draft-lachman-laser-ldap-mail-routing-02.txt 
to 2.16.840.1.113730.3.1.24.

Thanks for your input!
-- George

David Boreham wrote:
> George Holbert wrote:
>
>> I''m attempting to add a mail-routing draft schema 
>> (draft-lachman-laser-ldap-mail-routing-02.txt) to FDS.
>> The schema can be found here (among other places):
>> http://www.sendmail.org/m4/laser.txt
>>
>> In an unusual and unfortunate coincidence, the mailRoutingAddress OID 
>> defined by the schema is the same as the OID for
''ntGroupType'', which
>> is defined in FDS'' 50ns-directory.ldif schema.
>
>
> I believe that the ntGroupType
> attribute definition has been in the server for a very long time 
> (since DS3.x).
> It''s certainly in DS6.21 and Sun DS 5.2.
>
> Thinking more...perhaps this is a typo in 
> draft-lachman-laser-ldap-mail-routing-02.txt ?
> One would have thought that Hans would have tested the schema
> in a real server. Possibly there is a valid OID assigned for
> mailRoutingAddress and the doc is in error ?
>
> Checking the schema in a server...I see 2.16.840.1.113730.3.1.24 for
> mailRoutingAddress.
>
> So possibly the document is wrong and the laser schema is already there
> in your server (in 50ns-mail.ldif) ?
>
>
>
>
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Is there any way to give a filtered role an alternate base DN?  It seems 
like the search scope for filtered roles is limited to the container in 
which it''s created.  This means a role created in 
"cn=roles,dc=example,dc=com" will not apply to entries in 
"ou=people,dc=example,dc=com".  Is the only solution to create the
role
above the ou=people container?

Thanks,
-- George

George Holbert wrote:
> Is there any way to give a filtered role an alternate base DN?  It 
> seems like the search scope for filtered roles is limited to the 
> container in which it''s created.  This means a role created in 
> "cn=roles,dc=example,dc=com" will not apply to entries in 
> "ou=people,dc=example,dc=com".  Is the only solution to create
the
> role above the ou=people container?
That doesn''t sound right. I thought that the base DN could be
specified.
Sorry I don''t have the cycles to check the docs and/or the code right
now,
but I really thought that this was implemented already.

> -----Original Message-----
> From: fedora-directory-users-bounces@redhat.com 
> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf 
> Of George Holbert
> Sent: Tuesday, August 23, 2005 2:11 PM
> To: General discussion list for the Fedora Directory server project.
> Subject: [Fedora-directory-users] filtered roles'' base DN
> 
> Is there any way to give a filtered role an alternate base 
> DN?  It seems like the search scope for filtered roles is 
> limited to the container in which it''s created.  
There is no way to do that.  There _used_ to be a way (very early on) to
specify a base dn for class of service - until it was pointed out that there
were security issues with that.  Similar security issues arise with roles
e.g. it would be possible to assign roles across administrative boundaries
i.e. actually effecting the data returned for the entries despite having no
permission to do so.  This is really an artifact of the virtual nature of
the attribute, access control scoping, and performance considerations for
making a projected role secure.  The problem is quite unlike groups, which
have no effect on the entries themselves.
> This means a 
> role created in "cn=roles,dc=example,dc=com" will not apply 
> to entries in "ou=people,dc=example,dc=com".  Is the only 
> solution to create the role above the ou=people container?
In fact, to replicate the scope you require you would add the role as a
child of ou=people (the scope is from the parent of the role configuration).
This has its advantages e.g. the scope of a role is obvious from its
position in the dit; any replication or migration of the subtree would
include the role configuration too, it is much easier to delegate
adminstrative rights over roles across the organization etc.  Unlike group
entries, role configuration entries are not returned by searches that do not
specifically look for them (you need a filter that include
objectclass=ldapsubentry to return them) so there is less need to allow a
different scope.