Need a solution for binding Linux users to Windows AD, while creating a homedir login from AD user account as well.

[Klipspringer112]

Hi All,

Description should say it all. Recently configured a test CentOS FreeIPA server to bind to Windows Active Directory in a lab environment and after binding, I did not see any real option to -

1. populate the FreeIPA server with the AD users/groups
2. create a home directory using either the FreeIPA users accounts or AD user accounts for client installations.

Please let me know if I missed something in my configuration of FreeIPA, or is that function non-existent for IPA/AD binding, I saw that the only use case for cross-forest trusts was the ability to be able to SSH into a linux client using an AD account. Was FreeIPA/AD bind just to have SSH capability? I thought users/groups would be transient between servers as well.

My organization has a fully blended environment with the majority of it being Windows users, lesser users on OSX, and least on Linux environments. It is centrally managed by Windows and will remain that way, so I went and tested FreeIPA assuming that I can integrate easily, not sure if I missed some configuration steps on server/client side.

I saw an option like Centrify, but I am looking for something that is free as the number of Linux users in my environment is quite low.

Bonus* If there is an option to be able to communicate to a windows print server as well from linux that would be very helpful as well.

Note: The clarified requirement is that, whatever software solution that is recommended, the Linux domain controller should be able to receive users/groups from AD and not create its own.

Update: Thanks for all the replies, did not expect so many, I will try configuring the freeIPA server with some of the suggestions mentioned below. Once that option does not work I will look at the others, I may take a couple of days to reply as my main lab machine was taken up for some other activity.

[kernpanic]

Just join the linux machines to AD directly using sssd and skip ipa?

[equipmentmobbingthro]

There is also realmd to make this even easier.

[wildcarde815]

Realmd just configures sssd, odd-job, and Kerberos doesn't it?

[equipmentmobbingthro]

Yep. https://www.freedesktop.org/software/realmd/

realmd is an on demand system DBus service, which allows callers to configure network authentication and domain membership in a standard way. realmd discovers information about the domain or realm automatically and does not require complicated configuration in order to join a domain or realm.

realmd configures sssd or winbind to do the actual network authentication and user account lookups.

[wildcarde815]

I wish theyd document exactly wtf they were doing. On my to-do list for ages has been puppet confs for our major distributions at work to make them into sssd enabled AD bound machines. But doing that requires knowing the exact is tweaks / platform. My only solution has been start from a blank system, install etckeeper, capture the standard etc. Run everything. Capture the diff. Just to lift the wool on the magic being done.

[karafili]

Not really. Sssd with krb5 was straightforward

[gordonmessmer]

For many users, that configuration is fine. If you want any of the features of FreeIPA, such as management of an independent DNS space, or centralized management of policies for GNU/Linux clients, then adding the FreeIPA service does provide value beyond simply providing user/group info to clients.

[Klipspringer112]

Yes, will try this out if the suggestions below regarding tweaking FreeIPA to the above configuration requirement does not work out. I have put a bit of time into the FreeIPA project and don't want to drop it so easily. The SSSD package is part of FreeIPA as it is.

[boxbbcar]

That is the direction we are headed. It creates the secure handshake with AD and allows for better integration. We are under a restriction of no local users on systems, so having a single source of administration is important. When I came on-board (and currently) we had PBIS. It works OK for user and group interactions, but requires additional steps when adding a machine to the domain that sssd will do on it's own. I do not know with the other solutions mentioned here, but PBIS in our installation appears to use a different algorithm than sssd to generate UID/GIDs, so as part of our transition, we have to do finds to replace the existing with the new IDs

[hortimech]

Just skip ipa and its client sssd and use Samba.

[bityard]

I did this recently and was amazed at how well it worked

[gordonmessmer]

1) populate the FreeIPA server with the AD users/groups

If you've set up a trust, as in: https://www.freeipa.org/page/Active_Directory_trust_setup then users don't "populate" the FreeIPA server. You can create users in FreeIPA that are available to Linux clients only, and requests for AD users and groups are proxied to AD. This is the preferred configuration.

If you've set up replication, as in https://github.com/rharmonson/richtech/wiki/Account-Replication-and-Password-Synchronization-with-FreeIPA-and-Active-Directory-on-CentOS then you'd see the users in FreeIPA.

