How does it all works in CentOS/RHEL-6? Update...

This update is intended to cover some changes brought with the new sixth version of RHEL/Centos - enjoy.

Samba Winbind
Samba 3.5 winbind is hopelessly broken in CentOS-6 and unfortunately the Samba community does not seem to be willing to fix this - see this for details.

But if you need to use it anyway, this is the configuration needed:
workgroup = [domain]
realm =
security = ads
kerberos method = system keytab
idmap config [domain]:schema_mode = rfc2307
idmap config [domain]:backend = ad
idmap config [domain]:readonly = yes
idmap config [domain]:range = 100-30000
idmap backend = tdb

allow trusted domains = no
idmap uid = 100-1000000
idmap gid = 100-1000000

winbind use default domain = Yes
winbind enum users = Yes
winbind enum groups = Yes
winbind nss info = rfc2307
log level = 3 winbind:7 idmap:16
As you can see, some of the config parameters differ from Samba 3.0. Note that however winbind miserable is, we will need this configuration for "net" command anyway - see below.

Kerberos configuration

Does not differ too much from my previous posts. There is only one change needed sporadically - new Kerberos libraries seem favour stronger encryption methods, so if experience Kerberos - related errors, you might need to consider:

allow_weak_crypto = true

parameter.

SSSD
RHEL-6 comes with a very interesting project called SSSD - System Service Switch. This is aiming to replace a bit obsoleted Glibc interface and shed a new light into Posix-constrained corners of the Linux world.
Good news is that we could use SSSD for user&group&.... namespace lookup - i.e. yes for something that winbind can no longer do reliably. The bad news is, that SSSD can not create the computer object in AD - for this we still need Samba - specifically the "net ads join" command.
Once computer account created, the SSSD configuration would look like this:
[sssd]
services = nss, pam
config_file_version = 2
domains = default
[nss]

[pam]

[domain/default]
debug_level = 7
ldap_id_use_start_tls = False
ldap_search_base = [some DN here]
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
cache_credentials = True
ldap_sasl_authid = [machine name]$@[REALM]
dns_discovery_domain = [your dns domain]
krb5_realm = [REALM]
ldap_sasl_mech = GSSAPI
ldap_user_object_class = user
ldap_group_object_class = group
ldap_user_home_directory = unixHomeDirectory
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_schema = rfc2307bis
ldap_account_expire_policy = ad

As you can see, this is still fairly minimal setup (I can admit here that I like simplicity). I am almost solely relying on the dns_discovery_domain parameter to help me locate LDAP and KDC servers on the network.

Note:
SSSD can not handle Active Directory Sites yet so you might need to specify your site explicitly here - just to avoid SSSD connection to LDAP server on the other side of the world.

Automounter
No change here... hold on, wait... on is there indeed. If you are planning to use SSSD for your AD integration project, there is one change here. According to this RFE automounter will soon be able to use SSSD to lookup automount data in Active Directory.