[Novalug] LDAP Authentication RHEL7

Dan Lavu dan@redhat.com
Mon Jan 23 06:35:21 EST 2017


On Thu, Jan 19, 2017 at 6:43 PM, James Ewing Cottrell III <
jecottrell3@comcast.net> wrote:

> I'm wondering...
>
> [1] Why you would want "users" in the DMZ?
> [2] Assuming you do, why can't there be either
> [3a] Holes in the Internal Firewall gtom the DMZ to AD
> [3b] A Fledgeling AD in the DMZ as well
>
> On 1/19/2017 12:02 PM, Dan Lavu wrote:
>
>> James,
>>
>> That's not what he is asking. He's asking for authentication only and
>> omitting the LDAP directory and use local identities instead.
>>
>
> I understood that.
>
> I am saying that Authentication via LDAP is Trickier than doing it with
> Kerberos. I don't remember all the details at the moment, but it boils down
> to Fewer Moving Parts.
>
> LDAP is fine as long as he uses startTLS or SSL.
>>
>
> Fine...but More Complex.


Not really, every system administrator should understand this, especially
when it comes to web servers. The only thing I can see people having an
issue with is trying to use StartTLS and SSL together.


>
> Now that I'm thinking about it,
>> in this case, kerberos actually adds more complications because it
>> doesn't have any host principal. So in your example, when having a
>> kerberos ticket, delegated principals still won't work because there is
>> no way to authorize what he is logging into.
>>
>
> The fact that someone is Willing and Capable to Authorize me me via
> Kerberos means that I have almost surely landed in the Right Place. I'm not
> sure if a Man in the Middle Attack will gain anything.
>
>
That's the thing, you're not really authorized. An example would be, I
could tie in a jsmith's password to the root user, there is no
authorization regarding what kind of access the user has.


> pam_sss.so is becoming the commonly and most supported pam module on EL
>> distributions, so I would highly suggest using it, the built-in cache is
>> a good enough reason, while no other pam modules support an offline cache.
>>
>
> Believe me, I am definitely a Fan of SSSD, but I would much rather do Auth
> via Kerberos and Identity Management via LDAP.
>
> Nick,
>>
>> If you join the computer to the domain using realmd,
>>
>
> I'd really rather not, but Thanks for making it Easier to do.
>
> you can get added
>> benefits such as managing your sudoers, ssh keys, host base access
>> control in the directory ...
>>
>
> Like putting Automount entries in Maps, I never found those concepts
> useful.
>
> and as James mentioned delegated credentials.
>>
>
> OK, so when I say "Identity Management" I mean what you do when you say
> "Delegated Credentials".


Yup, from sshd_config, GSSAPIDelegateCredentials, don't confuse the two
> though, what you are referring is often encapsulated in the SSO support of
> some identity management solution.
>
> This is the preferred method and with auto id mapping, it' has becoming
>> significantly easier.
>>
>
> If by Auto ID Mapping you mean that I can have Different UIDs on Different
> machines, there is a Special Place in Hell for that idea.
>

No absolutely not, so in the case of not having the IDs managed, you can
mix and match UIDs/GIDs in the way Nick wants to set it up, which we all
know is bad for obvious reasons. LDAP requires the attribute uidNumber and
gidNumber from the posixAccount objectClass, but Active Directory does not
have this attribute unless you enable Unix Compatibility(?). Painfully, you
need to assign UIDs and GIDs per user in Active Directory. SSSD, with UID
mapping, will use an algorithm to convert the AD SID to a working UID/GID
for linux systems, no modification or administration necessary on the AD
side.




>
> Dan
>>
>
> JIM
>
> On Wed, Jan 18, 2017 at 12:10 AM, James Ewing Cottrell III via Novalug
>> <novalug@firemountain.net <mailto:novalug@firemountain.net>> wrote:
>>
>>     You don't want to do Authentication with LDAP; you want Kerberos for
>>     that. LDAP is for Identity Management, all the other fields in the
>>     Password File.
>>
>>     You get a Kerberos Ticket, which is just as good as an SSH Key.
>>
>>     IIRC, you don't even need SSSD.
>>
>>     JIM
>>
>>     P.S. I suppose it actually *is* possible to use LDAP for
>>     Authentication too, but you really don't want to if you can use
>>     Kerberos.
>>
>>
>>     On 1/15/2017 6:21 PM, Nick Danger via Novalug wrote:
>>
>>         I am trying to configure LDAP Auth with RHEL7. Note, I only want
>>         authentication, so the user still has a locally configured
>>         account with
>>         all their info.
>>
>>         What I have now working is Kerberos Auth. Accounts are local on
>>         box, and
>>         I set authconfig to use the AD servers. This works great. Users
>>         can use
>>         what is in AD to authenticate so they have SSO (same sign on)
>>         situation.
>>         Problem is I have to do the same thing in a DMZ, and the DMZ
>> doesn't
>>         have AD. It DOES have an LDAP proxy to AD.
>>
>>         All I can seem to find on LDAP assumes I am doing full posix info
>> in
>>         LDAP and that is not correct, I just want LDAP auth. I am
>>         guessing ldap
>>         auth with sssd since its RHEL7 and not 6, but that could be wrong.
>>
>>         Any pointers/docs out there? I gave up Friday at work on it, and
>>         going
>>         to start again tomorrow AM. Hopefully I can get this off my
>>         plate quickly!
>>
>>         -Nick
>>
>>
>>         ************************************************************
>> **********
>>         The Novalug mailing list is hosted by firemountain.net
>>         <http://firemountain.net>.
>>
>>         To unsubscribe or change delivery options:
>>         http://www.firemountain.net/mailman/listinfo/novalug
>>         <http://www.firemountain.net/mailman/listinfo/novalug>
>>
>>     ************************************************************
>> **********
>>     The Novalug mailing list is hosted by firemountain.net
>>     <http://firemountain.net>.
>>
>>     To unsubscribe or change delivery options:
>>     http://www.firemountain.net/mailman/listinfo/novalug
>>     <http://www.firemountain.net/mailman/listinfo/novalug>
>>
>>
>>



More information about the Novalug mailing list