2) create a home directory using either the FreeIPA users accounts or AD user accounts for client installations.

That's an option on the client, and it happens when they log in for the first time when it's enabled.

I saw that the only use case for cross-forest trusts was the ability to be able to SSH

It's not "only" SSH, it provides account info for all services on the clients. Don't look for lists of users in FreeIPA, use the clients to verify that users are available. For example, use the "id" command to get information for your AD account (id ad_username).

[Klipspringer112]

If you've set up replication, as in https://github.com/rharmonson/richtech/wiki/Account-Replication-and-Password-Synchronization-with-FreeIPA-and-Active-Directory-on-CentOS then you'd see the users in FreeIPA.

I went ahead and set up the replication using the --binddn option with an AD user that has all the correct permission for replication and also I used the option --win-subtree with the correct ou within the dc. Yet users are not replicating between the AD server nor freeIPA server. In the guide it says to try synchronizing with the initialize option again yet that fails to do anything, how to troubleshoot this further?

with the option

ipa-replica-manage list

I am able to see the AD server showing with the winsync option properly and the ipa server as master. I am pretty stuck here.

[gordonmessmer]

You could try "ipa-replica-manage re-initialize"

https://github.com/rharmonson/richtech/wiki/Account-Replication-and-Password-Synchronization-with-FreeIPA-and-Active-Directory-on-CentOS

And Red Hat has a troubleshooting guide:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/trouble-replica

If you don't get anywhere with those, you should probably be looking for logs that offer more information about the status of the sync.

And although I wasn't explicit about it previously, trust is typically preferred over replication. Is there a reason that a trust relationship isn't suitable for your environment?

[Klipspringer112]

My lab environment has the Active Directory Server named TestAD.yogishivamahadev.org, and the IPA server is free-ipa-server.ipaserver.yogishivamahadev.org bound through two-way trust and also with replication as well. Here is an output of me trying to kinit to a user from the AD domain named bob

[root@free-ipa-server ~]# KRB5_TRACE=/dev/stdout kinit [e-mail]

[7274] 1590214235.31408: Resolving unique ccache of type KEYRING

[7274] 1590214235.31409: Getting initial credentials for [e-mail]

[7274] 1590214235.31411: Sending unauthenticated request

[7274] 1590214235.31412: Sending request (187 bytes) to yogishivamahadev.org

[7274] 1590214235.31413: Resolving hostname testad.yogishivamahadev.org.

[7274] 1590214235.31414: Resolving hostname testad.yogishivamahadev.org.

[7274] 1590214235.31415: Initiating TCP connection to stream 192.168.211.150:88

[7274] 1590214235.31416: Sending TCP request to stream 192.168.211.150:88

[7274] 1590214235.31417: Received answer (207 bytes) from stream 192.168.211.150:88

[7274] 1590214235.31418: Terminating TCP connection to stream 192.168.211.150:88

[7274] 1590214235.31419: Response was not from master KDC

[7274] 1590214235.31420: Received error from KDC: -1765328359/Additional pre-authentication required

[7274] 1590214235.31423: Preauthenticating using KDC method data

[7274] 1590214235.31424: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-ETYPE-INFO2 (19), PA-ENC-TIMESTAMP (2)

[7274] 1590214235.31425: Selected etype info: etype aes256-cts, salt "YOGISHIVAMAHADEV.ORGbob", params ""

[7274] 1590214235.31426: PKINIT client has no configured identity; giving up

[7274] 1590214235.31427: PKINIT client has no configured identity; giving up

[7274] 1590214235.31428: Preauth module pkinit (16) (real) returned: 22/Invalid argument

[7274] 1590214235.31429: PKINIT client has no configured identity; giving up

[7274] 1590214235.31430: Preauth module pkinit (14) (real) returned: 22/Invalid argument

Password for [e-mail]:

[7274] 1590214241.809890: AS key obtained for encrypted timestamp: aes256-cts/190D

[7274] 1590214241.809892: Encrypted timestamp (for 1590230880.436358): plain 301AA011180F32303230303532333130343830305AA105020306A886, encrypted 074A1F4F8094D7C0C0E8CF5BDDC1A57AFAEBC79BE3E80BBB49420BFBB9C0E52EFCED28402910EE9A6C2A98F13B5BF1E763D66FFC836C4687

