[Novalug] LDAP Authentication RHEL7

Nick Danger nick@hackermonkey.com
Fri Jan 20 17:21:51 EST 2017


1. I do not run everything. There are quite a few web sites in the DMZ
run by various other people.  I maintain the server and apache itself,
but they are in charge of the pages and other bits. Right now they have
a local password, I would like to have that be the same as their AD.
This is all on right now only 2 servers, so I don't want to build an
LDAP system for 2 servers and a total of 15 users (not including myself).

3a - 3b. I do not run AD, in fact I have absolutely nothing to do with
the Windows infrastructure or the firewall. According to both my Windows
admin and the firewall admin, both 3a and 3b are "Impossible." The
reasons are comical and I know wrong but I don't feel like fighting. If
it was a huge setup, I would do something like FreeIPA and get firewall
holes yadda yadda, but again, its 2 systems and 15 people.

It was near a miracle to get the LDAPS proxy into AD in the first place.
I'd like to take advantage of it. Worst case scenario is users have
separate PWs.

What bothers me most is this used to work. I had it working two jobs ago
when I was on RedHat 5 and I used an LDAP server for doing just password
auth. So why can't I do that now? Using LDAPS for security of course,
but otherwise the design is sound.


-Nick

On 01/19/2017 06:43 PM, James Ewing Cottrell III via Novalug 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.
>
>> 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.
>
>> 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".
>
>> 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.
>
>> 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>
>>
>>
> **********************************************************************
> The Novalug mailing list is hosted by firemountain.net.
>
> To unsubscribe or change delivery options:
> http://www.firemountain.net/mailman/listinfo/novalug





More information about the Novalug mailing list