On 2012-07-12, at 11:09 PM, Eugene Vilensky wrote: > Hello Ilya, > > Were you able to find the solution for your inquiry? I did not see any > on-list replies in the archives. > > Cheers, > Eugene > > On Thursday, February 16, 2012, Musayev, Ilya wrote:r > In past, one of my clients was using domain auth with winbind mainly due to > the fact that we had multiple domains to login from and RHEL4u6 did not have > a cross realm support. > > > > As of now client moved completely to RHEL5u4 and soon to be u7, he would like > to migrate to native krb auth. > > > > Our backend infrastructure for AD is windows 2008 servers. My question is in > regards to user ID mapping. I would like to preserve/match the existing UID. > > > > There are two domains, “MYDOMAIN” and “NEWDOMAIN” that is used by different > users. > > > > With winbind, we used something like this on each host in order to get the > UID for each user – this setup would guarantee identical UID for each user on > every server. > > > > How can the same be accomplished with native krb with cross realm support? > > > > > > [global] > > workgroup = MYDOMAIN > > realm = MYDOMAIN.HOSTNAME.COM > > server string = Samba Client > > security = ADS > > obey pam restrictions = Yes > > passdb backend = tdbsam > > client NTLMv2 auth = Yes > > log file = /var/log/winbind > > local master = No > > dns proxy = No > > panic action = /usr/share/samba/panic-action %d > > idmap uid = 1000 - 299999 > > idmap gid = 1000 - 299999 > > template shell = /bin/bash > > winbind separator = + > > winbind enum users = Yes > > winbind enum groups = Yes > > winbind use default domain = Yes > > winbind expand groups = 10 > > winbind refresh tickets = Yes > > winbind offline logon = Yes > > idmap config MYDOMAIN:range = 100000 - 199999 > > idmap config MYDOMAIN:backend = rid > > idmap config NEWDOMAIN:range = 200000 - 299999 > > idmap config NEWDOMAIN:backend = rid >
Hi everyone! I have joined this list recently, and did not see the original email. 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). 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. This becomes a nightmare when you start sharing resources using NFS, for example. 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). 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. 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. 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. 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. 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. This would be the only way to preserve the same UIDs and GIDs on the Linux servers for those domain accounts. 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. 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. 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)... I have no real experience with cross-realm scenarios however, sorry I can't really help with that.. Hope that helps, Antoine Antoine Reid, RHCE Conseiller Principal / Principal Consultant Infrastructures Technologiques Gallium 1250, Boul. René-Lévesque Ouest Bureau 2200 Montréal (Québec) Canada H3B 4W8 E : ar...@gallium-it.com www.Gallium-IT.com
_______________________________________________ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
