[RFC] Remove supoort for NIS(+) from PAM

[Björn 'besser82' Esser]

Hello,

I'm currently doing some experiments with replacing the - upstream
mostly unmaintained - pam_unix module (authentication with user passwd)
with something using less bloated and cleaner code.  This topic is
currently also discussed with the upstream maintainer of pam_unix.

Replacing parts of a software for the sake of less complexity usually
comes with a cut-down of features; in this particular case it would be
dropping support for NIS(+), which has already been abandoned by its
initial developer SUN / Oracle for about 10 years [1].

Before starting some more concrete plans, I'd like to get some feedback
from the Fedora community how they feel about removing NIS(+) support in
PAM.  Is it even still actively used anywhere and/or by anyone in the
Fedora universe?

Thanks,
Björn


[1] 
https://www.oracle.com/solaris/technologies/end-of-feature-notices-solari...

[Iker Pedrosa]

Hi,

I'm adding rhel-devel also to the mailing recipients to get RHEL developers
feedback.

I'd also like to hear if there's any opinion on replacing pam_unix from
Fedora and RHEL.

On Fri, Oct 1, 2021 at 12:14 PM Björn 'besser82' Esser <
besser82(a)fedoraproject.org&gt; wrote:

>  Hello,
>
>  I'm currently doing some experiments with replacing the - upstream
>  mostly unmaintained - pam_unix module (authentication with user passwd)
>  with something using less bloated and cleaner code.  This topic is
>  currently also discussed with the upstream maintainer of pam_unix.
>
>  Replacing parts of a software for the sake of less complexity usually
>  comes with a cut-down of features; in this particular case it would be
>  dropping support for NIS(+), which has already been abandoned by its
>  initial developer SUN / Oracle for about 10 years [1].
>
>  Before starting some more concrete plans, I'd like to get some feedback
>  from the Fedora community how they feel about removing NIS(+) support in
>  PAM.  Is it even still actively used anywhere and/or by anyone in the
>  Fedora universe?
>
>  Thanks,
>  Björn
>
>
>  [1]
>
>  https://www.oracle.com/solaris/technologies/end-of-feature-notices-solari...
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>  

-- 

Iker Pedrosa

Software Engineer, Identity Management team

Red Hat <https://www.redhat.com>
<https://www.redhat.com>

[Alexander Bokovoy]

Hi,

On pe, 01 loka 2021, Björn 'besser82' Esser wrote:
> Hello,
>
> I'm currently doing some experiments with replacing the - upstream
> mostly unmaintained - pam_unix module (authentication with user passwd)
> with something using less bloated and cleaner code.  This topic is
> currently also discussed with the upstream maintainer of pam_unix.
>
> Replacing parts of a software for the sake of less complexity usually
> comes with a cut-down of features; in this particular case it would be
> dropping support for NIS(+), which has already been abandoned by its
> initial developer SUN / Oracle for about 10 years [1].
>
> Before starting some more concrete plans, I'd like to get some feedback
> from the Fedora community how they feel about removing NIS(+) support in
> PAM.  Is it even still actively used anywhere and/or by anyone in the
> Fedora universe? 
I am maintaining slapi-nis, the server side of NIS implementation on top
of FreeIPA. I also maintain libnsl2 in RHEL 9.

In RHEL 9 we removed client side of NIS(+) support from the
distribution. Server side emulation in FreeIPA is still available
because we have to be able to provide interoperability with non-Linux
clients.

The only reasonable use of NIS(+) beyond that is within computing farms.
NIS is very lightweight in terms of network traffic and an overhead for
a single request compared to LDAP-based solutions (SSSD). This is the
only reason we kept NIS support available for quite some time in
FreeIPA. But we are considering to remove it completely in future as
well.



-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Iker Pedrosa]

Hi,

I've asked internally for RHEL developers feedback about this topic and
I'll post a summary of it in this email.

On Fri, Oct 1, 2021 at 12:39 PM Iker Pedrosa <ipedrosa(a)redhat.com&gt; wrote:

>  Hi,
>
>  I'm adding rhel-devel also to the mailing recipients to get RHEL
>  developers feedback.
>
>  I'd also like to hear if there's any opinion on replacing pam_unix from
>  Fedora and RHEL.
>
>  On Fri, Oct 1, 2021 at 12:14 PM Björn 'besser82' Esser <
>  besser82(a)fedoraproject.org&gt; wrote:
>
> > Hello,
> >
> > I'm currently doing some experiments with replacing the - upstream
> > mostly unmaintained - pam_unix module (authentication with user passwd)
> > with something using less bloated and cleaner code.  This topic is
> > currently also discussed with the upstream maintainer of pam_unix.
> >
> > Replacing parts of a software for the sake of less complexity usually
> > comes with a cut-down of features; in this particular case it would be
> > dropping support for NIS(+), which has already been abandoned by its
> > initial developer SUN / Oracle for about 10 years [1].
> >
> > Before starting some more concrete plans, I'd like to get some feedback
> > from the Fedora community how they feel about removing NIS(+) support in
> > PAM.  Is it even still actively used anywhere and/or by anyone in the
> > Fedora universe?
> >
> > Thanks,
> > Björn
> >
> >
> > [1]
> >
> > https://www.oracle.com/solaris/technologies/end-of-feature-notices-solari...
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/[e-mail]
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> >
>
>
>  --
>
>  Iker Pedrosa
>
>  Software Engineer, Identity Management team
>
>  Red Hat <https://www.redhat.com>
>  <https://www.redhat.com>
>  

-- 

Iker Pedrosa

Software Engineer, Identity Management team

Red Hat <https://www.redhat.com>
<https://www.redhat.com>

[Stephen John Smoogen]

On Fri, 1 Oct 2021 at 06:14, Björn 'besser82' Esser
<besser82(a)fedoraproject.org&gt; wrote:
>  Hello,
>
>  I'm currently doing some experiments with replacing the - upstream
>  mostly unmaintained - pam_unix module (authentication with user passwd)
>  with something using less bloated and cleaner code.  This topic is
>  currently also discussed with the upstream maintainer of pam_unix.
>
>  Replacing parts of a software for the sake of less complexity usually
>  comes with a cut-down of features; in this particular case it would be
>  dropping support for NIS(+), which has already been abandoned by its
>  initial developer SUN / Oracle for about 10 years [1].
>
>  Before starting some more concrete plans, I'd like to get some feedback
>  from the Fedora community how they feel about removing NIS(+) support in
>  PAM.  Is it even still actively used anywhere and/or by anyone in the
>  Fedora universe?
>  
The places I have seen it still being used are in Universities run by
people who learned sysadmin in the 1990's and early 2000's. It is a
light weight system which is simple to set up and tends to be the
goto-stick for a lot of 'we put this together in 1999 with RHL6 and
upgraded ever since' places.

That said, NIS in most setups causes all kinds of security problems
and audit failures that those areas are probably rapidly going away.
[And the ones I know have been moving to Debian because it keeps
various other technologies we jettisoned long ago.]

If we drop this from pam_unix, should we look to dropping ypbind and
similar tools?

>  Thanks,
>  Björn
>
>
>  [1]
>  https://www.oracle.com/solaris/technologies/end-of-feature-notices-solari...
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.

[Frank Ch. Eigler]

Stephen John Smoogen <smooge(a)gmail.com&gt; writes:

>  The places I have seen it still being used are in Universities run
> by
>  people who learned sysadmin in the 1990's and early 2000's. It is a
>  light weight system which is simple to set up [...] 
For those people who like simple to set up and working systems but are
willing to consider upgrading if it's also simple and will keep working,
is there a NIS->$whatever migration document in fedora someplace?

- FChE

[Stephen John Smoogen]

On Fri, 1 Oct 2021 at 12:21, Frank Ch. Eigler <fche(a)redhat.com&gt; wrote:
>  Stephen John Smoogen <smooge(a)gmail.com&gt; writes:
>
>  > The places I have seen it still being used are in Universities run by
>  > people who learned sysadmin in the 1990's and early 2000's. It is a
>  > light weight system which is simple to set up [...]
>
>  For those people who like simple to set up and working systems but are
>  willing to consider upgrading if it's also simple and will keep working,
>  is there a NIS->$whatever migration document in fedora someplace? 
I don't think anyone has come up with an agreed upon $whatever that a
majority of people like. There is LDAP but that isn't light. There are
kerberos but that isn't easy. And honestly the cool kids only want web
logins these days as servers are a pain and why not just login into
Google/Facebook/Microsoft and let them deal with all that setup.



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.

[Frank Ch. Eigler]

Stephen John Smoogen <smooge(a)gmail.com&gt; writes:

> > > The places I have seen it still being used are in
> Universities run by
> > > people who learned sysadmin in the 1990's and early 2000's. It is a
> > > light weight system which is simple to set up [...]
> >
> > For those people who like simple to set up and working systems but are
> > willing to consider upgrading if it's also simple and will keep working,
> > is there a NIS->$whatever migration document in fedora someplace?
>
>  I don't think anyone has come up with an agreed upon $whatever that a
>  majority of people like. There is LDAP but that isn't light. There are
>  kerberos but that isn't easy.  
"light" in terms of CPU/network, who cares.  "light" in terms of
simplicity and maintenance, you have my attention.  If there is no such
gadget available, then please let's keep NIS around.


>  And honestly the cool kids only want web logins these days as
> servers
>  are a pain and why not just login into Google/Facebook/Microsoft and
>  let them deal with all that setup. 
(OK but seriously that's not a fedora matter.  Well, or rather, I'd love
to have a passwd/nss backed openid gadget.  Is that ipsilon?)

- FChE

[Neal Gompa]

On Fri, Oct 1, 2021 at 12:41 PM Frank Ch. Eigler <fche(a)redhat.com&gt; wrote:
>  Stephen John Smoogen <smooge(a)gmail.com&gt; writes:
>
>  >> > The places I have seen it still being used are in Universities run by
>  >> > people who learned sysadmin in the 1990's and early 2000's. It is
> a
>  >> > light weight system which is simple to set up [...]
>  >>
>  >> For those people who like simple to set up and working systems but are
>  >> willing to consider upgrading if it's also simple and will keep working,
>  >> is there a NIS->$whatever migration document in fedora someplace?
>  >
>  > I don't think anyone has come up with an agreed upon $whatever that a
>  > majority of people like. There is LDAP but that isn't light. There are
>  > kerberos but that isn't easy.
>
>  "light" in terms of CPU/network, who cares.  "light" in terms of
>  simplicity and maintenance, you have my attention.  If there is no such
>  gadget available, then please let's keep NIS around.
>
>
>  > And honestly the cool kids only want web logins these days as servers
>  > are a pain and why not just login into Google/Facebook/Microsoft and
>  > let them deal with all that setup.
>
>  (OK but seriously that's not a fedora matter.  Well, or rather, I'd love
>  to have a passwd/nss backed openid gadget.  Is that ipsilon?)
>  
We're currently missing a way to do OpenID or OIDC based login in
Linux like what Windows and macOS has. Ipsilon would be the
server-side aspect of it, we don't have any client-side integration
(sssd, gdm/sddm, etc.)




--
真実はいつも一つ！/ Always, there's only one truth!

[Tomasz Torcz]

On Fri, Oct 01, 2021 at 12:28:38PM -0400, Stephen John Smoogen wrote:
>  On Fri, 1 Oct 2021 at 12:21, Frank Ch. Eigler <fche(a)redhat.com&gt;
> wrote:
>  >
>  > Stephen John Smoogen <smooge(a)gmail.com&gt; writes:
>  >
>  > > The places I have seen it still being used are in Universities run by
>  > > people who learned sysadmin in the 1990's and early 2000's. It is a
>  > > light weight system which is simple to set up [...]
>  >
>  > For those people who like simple to set up and working systems but are
>  > willing to consider upgrading if it's also simple and will keep working,
>  > is there a NIS->$whatever migration document in fedora someplace?
>  
>  I don't think anyone has come up with an agreed upon $whatever that a
>  majority of people like. There is LDAP but that isn't light. There are
>  kerberos but that isn't easy. 
  There's FreeIPA, which makes both of them easy. And we even ship is a
Fedora feature.

