2014 - Integrating Red Hat Enterprise Linux 6 with Active Directory

Updated -

This paper details the components, considerations and configurations available for selecting, deploying and integrating Red Hat Enterprise Linux 6 into Windows Active Directory domains. Basic concepts are introduced, deployment and integration tasks outlined, and best practices and guidelines provided throughout.

Attachments

56 Comments

I've revised Configuration 3 to use the new AD provider for SSSD and updated the overall paper for RHEL 6.5. I'd welcome any comments, suggestions.

Thanks for this update, my biggest gripe with v1.4 was the lack of documentation to retrieve the kerberos tickets from Linux without the Windows interaction. What was documented previously wasn't much use to those scripting the install.

I notice another subtle change which I think needs more attention, and that's the addition of 'optional' to the IMU line. Would it be possible to split SSSD with/without IMU out into different configuration options as the "4.2 Configuration Feature Comparisons" isn't completely accurate with IMU being optional (namely the 'disadvantages' section).

I think the 'description' for ldap_id_mapping could be reworded as it says 'Enable to use POSIX (IMU) UIDs GIDs', but you mean enable the configuration item of 'false', ie. disable ldap_id_mapping?

Thanks again for the update.. are there any plans to confirm this configuration on 2012 AD?

Hello,

Part of what we're seeing here is simply due to the "evolution" of the products - namely SSSD. The current version shipping in RHEL 6.5, when used with the new AD provider does not require IMU to be enabled in AD.

What I tried to do with this paper was accommodate the deployment of the most typical use cases but as everyone's environment, situation is different there will of course be differences in needs. For many customers, IMU is not enabled or permitted - that is why we have Config 1 and 2 in the paper. Now, with the introduction of the new AD provider for SSSD, we could (as you point out here) make the same case. Let me think about this a bit - perhaps we can just re-word what we have?

I totally agree that the 'ldap_id_mapping' is counter-intuitive. I'd have to reach out to the engineer in charge of that to confirm when that was changed but I believe it was about the same timeframe as when the new AD provider was introduced. I also found it backwards to my way of thinking :-)

We have no current plans to revise for Windows Server 2012/R2 on RHEL 6.5+.
However, I have two new projects on the horizon that are related:

  • Integrating OpenShift 2.1 (RHEL 6.5) with Identity Management in RHEL 7.
    This should land the end of June and will also use Kerberos cross-realm trusts
    between IdM and Windows Server 2012 R2/AD.

  • Integrating RHEL 7 with Windows Server 2012 R2/AD. This will demonstrate
    both direct integration (SSSD -> AD) and indirect integration (SSSD -> IdM <--> AD).

I'm hoping to have the second project out late August/early September.

Thank you for the feedback - very much appreciated! If I do revise the current RHEL 6.5 paper then I'll be sure to give a shout out here.

-m

Mark,

I don't have any real issue with the configuration option 'ldap_id_mapping' being ambiguous; it's the wording of the description in the document.

On Page 63.

In the settings description it says:
'Enable to use POSIX (IMU) UIDs GIDs'

I think it should say:
'Set value to false to use POSIX (IMU) UIDs GIDs'

As you don't want that option 'Enabled' (ie. set to true) if using IMU. This is confirmed just below the option box on the same page (page 63):
"In environments where the POSIX attributes (aka - Identity Management for UNIX) have
been enabled on the Active Directory server, set ldap_id_mapping = false on the
Red Hat Enterprise Linux clients. This disables UID/GID to SID mappings and uses the
values that have been set in the UNIX Attributes tab on the Windows Active Directory
server."

As the document currently is, these comments appear to conflict.

Would it also be possible to include some clarity in the document around "override_homedir" and "default_shell" options, my understanding is that these should only be required if IMU is disabled?

-edit-

I also notice that the following two requirements have been added since the last document revision:
- Client must be running Red Hat Enterprise Linux 6.4 or higher
- Client must be running SSSD version 1.9.2 or higher

Is there a specific configuration capability that requires these versions?

Cheers.

Mark, any update on the "Integrating RHEL 7 with Windows Server 2012 R2/AD" project?

Hi Stijn,

Working on it as we speak. By design, we've been waiting for RHEL 7.1 which brings in CIFS support. I have the reference architecture outline and hosts in place, and targeting this to be published within a month of RHEL 7.1 GA. I've also been pulled into some RHEL-Atomic work and am not sure what impact that will have on the publish date but I'm still hoping to see this out well before Summit (March?).

-m

Hi PixelDrift,

re: Wording

I like your suggestion on the wording change - I'll add that in to the next revision.
(I'm currently waiting on input from a customer/partner on another section so after I that I'll make the change).

re: Parameters

Here is how I view the "override_homedir" and "default_shell" parameters: if you have IMU activated
and have set homedir and shell within AD then the local parameters are not required as the clients will use them. If you do set them then the local parameters will override the values set in AD.

If you do not have IMU activated but would like to be able to "cookie cutter" these across your clients
then you can configure them. I think this is the biggest benefit for large deployments that are not using
IMU.

Regardless of whether or not IMU is activated, the local parameters will take precedence.

re: Requirements

The main difference was in the streamlining of the direct integration to AD using SSSD AD provider.

Thank you for taking the time to provide feedback here - it's always appreciated.

-m

Mark,

I should clarify my statement, I think there should be more clarity about the two options you have included "override_homedir" and "default_shell", ie. provide information in the document that these are not required if these values are returned by the directory.

Also, to clarify. default_shell (according to SSSD man pages) will only be used if the directory service doesn't return a shell.

Man page states the following:

default_shell
The default shell to use if the provider does not return one during lookup. This option supersedes any other shell options if it takes effect.
Default: not set (Return NULL if no shell is specified and rely on libc to substitute something sensible when necessary, usually /bin/sh)

If the same behaviour as "override_homedir" is preferred, "override_shell" should be used.

override_shell (string)
Override the login shell for all users. This option can be specified globally in the [nss] section or per-domain.
Default: not set (SSSD will use the value retrieved from LDAP)

The reason I get caught up with these minor details is largely due to how I use the documents. If I refer to this Red Hat reference architecture document in a detailed design, and then don't implement the reference architecture exactly as it is implemented in the document (ie. with all the same options), I then need to provide justification for each option that differs from the reference architecture (for example, why I haven't used override_homedir or default_shell as they aren't marked 'optional').

I notice two other options in Configuration 3 ("ad_server" and "cache_credentials") both have 'optional' at the start of the description. I think this should be added for "override_homedir" and "default_shell" in their descriptions (page 63) as they are both optional, and only required in configurations not using IMU.

Cheers, and thanks again for the updates!

Thanks for this guide. Can you recommend any additional resources for migrating from an existing RedHat integration with Windows 2003 AD servers to 2008 R2 or 2012? Our ERP system is currently running on RedHat EL 6.4 64-bit and is integrated with a Windows 2003 domain for both SSH/telnet login authentication and file sharing. We want to eliminate W2K3 servers from our environment before MS stops supplying security updates and I'm trying to figure out the best way to upgrade the domain controllers without breaking the existing integration.

Thanks,
John

Hi John,

I fully understand and you are by no means alone in the need to upgrade.

From the RHEL client side, you should only have to change the server references in the relevant configurations files - (smb.conf, krb5.conf, sssd.conf, etc.) depending on which apporach is being used (Samba/Winbind, SSSD, Kerberos/LDAP, etc.).

I have not seen anything written up from the Windows side but one thing to consider is whether or not the POSIX attributes i.e. Identity Management for UNIX (IMU) or Services For UNIX (SFU) are in use. If they are not in use on the old (W2K3) servers and then are enabled on the new (2008/2012) servers then that could affect the RHEL clients. Of course, the opposite case would also be true but it's not likely to have POSIX disabled after a migration.

I'll keep an eye out for any materials that might be useful - my best guess would be something posted here on the portal or from the services organization.

I'd be re-miss if I didn't point out that we just published a new reference architecture on integrating OpenShift Enterprise with Identity Management (IdM) in RHEL. In this paper I show how to stand-up and deploy an IdM server and replica, and later show how to configure a Cross-realm trust to Active Directory on Win2012 R2. It might be worth taking a peek at for the future:

https://access.redhat.com/articles/1155603

I've also just started the next reference architecture which will be showing how to do direct (SSSD -> AD) and indirect (SSSD -> IdM -> AD) integration. This will be on RHEL 7.0 (no filesharing) and is targeted for an October release.

Best regards,

-m

Mark,

Thanks again for another great document (regarding link above).

Do Red Hat have a preferred method / guideline when implementing RHEL authentication in a green field environment?

What are the major benefits you see to adding idM in between the clients and AD?

Hi PixelDrift!

There really is no "one size fits all" and that is exactly why the RHEL6 based AD integration reference architecture has 4 separate configuration options - but they are the recommended ones based on whether or not filesharing is needed (Config 1 and 2) or not (Config 3 and 4). IMU of course subdivides Config 1 and 2 as well.

Having said that, the direction for RHEL 7 is moving away from Samba/Winbind configurations in favor of SSSD. Support for SSSD with file sharing is not planned until RHEL 7.1 (possibly 7.2). The discussions on this are happening as we speak so I suspect it will be Tech Preview for 7.1/2. To the best of my knowledge, there is no reason that the Samba client bits can't be installed if file sharing is also needed for the interim (- i.e. RHEL 7.0).

IdM is a whole different approach. IdM provides native Linux domain services (DNS, LDAP, Kerberos, NTP, Certs) and also supports a feature of Kerberos call cross-realm trusts that allows using existing AD accounts and user/group ID's on the IdM clients for user login and authentication. I've written up much more in the OSE-IdM refarch paper and will also have this in the next refarch as well.

btw - I've started assembling an interoperability blog to share and disseminate ideas, help with troubleshooting, etc. If this would be useful then let me know.

-m

Cheers Mark,

Is the SSSD + file sharing discussion happening upstream in public SSSD discussions or within Red Hat?

Would be keen to follow a blog on interoperability, especially if it provides insight into the direction Red Hat are heading (eg. SSSD file sharing and finally phasing out Winbind!).

It's targeted to RHEL 7.1 which is tentativley slated for the end of Feb but that date is too far out to be solid. I've only heard about it from the internal engineering team but if I hear of anything being posted/discussed upstream./outside I'll drop a line back to you. The FreeIPA and or/SSSD section of Fedorahosted sites would be the most likely places.

John,

As Mark has mentioned, determining if SFU/IMU is in use in your 2k3 domain is a good first step.

Do you have a 'Unix Attributes' tab available under User/Group properties in your 2k3 AD domain?

-edit-

This discussion may be better placed in the community discussion section if you're interested in starting a thread on the subject there.

Hi Mark and Pixel,

Thanks for your replies. I've never installed SFU/IMU services and there is no Unix Attributes tab in the AD properties, so I think it's safe to say it's not installed. I'm assuming SFU/IMU will not be installed and/or enabled by default on Server 2012. I'm planning to set up a 2012 DC in an isolated test environment, so I'll know for certain at that point.

Thanks,
John

John,

You are correct, IMU is not enabled by default in 2012.

