Re: [TUHS] YP / NIS / NIS+ / LDAP

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Norman Wilson]

A. P. Garcia:

  I'd be interested in knowing where a pure unix environment
  exists, beyond my imagination and dreams that is.

====

For starters, the computing facility used for teaching
in the Department of Computer Science at the University
of Toronto.  Linux workstations throughout our labs; Linux
file servers and other back-ends, except OpenBSD for the
Kerberos KDCs and firewalls.

And yes, we use Kerberos, including Kerberized NFS for
(almost) all exports to lab workstations, which cannot
be made wholly secure against physical breakins by students.
(There's no practical way to prevent that entirely.)

Except we also use traditional UNIX /etc/shadow files
and non-Kerberized NFS for systems that are physically
secure, including the host to which people can ssh from
outside.  If you don't type a password when you log in,
you cannot get a Kerberos TGT, so you wouldn't have access
to your home directory were it Kerberized there; and we
aren't willing to (and probably couldn't) forbid use of
.ssh/authorized_keys for users who know how to do that.

Because we need to maintain the password in two places,
and because we create logins automatically in bulk from
course-registration data, we've had to write some of our
own tools.  PAM and the ssh GSSAPI support suffice for
logging in, but not for password changes or account
creation and removal.

Someday we will have time to look at LDAP.  Meanwhile we
distribute /etc/passwd and /etc/shadow files (the latter
mostly blanked out to most systems) via our configuration-
management system, which we need to have to manage many
other files anyway.

Norman Wilson
Toronto ON

[TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

Does anyone have any experience with YP / NIS / NIS+ / LDAP as a central 
directory on Unix?

I'm contemplating playing with them for historical reasons.

As such, I'm wondering what the current evolution is for a pure Unix 
environment.  Read:  No Active Directory.  Is there a current central 
directory service for Unix (or Linux)?  If so, what is it?

I'm guessing it's LDAP combined with Kerberos, but I'm not sure.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Ben Greenfield via TUHS]

I had the great pleasure of learning on an NIS/NetInfo/Active Directory. I’m not sure what the windows service was called but we would edit all our clients to point to a sun solaris 6-8 NIS server.

Sun bought some LDAP company with planet in the name and I never in months of trying could get their LDAP script to set-up the LDAP environment.

Over time we added Open Directory which is what OS X used after NetInfo. I still use directory services and have used OS X Server’s Directory Server as a kerberized LDAP server or Linux and server user’s accounts. This required get the Linux servers to bind using SASL to my kerbierized server.

That has been my experience and with the changes coming to OS X server I’m now moving towards OpenBSD but plan on bringing the OS X and it’s Directory Server with me as long as it lasts:)

Let me know if you have specific questions,

Ben


> On Nov 4, 2018, at 3:51 PM, Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:
> 
> Does anyone have any experience with YP / NIS / NIS+ / LDAP as a central directory on Unix?
> 
> I'm contemplating playing with them for historical reasons.
> 
> As such, I'm wondering what the current evolution is for a pure Unix environment.  Read:  No Active Directory.  Is there a current central directory service for Unix (or Linux)?  If so, what is it?
> 
> I'm guessing it's LDAP combined with Kerberos, but I'm not sure.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Arthur Krewat]

On 11/4/2018 3:51 PM, Grant Taylor via TUHS wrote:
> Does anyone have any experience with YP / NIS / NIS+ / LDAP as a 
> central directory on Unix?
>

I've used all three (NIS and YP are the same thing).

I think it all depends on what you're centered on. If your user 
credentials are all in Active Directory, you use LDAP. If you already 
have LDAP, you use LDAP. If you've been using NIS for the past 20 years 
(like I have in my office), you stick with NIS+. NIS+? Same thing. NIS+ 
is a little limited, as I'm not sure what supports that anymore. I don't 
think even Solaris 11.x does.

As to which is better, I really can't say. LDAP/AD has it's points. When 
NIS+ first came out, I gladly moved to it, as it has a compatibility 
mode that allows it to answer NIS queries. So the transition from NIS to 
NIS+ went smoothly. But that was an almost 100% Sun shop where I did that.

if I were to start up a new environment today, and it was PURELY Unix, 
I'd probably use NIS. But then, I have a slew of scripts that I use to 
administer NIS (and NIS+) that use SCCS for change tracking, and also 
can populate DNS zones for the hosts map. To administer LDAP, you either 
use a GUI, or script things with ldapmodify, etc. Which is ghastly, IMO.

art k.

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Mantas Mikulėnas]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

On Sun, Nov 4, 2018 at 11:34 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> Does anyone have any experience with YP / NIS / NIS+ / LDAP as a central
> directory on Unix?
>
> I'm contemplating playing with them for historical reasons.
>
> As such, I'm wondering what the current evolution is for a pure Unix
> environment.  Read:  No Active Directory.  Is there a current central
> directory service for Unix (or Linux)?  If so, what is it?
>
> I'm guessing it's LDAP combined with Kerberos, but I'm not sure.
>

As far as I know, LDAP is very much in use in the Linux world – via nslcd
or SSSD as clients; OpenLDAP (blech) or 389-ds as "build from scratch"
servers. There's also FreeIPA which tries to be an integrated solution.
(But even if you seek a pure Linux/Unix environment, I suspect AD is what
keeps LDAP from being replaced – because as long as there are clients for
AD, there will be clients for pure LDAP as well.)

Kerberos exists too, but somewhat less common – FreeIPA includes it by
default, but many people just piggyback on LDAP bind as password-based
authentication and use SSH keys for passwordless (because apparently
protocols other than SSH and HTTPS don't exist anymore). The MIT Kerberos 5
suite is still actively maintained and receives new features, such as
S-PAKE), whereas Heimdal appears to be on life support.

(Speaking of zombies, Linux glibc still comes with Hesiod support built
in...)

Many people's idea of a central directory nowadays appears to be "deploy an
/etc/passwd via Salt or Ansible".

-- 
Mantas Mikulėnas

[-- Attachment #2: Type: text/html, Size: 2160 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

On Sun, Nov 4, 2018 at 4:44 PM Mantas Mikulėnas <grawity@gmail.com> wrote:

> Kerberos exists too, but somewhat less common – FreeIPA includes it by
> default, but many people just piggyback on LDAP bind as password-based
> authentication and use SSH keys for passwordless (because apparently
> protocols other than SSH and HTTPS don't exist anymore). The MIT Kerberos 5
> suite is still actively maintained and receives new features, such as
> S-PAKE), whereas Heimdal appears to be on life support.
>

FreeBSD has Heimdal. We switched over a long time ago when MIT Kerberos 5
at MIT looked like it was going to die. Now the roles have somewhat
reversed.

Warner

[-- Attachment #2: Type: text/html, Size: 1020 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Robert Brockway]

On Sun, 4 Nov 2018, Grant Taylor via TUHS wrote:

> Does anyone have any experience with YP / NIS / NIS+ / LDAP as a central 
> directory on Unix?

I used NIS a lot in the 90s and early 2000s.  I think it continues to be 
underrated.  The main gripe people had was lack of security but if all of 
the hosts were in the same security domain anyway it wouldn't matter. 
Integrated very well with NFS on Solaris & Linux for me back in the day.

NIS+ is awful.  Let us not speak of it again.

I did a lot of LDAP around 2007-2010.  I got quite good at writing 
filters as we were using for a lot more than juse user auth.

Most installations I'm seeing today auth to AD, which is of course now 
supported.

> I'm contemplating playing with them for historical reasons.
>
> As such, I'm wondering what the current evolution is for a pure Unix 
> environment.  Read:  No Active Directory.  Is there a current central 
> directory service for Unix (or Linux)?  If so, what is it?

In my experience LDAP is preferred in a pure *nix environment these days. 
I've never played much with Kerberos.

There is another option that is largely ignored...

Increasingly *nix systems are managed through orchestration tools like 
Puppet or Ansible.  One option is to build the user account details from 
an AD or LDAP backend on the orchestration server and write it out 
locally on the *nix boxes.  The *nix boxes just auth locally but still 
gain the benefit of dynamically managed users.  There are advantages and 
disavantages of this outside the scope of this list.

Cheers,

Rob

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 2706 bytes --]

On 11/04/2018 08:16 PM, Robert Brockway wrote:
> I used NIS a lot in the 90s and early 2000s.  I think it continues to be 
> underrated.  The main gripe people had was lack of security but if all 
> of the hosts were in the same security domain anyway it wouldn't matter.

I'd like to hear more about the security issues.

Did NIS(+) ever encrypt it's communications?  (I'm not counting things 
like IPsec transport.)

I'm fairly certain that it was possible to enumerate the directory or 
otherwise scrape most (if not all) of it's contents.

> Integrated very well with NFS on Solaris & Linux for me back in the day.

*nod*

I was pleasantly surprised at how well Samba+Winbind integrated with 
things.  Groups and IDs from AD just showed up identical to local 
groups.  We didn't even need to worry about NetGroups.

> NIS+ is awful.  Let us not speak of it again.

Okay.

Can I ask that you enlighten this grasshopper without saying it's name? 
():-)

> I did a lot of LDAP around 2007-2010.  I got quite good at writing 
> filters as we were using for a lot more than juse user auth.

Ya.  The LDAP filters are why I tried to avoid just using LDAP against 
AD.  That and the fact that the Unix passwords were actually a separate 
field that could have different values from what the Windows systems used.

> Most installations I'm seeing today auth to AD, which is of course now 
> supported.

I'm curious what "supported" actually means.  I think there is 
preconfigured LDAP against AD templates, and things like Samba+Winbind. 
But all seem to be less native / seamless than NIS.

> In my experience LDAP is preferred in a pure *nix environment these 
> days. I've never played much with Kerberos.

Does that mean that the authentication is also done across LDAP?  I hope 
that it's encrypted LDAP.

> There is another option that is largely ignored...
> 
> Increasingly *nix systems are managed through orchestration tools like 
> Puppet or Ansible.  One option is to build the user account details from 
> an AD or LDAP backend on the orchestration server and write it out 
> locally on the *nix boxes.  The *nix boxes just auth locally but still 
> gain the benefit of dynamically managed users.  There are advantages and 
> disavantages of this outside the scope of this list.

IMHO that is still local accounts and not centrally manged.  It's just 
automated deployment.  Sort of like the difference of creating a file in 
a directory with the GID bit set vs creating the file and then changing 
the group after the fact.  Similar end result, but totally different 
execution method.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Mantas Mikulėnas]

On Mon, Nov 5, 2018 at 9:19 AM Grant Taylor via TUHS
<tuhs@minnie.tuhs.org> wrote:
>
> On 11/04/2018 08:16 PM, Robert Brockway wrote:
> > I used NIS a lot in the 90s and early 2000s.  I think it continues to be
> > underrated.  The main gripe people had was lack of security but if all
> > of the hosts were in the same security domain anyway it wouldn't matter.
>
> I'd like to hear more about the security issues.
>
> Did NIS(+) ever encrypt it's communications?  (I'm not counting things
> like IPsec transport.)
>
> I'm fairly certain that it was possible to enumerate the directory or
> otherwise scrape most (if not all) of it's contents.

There was `ypcat passwd`, wasn't there?

> > I did a lot of LDAP around 2007-2010.  I got quite good at writing
> > filters as we were using for a lot more than juse user auth.
>
> Ya.  The LDAP filters are why I tried to avoid just using LDAP against
> AD.  That and the fact that the Unix passwords were actually a separate
> field that could have different values from what the Windows systems used.

I would say that expecting to just pull password hashes from the
directory service – using it as nothing more than networked
/etc/shadow – is a bad approach to begin with. Let the client handle
authentication via Kerberos (or via whatever else is apropriate for
AD).

> > Most installations I'm seeing today auth to AD, which is of course now
> > supported.
>
> I'm curious what "supported" actually means.  I think there is
> preconfigured LDAP against AD templates, and things like Samba+Winbind.
> But all seem to be less native / seamless than NIS.


Could you elaborate on that?


> > In my experience LDAP is preferred in a pure *nix environment these
> > days. I've never played much with Kerberos.
>
> Does that mean that the authentication is also done across LDAP?  I hope
> that it's encrypted LDAP.


Standard TLS.

-- 
Mantas Mikulėnas

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Mantas Mikulėnas]

On Mon, Nov 5, 2018 at 9:24 AM Mantas Mikulėnas <grawity@gmail.com> wrote:
> > > In my experience LDAP is preferred in a pure *nix environment these
> > > days. I've never played much with Kerberos.
> >
> > Does that mean that the authentication is also done across LDAP?  I hope
> > that it's encrypted LDAP.

