On Fri, Jul 13, 2012 at 1:32 PM, Antoine Reid <ar...@gallium-it.com> wrote: > From what I can see, the Original Poster was using a winbind configuration > that uses the RID (relative identifier) part of the users' and groups' SIDs > to generate the UIDs and GIDs. This is a great way to ensure that each > individual user (and group) gets the same UID (GID) on all servers (provided > that all servers have the exact same idmap rules in their respective > smb.conf).
As long as the RID is unique and does not conflict, especially not with other, existing IDs (be they local or in another system). Careful planning is always key. > I particularly dislike the configurations that allocate UIDs and > GIDs locally (kept in a tdb file) as users login, as it creates a different > mapping on each server. Unless you ensure your TDB is the same across the entire enterprise with some sort of Enterprise Configuration Management (ECM). Since many AD/Windows admins have no interest in maintaining RFC2307 information in AD, this is often the requirement -- handling the universal-unique information at the clients. This is also, often required for other IETF RFC2307 and additional IETF attributes the AD admins don't want to or cannot maintain any way, such as the location of home directories, Automounter maps, etc... Again, pushing them down with an ECM solution at some point becomes required. Or, eventually when the administrative headache is less, a separate LDAP tree with optional MIT Kerberos realm. The latter opens up the possibility of trusts between AD and that realm, although AD admins typically don't like that. But if you're only using AD for authentication, and the AD admins not managing IETF/POSIX users/groups any way, it makes far more sense to just have a separate tree. > This becomes a nightmare when you start sharing resources using NFS, for > example. And not managing your automounter maps in your LDAP is a nightmare in my view. ;) So if they are not using AD LDAP to store them, I might as well have my own. Because, otherwise, I'm pushing them down individual to each and every client any way via an ECM. ;) > This being said, the config posted by the OP seems to indicate that there > are no extensions to the AD LDAP schema (such as using Services For Unix, > aka "Identity Management for UNIX" if I am not mistaken). Yes. IETF RFC2307 should be _required_ knowledge for an AD admin IMPO. But then again, since Microsoft doesn't even have an "AD internals" class at all (like they do have an excellent, continuing "NT Internals" class), I don't expect much out of them. BTW, it's Subsystem for UNIX Applications (SUA) in NT6 (Vista/7/2008/8/2012), which provides some services beyond the prior SFU in NT5 (2000/XP/2003). AD 2003R2 domain levels are the first, "usable" releases with RFC2307 attributes in my view. I would recommend 2008R2 today though. But in my experience most AD admins either don't want to manage them, or are utterly ignorant of them (and how NTuser schema differs from IETF/POSIX attributes). I'm still dumbfounded by the number of AD architects that have absolutely no exposure to the concepts, and tell me "Google Samba" or my presonal favorite, "go read a Samba book." The latter always gets a chuckle from my team. ;) > If it were, the OP would be using something similar to "idmap config MYDOMAIN > : backend ad" > and "idmap config MYDOMAIN : schema_mode = rfc2307" or something similar in > their smb.conf. Agreed. But that still requires the AD admins to actually _maintain_ those RFC2307 attributes. Many do not, or do not understand why InetOrgPerson, etc... exists. ;) > Therefore, this configuration is presumably used for two purposes: > adding "winbind" to the "passwd" and "group" entries in nsswitch.conf (ie: > use winbind as a "proxy" to AD as a directory service) > authentication/authorization (using pam_winbind.so in /etc/pam.d/system-auth > and configuring groups in /etc/security/pam_winbind.conf) > In my opinion, if you wanted to stop using winbind for authentication, you > would probably still want to keep using winbind for the directory service > function. > In fact, you can very well run winbind for this purpose only, and configure > your PAM stack to use Kerberos5 for authentication (using pam_krb5.so). > This can be useful in some scenarios. For example if the users' homes are in > OpenAFS and you need both a kerberos ticket and an OpenAFS token (which you > acquire using your krb5 ticket) to access the home directory, and wish to > acquire both of those during the login (using PAM modules) rather than > through the shell itself. Or even just use legacy NIS maps for just automounter and a few other things. I've done that myself "spur of the moment" to get some aspects under control. Being able to detail the specific security aspects of the solution is always helpful when you get those, "but NIS is insecure!" comments. It also allows me to flip back the argument on the customer to say, "Okay, then either manage these maps in AD or let me have my own tree with a MIT-MS Kerberos cross-realm trust." > In fact, the pam_krb5.so provided in RHEL can acquire OpenAFS tokens on its > own (the one in RHEL6 can, I haven't tried in RHEL5). > Now, if the deployment scenario was changed to modify the AD schema to > include additional attributes (UID, GID, shell, home directory) by using the > Service For Unix extensions, for example, then I guess there could be a way > to implement the name service part without using winbind at all. You would > need to setup some LDAP configuration to provide the name service. Which is where the "fun" begins and often brings me back to the, "why don't we have a peer LDAP tree already?" > While I have done this using Solaris in the past (and needed to provide a full > mapping of the attribute names since Solaris was expecting the LDAP > attributes to be completely different than what SFU provides...), I do not > know off-hand how the equivalent setup would be done in RHEL. You can mix'n match in most PAM/NSS systems. Also remember that SSSD in EL5.6+/EL6+ changes some aspects, but it's largely to remove a lot of the legacy PAM and other services (including nscd). > Going this route would mean that whoever would add the missing attributes to > the AD schema would also need to modify every existing user and group to > pre-allocate the UID and GID fields (respectively) with the numerical value > that winbind used to compute. For MYDOMAIN, this would be RID+100000 and > for NEWDOMAIN, it would be RID+200000. Hopefully, MYDOMAIN did not have any > RIDs over 99999 or there would be an overlap between the two domains. Exactly my earlier point. Leveraging RID can be a really issue, especially in the hands of many AD admins who can do all sorts of things with their tree/forest really quick. There has to be cross-department communication and interest, otherwise ... and as I've been saying since 2001 ... "Linux becomes is AD's bitch" (and that's exactly how to put it at times) > This would be the only way to preserve the same UIDs and GIDs on the Linux > servers for those domain accounts. I've found maintaining the maps and pushing them out via an ECM mechanism is best. Whenever a new user comes on-board, the UNIX/Linux team addresses the user in those maps. Same goes for groups. It's a PITA, and at some point, the load justifies a peer and separate LDAP tree with management. Either that, or the AD/Windows folk are finally told to "work with the UNIX/Linux team." And if and when they eventually show they do not, it further justifies a separate tree. > Another way to proceed would be to deploy another LDAP directory service > besides AD to host the UID/GID mappings. If you need redundancy, this means > a cluster of servers with replication. While this can certainly work, it > basically duplicates the core AD functionality. I really hate that argument, and it's mis-information. It's not duplicating AD's functionality, it's adding the appropriate, _required_ IETF/POSIX attributes/objects. There's not only absolutely nothing wrong with peer trees, but most enterprises that had DAP or LDAP deployed prior to AD's introduction use a DAP/LDAP solution "above" AD (and any departmental "trees") where accounts are actually generated, managed and "pushed down" (often via LDIF or similar). > In a certain way, using Winbind in a large AD environment may still be a > good idea, since modern Samba tools (in RHEL5, the samba3x packages) will > properly find their "Site name" in AD, and then find the proper DCs to use > to lookup records and perform authentication to. You do need a valid > /etc/krb5.conf to bootstrap the process and perform the net join, but > winbind will produce its own private file > (/var/lib/samba/smb_krb5/krb5.conf_DOMAIN) by finding the DCs in their own > "Site" and pulling additional servers listed in smb.conf with the "password > server" directive. This private krb5.conf is rebuilt every time winbind > start, as far as I know. This helps in large AD deployments where the list > of DCs may be very dynamic. Which is where the UNIX/Linux admins need to a single, centrally managed set of files pushed out via ECM. It's doable, but requires pro-active monitoring of the AD tree for changes. > As I said earlier, using the RIDs is a really great way to ensure the users > and groups obtain the same UIDs and GIDs everywhere, without having to > modify the AD schema (in large corporations, different teams manage AD and > the Linux servers, typically). Since the UIDs and GIDs are derived from the > RIDs (part of the SID), there are no changes required in AD to support this, > and no additional directory service to deploy and maintain. This works as > long as the shell can be standardized and the home directories can be > standardized as well (/home/DOMAIN/user, for example)... Again, assuming the RIDs can be guaranteed and mapped well. But you're still left with different attributes and required maps that aren't in AD. So you're pushing out that information to each system individually. One customer I had solved it by running a local NIS on each and every system, one that was only accessible on the localhost. They pushed down the maps via their ECM mechanisms. It worked very well. > I have no real experience with cross-realm scenarios however, sorry I can't > really help with that.. It's not fun, even for AD itself with forests of differing schema. E.g., ever deploy LDS+ADFS to solve multiple AD forests that cannot be merged and adopt a common schema? At some point having a true LDAP authority would be quicker and easier, let alone solve the non-AD issue entirely. ;) -- Bryan J Smith - Professional, Technical Annoyance http://www.linkedin.com/in/bjsmith _______________________________________________ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
