Entries Tagged 'Directory' ↓

Red Hat

Originally uploaded by Jim Yang Photos

Identyx is now Red Hat. http://www.press.redhat.com/2008/06/19/introducing-red-hat-enterprise-ipa-10/

UPDATE: Session ID: S297199, Title: Getting Started with OpenDS, Monday, May 05, 11:00 - 11:55, Moscone North - Hall E 133

Penrose 2.0 ships OpenDS, MINA, FedoraDS, and ApacheDS as Penrose’s LDAP Service Providers (SP). OpenDS SP is now enabled by default in Penrose 2.0. We have put together a presentation below to describe how we integrate OpenDS into Penrose. We will be co-presenting with Sun at JavaOne/CommunityOne 2008 next May. Here is a portion of our presentation.

Penrose 2.0 introduces a new concept called Directory Application Archive (DAR). It mimics tomcat’s WAR/EAR files. We have a new directory structure and separate class loader for each partition. DAR files (files with a .dar extension) are intended to contain complete directory applications. In this context, an directory application is defined as a collection of drivers, custom modules, libraries, binaries, mapping, partitions and other supporting files such as images or ldif files. We included at least a dozen of these applications under /samples directory.

Samples of Directory Application

Account Lockout DAR directory layout

To start exploring Penrose 2.0, check out our documentation. Let me know what you think.

NIS vs LDAP Gateway

NIS Gateway is a software which uses LDAP as its information source while permitting  existing NIS clients to transparently use LDAP to resolve user, group and host information.

LDAP Gateway does the opposite. It translates and/or caches NIS entries and provides LDAP clients to transparently use NIS information.

Penrose can be configured as an LDAP Gateway to NIS servers, perhaps the only implementation that is available on the market - someone correct me if I am wrong. The NIS translation can be done in a real-time or through a persistence/caching layer, such as a Fedora Directory Server. In cached mode, Penrose is acting as a synchronization agent.  The primary data is still being mastered in NIS server so the administration/changes of the data still need to be done via NIS.

Avoiding “Bigbang” Migration from NIS to LDAP

You are probably asking. NIS is deprecated and no longer supported by Sun, so why are we still keeping NIS ? if the data still resides in NIS, what is the point of all of this then ?

There are still quite a few organizations out there that still use NIS as their primary authentication and identity stores. Most of them have hundreds, thousands or sometimes tens of thousands machines which still rely on multiple NIS servers. Migrating all of these NIS clients into LDAP clients can’t be done overnight  (”bigbang” migration).

Virtual Directory as an LDAP gateway is designed to help the system adminstrator to avoid this “bigbang” migration.

One needs to understand the challenges of migrating to an LDAP infrastructure.

• “If It’s Not Broken, Don’t Fix it” attitude. The reality is NIS does work well. We know a very large enterprise company who can’t completely switch to LDAP because their operational team doesn’t know how to scale their LDAP infrastructure to handle thousands of LDAP clients. So they are still sticking with NIS despite the fact that they might not pass an internal security audit.

• LDAP is hard. The concept of LDAP is not as easily grokked as database technology. Furthermore, this type of migration is considered a high-risk/mission critical project. Somebody will be fired if something goes wrong that cause their operations to halt. System Administrator has to be familiar with LDAP technology inside out to perform this type of large scale migration.

You might ask why can’t you just dump NIS entries,  import it into a directory server and stick a NIS gateway in front of the directory server ? Well, there are two problems that we see with this approach.

1. Before you cut-over to LDAP, NIS server is still the primary and authoritative identity. If there is an imperfection with your NIS entries such as conflicted UID/GID, namespace collision, etc., you will be forced to clean the NIS entries before you can export it to a directory server. The clean-up processes are the most manual and challenging efforts. If you have multiple NIS servers/domains, you’ll be forced to analyze all of the NIS entries across all of NIS servers/domains. By the time you are done with the analysis, there is a good chance someone may have changed the NIS entries and reintroduced yet another conflict. It is like trying to shoot a moving target.
2. The communication between NIS client and NIS Server is not secure. Thus, sticking a NIS Gateway in front of LDAP server won’t fix this issue. The goal of moving to LDAP is not having the clients to communicate any information to the servers without a proper authorization and  secure channel (LDAP SSL/TLS is more secure than YP’s clear text)

With the imminent release of Penrose 2.0, we will be providing tools and processes that can help you move out of NIS to LDAP in a gradual fashion. So stay tuned!

To be continued…

With the latest release of Penrose 1.2, we completed our integration with the latest release of OpenDS (0.9). Penrose 1.2 bundled OpenDS; however, OpenDS is not enabled by default.

Here is a very simple instruction on how to enable OpenDS in Penrose.

Penrose can provide an LDAP layer on top of a Crowd database, as well as implement a password decrypt/decode function, so that applications can authenticate using the same passwords that are stored in Crowd without duplicating user information. Detail instruction after the jump..

After the jump, read article by Michael Caton’s - “Virtual Directories Take Hold“.

I love 37signal products. I use BackpackIt to organize my personal tasks. I use Basecamp to manage my projects and clients. Recently, 37signal introduced Highrise, a simple contact sharing web-app. You can forward your e-mail conversations to Highrise and it will know how to append the conversations to the right contact. This is a great lead/sales tracking tool, in other words, salesforce.com killer!

Would it be nice if you can lookup Highrise contacts in your e-mail clients (Thunderbirds, Outlook Express, etc.) or address book? It turns out that there’s an ubiquitous way to look-up remote contacts on all of these clients. It is through directories/LDAP protocol.
Here is Apple Address Book directory configuration:

The combination of Highrise and Penrose allows users to lookup Highrise contacts thru LDAP. As you know, Penrose provides a light-weight LDAP service on top of identity silos, such as databases. The database to LDAP transformation is done in a real-time. No migration and synchronization is needed.
P.S: We have built a prototype for a telco environment. As you know, telco has the most stringent requirements, both from performance and scalability standpoints. So, Jason is you are reading this and interested in getting our help for Penrose implementation, give us a buzz. We’d love to work with you.

LDAP Studio is by far the best open source LDAP client implementation available. You can download it here. Credits goes to Stefan Seelmann, Pierre Arnauld Marcelot (we call him ‘pam’), Christie Koppelt and all of ApacheDS committers. I applaud these guys for yet again contributing a high quality software.

Just like Penrose Studio, LDAP Studio is based on Eclipse RCP PDE framework. It comes with two plugins: an LDAP browser and a schema editor. Both plugins can be installed into your Eclipse IDE by pointing it to the remote site  http://directory.apache.org/ldapstudio/update/

We are in the process of completing integration between Fedora DS and Penrose. We created a Java-Backend plug-in that can be installed as a Fedora DS Plug-ins module (Fedora DS is very well documented. Kudos to the Redhat team). The configuration instruction is here.