My biggest focus when migrating between directories when RH is involved is to ensure that UID/GID numbers remain the same. If these are currently generated by your client configuration (likely if you aren't using SFU/IMU) just keep an eye on them and ensure you can replicate the same numbering when testing against your new 2012 servers.

Thanks, PixelDrift. I'm using the rid backend specifically to keep the numbering the same across servers. Hopefully they will remain consistent, but I will definitely test for it. I also started a thread on the community forum per your suggestion to see if anyone out there has already been through this process.

I am reading the 1.5 version of the guide and having issues. I have a case 01177861. I am also wondering when you config the client with LDAP config so Referals work when AD does not suply the answer. Such as SUDO.

Hi Mike,

Which configuration are you using? Can you provide more details? If it's in the case I'll see if I can acccess it.

-mark

Configuration 3
When we try to switch to the machine keytab we get no key avaialble

Mike,

Did you first run # kinit administrator before running # net ads join -k to see if you can join AD with the keytab? Then when you run # klist -k you should see the machine keytab in the list. If that does not work then double-check to see that the smb.conf file is configured correctly:

[global]
workgroup = YOUR-AD-DOMAIN
client signing = yes
client use spnego = yes

kerberos method = secrets and keytab
realm = YOUR-AD-DOMAIN.FQDN.COM
security = ads

log file = /var/log/samba/log.%m
max log size = 50

There is a library dependency on samba common library so smb.conf still need to be configured.

-m

Have another quick question of info. Going through the appendixes to verify if our settings match yours. Appendix D, page 101, my Windows SA has setup a Domain Controller with DNS with Primary integrated zones and same for reverse. He wants to know if your Master server is Windows or Redhat and why you chose Secondary zones?

Our DNS is setup on a RHEL host that handles lookups within our lab ('cloud.lab...') domain - requests outside of that are forwarded to a higher level DNS server. The Windows AD server is a single, stand-alone host so it's setup as a secondary of the RHEL server. If you have a large AD environment with less RHEL hosts then you might take the opposite approach and have the RHEL server do there lookups through the Win/AD environment. In general (for the paper) we assume that DNS is managed at a higher level and both RHEL and AD servers do lookups outside of the local domain to the higher level DNS infrastructure.

-m

Hi Mark,

I've been doing further research on our planned 2003 AD upgrade and discovered there is a known issue that breaks Kerberos authentication when 2003 and 2012 R2 DCs are mixed within the same domain:

http://blogs.technet.com/b/askds/archive/2014/07/23/it-turns-out-that-weird-things-can-happen-when-you-mix-windows-server-2003-and-windows-server-2012-r2-domain-controllers.aspx#pi145002=4

The underlying cause is 2003 uses DES encryption for key salting and 2012 R2 uses AES. Do you think this issue is likely to break authentication on RH EL clients as it does on Windows clients?

Thanks,
John

Hi John,

I'm not sure but I've got a couple of inquiries out. What version of RHEL are your RHEL client running and how are they connecting to AD? Kerberos/LDAP?

-m

The most mission-critical clients are 6.4 64-bit but there's an older client running 5.1 32-bit. All are joined to the domain and use AD for samba and ssh authentication. They're using Kerberos and winbind, and I think I stuck pretty closely to this document when I configured the 6.4 servers last year:

https://access.redhat.com/solutions/67432

Thanks,
John

John,

Since encryption is not my forte, I reached out to a trusted colleague and the short-answer is just add/modify:

allow_weak_crypto = true

in /etc/krb5.conf. I wrote back with a few questions he wrote me an excellent explanation - I'm pasting it below as it explains everything :-)

-m

On Wed, 20 Aug 2014, Mark Heslin wrote:
>

I take it that will allow the existing clients to continue to work with the old keys on the new AD server?
How would the clients actually switch to using the AES salting? Does anything need to be changed?

If old AD clients want to use new AES keys, the keys need to be
regenerated. This would happen on password change for users and on
machine account refresh for hosts.

For RHEL clients connected directly to the AD an easiest thing would be
to rotate keys with net utility, assuming they are using Samba to set up
the machine account (net ads join).

net ads changetrustpw

Note that in typical SSSD/AD use case it is beneficial to use
kerberos method = secrets and keytab
or
kerberos method = system keytab

in smb.conf, as Samba will keep machine trust account password then in
/etc/krb5.keytab (along with secrets.tdb or exclusively) and SSSD then
can immeadiately use the keytab.

You can see what current keys are in use by running kvno command with
KRB5_TRACE=/dev/stderr set in the environment, you'll get something like
this:

$ KRB5_TRACE=/dev/stderr kinit Administrator@AD2008.TEST
....
....
[22961] 1408607062.509807: Salt derived from principal: AD2008.TESTAdministrator
[22961] 1408607062.509813: AS key determined by preauth: rc4-hmac/5BE5
[22961] 1408607062.509842: Decrypted AS reply; session key is: rc4-hmac/F6F3
....
$ KRB5_TRACE=/dev/stderr kvno -S ldap dc1.ipacloud.test
....
[22962] 1408607068.810619: Requesting tickets for ldap/dc1.ad2008.test@AD2008.TEST, referrals on
[22962] 1408607068.810664: Generated subkey for TGS request: rc4-hmac/7606
[22962] 1408607068.810707: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
....
$ klist -ef
Ticket cache: KEYRING:persistent:123456:krb_ccache_H1qC8nF
Default principal: Administrator@AD2008.TEST

Valid starting Expires Service principal
21.08.2014 10:45:09 21.08.2014 20:45:03 ldap/dc1.ad2008.test@AD2008.TEST
renew until 22.08.2014 10:45:00, Flags: FRAO
Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 21.08.2014 10:45:03 21.08.2014 20:45:03 krbtgt/AD2008.TEST@AD2008.TEST
renew until 22.08.2014 10:45:00, Flags: FRIA
Etype (skey, tkt): arcfour-hmac, arcfour-hmac
As you can see, my 2008 R2 setup forces aes256-cts already.

Note that if you have allow_weak_crypto = true

in [libdefaults] in /etc/krb5.conf, you'll see Kerberos library
requesting des keys:

....
[22974] 1408607391.836699: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts, des-cbc-crc, des, des-cbc-md4
....

To force certain types, one can use default_tgs_enctypes:

default_tgs_enctypes = aes256-cts, aes128-cts, rc4-hmac, camellia128-cts, camellia256-cts

-m

Thanks, Mark. I'm going to do all I can to avoid the issue completely, but I feel much more comfortable knowing there's a simple workaround if I run into it.

-John

I tried the folloing the new guide and when we ran the auth gui tool we are no longer able to log in. Addtionally we still can not get a machine keytab. Any ideas on how we can get working again.

Mike,

The authconfig tools (GUI, CLI) are a 2 edged sword and can easily clobber the previous settings. It has the capability to backup and restore the underlying files but unfortunately no "reset" option - at least none that I have yet to see.

Here is my suggestion. Go back through the following files:

/etc/krb5.conf
/etc/sssd/sssd.conf
/etc/pam.d/system-auth-ac
/etc/pam.d/password-auth-ac

and make sure they are configure just as documented in the reference architecture but adjusted for your environment. Pay close attention to the 2 PAM config files where the ordering is critical and the SSSD entries (pam_sss.so) must be correct. (For example, you should not have pam_sss.so and pam_krb5.so or pam_nss.so.).

-m

Hi,
I have configured RHEL6.5 authenticate against Win 2008 using config-3, SSSD/Kerberos/AD.
I ended up using "access_provider = simple" to filter users logging in to RHEL system based on their AD group memberships. I am having issues with changing AD user passwords from their RHEL sessions:
$ passwd
Changing password for user joe.
Current Password:
New password:
Retype new password:
passwd: Authentication token manipulation error

Tried using chpass_provider = ad with it but it is not working.
Any comments or suggestions from people who got this working along with "access_provider = simple" option?

Mesut,

When you specify 'access_provider = simple' do you have a simple list specified in your sssd.conf? Can the user you are attempting to change the password for login to the server OK?

eg.

access_provider = simple
simple_allow_users = user1, user2

I suggest turning the access_provider setting off completely until you have determined the root cause of your password changing error.

The 'passwd: Authentication token manipulation error' error is likely due to the password you are setting not meeting the password requirements of the Active Directory domain. The password prompt and validation happens locally, the server then attempts to use the password to update Active Directory. If it doesn't meet the Active Directory password policy, you will get the generic password manipulation error.

Can you confirm that the password meets the password policy? (after confirming the user can login to the server OK)

Yes, I am using "simple_allow_groups = linux_admins" and access to RHEL system is based on AD user' group membership.
Filter works when enabled.
For password changes, I commented out the access filter as suggested.
And yes I can use the rejected password on AD' users/computers and change user' password.

From RHEL system though:

login as: aduser
aduser@172.x.x.x's password:
Creating home directory for aduser.
[aduser@cntnt01 ~]$ passwd
Changing password for user aduser.
Current Password:
New password:
Retype new password:
passwd: Authentication token manipulation error

/var/log/secure entries while above is happening:

Sep 7 21:03:38 cntnt01 sshd[20564]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.x.x.x user=aduser
Sep 7 21:03:38 cntnt01 sshd[20564]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.x.x.x user=aduser
Sep 7 21:03:38 cntnt01 sshd[20564]: Accepted password for aduser from 10.x.x.x port 56638 ssh2
Sep 7 21:03:38 cntnt01 sshd[20564]: pam_unix(sshd:session): session opened for user aduser by (uid=0)
Sep 7 21:03:42 cntnt01 passwd: pam_unix(passwd:chauthtok): user "aduser" does not exist in /etc/passwd
Sep 7 21:04:01 cntnt01 passwd: pam_unix(passwd:chauthtok): user "aduser" does not exist in /etc/passwd
Sep 7 21:04:31 cntnt01 passwd: pam_sss(passwd:chauthtok): Password change failed for user aduser: 22 (Authentication token lock busy)

I am trying to keep the configuration as simple as possible with SSSD (sssd-1.9.2-129.el6_5.4.x86_64) and AD 2008 R2.
Used the sample config #3 from Ref Architecture document.

Thank you!

Is it possible for you to paste a (sanitised) copy of your krb5.conf and sssd.conf?

Sure,

sssd.conf:
[sssd]
config_file_version = 2
domains = example.com
services = nss, pam
debug_level = 5

[nss]

default_shell = /bin/bash

[pam]

[domain/example.com]
ad_server = exampledc01.example.com,exampledc02.example.com
ad_hostname = cntnt01.example.com
ad_domain = example.com
chpass_provider = ad
override_shell = /bin/bash
override_homedir = /home/%d/%u
ldap_access_order = expire,filter
ldap_account_expire_policy = ad
ldap_referrals = False
cache_credentials = False
enumerate = True

@ SIMPLE ACCESS PROVIDER SETUP

id_provider = ad

access_provider = ad

simple_allow_groups = dev_linux_admins,content_linux_users

@ END SIMPLE ACCESS PROVIDER SETUP

And krb5.conf:
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true

[realms]
EXAMPLE.COM = {
kdc = exampledc01.example.com
admin_server = exampledc01.example.com
}

[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM

I think they are pretty generic.
Thank you.

For some reason "#" signs didn't make it to previous post at "# @ SIMPLE ..."

Hi Mesut,

It maybe worth trying to reduce your sssd.conf and krb5.conf down to the essentials. I personally use a very reduced configuration that I have developed over time. I have validated this configuration with the 'simple' access provider, and password changes against both AD 2008 R2 and 2012. I am not sure it will assist in your situation but I will paste it in in case someone can find it useful:

/etc/sssd/sssd.conf

[sssd]
config_file_version = 2
debug_level = 0
domains = mydomain.local
services = nss, pam

[domain/mydomain.local]
id_provider = ad
access_provider = simple
simple_allow_groups = user_group
ldap_id_mapping = false
enumerate = true

/etc/krb5.conf

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = MYDOMAIN.LOCAL
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true

[domain_realm]
.mydomain.local = MYDOMAIN.LOCAL
mydomain.local = MYDOMAIN.LOCAL

The primary configuration I do differently is enable the dns lookup capabilities of Kerberos (dns_lookup_kdc). Active Directory provides the '_kerberos' and '_kpasswd' DNS records natively (ie. without modification) and I believe they should be used as they provide a dynamic lookup capability. I still manually define domain -> realm mappings locally however.

In your situation I would validate that these records exist and confirm that you can connect to the kerberos services:

nslookup -query=srv _kerberos._tcp.mydomain.local
  _kerberos._tcp.mydomain.local        service = 0 100 88 mydc01.mydomain.local.
  _kerberos._tcp.mydomain.local        service = 0 100 88 mydc02.mydomain.local.

nslookup -query=srv _kpasswd._tcp.mydomain.local
  _kpasswd._tcp.mydomain.local        service = 0 100 464 mydc01.mydomain.local.
  _kpasswd._tcp.mydomain.local        service = 0 100 464 mydc02.mydomain.local.

telnet mydc01.mydomain.local 88
telnet mydc02.mydomain.local 88
telnet mydc01.mydomain.local 464
telnet mydc02.mydomain.local 464

In particular I would confirm that your server can connect to the '_kpasswd' hosts listed on port 464 as this is the service used to change your password.

The Kerberos documentation states that it will attempt to use the admin_server as the kpasswd server if no kpasswd server is specified, so in your example it will be using exampledc01.example.com anyway, but it is worth checking what the DNS records provide in regards to kpasswd server and validate connectivity.

Unfortunately I haven't come across your 'authentication lock busy' error, so don't have any more specific assistance. If you still can't resolve the issue I would look at raising it with support.

Hi Mesut,

I'm sure you are already aware of this but just to be clear - we (systems engineering) haven't tested/verified the simple provider. That doesn't mean it can't be used but just that we have not verified it. By design we chose the AD provider for simplicity and functionality, just as we did for the other 3 configurations in the reference architecture.

I'm not trying to dissuade you from modifying any of configurations - just re-iterating that we can only test/verify/support a finite number of them :-)

Having said that, make sure you do not mix the valid parameters in one configuration with those from another. In other words, if you switch to using the simple provider then the parameters for the ad provider may be entirely different (because the context is different) so be sure check the relevant man pages (sssd-simple, sssd-ad, etc.). I see this often with customers and they just end up going back to the original, clean configuration because their configuration is munged.

btw - I actually filed an RFE (https://bugzilla.redhat.com/show_bug.cgi?id=1072458) 6 months ago requesting we have a syntax checker for the sssd.conf file - something very similar to the Samba testparm utility. It's still slated for the RHEL 7.1 timeframe.

-m

I will be back in my test enviroment in 2 weeks and will try all the above sugestions. I did get automaps and most working. I has having issues with sotage Isilon authentication. I have a plan will post after testing.

Note: I have relocated this post/discussion to the community for for more visibility:
https://access.redhat.com/discussions/1283873

Can anyone add some insight as to how AD machine password resets are handled in the above Red Hat configuration?

Having a look at Active Directory, it appears that the Samba 'net ads join' creates the machine account in AD with the option "PasswordNeverExpire". I have looked at different implementations and this appears common across them.

The machine account (by default in 2000+) has a default configuration of password expiry every 30 days, but it appears that when using the reference architecture, after the initial join the password is never changed (which is why I assume Winbind sets the PasswordNeverExpire option?).

The machine account password reset is meant to be initiated by the client and in the Windows world this reset is done by the netlogon service. Does anyone have a solution / alternative for this? as I would definitely prefer to not have PasswordNeverExpire set on the machine account.

More details on the machine account password in Windows here:
http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx

I am considering implementing configuration 1. Does the use of Samba version 4 alter the configuration at all?

Hi Fabian,

We've not tested this configuration on Samba 4 but to the best of my knowledge you should be fine. The bulk of the work done in Samba 4 was focused on improving MS compatibility and adding AD domain controller capabilities.

You can view the Samba project wiki for more insight:

https://wiki.samba.org/index.php/Samba_4.x_Readme_First

Please do post back with your deployment results - would be useful for others as well.

Best,

-m

Can you explain how to configure SSSD/Kerberos to authenticate against a Windows RODC? Is there an alternative if it doesn't work with Kerberos?
When I run "net ads join -k"
I get an error: Failed to join domain: failed to join domain 'XXX.LOCAL' over rpc: NT_STATUS_NOT_SUPPORTED

Dejan,

I've not worked with RODC but it appears the issue has to deal in how the machine accounts are mamnaged. I also see that you already posted a similar question in the context of Samba 4 here:

https://access.redhat.com/solutions/474023

so unless anyone else chimes in here, my best suggestion would be to reach out to the FreeIPA team list (freeipa-users@redhat.com) and be sure to include:

  • Windows Server version
  • RHEL version
  • Verison of SSSD in use (sssd --version)

The FreeIPA team is very responsive.

-m

Hi,
I'm a linux novice so please forgive me if this all doesnt make complete sense. I have been trying to use this guide to set up authentication against a Windows Server 2012 R2 forest for systems running RHEL 6.6. I have been trying to use option 4 (ldap/kerb) because it seems to be the only option that does not require the RHEL system to join the Windows domain and the only thing I want to accomplish is to have AD users be able to use their AD credentials to login to the RHEL systems. The reason I do not wish to use one of the other methods that join the RHEL system to the AD domain is that the RHEL systems will be deployed as VDI desktops running under VMware View 6.1.1 (which now supports RHEL 6.6 desktops). My logic is that it would be much easier to setup the desktop image being used by View to just have it authenticate AD users without joining the domain rather than to configure the image so that every time a new RHEL system is automaticaly deployed it would have to use some form of scripting actions to configure the authentication and then join the new RHEL system to the AD forest. I'm not a scripter and that seems like it would be a pretty significant scripting task to generate.

So here are the questions I have far:

  1. Should option 4 (ldap/kerb) as described work with Windows Server 2012 R2-based AD's?

  2. Assuming option 4 (ldap/kerb) works with WS2012 R2; do I need to configure any of the Unix attributes (gid,uid, etc...) on my AD user accounts that I want to be able to login to the RHEL systems? WS2012 R2 doesnt have the SFU or IDMgmt components anymore but the Unix attributes (unpopulated) are there in the Schema because when I look at the Attributes Editor section for any given user account I see them and can edit them.

  3. Is there a better method I should be considering? Again, if possible I don't want the RHEL machines joined to my AD. There is no real RHEL infrastructure services in my environment (i.e. IDM) and I want to avoid having to deploy additional infrastructure services to support RHEL systems if I don't have to.

  4. I believe I have kerb fundamentally working correctly. I can use kinit "AD_username"@"AD_REALM_NAME" to get a ticket from AD from the CLI on the RHEL system. I have to put the Realm name in all upper case for it to work though. Is there a way I can make it work with both upper and lower-case?

  5. Using option 4, assuming its configured correctly, what would be the format AD users would have to enter their names as when they attempt to login? (i.e. joeuser, MYDOMAIN\joeuser, joeuser@MYDOMAIN.COM, or joeuser@mydomain.com)

  6. Using option 4. is there any configuration required for the /etc/ldap.conf file? I didnt see anything in the guide but when I look at a lot of other Internet sites they seem to configure things there as well.

  7. In the various config files where I specify the URI do I need to include a port # in the URI? Again, on the internet I have seen people doing it different ways?

  8. When entering the ldap URI rather than using a specific AD domain controller (i.e. dc1.mydomain.com), can I just use the domain name (i.e. mydomain.com) since that resolves to any available domain controller? From a reliability/performance perspective it would seem better if I dont have pin the LDAP queries to just one specific AD DC.

Thanks for any replies...

Mike

Hi Mike,

All good questions :-)

First, let me step back and share a new Tech Brief titled "Red Hat Enterprise Linux: Active Directory
- Client Integration Options". I literally just put the finishing touches on and will be sharing at the
IdM-Windows interoperability booth this afternoon at Red Hat Summit. I've put a copy here that you can download:

http://people.redhat.com/~mheslin/Tech-Briefs/AD_Client_Integration_Options-2015-06-23.pdf

So you can officially claim to be the first customer to download it :-)

Take a peek at this and see if this helps clarify the client options. I worked very closely with the identity engineering team to create this. Every year at Summit, I have customers approach me
about older/mixed versions of RHEL and how best to integrate them with AD. This is our attempt
to adress that gap.

If I were you, I would suggest you consider using the "Modern" option and go with the SSSD based
configuration (Configuration 3 - "Enhanced) - especially since you are running RHEL 6.6 clients.
(in the Reference Architecture it's called "Enhanced", in the Tech Brief it's called "Modern" but it's
the same configuration).

The SSSD client configuration is much simpler, smarter, easier to work with. It uses the AD provider
which has been optimized to work for exactly what you are doing. It also is able to work with AD
whether or not the POSIX attributes (aka - rfc2307, IMU/SFU) have been enabled.

On other thing regarding case sensitivity. AD treats Kerberos principals as case insensitive. The default from the Linux side is to treat them as case sensitive. There is an option for sssd.conf
that you can configure 'ldap_force_upper_case_realm' - but you would need to check to see
if that is still supported (I haven't checked on RHEL 6.6 so it could have been deprecated).

Hope this helps clarify and get you pointed in the right direction. If you have other questions
feel free to reach out to me - I'll be at Summit the rest of the week so I may not be able to respond
as easily.

Cheers,

-m

Mark,
Appreciate your prompt response. My main concern with option 3 that you suggest is that it seems to requires me to join the RHEL systems to AD which is the one requirement I am trying to avoid. Am I misunderstanding the configuration presented in option 3?

Thanks,
Mike

Hi Mike,

Sorry for the delay (@ Summit last week).

So, basically you are correct in that the only configuration that doesn't do a true AD domain join is configuration 4. The other configurations all do the equivalent of obtaining a keytab and then running a 'net ads join' underneath.

I'm assuming you have a strong reason/preference for not having the RHEL hosts join the domain? Technically, you will see the hosts appear in AD as machine accounts but they can not be managed via policies like Windows clients - the entries you see are mostly just placeholders to let you know they are accessing the AD domain for ID lookups and authentication. The RHEL hosts have no write access or capabilities.

-m

Mark,
Sorry for this extremely long reply. So a couple of follow ups. First, could you please address question's # 1, 5, 6, 7, and 8 above if you know the answers? (if they are even relevant)

Second; I wanted to explain why I believe it would be best not to have them joined to the AD domain. Please let me know if any of them are poor reasons for not wanting them to join the AD domain because maybe I'm trying to tackle this problem in the wrong manner:

  • All Linux VMs will be deployed from VMware vCenter templates. vCenter Customization Specs for Linux don't allow for any post-deployment scripting as part of the deployment process. vCenter can only change the host name and IP addressing of Linux VMs deployed from a template. If the Linux systems aren't joined to the domain then I can still have AD users login immediately after the systems are deployed from the template with no further customization of the Linux system required.
  • These Linux systems will be part of a virtual desktop environment. In my situation there could potentially be thousands of them deployed and destroyed. This would create tons of computer objects in AD that might no longer exist as the Linux desktops are destroyed.
  • There is no requirement for file sharing between these Linux systems and Windows-based systems, Hence, no desire to install SAMBA components and deal with that additional component.
  • If I use any of the domain join options I would have to configure the Linux systems to run some kind of boot script after they have completely finished deployment in vCenter to get them to join the AD domain. This would have to happen after vCenter changes the Linux system's host name to something unique and it would have to happen in a completely automated manner to be useful in my situation. Not being a scripter or familiar with Linux boot sequencing, this option seemed kind of scary to me. If it would be easy to do this kind of thing then using any of the domain join options would be fine. If this is feasible can you point me to some resources that might cover where and how to run a one-time shell script without interactive login?

I also wanted to ask one additional question:
- Can I use the SSSD option with LDAPS authentication against the AD instead of using the SSSD pure AD method? If I can, would this eliminate the need to join the AD domain and still allow me to use SSSD? Since you are saying SSSD has supplanted NSLCD this might seem like the best option if it would work. If this is feasible, can you point me to any documentation examples for that kind of scenario?

Thanks,
Mike

If I use any of the domain join options I would have to configure the Linux systems to run some kind of boot script after they have completely finished deployment in vCenter to get them to join the AD domain.

I had an almost similar situation to tackle (regarding the script after boot). We came up with the following solution:

  1. In your Linux VM template, create an empty file /etc/firstboot
  2. Create your script in e.g. /usr/local/bin/firstboot
  3. In this script, you check for the existence of the /etc/firstboot file. If it exists, you execute the rest of the script (in your case join the AD domain) and at the end you remove the /etc/firstboot file. If it doesn't, exit the script.
  4. Make sure this script runs on each boot. Don't worry, it will only execute once because the trigger file is deleted.

The only issue with this approach is that it's hard to maintain your template (at least in our case with Hyper-V). Because if we needed to modify the template, we had to create a VM from the template, which would trigger the firstboot script. Then we had to create the trigger file again, do our modifications and re-create the template. If have no idea if this would be the same for VMWare.

I'm sure there are other (and possibly better) options as well.

The problem i've seen with this approach is that VMware boots the VM to do the guest customisation (ie. network configuration), this initial boot will trigger your firstboot script before the guest has been customised with the new IP and hostname configuration.

Are you using guest customisation in VMware with this method? or are you doing a simple clone + boot?

I use orchestration tools to carry out the AD join after the VM is deployed. The problem with joining AD from Linux servers is that the machine account password is set to never expire (as I detailed above) so when the hosts are deleted/removed the machine accounts remains in AD and must be cleaned up. In Windows, the machine account password is regularly updated by the Windows host and can be cleaned up by scavenging scripts based on the last updated/reset time.

Hi PixelDrift,
Could you let me know what automation tools you are using? If you have any script/code examples to go along, that would be great as well. My concern with what you mentioned is that the VM has to be ready to accept AD logins right after vCenter guest customization and/or any boot scripts have completed. Do you have something in the VM image that is checking in with the automation tool during boot to see if the VM needs to be domain-joined and then executing a script or are your tools running on a scheduled basis and doing that configuration later on?

It really seems to me that using the domain-join approach is ultimately a bad idea and if I can get LDAP authentication to work it keeps things much simpler. Even if I have to populate POSIX attributes on the AD users accounts for LDAP to work that's still a better solution from my perspective. I have seen example PowerShell scripts to go mass populate the POSIX attributes so I know that wouldn't be a lot of work.

Hi Michael,

With VMware I am integrating with the full vRealize automation suite to provide orchestration capabilities. Configuration of Linux OS components is handled by Puppet.

I join Linux hosts to AD. There is (from memory) only a couple of samba packages to add for the join and no services are required (low overhead). I clean up any AD artefacts for the host on teardown using orchestration scripts executed by vRealize.

In other situations without access to orchestration, the following style of workflow has worked for me (without guest customisation):

  1. Clone VM with DHCP baked into the image (no guest customisation)
  2. Boot with DHCP and acquire IP Address
  3. First boot script in the VM requests IP from IPAM service (if static is required)
  4. Reconfigure/restart networking
  5. Register with network services (Satellite / Puppet / AD)

Stijin,
Can you provide a copy of the script you are using? I agree that this is not the best approach but for my scenario it would probably be workable. I can think of a couple of things that could be added to make it a little more robust:
- For it to work properly with VMware you would have to make it so it actually does it on the second reboot instead of the first.
- You might also want to add in some kind of waiting delay (1-2 minutes?) in the script that would give you enough time to login and kill the script before it runs to make template management a little easier.

Mike

I don't really agree with item 3 (adding delay for template management).

You should really aim to get the template to build from a non-interactive kickstart that shuts down the VM at the end of build ready for conversion. If any changes need to be made to the base template, update the kickstart + rerun the process, that way the template is always reproducible and its provenance is known.

-edit-
Sorry to get sidetracked, these are probably automation discussions for the community discussion section.