[wellylug] LDAP info

[Cliff Pratt]

Daniel Pittman wrote:
> Cliff Pratt <enkidu at cliffp.com> writes:
>> 
>>> LDAP is the thing that comes to mind when I think about ways of 
>>> trying to manage this complexity and move towards a single sign
>>> on, (preferably using PKI rater than passwords, but that's
>>> another step).
> 
> The Windows / Active Directory answer to this is "Kerberos", which 
> provides the PKI style authentication using cryptographic tokens.
> 
>>> Trouble is, I don't really even know the questions to ask to get
>>> me on the way, hence the ill-defined nature of the original post.
>>> 
> 
> The right question to ask is "how do I use winbind authentication
> with all these services"  (except for Squid where it is "how do I use
> winbind as an NTLM authentication helper.)
> 
>>> Does LDAP sound like the right type of tool to use in this case?
>>> 
> 
> No, because you want to integrate with Active Directory
> authentication.
> 
Does he yet have AD? From what I read, I'm not sure he has.
> 
> [...]
> 
>> Ah, I wondered if they had all gone racing down the wrong track (at
>>  least partially) when they mentioned Samba.
> 
> Nope, that was absolutely the correct track.
> 
>> Samba is not after all an *authentication* tool,
> 
> Yes, it is.
> 
>> but it does provide some authentication (usually to authenticate 
>> Winders users to Unix resources).
> 
> No, it provides the SMB authentication layer against whatever
> back-end you care to configure.  This can be an internal database
> derived from the Unix account database or whatever part of a real
> Windows domain you care to name.
> 
So, will it (running on A) authenticate a user (X) using a back-end on 
C? And can the credentials that it gathers can be used to allow X to 
access a resource on D?
> 
>> I'd say that unless you have a lot of time, your best approach
>> would be to use PAM to control access to Unix servers LDAP servers
>> and consolidate all Unix authentication on those. Then expand from
>> there.
> 
> You would use the *winbind* system, which includes a PAM module, to 
> support authentication of users against the AD domain in this case.
> 
>> I'm sure you could use Windows AD's LDAP facilities to do this
>> (with the AD acting simply as an LDAP datastore for Unix, but I've
>> never done it so I don't know how hard it would be.
> 
> No.  AD's LDAP is not the correct answer for authentication and you
> will regret going down that path.
> 
> The correct answer is, yes, winbind.  That works with the LDAP,
> Kerberos and SMB domain controller stuff the same way Windows does so
> that this does all "just work."
> 
>> AD + Exchange does give a 'single signon' for mail, shares and so
>> on, but it sounds OTT for your setup which seems from your
>> description to be fairly small.
> 
> So does Linux, Squid, Apache and Samba -- if you use the right tools
> for the job. :)
> 
>> I'd go for controlling and centralising the Unix signons via
>> PAM/LDAP, and then see what you can do to pull the rest in. Your
>> mail clients should be able to use LDAP.
> 
> Now, /that/ part you probably want to wire LDAP up for -- configure a
>  directory query so the MUA can ask AD via LDAP what accounts exist
> in the global address book. :)
> 
>> I'm not sure why you are using signon for squid - any reason for
>> that? Unless you want to control what they do and see on the
>> Internet there's probably no reason for it.
> 
> It also identifies who requested each resource much more clearly than
>  without authentication and allows you to control who has Internet
> access in the office.
> 
> This is a useful or vital feature in many businesses -- especially
> where regulatory requirements make it mandatory.
> 
>> It's probably a dream to have a single signon for *everything*. Not
>>  everything supports LDAP authentication.
> 
> There is more or less nothing that you can't support for SSO with an
> AD domain under Linux using winbind, more or less.
> 

Cheers,

Cliff