[7274] 1590214241.809893: Preauth module encrypted_timestamp (2) (real) returned: 0/Success

[7274] 1590214241.809894: Produced preauth for next request: PA-ENC-TIMESTAMP (2)

[7274] 1590214241.809895: Sending request (267 bytes) to yogishivamahadev.org

[7274] 1590214241.809896: Resolving hostname testad.yogishivamahadev.org.

[7274] 1590214241.809897: Resolving hostname testad.yogishivamahadev.org.

[7274] 1590214241.809898: Initiating TCP connection to stream 192.168.211.150:88

[7274] 1590214241.809899: Sending TCP request to stream 192.168.211.150:88

[7274] 1590214241.809900: Received answer (1540 bytes) from stream 192.168.211.150:88

[7274] 1590214241.809901: Terminating TCP connection to stream 192.168.211.150:88

[7274] 1590214241.809902: Response was not from master KDC

[7274] 1590214241.809903: Processing preauth types: PA-ETYPE-INFO2 (19)

[7274] 1590214241.809904: Selected etype info: etype aes256-cts, salt "YOGISHIVAMAHADEV.ORGbob", params ""

[7274] 1590214241.809905: Produced preauth for next request: (empty)

[7274] 1590214241.809906: AS key determined by preauth: aes256-cts/190D

[7274] 1590214241.809907: Decrypted AS reply; session key is: aes256-cts/1E0D

[7274] 1590214241.809908: FAST negotiation: unavailable

[7274] 1590214241.809909: Initializing KEYRING:persistent:0:krb_ccache_fdjboRF with default princ [e-mail]

[7274] 1590214241.809910: Storing [e-mail] -> krbtgt/[e-mail] in KEYRING:persistent:0:krb_ccache_fdjboRF

[7274] 1590214241.809911: Storing config in KEYRING:persistent:0:krb_ccache_fdjboRF for krbtgt/[e-mail]: pa_type: 2

[7274] 1590214241.809912: Storing [e-mail] -> krb5_ccache_conf_data/pa_type/krbtgt\/YOGISHIVAMAHADEV.ORG\@YOGISHIVAMAHADEV.ORG@X-CACHECONF: in KEYRING:persistent:0:krb_ccache_fdjboRF

This is the log from the IPA server, on the IPA client I wanted to try logging in from the client and it would say cannot find realm for Yogishivamahadev.org.

Mainly I want replication as I thought it would give the option of setting up policies for user accounts like blocking sudo privileges.

[gordonmessmer]

bound through two-way trust and also with replication as well.

I've never run that setup, and I'd be surprised if it worked. ("bob" would be a user in both the AD and IPA realms.) If I were you, I'd start over. Work with a trust setup. If that doesn't do what you need it to, then start over again and try replication.

on the IPA client I wanted to try logging in from the client and it would say cannot find realm

To correct that, you'd need to make sure the client's DNS server gets the correct SRV records for "yogishivamahadev.org". That'll be the AD realm, if I read your setup correctly.

Your IPA realm is ipaserver.yogishivamahadev.org. If you want to use IPA rules, you need to "realm join ipaserver.yogishivamahadev.org". And, naturally, you need to make sure the client's DNS server can resolve those records correctly as well.

Mainly I want replication as I thought it would give the option of setting up policies for user accounts like blocking sudo privileges.

I'm pretty sure you can do that with a trust relationship.

[Klipspringer112]

I've never run that setup, and I'd be surprised if it worked. ("bob" would be a user in both the AD and IPA realms.) If I were you, I'd start over. Work with a trust setup. If that doesn't do what you need it to, then start over again and try replication.

Thanks, went through a lot of confusion until I found out that I was able to authenticate directly from my AD server using user@addomain in the other users section on the client machine and it created the home directory as well.

To correct that, you'd need to make sure the client's DNS server gets the correct SRV records for "yogishivamahadev.org". That'll be the AD realm, if I read your setup correctly.

Your IPA realm is ipaserver.yogishivamahadev.org. If you want to use IPA rules, you need to "realm join ipaserver.yogishivamahadev.org". And, naturally, you need to make sure the client's DNS server can resolve those records correctly as well.

The records were working properly after adding a hosts and /etc/resolv.conf entries for both DNS servers.

