Re: [389-users] Reset Password as Root if User Forgets Password

[Nathan Kinder]

On 01/22/2014 12:31 PM, Chaudhari, Rohit K. wrote:
> Before I explore this further, when using "ldappasswd," will it still
> prompt me for the current password before I can type in a new password to
> replace it?

You need to be bound to the LDAP server as a user who has permission to
change the password.  If you are changing your own password, you need to
supply your existing password to complete this bind operation.  If you
are an admin resetting a password for a different user, you will need to
supply the admin user password to complete the bind, but you will not
need to supply the user's existing password.

The ldappasswd command requires that the connection is protected with
SSL/TLS or a SASL mechanism that provides confidentiality.  You will
need to resolve your TLS problem.

> 
> 
> On 1/22/14 3:26 PM, "Paul Robert Marino"  wrote:
> 
>> your SSL cert or your DNS is bad. TLS requires full forward and revers
>> lookup of the C name for the host to match one of the host names in
>> the SSL cert.
>>
>>
>>
>> On Wed, Jan 22, 2014 at 3:08 PM, Chaudhari, Rohit K.
>>  wrote:
>>> I'm not using kerberos.  The other suggestion about using ldappasswd led
>>> to the error:
>>>
>>> ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
>>> Additional info: TLS: hostname does not match CN in peer certificate
>>>
>>> Is there a way to create a JNDI equivalent command so that I could add a
>>> checkbox to a Java GUI that basically toggles the "force password change
>>> after reset" checkbox built into the password policy in 389?
>>>
>>> On 1/22/14 10:49 AM, "Paul Robert Marino"  wrote:
>>>
 sorry thats not possible.
 If you are using Kerberos then you can do it via the kadmin command.
 If not then you have to use one of several other tools like the admin
 console or ldapmodify for example.


 On Wed, Jan 22, 2014 at 9:06 AM, Chaudhari, Rohit K.
  wrote:
> Hello,
>
> I need to be able to reset a LDAP user's password if they forget it
> with the
> user root.  But when I try the "passwd" command as root for a LDAP
> user,  I
> get the following:
>
> (as root)
> passwd tuser
> Changing password for user tuser.
> Password reset by root is not supported.
> passwd: Authentication token manipulation error.
>
> I am using sssd as the LDAP authentication mechanism tool, to be
> specific.
> Does anyone have a solution to dealing with this issue of resetting a
> LDAP
> user's password if they forgot it?
>
> Thanks,
>
> Rohit
>
> From: , "Rohit K. Chaudhari" 
> Date: Tuesday, January 21, 2014 3:29 PM
> To: "General discussion list for the 389 Directory server project."
> <389-users@lists.fedoraproject.org>
> Subject: using passwd with 389
>
> Hello,
>
> I want to be able to use the Unix "passwd" command to reset a LDAP
> user's
> password from the command line.  However, I keep getting an
> authentication
> token manipulation error whenever I try to reset the password using
> that
> command.  What do I need to do in the 389 DS or on Unix in order to
> get
> this
> command to work?
>
> Thanks,
>
> Rohit
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
 --
 389 users mailing list
 389-users@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>> --
>>> 389 users mailing list
>>> 389-users@lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
> 
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
> 

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Only username as bind dn

[Nathan Kinder]

On 01/16/2014 07:13 AM, Paolo Barbato wrote:
> 
> On 16/gen/2014, at 15:52, Rich Megginson  wrote:
> 
>> On 01/16/2014 07:48 AM, Paolo Barbato wrote:
>>> Hi Rich,
>>>
>>> On 16/gen/2014, at 15:28, Rich Megginson  wrote:
>>>
 On 01/16/2014 12:56 AM, Paolo Barbato wrote:
> Thanks for replies, I think I need to better describe what I'm testing.
>
> As I said I've a central repository for credentials accessible via ldaps.
>
> 389dirsvr stores some information, but before get them I need that a user 
> authenticate on the central repository.
>
> So I've activated and configured PAM Pass Through Authentication Plug-in, 
> and following instructions creating a specific /etc/pam.d/ldapserver as 
> well as /etc/pam_ldap.conf
>
> This is working, I mean that if I type
>
> ldapsearch -v -LLL -Hldaps://my389 -b"dc=myDC" -D "uid=myUser" -W -x
>
> the PAM PTA strips myUser from binddn and use that as login username for 
> PAM.
>
> Let me just say that in production I'll use a different repository based 
> on Active DIrectory, so probably I'll use SSSD, as you suggest.
>
> The problem.
>
> If I use a command like
>
> ldapsearch -v -LLL -Hldaps://my389 -b"dc=myDC" -D "myUser" -W -x
>
> it fails, since 389dirsrv makes a syntax check on binddn before pass 
> stripped myUser value to PAM PTA
>
> This is really trye since I do not any attempt on ldap central repository 
> access logs.
>
> Here my question : is it mandatory using as binddn (-D) a syntax like 
> uid=myUser or cn=myUser, or is it possible to configure 389dirsrv to 
> rewrite myUser in uid=myUser before process it ?
 No.  The argument to -D must be a DN.

>>> I suspect that, so you confirm that such a syntax control is performed by 
>>> 389dirsrv .
>> Yes.  You can disable syntax and DN syntax checking, but that is strongly 
>> discouraged.
>>>
> ok !
 There are SASL mechanisms that take a username instead of a DN.

>>> Yes, I've tried that way using openldap and saslauthd, but also in that 
>>> deployment I must always use uid=myUser as DN, since control syntax 
>>> prevails.
>>
>> There are SASL mechanisms that allow you to use a username and not a bind 
>> DN.  This should work with 389 and openldap and other directory servers that 
>> support those SASL mechanisms.  In that case, you do not use -D "bind=dn"
>>
> 
> I've to further investigate this way
> 
>>>
>>> In my lab I use Stalker CGPro as mailer, that allow ldap bind, for example 
>>> from thunderbird address book client, using only a username as bind dn.
>>
>> I wonder if that is an AD-ism?  One of the many ways that AD violates LDAP 
>> is that it allows non-DNs to be used with -D.
>>
> Oh yes could be really that. So that ldap server get the username from -D 
> non-DN  without any particular check, and lookup for a match in the default 
> subtree. Is that really so dangerous ? 

For thunderbird, I suspect the client side does an anonymous search for
"uid=" to find the full bind DN, which it then uses to perform
the bind.

> 
> Regards,
> Paolo.
> 
>>>
>>> Regards,
>>> Paolo.
>>>
>>>
>
> Regards,
> Paolo.
>
>
>
> On 15/gen/2014, at 23:13, Dan Lavu  wrote:
>
>> Why are you using pam passthrough, what are you using as your 
>> authentication mechanism? SSSD has all commonly implemented 
>> authentication mechanisms.
>>
>>
>>
>> On 01/15/2014 12:54 PM, Jonathan Vaughn wrote:
>>> If you want to be able to map the simple username "myUser" to say, 
>>> "uid=myUser,cn=Users,dc=mycompany,dc=net", you probably are best off 
>>> using SSSD to handle that.
>>> SSSD can be configured to know where to search and how to apply the 
>>> supplied username to the search (i.e. to look for anything under 
>>> cn=Users,dc=mycompany,dc=net where uid=[the supplied username]).
>>>
>>> SSSD in turn provides a PAM module to talk to the SSSD daemon itself, 
>>> which is where you can hook up your PAM passthrough authentication.
>>>
>>> i.e., we use SSSD for SSO login to our Linux machines, and have the 
>>> following lines (in addition to the usual stuff) in our 
>>> pam.d/password-auth :
>>>
>>> authsufficientpam_sss.so use_first_pass
>>> account [default=bad success=ok user_unknown=ignore] pam_sss.so
>>> passwordsufficientpam_sss.so use_authtok
>>> session optional  pam_sss.so
>>>
>>>
>>>
>>>
>>> On Wed, Jan 15, 2014 at 3:46 AM, Paolo Barbato 
>>>  wrote:
>>> Hi 389-users,
>>>
>>> I'm testing last released 389 dirsrv on a rhel 6.5.
>>>
>>> I've deployed a PAM passthrough, since I have a central repository for 
>>> credentials, and it works.
>>>
>>> I guess if it would be possible to use a simple username or it's 
>>> mandatory use syntax lik

Re: [389-users] How to specify number of hashing iterations for a password

[Nathan Kinder]

On 01/15/2014 10:51 AM, Richard Mixon wrote:
> Nathan/Rich,
> 
> Thank you both for the responses.
> 
> We are using the 389 Directory Server for a pretty isolated situation -
> authentication/authorization for external users on an "extranet" type
> portal website (it integrates pieces of several different web applications).
> 
> We don't really envision (famous last words, I know) using it on a
> broader basis.
> 
> Rich, I can understand why the pre-hashed passwords cause a lot of
> integration points to break. Is there a good alternative that still
> makes cracking your passwords prohibitively expensive?
> 
> Nathan, I have a background in C, but do mostly Java these days. I will
> take a look at ticket 397 and get back to you if it's something I could
> work on. Can you provide me the pointers you were referring to?

You can take a look at the existing password storage scheme plugin code:


https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/servers/plugins/pwdstorage

Each storage scheme needs a set of comparison and encoding functions.
The comparison is used to validate a password during a bind operation,
and the encoding function is used when a password is set.  You then
register these functions in pwd_init.c, which is where you can map the
storage scheme prefix with the callbacks.

The actual hashing would be done by calling into NSS from the new
functions.

> 
> Thank you - Richard
> 
> 
> 
> On Wed, Jan 15, 2014 at 11:25 AM, Rich Megginson  > wrote:
> 
> On 01/15/2014 10:38 AM, Richard Mixon wrote:
>> During the bind process is there anyway to tell 389 directory
>> server to hash a plaintext password n (multiple) times before
>> trying to compare to what is stored?
>>
>> I am trying to implement something similar to what's described in
>> this article:
>>   http://www.stormpath.com/blog/strong-password-hashing-apache-shiro
>>
>> Our plan was to to use SSHA256 to hash the passwords around
>> 200,000 times before storing. This would at least slow down any
>> cracking attempts should someone get access to our directory.
>>
>> I've read through the documentation on the Red Hat Directory
>> Server site, including the "Plug-in Guide". Under "5.8 Checking
>> Passwords" it refers to calling function "slapi_pw_find_sv()" -
>> looking at the doc for this function it does not look like hashing
>> multiple times is supported.
>>
>> Is there  some means of doing this that is not obvious to me?
> 
> No.
> 
>>
>> I can certainly do it by re-writing the security plugins for the
>> various servers (Tomcat, PHP Wordpress, etc) such that they hash
>> the plaintext password n minus 1 times before issuing the bind -
>> but was hoping not to do that.
> 
> Use of pre-hashed passwords is strongly discouraged and will break
> things like sasl and replication.
> 
> Does this have anything to do with
> https://fedorahosted.org/389/ticket/397?
> 
>>
>> I'm relatively new to 389 directory server, but so far quite happy
>> to have moved to it from another directory server.
>>
>> Thank you - Richard
>>
>> -- 
>> Richard Mixon
>> Custom Computer Creations, L.L.C.
>> mobile: (480) 577-6834  office: (480)
>> 614-3442 
>> email: rnmi...@custco.biz 
>> >
>> Microsoft Partner ID: 1263725 
>> The messages and documents transmitted with this notice contain
>> confidential information belonging to the sender. If you are not
>> the intended recipient of this information, you are hereby
>> notified that any disclosure, copying, distribution or use of the
>> information is strictly prohibited. If you have received this
>> transmission in error, please notify the sender immediately.
>>
>>
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org 
>> 
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
> 
> 
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> 
> https://admin.fedoraproject.org/mailman/listinfo/389-users
> 
> 
> 
> 
> -- 
> Richard Mixon
> Custom Computer Creations, L.L.C.
> mobile: (480) 577-6834 office: (480) 614-3442
> email: rnmi...@custco.biz  >
> Microsoft Partner ID: 1263725 
> The messages and documents transmitted with this notice contain
> confidential information belonging to the sender. If you are not the
> intended recipient of this information, you are hereby notified that any
> disclosure, copying, distribution or use of the information is strictly
> prohibited. If you have received this transmission in error, please
> notify the sender immediately.
> 
> 
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https

Re: [389-users] How to specify number of hashing iterations for a password

[Nathan Kinder]

On 01/15/2014 09:38 AM, Richard Mixon wrote:
> During the bind process is there anyway to tell 389 directory server to
> hash a plaintext password n (multiple) times before trying to compare to
> what is stored?
> 
> I am trying to implement something similar to what's described in this
> article:
>   http://www.stormpath.com/blog/strong-password-hashing-apache-shiro
> 
> Our plan was to to use SSHA256 to hash the passwords around 200,000
> times before storing. This would at least slow down any cracking
> attempts should someone get access to our directory.

No, there is not a way to configure it to perform multiple hash
iterations.  This would require a password storage scheme plug-in.  This
is very similar to PBKDF2, which we have on a list of potential future
features:

https://fedorahosted.org/389/ticket/397
> 
> I've read through the documentation on the Red Hat Directory Server
> site, including the "Plug-in Guide". Under "5.8 Checking Passwords" it
> refers to calling function "slapi_pw_find_sv()" - looking at the doc for
> this function it does not look like hashing multiple times is supported.
> 
> Is there  some means of doing this that is not obvious to me?
> 
> I can certainly do it by re-writing the security plugins for the various
> servers (Tomcat, PHP Wordpress, etc) such that they hash the plaintext
> password n minus 1 times before issuing the bind - but was hoping not to
> do that.

If you are familiar with C coding, you could work on the above ticket to
implement a PBKDF2 plugin for 389 DS.  We would be willing to get it
into the project since it's on our roadmap.  Let me know if you are
interested in working on this, and I can provide you with some pointers.

Thanks!
-NGK

> 
> I'm relatively new to 389 directory server, but so far quite happy to
> have moved to it from another directory server.
> 
> Thank you - Richard
> 
> -- 
> Richard Mixon
> Custom Computer Creations, L.L.C.
> mobile: (480) 577-6834 office: (480) 614-3442
> email: rnmi...@custco.biz  >
> Microsoft Partner ID: 1263725 
> The messages and documents transmitted with this notice contain
> confidential information belonging to the sender. If you are not the
> intended recipient of this information, you are hereby notified that any
> disclosure, copying, distribution or use of the information is strictly
> prohibited. If you have received this transmission in error, please
> notify the sender immediately.
> 
> 
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
> 

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Distributed Numeric Assignment plugin fails with indexing

