[NTLUG:Discuss] Pre June-meeting discussion [was Saurday]

Leroy Tennison leroy_tennison at prodigy.net
Fri Jun 15 00:59:34 CDT 2007


Richard Geoffrion wrote:
> Saurday?? :)
>
> Jerome Haltom wrote:
>   
>> There's a lot of work to do at the distro/OS level before we have this
>> problem really fixed. 
>>     
> THIS problem?? what problem is "this' ??
>
>   
>> <snip>..nobody wants to actually help on these sorts of issues, either.
>> I guess because they're not cool, and don't use Web 2.0. Or something.
>>     
> Well, the basic fundamentals that run the corporate network must not be 
> left behind.   In the words of a great master.. "First learn stand, then 
> learn fly..."
>   
>> Also because most people I've met who use Linux have never *really* used
>> Windows on a corporate scale. Alas.
>>   
>>     
> Well... maybe we won't be like most. :)
>
>   
Unless I've missed it "this" could easily be defined as "client 
software".  We have open LDAP and Red Hat Directory Services to my 
knowledge but the only client I am aware of is pam_ldap and, when I 
looked at it, there were obvious limitations - at least one of which 
still exists (more in a minute).

When I evaluated it you had to hard code the login context into a file 
on the host - that's not going to come even close to flying in the 
corporate world.  The freshmeat site says that the environment is for a 
test-based console, although I got it to work from the graphical display 
manager you only keyed in a user ID (the context was set).  To fix this 
not only is the client LDAP code going to have to be changed to accept 
(or pick) user-supplied contexts but gdm, kdm, xdm (and maybe a display 
manager for xfce) could have to be modified to accept a context as well.

Another issue is that the client password is (or at least was when I 
tested) sent in clear text across the wire - need I say more in regard 
to the corporate world?  I realize that this is "out of scope" as far as 
LDAP is concerned but it's still a real-world problem which needs an 
answer.  The solution is to set up encryption on every host.  I couldn't 
get it to work then but possibly could now that I've done a lot more 
work with cryptography.  Even if I can that's another hurdle to 
overcome, I suspect that more than a few technicians would feel 
intimidated at having to set up encryption by generating keys, etc.  
Even if there is no intimidation there's the level of effort involved - 
a key pair for every host...

To make matters worse at least some open source developers don't seem to 
understand the issue.  When I posted on the Fedora Directory Services 
forum about this I specifically mentioned the client problem and the 
reply I got showed the person responding didn't understand the 
significance of what I was saying.

Another issue (at least with open LDAP when I tested) is that you get to 
"roll your own" schema.  While some standard schemas were supplied you 
had to understand how to combine them. This isn't impossible to do but 
it does mean that you have to understand LDAP, yet another hurdle.

LDAP itself (regardless of flavor: NDS, AD, Red Hat Directory Server, 
open LDAP, etc.) has a hurdle to overcome with the user community which 
doesn't "get" contexts.  The magnitude of this problem is evidenced by 
the fact that Novell came out with Catalog Services in an attempt to 
deal with this issue.  AD's approach of using domains isn't much better, 
users seem to "get that" more but it may be because it's been foisted on 
them more.  They still don't "get it" easily.  The user at domain email 
format seems to have some promise because users have to understand email 
addresses.  However, all this (catalogs, user@) still leads to a more 
flat view of user space and ends up presenting scalability problems 
(name collisions).  Having contexts solves all of this if only the user 
community got it...  It's simply a tough problem.

Finally, there's the interaction between LDAP and other technologies 
such as SSL.  I saw a post on the Open AFS forum that some technologies 
have to be "first" in authentication priority and of course only one can 
be first...

If all of this has changed in the time since I looked at LDAP then 
please, PLEASE let me know.  This is an area that I'm very interested 
in.  I believe that, if the open source community had a really good 
implementation in this one area, Microsoft might be seeing the exit sign 
on a far greater scale at a lot more corporations.



More information about the Discuss mailing list