Re: User Profiles to LDAP

[Patrick Botz <botz@xxxxxxxxxx>]

WARNING: The following information is basically true.  The details have
been salvaged from the depths of my memory and as such may be suspect (i.e.
not exactly accurate)!

There are two approaches and it REALLY depends on how you are going to use
the user profile/group info that can be accessed in or through LDAP.
If you are NOT intending to use Portal Server, then you don't have to do
anything.  You can authenticate against an i5/OS user profile from any
system by using the LDAP_bind API.  All this requires is that you know the
DN for "projected user profiles", the user profile name, and the password.
You can also use the LDAP_mod and LDAP_add, and LDAP_delete APIs to change,
create, and delete real user profiles via the LDAP server (of course you
have to had done an LDAP_bind with a user profile with *SECADM and
authority to the profile or you won't be allowed to).  You can also write
apps to allow end users to change their own user profile passwords using
the LDAP_mod API (note that under the covers, the LDAP server will use
CHGUSRPRF so password composition rules aren't applied).  The same is
basically true for group user profiles.

Unfortunately, if Portal Server is the mix (or when it is), then you'll
have to use the other mechanism.  I don't have time to look up the details
(it's been a while), but you have to publish the user profiles to the
system distribution directory. Then there is a switch somewhere (perhaps in
the LDAP configuration as I recall) that you turn on.  This actually makes
a copy of the user profile and certain attributes in the LDAP repository.
As I recall, if you change the password in the user profile, then the LDAP
copy gets updated, but not vice versa (I may either have this backwards or
t totally hallucinating).  In any case, it is possible to find accurate
information on both of these in the information center.  Search on
"projected user profiles" or "publish" AND LDAP.

Projected user profiles don't work with Portal Server because they require
a certain LDAP group structure schema.  The only way to do this is to
actually define/store the user and group info in LDAP and to extend the
schema with the group structure schema and info required by Portal Server.

NOTE: The previous is true and accurate to the best of my recollection.
The basic information is good, some of the details may not be quite right.

Patrick Botz
Senior Technical Staff Member
IBM Lab Services, Rochester
Security Architecture & Consulting, i5/OS Security Architect
(507) 253-0917, T/L 553-0917
CTC Fax # 507-253-2070
email: botz@xxxxxxxxxx

For more information on CTC, visit our website at
http://www.ibm.com/eserver/services
http://www.ibm.com/servers/eserver/services


midrange-l-bounces@xxxxxxxxxxxx wrote on 08/28/2006 08:41:48 AM:

> Good morning.
>
> Recently IBM Support got our IBM Directory Server running after
> overcoming an issue caused by some left over files from a previous OS
> install. Since it was expected to work with a flip of a switch I'm
> crunched for time to accomplish something with it. Could someone please
> clue me in on the fastest way to set up the system's user profiles in
> the directory?
>
> The eventual goal is to arrive at a point where users are primarily
> defined on the i5 and any services not provided on the i5 can run off
> these profiles via LDAP.
>
> Thanks,
> Alfred
>
> --
> Alfredo Delgado
> Laird Plastics -- Web Developer
> 6800 Broken Sound Pkwy; Suite 150
> Boca Raton, Florida 33487
>
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.