>  And honestly the cool kids only want web
>  logins these days as servers are a pain and why not just login into
>  Google/Facebook/Microsoft and let them deal with all that setup. 
-- 
Tomasz Torcz                 Morality must always be based on practicality.
tomek(a)pipebreaker.pl                 — Baron Vladimir Harkonnen

[Stephen John Smoogen]

On Fri, 1 Oct 2021 at 12:42, Frank Ch. Eigler <fche(a)redhat.com&gt; wrote:
>  Stephen John Smoogen <smooge(a)gmail.com&gt; writes:
>
>  >> > The places I have seen it still being used are in Universities run by
>  >> > people who learned sysadmin in the 1990's and early 2000's. It is
> a
>  >> > light weight system which is simple to set up [...]
>  >>
>  >> For those people who like simple to set up and working systems but are
>  >> willing to consider upgrading if it's also simple and will keep working,
>  >> is there a NIS->$whatever migration document in fedora someplace?
>  >
>  > I don't think anyone has come up with an agreed upon $whatever that a
>  > majority of people like. There is LDAP but that isn't light. There are
>  > kerberos but that isn't easy.
>
>  "light" in terms of CPU/network, who cares.  "light" in terms of
>  simplicity and maintenance, you have my attention.  If there is no such
>  gadget available, then please let's keep NIS around.
>  
The issue is that no one has written anything as simple as ypserv's
Makefile in the 35+ years yp has been around. Most of the replacements
start looking at all the problems yp brings with it from sending
things in plain text, ability to spoof services and controllers,
ability to spoof user/hosts, and a flood of other things.. and 'fixes
them'. Those fixes add in complexity and it goes back to 'this is
stupid, keep yp'.

The reason I brought up OpenID is that it is the only thing simpler
than YP.. You don't have to deal with any of the hassles of id because
you don't own it anymore.


>  > And honestly the cool kids only want web logins these days as
> servers
>  > are a pain and why not just login into Google/Facebook/Microsoft and
>  > let them deal with all that setup.
>
>  (OK but seriously that's not a fedora matter.  Well, or rather, I'd love
>  to have a passwd/nss backed openid gadget.  Is that ipsilon?) 


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.

[Stephen John Smoogen]

On Fri, 1 Oct 2021 at 12:51, Tomasz Torcz <tomek(a)pipebreaker.pl&gt; wrote:
>  On Fri, Oct 01, 2021 at 12:28:38PM -0400, Stephen John Smoogen wrote:
>  > On Fri, 1 Oct 2021 at 12:21, Frank Ch. Eigler <fche(a)redhat.com&gt; wrote:
>  > >
>  > > Stephen John Smoogen <smooge(a)gmail.com&gt; writes:
>  > >
>  > > > The places I have seen it still being used are in Universities run by
>  > > > people who learned sysadmin in the 1990's and early 2000's. It is
> a
>  > > > light weight system which is simple to set up [...]
>  > >
>  > > For those people who like simple to set up and working systems but are
>  > > willing to consider upgrading if it's also simple and will keep working,
>  > > is there a NIS->$whatever migration document in fedora someplace?
>  >
>  > I don't think anyone has come up with an agreed upon $whatever that a
>  > majority of people like. There is LDAP but that isn't light. There are
>  > kerberos but that isn't easy.
>
>    There's FreeIPA, which makes both of them easy. And we even ship is a
>  Fedora feature.
>  
As much as I love FreeIPA.. it is not as simple as going into a
directory, typing make and having your central systems
passwords,hosts, groups, uids now available to everyone else on your
network. And yes all that power is available in plaintext without any
confirmation that it is valid or correct :).. but it is done in 2-5
minutes and probably extended by scripts written over a 35 year
timeframe. Most of the site admins running NIS I know would change
their text editor to $that_other_one before they would turn off NIS.

My own opinion is that it is way past time to stop using it and
supporting it. I understand its allure, but I also understand the
allure of .rhosts files with * in them.

>  > And honestly the cool kids only want web
>  > logins these days as servers are a pain and why not just login into
>  > Google/Facebook/Microsoft and let them deal with all that setup.
>
>  --
>  Tomasz Torcz                 Morality must always be based on practicality.
>  tomek(a)pipebreaker.pl                 — Baron Vladimir Harkonnen
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.

