Date: Mon, 23 Nov 2015 17:09:50 +0100 From: "Patrick M. Hausen" <hausen@punkt.de> To: freebsd-stable <freebsd-stable@freebsd.org> Subject: PAM changes? (was: Re: NSS changes in releng/10.2?) Message-ID: <191784A3-0238-4889-9307-FF413D13F659@punkt.de> In-Reply-To: <07B8E386-4692-4BE0-9516-E1CA67B2934D@punkt.de> References: <07B8E386-4692-4BE0-9516-E1CA67B2934D@punkt.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, all,
sorry for not trying this earlier and now replying to myself, but I'm
slowly making progress isolating the problem.
> Am 23.11.2015 um 15:42 schrieb Patrick M. Hausen <hausen@punkt.de>:
>=20
> Hi, all,
>=20
> I just upgraded an older system from 8.4 to 10.2 in a single go.
> No unexpected problems, until I tried to use "su":
>=20
> $ su -
> su: Sorry
>=20
> Well, I *am* a member of the wheel group:
>=20
> $ id
> uid=3D10093(ry93) gid=3D10001(intern) =
groups=3D10001(intern),0(wheel),10002(entwickler)
>=20
> Hmmm ... we pull all this information from LDAP. My nsswitch.conf has =
always been:
>=20
> group: files cache ldap
> passwd: files cache ldap
And this part seems to be just as valid and working as before. I had the =
implicit
assumption that su(1) was using something like getgroups() to determine =
if I am
a member of "wheel" - which it doesn't. I even hacked up 5 lines of C to =
quickly
get my supplementary group list and lo and behold:
$ ./groups=20
10002
0
10001
So, it is not NSS' or LDAP's fault.
I just looked at the source for su(1) and it looks like it uses PAM to =
check if
I am authorized to su to root:
retcode =3D pam_authenticate(pamh, 0);
if (retcode !=3D PAM_SUCCESS) {
syslog(LOG_AUTH|LOG_WARNING, "BAD SU %s to %s on %s",
username, user, mytty);
errx(1, "Sorry");
My /etc/pam.d/system looks like this:
----------- system -----------
#
# $FreeBSD: releng/10.2/etc/pam.d/system 197769 2009-10-05 09:28:54Z des =
$
#
# System-wide defaults
#
# auth
auth sufficient pam_opie.so no_warn =
no_fake_prompts
auth requisite pam_opieaccess.so no_warn =
allow_local
#auth sufficient pam_krb5.so no_warn =
try_first_pass
#auth sufficient pam_ssh.so no_warn =
try_first_pass
auth sufficient /usr/local/lib/pam_ldap.so no_warn =
try_first_pass
auth required pam_unix.so no_warn =
try_first_pass nullok
# account
#account required pam_krb5.so
account required pam_login_access.so
account required /usr/local/lib/pam_ldap.so =
ignore_authinfo_unavail ignore_unknown_user
account required pam_unix.so
# session
#session optional pam_ssh.so want_agent
session required pam_lastlog.so no_fail
# password
#password sufficient pam_krb5.so no_warn =
try_first_pass
password required pam_unix.so no_warn =
try_first_pass
----------------------
And /etc/pam.d/su like this:
----------- su -----------
#
# $FreeBSD: releng/10.2/etc/pam.d/su 219663 2011-03-15 10:13:35Z des $
#
# PAM configuration for the "su" service
#
# auth
auth sufficient pam_rootok.so no_warn
auth sufficient pam_self.so no_warn
auth requisite pam_group.so no_warn =
group=3Dwheel root_only fail_safe ruser
auth include system
# account
account include system
# session
session required pam_permit.so
----------------------
Any changes that I missed on the way from 8.4 to 10.2? Unfortunately
I do not have an older 10.x system that runs with an Active Directory =
connection.
Only 8.4 ones - this one was the first to finally get updated to a =
current FreeBSD
version.
As I stated this PAM configuration works as intended on 8.4. I generated =
the
10.2 files above by running mergemaster.
Thanks,
Patrick
--=20
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
info@punkt.de http://www.punkt.de
Gf: J=C3=BCrgen Egeling AG Mannheim 108285
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?191784A3-0238-4889-9307-FF413D13F659>