[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