Fedora directory users - Jul 2006 - I''m feeling like I''m drowning!

I''ve been reading about LDAP for the last couple of years, and finally 
got to start planning an implementation.

I''ve settled for a pretty simple config, where I would put user info 
(unix), samba and general user info on LDAP for starters (future plans 
is SSH public keys and host based access rules)

But...I''m feeling like I''m drowning, I''ve read the
o''reilly book, and
I''ve googled my behind off.

And so far I have found that LDAP is like PERL , there is no ONE way of 
doing it:)...

I''ve read the white papers at redhat.com, and managed to get SMB 
authentication to work, but the one thing that keeps bugging me is this:

Do I have to write my own data entry interface ?

I had hoped to let the people at HR do the data entry on the "soft" 
information , while the operations people do the "hard" information.

I hoped FDS would have something I could use, but I''m unable to figure 
out if it has a web interface or if it must be entry via the X-Windows 
program.

I''m sorry to be so whiny :)..and yes I''ll have some cheese
later, but
please, anyone throw me a friggin'' bone here :)

> -----Original Message-----
> From: fedora-directory-users-bounces@redhat.com 
> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf 
> Of Per Kristiansen
> Sent: Friday, July 21, 2006 10:16 AM
> To: fedora-directory-users@redhat.com
> Subject: [Fedora-directory-users] I''m feeling like I''m
drowning!
> 
> I had hoped to let the people at HR do the data entry on the
"soft"
> information , while the operations people do the "hard"
information.
> 
When you set up your directory server, you specified a port for the
admin interface.  Browse to it and see if it does what you want.

On 7/21/06, Per Kristiansen <perk@funcom.com> wrote:
> But...I''m feeling like I''m drowning, I''ve read
the o''reilly book, and
> I''ve googled my behind off.
The O''Reilly book is OK as far as it goes but it barely scratches the
surface.  It''s also focussed on OpenLDAP which is almost, but not
entirely unlike FDS.  "Understanding and Deploying LDAP Directory
Services" by Howes, Smith & Good is an excellent reference, especially
when you get to dealing with the internals...
http://www.amazon.com/gp/product/0672323168/sr=8-1/qid=1153505689/ref=pd_bbs_1/103-6902275-7741413?ie=UTF8
> Do I have to write my own data entry interface ?
It depends on entirely on what you need and how much power you''re
willing to give to people.  The built-in web interface is fairly
robust, but there''s also phpLDAPAdmin (http://phpldapadmin.sf.net/)
which I really like.  Our account admins use it.
> I had hoped to let the people at HR do the data entry on the
"soft"
> information , while the operations people do the "hard"
information.
If people are going to need access to just a few attributes, or you
need to apply business rules to the process before it hits the
directory, you''re probably best off building your own interfaces (or a
framework on which to build multiple interfaces).  In our case I built
a PERL module that our devs use to talk to the directory that
implements our directory organization principles, neatly abstracting
it out so that they don''t have to worry about mundate directory
matters but can concentrate on the business rules and user interface.

-- 
 _  Ben Steeves                                    bcs@metacon.ca
( ) The ASCII ribbon campaign                  ben.steeves@unb.ca
 X     against HTML e-mail                     GPG ID: 0xB3EBF1D9
/ \ http://www.metacon.ca/ascii      Yahoo Messenger: ben_steeves

Per Kristiansen wrote:
> I''ve been reading about LDAP for the last couple of years, and
finally
> got to start planning an implementation.
>
> I''ve settled for a pretty simple config, where I would put user
info
> (unix), samba and general user info on LDAP for starters (future plans 
> is SSH public keys and host based access rules)
>
> But...I''m feeling like I''m drowning, I''ve read
the o''reilly book, and
> I''ve googled my behind off.
>
> And so far I have found that LDAP is like PERL , there is no ONE way 
> of doing it:)...
>
> I''ve read the white papers at redhat.com, and managed to get SMB 
> authentication to work, but the one thing that keeps bugging me is this:
>
> Do I have to write my own data entry interface ?
>
> I had hoped to let the people at HR do the data entry on the
"soft"
> information , while the operations people do the "hard"
information.
What usually happens (in medium/large enterprises) is that HR people 
enter data into their Oracle/Peoplesoft/SAP system, and this data gets 
sync''d over to the LDAP server.  For example, check out this - 
ftp://ftp.mozilla.org/pub/mozilla.org/directory/tools - written using 
perldap by our LDAP admin at Netscape many years ago.  There are 
probably newer, better tools for doing this now.
> I hoped FDS would have something I could use, but I''m unable to
figure
> out if it has a web interface or if it must be entry via the X-Windows 
> program.
There are two web interfaces.  The Directory Express web app is used to 
allow self service user data administration (including password
change).
>
> I''m sorry to be so whiny :)..and yes I''ll have some
cheese later, but
> please, anyone throw me a friggin'' bone here :)
>
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

Ben Steeves wrote:
> On 7/21/06, Per Kristiansen <perk@funcom.com> wrote:
>
>> I had hoped to let the people at HR do the data entry on the
"soft"
>> information , while the operations people do the "hard"
information.
>
> If people are going to need access to just a few attributes, or you
> need to apply business rules to the process before it hits the
> directory, you''re probably best off building your own interfaces
(or a
> framework on which to build multiple interfaces).  In our case I built
> a PERL module that our devs use to talk to the directory that
> implements our directory organization principles, neatly abstracting
> it out so that they don''t have to worry about mundate directory
> matters but can concentrate on the business rules and user interface.
I like to think of LDAP as a building block toward creating an 
infrastructure.  Think of it like an SQL database, if you are familiar 
with that - you can set it up, but the structure of the data, as well as 
permissions on who can do what with the data, is more or less external 
to the directory/db server.  Creating a useful LDAP service, esp if you 
are integrating lots of end user services against it, is sometimes a bit 
of an art.

You can write a custom interface in perl, java, etc - I prefer php, but 
that''s just me (actually, php''s LDAP api is pretty primitive,
but php is
simple to code in, and has just enough api to do most things you''ll 
want)...  Anyway, that lets me create an interface that looks exactly 
the way I want it to, covers all the components I have working against 
LDAP, allows me to apply business logic against it, etc.

You can find prebuilt generic ldap browsers, but these tend to either 
not include business logic (see below), or aren''t "aware"
enough about
apps you have (for example, if you are using samba, there may be certain 
restrictions of the values you put in ldap that a generic browser that 
just lets you edit fields doesn''t know about).

Interfaces that ARE aware of some apps you use tend to not know about 
others - i.e. you might find one that creates users for samba, but knows 
nothing about your other apps and how they use LDAP, so you may not get 
a single "complete" admin tool.

ACI''s in ldap can be used to restrict who can do what - i.e. an ops 
group that can create users, and HR group that can edit address, phone, 
etc info on existing users, etc.  However, if you want to incorporate 
business logic (i.e. make uid''s all lower case, restrict the state
field
to only upper case/valid US state abbreviations, etc), you have to have 
an admin tool that enforces this - there is nothing inherent in LDAP to 
do this.

 - Jeff