On Mon, Nov 5, 2018 at 9:19 AM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> wrote: There was `ypcat passwd`, wasn't there? 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). Could you elaborate on that? Standard TLS. -- Mantas Mikulėnas

On 11/5/2018 2:24 AM, Mantas Mikulėnas 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. 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.

On 11/5/2018 2:32 PM, Grant Taylor via TUHS wrote: 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

On 11/6/2018 12:25 AM, Grant Taylor via TUHS wrote: Not sure if that's humor or not ;) NIS (YP) vs. NIS+

On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote: 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 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. 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

On Mon, Nov 5, 2018 at 11:00 PM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> 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. My ignorance is leaving me with a priming problem that seems like a 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.) Yes, that's exactly what happens. However, probably not for all of the same reasons as you imagine. -- Mantas Mikulėnas

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

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:)

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. 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.

Which might be what I’m trying to describe.

On Mon, Nov 5, 2018 at 4:00 PM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> wrote: 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 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(a)GAJENDRA.NET".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.

On Tue, Nov 6, 2018 at 8:40 AM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> wrote: These days the modification generally consists of pam_krb5 added to the system's PAM configuration. 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. 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

On Tue, Nov 6, 2018 at 9:18 PM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> wrote: 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. 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. 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.) 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 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

On 11/06/2018 03:24 PM, Dan Cross wrote: 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. Fair enough. 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. *nod* Maybe. There has been a LOT of energy put into FTP. Likely. ~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. I'm not sure I understand what you're alluding to. But that's getting off topic. So I digress. 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. It's still subject to alternate ypcat impersonation binaries too. ACK ;-) -- Grant. . . . unix || die

On 11/07/2018 04:37 AM, Pete Turnbull wrote: 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. 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? 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. 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

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

On 06/11/2018 05:24, Grant Taylor via TUHS wrote: Access Control = Authorisation. Everywhere I've been, AAA = Authentication, Authorisation, Accounting. -- Pete Pete Turnbull

On Sun, 4 Nov 2018, Grant Taylor via TUHS wrote: 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

On 11/04/2018 08:49 PM, Larry McVoy wrote: 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. ;-) 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. That sounds very intriguing. I'd be interested to hear more about it. -- Grant. . . . unix || die

On 11/05/2018 12:58 PM, Dave Horsfall wrote: 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. Do you by chance know any more details? I'll dig and see if I can find it. ACK ~chuckle~ 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. Thank you for the ProTip. -- Grant. . . . unix || die

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: -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

On Mon, Nov 05, 2018 at 11:38:50AM -0700, arnold(a)skeeve.com wrote: 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.

Larry McVoy <lm(a)mcvoy.com> wrote: Any idea where to find this now? Thanks, Arnold

On Mon, Nov 5, 2018 at 7:33 PM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> wrote: 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.

On Tue, Nov 6, 2018 at 1:42 AM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> wrote: 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. distributing them around (possibly with rdist or rsync) and pairing that with kerberos would be less work and more robust. - Dan C.

On 11/6/2018 5:29 PM, Dan Cross wrote: 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.

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