I replied to the second sentence, but missed the first one. Yes, many
places use LDAP for authentication.

Although strictly speaking LDAP is not an *authentication* protocol,
but it *is* a read/write protocol: the way you make updates to the
directory isn't by rebuilding it from a textfile, but by
authenticating and sending updates via LDAP itself. Naturally this
supports TLS for encrypting the channel.

Normally it isn't just the sysadmin who can do so, but every user can
also authenticate as themselves (i.e. "bind" to their own entry in
LDAP terms). Maybe they can't edit anything at all, maybe they can
edit only their own finger information, but they're usually able to
authenticate nevertheless.

And so many installations just turn this backwards and declare "If you
can successfully bind to the LDAP database, you must be a valid user".

-- 
Mantas Mikulėnas

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Arthur Krewat]

[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]

On 11/5/2018 2:24 AM, Mantas Mikulėnas wrote:
>> I'd like to hear more about the security issues.
>>
>> Did NIS(+) ever encrypt it's communications?  (I'm not counting things
>> like IPsec transport.)
>>
>> I'm fairly certain that it was possible to enumerate the directory or
>> otherwise scrape most (if not all) of it's contents.
> There was `ypcat passwd`, wasn't there?
>

It was possible, unless you used a network filter on the server, to just 
ypbind to the server, and then you could ypcat all the maps. Not to 
mention that without specifying a server, it was a broadcast. So any YP 
server on the subnet would answer.

NIS+ was encrypted over the network, and needed a public key mechanism 
to authenticate clients. One of which was the server itself. With it's 
hierarchical architecture, it had a lot of flexibility.

I really never understood why people didn't like NIS+. It took an extra 
step or two to do certain things, but once scripted it was a fairly 
secure way of handling authentication and directory services. I added 
new maps to it to do custom .cshrc/.profile scripts using subsections in 
/usr/local/profile, and a few other customizations. Add it's 
compatibility mode for NIS/YP, and you could use it to serve not only 
Sun clients.

Operationally, it really was just NIS/YP but with a lot of whiz-bang 
features. In a deployment of a few hundred mechanical and electrical 
engineers, with about 50 actual workstations and servers I never had a 
problem with it. Permissions and other features were actually quite useful.

However, I must say, I kept the NIS/YP way of using flat files to 
regenerate the NIS+ maps each time they were edited. So I guess I 
cheated a little.

art k.


[-- Attachment #2: Type: text/html, Size: 2275 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]

On 11/05/2018 09:12 AM, Arthur Krewat wrote:
> It was possible, unless you used a network filter on the server, to just 
> ypbind to the server, and then you could ypcat all the maps. Not to 
> mention that without specifying a server, it was a broadcast. So any YP 
> server on the subnet would answer.

Duly noted.  Thank you for the explanation.

> NIS+ was encrypted over the network, and needed a public key mechanism 
> to authenticate clients. One of which was the server itself. With it's 
> hierarchical architecture, it had a lot of flexibility.

The encryption would thwart snooping.  But it doesn't sound like that 
would prevent a properly authenticated client from ypcating too much 
information.

> I really never understood why people didn't like NIS+. It took an extra 
> step or two to do certain things, but once scripted it was a fairly 
> secure way of handling authentication and directory services.

I've heard a lot of people say they don't like something when they had 
something else that did what they needed / wanted (at the time) that 
required less work.  Occam's Razor / Parsimony....

> I added new maps to it to do custom .cshrc/.profile scripts using 
> subsections in /usr/local/profile, and a few other customizations. Add 
> it's compatibility mode for NIS/YP, and you could use it to serve not 
> only Sun clients.

Nice.

> Operationally, it really was just NIS/YP but with a lot of whiz-bang 
> features. In a deployment of a few hundred mechanical and electrical 
> engineers, with about 50 actual workstations and servers I never had a 
> problem with it. Permissions and other features were actually quite useful.

ACK

> However, I must say, I kept the NIS/YP way of using flat files to 
> regenerate the NIS+ maps each time they were edited. So I guess I 
> cheated a little.

Work smarter, not harder.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Arthur Krewat]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

On 11/5/2018 2:32 PM, Grant Taylor via TUHS wrote:
>
>> NIS+ was encrypted over the network, and needed a public key 
>> mechanism to authenticate clients. One of which was the server 
>> itself. With it's hierarchical architecture, it had a lot of 
>> flexibility.
>
> The encryption would thwart snooping.  But it doesn't sound like that 
> would prevent a properly authenticated client from ypcating too much 
> information.
Unless someone already replied and I didn't read it yet:

NIS/YP is different than NIS+. NIS/YP is the old protocol. You could 
basically bind to any server with the correct domain name, and look at 
all the maps including passwd with it's encrypted passwords.

NIS+ is the hierarchical, encrypted, clients-need-keys, protocol.

Almost two entirely different things. And "almost" is more like 
99.99999999999999999% different :)

ak

[-- Attachment #2: Type: text/html, Size: 1361 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]

On 11/05/2018 03:43 PM, Arthur Krewat wrote:
> NIS/YP is different than NIS+. NIS/YP is the old protocol. You could 
> basically bind to any server with the correct domain name, and look at 
> all the maps including passwd with it's encrypted passwords.
> 
> NIS+ is the hierarchical, encrypted, clients-need-keys, protocol.

ACK

> Almost two entirely different things. And "almost" is more like 
> 99.99999999999999999% different :)

I'm sorry, are you talking about NIS vs NIS+ or IPv4 vs IPv6?



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Arthur Krewat]

On 11/6/2018 12:25 AM, Grant Taylor via TUHS wrote:
> On 11/05/2018 03:43 PM, Arthur Krewat wrote:
>
>> Almost two entirely different things. And "almost" is more like 
>> 99.99999999999999999% different :)
>
> I'm sorry, are you talking about NIS vs NIS+ or IPv4 vs IPv6?
>
>
>

Not sure if that's humor or not ;)


NIS (YP) vs. NIS+

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 274 bytes --]

On 11/06/2018 09:50 AM, Arthur Krewat wrote:
> Not sure if that's humor or not ;)

Just spinning what I took as your humor about NIS vs NIS+ and 
reassigning it as my humor about IPv4 vs IPv6.  }:-)

> NIS (YP) vs. NIS+

ACK



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
> There was `ypcat passwd`, wasn't there?

I suppose.  I don't have any first hand experience with NIS(+).  So I'm 
trying to learn vicariously through others before I dive into any end of 
pool that is my lab network.

> I would say that expecting to just pull password hashes from the directory 
> service – using it as nothing more than networked /etc/shadow – is 
> a bad approach to begin with. Let the client handle authentication via 
> Kerberos (or via whatever else is apropriate for AD).

I think I naively thought there was some level of detail(s) sent between 
the client and the server such that the server would only return the 
pertinent information of the user being ypcated.  Thus (hopefully) 
preventing seeing other people's shadow information.

> Could you elaborate on that?

I thought that I'd seen equipment that /only/ used LDAP but had 
templates for the query to sidle up to AD's LDAP and things just worked. 
  I.e. you filled in enough details so that the template could construct 
the proper LDAP query.

This obviously is not joined to an AD domain and is really just an LDAP 
client.  (No Kerberos.)



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
> Let the client handle authentication via Kerberos

I don't know enough about Kerberos (yet) to know if it would be possible 
for a login process to communicate with the KDC and get a TGT as part of 
logging in, without already being logged in.

My ignorance is leaving me with a priming problem that seems like a 
catch 22.  You can't login without shadow information or TGT.  But 
traditional (simpler) kinit is run after being logged in.  So ... how do 
you detangle that?  The only thing that I can come up with is that the 
login process does the kinit functionality on the users behalf.

I can see how NIS(+) sans-shadow could still be useful.  I can also see 
how LDAP could be a close approximation / replacement for NIS(+) in this 
case.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Mantas Mikulėnas]

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

On Mon, Nov 5, 2018 at 11:00 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
> > Let the client handle authentication via Kerberos
>
> I don't know enough about Kerberos (yet) to know if it would be possible
> for a login process to communicate with the KDC and get a TGT as part of
> logging in, without already being logged in.
>

Sure, that's how the process of obtaining a TGT works in the first place.
You send an AS-REQ packet with proof of password knowledge, you get an
AS-REP with the TGT ticket back.

My ignorance is leaving me with a priming problem that seems like a
> catch 22.  You can't login without shadow information or TGT.  But
>

Not sure what part of the 'login' process you're referring to.

 * Credential verification? That's part of obtaining a TGT. You don't need
a ticket to obtain the TGT – instead you submit proof that you know the
password.

 * Retrieval of directory information (uid, gid, homedir)? The login
process either uses its own "machine" credentials to do so, or just
retrieves the information anonymously, depending on sysadmin's preference.
(Or in the case of AD it's already stapled to the TGT to speed everything
up.)


> traditional (simpler) kinit is run after being logged in.  So ... how do
> you detangle that?  The only thing that I can come up with is that the
> login process does the kinit functionality on the users behalf.
>

Yes, that's exactly what happens. However, probably not for all of the same
reasons as you imagine.

-- 
Mantas Mikulėnas

[-- Attachment #2: Type: text/html, Size: 2395 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

On 11/05/2018 02:36 PM, Mantas Mikulėnas wrote:
> Sure, that's how the process of obtaining a TGT works in the first 
> place. You send an AS-REQ packet with proof of password knowledge, you 
> get an AS-REP with the TGT ticket back.

Thank you for confirming that such is possible.

> Not sure what part of the 'login' process you're referring to.

Vaguely ... /bin/login or the login prompt from SSH (which I /think/ is 
independent of /bin/login.)

>   * Credential verification? That's part of obtaining a TGT. You don't 
> need a ticket to obtain the TGT – instead you submit proof that you know 
> the password.
> 
>   * Retrieval of directory information (uid, gid, homedir)? The login 
> process either uses its own "machine" credentials to do so, or just 
> retrieves the information anonymously, depending on sysadmin's 
> preference. (Or in the case of AD it's already stapled to the TGT to 
> speed everything up.)

Thank you for explaining.

> Yes, that's exactly what happens. However, probably not for all of the 
> same reasons as you imagine.

ACK



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Ben Greenfield via TUHS]

> On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:
> 
> On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
>> Let the client handle authentication via Kerberos
> 
> I don't know enough about Kerberos (yet) to know if it would be possible for a login process to communicate with the KDC and get a TGT as part of logging in, without already being logged in.
> 
> My ignorance is leaving me with a priming problem that seems like a catch 22.  You can't login without shadow information or TGT.  But traditional (simpler) kinit is run after being logged in.  So ... how do you detangle that?  The only thing that I can come up with is that the login process does the kinit functionality on the users behalf.

I found that I had to do all of this using SASL. 


I remember it as SASL would handle the kerberization during boot up getting tickets for each LDAP entry that you wanted mapped to a service on that client.

I could be wrong but I think SASL seems to be way connect services on Linux with LDAP that are served kerberized.


Thanks,

Ben

> 
> I can see how NIS(+) sans-shadow could still be useful.  I can also see how LDAP could be a close approximation / replacement for NIS(+) in this case.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

On 11/05/2018 02:43 PM, Ben Greenfield via TUHS wrote:
> I found that I had to do all of this using SASL.

At first read I was thinking "SASL?  Really?".  Then I remembered that 
Simple Authentication and Security Layer is really just an abstraction 
layer.  An abstraction layer that very easily could have (but I don't 
know one way or the other) a back end to Kerberos.

> I remember it as SASL would handle the kerberization during boot up 
> getting tickets for each LDAP entry that you wanted mapped to a service 
> on that client.

Hum.

> I could be wrong but I think SASL seems to be way connect services on 
> Linux with LDAP that are served kerberized.

I've always viewed SASL as a way for applications to outsource the 
authentication / security so that the program code didn't need to worry 
about it.  It also allowed SASL to manage supporting all the different 
back end security methods.

I also think much the same about PAM.  -  In fact, I don't think I could 
properly differentiate between PAM and SASL.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Ben Greenfield via TUHS]