[Demi Marie Obenour]

On 10/1/21 12:54 PM, Stephen John Smoogen wrote:
>  On Fri, 1 Oct 2021 at 12:42, Frank Ch. Eigler <fche(a)redhat.com&gt;
> wrote:
> >
> > Stephen John Smoogen <smooge(a)gmail.com&gt; writes:
> >
> >>>> The places I have seen it still being used are in Universities run by
> >>>> people who learned sysadmin in the 1990's and early 2000's. It is
> a
> >>>> light weight system which is simple to set up [...]
> >>>
> >>> For those people who like simple to set up and working systems but are
> >>> willing to consider upgrading if it's also simple and will keep working,
> >>> is there a NIS->$whatever migration document in fedora someplace?
> >>
> >> I don't think anyone has come up with an agreed upon $whatever that a
> >> majority of people like. There is LDAP but that isn't light. There are
> >> kerberos but that isn't easy.
> >
> > "light" in terms of CPU/network, who cares.  "light" in terms of
> > simplicity and maintenance, you have my attention.  If there is no such
> > gadget available, then please let's keep NIS around.
> >
>  
>  The issue is that no one has written anything as simple as ypserv's
>  Makefile in the 35+ years yp has been around. Most of the replacements
>  start looking at all the problems yp brings with it from sending
>  things in plain text, ability to spoof services and controllers,
>  ability to spoof user/hosts, and a flood of other things.. and 'fixes
>  them'. Those fixes add in complexity and it goes back to 'this is
>  stupid, keep yp'. 
How many of these can be solved by tunneling everything in a WireGuard
mesh network, and using nftables rules to prevent spoofing?

Sincerely,

Demi Marie Obenour (she/her/hers)

[James Szinger]

On Sat, 2 Oct 2021 08:42:02 -0400
Demi Marie Obenour <demiobenour(a)gmail.com&gt; wrote:
>  
>  How many of these can be solved by tunneling everything in a WireGuard
>  mesh network, and using nftables rules to prevent spoofing? 
Sounds harder than setting up NIS+, which was supposed to solve many
of these issues 30 years ago, but still has not displaced NIS.  Even
if one can secure NIS on the network, that still leaves the issue of
`ypcat passwd`.

These days, I think FreeIPA or Active Directory are the best choices,
but both are complicated and possibly too much for a SO/HO, workgroup,
or departmental sysadmin.  AD has the advantage of supporting Windows,
MacOS, and Samba; the last time I looked FreeIPA was not good at this.

Jim

[Björn 'besser82' Esser]

Am Freitag, dem 01.10.2021 um 09:31 -0400 schrieb Stephen John Smoogen:
>  On Fri, 1 Oct 2021 at 06:14, Björn 'besser82' Esser
>  <besser82(a)fedoraproject.org&gt; wrote:
>  > 
>  > Hello,
>  > 
>  > I'm currently doing some experiments with replacing the - upstream
>  > mostly unmaintained - pam_unix module (authentication with user
>  > passwd)
>  > with something using less bloated and cleaner code.  This topic is
>  > currently also discussed with the upstream maintainer of pam_unix.
>  > 
>  > Replacing parts of a software for the sake of less complexity
>  > usually
>  > comes with a cut-down of features; in this particular case it would
>  > be
>  > dropping support for NIS(+), which has already been abandoned by its
>  > initial developer SUN / Oracle for about 10 years [1].
>  > 
>  > Before starting some more concrete plans, I'd like to get some
>  > feedback
>  > from the Fedora community how they feel about removing NIS(+)
>  > support in
>  > PAM.  Is it even still actively used anywhere and/or by anyone in
>  > the
>  > Fedora universe?
>  > 
>  
>  The places I have seen it still being used are in Universities run by
>  people who learned sysadmin in the 1990's and early 2000's. It is a
>  light weight system which is simple to set up and tends to be the
>  goto-stick for a lot of 'we put this together in 1999 with RHL6 and
>  upgraded ever since' places.
>  
>  That said, NIS in most setups causes all kinds of security problems
>  and audit failures that those areas are probably rapidly going away.
>  [And the ones I know have been moving to Debian because it keeps
>  various other technologies we jettisoned long ago.]
>  
>  If we drop this from pam_unix, should we look to dropping ypbind and
>  similar tools? 

