On redhat/centos like systems you can install the openssh-ldap package so no
On Mon 25/03/13 1:20 PM , Vesa Alho listat(a)alho.fi sent:
> I think 389 side is "easy", but how about openssh-server and/or
> clients? Wondering do I need to patch openssh-server to get it working or is
> there an easier way.
> PS. thanks for responding!
> On 03/25/2013 03:09 PM, s.oreilly wrote:
> > I have just done this. I will see if I can find
> the docs.>
> > You need to add an objectclass (ldappublickey)
> and an attribute (sshpublickey) to> the schema.
> > Regards
> > Sean O'Reilly
> > On Mon 25/03/13 1:02 PM , Vesa Alho listat(a)alho.fi
> sent:>> Hi,
> >> What would it take to store SSH public keys
> in 389?>>
> >> I found this old thread in archives, but
> mentioned link doesn't work:>>
Other googling revealed guides which seem to
> require patched version of>> openssh-server and openldap
> >> I guess freeipa would support this, but any
> chance with only 389?>>
> >> -Mr. Vesa Alho
> >> --
> >> 389 users mailing list
> > --
> > 389 users mailing list
> > 389-users(a)lists.fedoraproject.org>
> 389 users mailing list
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
//*[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
*//[22/Mar/2013:09:54:37 +0800] roles-plugin - --> roles_post_op//
//[22/Mar/2013:09:54:37 +0800] roles-plugin - -->
//[22/Mar/2013:09:54:37 +0800] roles-plugin - <-- roles_post_op/
We've tried indexing the uidNumber and employeeNumber attributes as
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
Phone: +86 10 8587 7441
Mobile: +86 138 1089 8314
Logo MCON China Ltd.
Suite 1202, e-Tower
12C Guanghua Road
Beijing 100020 *??????**?**? ??**?**(**? ?**)**????**
Member of mcon group: Australia . Austria . China . Czech Republic .
Germany . India . Japan . Malaysia . Russia . South Korea . Switzerland
I have just done this. I will see if I can find the docs.
You need to add an objectclass (ldappublickey) and an attribute (sshpublickey) to
On Mon 25/03/13 1:02 PM , Vesa Alho listat(a)alho.fi sent:
> What would it take to store SSH public keys in 389?
> I found this old thread in archives, but mentioned link doesn't work:
> Other googling revealed guides which seem to require patched version of
> openssh-server and openldap guides.
> I guess freeipa would support this, but any chance with only 389?
> -Mr. Vesa Alho
> 389 users mailing list
What would it take to store SSH public keys in 389?
I found this old thread in archives, but mentioned link doesn't work:
Other googling revealed guides which seem to require patched version of
openssh-server and openldap guides.
I guess freeipa would support this, but any chance with only 389?
-Mr. Vesa Alho
We've standardized on CentOS Directory our ~30,000 user directory environment. It's a 6 servers total: two multi-master, two read-only consumers with a full replication agreement and two read-only consumers with a partial replication.
We have a specific problem that we were *sure* was fixed in CentOS directory 8.2.8. It was not and now we're wondering if we'd be better off on 389 or Redhat Directory since we'd at least have reliable changelogs with the former and support to call for the latter.
Here's the problem, in the master error logs:
[19/Mar/2013:17:59:49 -0400] NSMMReplicationPlugin - agmt="cn=ldapm01-mgmt to ds01-mgmt" (ds01-mgmt:636): Failed to send update operation to consumer (uniqueid c3230b03-18e411e2-af56b819-045c296a, CSN 5148b7cd000100010000): Bad parameter to an ldap routine. Will retry later.
[19/Mar/2013:17:59:49 -0400] NSMMReplicationPlugin - agmt="cn=ldapm01-mgmt to ds02-mgmt" (ds02-mgmt:636): Failed to send update operation to consumer (uniqueid c3230b03-18e411e2-af56b819-045c296a, CSN 5148b7cd000100010000): Bad parameter to an ldap routine. Will retry later.
It repeats once every few seconds. Reinitializing replication solves it for a while, maybe an hour and then it re-occurs.
Recently we've started seeing this:
[21/Mar/2013:15:00:01 -0400] NSMMReplicationPlugin - agmt="cn=ldapm01-mgmt to ds01-mgmt" (ds01-mgmt:636): Unable to acquire replica: there is no replicated area "dc=philasd,dc=org" on the consumer server. Replication is aborting.
deleting the host as a replica and re-adding it solves it but it shouldn't be happening.
They were Sun Directory customers going to back to 5.2 so this product is comfortable for them but with the pain we've been feeling as we roll it into production we're trying to decide if we should consider alternatives.
Does anyone have insight on the problem above or on whether it's best to stick with CentOS, switch to Redhat or 389?
They're heavy users of open source and happy to self support. If Redhat support for directory is good they'd be happy to go that direction.
I have run into a bug that is still open several times now causing large
problems in our LDAP Service. https://fedorahosted.org/389/ticket/346
We have group updates that are very large in size (20k+ records) and while
we're specifically targeting the engineering group responsible, there is
nothing to stop another group to write bad code and abuse our service.
When the large update occurs during replication of the group from our
master to our search fleet we often miss SLAs on replication and search
latency because the boxes go under such heavy load.
Is there a way on our master servers we can block people from preforming
such updates? Either to discard and error on the write or just drop that
traffic all together. I'm open to any sort of suggestion this list might
have to offer.
Not sure if this is the right forum to ask about RHDS vs 389DS, but....
I am currently using RHDS 8.2 and am looking to deploy 9.0 (master, hub, and consumer). Will I be able to replication between an 8.2 master and a 9.0 master?
I have looked in the Administration Guide on Rhed hat Customer Portal and only see references to RHDS 4.x (scratching my head why am I seeing references to 4.x and not anything related to 8.x.).
Paul M. Whitney
Paul M. Whitney
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.
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 -> <My plugin>
User creation statements
mepManagedEntry: cn=Pappu Group
dn: cn=Posix User-Group,cn=Managed Entries,cn=plugins,cn=config
cn: Posix User-Group
managedTemplate: cn=Posix User-Group Template,ou=Templates,dc=ma,dc=net
dn: cn=Posix User-Group Template, ou=Templates,dc=ma,dc=net
cn: Posix User-Group Template
mepStaticAttr: objectclass: posixGroup
mepMappedAttr: cn: $cn Group Entry
mepMappedAttr: gidNumber: $gidNumber
mepMappedAttr: memberUid: $uid
Am I correct in my understanding that I cannot sync OU's from Active Directory to
I am trying to sync users fro an AD server that I do not control and most of the
users are separated in to different OU's
Is there any way of making this work?
I need help implementing a client-server SSL connection. I've been researching on the web and I have no idea how to get my Java application to talk to the 389DS securely. I have been looking into keytool and JSSE, but there is no clear cut explanation on how it should be done. I have a self-signed CA certificate that I created using certutil, and then a server certificate generated from that self-signed CA. Is there anyone who knows a path to a solution?