> On Nov 5, 2018, at 11:58 PM, Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:
> 
> On 11/05/2018 02:43 PM, Ben Greenfield via TUHS wrote:
>> I found that I had to do all of this using SASL.
> 
> At first read I was thinking "SASL?  Really?".  Then I remembered that Simple Authentication and Security Layer is really just an abstraction layer.  An abstraction layer that very easily could have (but I don't know one way or the other) a back end to Kerberos.
> 
>> I remember it as SASL would handle the kerberization during boot up getting tickets for each LDAP entry that you wanted mapped to a service on that client.
> 
> Hum.
> 
>> I could be wrong but I think SASL seems to be way connect services on Linux with LDAP that are served kerberized.
> 
> I've always viewed SASL as a way for applications to outsource the authentication / security so that the program code didn't need to worry about it.  It also allowed SASL to manage supporting all the different back end security methods.
> 
> I also think much the same about PAM.  -  In fact, I don't think I could properly differentiate between PAM and SASL.

Yes, pam when I was trying to figure out how to put it altogether PAM was always working in the background but I believe it was the SASL configs that pointed to my Open Directory server that centralized our Linux accounts. So as strange as it may seem to some there have be instances were OS X served Linux clients:)



> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Mantas Mikulėnas]

[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]

On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS <tuhs@minnie.tuhs.org>
wrote:

>
>
> > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
> wrote:
> >
> > On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
> >> Let the client handle authentication via Kerberos
> >
> > I don't know enough about Kerberos (yet) to know if it would be possible
> for a login process to communicate with the KDC and get a TGT as part of
> logging in, without already being logged in.
> >
> > My ignorance is leaving me with a priming problem that seems like a
> catch 22.  You can't login without shadow information or TGT.  But
> traditional (simpler) kinit is run after being logged in.  So ... how do
> you detangle that?  The only thing that I can come up with is that the
> login process does the kinit functionality on the users behalf.
>
> I found that I had to do all of this using SASL.
>
>
> I remember it as SASL would handle the kerberization during boot up
> getting tickets for each LDAP entry that you wanted mapped to a service on
> that client.
>

Sorry but I cannot parse that sentence at all...


> I could be wrong but I think SASL seems to be way connect services on
> Linux with LDAP that are served kerberized.
>

SASL is involved somewhat, in that it does help with implementing Kerberos
– services and clients can call libsasl instead of talking Kerberos
directly, abstract away the complexity – but that's all it is, an
abstraction layer. (A quite useful one, though.)

But it's not the only method, strictly speaking (e.g. SSH and HTTP use
GSSAPI, and various older software use Kerberos directly). And as far as I
could understand the previous paragraph – it doesn't have anything specific
about "kerberization during boot up".