[Nathan Kinder]

Title: Untitled Document

  
  
On 03/22/2013 02:24 AM, Scott Crooks
  wrote:


  
  Greetings,

We're using 389-ds on CentOS 6.4 with 3 master LDAP servers in
different locations. All three master servers have a problem
adding new users in our organization database using the DNA
plugin.

We receive the following (unhelpful) error message in the log
files:

[22/Mar/2013:09:54:37 +0800] NSUniqueAttr - ADD begin
[22/Mar/2013:09:54:37 +0800] NSUniqueAttr - ADD parameter
  untagged: uid
[22/Mar/2013:09:54:37 +0800] NSUniqueAttr - ADD
  target=cn=testuser01,ou=Organizations,dc=test,dc=net
[22/Mar/2013:09:54:37 +0800] dna-plugin - dna_pre_op:
failed to allocate a new ID!!
  [22/Mar/2013:09:54:37 +0800] dna-plugin -
dna_pre_op: operation failure [1]
  [22/Mar/2013:09:54:37 +0800] roles-plugin - -->
  roles_post_op
[22/Mar/2013:09:54:37 +0800] roles-plugin - -->
  roles_cache_change_notify
[22/Mar/2013:09:54:37 +0800] roles-plugin - <--
  roles_post_op

We've tried indexing the uidNumber and employeeNumber attributes
as described here: http://www.spinics.net/linux/fedora/389-users/msg10796.html

One curious fact: there are exactly 1000 users in our database
for ou=Organizations,dc=test,dc=net.
When following the instructions for the above link, the log
outputs the following

organizations: Indexing attribute: employeenumber
  organizations: Indexed 1000 entries (97%).
  organizations: Finished indexing.

Our organization uses employeenumber rather than uidNumber, but
they're the same in the end. We find it strange that the user
creation fails at exactly 1000 entries.

Any ideas on where the configuration is wrong? We assume it's a
configuration problem.
  
What does your DNA configuration entry look
  like?  Perhaps you are just out of values due to the size of the
  configured range?
  
  -NGK

 
   



 

  Best Regards
  Scott Crooks
Systems Engineer
  scott.cro...@mcon.net
  Phone: +86 10 8587 7441
  Mobile: +86 138 1089 8314
  http://www.mcon.net 


  

  
  MCON China Ltd.
Suite 1202, e-Tower
12C Guanghua Road
Chaoyang District
Beijing 100020
  埃蒙坎信息系统集
  成技术(北
  京)有限公司
中国 北京市朝阳区光华路丙12号
数码01大厦1202室
邮编：100020 

  

Member of mcon group: Australia •
  Austria • China • Czech Republic • Germany • India • Japan •
  Malaysia • Russia • South Korea • Switzerland • USA


  
  
  
  
  --
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


  

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] How to Managed Entries Plugin for Linux Users?

[Nathan Kinder]

On 03/19/2013 02:33 PM, Chandan Kumar wrote:

Hello,

I am deploying the 389 server (On CentOS 6) to manage the Linux 
Users/Password. So as part of Linux User management, I was trying to 
get the Managed Entries work for Posix user creation.


I am following the standard Redhat documentation.

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html-single/Deployment_Guide/index.html#managed-entries

So I created the templates, exactly the way explained in the doc, but 
when I create the users it is not creating corresponding Groups.


I am using following ldap commands to add entries. I could see the 
this plugin created in from the console server -> data -> Plugins -> 
Managed Entries -> 



User creation statements


dn: uid=pappu1,ou=People,dc=ma,dc=net
objectclass: person
objectclass: inetorgperson
objectclass: posixAccount
cn: Pappu
sn: Papa
givenName: pappu1
uid:pappu1
uidNumber:9003
gidNumber:9003
objectclass: mepOriginEntry
mepManagedEntry: cn=Pappu Group
homeDirectory: /home/pappu1

The plugin

dn: cn=Posix User-Group,cn=Managed Entries,cn=plugins,cn=config
objectclass: extensibleObject
cn: Posix User-Group
originScope: ou=people,dc=ma,dc=ma
You have a typo in your originScope setting.  It should be 
"ou=people,dc=ma,dc=net".


-NGK

originFilter: objectclass=posixAccount
managedBase: ou=groups,dc=ma,dc=net
managedTemplate: cn=Posix User-Group Template,ou=Templates,dc=ma,dc=net

The template

dn: cn=Posix User-Group Template, ou=Templates,dc=ma,dc=net
objectclass: mepTemplateEntry
cn: Posix User-Group Template
mepRDNAttr: cn
mepStaticAttr: objectclass: posixGroup
mepMappedAttr: cn: $cn Group Entry
mepMappedAttr: gidNumber: $gidNumber
mepMappedAttr: memberUid: $uid


--
http://about.me/chandank


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] AD sync problem for group with more than 1500 entries

[Nathan Kinder]

On 02/27/2013 07:49 AM, Rich Megginson wrote:

On 02/27/2013 08:48 AM, Nathan Kinder wrote:

On 02/27/2013 06:57 AM, Rich Megginson wrote:

On 02/26/2013 10:17 PM, Nathan Kinder wrote:

On 02/26/2013 08:42 PM, David Baird wrote:

Hi,

We have been experiencing an intermittent problem with our AD 
sync, where updates to a group in 389 have resulted in the group 
being emptied of users.


This has been occurring at various times but not consistently, so 
was very difficult to track.  Previously, the group would be 
emptied in the AD, which would then replicate back to 389, 
resulting in an empty group in both Directories.


Since installing a fresh CentOS 6.3 server and the latest stable 
389 (at the time, 1.2.10.12-1) the behaviour has only changed 
slightly, in that now the 389 group gets emptied and the AD group 
remains intact.  When this happens, initiating a full re-sync will 
not fix the issue.


We have since discovered that this behaviour is, in fact, 
consistent and repeatable if the group contains more than 1500 
members.  Below that threshold, adding or subtracting users from 
the 389 group replicates perfectly. As soon as you exceed that 
limit, the group gets emptied.


Turning on replication logging revealed the following.
(domain and server names have been made anonymous)

[27/Feb/2013:12:20:33 +1300] - Calling dirsync search request plugin
[27/Feb/2013:12:20:33 +1300] - Sending dirsync search request
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - received 
entry from dirsync: 
CN=students,OU=Groups,OU=Active,OU=People,DC=domain,DC=com
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
agmt="cn=DC01" (DC01:636): map_entry_dn_inbound: looking for local 
entry matching AD entry 
[CN=students,OU=Groups,OU=Active,OU=People,DC=domain,DC=com]
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
agmt="cn=DC01" (DC01:636): map_entry_dn_inbound: looking for local 
entry by guid [919561f60fe49f409afcdf80a63eb089]
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
agmt="cn=DC01" (DC01:636): map_entry_dn_inbound: found local entry 
[CN=students,ou=Groups,ou=Active,ou=People,dc=domain,dc=com]
[27/Feb/2013:12:20:33 +1300] - Calling windows entry search 
request plugin
[27/Feb/2013:12:20:33 +1300] - windows_search_entry: received 2 
messages, 1 entries, 0 references
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
agmt="cn=DC01" (DC01:636): map_entry_dn_inbound: looking for local 
entry matching AD entry 
[CN=students,OU=Groups,OU=Active,OU=People,DC=domain,DC=com]
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
windows_generate_update_mods: 
CN=students,ou=Groups,ou=Active,ou=People,dc=domain,dc=com, 
description : values are equal
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
windows_generate_update_mods: 
CN=students,ou=Groups,ou=Active,ou=People,dc=domain,dc=com, 
ntUserDomainId : values are equal
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
windows_generate_update_mods: deleting uniquemember attribute from 
local entry

[27/Feb/2013:12:20:33 +1300] - smod - windows sync
[27/Feb/2013:12:20:33 +1300] - smod 0 - delete: uniquemember


The particularly interesting line is this
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
windows_generate_update_mods: deleting uniquemember attribute from 
local entry


This only appears to happen when the group contains more than 1500 
entries.


Surely there must be someone else out there syncing groups with 
more than 1500 members between 389 and AD?


It wasn't until I used Apache Directory Studio to compare entries 
between the 389 server and the AD that I noticed the attribute 
name was represented differently when the group contained over 
1500 entries.


This is a result of the range retrieval limit in AD.  When you hit 
the range limit, the attribute name changes from "member" to 
"member;range=0-1499", which causes the mismatch that leads to the 
uniquemember attribute being deleted.


In order to prevent this from happening, we have had to increase 
the MaxValRange setting in our Active Directory as per 
http://support.microsoft.com/kb/2009267 and 
http://support.microsoft.com/kb/315071


The value defaults to 1500 for Windows Server 2003 or 5000 for 
Windows Server 2008.


Personally I consider this a bug in the AD sync plugin, as it 
fails to correctly handle range retrieval.  At the very least, the 
documentation for Windows Sync should contain information about 
this limit.
This does sound like a bug.  Please open a ticket in our Trac 
instance here:


https://fedorahosted.org/389/

The Windows Sync plug-in needs to be modified to understand how to 
use ranged searches.

https://fedorahosted.org/389/ticket/472
This ticket is for simple paged results, which is different. Paged 
results is used for returning a large number of entries. Range 
retrieval is used for a large number of values for a multi-valued 
attributes.  Even when using p

Re: [389-users] AD sync problem for group with more than 1500 entries

[Nathan Kinder]

On 02/27/2013 06:57 AM, Rich Megginson wrote:

On 02/26/2013 10:17 PM, Nathan Kinder wrote:

On 02/26/2013 08:42 PM, David Baird wrote:

Hi,

We have been experiencing an intermittent problem with our AD sync, 
where updates to a group in 389 have resulted in the group being 
emptied of users.


This has been occurring at various times but not consistently, so 
was very difficult to track.  Previously, the group would be emptied 
in the AD, which would then replicate back to 389, resulting in an 
empty group in both Directories.


Since installing a fresh CentOS 6.3 server and the latest stable 389 
(at the time, 1.2.10.12-1) the behaviour has only changed slightly, 
in that now the 389 group gets emptied and the AD group remains 
intact.  When this happens, initiating a full re-sync will not fix 
the issue.


We have since discovered that this behaviour is, in fact, consistent 
and repeatable if the group contains more than 1500 members.  Below 
that threshold, adding or subtracting users from the 389 group 
replicates perfectly. As soon as you exceed that limit, the group 
gets emptied.


Turning on replication logging revealed the following.
(domain and server names have been made anonymous)

[27/Feb/2013:12:20:33 +1300] - Calling dirsync search request plugin
[27/Feb/2013:12:20:33 +1300] - Sending dirsync search request
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - received entry 
from dirsync: 
CN=students,OU=Groups,OU=Active,OU=People,DC=domain,DC=com
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - agmt="cn=DC01" 
(DC01:636): map_entry_dn_inbound: looking for local entry matching 
AD entry [CN=students,OU=Groups,OU=Active,OU=People,DC=domain,DC=com]
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - agmt="cn=DC01" 
(DC01:636): map_entry_dn_inbound: looking for local entry by guid 
[919561f60fe49f409afcdf80a63eb089]
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - agmt="cn=DC01" 
(DC01:636): map_entry_dn_inbound: found local entry 
[CN=students,ou=Groups,ou=Active,ou=People,dc=domain,dc=com]
[27/Feb/2013:12:20:33 +1300] - Calling windows entry search request 
plugin
[27/Feb/2013:12:20:33 +1300] - windows_search_entry: received 2 
messages, 1 entries, 0 references
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - agmt="cn=DC01" 
(DC01:636): map_entry_dn_inbound: looking for local entry matching 
AD entry [CN=students,OU=Groups,OU=Active,OU=People,DC=domain,DC=com]
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
windows_generate_update_mods: 
CN=students,ou=Groups,ou=Active,ou=People,dc=domain,dc=com, 
description : values are equal
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
windows_generate_update_mods: 
CN=students,ou=Groups,ou=Active,ou=People,dc=domain,dc=com, 
ntUserDomainId : values are equal
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
windows_generate_update_mods: deleting uniquemember attribute from 
local entry

[27/Feb/2013:12:20:33 +1300] - smod - windows sync
[27/Feb/2013:12:20:33 +1300] - smod 0 - delete: uniquemember


The particularly interesting line is this
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
windows_generate_update_mods: deleting uniquemember attribute from 
local entry


This only appears to happen when the group contains more than 1500 
entries.


Surely there must be someone else out there syncing groups with more 
than 1500 members between 389 and AD?


It wasn't until I used Apache Directory Studio to compare entries 
between the 389 server and the AD that I noticed the attribute name 
was represented differently when the group contained over 1500 entries.


This is a result of the range retrieval limit in AD.  When you hit 
the range limit, the attribute name changes from "member" to 
"member;range=0-1499", which causes the mismatch that leads to the 
uniquemember attribute being deleted.


In order to prevent this from happening, we have had to increase the 
MaxValRange setting in our Active Directory as per 
http://support.microsoft.com/kb/2009267 and 
http://support.microsoft.com/kb/315071


The value defaults to 1500 for Windows Server 2003 or 5000 for 
Windows Server 2008.


Personally I consider this a bug in the AD sync plugin, as it fails 
to correctly handle range retrieval.  At the very least, the 
documentation for Windows Sync should contain information about this 
limit.
This does sound like a bug.  Please open a ticket in our Trac 
instance here:


https://fedorahosted.org/389/

The Windows Sync plug-in needs to be modified to understand how to 
use ranged searches.

https://fedorahosted.org/389/ticket/472
This ticket is for simple paged results, which is different.  Paged 
results is used for returning a large number of entries.  Range 
retrieval is used for a large number of values for a multi-valued 
attributes.  Even when using paged results, AD will trim a multi-valued 
attribute whose values pass the range retrieval limi

Re: [389-users] AD sync problem for group with more than 1500 entries

[Nathan Kinder]

On 02/26/2013 08:42 PM, David Baird wrote:

Hi,

We have been experiencing an intermittent problem with our AD sync, 
where updates to a group in 389 have resulted in the group being 
emptied of users.


This has been occurring at various times but not consistently, so was 
very difficult to track.  Previously, the group would be emptied in 
the AD, which would then replicate back to 389, resulting in an empty 
group in both Directories.


Since installing a fresh CentOS 6.3 server and the latest stable 389 
(at the time, 1.2.10.12-1) the behaviour has only changed slightly, in 
that now the 389 group gets emptied and the AD group remains intact.  
When this happens, initiating a full re-sync will not fix the issue.


