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 https://www.redhat.com/mailman/listinfo/rhelv5-list