[-- Attachment #2: Type: text/html, Size: 2459 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Ben Greenfield via TUHS]

[-- Attachment #1: Type: text/plain, Size: 2528 bytes --]



> On Nov 6, 2018, at 1:53 AM, Mantas Mikulėnas <grawity@gmail.com> wrote:
> 
> On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS <tuhs@minnie.tuhs.org <mailto:tuhs@minnie.tuhs.org>> wrote:
> 
> 
> > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS <tuhs@minnie.tuhs.org <mailto:tuhs@minnie.tuhs.org>> wrote:
> > 
> > On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
> >> Let the client handle authentication via Kerberos
> > 
> > I don't know enough about Kerberos (yet) to know if it would be possible for a login process to communicate with the KDC and get a TGT as part of logging in, without already being logged in.
> > 
> > My ignorance is leaving me with a priming problem that seems like a catch 22.  You can't login without shadow information or TGT.  But traditional (simpler) kinit is run after being logged in.  So ... how do you detangle that?  The only thing that I can come up with is that the login process does the kinit functionality on the users behalf.
> 
> I found that I had to do all of this using SASL. 
> 
> 
> I remember it as SASL would handle the kerberization during boot up getting tickets for each LDAP entry that you wanted mapped to a service on that client.
> 
> Sorry but I cannot parse that sentence at all…


I’m sorry it was about 8 years ago and is from memory but. I believe during the startup of the system the SASL config files contained tickets that established a trust relationship between that system and our Open Directory server. My memory is that each ticket was associated a service and the config file for the service  would point to the ticket.

> 
> I could be wrong but I think SASL seems to be way connect services on Linux with LDAP that are served kerberized.
>  
> SASL is involved somewhat, in that it does help with implementing Kerberos – services and clients can call libsasl instead of talking Kerberos directly, abstract away the complexity – but that's all it is, an abstraction layer. (A quite useful one, though.)
> 
> But it's not the only method, strictly speaking (e.g. SSH and HTTP use GSSAPI, and various older software use Kerberos directly). And as far as I could understand the previous paragraph – it doesn't have anything specific about "kerberization during boot up”.


My memory could be wrong but I thought to establish the trust relationship between the kerberized server and the client happened during boot/when the config files were read ticket granting tickets were given and received. 




[-- Attachment #2: Type: text/html, Size: 4955 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Mantas Mikulėnas]

[-- Attachment #1: Type: text/plain, Size: 3763 bytes --]

On Tue, Nov 6, 2018 at 3:21 PM Ben Greenfield <ben@cogs.com> wrote:

>
>
> On Nov 6, 2018, at 1:53 AM, Mantas Mikulėnas <grawity@gmail.com> wrote:
>
> On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS <tuhs@minnie.tuhs.org>
> wrote:
>
>>
>>
>> > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
>> wrote:
>> >
>> > On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
>> >> Let the client handle authentication via Kerberos
>> >
>> > I don't know enough about Kerberos (yet) to know if it would be
>> possible for a login process to communicate with the KDC and get a TGT as
>> part of logging in, without already being logged in.
>> >
>> > My ignorance is leaving me with a priming problem that seems like a
>> catch 22.  You can't login without shadow information or TGT.  But
>> traditional (simpler) kinit is run after being logged in.  So ... how do
>> you detangle that?  The only thing that I can come up with is that the
>> login process does the kinit functionality on the users behalf.
>>
>> I found that I had to do all of this using SASL.
>>
>>
>> I remember it as SASL would handle the kerberization during boot up
>> getting tickets for each LDAP entry that you wanted mapped to a service on
>> that client.
>>
>
> Sorry but I cannot parse that sentence at all…
>
>
>
> I’m sorry it was about 8 years ago and is from memory but. I believe
> during the startup of the system the SASL config files contained tickets
> that established a trust relationship between that system and our Open
> Directory server. My memory is that each ticket was associated a service
> and the config file for the service  would point to the ticket.
>
>
>> I could be wrong but I think SASL seems to be way connect services on
>> Linux with LDAP that are served kerberized.
>>
>
> SASL is involved somewhat, in that it does help with implementing Kerberos
> – services and clients can call libsasl instead of talking Kerberos
> directly, abstract away the complexity – but that's all it is, an
> abstraction layer. (A quite useful one, though.)
>
> But it's not the only method, strictly speaking (e.g. SSH and HTTP use
> GSSAPI, and various older software use Kerberos directly). And as far as I
> could understand the previous paragraph – it doesn't have anything specific
> about "kerberization during boot up”.
>
>
> My memory could be wrong but I thought to establish the trust relationship
> between the kerberized server and the client happened during boot/when the
> config files were read ticket granting tickets were given and received.
>

No, kerberized servers don't obtain own tickets – unless they themselves
act as *clients* to another kerberized service.

Trust relationships between the server and KDC (as well as between the
client and KDC) are just based on it knowing the same shared secret as the
KDC does. For clients that's the password, for server's that's usually the
raw key in /etc/krb5.keytab.

As for the trust relationship between client and server – if I remember the
protocol correctly, at this point it becomes asymmetric. When a client
sends its ticket to the server, the server will just decrypt it using its
own key (keytab) without any KDC involvement. On success, it knows that
it's a legitimate ticket because only the KDC could have encrypted it –
whereas the client knows that only the real server will be able to decrypt
it.

The main reason a server might obtain tickets on boot is because it *also*
acts as client to another kerberized service. (For example, a web server
might be a client of a fileserver. An SSH shell server might be a client of
an LDAP directory server.)

-- 
Mantas Mikulėnas

[-- Attachment #2: Type: text/html, Size: 5846 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Ben Greenfield via TUHS]

[-- Attachment #1: Type: text/plain, Size: 3957 bytes --]



> On Nov 6, 2018, at 8:44 AM, Mantas Mikulėnas <grawity@gmail.com> wrote:
> 
> On Tue, Nov 6, 2018 at 3:21 PM Ben Greenfield <ben@cogs.com <mailto:ben@cogs.com>> wrote:
> 
> 
>> On Nov 6, 2018, at 1:53 AM, Mantas Mikulėnas <grawity@gmail.com <mailto:grawity@gmail.com>> wrote:
>> 
>> On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS <tuhs@minnie.tuhs.org <mailto:tuhs@minnie.tuhs.org>> wrote:
>> 
>> 
>> > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS <tuhs@minnie.tuhs.org <mailto:tuhs@minnie.tuhs.org>> wrote:
>> > 
>> > On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
>> >> Let the client handle authentication via Kerberos
>> > 
>> > I don't know enough about Kerberos (yet) to know if it would be possible for a login process to communicate with the KDC and get a TGT as part of logging in, without already being logged in.
>> > 
>> > My ignorance is leaving me with a priming problem that seems like a catch 22.  You can't login without shadow information or TGT.  But traditional (simpler) kinit is run after being logged in.  So ... how do you detangle that?  The only thing that I can come up with is that the login process does the kinit functionality on the users behalf.
>> 
>> I found that I had to do all of this using SASL. 
>> 
>> 
>> I remember it as SASL would handle the kerberization during boot up getting tickets for each LDAP entry that you wanted mapped to a service on that client.
>> 
>> Sorry but I cannot parse that sentence at all…
> 
> 
> I’m sorry it was about 8 years ago and is from memory but. I believe during the startup of the system the SASL config files contained tickets that established a trust relationship between that system and our Open Directory server. My memory is that each ticket was associated a service and the config file for the service  would point to the ticket.
> 
>> 
>> I could be wrong but I think SASL seems to be way connect services on Linux with LDAP that are served kerberized.
>>  
>> SASL is involved somewhat, in that it does help with implementing Kerberos – services and clients can call libsasl instead of talking Kerberos directly, abstract away the complexity – but that's all it is, an abstraction layer. (A quite useful one, though.)
>> 
>> But it's not the only method, strictly speaking (e.g. SSH and HTTP use GSSAPI, and various older software use Kerberos directly). And as far as I could understand the previous paragraph – it doesn't have anything specific about "kerberization during boot up”.
> 
> 
> My memory could be wrong but I thought to establish the trust relationship between the kerberized server and the client happened during boot/when the config files were read ticket granting tickets were given and received. 
> 
> No, kerberized servers don't obtain own tickets – unless they themselves act as *clients* to another kerberized service.

Which might be what I’m trying to describe.


> 
> Trust relationships between the server and KDC (as well as between the client and KDC) are just based on it knowing the same shared secret as the KDC does. For clients that's the password, for server's that's usually the raw key in /etc/krb5.keytab.
> 
> As for the trust relationship between client and server – if I remember the protocol correctly, at this point it becomes asymmetric. When a client sends its ticket to the server, the server will just decrypt it using its own key (keytab) without any KDC involvement. On success, it knows that it's a legitimate ticket because only the KDC could have encrypted it – whereas the client knows that only the real server will be able to decrypt it.
> 
> The main reason a server might obtain tickets on boot is because it *also* acts as client to another kerberized service. (For example, a web server might be a client of a fileserver. An SSH shell server might be a client of an LDAP directory server.)
> 
> -- 
> Mantas Mikulėnas


[-- Attachment #2: Type: text/html, Size: 7270 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Mantas Mikulėnas]

[-- Attachment #1: Type: text/plain, Size: 1890 bytes --]

On Tue, Nov 6, 2018 at 3:21 PM Ben Greenfield <ben@cogs.com> wrote:

>
>
> On Nov 6, 2018, at 1:53 AM, Mantas Mikulėnas <grawity@gmail.com> wrote:
>
> On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS <tuhs@minnie.tuhs.org>
> wrote:
>
>>
>>
>> > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
>> wrote:
>> >
>> > On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
>> >> Let the client handle authentication via Kerberos
>> >
>> > I don't know enough about Kerberos (yet) to know if it would be
>> possible for a login process to communicate with the KDC and get a TGT as
>> part of logging in, without already being logged in.
>> >
>> > My ignorance is leaving me with a priming problem that seems like a
>> catch 22.  You can't login without shadow information or TGT.  But
>> traditional (simpler) kinit is run after being logged in.  So ... how do
>> you detangle that?  The only thing that I can come up with is that the
>> login process does the kinit functionality on the users behalf.
>>
>> I found that I had to do all of this using SASL.
>>
>>
>> I remember it as SASL would handle the kerberization during boot up
>> getting tickets for each LDAP entry that you wanted mapped to a service on
>> that client.
>>
>
> Sorry but I cannot parse that sentence at all…
>
>
>
> I’m sorry it was about 8 years ago and is from memory but. I believe
> during the startup of the system the SASL config files contained tickets
> that established a trust relationship between that system and our Open
> Directory server. My memory is that each ticket was associated a service
> and the config file for the service  would point to the ticket.
>

Upon rereading this, you're probably thinking of keytabs (which hold static
pre-provisioned keys) rather than tickets (which hold session keys).

-- 
Mantas Mikulėnas

[-- Attachment #2: Type: text/html, Size: 3407 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 7934 bytes --]

On Mon, Nov 5, 2018 at 4:00 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
> > Let the client handle authentication via Kerberos
>
> I don't know enough about Kerberos (yet) to know if it would be possible
> for a login process to communicate with the KDC and get a TGT as part of
> logging in, without already being logged in.
>
> My ignorance is leaving me with a priming problem that seems like a
> catch 22.  You can't login without shadow information or TGT.  But
> traditional (simpler) kinit is run after being logged in.  So ... how do
> you detangle that?  The only thing that I can come up with is that the
> login process does the kinit functionality on the users behalf.
>

You can use a modified `login` that will validate you against a KDC.

The way it works is to set up a host key for the host you're logging into;
that is then used to authenticate the *host* to the KDC, which then allows
it to validate a user against the KDC and issue the user a TGT at the same
time. This works well for e.g. console and X logins.

Modifications have been made to e.g. SSH so that one can authenticate an
SSH session via GSSAPI, which usually wraps Kerberos. If I recall, GSSAPI
might be one of the lasting legacies of the DCE, though I may be
misremembering history.

I can see how NIS(+) sans-shadow could still be useful.  I can also see
> how LDAP could be a close approximation / replacement for NIS(+) in this
> case.
>

Security, in general, usually seeks to address five questions:

1. Authentication - Is some entity who it claims to be?
2. Authorization - Is some entity allowed to perform some action?
3. Privacy - Can a third party snoop on a private conversation between two
entities?
4. Integrity - Can a third party alter communications between two entities
in an undetectable way?
5. Non-repudiation - Can it be definitively shown that some entity was a
party to some communication?

Kerberos is a authentication protocol.

LDAP, YP (retroactively named NIS after a lawsuit involving, I believe,
British Telecomm), NIS+, NetInfo, Active Directory, and Hesiod are all
examples of directory services. To a first-order approximation, one might
think of a directory service as providing an oracle allowing one to
discover what entities exist in some domain.

Authentication protocols and directory services solve different problems.
Though in true Micro$oft-of-old fashion, AD sort of merged both.

Kerberos solves the authentication problem, but does not provide a
directory service nor does it solve the authorization problem (though some
"kerberized" services could use a library to consult a user-provided file
of ACLs mapping principals to privileges). On Unix, "authorization data"
includes things like your UID and the set of groups you belong to (or more
precisely, your process's UIDs and GIDs/groups). Kerberos provided support
for privacy via encryption libraries, and it provided support for integrity
via hashing/checksumming/signature libraries. "Kerberized" versions of
network services such as telnet, FTP, rsh/rlogin/rcp etc all provided
support for authentication via the baseline Kerberos protocol as well as
privacy and integrity via connection-level encryption and checksumming.
Kerberos provided a replay cache, but otherwise provided only limited
support for non-repudiation via mutual authentication through the KDC (that
is, clients authenticated to servers, but servers also authenticated to
clients). So while a KDC might tell you whether the principal connecting to
your SSH service is really "cross@GAJENDRA.NET", it won't tell you your
UID, what shell you use, the path to your home directory, what groups you
are a member of, or what finger should say for your real name.

In its pure form, SSH provides support for limited authentication (via
public key cryptography and the wide distribution of public keys) and
limited authorization (via the `authorized_keys` file), privacy and
integrity.

LDAP might provide you some mechanism to look up a user record that
provides those details; it may also provide some kind of hashed password
that a system can use to validate a password, but it won't do much better
than that. I suppose you could put an authorized SSH public key into an
LDAP directory in the same way you would put a hashed password.

NIS was based on Sun RPC; as was mentioned earlier, anyone on a network
could bind to an NIS server and query it to get e.g., hashed password file
entries that they could run crack against. Nothing was encrypted. There was
a system for a user to update his/her information in the NIS database
(e.g., this was how you changed your password or set your shell or updated
your office phone number...), but the "authentication" was just checking
your password; again nothing was encrypted, so a malicious third party on
your network could in theory mount a man-in-the-middle attack against you
and inject his/her own data into the transaction and take over your account.

NIS+ improved on this, but wasn't universally supported across systems and
we lost some useful NIS functionality: back in the NIS days, you could
supplement the contents of /etc/passwd with the NIS passwd maps, but keep
local overrides (e.g., for anyone not in the `@staff` netgroup, set shell
to `/sbin/nologin` on servers); perhaps there was a way to do this with
NIS+ but it felt very much like a binary thing: you were either all in on
NIS+ or not at all. Mixing and matching just wasn't as easy as it had been.
Also, the symmetric crypto was, I think, DES based and as that fell apart I
don't recall it getting much better. So unless you were all Sun based (and
many of us had heterogenous systems to worry about; my shops supported Suns
running SunOS 4 and Solaris 2, SGIs running Irix, HP-UX machines, Alphas
running OSF/1 then DEC Unix then Tru64, DECstations running Ultrix,
RS/6000's running AIX, RTs running AOS, a few NeXTs, PCs running Linux *BSD
and PCs running Windows and Macs. Oh, and VMS on VAXen and Alphas. Yay.
Elsewhere on campus we had a mainframe running VM/ESA, a couple of Crays,
some AS/400s; we also had a few plan9 machines. We even had a PDP-10
running TOPS-10 at some point. Good ol' YP cut across the widest swath of
these so that's what we ran the longest, but it was a more innocent time,
network access was more tightly controlled and it wasn't quite as dangerous
to run something like ypserv.

I thought for a while that LDAP would be the light and the way, but it was
really a lot more general than what I cared about just for Unix system
administration. Setting it up wasn't as easy as NIS, or even NIS+ for that
matter.

Netinfo came from NeXT and survived into Macos for a little while. It was
kind of neat but again the all-singing, all-dancing solution to the world.
No one else really used it.

Hesiod, which seems unique to Athena, was kind of neat; it piggy-backed the
need for a directory service on DNS, which is already a distributed
directory service. You embedded relevant data into DNS TXT records, so
imagine doing a DNS query to look up a user's /etc/passwd entry: after all,
DNS already scaled and was well-proven Internet-wide. I don't know that
anyone ever really supported it, though.

So yeah. Kerberos is plenty fine for authentication for small to medium
sites (up to mid tens of thousands of users, I'd guess), but won't help you
distribute your authorization data. You need a directory service or some
other mechanism for that. Directory services will help you with that, but
usually don't do a great job at authentication, though they may provide the
means to distributed the data that other systems can use for that. Of the
directory services out there these days, LDAP seems to have "won".

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 8992 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 9329 bytes --]

On 11/05/2018 03:34 PM, Dan Cross wrote:
> You can use a modified `login` that will validate you against a KDC.

ACK

> The way it works is to set up a host key for the host you're logging 
> into; that is then used to authenticate the *host* to the KDC, which 
> then allows it to validate a user against the KDC and issue the user a 
> TGT at the same time. This works well for e.g. console and X logins.

That makes sense.

> Modifications have been made to e.g. SSH so that one can authenticate an 
> SSH session via GSSAPI, which usually wraps Kerberos. If I recall, 
> GSSAPI might be one of the lasting legacies of the DCE, though I may be 
> misremembering history.

*nod*

Generic Security Service Application Program Interface - The abstraction 
layer that (as far as I know) only had one service behind it.

> Security, in general, usually seeks to address five questions:
> 
> 1. Authentication - Is some entity who it claims to be?
> 2. Authorization - Is some entity allowed to perform some action?
> 3. Privacy - Can a third party snoop on a private conversation between 
> two entities?
> 4. Integrity - Can a third party alter communications between two 
> entities in an undetectable way?
> 5. Non-repudiation - Can it be definitively shown that some entity was a 
> party to some communication?

The 3rd A that I'm used to is "Access Control".  Is the requested action 
allowed given the above information.

> Kerberos is a authentication protocol.
> 
> LDAP, YP (retroactively named NIS after a lawsuit involving, I believe, 
> British Telecomm), NIS+, NetInfo, Active Directory, and Hesiod are all 
> examples of directory services. To a first-order approximation, one 
> might think of a directory service as providing an oracle allowing one 
> to discover what entities exist in some domain.
> 
> Authentication protocols and directory services solve different 
> problems. Though in true Micro$oft-of-old fashion, AD sort of merged both.

I would argue that a directory including shadow information (like 
NIS(+)) does both too.

> Kerberos solves the authentication problem, but does not provide a 
> directory service nor does it solve the authorization problem (though 
> some "kerberized" services could use a library to consult a 
> user-provided file of ACLs mapping principals to privileges). On Unix, 
> "authorization data" includes things like your UID and the set of groups 
> you belong to (or more precisely, your process's UIDs and GIDs/groups). 
> Kerberos provided support for privacy via encryption libraries, and it 
> provided support for integrity via hashing/checksumming/signature 
> libraries. "Kerberized" versions of network services such as telnet, 
> FTP, rsh/rlogin/rcp etc all provided support for authentication via the 
> baseline Kerberos protocol as well as privacy and integrity via 
> connection-level encryption and checksumming.

I was not aware that Kerberos could provide privacy (encryption) for 
kerberized services.  I (naively) thought that Kerberos was 
authentication that other things could use to make access control decisions.

> Kerberos provided a replay cache, but otherwise provided only limited 
> support for non-repudiation via mutual authentication through the 
> KDC (that is, clients authenticated to servers, but servers also 
> authenticated to clients).

*nod*  I think NT4 domains and AD both had the same type of client to 
server mutual trust.  (At least for NT derived clients with machine 
trust accounts.)

> So while a KDC might tell you whether the principal connecting to your 
> SSH service is really "cross@GAJENDRA.NET <mailto:cross@GAJENDRA.NET>", 
> it won't tell you your UID, what shell you use, the path to your home 
> directory, what groups you are a member of, or what finger should say 
> for your real name.

*nod*nod*nod*

That's why the directory component is so important.  Somewhere to get 
all that other information.

> In its pure form, SSH provides support for limited authentication (via 
> public key cryptography and the wide distribution of public keys) and 
> limited authorization (via the `authorized_keys` file), privacy and 
> integrity.

I think that OpenSSH's certificate support extends that a bit.

> LDAP might provide you some mechanism to look up a user record that 
> provides those details; it may also provide some kind of hashed password 
> that a system can use to validate a password, but it won't do much 
> better than that. I suppose you could put an authorized SSH public key 
> into an LDAP directory in the same way you would put a hashed password.

I've always viewed LDAP as a directory that can have various content in 
it.  It then makes this content relatively easy to access.  What the 
content is is up to the content consumer.  Be it names, email addresses, 
shells, or password hashes.

> NIS was based on Sun RPC; as was mentioned earlier, anyone on a network 
> could bind to an NIS server and query it to get e.g., hashed password 
> file entries that they could run crack against. Nothing was encrypted.

Even if communications with the NIS server was encrypted, I'm not 
hearing anything that prevents an authenticated user from enumerating 
NIS.  Even if it was over encrypted channels.

> There was a system for a user to update his/her information in the NIS 
> database (e.g., this was how you changed your password or set your shell 
> or updated your office phone number...), but the "authentication" was 
> just checking your password; again nothing was encrypted, so a malicious 
> third party on your network could in theory mount a man-in-the-middle 
> attack against you and inject his/her own data into the transaction and 
> take over your account.

ACK

> NIS+ improved on this, but wasn't universally supported across systems 
> and we lost some useful NIS functionality: back in the NIS days, you 
> could supplement the contents of /etc/passwd with the NIS passwd maps, 
> but keep local overrides (e.g., for anyone not in the `@staff` netgroup, 
> set shell to `/sbin/nologin` on servers); perhaps there was a way to do 
> this with NIS+ but it felt very much like a binary thing: you were 
> either all in on NIS+ or not at all. Mixing and matching just wasn't as 
> easy as it had been. Also, the symmetric crypto was, I think, DES based 
> and as that fell apart I don't recall it getting much better. So unless 
> you were all Sun based (and many of us had heterogenous systems to worry 
> about; my shops supported Suns running SunOS 4 and Solaris 2, SGIs 
> running Irix, HP-UX machines, Alphas running OSF/1 then DEC Unix then 
> Tru64, DECstations running Ultrix, RS/6000's running AIX, RTs running 
> AOS, a few NeXTs, PCs running Linux *BSD and PCs running Windows and 
> Macs. Oh, and VMS on VAXen and Alphas. Yay. Elsewhere on campus we had a 
> mainframe running VM/ESA, a couple of Crays, some AS/400s; we also had a 
> few plan9 machines. We even had a PDP-10 running TOPS-10 at some point. 
> Good ol' YP cut across the widest swath of these so that's what we ran 
> the longest, but it was a more innocent time, network access was more 
> tightly controlled and it wasn't quite as dangerous to run something 
> like ypserv.

*nod*

> I thought for a while that LDAP would be the light and the way, but it 
> was really a lot more general than what I cared about just for Unix 
> system administration. Setting it up wasn't as easy as NIS, or even NIS+ 
> for that matter.

That's what I've gathered from a number of sources.  Which is why I've 
heard people avoid LDAP directly.  Or at least use something like 
Samba+Winbind or SSSD as an abstraction layer into LDAP+Kerberos.

> Netinfo came from NeXT and survived into Macos for a little while. It 
> was kind of neat but again the all-singing, all-dancing solution to the 
> world. No one else really used it.

Typical.

> Hesiod, which seems unique to Athena, was kind of neat; it piggy-backed 
> the need for a directory service on DNS, which is already a distributed 
> directory service. You embedded relevant data into DNS TXT records, so 
> imagine doing a DNS query to look up a user's /etc/passwd entry: after 
> all, DNS already scaled and was well-proven Internet-wide. I don't know 
> that anyone ever really supported it, though.

I know that Red Hat Linux did have support for it.  One of my colleagues 
was a Hesiod maintainer for a while.

> So yeah. Kerberos is plenty fine for authentication for small to medium 
> sites (up to mid tens of thousands of users, I'd guess), but won't help 
> you distribute your authorization data. You need a directory service or 
> some other mechanism for that. Directory services will help you with 
> that, but usually don't do a great job at authentication, though they 
> may provide the means to distributed the data that other systems can use 
> for that. Of the directory services out there these days, LDAP seems to 
> have "won".

(Raw) LDAP and AD seem to be what I see the most of.  I've worked in a 
few shops that evolved their NDS into eDirectory with appropriate 
clients for other platforms.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Mantas Mikulėnas]

[-- Attachment #1: Type: text/plain, Size: 2669 bytes --]

On Tue, Nov 6, 2018 at 8:40 AM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> On 11/05/2018 03:34 PM, Dan Cross wrote:
> > You can use a modified `login` that will validate you against a KDC.
>
> ACK
>

These days the modification generally consists of pam_krb5 added to the
system's PAM configuration.


> > Modifications have been made to e.g. SSH so that one can authenticate an
> > SSH session via GSSAPI, which usually wraps Kerberos. If I recall,
> > GSSAPI might be one of the lasting legacies of the DCE, though I may be
> > misremembering history.
>
> *nod*
>

And similarly – in other protocols (IMAP, SMTP, IRC, the same LDAP) one can
authenticate a session via SASL, which usually wraps GSSAPI, which usually
wraps Kerberos.

> Kerberos solves the authentication problem, but does not provide a
> > directory service nor does it solve the authorization problem (though
> > some "kerberized" services could use a library to consult a
> > user-provided file of ACLs mapping principals to privileges). On Unix,
> > "authorization data" includes things like your UID and the set of groups
> > you belong to (or more precisely, your process's UIDs and GIDs/groups).
> > Kerberos provided support for privacy via encryption libraries, and it
> > provided support for integrity via hashing/checksumming/signature
> > libraries. "Kerberized" versions of network services such as telnet,
> > FTP, rsh/rlogin/rcp etc all provided support for authentication via the
> > baseline Kerberos protocol as well as privacy and integrity via
> > connection-level encryption and checksumming.
>
> I was not aware that Kerberos could provide privacy (encryption) for
> kerberized services.  I (naively) thought that Kerberos was
> authentication that other things could use to make access control
> decisions.
>

You're right, it's primarily an authentication protocol. But due to the way
it works, it *also* negotiates a 'session key' between the user and the
service, which then may be used for transport encryption (sealing). It's
not commonly used as far as I know – most new protocols already have their
own security layers such as TLS or SSH.

Actually LDAP is the only still-widespread protocol that comes to mind
whose implementations frequently make use of Kerberos-based encryption (via
GSSAPI). This is especially common in Active Directory environments, where
the DCs might not have a valid TLS certificate.

(I seem to recall kerberized Telnet didn't survive because it was limited
to DES/3DES for an odd reason. Didn't quite understand why that was the
case, though.)

-- 
Mantas Mikulėnas

[-- Attachment #2: Type: text/html, Size: 3551 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 2289 bytes --]

On 11/06/2018 12:07 AM, Mantas Mikulėnas wrote:
> These days the modification generally consists of pam_krb5 added to the 
> system's PAM configuration.

Hum....  I need to do some reading on that.

> And similarly – in other protocols (IMAP, SMTP, IRC, the same LDAP) one 
> can authenticate a session via SASL, which usually wraps GSSAPI, which 
> usually wraps Kerberos.

*nod*

Complicating things is that implementations can choose to bypass SASL 
and do the GSSAPI interaction directly.  Or take things even further and 
do the Kerberos interaction directly.

Yet another reason why all these things are complicated.  So many 
choices that impact other choices in the same problem domain.

> You're right, it's primarily an authentication protocol.

:-)

> But due to the way it works, it *also* negotiates a 'session key' between 
> the user and the service, which then may be used for transport encryption 
> (sealing).

Does that mean that the protocols would need to retain the session key 
and use it for their other non-Kerberos specific protocols?  I.e. the 
rsh daemon would need to use the session key to encrypt / decrypt the 
rsh data, after and independent of the Kerberos authentication process.

> It's not commonly used as far as I know – most new protocols already 
> have their own security layers such as TLS or SSH.

ACK

I worry that other encryption protocols / methods have far surpassed 
Kerberos' encryption capability / strength.

> Actually LDAP is the only still-widespread protocol that comes to mind 
> whose implementations frequently make use of Kerberos-based encryption 
> (via GSSAPI).

O.o‽

This sounds like it would be independent of LDAP over SSL (TCP 636).

Would this Kerberos specified encryption be run over the standard LDAP 
port (TCP 389)?

> This is especially common in Active Directory environments, where the 
> DCs might not have a valid TLS certificate.

O.o‽

I'm going to have to go pick my AD guru's brain after reading that.

> (I seem to recall kerberized Telnet didn't survive because it was 
> limited to DES/3DES for an odd reason. Didn't quite understand why that 
> was the case, though.)

#questionsQuestions



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Mantas Mikulėnas]

[-- Attachment #1: Type: text/plain, Size: 4062 bytes --]

On Tue, Nov 6, 2018 at 9:18 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> On 11/06/2018 12:07 AM, Mantas Mikulėnas wrote:
> > These days the modification generally consists of pam_krb5 added to the
> > system's PAM configuration.
>
> Hum....  I need to do some reading on that.
>
> > And similarly – in other protocols (IMAP, SMTP, IRC, the same LDAP) one
> > can authenticate a session via SASL, which usually wraps GSSAPI, which
> > usually wraps Kerberos.
>
> *nod*
>
> Complicating things is that implementations can choose to bypass SASL
> and do the GSSAPI interaction directly.  Or take things even further and
> do the Kerberos interaction directly.
>

Though from what I've seen on their mailing list, MIT Kerberos developers
seem to recommend using GSSAPI at minimum, rather than the raw Kerberos
APIs.


>
> Yet another reason why all these things are complicated.  So many
> choices that impact other choices in the same problem domain.
>
> > You're right, it's primarily an authentication protocol.
>
> :-)
>
> > But due to the way it works, it *also* negotiates a 'session key'
> between
> > the user and the service, which then may be used for transport
> encryption
> > (sealing).
>
> Does that mean that the protocols would need to retain the session key
> and use it for their other non-Kerberos specific protocols?  I.e. the
> rsh daemon would need to use the session key to encrypt / decrypt the
> rsh data, after and independent of the Kerberos authentication process.
>

Well, they can use it, but they don't have to. It's up to the developer in
the end. The earlier kerberized protocols did, because they didn't have any
other encryption layer. Most recent protocols establish encryption in any
case (be it TLS or SSHv2 or something else) so they just don't bother
calling the SASL (or GSSAPI) seal functions.


>
> > It's not commonly used as far as I know – most new protocols already
> > have their own security layers such as TLS or SSH.
>
> ACK
>
> I worry that other encryption protocols / methods have far surpassed
> Kerberos' encryption capability / strength.
>

Kerberos does include modern enctypes (such as aes128/aes256), but from
what *little* I understand about this part, it's still not as good as the
modern protocols. (E.g. complete lack of PFS – the same client or server
always uses the same master key until it's manually rotated...)

On the bright side, the *authentication* of Kerberos is solid as far as
I've heard. (Which, again I know very little about this part, but I do
remember someone saying that it has an actual security proof, as well as
being decently quantum-resistant.)


>
> > Actually LDAP is the only still-widespread protocol that comes to mind
> > whose implementations frequently make use of Kerberos-based encryption
> > (via GSSAPI).
>
> O.o‽
>
> This sounds like it would be independent of LDAP over SSL (TCP 636).
>
> Would this Kerberos specified encryption be run over the standard LDAP
> port (TCP 389)?
>

Usually, yes.

(There is no technical reason why it couldn't run inside TLS, it's just
redundant – OpenLDAP doesn't mind but e.g. Active Directory explicitly
refuses to use both encryption layers at once. If you use TLS, you can
still use GSSAPI auth, but it insists that you turn off the GSSAPI
signing/sealing.)


>
> > This is especially common in Active Directory environments, where the
> > DCs might not have a valid TLS certificate.
>
> O.o‽
>
> I'm going to have to go pick my AD guru's brain after reading that.
>
> > (I seem to recall kerberized Telnet didn't survive because it was
> > limited to DES/3DES for an odd reason. Didn't quite understand why that
> > was the case, though.)
>
> #questionsQuestions
>

(This reminds me that I've noticed at least one of the MIT Kerberos
developers here in TUHS, who would surely know more about this than I've
gathered through barely few years of messing around.)

-- 
Mantas Mikulėnas

[-- Attachment #2: Type: text/html, Size: 5343 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 5251 bytes --]

On Tue, Nov 6, 2018 at 1:40 AM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> On 11/05/2018 03:34 PM, Dan Cross wrote:
> [snip]
> > Security, in general, usually seeks to address five questions:
> >
> > 1. Authentication - Is some entity who it claims to be?
> > 2. Authorization - Is some entity allowed to perform some action?
> > 3. Privacy - Can a third party snoop on a private conversation between
> > two entities?
> > 4. Integrity - Can a third party alter communications between two
> > entities in an undetectable way?
> > 5. Non-repudiation - Can it be definitively shown that some entity was a
> > party to some communication?
>
> The 3rd A that I'm used to is "Access Control".  Is the requested action
> allowed given the above information.
>

Isn't that authorization?

> Kerberos is a authentication protocol.
> >
> > LDAP, YP (retroactively named NIS after a lawsuit involving, I believe,
> > British Telecomm), NIS+, NetInfo, Active Directory, and Hesiod are all
> > examples of directory services. To a first-order approximation, one
> > might think of a directory service as providing an oracle allowing one
> > to discover what entities exist in some domain.
> >
> > Authentication protocols and directory services solve different
> > problems. Though in true Micro$oft-of-old fashion, AD sort of merged
> both.
>
> I would argue that a directory including shadow information (like
> NIS(+)) does both too.
>

Not really. It provides the data that lets one perform a relatively weak
validation of e.g. a password, but it is not *itself* an authentication
protocol.

> Kerberos solves the authentication problem, but does not provide a
> > directory service nor does it solve the authorization problem (though
> > some "kerberized" services could use a library to consult a
> > user-provided file of ACLs mapping principals to privileges). On Unix,
> > "authorization data" includes things like your UID and the set of groups
> > you belong to (or more precisely, your process's UIDs and GIDs/groups).
> > Kerberos provided support for privacy via encryption libraries, and it
> > provided support for integrity via hashing/checksumming/signature
> > libraries. "Kerberized" versions of network services such as telnet,
> > FTP, rsh/rlogin/rcp etc all provided support for authentication via the
> > baseline Kerberos protocol as well as privacy and integrity via
> > connection-level encryption and checksumming.
>
> I was not aware that Kerberos could provide privacy (encryption) for
> kerberized services.  I (naively) thought that Kerberos was
> authentication that other things could use to make access control
> decisions.
>

Older versions of Kerberos often included modified versions of popular
servers and their clients that had been modified to use the kerberos
protocol for authentication, and also often to encrypt communications. For
example, the version of `telnet` that shipped with MIT kerberos back in the
day had an option that could be used to encrypt the data stream; similarly
with rlogin, et al. I have a dim memory that the version of FTP might
support encryption for the control connection but not data connections (but
I also might be purely imagining that). I'm guessing most of this stuff has
been dropped from more recent distributions because...really...telnet?

[snip]
> > In its pure form, SSH provides support for limited authentication (via
> > public key cryptography and the wide distribution of public keys) and
> > limited authorization (via the `authorized_keys` file), privacy and
> > integrity.
>
> I think that OpenSSH's certificate support extends that a bit.
>

What I meant is that SSH supports a limited sense of checking whether a
given key matches and making a yea or nay decision based on that.

[snip]
> Even if communications with the NIS server was encrypted, I'm not
> hearing anything that prevents an authenticated user from enumerating
> NIS.  Even if it was over encrypted channels.
>

Correct. `ypcat passwd` often gave you a bunch of hashed passwords in field
two of a stream 7th Edition /etc/passwd formatted entries.

I have, again, some vague memory that at some point this was changed so
that root on the localhost could get a shadow-style map, but normal users
couldn't see the password hashes. But I might totally be making that up,
and of course, it wasn't robust security since what went over the wire
wasn't encrypted and breaking root on a host could still get you all the
hashes on the network. Contrast with Kerberos, where breaking root on a
host doesn't compromise much beyond that host (modulo leveraging that to
steal user passwords and the like).

[snip]
> > Hesiod, which seems unique to Athena, was kind of neat; it piggy-backed
> > the need for a directory service on DNS, which is already a distributed
> > directory service. You embedded relevant data into DNS TXT records, so
> > imagine doing a DNS query to look up a user's /etc/passwd entry: after
> > all, DNS already scaled and was well-proven Internet-wide. I don't know
> > that anyone ever really supported it, though.
>
> I know that Red Hat Linux did have support for it.  One of my colleagues
> was a Hesiod maintainer for a while.
>

Ha! That's a hoot.

[snip]

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 6814 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 3438 bytes --]

On 11/06/2018 03:24 PM, Dan Cross wrote:
> Isn't that authorization?

Not really.

Authentication is proving that you are who you claim to be.  -  Show 
your drivers license to the bouncer.

Authorization is deciding if the authenticated entity is allowed to have 
access or not.  -  Is your name on the list of people allowed into the 
nightclub?

Access Control - The bouncer, allowing you in or physically barring you 
from entering.

Each is a discrete function.  They all work in close concert with each 
other.

> Not really. It provides the data that lets one perform a relatively weak 
> validation of e.g. a password, but it is not *itself* an authentication 
> protocol.

Fair enough.

> Older versions of Kerberos often included modified versions of popular 
> servers and their clients that had been modified to use the kerberos 
> protocol for authentication, and also often to encrypt communications.

I take it that you mean that the Kerberos software that was distributed 
also included an alternate telnet / rsh / etc daemon that took advantage 
of Kerberos.

> For example, the version of `telnet` that shipped with MIT kerberos back 
> in the day had an option that could be used to encrypt the data stream; 
> similarly with rlogin, et al.

*nod*

> I have a dim memory that the version of FTP might support encryption 
> for the control connection but not data connections (but I also might be 
> purely imagining that).

Maybe.  There has been a LOT of energy put into FTP.

> I'm guessing most of this stuff has been dropped from more recent 
> distributions

Likely.

> because...really...telnet?

~chuckle~

I supported multiple old Solaris 6 machines about 5 years ago that I 
still had to use telnet to connect to.

I feel like telnet as a service REALLY does need to go away.  That being 
said, I still find the telnet (or any NVT) client a valuable diagnostic 
tool.

> What I meant is that SSH supports a limited sense of checking whether 
> a given key matches and making a yea or nay decision based on that.

I'm not sure I understand what you're alluding to.  But that's getting 
off topic.  So I digress.

> Correct. `ypcat passwd` often gave you a bunch of hashed passwords in 
> field two of a stream 7th Edition /etc/passwd formatted entries.

I would have hoped that there would have been some intelligence to only 
return the record of the person requesting the information.  Or that the 
password field was redacted for other users.

I guess the ypcat binary could be augmented to do that filtering client 
side.  But that still leaves the underlying problem there for alternate 
NIS clients.

> I have, again, some vague memory that at some point this was changed so 
> that root on the localhost could get a shadow-style map, but normal users 
> couldn't see the password hashes. But I might totally be making that up, 
> and of course, it wasn't robust security since what went over the wire 
> wasn't encrypted and breaking root on a host could still get you all 
> the hashes on the network.

It's still subject to alternate ypcat impersonation binaries too.

> Contrast with Kerberos, where breaking root on a host doesn't compromise 
> much beyond that host (modulo leveraging that to steal user passwords 
> and the like).

ACK

> Ha! That's a hoot.

;-)



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Pete Turnbull]

On 07/11/2018 00:35, Grant Taylor via TUHS wrote:
> On 11/06/2018 03:24 PM, Dan Cross wrote:
>> Isn't that authorization?
> 
> Not really.
> 
> Authentication is proving that you are who you claim to be.  -  Show 
> your drivers license to the bouncer.
> 
> Authorization is deciding if the authenticated entity is allowed to have 
> access or not.  -  Is your name on the list of people allowed into the 
> nightclub?
> 
> Access Control - The bouncer, allowing you in or physically barring you 
> from entering.

Not really.  You go past the bouncer as an immediate consequence of 
authorization.  The third 'A' is normally accounting: the bouncer notes 
the time you entered in the visitors book or logbook, and sometimes also 
notes the time you leave.  Just about every network access service does 
this, and "access control" is the whole AAA thing combined.

Have you ever seen a system that confirmed authentication and 
authorisation but then denied access (other than through a fault)? 
Denying access would be by a (possibly temporary) denial of authorisation.

-- 
Pete
Pete Turnbull

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 2535 bytes --]

On 11/07/2018 04:37 AM, Pete Turnbull wrote:
> Not really.  You go past the bouncer as an immediate consequence of 
> authorization.

I disagree.

To me these are two very distinct things.

I view authorization as a low pressure yes / no answer to should this 
access be allowed or not.

The access control (bouncer) is the high pressure and high risk exposed 
surface that people beat on to try to force their way in.

Much like how a low base current can control a high collector current on 
a transistor.

> The third 'A' is normally accounting: the bouncer notes the time you 
> entered in the visitors book or logbook, and sometimes also notes the 
> time you leave.  Just about every network access service does this, and 
> "access control" is the whole AAA thing combined.

I'll agree that accounting, or logging, is desired.  But many of the 
bouncers that I've seen don't do any logging (accounting) at all.  They 
simply enforce the decisions of other people (entities).

s/bouncer/security guard/ and I'll agree that logging (accounting) is 
typically done.

Does a turn stile do any logging?  Or does it simply allow somebody 
through if they provide the token?

> Have you ever seen a system that confirmed authentication and 
> authorisation but then denied access (other than through a fault)?

My ignorance does not preclude such from existing.

Think about someone approaching a checkpoint:

1)  They must authenticate themselves.
2)  They must be authorized to pass.
3)  The retractable tank traps (meant to be robust enough to stop a 
speeding car) must be retracted.

#3 is the access control that is independent of #1 & #2 as well as takes 
time to move.

I view the access control as the physical (or logical) barrier that 
allows or prevents things based on input of others.

> Denying access would be by a (possibly temporary) denial of authorisation.

I disagree.  You are still authorized.  You are still permitted to do 
$theThing.

Reusing the a tank trap comparison, does the drivers authentication or 
authorization status change between the time the guard says "Okay" and 
the time the driver leaves the check point?  The access control takes 
time to execute, namely the time it takes the guard to initiate 
retracting the tank trap and the time it takes for the tank trap to 
retract.  This entire time the driver is still authenticated and still 
authorized.  But access is still being prevented.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Dave Horsfall]

On Wed, 7 Nov 2018, Grant Taylor via TUHS wrote:

> Much like how a low base current can control a high collector current on 
> a transistor.

A fellow electronics bod, I see :-)

-- Dave

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Dave Horsfall]

Sorry; that last message was supposed to have gone direct...

-- Dave

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Pete Turnbull]

On 07/11/2018 17:30, Grant Taylor via TUHS wrote:
> On 11/07/2018 04:37 AM, Pete Turnbull wrote:
>> Not really.  You go past the bouncer as an immediate consequence of 
>> authorization.
> 
> I disagree.

You're entitled to your own opinion of the meaning of the term AAA, of 
course, and I understand some of the points you make, but I never 
claimed the three parts are necessarily atomic.  I was merely explaining 
my experience and knowledge of AAA (as a systems administrator, network 
manager and member of CERT and later CSIRT in a large enterprise) from 
working with Hewlett Packard, Cisco, Juniper, Aruba, Sun, SGI, 
Microsoft, eduroam, RADIUS, ...

-- 
Pete
Pete Turnbull

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Pete Turnbull]

On 06/11/2018 05:24, Grant Taylor via TUHS wrote:
> On 11/05/2018 03:34 PM, Dan Cross wrote:

>> Security, in general, usually seeks to address five questions:
>>
>> 1. Authentication - Is some entity who it claims to be?
>> 2. Authorization - Is some entity allowed to perform some action?
>> 3. Privacy - Can a third party snoop on a private conversation between 
>> two entities?
>> 4. Integrity - Can a third party alter communications between two 
>> entities in an undetectable way?
>> 5. Non-repudiation - Can it be definitively shown that some entity was 
>> a party to some communication?
> 
> The 3rd A that I'm used to is "Access Control".  Is the requested action 
> allowed given the above information.

Access Control = Authorisation.
Everywhere I've been, AAA = Authentication, Authorisation, Accounting.

-- 
Pete
Pete Turnbull

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Ben Greenfield via TUHS]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]



> On Nov 5, 2018, at 5:34 PM, Dan Cross <crossd@gmail.com> wrote:
> 
> Netinfo came from NeXT and survived into Macos for a little while.

We had are Netinfo server lookup passwords from our Solaris system and we used that through Mac OS X Server which I think stopped at version 1.2 or 1.6. They then switched the directory system when Mac OS X client was released  to Open Directory which was an OpenLDAP. The Open Directory was kerberized and all services that were shipped used kerberos.  This could act as Directory Domain server for windows clients.