Yes, finally dropping the ypbind, yp-tools, and ypserv packages seems to
make sense in this context, as from my understanding they won't be of
any practical use anymore.

Maybe libnsl, libnsl2, nss_nis, and slapi-nis can be evaluated to be
dropped also.

Björn

[Alexander Bokovoy]

On ke, 06 loka 2021, Björn 'besser82' Esser wrote:
> Am Freitag, dem 01.10.2021 um 09:31 -0400 schrieb Stephen John
> Smoogen:
> > On Fri, 1 Oct 2021 at 06:14, Björn 'besser82' Esser
> > <besser82(a)fedoraproject.org&gt; wrote:
> > >
> > > Hello,
> > >
> > > I'm currently doing some experiments with replacing the - upstream
> > > mostly unmaintained - pam_unix module (authentication with user
> > > passwd)
> > > with something using less bloated and cleaner code.  This topic is
> > > currently also discussed with the upstream maintainer of pam_unix.
> > >
> > > Replacing parts of a software for the sake of less complexity
> > > usually
> > > comes with a cut-down of features; in this particular case it would
> > > be
> > > dropping support for NIS(+), which has already been abandoned by its
> > > initial developer SUN / Oracle for about 10 years [1].
> > >
> > > Before starting some more concrete plans, I'd like to get some
> > > feedback
> > > from the Fedora community how they feel about removing NIS(+)
> > > support in
> > > PAM.  Is it even still actively used anywhere and/or by anyone in
> > > the
> > > Fedora universe?
> > >
> >
> > The places I have seen it still being used are in Universities run by
> > people who learned sysadmin in the 1990's and early 2000's. It is a
> > light weight system which is simple to set up and tends to be the
> > goto-stick for a lot of 'we put this together in 1999 with RHL6 and
> > upgraded ever since' places.
> >
> > That said, NIS in most setups causes all kinds of security problems
> > and audit failures that those areas are probably rapidly going away.
> > [And the ones I know have been moving to Debian because it keeps
> > various other technologies we jettisoned long ago.]
> >
> > If we drop this from pam_unix, should we look to dropping ypbind and
> > similar tools?
>
>
> Yes, finally dropping the ypbind, yp-tools, and ypserv packages seems to
> make sense in this context, as from my understanding they won't be of
> any practical use anymore.
>
> Maybe libnsl, libnsl2, nss_nis, and slapi-nis can be evaluated to be
> dropped also. 
slapi-nis implements two separate plugins, one of which provides NIS
support. It is going to be supported in RHEL 9 and I'd like to keep NIS
part supported in Fedora as well for some time. This only requires
existence of libnsl2.



-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Matthew Miller]

On Wed, Oct 06, 2021 at 01:28:33PM +0200, Björn 'besser82' Esser wrote:
>  Yes, finally dropping the ypbind, yp-tools, and ypserv packages seems
> to
>  make sense in this context, as from my understanding they won't be of
>  any practical use anymore. 
+1. Time to say goodbye.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[David Sommerseth]

On 02/10/2021 15:27, James Szinger wrote:
>  These days, I think FreeIPA or Active Directory are the best
> choices,
>  but both are complicated and possibly too much for a SO/HO, workgroup,
>  or departmental sysadmin.  AD has the advantage of supporting Windows,
>  MacOS, and Samba; the last time I looked FreeIPA was not good at this. 
While a FreeIPA server certainly doesn't come for free in regards to 
system resource consumption.  And you need to relate to at least the 
webadmin at times.  Under the hood it also surely is complicated, but 
from an every-day use .... is it that complicated?

I'm running an IPA server at home on a VM which should have been given 
more memory, but it is functional and responsive enough.  And I don't 
really think much about it.  Adding new users is easy enough.  And 
enrolling a new host and get it setup is also fairly straight forward 
(run `ipa-client-install` and optionally `ipa-client-automount`).  Once 
the IPA client install has completed, logins usually work instantly with 
sudo access and whatever else you've configured in the domain.

