RE: Using Penrose (or similar software) to solve our LDAP needs

We are actually going through what you're going through right now, only
inverted. We have been using Sun's directory server for years, well
deployed throughout our organization and are just getting ready to deploy
AD. Since AD uses some attributes that are proprietary to AD (for example
the password field for an AD user is the unicodePwd attribute of an object,
whereas on any other ldap v2 and v3 directory server I've used a users'
password is stored in the objects userPassword attribute. There are other
examples of AD storing attributes in non-standard places as well. Also, as
you know, AD is not posix aware, meaning you either won't be able to
synchronize those attributes to whatever directory server you use, or you'll
be using your own attributes on the AD side of the house to populate the
posix attributes. Because of this, we are not trying to replicate all
attributes that a object has in our directory server to AD, but rather just
enough to make AD useful, which for us is essentially user authentication to
windows workstations and windows servers. Were using a tool called adtool
to populate and synchronize our ldap environment to AD (which means that if
you're going to synchronize passwords, you'll need to enable SSL on your
domain controllers). Since we are managing the replication, we control
exactly what is and isn't replicated from ldap to AD. Hope that helps.


-----Original Message-----
From: redhat-list-bounces@xxxxxxxxxx [mailto:redhat-list-bounces@xxxxxxxxxx]
On Behalf Of Kenneth Holter
Sent: Tuesday, November 11, 2008 5:16 AM
To: redhat-list@xxxxxxxxxx
Subject: Using Penrose (or similar software) to solve our LDAP needs

Hello list.

We've been trying to deploy Red Hat Directory Server (RHDS) in our
organization, but are not so sure it's integration with Active Directory
(AD) suits our needs. Let me briefly outline our situation:

AD is well deployed within our organization, but we're in need of a
directory server for our Red Hat Linux servers. The directory server should
first and foremost allow for user authentication when connecting through
SSH, but other applications will also be integrated with the directory
server. The AD admins is not very keen on us Linux admins modifying or
installing applications on their AD boxes, so a directory server deployment
should take this into account. Also, we *probably* don't need to sync
passwords. Lastly, our linux directory server will be synced to a dedicated
"linux OU" on the AD side.

We've played around with RHDS for a while, but the integration with AD
(using Windows Sync) doesn't seem to meet our requirements. For example,
since attributes such as posix-stuff must be entered manually (or scripted)
on a per user basis, some of the benefits of syncing with AD seems
diminished, and it seems easier just managing everything on the RHDS side
alone without syncing with AD.

But since we very much would like to sync with AD, we thought we'd maybe go
for another directory server, hoping that syncing with AD will be
more seamless. We got pointed to Penrose (, and I' thought I'd hear if
anyone have any experience with this software to see if it might be the
right choice for us.

So does anyone have enough experience with Penrose to advice us on whether
it might be a good solution for us? And is Penrose supported by Red Hat?

I've done some reading on the Penrose home page, and found some other issues
maybe someone can clear up:

- Is there support for unidirectional sync with AD (that is, sync users
from AD to Penrose, but not the other way around)? Maybe using Penrose as
proxy or pass through authentication for AD might solve this.
- If integrated with AD, and still assuming a one way sync from AD to
Penrose, can one create new users directly on Penrose?

Any input on this subject will be greatly appreciate. And please comment
on other software products that may suit our needs.

Kenneth Holter
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe

redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe