You'll get a lot of answers on this, especially from people who have only used one solution. But it's clear you see the different between SAM/NTUSER and IETF schema, and have been dealing with keytab and other considerations (there are an extreme few MCSE/MCITPs that have ever hit those TechNet articles). So I don't have to go over that, and you're probably going to be the best person to tell yourself what's best for your environment.
In a nutshell, from my experience, it's really a matter of if you want to deal with changes on the Linux clients, or a single, Linux server. If you go the Winbind and other Linux client route, if there is an Active Directory Services (ADS) change that affects compatibility, you're going to be changing things on each Linux client. If you setup Red Hat Directory Server (RHDS), and make your Linux clients LDAP clients to RHDS, then your headaches are limited to the server-to-server exchange. Of course, there are other factors too. Like ... - Can you run a service on the Windows machines for ADS-RHDS account sync? - Are you 2003 R2 domain-level or forest-level with IETF schema today in your forest already? - Can you create a new 2003 R2 domain-level and server in your 2003 forest (assuming you're not 2008)? - Also, are you going to be accessing CIFS/SMB shares on the Windows servers, or just authentication? Identity, Policy, Audit (IPA, http://www.freeipa.org) is a Red Hat Emerging Technology (ET) that takes RHDS, combines it with the SAM/NTUSER schema, requires DNS and Kerberos and, in a nutshell, makes it ADS compatible without requiring ADS to have IETF (2003 R2+). That's an option if you're really stuck, but it's not available in a commercially supported option at this time, unlike RHDS (even though RHDS is at the heart of IPA, among other, Red Hat shipping components in IPA). A couple of things to remember on the Windows side. There is 0 advantage to 2008 forests, so hopefully your company hasn't made that move. Introducing a 2003 R2 server or even a 2008 server in 2003 (R2) domain-level mode is typically best with RHDS in my book. Of course, if your schema is not IETF, then that is more of an issue -- something solved by the IPA managed stack. If you can't tell, I'm a big fan of multi-directory exchange, instead of walking in one day to find out people can't work because a Windows change happened, and it broke their own interfaces (with an update for the Windows clients, but that doesn't help Linux/standards interfaces). If you want to talk off-line, feel free. In fact, this is one of those things that if you already have a relationship with a Red Hat Solutions Architect (SA), they can best assist you. -- Bryan P.S. There are other, Windows to Linux identity management solutions on the Linux client side as well. Some have their pluses and minuses. It's all about what you need to do -- just authenticate, or add CIFS/SMB access or even add GNOME/Firefox object management into the ADS LDAP tree (instead of using a native LDAP like RHDS, or other, standard distribution for that matter, to store the objects). -- Bryan J Smith Professional, Technical Annoyance Linked Profile: http://www.linkedin.com/in/bjsmith ---------------------------------------------------- UCF Basketball: AP #23, ESPN/USAToday #22, RPI #17 UCF Football: AP #21, BCS #25, ESPN/USAToday #20 ----- Original Message ---- From: "Bohmer, Andre ten" <[email protected]> Until now we had to manage a few user accounts per Linux server. We create a local account with the same name as the Windows Active directory samAccountName and authenticated via Kerberos. But now we’re on the brink of rolling out large high performance servers with lot's of users which also share storage across different Linux servers. So it would be much easier to grant users access based on AD group membership, but also it's significant to maintain the same uid/guid across all servers. Some googling around show a combination of samba, winbind, ldap, Kerberos and Microsoft Services for Unix, but also RedHat Directory Server which seems to do it's own uid/guid mapping without the need of a AD schema update. Any thoughts on what would suite/works best? _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