But it must be said ... I don't have any other hosts than Linux hosts at 
home.  A more heterogeneous environment might bring in bigger challenges.


-- 
kind regards,

David Sommerseth

[Alexander Bokovoy]

On la, 02 loka 2021, James Szinger wrote:
> On Sat, 2 Oct 2021 08:42:02 -0400
> Demi Marie Obenour <demiobenour(a)gmail.com&gt; wrote:
> >
> > How many of these can be solved by tunneling everything in a WireGuard
> > mesh network, and using nftables rules to prevent spoofing?
>
> Sounds harder than setting up NIS+, which was supposed to solve many
> of these issues 30 years ago, but still has not displaced NIS.  Even
> if one can secure NIS on the network, that still leaves the issue of
> `ypcat passwd`.
>
> These days, I think FreeIPA or Active Directory are the best choices,
> but both are complicated and possibly too much for a SO/HO, workgroup,
> or departmental sysadmin.  AD has the advantage of supporting Windows,
> MacOS, and Samba; the last time I looked FreeIPA was not good at this. 
FreeIPA has integration with Samba (to run Samba file server on IPA
clients) for quite some time, around two years now. You need to run
'ipa-client-samba' tool on IPA client to set it up, that's all. This
will make Kerberos authentication work against smbd and partially
password authentication too.

See man page for ipa-client-samba(1) for more details and
https://freeipa.readthedocs.io/en/latest/designs/adtrust/samba-domain-mem...
for even more technical details.

Samba upstream is planning to eventually remove support for a standalone
domain controller without Kerberos (e.g. not Samba AD or IPA DC). Given
that NTLM authentication will eventually be disabled everywhere, until
we get something better for a standalone use case, Kerberos is there to
handle such cases. Both Samba AD and FreeIPA in Fedora are good to cover
them.

Critique of complexity of a general 'domain controller' setup is
warrant, of course. It is something that FreeIPA really tries to
address and for simple use cases we are almost there if you are using an
integrated approach where FreeIPA runs and configures all the pieces it
needs (DNS, CA, ...). At least a basic understanding of DNS and Kerberos
is still preferrable, of course. We need to improve in this area in
Fedora Server documentation...

NIS+ as a tooling for such configurations is even less secure than
relying on NTLM in SMB protocol.


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Alexander Bokovoy]

On pe, 01 loka 2021, Neal Gompa wrote:
> On Fri, Oct 1, 2021 at 12:41 PM Frank Ch. Eigler
> <fche(a)redhat.com&gt; wrote:
> >
> > Stephen John Smoogen <smooge(a)gmail.com&gt; writes:
> >
> > >> > The places I have seen it still being used are in Universities run by
> > >> > people who learned sysadmin in the 1990's and early 2000's. It
> is a
> > >> > light weight system which is simple to set up [...]
> > >>
> > >> For those people who like simple to set up and working systems but are
> > >> willing to consider upgrading if it's also simple and will keep
> working,
> > >> is there a NIS->$whatever migration document in fedora someplace?
> > >
> > > I don't think anyone has come up with an agreed upon $whatever that a
> > > majority of people like. There is LDAP but that isn't light. There are
> > > kerberos but that isn't easy.
> >
> > "light" in terms of CPU/network, who cares.  "light" in terms of
> > simplicity and maintenance, you have my attention.  If there is no such
> > gadget available, then please let's keep NIS around.
> >
> >
> > > And honestly the cool kids only want web logins these days as servers
> > > are a pain and why not just login into Google/Facebook/Microsoft and
> > > let them deal with all that setup.
> >
> > (OK but seriously that's not a fedora matter.  Well, or rather, I'd love
> > to have a passwd/nss backed openid gadget.  Is that ipsilon?)
> >
>
> We're currently missing a way to do OpenID or OIDC based login in
> Linux like what Windows and macOS has. Ipsilon would be the
> server-side aspect of it, we don't have any client-side integration
> (sssd, gdm/sddm, etc.) 
We are working on that part for SSSD and FreeIPA. Not production ready
yet but aim to have something testable later this year. In a prototype
we have it is possible to authenticate against a thing like Github or
Keycloak.



-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland