[Novalug] LDAP Authentication RHEL7

Dan Lavu dan@redhat.com
Wed Jan 25 14:35:10 EST 2017


Peter,

The AD schema is structured differently then normal LDAP servers, the
password attribute is hidden and does not come back on a normal query or
administrative query. Though it can certainly be authenticated using LDAP
easily.

Jim,

You're right, it is much easier to set the realm and authenticate as that
user but they're a few more things at hand that I know you are
underestimating. You are also over estimating the difficultly of LDAP(s) as
well, the problem with Nick's setup, is that he wants to use local
identities with an external location for passwords. What pain points,
issues have you had setting this up in the past, maybe we can address them?

Nick,

In your previous email, what you had with the authconfig-tui tool will not
work. Take a look at this

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/PAM_Configuration_Files.html

In short you need to setup pam_sss.so to be sufficient in auth section but
remove it from account section of your pam file, that way the
authentication is made irregardless of the user identity, which is stored
locally and not using the pam_sss.so module to validate, the user will be
able to login.

I haven't tested this but, **this** should work

auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        [default=1 success=ok] pam_localuser.so
auth        [success=done ignore=ignore default=die] pam_unix.so nullok
try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so forward_pass
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only
retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass
use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     optional      pam_oddjob_mkhomedir.so umask=0077
session     [success=1 default=ignore] pam_succeed_if.so service in crond
quiet use_uid
session     required      pam_unix.so

It reads top down, so you might have to play with the order of which module
it engaged at what time. So if it hits sufficient, it'll pass without
needing to run through the other modules.


Dan

On Wed, Jan 25, 2017 at 12:46 AM, Peter Larsen via Novalug <
novalug@firemountain.net> wrote:

> On 01/25/2017 12:05 AM, James Ewing Cottrell III via Novalug wrote:
> >>> 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.
> >
> > IIRC, AD doesn't maintain the Password as part of the Identity Record.
> > AFAICT, AD will NEVER give out the password. You can either Auth via
> > Kerberos, or perhaps some Obscure M$ protocol, but that's it.
> >
> > In other words, your Password is NOT part of your LDAP record.
>
> So this part of the MIB isn't true?
> objectClasses: (
>   1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY
>   DESC 'Abstraction of an account with POSIX attributes'
>   MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
>   MAY ( userPassword $ loginShell $ gecos $
>         description )
>   )
>
> I think you're confusing security views with schema/content.  With the
> right access, you can retrieve the hashed password. Normal users cannot,
> and it's against all common sense security practice to transport the
> password TO the client. It's the other way around - the offered password
> is hashed according to the hash settings and sent in this format to the
> server - where the value is compared to the data found in the record for
> the appropriate entry.
>
> --
>
> Regards
>   Peter Larsen
>
> **********************************************************************
> 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