27 августа 2016 г. 15:00:38 CEST, Tobi Oetiker <t...@oetiker.ch> пишет: >Gordon > >from your explanation it is not quite clear to me if one colud use an >openldap server, and how one would have to go about telling illumos to >use it. > >cheers >tobi > >> On 26.08.2016, at 18:14, Gordon Ross <gordon.w.r...@gmail.com> wrote: >> >> Sorry for the delay -- been quite busy. I do look at this list, but >> only occasionally. >> >> The way LDAP auth. works in SMB servers like Samba is that the server >> allows SMB clients (i.e. Windows) to logon using accounts that work >> the same as "local" accounts (what Windows would call "local" >> accounts, meaning they are NOT domain accounts). However, while the >> SMB clients think these are "local" accounts, the server uses >> something akin to the name service switch functions for LDAP to get >> the details of these accounts needed for SMB. >> >> Such accounts are not really "local", but are defined in your LDAP >> service. The SMB server needs a way to get some Windows-specific >> details about those accounts from LDAP, including the "NT password >> hash" (for authentication) and some other Windows-ish details. >> >> The current LDAP libraries in illumos are sufficient for this (though >> for other reasons, it would be nice if we could update them some >day). >> What's missing is some "glue" in the name service switch design, and >> perhaps a new lookup method for the "NT password hash", which is >> similar conceptually to the "shadow password" back-end functions. >One >> can probably pretty much copy/paste the LDAP back-end function for >> shadow passwd. to make the "ntpass" or whatever we call this new >> nsswitch method. The current /var/smb/smbpasswd stuff, currently >> accessed directly from libsmb should really go through the "files" >> back-end, and we might want to consider taking the opportunity to >> change the format of that file (though that means doing some format >> conversion work during upgrades). Once a new nsswitch method for >> "ntpass" (or whatever) is in place, the parts of this in the SMB >> server (mostly libsmb) are fairly easy. >> >> Requests for this feature have come up from time to time over the >last >> few years, but (so far) not from anyone who wanted it badly enough to >> pay for the work. >> >> Gordon >> >> >>> On Thu, Aug 18, 2016 at 11:15 AM, Dan McDonald <dan...@omniti.com> >wrote: >>> >>>> On Aug 18, 2016, at 11:04 AM, Mick Burns <bmx1...@gmail.com> wrote: >>>> >>>> *bump* >>>> anyone ? >>> >>> I'm going to forward your note to someone I know who works on CIFS. >He's not on this list. >>> >>> Stay tuned, >>> Dan >>> >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss@lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss@lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> > >_______________________________________________ >OmniOS-discuss mailing list >OmniOS-discuss@lists.omniti.com >http://lists.omniti.com/mailman/listinfo/omnios-discuss
From my fiddling with LDAP (DSEE) for Solaris/OI/Linux accounts with Sol/OI kCIFS server vs. a separate AD domain a few years back, and Gordon's explanations, I think you are asking about several slightly related subsystems in one sentence ;) Yes, you can use an(y?) LDAP service with NIS-equivalent schema with the Solarish ldap-client. DSEE and AD+MS Unix Extensions can do it. Probably OpenLDAP can do it - you might need to port DSEE schema dialect to be recognised by that service though. This regards recognition of Unix accounts for file ownership, ssh, etc. You can also fiddle with netgroups to limit which groups and accounts from LDAP are at all "defined" for a particular client (e.g. a zone might only know about admins or devs for its services, not all organization). Separate from that is kCIFS auth that may rely on a password file (with NTLM hashes, or so they say) which Gordon suggests might be re-coded separately to be an nsswitch service so it can also come from an LDAP backend or from the file. This authorizes the users to enter the server via CIFS. Separate from that is ephemeral mapping (and SMF service for that) to connect AD UUIDs to local (or ldap) Unix id numbers. This part requires an AD service connection so probably a special AD account for the server and perhaps a kerberos login setup. Hope this rant helps ;) Jim -- Typos courtesy of K-9 Mail on my Samsung Android _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