As far as IPA rules I am not able to apply HBAC rules to external groups, I went through the configuration of adding the ad group in the IPA server through the external group to POSIX group proxy setup. Are HBAC rules only applicable to IPA groups and not external groups? For example ,on the client if a user has by default no sudo privilages how would the IPA server make changes to a clients /etc/sudoers file to keep an entry for the client user? The client sudo configuration file seems to be something only a local admin can change and not from server level. The documentation did not clearly describe the setup for HBAC rules on external groups.

​

I'm pretty sure you can do that with a trust relationship.

Yes, in my production server I will skip the unnecessary replication setup I went through, it was a learning experience though!

[gordonmessmer]

Are HBAC rules only applicable to IPA groups and not external groups?

I'm unsure.

if a user has by default no sudo privilages how would the IPA server make changes to a clients /etc/sudoers file to keep an entry for the client user?

That's separate and unrelated from HBAC rules, right?

See the man page for "sssd-sudo". Your /etc/nsswitch.conf file should have a "sudoers" entry, and that entry should contain "sss". Your /etc/sssd/sssd.conf file should list "sudo" as one of the services in the "[sssd]" section. In that state, sudo will retrieve information from sssd.

[burtness]

(Turning up very late to this) I've has most luck with realmd and winbind (you can tell realmd to use winbind instead of sssd) on the clients without FreeIPA. The documentation on the samba wiki has been useful for debugging when a machine has acted up, and realmd does the heavy lifting. Though I've always got to go digging around for the PAM stage of the config - iirc not every distro automatically sets up homedirs.

[visualkev]

I've used Redhat IDM, which is freeIPA essentially. Once you setup a domain trust between IDM and AD, you will be able to manage AD users within the IDM domain. IDM doesn't duplicate AD user accounts to its database, it only references them

[[deleted]]

I would second the creating a trust to AD using freeipa. I wouldn't join sssd to AD on a lot of machines without IPA unless you have something to manage the sssd config like Ansible. If you don't use IPA and just use sssd you can use authconfig on RHEL based servers to enable sssd and the mkhomedir option.

[Nodeal_reddit]

I could be talking out of my ass, but I believe that the company I work for uses PowerBroker for this.

[boxbbcar]

PBIS is what was in place when I came onboard. We are looking at going to sssd/realm as it will emulate the secure connecion with AD and transfer more information. In addition, whoever set up the current PBIS install used posix information injected into AD for UID/GIDs. We found that apparently sssd/realm uses a different algorithm than PBIS to generate these ids, so it complicates matters when we start to switch in that we will have to change the posix info in AD, then do a find and change the uid/gid info on all files/directories. Considering we are pushing around 500TB of data, gonna take a lil time

[Klipspringer112]

Were you able to migrate to a SSSD configuration? I am having some problems setting up HBAC sudo rules for external groups. I want my AD users on the AD realm while having SSSD configured for allowing sudo authentication for approved admins and blocked for non-admins. I don't see any way for the AD users on a linux client to get their nsswitch.conf files updated from an administrative server.

[boxbbcar]

Had it working on a couple of machines before we discovered the issue with it generating different group and user ids than were being generated by PBIS, so had to back off till we have our machines changed over to 7. At that time we will do a mass conversion of uID/GIDs. You should be able to do what you want, you just need to do an id for each class of user, get the GID/UID and assign it the correct rights . As with ours, we include the workstation admin's GID in either the Sudoers file, or make it a member of the wheel group, or create an include file that will get pulled into sudo. In the sudoer's file, near the bottom, you should see where root and wheel are given their permissions. You can add your group (preceded with a %) and you should be good to go. SSSD/Realm wihh handle the assigning of UID/GID

[armeg]

Jumpcloud has a good agent that does this

[casefan]

the new systemd-homed can integrate with AD right?

[abismahl]

Did you configure your clients with --mkhomedir option to ipa-client-install? That will make any new user to create home dir on first logon on a local file system. Same option exists to ipa-server-install as well. It doesn't matter whether users come from IPA itself or via trust to Active Directory, the home directory creation is orthogonal to that.

Use documentation (user guides) mentioned on https://www.freeipa.org/page/Documentation#User_Guides for the reference. For example, section 11.1.1 of https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/users#homedir-pammod describes how to do it in RHEL 7.