Re: [rhelv5-list] Domain Auth - winbind to native krb - preserving UID
Bryan's responses are a small treaty about internal psychology in all companies of the world :-) -Original Message- From: rhelv5-list-boun...@redhat.com [mailto:rhelv5-list- boun...@redhat.com] On Behalf Of Musayev, Ilya Sent: Tuesday, July 17, 2012 1:03 AM To: Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list Subject: Re: [rhelv5-list] Domain Auth - winbind to native krb - preserving UID Bryan, Thanks for detailed info - definitely and eye opener. As you can tell, I don't have as much experience as you do in this realm. I will need to re-read you response couple times to digest better. ___ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
Re: [rhelv5-list] Domain Auth - winbind to native krb - preserving UID
Antoine, Thanks for the detailed feedback. I missed your response for second. I was thinking of using Unix Services for Windows - but we need to automate the GID and UID assignment, and convert existing user to use new setup. I will give it a shot when time allows . This would be a good approach for a new environment, for existing one, it will be a bit painful. Regards ilya From: rhelv5-list-boun...@redhat.com [mailto:rhelv5-list-boun...@redhat.com] On Behalf Of Antoine Reid Sent: Friday, July 13, 2012 1:33 PM To: Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list Subject: Re: [rhelv5-list] Domain Auth - winbind to native krb - preserving UID 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.COMhttp://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 - 29 idmap gid = 1000 - 29 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 = 10 - 19 idmap config MYDOMAIN:backend = rid idmap config NEWDOMAIN:range = 20 - 29 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
Re: [rhelv5-list] Domain Auth - winbind to native krb - preserving UID
On Mon, Jul 16, 2012 at 2:45 PM, Musayev, Ilya imusa...@webmd.net wrote: Antoine, Thanks for the detailed feedback. I missed your response for second. I was thinking of using Unix Services for Windows – but we need to automate the GID and UID assignment, and convert existing user to use new setup. Define automate the GID/UID assignment? This is a common issue to having both Windows clients/services and IETF/POSIX (UNIX/Linux) clients/services. I.e., - NTuser schema for Windows - IETF RFC2307 (among others) for IETF/POSIX (UNIX/Linux) Understand when Microsoft adopted Michigan LDAP for AD, they decided to pull the existing SAM (Workgroup = local registry, Domain = local registry of the PDC, later first DC in AD, that became network wide). This is commonly referred to as NTuser schema, NTDOM, etc... It is utterly different, along with other AD schema, from IETF/POSIX standards/attributes and related objects. Now you can install IETF RFC2307 schema on Windows c/o NT5 (2000/XP/2003) Services for UNIX (SFU), now NT6 (Vista/7/2008/8/2012) Subsystem for UNIX Applications (SUA). Even 2003R2 and later make it easy to integrate, with some caveats. But that still doesn't remove the requirement that someone actually _manage_ the IETF RFC2307. If your Windows team doesn't have someone who understand that reality, then no client side solution is going to solve that alone. So that's why I ask, what do you mean by automated? Especially in the context, convert existing user to use new setup. A lot of times this means a schema change to add IETF RFC2307, and Windows admins get that deer in headlights and often bark back, the UNIX guys just need to use Samba and not bother us. [ Professional Note: If I had a dollar for every time some AD architect said you UNIX people just need to learn Samba, I'd be a millionaire. At the same time, having more, current Microsoft certifications and Samba publication credits has helped establish some authority when I'm faced with such attitudes. ] A lot of people look to Centrify or Likewise solutions, because it often runs on and modifies the DCs, if not the schema (depending on the product or solution), and helps Windows admins manage them. But you can do so without those solutions as well. Otherwise you have to set up Winbindd with exactly mappings on each and every IETF/POSIX (UNIX/Linux) system -- assuming it has a PAM or other pluggable system that works with Winbindd in the first place. That means pushing down the same configuration files, plus hoping the Windows admins don't break things. I.e., maintaining consistency at the end UNIX/Linux systems, instead of AD, because UNIX/Linux doesn't use NT-only SAM/SID information, etc... ;) Or you can do what a lot of Enterprises were doing for AD, and kept doing after AD. They have their enterprise managed by LDAP, and then they selectively synchronize to/from AD, and other LDAP trees. The Windows attributes/objects are managed in AD trees, the IETF/POSIX objects managed in LDAP trees. This is not cake, and it takes architecture and planning. Which is where Identity, Policy, Audit (IPA) aka Red Hat Enterprise Identity Management (IdM) come in. It is designed to be the canned IETF/POSIX (UNIX/Linux) complement to AD. At the same time, because it's still IETF LDAP and MIT Kerberos underneath, it can work with legacy systems too (unlike AD). And it's designed for basic synchronization to AD, passwords in 2.x, transitive trusts in 3.x (3.0 just hit Beta earlier this month). RHEL 6.2 IdM is IPA 2.1, RHEL 6.3 IdM is IPA 2.2. Again, for most UNIX/Linux departments, it's often just much easier to maintain your own trees, because the Windows folk just don't get the difference between NTuser and IETF schema. They don't understand why they have to assign UNIX home directory paths and other attributes, and don't want to. That's why most have separate trees, because the AD admins don't want to be bothered. Password synchronization is easy, and has been going around for the past decade. And select attribute/object exchange is not impossible to setup as well. IPA 3.x is taking it a step further so UNIX/Linux systems in an IPA MIT Kerberos realm can use resources in AD trees, and Windows systems in an AD MS Kerberos domain can access those under IPA trees. It's never going to be perfect. I mean, Integrated Windows Authentication (IWA), NTLMv2 and other aspects of federated services may not be completely transparent, but it's going to get much better with IPA 3.x. The only thing the AD/Windows admins will really need to be bothered with is a login so you can register/bind to the AD domain. Because most AD/Windows admins don't know the first thing why IETF RFC2307 exists, and they don't want to be bothered with it. -- Bryan J Smith - Professional, Technical Annoyance http://www.linkedin.com/in/bjsmith ___ rhelv5-list mailing list rhelv5-list@redhat.com
Re: [rhelv5-list] Domain Auth - winbind to native krb - preserving UID
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
Re: [rhelv5-list] Domain Auth - winbind to native krb - preserving UID
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 - 29 idmap gid = 1000 - 29 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 = 10 - 19 idmap config MYDOMAIN:backend = rid idmap config NEWDOMAIN:range = 20 - 29 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
Re: [rhelv5-list] Domain Auth - winbind to native krb - preserving UID
Hi Eugene, No, I could not find a way to preserve UIDs with native KRB/PAM/LDAP and had to use WinBind. At this moment, this is the only viable solution in the open source world (that I'm aware of). You may to look at centrify - which is modified version of samba (but its not free). If you do come across something that works, please let me know. Regards ilya From: rhelv5-list-boun...@redhat.com [mailto:rhelv5-list-boun...@redhat.com] On Behalf Of Antoine Reid Sent: Friday, July 13, 2012 1:33 PM To: Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list Subject: Re: [rhelv5-list] Domain Auth - winbind to native krb - preserving UID 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.COMhttp://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 - 29 idmap gid = 1000 - 29 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 = 10 - 19 idmap config MYDOMAIN:backend = rid idmap config NEWDOMAIN:range = 20 - 29 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