> It was kind of neat but again the all-singing, all-dancing solution to the world. No one else really used it.




[-- Attachment #2: Type: text/html, Size: 2072 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Dave Horsfall]

On Sun, 4 Nov 2018, Grant Taylor via TUHS wrote:

> I'd like to hear more about the security issues.

When I was working for Lionel Singer (a Sun reseller) we used to refer to 
YP as Yellow Plague.  It was riddled with security holes, but alas I can 
no longer remember them.

-- Dave

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Larry McVoy]

I'm really tired (been crabbing all day and got 2 crabs, 7 pots, 5 hour soak,
got 2, sucked).

And I know very little about LDAP.

But I did do a sort of vnode/file system switch answer to this problem,
we called it lamed, I'll try and find you some docs in the morning.

We built a server that could take requests in any form and spit back
the answer.  My goal was to have a 200mhz MIPS server serve up this info
for the entire state of California, perform well, and work across reboots.
We pretty much did it.

On Sun, Nov 04, 2018 at 01:51:08PM -0700, Grant Taylor via TUHS wrote:
> Does anyone have any experience with YP / NIS / NIS+ / LDAP as a central
> directory on Unix?
> 
> I'm contemplating playing with them for historical reasons.
> 
> As such, I'm wondering what the current evolution is for a pure Unix
> environment.  Read:  No Active Directory.  Is there a current central
> directory service for Unix (or Linux)?  If so, what is it?
> 
> I'm guessing it's LDAP combined with Kerberos, but I'm not sure.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 



-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

On 11/04/2018 08:49 PM, Larry McVoy wrote:
> I'm really tired (been crabbing all day and got 2 crabs, 7 pots, 5 hour 
> soak, got 2, sucked).

I'm sorry the day wasn't as productive as you had hoped.  Here's hoping 
that you at least got to spend some quality time with good friends.  In 
between all the hard work.  ;-)

> And I know very little about LDAP.

I know very little.  But it's enough to know that I think learning more 
and / or dealing with it is going to be annoying.