We have since discovered that this behaviour is, in fact, consistent 
and repeatable if the group contains more than 1500 members.  Below 
that threshold, adding or subtracting users from the 389 group 
replicates perfectly. As soon as you exceed that limit, the group gets 
emptied.


Turning on replication logging revealed the following.
(domain and server names have been made anonymous)

[27/Feb/2013:12:20:33 +1300] - Calling dirsync search request plugin
[27/Feb/2013:12:20:33 +1300] - Sending dirsync search request
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - received entry 
from dirsync: CN=students,OU=Groups,OU=Active,OU=People,DC=domain,DC=com
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - agmt="cn=DC01" 
(DC01:636): map_entry_dn_inbound: looking for local entry matching AD 
entry [CN=students,OU=Groups,OU=Active,OU=People,DC=domain,DC=com]
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - agmt="cn=DC01" 
(DC01:636): map_entry_dn_inbound: looking for local entry by guid 
[919561f60fe49f409afcdf80a63eb089]
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - agmt="cn=DC01" 
(DC01:636): map_entry_dn_inbound: found local entry 
[CN=students,ou=Groups,ou=Active,ou=People,dc=domain,dc=com]
[27/Feb/2013:12:20:33 +1300] - Calling windows entry search request 
plugin
[27/Feb/2013:12:20:33 +1300] - windows_search_entry: received 2 
messages, 1 entries, 0 references
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - agmt="cn=DC01" 
(DC01:636): map_entry_dn_inbound: looking for local entry matching AD 
entry [CN=students,OU=Groups,OU=Active,OU=People,DC=domain,DC=com]
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
windows_generate_update_mods: 
CN=students,ou=Groups,ou=Active,ou=People,dc=domain,dc=com, 
description : values are equal
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
windows_generate_update_mods: 
CN=students,ou=Groups,ou=Active,ou=People,dc=domain,dc=com, 
ntUserDomainId : values are equal
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
windows_generate_update_mods: deleting uniquemember attribute from 
local entry

[27/Feb/2013:12:20:33 +1300] - smod - windows sync
[27/Feb/2013:12:20:33 +1300] - smod 0 - delete: uniquemember


The particularly interesting line is this
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
windows_generate_update_mods: deleting uniquemember attribute from 
local entry


This only appears to happen when the group contains more than 1500 
entries.


Surely there must be someone else out there syncing groups with more 
than 1500 members between 389 and AD?


It wasn't until I used Apache Directory Studio to compare entries 
between the 389 server and the AD that I noticed the attribute name 
was represented differently when the group contained over 1500 entries.


This is a result of the range retrieval limit in AD.  When you hit the 
range limit, the attribute name changes from "member" to 
"member;range=0-1499", which causes the mismatch that leads to the 
uniquemember attribute being deleted.


In order to prevent this from happening, we have had to increase the 
MaxValRange setting in our Active Directory as per 
http://support.microsoft.com/kb/2009267 and 
http://support.microsoft.com/kb/315071


The value defaults to 1500 for Windows Server 2003 or 5000 for Windows 
Server 2008.


Personally I consider this a bug in the AD sync plugin, as it fails to 
correctly handle range retrieval.  At the very least, the 
documentation for Windows Sync should contain information about this 
limit.

This does sound like a bug.  Please open a ticket in our Trac instance here:

https://fedorahosted.org/389/

The Windows Sync plug-in needs to be modified to understand how to use 
ranged searches.


Thanks,
-NGK


David.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] recovering DNA ranges

[Nathan Kinder]

On 02/20/2013 02:33 PM, Rob Crittenden wrote:
With DNA configured for allocating POSIX uids with an MMR setup we see 
the range split in half with every new replica provisioned. This is 
expected.


It appears that if a replica is deleted then its range is lost. Is 
there a way to recover this range?

Yes, but it's not handled automatically by DNA.


Since each has a start/max value, I guess what we'd have to do is find 
whatever server has the closest min value and extend the max value on 
that master. I'm assuming we'll need to delegate writing to the DNA 
config entry, which I'm a little uncomfortable with.
DNA configuration for each server has an active range as well as an 
on-deck range.  The active range is defined by the "dnaNextValue" and 
"dnaMaxValue" attributes.  The on-deck range is defined by the 
"dnaNextRange" attribute, which takes a value in the form 
"-" ("500-1000" would be an example).  I would recommend 
giving the range of a deleted replica to the on-deck range of another 
replica instead of trying to extend it's active range.  That way you 
don't have to deal with problems where you don't have another master 
with an adjacent range.


The on-deck range is used internally by DNA when a range transfer takes 
place.  If a replica hits the configured low-water mark (the 
"dnaThreshold" attribute), it will request a range transfer from another 
replica.  It might still have some active range values left to use, so 
it puts the transferred range on-deck and swaps it to the active range 
once the active range is fully exhausted.  When you are trying to choose 
a server to reassign the deleted replica range to, you should make sure 
it doesn't already have another range on-deck.


Is it also safe to assume that this wouldn't require a restart?

Correct.  Dynamic changes will work fine.


Would it be better to instead write a tool to help manage the DNA ranges?

It could certainly help make things easier.

-NGK


thanks

rob
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Strange Disk IO issue

[Nathan Kinder]

On 05/16/2012 01:09 PM, Brad Schuetz wrote:

On 05/16/2012 11:54 AM, Nathan Kinder wrote:

On 05/16/2012 11:19 AM, Brad Schuetz wrote:

On 05/16/2012 06:16 AM, Paul Robert Marino wrote:

The exact timing of the issue is to strange is there a backup job
running at midnight. Or some other timed job that could be eating the
ram or disk IO. Possibly one that is reliant on ldap queries that
would otherwise be inocuious.



It doesn't happen at midnight, it's 24 hours from when the process was
started, so I can restart dirsrv at 3:17pm on Wednesday and at right
around 3:17pm on Thursday that server will go to 100% disk IO usage.

The default tombstone purge interval is 1 day, which seems to fit what
you are seeing.  The tombstone reap thread will start every 24 hours
to find tombstone entries that can be deleted.  The default retention
period for tombstones is 1 week.  It is possible that you have a large
number of tombstone entries that need to be deleted.  This will occur
independently on all of your server instances.  This is controlled by
the "nsDS5ReplicaTombstonePurgeInterval" and "nsDS5ReplicaPurgeDelay"
attributes in your "cn=replica,cn=,cn=mapping
tree,cn=config" entry.


I have no "nsDS5ReplicaTombstonePurgeInterval" value set (so it's using
that default), and "nsDS5ReplicaPurgeDelay" is set to 3600
Ok, so this means every 24 hours, the tombstone reap thread will look 
for tombstones older than 1 hour and remove them.




You can search for "(objectclass=nstombstone)" as Directory Manager to
see how many tombstone entries you have.

I have a LOT of tombstone entries, over 200k on this one server (I'm
guessing since I've been restarting the process for over a week now, not
letting it run the cleanup process).
That's possible if you really do 200k delete operations in 1 week, but 
that sounds like a lot.  It would seem that these tombstones have been 
building up for a longer time than 1 week.


So, any suggestions on what can I do to fix this?  The process that's
reaping the entries is using too much IO making queries time out, older
versions of the software did not exhibit this behavior.  In fact, I can
reinitalize the entire replica faster than this thing is reaping the
entries, it takes 7 minutes to reinit a replica, but when this issue
first started I let the dirsrv run much longer before restarting it.
Due to the number of matching entries for the tombstone search, it is 
having to walk your entire database, which is why you see the IO 
spiking.  What you could do is to export your database with "db2ldif 
-r".  This will preserve the replication related data in the LDIF.  You 
can then remove the tombstone entries in the LDIF file via a script and 
reimport it.  You would have to do this on each server, or do it on one 
master and then reinitialize the rest of your servers.  One thing to 
watch out for is that you do not want to remove the RUV entry, which 
will have the "nstombstone" objectclass.  This RUV entry will have a 
"nsuniqueid=---" value that you can use 
to distinguish if from the rest of the tombstones.


Should I make it purge more frequently so there are fewer entries to
reap?  Or is this just some weird bug?

I'd leave the purge settings as they are.


--
Brad
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Strange Disk IO issue

[Nathan Kinder]

On 05/16/2012 06:16 AM, Paul Robert Marino wrote:


The exact timing of the issue is to strange is there a backup job 
running at midnight. Or some other timed job that could be eating the 
ram or disk IO. Possibly one that is reliant on ldap queries that 
would otherwise be inocuious.


It is possible that it is the tombstone reap thread, which runs 
periodically.  Do you do a lot of entry deletion operations throughout 
the typical day?
On May 16, 2012 7:51 AM, "Gregory Matthews" 
mailto:greg.matth...@diamond.ac.uk>> wrote:


On 15/05/12 19:22, Brad Schuetz wrote:

Of the 7 replicas, 5 are attached to one network, and 2 are on
another
network.  The 5 are queried a LOT, the other 2 barely get any
traffic at
all.  All, however, are getting the same traffic that they
were getting
when I was using previous versions of the LDAP server.

The 2 that are barely used I've checked for excessive queries
being run
at the point when load goes crazy and they are getting the
usual minimal
load.

Also that doesn't explain why it's always 24 hours that it goes
haywire.  It doesn't matter when I restart the service, it
could be
restarted at 2am, then in 24 hours it will go crazy IO load.


do you know what the IO is? is it swapping? are you running
collectl or similar so you can look at historic performance data?

G


--
Brad
--
389 users mailing list
389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users



-- 
Greg Matthews01235 778658

Scientific Computing Group Leader
Diamond Light Source Ltd. OXON UK

-- 
This e-mail and any attachments may contain confidential,

copyright and or privileged material, and are for the use of the
intended addressee only. If you are not the intended addressee or
an authorised recipient of the addressee please notify us of
receipt by returning the e-mail and do not use, copy, retain,
distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the
individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any
attachments are free from viruses and we cannot accept liability
for any damage which you may sustain as a result of software
viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in
England and Wales with its registered office at Diamond House,
Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11
0DE, United Kingdom




--
389 users mailing list
389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] run memberof update

[Nathan Kinder]

On 03/19/2012 01:19 PM, Ellsworth, Josh wrote:

I configured the memberof plugin after having a bunch of people in groups. How 
can I get these to update now, after the fact?

See the documentation about the fixup-memberof.pl script mentioned here:

http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Advanced_Entry_Management.html#groups-cmd-memberof


Josh
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] bypassing limits for persistent search and specific user

[Nathan Kinder]

On 03/13/2012 04:09 PM, Petr Spacek wrote:

Hello list,

I'm looking for way how to bypass nsslapd-sizelimit and 
nsslapd-timelimit for persistent search made by specific user (or 
anything made by that user).


Please, can you point me to right place in documentation about 
persistent search/user specific settings in 389? I googled for a 
while, but I can't find exact way how to accomplish this.

You can set user-based limits as shown here:

http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/User_Account_Management-Setting_Resource_Limits_Based_on_the_Bind_DN.html#Setting_Resource_Limits_Based_on_the_Bind_DN-Setting_Resource_Limits_Using_the_Command_Line


I found attributes nsSizeLimit and nsTimeLimit in 
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html-single/Schema_Reference/index.html#nsPagedSizeLimit 
, but I'm not sure how to deploy them.



If bypassing is not possible in 389:
Is there any way how to enumerate all records from given subtree 
part-by-part? (My guess: VLV or something similar.)
There is VLV, and there is also simple-paged results.  Both are methods 
that can be used to enumerate through search results in chunks.  VLV 
requires explicit configuration of a VLV index for the exact search that 
you want to perform ahead of time.  Simple-paged results can be used 
with any search.  Here are some details on using simple-paged results:


http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/using-simple-paged-results.html


I know only basics about persistent search and next to nothing about 
VLV, so sorry if I'm completely wrong.



--- Background / why I needed this / long story ---
FreeIPA project has LDAP plugin for BIND. This plugin pulls DNS 
records from LDAP database and populates BIND's internal memory with 
them. (Homepage: https://fedorahosted.org/bind-dyndb-ldap/)


This plugin can use persistent search, which enables reflecting 
changes in LDAP inside BIND immediately.


At this moment, plugin after start do persistent search for all DNS 
records. This single query can lead to tens of thousands records - and 
of course fails, because nssldapd-sizelimit stops that.


Another problem arises with databases smaller than sizelimit - query 
is ended after timelimit and has to be re-established. It leads to 
periodical re-downloading whole DNS DB.


Question is:
 It's possible to bypass limits for this connection/user

I think setting the limits based on your bind DN should work.

-NGK

OR
 plugin is completely broken by design?


Thanks for you time.

Petr^2 Spacek  @  Red Hat  @  Brno office
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Possible problems on 1.2.10-0.6.a6.fc15.x86_64

[Nathan Kinder]

On 02/08/2012 07:53 AM, Edward Z. Yang wrote:

Hello folks,

We recently updated our dirsrv instances to 1.2.10-0.6.a6.fc15.x86_64,
and had it crash repeatedly one of our more loaded servers. We haven't
debugged in depth but were curious whether or not anyone else had seen
this problem.  There were no error logs, but we weren't add loglevel
debug.
You really should try a more recent build.  The 
389-ds-base-1.2.10-0.10.rc1 build should be available in the Fedora 
updates-testing repos.  There were some crash issues that were fixed 
since the a6 build.


Edward
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Sync uidNumber between AD and directory server

[Nathan Kinder]

On 03/17/2011 01:33 PM, pav...@gmail.com wrote:
> Hi,
> Is it possible to sync uidNumber and gidNumber from AD 2008 to DS. If
> not is there any way to map this attributes? Documentation is showing
> only hard coded pre-define attribute is being synchronize. Thanks
The documentation is correct.  The list of attributes synchronized is 
hard-coded.

-NGK
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Change of attibute syntaxes between versions

[Nathan Kinder]

On 03/16/2011 04:31 AM, Juan Asensio Sánchez wrote:
> Hi
>
> We had in version 1.1.3, some values in the attribute
> destinationIndicator with tildes and special chars; in that version
> the syntax of the attribute was Directory String. We have updated to
> version 1.2.5, and now, when running syntax-validate.pl, it reports
> that those values violate the syntax, because the syntax of the
> attribute has changed to Printable String. Why has the syntax changed?
A number of the syntaxes changed to match the current RFCs.  The 
destinationIndicator task is specified as a Printable String in RFC 4519.
> How can I solve this issue? We have a replicated environment, so I
> can't (or shouldn't) modify the standard schema files. The same
> happens with the attribute searchGuide.
If you can not follow the syntax rules of the attributes, you may need 
to disable syntax checking.  This is not desirable, but you may not have 
any other choice if you can't change your values to follow the rules.  
If you wish to turn syntax checking off, set "nsslapd-syntaxcheck: off" 
in "cn=config".
> Something similar happens with the attribute nsViewFilter, altough
> this attribute has not changed its syntax across these two versions.
> Ths script reports that this filter violates the syntax:
>
> (ou=*ou=AABBB,ou=Recursos,o=,dc=YYY,dc=ZZ)
>
> But I think this filter is valid. Why is the tool reporting that error?
Older versions of 389 (or Fedora DS) did not have syntax checking at 
all.  The nsViewFilter attribute uses the IA5 String syntax, which 
should allow all of these characters.  Some more details on this error 
and the steps you took to hit it would be useful.
> Also, if I try to import an exported database that contains those
> values, the server fails because of the syntax errors.
Yes, syntax checking is run during import.  If you had old values that 
are now illegal, you will get these errors if syntax checking is enabled.
> Regards and thanks in advance.
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] 389 1.2.7.5 build on RHEL6

[Nathan Kinder]

On 02/17/2011 04:40 PM, Daniel R. Gore wrote:
> Nathan,
>
> I will check tomorrow.  I do not think I do though.  I will let you
> know.
You should do a "yum install dejavu-*" if you don't have any of those 
packages installed already.  That may fix this issue.
> Thank you.
>
> Dan
>
> On Thu, 2011-02-17 at 15:29 -0800, Nathan Kinder wrote:
>> Do you have any of the dejavu-* packages installed?  This might be a
>> font problem.
>>
>> On 02/17/2011 03:23 PM, Daniel R. Gore wrote:
>>> I have finally got 389 to build completely on a RHEL6 virtual systems.
>>> Unfortunately, I cannot get the console(s) to work correctly.  When I
>>> execute the /usr/sbin/389-console script, I get a console, but it shows
>>> three empty input fields with no description of what they are for and
>>> three little tabs across the bottom that appear to be for something, but
>>> have no labels.  I clicked on one of them and it closed the console.  I
>>> also could not get the idm-console -a http://localhost:9830 to work.
>>>
>>> Any suggestions would be great.
>>>
>>> I am running out of time and may have to build a rhel5.5 system to run
>>> DS on.  I would prefer to do it on RHEL6 for many reason.  It sure would
>>> be nice to have the RHEL6 RPM builds for DS.
>>>
>>> Thanks.
>>>
>>> Dan
>>>
>>>
>>
>
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] 389 1.2.7.5 build on RHEL6

[Nathan Kinder]

Do you have any of the dejavu-* packages installed?  This might be a 
font problem.

On 02/17/2011 03:23 PM, Daniel R. Gore wrote:
> I have finally got 389 to build completely on a RHEL6 virtual systems.
> Unfortunately, I cannot get the console(s) to work correctly.  When I
> execute the /usr/sbin/389-console script, I get a console, but it shows
> three empty input fields with no description of what they are for and
> three little tabs across the bottom that appear to be for something, but
> have no labels.  I clicked on one of them and it closed the console.  I
> also could not get the idm-console -a http://localhost:9830 to work.
>
> Any suggestions would be great.
>
> I am running out of time and may have to build a rhel5.5 system to run
> DS on.  I would prefer to do it on RHEL6 for many reason.  It sure would
> be nice to have the RHEL6 RPM builds for DS.
>
> Thanks.
>
> Dan
>
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Fwd: [389-announce] Please Help Test 389 Directory Server 1.2.7

[Nathan Kinder]

On 11/23/2010 12:34 PM, Nathan Kinder wrote:
> On 11/23/2010 08:56 AM, Andrey Ivanov wrote:
>> Hi Rich,
>>
>> I have two issues with this new version (that i have compiled from the
>> git sources)
>>
>> here is the first issue :
>>
>> there were some changes to the memberfo plugin (Bug 620927) that added
>> a more rigorous verification of memberofgroupattr parameter of
>> MemberOf plugin. We use the uniqueMember/memberOf attribute pair to
>> manage our groups and backlinks. This configuration does not work with
>> the 1.2.7 server :
>>
>> [23/Nov/2010:17:32:51 +0100] memberof-plugin - Error 53: The
>> uniqueMember configuration attribute must be set to an attribute
>> defined to use the Distinguished Name syntax. (illegal value:
>> memberOfGroupAttr)
>> [23/Nov/2010:17:32:51 +0100] memberof-plugin - configuration failed
>> (DSA is unwilling to perform)
>> [23/Nov/2010:17:32:51 +0100] - Failed to start postoperation plugin
>> MemberOf Plugin
>> [23/Nov/2010:17:32:51 +0100] memberof-plugin - only one memberOf
>> plugin instance can be used
>> [23/Nov/2010:17:32:51 +0100] memberof-plugin - configuration failed
>> (Bad parameter to an ldap routine)
>> [23/Nov/2010:17:32:51 +0100] - Failed to start postoperation plugin
>> MemberOf Plugin
>> [23/Nov/2010:17:32:51 +0100] memberof-plugin - only one memberOf
>> plugin instance can be used
>> [23/Nov/2010:17:32:51 +0100] memberof-plugin - configuration failed
>> (Bad parameter to an ldap routine)
>> [23/Nov/2010:17:32:51 +0100] - Failed to start postoperation plugin
>> MemberOf Plugin
>> [23/Nov/2010:17:32:51 +0100] memberof-plugin - only one memberOf
>> plugin instance can be used
>> [23/Nov/2010:17:32:51 +0100] memberof-plugin - configuration failed
>> (Bad parameter to an ldap routine)
>> [23/Nov/2010:17:32:51 +0100] - Failed to start postoperation plugin
>> MemberOf Plugin
>> [23/Nov/2010:17:32:51 +0100] - Error: Failed to resolve plugin dependencies
>> [23/Nov/2010:17:32:51 +0100] - Error: postoperation plugin MemberOf
>> Plugin is not started
>>
>>
>> The thing is that uniquemember does not have the DN syntax, it has
>> "Name and Optional UID syntax" :
>>
>> attributeTypes: ( 2.5.4.50 NAME 'uniqueMember'
>>EQUALITY uniqueMemberMatch
>>SYNTAX 1.3.6.1.4.1.1466.115.121.1.34
>>X-ORIGIN 'RFC 4519' )
> Please open a bug on this.  My current thinking is that we should also
> allow the grouping attribute to use this syntax, but you should be aware
> that memberOf will not work if you actually have the optional UID part
> present.
I went ahead and logged a bug for this:

https://bugzilla.redhat.com/show_bug.cgi?id=656515
>> Our memberOf configuration:
>> dn: cn=MemberOf Plugin,cn=plugins,cn=config
>> objectClass: top
>> objectClass: nsSlapdPlugin
>> objectClass: extensibleObject
>> cn: MemberOf Plugin
>> nsslapd-pluginPath: libmemberof-plugin
>> nsslapd-pluginInitfunc: memberof_postop_init
>> nsslapd-pluginType: postoperation
>> nsslapd-pluginEnabled: on
>> nsslapd-plugin-depends-on-type: database
>> memberofgroupattr: uniqueMember
>> memberofattr: memberOf
>> nsslapd-pluginId: memberof
>> nsslapd-pluginVersion: 1.2.7
>> nsslapd-pluginVendor: 389 Project
>> nsslapd-pluginDescription: memberof plugin
>>
>>
>>
>> The second issue : when using sutup-ds-admin there is a LD_PRELOAD
>> libldap60.so error. I used the sources mod_nss-1.0.8.tar.gz,
>> 389-admin-1.1.12.a2.tar.bz2 and 389-adminutil-1.1.13.tar.bz2 to
>> compile teh admin server.
>>
>> Creating directory server . . .
>> Your new DS instance 'dmz' was successfully created.
>> Creating the configuration directory server . . .
>> Beginning Admin Server creation . . .
>> Creating Admin Server files and directories . . .
>> Updating adm.conf . . .
>> Updating admpw . . .
>> Registering admin server with the configuration directory server . . .
>> Updating adm.conf with information from configuration directory server . . .
>> Updating the configuration for the httpd engine . . .
>> Starting admin server . . .
>> output: ERROR: ld.so: object '/libldap60.so' from LD_PRELOAD cannot be
>> preloaded: ignored.
>> The admin server was successfully started.
>> Admin server was successfully created, configured, and started.
>> Exiting . . .
>> Log file is '/tmp/setupXxX7a5.log'
>>
>>
>> 2010/11/22 Rich Megginson:
>>> 389-ds-base-1.2.7 is now in Testing.  This release adds some new
>>> features and fixes many bugs.  Please help us test. The sooner we can
>>> get this release tested, the sooner we can push it to Stable and make it
>>> generally available.
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Fwd: [389-announce] Please Help Test 389 Directory Server 1.2.7

[Nathan Kinder]

On 11/23/2010 08:56 AM, Andrey Ivanov wrote:
> Hi Rich,
>
> I have two issues with this new version (that i have compiled from the
> git sources)
>
> here is the first issue :
>
> there were some changes to the memberfo plugin (Bug 620927) that added
> a more rigorous verification of memberofgroupattr parameter of
> MemberOf plugin. We use the uniqueMember/memberOf attribute pair to
> manage our groups and backlinks. This configuration does not work with
> the 1.2.7 server :
>
> [23/Nov/2010:17:32:51 +0100] memberof-plugin - Error 53: The
> uniqueMember configuration attribute must be set to an attribute
> defined to use the Distinguished Name syntax. (illegal value:
> memberOfGroupAttr)
> [23/Nov/2010:17:32:51 +0100] memberof-plugin - configuration failed
> (DSA is unwilling to perform)
> [23/Nov/2010:17:32:51 +0100] - Failed to start postoperation plugin
> MemberOf Plugin
> [23/Nov/2010:17:32:51 +0100] memberof-plugin - only one memberOf
> plugin instance can be used
> [23/Nov/2010:17:32:51 +0100] memberof-plugin - configuration failed
> (Bad parameter to an ldap routine)
> [23/Nov/2010:17:32:51 +0100] - Failed to start postoperation plugin
> MemberOf Plugin
> [23/Nov/2010:17:32:51 +0100] memberof-plugin - only one memberOf
> plugin instance can be used
> [23/Nov/2010:17:32:51 +0100] memberof-plugin - configuration failed
> (Bad parameter to an ldap routine)
> [23/Nov/2010:17:32:51 +0100] - Failed to start postoperation plugin
> MemberOf Plugin
> [23/Nov/2010:17:32:51 +0100] memberof-plugin - only one memberOf
> plugin instance can be used
> [23/Nov/2010:17:32:51 +0100] memberof-plugin - configuration failed
> (Bad parameter to an ldap routine)
> [23/Nov/2010:17:32:51 +0100] - Failed to start postoperation plugin
> MemberOf Plugin
> [23/Nov/2010:17:32:51 +0100] - Error: Failed to resolve plugin dependencies
> [23/Nov/2010:17:32:51 +0100] - Error: postoperation plugin MemberOf
> Plugin is not started
>
>
> The thing is that uniquemember does not have the DN syntax, it has
> "Name and Optional UID syntax" :
>
> attributeTypes: ( 2.5.4.50 NAME 'uniqueMember'
>   EQUALITY uniqueMemberMatch
>   SYNTAX 1.3.6.1.4.1.1466.115.121.1.34
>   X-ORIGIN 'RFC 4519' )
Please open a bug on this.  My current thinking is that we should also 
allow the grouping attribute to use this syntax, but you should be aware 
that memberOf will not work if you actually have the optional UID part 
present.
> Our memberOf configuration:
> dn: cn=MemberOf Plugin,cn=plugins,cn=config
> objectClass: top
> objectClass: nsSlapdPlugin
> objectClass: extensibleObject
> cn: MemberOf Plugin
> nsslapd-pluginPath: libmemberof-plugin
> nsslapd-pluginInitfunc: memberof_postop_init
> nsslapd-pluginType: postoperation
> nsslapd-pluginEnabled: on
> nsslapd-plugin-depends-on-type: database
> memberofgroupattr: uniqueMember
> memberofattr: memberOf
> nsslapd-pluginId: memberof
> nsslapd-pluginVersion: 1.2.7
> nsslapd-pluginVendor: 389 Project
> nsslapd-pluginDescription: memberof plugin
>
>
>
> The second issue : when using sutup-ds-admin there is a LD_PRELOAD
> libldap60.so error. I used the sources mod_nss-1.0.8.tar.gz,
> 389-admin-1.1.12.a2.tar.bz2 and 389-adminutil-1.1.13.tar.bz2 to
> compile teh admin server.
>
> Creating directory server . . .
> Your new DS instance 'dmz' was successfully created.
> Creating the configuration directory server . . .
> Beginning Admin Server creation . . .
> Creating Admin Server files and directories . . .
> Updating adm.conf . . .
> Updating admpw . . .
> Registering admin server with the configuration directory server . . .
> Updating adm.conf with information from configuration directory server . . .
> Updating the configuration for the httpd engine . . .
> Starting admin server . . .
> output: ERROR: ld.so: object '/libldap60.so' from LD_PRELOAD cannot be
> preloaded: ignored.
> The admin server was successfully started.
> Admin server was successfully created, configured, and started.
> Exiting . . .
> Log file is '/tmp/setupXxX7a5.log'
>
>
> 2010/11/22 Rich Megginson:
>> 389-ds-base-1.2.7 is now in Testing.  This release adds some new
>> features and fixes many bugs.  Please help us test. The sooner we can
>> get this release tested, the sooner we can push it to Stable and make it
>> generally available.
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Fwd: [389-announce] Please Help Test 389 Directory Server 1.2.7

[Nathan Kinder]

On 11/23/2010 09:33 AM, Nathan Kinder wrote:
> On 11/23/2010 08:56 AM, Andrey Ivanov wrote:
>> Hi Rich,
>>
>> I have two issues with this new version (that i have compiled from the
>> git sources)
>>
>> here is the first issue :
>>
>> there were some changes to the memberfo plugin (Bug 620927) that added
>> a more rigorous verification of memberofgroupattr parameter of
>> MemberOf plugin. We use the uniqueMember/memberOf attribute pair to
>> manage our groups and backlinks. This configuration does not work with
>> the 1.2.7 server :
>>
>> [23/Nov/2010:17:32:51 +0100] memberof-plugin - Error 53: The
>> uniqueMember configuration attribute must be set to an attribute
>> defined to use the Distinguished Name syntax. (illegal value:
>> memberOfGroupAttr)
>> [23/Nov/2010:17:32:51 +0100] memberof-plugin - configuration failed
>> (DSA is unwilling to perform)
>> [23/Nov/2010:17:32:51 +0100] - Failed to start postoperation plugin
>> MemberOf Plugin
>> [23/Nov/2010:17:32:51 +0100] memberof-plugin - only one memberOf
>> plugin instance can be used
>> [23/Nov/2010:17:32:51 +0100] memberof-plugin - configuration failed
>> (Bad parameter to an ldap routine)
>> [23/Nov/2010:17:32:51 +0100] - Failed to start postoperation plugin
>> MemberOf Plugin
>> [23/Nov/2010:17:32:51 +0100] memberof-plugin - only one memberOf
>> plugin instance can be used
>> [23/Nov/2010:17:32:51 +0100] memberof-plugin - configuration failed
>> (Bad parameter to an ldap routine)
>> [23/Nov/2010:17:32:51 +0100] - Failed to start postoperation plugin
>> MemberOf Plugin
>> [23/Nov/2010:17:32:51 +0100] memberof-plugin - only one memberOf
>> plugin instance can be used
>> [23/Nov/2010:17:32:51 +0100] memberof-plugin - configuration failed
>> (Bad parameter to an ldap routine)
>> [23/Nov/2010:17:32:51 +0100] - Failed to start postoperation plugin
>> MemberOf Plugin
>> [23/Nov/2010:17:32:51 +0100] - Error: Failed to resolve plugin dependencies
>> [23/Nov/2010:17:32:51 +0100] - Error: postoperation plugin MemberOf
>> Plugin is not started
>>
>>
>> The thing is that uniquemember does not have the DN syntax, it has
>> "Name and Optional UID syntax" :
>>
>> attributeTypes: ( 2.5.4.50 NAME 'uniqueMember'
>>EQUALITY uniqueMemberMatch
>>SYNTAX 1.3.6.1.4.1.1466.115.121.1.34
>>X-ORIGIN 'RFC 4519' )
>>
>> Our memberOf configuration:
>> dn: cn=MemberOf Plugin,cn=plugins,cn=config
>> objectClass: top
>> objectClass: nsSlapdPlugin
>> objectClass: extensibleObject
>> cn: MemberOf Plugin
>> nsslapd-pluginPath: libmemberof-plugin
>> nsslapd-pluginInitfunc: memberof_postop_init
>> nsslapd-pluginType: postoperation
>> nsslapd-pluginEnabled: on
>> nsslapd-plugin-depends-on-type: database
>> memberofgroupattr: uniqueMember
>> memberofattr: memberOf
>> nsslapd-pluginId: memberof
>> nsslapd-pluginVersion: 1.2.7
>> nsslapd-pluginVendor: 389 Project
>> nsslapd-pluginDescription: memberof plugin
> Prior to 1.2.7, how was this configuration working for you?  What sort
> of values were you setting in the "uniqueMember" attribute?  The
> memberOf plug-in really needs a full DN to work, which is why the
> restriction to use an attribute with the DN syntax was added.
One other note to add is that the syntax of an attribute is taken into 
account when attribute values are compared.  The memberOf plug-in does 
comparisons like this to detect grouping loops.  It is important to use 
the DN syntax here when we are comparing values that represent DNs, as 
there are many special rules that pertain to a DN.  If an attribute is 
used that uses some other syntax, the comparisons may not detect two 
equivalent DNs which could cause a group looping issue.
>>
>> The second issue : when using sutup-ds-admin there is a LD_PRELOAD
>> libldap60.so error. I used the sources mod_nss-1.0.8.tar.gz,
>> 389-admin-1.1.12.a2.tar.bz2 and 389-adminutil-1.1.13.tar.bz2 to
>> compile teh admin server.
>>
>> Creating directory server . . .
>> Your new DS instance 'dmz' was successfully created.
>> Creating the configuration directory server . . .
>> Beginning Admin Server creation . . .
>> Creating Admin Server files and directories . . .
>> Updating adm.conf . . .
>> Updating admpw . . .
>> Registering admin server with the configuration directory server . . .
>> Updating adm.conf with information from configuration directory server . . .
>> Updating the configuration for the httpd engine . . .
>> Starting admin server . . .
>

Re: [389-users] Fwd: [389-announce] Please Help Test 389 Directory Server 1.2.7

[Nathan Kinder]

On 11/23/2010 08:56 AM, Andrey Ivanov wrote:
> Hi Rich,
>
> I have two issues with this new version (that i have compiled from the
> git sources)
>
> here is the first issue :
>
> there were some changes to the memberfo plugin (Bug 620927) that added
> a more rigorous verification of memberofgroupattr parameter of
> MemberOf plugin. We use the uniqueMember/memberOf attribute pair to
> manage our groups and backlinks. This configuration does not work with
> the 1.2.7 server :
>
> [23/Nov/2010:17:32:51 +0100] memberof-plugin - Error 53: The
> uniqueMember configuration attribute must be set to an attribute
> defined to use the Distinguished Name syntax. (illegal value:
> memberOfGroupAttr)
> [23/Nov/2010:17:32:51 +0100] memberof-plugin - configuration failed
> (DSA is unwilling to perform)
> [23/Nov/2010:17:32:51 +0100] - Failed to start postoperation plugin
> MemberOf Plugin
> [23/Nov/2010:17:32:51 +0100] memberof-plugin - only one memberOf
> plugin instance can be used
> [23/Nov/2010:17:32:51 +0100] memberof-plugin - configuration failed
> (Bad parameter to an ldap routine)
> [23/Nov/2010:17:32:51 +0100] - Failed to start postoperation plugin
> MemberOf Plugin
> [23/Nov/2010:17:32:51 +0100] memberof-plugin - only one memberOf
> plugin instance can be used
> [23/Nov/2010:17:32:51 +0100] memberof-plugin - configuration failed
> (Bad parameter to an ldap routine)
> [23/Nov/2010:17:32:51 +0100] - Failed to start postoperation plugin
> MemberOf Plugin
> [23/Nov/2010:17:32:51 +0100] memberof-plugin - only one memberOf
> plugin instance can be used
> [23/Nov/2010:17:32:51 +0100] memberof-plugin - configuration failed
> (Bad parameter to an ldap routine)
> [23/Nov/2010:17:32:51 +0100] - Failed to start postoperation plugin
> MemberOf Plugin
> [23/Nov/2010:17:32:51 +0100] - Error: Failed to resolve plugin dependencies
> [23/Nov/2010:17:32:51 +0100] - Error: postoperation plugin MemberOf
> Plugin is not started
>
>
> The thing is that uniquemember does not have the DN syntax, it has
> "Name and Optional UID syntax" :
>
> attributeTypes: ( 2.5.4.50 NAME 'uniqueMember'
>   EQUALITY uniqueMemberMatch
>   SYNTAX 1.3.6.1.4.1.1466.115.121.1.34
>   X-ORIGIN 'RFC 4519' )
>
> Our memberOf configuration:
> dn: cn=MemberOf Plugin,cn=plugins,cn=config
> objectClass: top
> objectClass: nsSlapdPlugin
> objectClass: extensibleObject
> cn: MemberOf Plugin
> nsslapd-pluginPath: libmemberof-plugin
> nsslapd-pluginInitfunc: memberof_postop_init
> nsslapd-pluginType: postoperation
> nsslapd-pluginEnabled: on
> nsslapd-plugin-depends-on-type: database
> memberofgroupattr: uniqueMember
> memberofattr: memberOf
> nsslapd-pluginId: memberof
> nsslapd-pluginVersion: 1.2.7
> nsslapd-pluginVendor: 389 Project
> nsslapd-pluginDescription: memberof plugin
Prior to 1.2.7, how was this configuration working for you?  What sort 
of values were you setting in the "uniqueMember" attribute?  The 
memberOf plug-in really needs a full DN to work, which is why the 
restriction to use an attribute with the DN syntax was added.
>
>
> The second issue : when using sutup-ds-admin there is a LD_PRELOAD
> libldap60.so error. I used the sources mod_nss-1.0.8.tar.gz,
> 389-admin-1.1.12.a2.tar.bz2 and 389-adminutil-1.1.13.tar.bz2 to
> compile teh admin server.
>
> Creating directory server . . .
> Your new DS instance 'dmz' was successfully created.
> Creating the configuration directory server . . .
> Beginning Admin Server creation . . .
> Creating Admin Server files and directories . . .
> Updating adm.conf . . .
> Updating admpw . . .
> Registering admin server with the configuration directory server . . .
> Updating adm.conf with information from configuration directory server . . .
> Updating the configuration for the httpd engine . . .
> Starting admin server . . .
> output: ERROR: ld.so: object '/libldap60.so' from LD_PRELOAD cannot be
> preloaded: ignored.
> The admin server was successfully started.
> Admin server was successfully created, configured, and started.
> Exiting . . .
> Log file is '/tmp/setupXxX7a5.log'
>
>
> 2010/11/22 Rich Megginson:
>> 389-ds-base-1.2.7 is now in Testing.  This release adds some new
>> features and fixes many bugs.  Please help us test. The sooner we can
>> get this release tested, the sooner we can push it to Stable and make it
>> generally available.
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] duplicate existing ssl crenentials on another server ?

[Nathan Kinder]

On 11/09/2010 08:06 AM, Daniel Maher wrote:
> On 11/09/2010 04:27 PM, Gerrard Geldenhuis wrote:
>
>
>> There is another document on the wiki which describes how to setup 
>> certificates for a vip that is similar to what you want to do. I can't 
>> find it at the moment but might be worth trolling through the wiki again.
>>  
> Actually, the SSL howto has a section on VIPs (the only hit on a search,
> in fact) :
> http://directory.fedoraproject.org/wiki/Howto:SSL#Using_Subject_Alt_Name
>
> I gave it a second read-through, and it would seem to indicate that alt
> names can be IPs as well as hostnames (i thought it was only the latter
> that was possible).
>
> It would therefore appear to be possible to create a certificate that
> with a series of alt names - in my scenario, there would literally be
> one hostname and two IP addresses.
>
> Has anybody on the list done something similar ?  Any advice ?  Should
> this just work outright ?
>
If you are using the same exact hostname for the second system, you 
could just use the same certificate as the first system (or copy your 
entire cert db).  You then just need to enable SSL in "cn=config" on the 
second system.
> (p.s. Angel Bosch Mora - turns out you may have been right the first
> time ! :) ).
>
>
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] In need of Storing Cleartext Password

[Nathan Kinder]

On 10/29/2010 08:28 AM, Uzor Ide wrote:


Hi

we have a need for 389 directory to store password in clear text, in 
given subtree. I have used the console to configure password policy 
and chose CLEAR for the encryption scheme under passwordStorageScheme, 
yet the passwords are still SSHA encrypted. Is there any other thing 
that I should do.
You need to check the "Enable fine-grained password policies" checkbox 
in the global password policy section in the Console.


# entry-id: 11
dn: cn=users,cn=subscribers,dc=ourcompany,dc=com
objectClass: top
objectClass: nsContainer
cn: users

# entry-id: 14
dn: cn=nsPwPolicyContainer,cn=users,cn=subscribers,dc=ourcompany,dc=com
objectClass: nsContainer
objectClass: top
cn: nsPwPolicyContainer

# entry-id: 15
dn: 
cn=cn\3DnsPwPolicyEntry\2Ccn\3Dusers\2Ccn\3Dsubscribers\2Cdc\3Dourcompany\2Cdc\

 3Dcom,cn=nsPwPolicyContainer,cn=users,cn=subscribers,dc=ourcompany,dc=com
objectClass: ldapsubentry
objectClass: passwordpolicy
objectClass: top
cn: cn=nsPwPolicyEntry,cn=users,cn=subscribers,dc=ourcompany,dc=com
passwordMustChange: off
passwordExp: off
passwordHistory: on
passwordMinAge: 0
passwordChange: off
passwordStorageScheme: clear
passwordInHistory: 3
passwordLockout: on
passwordLockoutDuration: 21600
passwordResetFailureCount: 1800
passwordUnlock: on
passwordMaxFailure: 3

# entry-id: 16
dn: 
cn=cn\3DnsPwTemplateEntry\2Ccn\3Dusers\2Ccn\3Dsubscribers\2Cdc\3Dourcompany\2Cd

 c\3Dcom,cn=nsPwPolicyContainer,cn=users,cn=subscribers,dc=ourcompany,dc=com
objectClass: extensibleObject
objectClass: costemplate
objectClass: ldapsubentry
objectClass: top
cosPriority: 1
pwdpolicysubentry: 
cn=cn\3DnsPwPolicyEntry\2Ccn\3Dusers\2Ccn\3Dsubscribers\2Cdc\3

 
Dourcompany\2Cdc\3Dcom,cn=nsPwPolicyContainer,cn=users,cn=subscribers,dc=ourcompany
 ,dc=com
cn: cn=nsPwTemplateEntry,cn=users,cn=subscribers,dc=ourcompany,dc=com

# entry-id: 17
dn: cn=nsPwPolicy_CoS,cn=users,cn=subscribers,dc=ourcompany,dc=com
objectClass: ldapsubentry
objectClass: cosSuperDefinition
objectClass: cosPointerDefinition
objectClass: top
costemplatedn: 
cn=cn\3DnsPwTemplateEntry\2Ccn\3Dusers\2Ccn\3Dsubscribers\2Cdc\3Do

 
urcompany\2Cdc\3Dcom,cn=nsPwPolicyContainer,cn=users,cn=subscribers,dc=ourcompany,d
 c=com
cosAttribute: pwdpolicysubentry default operational-default
cn: nsPwPolicy_CoS

# entry-id: 18
dn: uid=testuser,cn=users,cn=subscribers,dc=ourcompany,dc=com
givenName: U-da-man
uidNumber: 501
gidNumber: 501
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: account
objectClass: radiusprofile
uid: testuser
userPassword: {SSHA}HBk8h1pkgsUocxUgPF+HNeuHF1LgYaI99co6Aw==
radiusFramedMTU: 1400
radiusGroupName: local
radiusHuntgroupName: vpn.ourcompany.com 
radiusRealm: vpn.ourcompany.com 
radiusServiceType: Framed-User
radiusFilterId: std.ppp
passwordGraceUserTime: 0
dialupAccess: yes

There is also an attribute pwdpolicysubentry: 
cn=cn\3DnsPwPolicyEntry\2Ccn\3Dusers\2Ccn\3Daccounts\2Cdc\3Dourcompany\2Cdc\3Dcom,cn=nsPwPolicyContainer,cn=users,cn=accounts,dc=ourcompany,dc=com 

that shows up in the testuser's profile from the console that does not 
show up in the ldif dump.


Please help I have followed the documentation Redhat directory 8.2

thanks



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] replication between 1.2.2 and 1.2.6.1

[Nathan Kinder]

On 10/18/2010 07:36 AM, Robert Viduya wrote:
> A quick grep through the code shows that repl90consumer (a field of 
> Private_Repl_Protocol struct) is never initialized to zero.  Neither is field 
> repl71consumer, but field repl50consumer is initialized to zero in 
> Repl_5_Inc_Protocol_new.
>
Good catch.  Please open up a bug on this and I'll get it addressed.

-NGK
> On Oct 15, 2010, at 11:19 AM, Robert Viduya wrote:
>
>
>> On Oct 14, 2010, at 5:25 PM, Nathan Kinder wrote:
>>
>>  
>>> The 1.2.6.1 instance should detect that the 1.2.2 version does not support 
>>> the newer startReplication extop.  This detection is done by searching the 
>>> rootDSE of the receiving side to see if it advertises 
>>> 2.16.840.1.113730.3.5.12 as a supportedExtension.  The code is designed to 
>>> send the old style startReplication extop if it detects that the newer 
>>> style is not supported.
>>>
>>> I would like to see the rootDSE entry from the 1.2.2 system.
>>>
>> dn:
>> objectClass: top
>> namingContexts: dc=gted,dc=gatech,dc=edu
>> namingContexts: o=netscaperoot
>> supportedExtension: 2.16.840.1.113730.3.5.7
>> supportedExtension: 2.16.840.1.113730.3.5.8
>> supportedExtension: 2.16.840.1.113730.3.5.10
>> supportedExtension: 2.16.840.1.113730.3.5.3
>> supportedExtension: 2.16.840.1.113730.3.5.5
>> supportedExtension: 2.16.840.1.113730.3.5.6
>> supportedExtension: 2.16.840.1.113730.3.5.9
>> supportedExtension: 2.16.840.1.113730.3.5.4
>> supportedExtension: 1.3.6.1.4.1.1466.20037
>> supportedExtension: 1.3.6.1.4.1.4203.1.11.1
>> supportedControl: 2.16.840.1.113730.3.4.2
>> supportedControl: 2.16.840.1.113730.3.4.3
>> supportedControl: 2.16.840.1.113730.3.4.4
>> supportedControl: 2.16.840.1.113730.3.4.5
>> supportedControl: 1.2.840.113556.1.4.473
>> supportedControl: 2.16.840.1.113730.3.4.9
>> supportedControl: 2.16.840.1.113730.3.4.16
>> supportedControl: 2.16.840.1.113730.3.4.15
>> supportedControl: 2.16.840.1.113730.3.4.17
>> supportedControl: 2.16.840.1.113730.3.4.19
>> supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1
>> supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2
>> supportedControl: 1.2.840.113556.1.4.319
>> supportedControl: 1.3.6.1.4.1.4203.666.5.16
>> supportedControl: 2.16.840.1.113730.3.4.14
>> supportedControl: 2.16.840.1.113730.3.4.20
>> supportedControl: 1.3.6.1.4.1.1466.29539.12
>> supportedControl: 2.16.840.1.113730.3.4.12
>> supportedControl: 2.16.840.1.113730.3.4.18
>> supportedControl: 2.16.840.1.113730.3.4.13
>> supportedSASLMechanisms: EXTERNAL
>> supportedSASLMechanisms: LOGIN
>> supportedSASLMechanisms: DIGEST-MD5
>> supportedSASLMechanisms: PLAIN
>> supportedSASLMechanisms: ANONYMOUS
>> supportedSASLMechanisms: CRAM-MD5
>> supportedSASLMechanisms: GSSAPI
>> supportedLDAPVersion: 2
>> supportedLDAPVersion: 3
>> vendorName: 389 Project
>> vendorVersion: 389-Directory/1.2.2 B2009.237.2054
>> dataversion: 020101015151757020101015151757020101015151757020101015151757
>> netscapemdsuffix: cn=ldap://dc=stefan,dc=iam,dc=gatech,dc=edu:389
>>
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>  
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] replication between 1.2.2 and 1.2.6.1

[Nathan Kinder]

On 10/14/2010 01:34 PM, Robert Viduya wrote:
> Can we expect replication between 1.2.2 and 1.2.6.1 to work?  I'm trying to 
> set up MMR between two servers running the two different versions and the 
> 1.2.6.1 master is failing with the following message in it's errors log:
>
> [14/Oct/2010:16:26:19 -0400] NSMMReplicationPlugin - agmt="cn=people moulin 
> stefan" (stefan:636): Unable to parse the response to the startReplication 
> extended operation. Replication is aborting.
> [14/Oct/2010:16:26:19 -0400] NSMMReplicationPlugin - agmt="cn=people moulin 
> stefan" (stefan:636): Incremental update failed and requires administrator 
> action
>
> The corresponding messages in the 1.2.2 master's access file show:
>
> [14/Oct/2010:16:26:19 -0400] conn=139 fd=65 slot=65 SSL connection from 
> 130.207.183.16 to 130.207.183.14
> [14/Oct/2010:16:26:19 -0400] conn=139 op=0 BIND dn="cn=Replication 
> Manager,cn=config" method=128 version=3
> [14/Oct/2010:16:26:19 -0400] conn=139 op=0 RESULT err=0 tag=97 nentries=0 
> etime=0 dn="cn=replication manager,cn=config"
> [14/Oct/2010:16:26:19 -0400] conn=139 op=1 SRCH base="" scope=0 
> filter="(objectClass=*)" attrs="supportedControl supportedExtension"
> [14/Oct/2010:16:26:19 -0400] conn=139 op=1 RESULT err=0 tag=101 nentries=1 
> etime=0
> [14/Oct/2010:16:26:19 -0400] conn=139 op=2 SRCH base="" scope=0 
> filter="(objectClass=*)" attrs="supportedControl supportedExtension"
> [14/Oct/2010:16:26:19 -0400] conn=139 op=2 RESULT err=0 tag=101 nentries=1 
> etime=0
> [14/Oct/2010:16:26:19 -0400] conn=139 op=3 SRCH base="" scope=0 
> filter="(objectClass=*)" attrs="supportedControl supportedExtension"
> [14/Oct/2010:16:26:19 -0400] conn=139 op=3 RESULT err=0 tag=101 nentries=1 
> etime=0
> [14/Oct/2010:16:26:19 -0400] conn=139 op=4 EXT oid="2.16.840.1.113730.3.5.12"
> [14/Oct/2010:16:26:19 -0400] conn=139 op=4 RESULT err=2 tag=120 nentries=0 
> etime=0
> [14/Oct/2010:16:27:19 -0400] conn=139 op=5 UNBIND
> [14/Oct/2010:16:27:19 -0400] conn=139 op=5 fd=65 closed - U1
>
> I looked up oid 2.16.840.1.113730.3.5.12 and it's apparently new for hooking 
> plugins into the replication process.  I just skimmed the 1.2.6.1 source code 
> and it appears that there's logic to detect if the remote server supports it. 
>  Is that the intent and it's bugged or is replication between the two version 
> just not supposed to work?
>
The 1.2.6.1 instance should detect that the 1.2.2 version does not 
support the newer startReplication extop.  This detection is done by 
searching the rootDSE of the receiving side to see if it advertises 
2.16.840.1.113730.3.5.12 as a supportedExtension.  The code is designed 
to send the old style startReplication extop if it detects that the 
newer style is not supported.

I would like to see the rootDSE entry from the 1.2.2 system.

-NGK
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Syntax validation rejecting DirectoryStrings

[Nathan Kinder]

On 09/16/2010 11:21 AM, Edward Z. Yang wrote:
> Hello all,
>
> We are having some difficulties with the new syntax validation built in
> to LDAP.  Consider the following schema (formatted for
> readability):
>
> dn: cn=schema
> attributeTypes: ( 1.2.840.113554.4.2.1.1
>  NAME 'scriptsVhostName'
>  DESC 'Canonical server name'
>  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>  SINGLE-VALUE
>  X-ORIGIN 'scripts.mit.edu' )
> attributeTypes: ( 1.2.840.113554.4.2.1.2
>  NAME 'scriptsVhostAlias'
>  DESC 'Other server names'
>  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>  X-ORIGIN 'scripts.mit.edu' )
> attributeTypes: ( 1.2.840.113554.4.2.1.3
>  NAME 'scriptsVhostDirectory'
>  DESC 'Directory under $HOME/Scripts/$service for the root of this 
> service'
>  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>  SINGLE-VALUE
>  X-ORIGIN 'scripts.mit.edu' )
> attributeTypes: ( 1.2.840.113554.4.2.1.4
>  NAME 'scriptsVhostAccount'
>  DESC 'User account for finding home direcory and suexec uid/gid'
>  SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
>  SINGLE-VALUE
>  X-ORIGIN 'scripts.mit.edu' )
> objectClasses: ( 1.2.840.113554.4.2.2.1
>  NAME 'scriptsVhost'
>  DESC 'Configuration for a scripts virtual host'
>  SUP top
>  AUXILIARY
>  MUST ( scriptsVhostName $ scriptsVhostDirectory $ scriptsVhostAccount )
>  MAY ( scriptsVhostAlias )
>  X-ORIGIN 'scripts.mit.edu' )
>
> The syntax validation then rejects a directory entry of the following
> form.
>
> 0 
> scriptsVhostName=ezyang.scripts.mit.edu,ou=VirtualHosts,dc=scripts,dc=mit,dc=edu
> objectClass: scriptsVhost
> objectClass: top
> scriptsVhostName: ezyang.scripts.mit.edu
> scriptsVhostAlias: ezyang.scripts
> scriptsVhostAccount: uid=ezyang,ou=People,dc=scripts,dc=mit,dc=edu
> scriptsVhostDirectory:
>
> With the following error:
>
> [16/Sep/2010:14:19:39 -0400] syntax-plugin - Syntax validate task starting 
> (base: 
> "scriptsVhostName=ezyang.scripts.mit.edu,ou=VirtualHosts,dc=scripts,dc=mit,dc=edu",
>  filter: "(objectclass=*)") ...
> [16/Sep/2010:14:19:40 -0400] syntax-plugin - Entry 
> "scriptsVhostName=ezyang.scripts.mit.edu,ou=VirtualHosts,dc=scripts,dc=mit,dc=edu"
>  violates syntax.
> scriptsVhostDirectory: value #0 invalid per syntax
> [16/Sep/2010:14:19:41 -0400] syntax-plugin - Syntax validate task complete.  
> Found 1 invalid entries.
>
> It is difficult for me to tell what value #0 is referring to, but if it
> is scriptsVhostName, as far as I can tell it is a perfectly fine 
> DirectoryString.
> Is our schema wrong or is there a bug in the syntax validation?
>
It looks to me like your scriptsVhostDirectory attribute value is 
empty.  Per RFC 4517, a Directory String must consist of one or more 
UTF8 characters.  An empty value is invalid.

-NGK
> Cheers,
> Edward
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Password history limit reached--no longer able to set passwords?

[Nathan Kinder]

On 09/14/2010 02:00 PM, Nathan Kinder wrote:
> On 09/14/2010 12:41 PM, Rich Megginson wrote:
>
>> Brandon G wrote:
>>
>>  
>>> Nathan Kinder wrote:
>>>
>>>
>>>> On 09/01/2010 05:50 PM, brandon wrote:
>>>>
>>>>
>>>>  
>>>>> I am curious if anybody knows of a bug with the password history limit?
>>>>>
>>>>>
>>>>>
>>>>>
>>>> I am not aware of a bug like this.  What version of 389-ds-base are you
>>>> running?
>>>>
>>>>
>>>>  
>>> Versions:
>>>
>>> 389-ds-console-1.2.0-5
>>> 389-admin-1.1.9-1
>>> 389-admin-console-1.1.4-2
>>> 389-console-1.1.3-5
>>> 389-ds-base-1.2.3-1
>>> 389-admin-console-doc-1.1.4-2
>>> 389-adminutil-1.1.8-4
>>> 389-ds-console-doc-1.2.0-5
>>> 389-dsgw-1.1.4-1
>>> 389-ds-1.1.3-5
>>> RHEL 5.5
>>>
>>> We have one master and two replica's.
>>>
>>>
>> See if you get the problem with the newly released 389-ds-base 1.2.6 and
>> related packages.
>>
>>  
> There was a bug that I fixed a few months back that was related to
> password history.  I'll have to dig up the details.  It may very well
> fix this issue.
>
Here is the bug I was referring to.

https://bugzilla.redhat.com/show_bug.cgi?id=52
> -NGK
>
>>> -Brandon
>>> 
>>>
>>> --
>>> 389 users mailing list
>>> 389-users@lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>>
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>>  
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Password history limit reached--no longer able to set passwords?

[Nathan Kinder]

On 09/14/2010 12:41 PM, Rich Megginson wrote:
> Brandon G wrote:
>    
>> Nathan Kinder wrote:
>>  
>>> On 09/01/2010 05:50 PM, brandon wrote:
>>>
>>>
>>>> I am curious if anybody knows of a bug with the password history limit?
>>>>
>>>>
>>>>  
>>> I am not aware of a bug like this.  What version of 389-ds-base are you
>>> running?
>>>
>>>
>>
>> Versions:
>>
>> 389-ds-console-1.2.0-5
>> 389-admin-1.1.9-1
>> 389-admin-console-1.1.4-2
>> 389-console-1.1.3-5
>> 389-ds-base-1.2.3-1
>> 389-admin-console-doc-1.1.4-2
>> 389-adminutil-1.1.8-4
>> 389-ds-console-doc-1.2.0-5
>> 389-dsgw-1.1.4-1
>> 389-ds-1.1.3-5
>> RHEL 5.5
>>
>> We have one master and two replica's.
>>  
> See if you get the problem with the newly released 389-ds-base 1.2.6 and
> related packages.
>
There was a bug that I fixed a few months back that was related to 
password history.  I'll have to dig up the details.  It may very well 
fix this issue.

-NGK
>> -Brandon
>> 
>>
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>  
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Password history limit reached--no longer able to set passwords?

[Nathan Kinder]

On 09/01/2010 05:50 PM, brandon wrote:
> I am curious if anybody knows of a bug with the password history limit?
>
I am not aware of a bug like this.  What version of 389-ds-base are you 
running?
> I have the limit set to 20 passwords, and due to debugging I have cycled
> through 20 passwords.  From that point forward I cannot set any more
> passwords.  Regardless of what I put in it claims it is in the password
> history, which is not true since they are completely randomly generated
> passwords.
>
> If I disable password history checking in the policy, I can set my
> password again.
>
> -Brandon
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Announcing 389 Directory Server 1.2.6 Release Candidate 3

[Nathan Kinder]

On 07/19/2010 01:30 PM, Aaron Hagopian wrote:

I filed a bug per Rich: https://bugzilla.redhat.com/show_bug.cgi?id=616206

How did you create the ldif file in
"/var/lib/dirsrv/slapd-/ldif/"?  Did you move the ldif
file there from elsewhere on your system?  That could explain why
your ldif file has an incorrect context of "var_t".


Yes I moved the file there from another location.  I was just trying 
to see if there is some acceptable directory.
This explains it.  When you move a file, it's SELinux context is 
preserved (as opposed to copying, which creates a new file with the 
correct context for the target directory).



Try creating a new file in
"/var/lib/dirsrv/slapd-/ldif/" using 'touch', then run
'ls -lZ' to see what the SELinux context is on that new file.  It
should be "dirsrv_var_lib_t".


Yes creating a new file in that directory gets dirsrv_var_lib_t.  I 
did get it in once I was able to get my file to have that SELinux 
attribute.  The ldif file was created on my production server which is 
running 1.2.5.


I can't say I know that much about SELinux but I imagine this may 
become a problem for people upgrading to 1.2.6 who want to start 
fresh?  Maybe can the db2ldif.pl  utility add that 
SELinux attribute?  Although that seems like it would go against the 
point of SELinux if things can just add attributes as needed.  Does 
the file not have the attribute because it was created in 1.2.5 or was 
it because on my production machine, when I created the file (using 
db2ldif.pl ), I saved it to a directory other than 
the SELinux one?  It looks like when I run the db2ldif.pl 
 command on my 1.2.6 machine it does add some 
SELinux attributes.
This is a general problem for those new to SELinux.  A directory on the 
file-system has a default SELinux context that will be used when a file 
is created in it.  When you move a file from one location to another, 
it's previous SELinux context is preserved.  This can cause issues like 
what you've run into.  If you copy a file instead of moving it, the new 
file will have the appropriate context as defined by the policy for the 
target directory.


I think the main reason I don't use the 
/var/lib/dirsrv/slapd-/ldif/ file for my backups in the 
first place is because by default the "nobody" user cannot write to 
that directory.
The dirsrv SELinux is going make things like this more restrictive.  
It's one of those tradeoffs for being able to confine ns-slapd.


-NGK




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Announcing 389 Directory Server 1.2.6 Release Candidate 3

[Nathan Kinder]

On 07/15/2010 09:12 AM, Aaron Hagopian wrote:
I upgraded my fedora 13 x86_64 machine to the RC3 using the rpms in 
updates-testing and now I cannot start the admin server with selinux 
enabled.  I am attaching the selinux message.  It does start when I 
disable selinux.

What version of 389-admin are you running?

I'd also like to see the output of 'semodule -l | grep 389' from your 
system.


-NGK



On Tue, Jul 6, 2010 at 2:38 PM, Rich Megginson > wrote:


The 389 team is pleased to announce the availability of Release
Candidate 3 of version 1.2.6.  This release has a few bug fixes.

***We need your help!  Please help us test this software.***  It is a
release candidate, so it may have a few glitches, but it has been
tested
for regressions and for new feature bugs.  The Fedora system
strongly encourages packages to be in Testing until verified and
pushed
to Stable.  If we don't get any feedback while the packages are in
Testing, the packages will remain in limbo, or get pushed to Stable.

The more testing we get, the faster we can release these packages to
Stable.  See the Release Notes for information about how to provide
testing feedback (or just send an email to
389-users@lists.fedoraproject.org
).

The packages that need testing are:
* 389-ds-base-1.2.6.rc3 - 389-ds-base

More information
* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download

=== Bugs Fixed ===
This release contains a couple of bug fixes.  The complete list of
bugs
fixed is found at the link below.  Note that bugs marked as MODIFIED
have been fixed but are still in testing.
* Tracking bug for 1.2.6 release -
https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0


**  Bug 606920 - anonymous resource limit - nstimelimit - also applied
to "cn=directory manager"
** Bug 604453 - SASL Stress and Server crash: Program quits with the
assertion failure in PR_Poll
** Bug 605827 - In-place upgrade: upgrade dn format should not run in
setup-ds-admin.pl 
** Bug 578296 - Attribute type entrydn needs to be added when subtree
rename switch is on
** Bug 609256 - Selinux: pwdhash fails if called via Admin Server CGI
** Bug 603942 - null deref in _ger_parse_control() for subjectdn

--
389 users mailing list
389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] dynamic group expansion: summarizing ;)

[Nathan Kinder]

On 05/31/2010 02:05 AM, Roberto Polli wrote:
> Hi all,
>
> I'll try to summarize:
> 1 - we like dynamic group expansion (memberURL is an ldap URI)
> 2 - ldapsearch -b GROUPDN "uniqueMember=*" retrieves both static and dynamic
> members
>2.1- the forementioned search should retrieve nested group members too
> 3 - (wish) memberOf plugin should dynamically set the memberOf attribute in
> underlying entries
>3.1 * if memberOf is a virtual attribute, it's impossible to use it in
> Searches (eg this won't work #ldapsearch "memberof=GROUPDN" )
>3.2 * memberOf should be "real"
>3.3 * we need a listener on each Update to
>  3.3.1 * rescan all groups
>  3.3.2 * update the memberOf attribute
>
There are likely some things you can do here to optimize for updates.  
One idea would be to maintain an in-memory cache of dynamic group 
filters that are present.  You would have to scan for these groups at 
server startup to populate the cache and maintain it whenever a group 
filter is modified/added/deleted.

When an entry is updated, you can use the group filter cache to quickly 
determine if a change to an entry affects it's group membership instead 
of searching for all of the groups each time.

There may be better ideas than the above, but the cache idea was just a 
quick thought that may help.
> my opinion:
>   - the dynamic memberOf plugin adds a lot of overhead on Update (that's no
> good)
>
It is true that this adds overhead when an update to grouping is made, 
but that is much better than taking a hit at search time as you would 
with a dynamic attribute.  The assumption made in a case like this is 
that a search for group membership happens much more often than an 
update to group membership.  We want to optimize for the more common case.
>   - its complexity grows with #groups and #users, so should be limited in some
> ways
>
Nested groups also add quite a bit of complexity if you want to support 
them.  The memberOf plug-in already deals with nested groups.  We 
decided to not add any sort of limiting based off of number of 
users/groups when writing the memberOf plug-in.
>   - 2 is a priority as that ldapsearch is expected to retrieve all group
> members
>
> another interesting thread is about group naming.
> in the sun mailgroup objectclass you can set an email address as a group name
> (eg. groups are mailinglist, with static or dynamic members).
>
> LetMeKnow+Peace,
> R.
>
>
> On Tuesday 18 May 2010 19:40:08 Rich Megginson wrote:
>
>> Nathan Kinder wrote:
>>  
>>> On 05/18/2010 09:50 AM, Rich Megginson wrote:
>>>
>>>> Nathan Kinder wrote:
>>>>  
>>>>> On 05/18/2010 08:48 AM, Rich Megginson wrote:
>>>>>
>>>>>> Roberto Polli wrote:
>>>>>>  
>>>>>>> On Tuesday 18 May 2010 16:28:48 Rich Megginson wrote:
>>>>>>>
>>>>>>>> ...I would start with the member of plugin code.
>>>>>>>>  
>>>>>>> I'll take a look.
>>>>>>>
>>>>>>> do you think it will be better to extend memberof plugin or play
>>>>>>> directly into the group entry
>>>>>>>
>>>>>> not sure what you mean by "play directly into the group entry"
>>>>>>
>>>>>> You might be able to do this by extending the member of plugin.  With
>>>>>> dynamic groups, you will probably still want to have the member of
>>>>>> functionality, and it should work with member of when using static
>>>>>> groups too.
>>>>>>  
>>>>> The difficult part is going to be making the memberOf plug-in work with
>>>>> dynamic groups.
>>>>>
>>>>> Is the idea to have the "member" attributes be virtual attributes that
>>>>> are generated on the fly when a client performs a search for the group?
>>>>>
>>>> That might work, as long as you don't have to support searches in
>>>> dynamic group entries like (member=someUserDN)
>>>>
>>>>  
>>>>> I'm not quite sure how this approach can be made to work with the
>>>>> memberOf plug-in since it is triggered by write operations that affect
>>>>> group membership.
>>>>>
>>>> However it works, it should work with memberof and generate memberof
>>&

Re: [389-users] Logfile buffering

[Nathan Kinder]

On 05/19/2010 01:39 PM, Roland Schwingel wrote:


Hi

One last question before switching of my machine...
Is it possible that the dirsrv logfiles (access, error etc.) are 
written to disk with activated buffering?


When I do a tail -f on these logfiles I see a big delay in output. 
When I do eg. an ldapsearch from
a client the result appears immediately at the client, but it takes 
about 10 to 15 seconds until the tail -f
shows the search (or whatever I do). This is a bit inconvenient when 
debugging things.


Does this happen only to me or is this generally the case? Can this be 
switched off/changed?
The access log output is buffered by default.  You can turn this off by 
setting the "nsslapd-accesslog-logbuffering" attribute to "off" in the 
"cn=config" entry.


The errors log is not buffered.

-NGK


Thanks for your help,

Roland


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] dynamic group expansion: writing a patch...

[Nathan Kinder]

On 05/18/2010 09:50 AM, Rich Megginson wrote:
> Nathan Kinder wrote:
>
>> On 05/18/2010 08:48 AM, Rich Megginson wrote:
>>
>>  
>>> Roberto Polli wrote:
>>>
>>>
>>>
>>>> On Tuesday 18 May 2010 16:28:48 Rich Megginson wrote:
>>>>
>>>>
>>>>
>>>>  
>>>>> ...I would start with the member of plugin code.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> I'll take a look.
>>>>
>>>> do you think it will be better to extend memberof plugin or play directly 
>>>> into
>>>> the group entry
>>>>
>>>>
>>>>
>>>>  
>>> not sure what you mean by "play directly into the group entry"
>>>
>>> You might be able to do this by extending the member of plugin.  With
>>> dynamic groups, you will probably still want to have the member of
>>> functionality, and it should work with member of when using static
>>> groups too.
>>>
>>>
>>>
>> The difficult part is going to be making the memberOf plug-in work with
>> dynamic groups.
>>
>> Is the idea to have the "member" attributes be virtual attributes that
>> are generated on the fly when a client performs a search for the group?
>>
>>  
> That might work, as long as you don't have to support searches in
> dynamic group entries like (member=someUserDN)
>
>> I'm not quite sure how this approach can be made to work with the
>> memberOf plug-in since it is triggered by write operations that affect
>> group membership.
>>
>>  
> However it works, it should work with memberof and generate memberof
> attributes in user entries, whether the group is static or dynamic.
>
> I suppose it would work a little like persistent search - on every
> update operation (not just group updates, but all updates), it would
> have to scan every dynamic group entry, looking at the pre-update entry
> and the post-update entry.  If the pre-update entry does not match the
> dynamic group definition, but the post-update entry does match the
> dynamic group definition, then you add the DN of that entry to the
> member attribute in the group entry.  If the pre-update matches but not
> the post-update, you have to remove the member.
>
I think this approach is best, assuming you are saying that the member 
of value is actually added to the group entry (not a virtual 
attribute).  This could be implemented as a new post-op plug-in.  If 
plug-in ordering is used to have this new plug-in invoked before the 
memberOf plug-in, then the memberOf feature should work fine.
>>> static group:
>>> cn=groupA,
>>> objectclass: groupOfNames
>>> member: uid=foo,...<- static member - must add/delete manually
>>> member: uid=bar,...<- static member - must add/delete manually
>>>
>>> dynamic group:
>>> cn=groupB,...
>>> objectclass: groupOfDynNames<- need new objectclass that has both url
>>> specifier attribute and member attribute
>>> memberURL: ldap:///ou=people?sub?(ou=myorg)<- specifies which entries
>>> are members
>>> member: uid=foo,...<- dynamic member - plugin adds this
>>> member: uid=bar,...<- dynamic member - plugin adds this
>>>
>>> uid=foo,ou=people,...
>>> ou: myorg
>>> memberof: cn=groupA,<- plugin adds this
>>> memberof: cn=groupB,<- plugin adds this
>>>
>>>
>>>
>>>> thx+Peace,
>>>> R.
>>>>
>>>>
>>>>
>>>>
>>>>  
>>> --
>>> 389 users mailing list
>>> 389-users@lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>>
>>>
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>>  
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] dynamic group expansion: writing a patch...

[Nathan Kinder]

On 05/18/2010 08:48 AM, Rich Megginson wrote:
> Roberto Polli wrote:
>
>> On Tuesday 18 May 2010 16:28:48 Rich Megginson wrote:
>>
>>  
>>> ...I would start with the member of plugin code.
>>>
>>>
>> I'll take a look.
>>
>> do you think it will be better to extend memberof plugin or play directly 
>> into
>> the group entry
>>
>>  
> not sure what you mean by "play directly into the group entry"
>
> You might be able to do this by extending the member of plugin.  With
> dynamic groups, you will probably still want to have the member of
> functionality, and it should work with member of when using static
> groups too.
>
The difficult part is going to be making the memberOf plug-in work with 
dynamic groups.

Is the idea to have the "member" attributes be virtual attributes that 
are generated on the fly when a client performs a search for the group?  
I'm not quite sure how this approach can be made to work with the 
memberOf plug-in since it is triggered by write operations that affect 
group membership.
> static group:
> cn=groupA,
> objectclass: groupOfNames
> member: uid=foo,...<- static member - must add/delete manually
> member: uid=bar,...<- static member - must add/delete manually
>
> dynamic group:
> cn=groupB,...
> objectclass: groupOfDynNames<- need new objectclass that has both url
> specifier attribute and member attribute
> memberURL: ldap:///ou=people?sub?(ou=myorg)<- specifies which entries
> are members
> member: uid=foo,...<- dynamic member - plugin adds this
> member: uid=bar,...<- dynamic member - plugin adds this
>
> uid=foo,ou=people,...
> ou: myorg
> memberof: cn=groupA,<- plugin adds this
> memberof: cn=groupB,<- plugin adds this
>
>> thx+Peace,
>> R.
>>
>>
>>  
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] is anybody having problems with latest selinux policy update in F12?

[Nathan Kinder]

On 03/03/2010 07:44 AM, me wrote:
> hi Rich
> do you know why it all broke so suddenly with latest update for base policy?
>
As Rich said, it was a miscommunication between the 389 and SELinux dev 
teams.  We have a 389 specific SELinux policy module that was recently 
developed but is not released yet.  It will be in 389 1.2.6.  This 
policy will confine the ns-slapd daemon to the dirsrv_t domain.

A change was made to the base selinux policy to confine 389 to the 
slapd_t domain, which is the policy used for OpenLDAP.  This does not 
just work with 389 since different paths are used (among other things).  
This change was backed out of the selinux-policy package at my request.  
This should be fixed in selinux-policy-3.6.32-92, which is currently in 
the testing repo.  Please see this comment in the bug where this change 
was made:

 https://bugzilla.redhat.com/show_bug.cgi?id=559298#c28

I would encourage you to test the fixed selinux-policy package and 
provide feedback as requested in the bug.

Thanks,
-NGK
> for some users it could be kind of a disaster, if now base policy is
> lacking rules for 389
> then some other dependencies, like ones you said of, should be pulled in
> automatically
> for me it looked like that, everything just crashed, like if there was
> no major part
> of 389's things in base selinux policy.
> I've just yumed 389-ds and no extra deps were looked for with regards to
> selinux
> tracking seliunx events and rendering custom module for inevitable
> I guess lots of people on F12 were having lots of problems today
> cheers
>
> On 03/03/2010 03:07 PM, Rich Megginson wrote:
>
>> me wrote:
>>
>>  
>>> regards
>>>
>>>
>>>
>> 389-ds-base 1.2.6.a2 has a selinux sub-package - 389-ds-base-selinux -
>> and 389-admin-1.1.11.a2 also - 389-admin-selinux - these are currently
>> in the testing repos - yum install/upgrade --enablerepo=updates-testing
>> 389-ds-base-selinux 389-admin-selinux
>> Not sure if these packages have hit all of the mirrors yet, but if they
>> have, try them out (and give us some feedback!)
>>
>>  
>>> --
>>> 389 users mailing list
>>> 389-users@lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>>
>>>
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>>  
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Last problem before migrating from tivoli to 389 ldap

[Nathan Kinder]

On 02/18/2010 05:51 AM, serge.ste...@fmsb.be wrote:

attributeTypes: (
  1.3.6.1.4.1..2.8
  NAME 'birthdate'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
  SINGLE-VALUE
  )
this is derived from a custom schema found in the ibm ldap
or ibm ldap is currently in lenian mode (a big shit) it accept
data even if the syntax is not correct
i have looked the syntax   SYNTAX 1.3.6.1.4.1.1466.115.121.1.24  is a 
time generalized attribute
so it must be encoded in numbre of second since  a referenc date thx 
to point me that this attribute

was imported from our ibm ldap schema.
Please see RFC 4517 for details on the Generalized Time syntax.  It is 
not the number of seconds since the epoch.  Here are some examples of 
valid values from the RFC:


199412161032Z
199412160532-0500

It looks like you are just missing the g-time-zone portion of the 
value.  Either add a "Z" at the end or use an offset as described in the 
g-differential definition in the RFC.


-NGK



Serge Sterck
Chef de service informatique adjoint
Tel : (02) 506.97.15
Email: serge.ste...@fmsb.be serge.ste...@gmail.com

-389-users-boun...@lists.fedoraproject.org a écrit : -

A : "General discussion list for the 389 Directory server
project." <389-users@lists.fedoraproject.org>
De : Nathan Kinder 
Envoyé par : 389-users-boun...@lists.fedoraproject.org
Date : 17/02/2010 22:51
Objet : Re: [389-users] Last problem before migrating from tivoli
to 389 ldap

On 02/17/2010 01:36 PM, serge.ste...@fmsb.be wrote:

I still have one problem that prevent me to migrate from tivoli
to 389 ldap
i have a problem with the birthdate attribute. I have encoded
this in a ldif
with the format MMJJHHMMSS but it refuse my question is
what is the format that i must use, must i encode this in base64
like the trick to set a attribute with a value a space
Thx for the reply guys

What error do you get?  I don't see a "birthdate" attribute in the
default schema, so you may need to create some custom schema if
you must have that attribute.


#!ERROR [LDAP: error code 21 - birthdate: value #0 invalid per
syntax ]
dn: uid=f704,ou=users,dc=fmsb,dc=be
objectClass: FMSBPerson
objectClass: posixAccount
objectClass: extensibleObject
objectClass: top
objectClass: ePerson
applicationprofile: RemoteHomeDirectoryModel=Fedora-Core-6
applicationprofile:
X3270Profile=sessions:{a,b,c,d,e};a:{keyboard=encodage|c
 odering(mouse),host=fmsbo390.fmsb.be,type=CICS};b:{keyboard=encodage|coderi
 ng(mouse),host=fmsbo390.fmsb.be,type=CICS};c:{keyboard=encodage|codering(mo
 use),host=fmsbo390.fmsb.be,type=CICS};d:{keyboard=encodage|codering(mouse),
 host=fmsbo390.fmsb.be,type=CICS};e:{keyboard=encodage|codering(mouse),host=
 fmsbo390.fmsb.be,type=EOS}
applicationprofile: internet=,ctx
birthdate: 1955072400
cn:: SmVhbi1NYXJpZSBHcsOpZ29pcmU=
description:: SmVhbiBNYXJpZSBHcsOpZ29pcmU=
employeenumber: 0704
firstname: Jean-Marie
gidnumber: 501
homeDirectory: /home/f704
lastname:: R3LDqWdvaXJl
loginShell: /bin/bash
mail: mailareenco...@fmsb.be
o: 306000
preferredLanguage: FR
telephonenumber: 9806
uid: f704
uidNumber: 1704
userPassword:: ZGViaQ==


Serge Sterck
Chef de service informatique adjoint
Tel : (02) 506.97.15
Email: serge.ste...@fmsb.be serge.ste...@gmail.com
//

/
«Ceci est un courrier électronique à caractère professionnel. Le
présent message comporte une information confidentielle à
l'attention exclusive de la personne ou de l'entité à qui il est
adressé ainsi que des autres destinataires autorisés à le
recevoir. Si vous n'êtes pas le destinataire désigné ou autorisé,
il vous est signifié que toute divulgation, copie, distribution
ou utilisation de cette information est strictement interdite et
peut être illégale. L'expéditeur ne peut être tenu pour
responsable en cas de transmission incorrecte ou incomplète de
l'information contenue dans le message ou en cas de retard dans
sa réception. Nous déclinons toute responsabilité pour toute
perte ou dommage causé par des virus.»

«Dit is een professionele e-mail. De informatie in dit bericht is
vertrouwelijk en uitsluitend bestemd voor de persoon of entiteit
aan wie het bericht is verzonden en anderen die gerechtigd zijn
dit bericht te ontvangen. Indien u niet de geadresseerde of een
gerechtigde bent, wordt u hierbij op gewezen dat het openbaar
maken, kopiëren, verspreiden of gebruik maken ervan, verboden is
en illegaal kan zijn. De verzender kan niet aansprakelijk worden
geacht voor een onjuiste of onvolledige overbrenging van de
inhoud van dit verzonden bericht, noch voor ni

Re: [389-users] Last problem before migrating from tivoli to 389 ldap

[Nathan Kinder]

On 02/17/2010 01:36 PM, serge.ste...@fmsb.be wrote:
I still have one problem that prevent me to migrate from tivoli to 389 
ldap
i have a problem with the birthdate attribute. I have encoded this in 
a ldif

with the format MMJJHHMMSS but it refuse my question is
what is the format that i must use, must i encode this in base64
like the trick to set a attribute with a value a space
Thx for the reply guys
What error do you get?  I don't see a "birthdate" attribute in the 
default schema, so you may need to create some custom schema if you must 
have that attribute.


#!ERROR [LDAP: error code 21 - birthdate: value #0 invalid per syntax ]
dn: uid=f704,ou=users,dc=fmsb,dc=be
objectClass: FMSBPerson
objectClass: posixAccount
objectClass: extensibleObject
objectClass: top
objectClass: ePerson
applicationprofile: RemoteHomeDirectoryModel=Fedora-Core-6
applicationprofile: 
X3270Profile=sessions:{a,b,c,d,e};a:{keyboard=encodage|c

 odering(mouse),host=fmsbo390.fmsb.be,type=CICS};b:{keyboard=encodage|coderi
 ng(mouse),host=fmsbo390.fmsb.be,type=CICS};c:{keyboard=encodage|codering(mo
 use),host=fmsbo390.fmsb.be,type=CICS};d:{keyboard=encodage|codering(mouse),
 host=fmsbo390.fmsb.be,type=CICS};e:{keyboard=encodage|codering(mouse),host=
 fmsbo390.fmsb.be,type=EOS}
applicationprofile: internet=,ctx
birthdate: 1955072400
cn:: SmVhbi1NYXJpZSBHcsOpZ29pcmU=
description:: SmVhbiBNYXJpZSBHcsOpZ29pcmU=
employeenumber: 0704
firstname: Jean-Marie
gidnumber: 501
homeDirectory: /home/f704
lastname:: R3LDqWdvaXJl
loginShell: /bin/bash
mail: mailareenco...@fmsb.be
o: 306000
preferredLanguage: FR
telephonenumber: 9806
uid: f704
uidNumber: 1704
userPassword:: ZGViaQ==


Serge Sterck
Chef de service informatique adjoint
Tel : (02) 506.97.15
Email: serge.ste...@fmsb.be serge.ste...@gmail.com
//

/
«Ceci est un courrier électronique à caractère professionnel. Le 
présent message comporte une information confidentielle à l'attention 
exclusive de la personne ou de l'entité à qui il est adressé ainsi que 
des autres destinataires autorisés à le recevoir. Si vous n'êtes pas 
le destinataire désigné ou autorisé, il vous est signifié que toute 
divulgation, copie, distribution ou utilisation de cette information 
est strictement interdite et peut être illégale. L'expéditeur ne peut 
être tenu pour responsable en cas de transmission incorrecte ou 
incomplète de l'information contenue dans le message ou en cas de 
retard dans sa réception. Nous déclinons toute responsabilité pour 
toute perte ou dommage causé par des virus.»


«Dit is een professionele e-mail. De informatie in dit bericht is 
vertrouwelijk en uitsluitend bestemd voor de persoon of entiteit aan 
wie het bericht is verzonden en anderen die gerechtigd zijn dit 
bericht te ontvangen. Indien u niet de geadresseerde of een 
gerechtigde bent, wordt u hierbij op gewezen dat het openbaar maken, 
kopiëren, verspreiden of gebruik maken ervan, verboden is en illegaal 
kan zijn. De verzender kan niet aansprakelijk worden geacht voor een 
onjuiste of onvolledige overbrenging van de inhoud van dit verzonden 
bericht, noch voor niet tijdige ontvangst ervan. We wijzen elke 
aansprakelijkheid af voor elk verlies of schade door software virussen 
veroorzaakt.»

/

/
///


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Help with setiting up Password Policy and SSL/TLS

[Nathan Kinder]

On 01/14/2010 10:56 AM, Fulda, Paul R (IS) wrote:


Hi,

I am trying to configure the Password Policy for my users and read 
that you would not be able to use the Policy unless you set up SSL/TLS.


Where did you read this?  SSL/TLS is not required to use the password 
policy features.


I am using 389 Server version 1.2.2.   Also I am running the Server on 
Fedora 11 64 bit.  All clients are also Fedora 11 64 bit.


I followed the instructions in setting up SSL here  at 
_http://directory.fedoraproject.org/wiki/Howto:SSL_


I ran the setupssl2.sh script and it completed with no errors.  In the 
389 Admin Console I could see the certificates for both the Admin 
Server and DS Server in the


Manage Certificates screens.

Also, I do not want to use SSL for the Admin Server or the Admin 
Console.  I just want to be able to use it for user authentication so 
the Password Policy works.


Bottom line is that I cannot get both features (Password Policies and 
SSL) working.  Any help would be greatly appreciated.


Up to this point here are my questions:

1) In the Directory Server GUI from the 389 Admin Console what 
certificate do I use to populate the Certificate field in the 
Encryption Tab?


There are 3 choices it provides after running the
sslsetup2.sh script which are CA Certificate, server-cert,
and server-Cert.


The one named "Server-Cert" should be used for the Directory Server.


2) In the Client Authentication Block in the same Encryption Tab  as 
#1 above, I have selected "Require client authentication".  Is this 
correct?


Is this how you force the Directory Server to use only
port 636 for secure communications?  If not, how do you do
that?

No.  Client authentication refers to using a client certificate to 
authenticate as opposed to a bind DN and password.  You most likely 
don't want to do this.  If you truly want to only use port 636, you can 
set nsslapd-listenport to "0", but all of your clients will be required 
to use LDAPS over port 636.  You should be really sure that this is what 
you want.


3) What are the differences between /etc/openldap/ldap.conf   and   
/etc/ldap.conf?  What are the client configurations needed to make 
this work?


/etc/openldap/ldap.conf is the OpenLDAP client config file.  
/etc/ldap.conf is the config file for nss_ldap and pam_ldap.


The only ldap.conf file that
_http://directory.fedoraproject.org/wiki/Howto:SSL_ talks
about configuring is the /etc/openldap/ldap.conf file.

My /etc/openldap/ldap.conf file looks like this:

URI ldap://hadmina.eidev.ngc.com/

BASE dc=eidev, dc=ngc, dc=com

TLS_CACERT /etc/openldap/cacerts

TLS_REQCERT allow

4) How do you get the certificate on the client machines?  What I did 
was copy from the server the cacert.asc file that is located in 
/etc/dirsrv/slapd-hadmina


to the client machine in /etc/openldap/cacerts directory. 
Is this correct?


Thanks and I hope there is someone out there that can help me get this 
working!


Paul


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users