Date: Tue, 27 Mar 2018 12:21:36 +0100 From: "Norman Gray" <norman@astro.gla.ac.uk> To: freebsd-questions@freebsd.org Subject: pam_ldap: documentation problems Message-ID: <91400FA4-B69E-4272-9F89-88626AE55136@astro.gla.ac.uk>
next in thread | raw e-mail | index | archive | help
Greetings.
I'm trying to set up PAM/LDAP authentication. I think the following may
represent documentation bugs (or at least omissions), but I'm
insufficiently confident about the technology to raise them as such
without some discussion here first.
Do let me know if there's a better list for this to go to.
1. The pam_ldap(5) manpage (installed as part of the pam_ldap pkg/port)
says
pam_groupdn <groupdn>
Specifies the distinguished name of a group to which a
user must
belong for logon authorization to succeed.
pam_member_attribute
<attribute> Specifies the attribute to use when testing a
user's
membership of a group specified in the pam_groupdn
option.
This description doesn't, however, make clear whether
pam_member_attribute is an attribute on the user's entry, naming the
group they belong to (eg memberOf), or an attribute on the group's
entry, naming the users who are members (eg member or memberUid). Other
resources suggest [5] it's the latter, but it would be useful to have
this clarified in the FreeBSD manpage.
2. The article at [1] discusses PAM configuration and mentions
pam_groupdn, but _doesn't_ illustrate pam_member_attribute, so doesn't
resolve the ambiguity in pam_ldap(5).
Further, this article says:
> Members of this group are specified in one or more memberUid
> attributes, and each attribute must have the full distinguished name
> of the member. So memberUid: someuser will not work; it must be:
>
> memberUid: uid=someuser,ou=people,dc=example,dc=org
I think this may actually not conform with how memberUid is intended to
be used. Specifically, I think that memberUid should indeed be simply
`someuser`. That is, I suspect this article is wrong, or at least
unconventional, in this demand.
If we look at `/usr/local/etc/openldap/schema/nis.schema`, we see that
memberUid has syntax 1.3.6.1.4.1.1466.115.121.1.26 which (as you will of
course instantly recognise) is IA5String (ie, ASCII) (some other
nis.schema files, eg on macOS, give this as 'directory string', meaning
a UTF-8 encoded ISO10646/Unicode string). RFC 2307 [3] also says that
memberUid is an IA5String. The DN quoted above doesn't violate this as
a matter of syntax, but note that the attribute is _not_ given syntax
...121.1.12, or DN. In contrast. the `member` attribute (RFC 2256, [4])
_is_ given syntax distinguishedName. Thus the implication does seem to
be that, pace the article at [1], memberUid is intended _not_ to be a
DN.
Also, RFC 2307bis ([6], draft, but widely implemented) explicitly says:
It is suggested that uid and cn are used as the naming attribute for
posixAccount and posixGroup entries, respectively. Group members
may
either be login names (values of memberUid) or distinguished names
(values of member).
which seems to rule out DN-valued memberUid.
The howto at [5] also illustrates memberUid as a simple uid, not a DN.
I haven't yet experimented with this in practice -- I'm still trying to
read around this -- so it's possible that memberuid:someuser does in
fact work in practice, and the article is simply out of date.
Can anyone comment? Or point to alternative instructions for setting up
FreeBSD client PAM/LDAP (in the current context, I'm configuring the
server-side as well, but that has to be compatible with Linux clients,
too)?
Best wishes,
Norman
[1]
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/ldap-auth/client.html
[2] http://www.ietf.org/rfc/rfc2252.txt
[3] http://www.ietf.org/rfc/rfc2307.txt
[4] http://www.ietf.org/rfc/rfc2256.txt
[5]
http://www.tldp.org/HOWTO/archived/LDAP-Implementation-HOWTO/pamnss.html
[6] https://tools.ietf.org/html/draft-howard-rfc2307bis-02
--
Norman Gray : https://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?91400FA4-B69E-4272-9F89-88626AE55136>