> But I did do a sort of vnode/file system switch answer to this problem, 
> we called it lamed, I'll try and find you some docs in the morning.
> 
> We built a server that could take requests in any form and spit back 
> the answer.  My goal was to have a 200mhz MIPS server serve up this info 
> for the entire state of California, perform well, and work across reboots. 
> We pretty much did it.

That sounds very intriguing.  I'd be interested to hear more about it.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Dave Horsfall]

On Sun, 4 Nov 2018, Grant Taylor via TUHS wrote:

[...]

>> And I know very little about LDAP.
>
> I know very little.  But it's enough to know that I think learning more 
> and / or dealing with it is going to be annoying.

I've used OpenLDAP in a previous job for many years, for all sorts of 
things, and it worked well.  I had it integrated with Sendmail and even 
Kerberos, but I've forgotten the details now.

There is a damned good book on LDAP in general (I can't remember the 
title, but it's a thick hard-cover) so read it, cover to cover.  Then 
download the OpenLDAP source (or used a trusted binary) and read the 
documentation, esp. the quick start guide and the admin guide.

Then read them again :-)

The most important thing about learning LDAP is forgetting everything you 
ever knew about relational databases; LDAP is a *directory*, not a 
database, and the idiots at work were constantly referring to records, not 
*entries*, which drove me crazy (I have a Unify RDBMS background too).

And if/when you start using OpenLDAP, always keep it up to date; there is 
an active mailing list, but the first thing they'll ask is "What version 
are you running?".  Sure, there's been some lemon releases, but in general 
it worked fine for us; the company's balls depended upon it.

-- Dave

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 2064 bytes --]

On 11/05/2018 12:58 PM, Dave Horsfall wrote:
> I've used OpenLDAP in a previous job for many years, for all sorts of 
> things, and it worked well.  I had it integrated with Sendmail and even 
> Kerberos, but I've forgotten the details now.

ACK

My biggest problem with OpenLDAP, or any LDAP, is (other than my 
ignorance) the fact that all of them (save for AD) started with an empty 
schema.  So I was functionally needing to create a schema that was 
hopefully compatible with the things I needed /while/ learning LDAP ~> 
$LDAPimplementation.  I always felt it was a relatively steep learning 
curve.  And I was never sufficiently motivated.

Conversely, AD, has a very well established LDAP schema and many things 
know how to work with it.

> There is a damned good book on LDAP in general (I can't remember the 
> title, but it's a thick hard-cover)

Do you by chance know any more details?  I'll dig and see if I can find it.

> so read it, cover to cover.  Then download the OpenLDAP source (or used 
> a trusted binary) and read the documentation, esp. the quick start guide 
> and the admin guide.

ACK

> Then read them again :-)

~chuckle~

> The most important thing about learning LDAP is forgetting everything 
> you ever knew about relational databases; LDAP is a *directory*, not a 
> database, and the idiots at work were constantly referring to records, 
> not *entries*, which drove me crazy (I have a Unify RDBMS background too).

I think I understand that.  Or at least what (little) I know doesn't 
doesn't seem to have any objection to that.  I know that I would not 
want to use LDAP as a general purpose relational database.

> And if/when you start using OpenLDAP, always keep it up to date; there 
> is an active mailing list, but the first thing they'll ask is "What 
> version are you running?".  Sure, there's been some lemon releases, but 
> in general it worked fine for us; the company's balls depended upon it.

Thank you for the ProTip.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Dave Horsfall]

[Getting a bit off-topic now...]

On Mon, 5 Nov 2018, Grant Taylor via TUHS wrote:

>> There is a damned good book on LDAP in general (I can't remember the 
>> title, but it's a thick hard-cover)
>
> Do you by chance know any more details?  I'll dig and see if I can find 
> it.

This looks like it (I recognise the authors) but I would've had the first 
edition, and my ex-supervisor is no longer at work:

     https://www.amazon.com/Understanding-Deploying-LDAP-Directory-Services/dp/0672323168/ref=zg_bs_69960_25?_encoding=UTF8&psc=1&refRID=ZWNJQSFWS5ARJEG469XN

You may have to strip off tracking codes...

I see there's also an O'Reilly book, but it's an admin guide so presumably 
basic knowledge of LDAP is required.

[...]

> I think I understand that.  Or at least what (little) I know doesn't 
> doesn't seem to have any objection to that.  I know that I would not 
> want to use LDAP as a general purpose relational database.

It most certainly is not; it's optimised for searching (with complex 
patterns) and reading, not for writing.

-- Dave

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Larry McVoy]

OK, found some slides:

http://mcvoy.com/lm/papers/lamed.pdf

If your browser can't read the pdf (firefox failed for me), wget it or
whatever and try a command line pdf viewer (mupdf worked for me).

Happy to fill in the details if you have questions.

On Sun, Nov 04, 2018 at 07:49:40PM -0800, Larry McVoy wrote:
> I'm really tired (been crabbing all day and got 2 crabs, 7 pots, 5 hour soak,
> got 2, sucked).
> 
> And I know very little about LDAP.
> 
> But I did do a sort of vnode/file system switch answer to this problem,
> we called it lamed, I'll try and find you some docs in the morning.
> 
> We built a server that could take requests in any form and spit back
> the answer.  My goal was to have a 200mhz MIPS server serve up this info
> for the entire state of California, perform well, and work across reboots.
> We pretty much did it.
> 
> On Sun, Nov 04, 2018 at 01:51:08PM -0700, Grant Taylor via TUHS wrote:
> > Does anyone have any experience with YP / NIS / NIS+ / LDAP as a central
> > directory on Unix?
> > 
> > I'm contemplating playing with them for historical reasons.
> > 
> > As such, I'm wondering what the current evolution is for a pure Unix
> > environment.  Read:  No Active Directory.  Is there a current central
> > directory service for Unix (or Linux)?  If so, what is it?
> > 
> > I'm guessing it's LDAP combined with Kerberos, but I'm not sure.
> > 
> > 
> > 
> > -- 
> > Grant. . . .
> > unix || die
> > 
> 
> 
> 
> -- 
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

Re: [TUHS] YP / NIS / NIS+ / LDAP

[arnold]

Larry McVoy <lm@mcvoy.com> wrote:

> OK, found some slides:
>
> http://mcvoy.com/lm/papers/lamed.pdf

That was quite interesting!! Very impressive.  Did the reference
port ever get contributed to Linux?  It looks like a nice architecture.

Arnold

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Larry McVoy]

On Mon, Nov 05, 2018 at 11:38:50AM -0700, arnold@skeeve.com wrote:
> Larry McVoy <lm@mcvoy.com> wrote:
> 
> > OK, found some slides:
> >
> > http://mcvoy.com/lm/papers/lamed.pdf
> 
> That was quite interesting!! Very impressive.  Did the reference
> port ever get contributed to Linux?  It looks like a nice architecture.

Yeah, it was sort of overkill for the problem space, but it seemed
like the right answer.  Very much inspired by the vnode/vfs interface
I learned in SunOS.

The caches worked across reboots.  I left not long after we completed 1.0,
Bob Mende (RIP) and some other folks took the mmap based dbm (I called
mdbm) and put locks in each page so you could have multiple writers.
That code made its way to yahoo and just got used for everything, they
made it C++ (not a fan of that but whatever) and evolved it farther than
I ever imagined.  They had DBs that were 100's of gigs ~20 years ago.
They open sourced their stuff.

I'm not sure if SGI ever open sourced it, be a shame if they didn't.
Though the need for a YP server that scales to the entire world is
not so clear to me.  But you could do it.

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Noel Hunt]

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

The mention of a YP server that scales to the entire world
reminds me of my time at Lehman Bros. (yes, evil incarnate)
in Tokyo, 1995-96. They were using moira which I believe was
from Project Athena, to push out YP maps to all their sites
around the world. I have a feeling there were ex-MIT people
at Lehman in New York.

On Tue, Nov 6, 2018 at 7:09 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Mon, Nov 05, 2018 at 11:38:50AM -0700, arnold@skeeve.com wrote:
> > Larry McVoy <lm@mcvoy.com> wrote:
> >
> > > OK, found some slides:
> > >
> > > http://mcvoy.com/lm/papers/lamed.pdf
> >
> > That was quite interesting!! Very impressive.  Did the reference
> > port ever get contributed to Linux?  It looks like a nice architecture.
>
> Yeah, it was sort of overkill for the problem space, but it seemed
> like the right answer.  Very much inspired by the vnode/vfs interface
> I learned in SunOS.
>
> The caches worked across reboots.  I left not long after we completed 1.0,
> Bob Mende (RIP) and some other folks took the mmap based dbm (I called
> mdbm) and put locks in each page so you could have multiple writers.
> That code made its way to yahoo and just got used for everything, they
> made it C++ (not a fan of that but whatever) and evolved it farther than
> I ever imagined.  They had DBs that were 100's of gigs ~20 years ago.
> They open sourced their stuff.
>
> I'm not sure if SGI ever open sourced it, be a shame if they didn't.
> Though the need for a YP server that scales to the entire world is
> not so clear to me.  But you could do it.
>

[-- Attachment #2: Type: text/html, Size: 2548 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[arnold]

Larry McVoy <lm@mcvoy.com> wrote:

> The caches worked across reboots.  I left not long after we completed 1.0,
> Bob Mende (RIP) and some other folks took the mmap based dbm (I called
> mdbm) and put locks in each page so you could have multiple writers.
> That code made its way to yahoo and just got used for everything, they
> made it C++ (not a fan of that but whatever) and evolved it farther than
> I ever imagined.  They had DBs that were 100's of gigs ~20 years ago.
> They open sourced their stuff.

Any idea where to find this now?

Thanks,

Arnold

Re: [TUHS] YP / NIS / NIS+ / LDAP

[arnold]

arnold@skeeve.com wrote:

> Larry McVoy <lm@mcvoy.com> wrote:
>
> > The caches worked across reboots.  I left not long after we completed 1.0,
> > Bob Mende (RIP) and some other folks took the mmap based dbm (I called
> > mdbm) and put locks in each page so you could have multiple writers.
> > That code made its way to yahoo and just got used for everything, they
> > made it C++ (not a fan of that but whatever) and evolved it farther than
> > I ever imagined.  They had DBs that were 100's of gigs ~20 years ago.
> > They open sourced their stuff.
>
> Any idea where to find this now?
>
> Thanks,
>
> Arnold

And, I *still* haven't learned to ask Google first.  A quick search
finds these:

https://github.com/yahoo/mdbm
https://yahooeng.tumblr.com/post/104861108931/mdbm-high-speed-database

Enjoy,

Arnold

Re: [TUHS] YP / NIS / NIS+ / LDAP

[A. P. Garcia]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

On Sun, Nov 4, 2018, 4:34 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org
wrote:

> Does anyone have any experience with YP / NIS / NIS+ / LDAP as a central
> directory on Unix?
>
> I'm contemplating playing with them for historical reasons.
>
> As such, I'm wondering what the current evolution is for a pure Unix
> environment.  Read:  No Active Directory.  Is there a current central
> directory service for Unix (or Linux)?  If so, what is it?
>
> I'm guessing it's LDAP combined with Kerberos, but I'm not sure.
>

Yes, that's exactly what Active Directory does and does well, so why shun
it? I'd be interested in knowing where a pure unix environment exists,
beyond my imagination and dreams that is. Linux is pretty much a first
class citizen in a Windows world today. Samba4 can act as a domain
controller, but I don't know how practical that solution is, how well it
scales, or what kind of support exists. It uses the same standard protocols
as AD.

I do dread the day that Microsoft introduces "Group Policy for Linux", if
they haven't already. Also, I like Powershell and was stoked when they
introduced it to Linux, but I've personally been resisting its use to
manage Linux servers, perhaps for no good reason.

Yesterday I read that MS is starting to develop SysInternals-like tools for
Linux. They own GitHub. Like it or not, they're not going away. They're
going to continue diluting the waters between Windows and Linux more and
more. Resistance is futile.

[-- Attachment #2: Type: text/html, Size: 2161 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 3821 bytes --]

On 11/05/2018 01:48 PM, A. P. Garcia wrote:
> Yes, that's exactly what Active Directory does and does well, so why 
> shun it? I'd be interested in knowing where a pure unix environment 
> exists, beyond my imagination and dreams that is.

Ah.  Let me describe it this way:

LAN with a mixture of Windows and Linux /workstations/ that doesn't 
include a Windows /server/ to provide the AD resources (DNS, LDAP, 
Kerberos, etc.)

I guess it could be said that Samba4 acting as an AD DC might be the 
proper choice here.  But that sounds like some hassle without the 
typical Windows GUI tools for administering AD.  -  I've also never done 
that, so the unknown quantity is a bit deterrent.

I can also see having multiple Linux machines in a network without any 
other OS.  Possibly a cluster of Raspberry Pi Zeros on a Cluster Hat. 
}:-)  Use the underlying Pi as the gateway and infrastructure device, 
including the directory.

The point being, there are environments with multiple Linux (Unix) 
machines that don't have ready access to AD.  Thus my asking about the 
Unix (Linux) native method.

> Linux is pretty much a first class citizen in a Windows world 
> today. Samba4 can act as a domain controller, but I don't know how 
> practical that solution is, how well it scales, or what kind of support 
> exists. It uses the same standard protocols as AD.

I feel like standing up AD, be it on Windows Server or Linux with 
Samba4, is applying a Windows centric solution to Linux (Unix) systems. 
I think this is acceptable if there is already Windows ~> AD in the mix. 
  But that's not always the case.

I also loath the idea that Unix (Linux) doesn't have a stand alone 
central directory server solution.  Or if LDAP + Kerveros is said 
solution, so be it.  -  That's sort of what I'm trying to figure out.

> I do dread the day that Microsoft introduces "Group Policy for Linux", 
> if they haven't already.

I'm fairly certain that group policy objects do exist for Linux AD 
clients.  I think they are just simpler and can do far fewer things.  I 
think they also effectively map to the standard things that we could 
already do in Linux.  It's just behind a Microsoft MMC snap-in to edit GPOs.

> Also, I like Powershell and was stoked when they introduced it to Linux, 
> but I've personally been resisting its use to manage Linux servers, 
> perhaps for no good reason.

I know a couple of people that have messed with PowerShell on Linux. 
One of whom actually prefers PowerShell to Bash (et al) for scripting. 
He stated that things are stored in data structures in PowerShell, and 
as such were easier to manipulate and work with, compared to 
unstructured data in STDIN / STDOUT.

He also stated that PowerShell was functionally just another shell for 
doing things on Linux.  In some ways, quite similar to moving between 
/bin/sh, /bin/bash, /bin/zsh, etc.  Obviously interacting with the shell 
is different.  But you're still calling Linux commands to do core 
things.  The glue is just different.

> Yesterday I read that MS is starting to develop SysInternals-like tools 
> for Linux. They own GitHub. Like it or not, they're not going away. 
> They're going to continue diluting the waters between Windows and Linux 
> more and more. Resistance is futile.

I was more meaning environments that don't include Windows Server, not 
meaning to shun Windows.

Translation:  What is the current Unix (Linux) method to provide central 
user directory / authentication for about a dozen Unix (Linux / Solaris 
/ *BSD / AIX) systems /without/ a Windows Server in the mix.  I don't 
own a license for any version of Windows Server that supports AD.  Nor 
do I feel compelled to buy one.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]

On Mon, Nov 5, 2018 at 7:33 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> [snip]
> Translation:  What is the current Unix (Linux) method to provide central
> user directory / authentication for about a dozen Unix (Linux / Solaris
> / *BSD / AIX) systems /without/ a Windows Server in the mix.  I don't
> own a license for any version of Windows Server that supports AD.  Nor
> do I feel compelled to buy one.
>

On small networks, I eventually jettisoned YP/LDAP et al in favor of flat
text files in a directory tree on an NFS server. All clients mounted that
and every $n$ minutes cron ran a script that sync'ed important files on
each host. We were already using Kerberized NFS everywhere; this eliminated
the directory service as another point of failure. Since passwords were in
the Kerberos master, I didn't care about the contents of /etc/passwd,
though I used make and cpp to generate "ACL" files that drove a script that
generated /etc/passwd on each host so that e.g., normal users couldn't log
into the NFS server; not because I cared about them logging in but rather
because I didn't want them running real programs there and slowing it down.

Root was probably the only account with an actual password in
/etc/{shadow,master.passwd} but that was explicitly chosen with enough
entropy that if someone got the hash and ran crack or john the ripper or
whatever against it they were only going to succeed in generating lots of
heat.

If I only got a dozen or so systems, that's what I'd do again. Setting up
an LDAP schema probably isn't worth the complexity; NIS would be the only
other realistic option and it's just not secure enough in this day and age.
Setting up a KDC and an NFS server is much easier.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 2209 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 281 bytes --]

On 11/05/2018 06:46 PM, Dan Cross wrote:
> NIS would be the only other realistic option and it's just not secure 
> enough in this day and age.

What do you think about NIS (sans shadow) for directory and Kerberos for 
authentication?



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]

On Tue, Nov 6, 2018 at 1:42 AM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> On 11/05/2018 06:46 PM, Dan Cross wrote:
> > NIS would be the only other realistic option and it's just not secure
> > enough in this day and age.
>
> What do you think about NIS (sans shadow) for directory and Kerberos for
> authentication?
>

It wouldn't do it, but I guess it depends on how much you trust your
environment and your users etc. If you're intent on using a network
directory service, I'd bite the bullet and invest in setting up Kerberos
and LDAP. The thing with pairing Kerberos (for authentication) with NIS is
that while you'll have decent authentication security, nothing prevents a
malicious third party from modifying the answer from `ypserv` for some user
to set the UID to 0, thus making that user root. If authentication is
happening by users typing passwords into SSH clients, which then get sent
to SSH servers to be validated against the KDC on machines that have been
so cracked, an attacker can steal passwords by subverting the SSH server
processes.

However, if you trust your users not to do that and you're on a relatively
small, self-contained and decently secured network, then it may be fine.
From what you described earlier I think generating text files and
distributing them around (possibly with rdist or rsync) and pairing that
with kerberos would be less work and more robust.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 1802 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

On 11/06/2018 03:29 PM, Dan Cross wrote:
> It wouldn't do it, but I guess it depends on how much you trust your 
> environment and your users etc.

That's not quite what I had expected, but it is an answer to the 
question that I asked.

> If you're intent on using a network directory service, I'd bite the 
> bullet and invest in setting up Kerberos and LDAP. The thing with pairing 
> Kerberos (for authentication) with NIS is that while you'll have decent 
> authentication security, nothing prevents a malicious third party from 
> modifying the answer from `ypserv` for some user to set the UID to 0, 
> thus making that user root.

ACK

> If authentication is happening by users typing passwords into SSH clients, 
> which then get sent to SSH servers to be validated against the KDC on 
> machines that have been so cracked, an attacker can steal passwords by 
> subverting the SSH server processes.

What would the user be typing their password into?  The SSH client to 
authenticate to the SSH daemon?  Or kinit (et al) on the remote system?

I would have thought that the ideal situation would be for the user to 
kinit on their client, then authenticate to ssh using Kerberos.

I'm guessing they would need to do something to extend their Kerberos 
tickets therefrom.  I don't know if they would need to kinit on the 
remote system, or if there's something like agent forwarding for Kerberos.

> However, if you trust your users not to do that and you're on a 
> relatively small, self-contained and decently secured network, then it 
> may be fine.

ACK

> From what you described earlier I think generating text files and 
> distributing them around (possibly with rdist or rsync) and pairing that 
> with kerberos would be less work and more robust.

Possibly.

Though I don't consider that to be a central directory server.  Instead 
I consider it to be replicating information locally.  I'm sure it has 
it's pros and cons.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Arthur Krewat]

On 11/6/2018 5:29 PM, Dan Cross wrote:
> If authentication is happening by users typing passwords into SSH 
> clients, which then get sent to SSH servers to be validated against 
> the KDC on machines that have been so cracked, an attacker can steal 
> passwords by subverting the SSH server processes.

One of the most fun things I've done in the past few years was to take 
OpenSSH and make it dump the attempted password while hackers are trying 
to brute-force my inbound SSH.

They've stopped for some reason. Now they just try TELNET over and over 
again. Mostly from exploited cameras.

art k.

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Robert Brockway]

On Mon, 5 Nov 2018, Grant Taylor via TUHS wrote:

> I also loath the idea that Unix (Linux) doesn't have a stand alone central 
> directory server solution.  Or if LDAP + Kerveros is said solution, so be it. 
> -  That's sort of what I'm trying to figure out.

LDAP with or without Kerberos certainly counts as a standalone directory 
server solution for *nix.

> Translation:  What is the current Unix (Linux) method to provide central user 
> directory / authentication for about a dozen Unix (Linux / Solaris / *BSD / 
> AIX) systems /without/ a Windows Server in the mix.  I don't own a license 
> for any version of Windows Server that supports AD.  Nor do I feel compelled 
> to buy one.

I've seen plenty of businesses with Linux servers and OSX desktops.  These 
business often manage user auth on Linux with LDAP.  Various solutions 
were used to manage the OSX boxes but they were quite separate to Linux.

One caveat with LDAP.  When I last did this a few years ago many Linux 
systems were set up in such a manner that a failure of LDAP makes the 
systems largely unusable. AFAIK this is still a problem.

A sysadmin logging in had to wait out a series of timeouts while trying to 
open nsswitch.conf or the PAM config to disable LDAP so the underlying 
problems could be addressed.

One fix for this that I mentioned earlier is to manage the Linux systems 
using orchestration tools like Ansible.  Have them generate local passwd, 
shadow & group files from data stored in LDAP.  This prevent the timeout 
problems I mentioned earlier and also means that switching to a new 
authentication backend (eg, OpenLDAP to AD) is a lot easier since it is 
abstracted away.

Cheers,

Rob

Re: [TUHS] YP / NIS / NIS+ / LDAP

[David Arnold]

[-- Attachment #1: Type: text/plain, Size: 2854 bytes --]

One place I worked recently used FreeIPA.  It's a Redhat-sponsored attempt to integrate a bunch of other free/open source projects and put them under a single web UI.

It’s largely compatible, functionally, with Active Directory, and I think can be set up to support cross-realm authentication with an AD installation as well.  It *doesn’t* (or at least in the setup I used) replace AD, and doesn’t seem to use any Samba components.

It does however include the DHCP and (Dynamic)DNS integration that’s part of AD.

It seemed pretty fragile in practice, although the overall level of systems expertise in this place was fairly low, and a lot of its problems could well have been issues with the underlying virtual machine or storage infrastructure.

I too still use NIS at home.  It works with my Linux boxes, but also the Sun, DEC, SGI and NeXT stuff as well.  I like the idea of a central directory, but X.500 always seemed like overkill and the “Lightweight” bit of LDAP doesn’t quite throw enough away for me …



d


> On 6 Nov 2018, at 14:03, Robert Brockway <robert@timetraveller.org> wrote:
> 
> On Mon, 5 Nov 2018, Grant Taylor via TUHS wrote:
> 
>> I also loath the idea that Unix (Linux) doesn't have a stand alone central directory server solution.  Or if LDAP + Kerveros is said solution, so be it. -  That's sort of what I'm trying to figure out.
> 
> LDAP with or without Kerberos certainly counts as a standalone directory server solution for *nix.
> 
>> Translation:  What is the current Unix (Linux) method to provide central user directory / authentication for about a dozen Unix (Linux / Solaris / *BSD / AIX) systems /without/ a Windows Server in the mix.  I don't own a license for any version of Windows Server that supports AD.  Nor do I feel compelled to buy one.
> 
> I've seen plenty of businesses with Linux servers and OSX desktops.  These business often manage user auth on Linux with LDAP.  Various solutions were used to manage the OSX boxes but they were quite separate to Linux.
> 
> One caveat with LDAP.  When I last did this a few years ago many Linux systems were set up in such a manner that a failure of LDAP makes the systems largely unusable. AFAIK this is still a problem.
> 
> A sysadmin logging in had to wait out a series of timeouts while trying to open nsswitch.conf or the PAM config to disable LDAP so the underlying problems could be addressed.
> 
> One fix for this that I mentioned earlier is to manage the Linux systems using orchestration tools like Ansible.  Have them generate local passwd, shadow & group files from data stored in LDAP.  This prevent the timeout problems I mentioned earlier and also means that switching to a new authentication backend (eg, OpenLDAP to AD) is a lot easier since it is abstracted away.
> 
> Cheers,
> 
> Rob


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

On 11/05/2018 08:03 PM, Robert Brockway wrote:
> One caveat with LDAP.  When I last did this a few years ago many Linux 
> systems were set up in such a manner that a failure of LDAP makes the 
> systems largely unusable. AFAIK this is still a problem.
> 
> A sysadmin logging in had to wait out a series of timeouts while trying 
> to open nsswitch.conf or the PAM config to disable LDAP so the 
> underlying problems could be addressed.

I've experienced such pain.  It's not fun.

I think SSSD is coming in to vogue as an abstraction layer between the 
system and LDAP+Kerberos for this very reason.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]