Entries Tagged 'Use Case' ↓

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.

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…

Penrose can be use to provide an account lockout to block password guessing attack. Most directory servers aren’t equipped with this type of functionality. You will need to download our Penrose 2.0 nightly build to do this. Checkout the detailed configuration after the jump.

One of our customer is a large server hosting company. They currently maintain a large customer e-mails in Microsoft SQL 2005. They need to configure their SMTP/anti-spam software to authenticate/look-up against those customer information. They had been running a scheduled batch to dump their SQL database and re-import the entries into a directory. We suggested a better and more elegant approach. Using Penrose real-time translation, we map their SQL entries into an LDAP entries “on-the-fly”. Their SMTP/Anti-spam application is then configured to talk to Penrose via a standard LDAP protocol.  A detailed configuration, such as creating LDAP connector and creating user group in Mail Marshall, after the jump.

UPDATE: A complete documentation on how to “Aggregate Multiple Proxies” is now available including sample configuration.

The Good

Starting from version 8.1, PeopleSoft user’s credentials be validated against the directory; hence leveraging pre-existing authentication data in an LDAP directory service and achieve Single-Sign-On across multiple PeopleSoft applications. Furthermore, user data that is typically used in a LDAP directory (such as name, phone number, and email address) can be updated instantaneously or on batch interval when information changes in PeopleSoft database.

The Bad

However, PeopleSoft delivered LDAP Authentication interface can only authenticate against one Directory tree. PeopleSoft do support multiple LDAP authentication but only for fail-over and redundancy purpose. Each replica server must contains identical tree as the master LDAP server.

The Ugly

Under typical enterprise environment, where there are more than one directory trees (multiple AD implementations) exist, integration of PeopleSoft and multiple LDAP is only possible with customization to application sign-on process in PeopleCode. However, such customization is beyond normal support provided by PeopleSoft Global Support Center.

The Solution

Use Penrose to tie all the AD servers into one directory tree by Merging, Proxying and PTA-ing the AD servers.

Devils in the Detail

There are various ways for an application to authenticate against an LDAP server. Here is
a common method:

1. User enters username and password into the application.
2. The application will perform a search operation against the LDAP server to find the full DN of the LDAP entry representing the user. The application will supply a search filter, for instance: (sAMAccountName=)
3. For each DN returned, the application will attempt a bind operation against the LDAP server using the DN and the supplied password.
4. Upon a successful bind, the application will perform another search operation based on the DN to retrieve certain attributes (e.g. cn, mail, memberOf) that are needed by the application.

The problem is that many applications assume that all of the users will be located in a single LDAP server. In many cases, the users are spread out in different domains and different Active Directory servers. Penrose solves the problem by mapping the users into a single “virtual” tree. From the application’s point of view, all user are now located in a single LDAP server. When the application performs an LDAP operation on Penrose, Penrose will forward the request to the appropriate LDAP/AD server, and then forward the results back to the client.

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..

With NIS is being EOL’d by Sun, most organizations will want to migrate their NIS servers to LDAP-based directories. Organization who is still using Sun NIS will fail Sarbanes-Oxley audits. However, the Sun current migration process is fairly lengthy and complicated one. Penrose can simplify this process by providing an LDAP façade for the NIS backend servers. Its NIS adapter technology will facilitate an extended transition period by leveraging data in the NIS domains data stores. Its transformation, join and proxy engines will help address data migration concerns such as UIDs and GIDs conflicts (non unique across all of its NIS domains) and management of site local data. The advantage of this approach is that administrator can start moving pool of machines into the new LDAP system in a staggered manner with no or minimal downtime.

How does virtual directory relate to single-sign on solution ? Why do you need a virtual directory when you have SSO ?

They say a picture is worth 1,000 words. So here are four pictures for you.
Picture 1: before SSO

Picture 2: After SSO

As you can clearly see, an SSO solution removes multiple authentications so that a user doesn’t need to type (present) his credentials every time he accesses an application.

The nature of SSO implies that there will be only one central repository for user information and credential, preferably within an LDAP server. So, any additions, modifications, etc. of user information and credentials will have to be performed within this central store.

The reality is far from this simple concept, as described in this excellent blog from Radovan’s single directory paradigm.

This is where virtual directory technology comes to the rescue.

Picture 3: Here’s the picture before a virtual directory

Picture 4: Here’s after a virtual directory

The ultimate goal of a virtual directory is to create a single account (virtualized/centralized) for a user, which is obviously a real improvement.

Single account (end goal of a virtual directory) is not equal to single authentication (end goal of an SSO solution).

Make sense? Please feel free to chime in.

Here is a high-level overview of Pass-through Authentication.

Stephen Lombardo from Identicentric wrote:

” +1 for virtual directory pass-through authentication.

It’s definitely technically feasible and works very well to drive consolidation of authentication services. From past experience it’s one of the most powerful benefits of virtual directory technology. In fact, this feature was key to the value proposition and purchasing decision for several of the prominent deployments I’ve worked on. ”

UPDATED: We added wizards in Penrose Studio to automatically configure Penrose server to allow pass authentication requests back to Active Directory.

UPDATED: We currently support three different modes of PTA, namely:

• Default mode: Penrose initially binds to the target directory to check the credentials, then to switch to a proxy account for all further operations on the connection. This is by far the most common scenario.
• Full mode: Penrose binds to the target directory check credentials and then holds the connection open to process all directory operations for that connection. In this mode the same credentials you supplied during bind will continue to be used when you perform the subsequent operations. This mode is the most valuable in a security conscious directory environment that makes heavy use of ACLs. In that kind of environment the use of default mode might be undesirable.
• Disabled mode: In this mode, Penrose doesn’t allow passthrough at all. It always operates on the back end directory with a proxy account. All bind operations against the target server are rejected. Any other operations will be executed using the proxy account specified in its xml config.

One of the goals of federation is to provide a global sign-sign on for the end users. Identities from multiple organizations must be shared. As a consequence, federation projects must now work together with other companies while dealing with internal federation issues (involving the integration of internal identities). A Virtual Directory Server solves these common barriers when it:

Acts as an Authentication Server:
In federation, a user can sign on to a trusted server to get a security token (identifier). This Authentication server has to aggregate multiple identities from possibly many external sources.

Acts as an Attribute Server:
Federation, involves the association of your various accounts from site to site. A small identifier containing a minimal set of information about you maintains the associations. Exposing this minimal attribute, requires an attribute server to allow sites to obtain more information about the user based on the token held by the attribute. The challenge of building an attribute server rests in the ability to search all attributes from external databases/directories quickly. Virtual directories dynamically access and store entries within a cache engine to aggregate user attributes from various places.

Acts as an Authentication Authority Server:
Virtual directory can bring in various policies from different data sources.

UPDATED 5/9/06: We just announced partnership with Ping Identity. PingFederate can use identity information within Penrose through its LDAP attribute selection and mapping feature.