I'm trying to set up a trust between IPA and Active Directory, and it keeps
failing. The problem is the same as this one
the solution is not. In that case, it was solved by enabling IPv6 in the
kernel, and in this
For Active Directory cross-forest trusts to work, we need following records
to be in place:
Information Technology Services
700 Exchange St.
Middlebury, VT 05753
From: Alexander Bokovoy aboko...@redhat.com
Sent: Tuesday, February 10, 2015 2:51 AM
To: Guertin, David S.
Subject: Re: [Freeipa
For the record, here's the solution I came up with for RHEL6 (and presumably
other SysV init-based systems):
Its Linux kernel is 2.6, which does have IPv6 enabled. The ipv6 module is
loaded. I had looked at those and assumed that everything was OK, but these two
are not enough. I needed to
Wait, why do you have middlebury.edu section here at all? If middlebury is
trusted by csns.middlebury.edu, you should not have a separate
[domain/middlebury.edu] section at all!
That was in there because in my increasingly desperate attempts to get this
working, I actually read the
In standard FreeIPA setup we have 'allow_all' HBAC rule which roughly
states anyone can access any service on any host. Did you disable this
If yes, then you have to have an explicit rules allowing access to specific
Thanks! Yes, that was it exactly. I did disable the allow
We have a trust relationship established between our AD domain and our IPA
domain, and AD users can be found on the IPA server with id and getent passwd.
When a user tries to SSH to the IPA server with AD credentials, the logs show:
(Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]]
I don't think sss_cache -E removes cached idrange objects. You need to
delete the databases in /var/lib/sss/db/.
OK, I stopped sssd, removed everything in /var/lib/sss/db, and restarted sssd.
Still no change -- I get the same error.
You mean RHEL 7.1, right?
Yes, RHEL 7.1.
I've almost got AD integration going, except for the minor detail that no one
can log in. When an AD user tries to SSH in to the IPA server, /var/log/secure
Mar 18 13:59:08 genet sshd: pam_unix(sshd:auth): authentication failure;
When you changed idrange, it helps to remove SSSD cache, both on IPA
master and IPA clients and restart SSSD.
OK, I cleared the cache and restarted sssd with:
systemctl restart sssd
Still no change in the error: Could not convert objectSID
Seems the initial/default setup for IPA server is to put in an 'allow_all'
rule. Thus you can actively manage HBAC but out of the box, it is essentially
turned off by that rule.
Yes. The default was the opposite very long time ago, you had to explicitly
enable access to the box. But it was
You should be able to 'see' them via getent passwd but they should not be
allowed to login when HBAC_ALLOW_ALL is disabled.
Ah, OK, thanks, that's what is happening. I can see them with getent passwd and
id, and I can su to them, but I can't log in as them.
On the other hand, I also can't log
I have already:
- created an IPA group called ad_users.
- created an IPA group called ad_users_external.
Did you create this group with --external?
Doh! Nope, somehow I missed that. I've done that and that part is working now.
But the other part of the question remains, i.e. I'm still seeing
For troubleshooting this you need to enable debug_level=10 in sssd.conf in
domain and pam sections. Restart sssd and try to login.
OK, this has pinpointed the problem. The log file now shows:
(Wed Mar 11 11:31:01 2015) [sssd[be[middlebury.edu]]] [sdap_save_user]
(0x1000): Mapping user
I'm on my second attempt trying to set up an IPA server with a trust
relationship to our AD domain. The first attempt had inexplicable problems with
winbind, so this time I've set up a RHEL7 server, and things are going better,
but I'm stuck when trying to add an AD user group to an IPA group.
What are the platforms and package versions of SSSD on these clients?
Manage your subscription for the Freeipa-users mailing list:
Follow-up: today I tried clearing the sssd cache and restarting sssd on all
three clients, and all three lost their AD users:
# rm -f /var/lib/sss/db/*
# service sssd restart
Stopping sssd: [ OK ]
To see why the login fails it would be good to
know how you try to log in (I assume ssh) and which authentication method
is used (password, ssh key, Kerberos ticket).
Additionally the SSSD log files might be needed, most important here are the
logs from the PAM and PAC responders and the domain
Lets separate issues.
1. Adding AD user to IPA group in AD.
Did you re-login as that user on Windows side and then tried to logon
to IPA server?
2. What do SSSD logs say about the login attempt? You need to set
debug_level = 10 in [domain/..], [nss] and [pam] sections of
Can you show us your sssd.conf? When SSSD runs on IPA master it should
not use extdom (ipa_s2n_exop_send and friends) at all.
Sure, here's my sssd.conf:
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = csns.middlebury.edu
Do these logs come from a client or the IPA server? Are you able to look up
the user on the IPA server at least?
These come from the IPA server. So no, I can't even look up the user on the
Can you paste (sanitized) logs from the sssd_be process as well? They would
be located at
I'm trying to set up a trust relationship between IPA and our Active Directory
environment so that our AD users can log in to our Linux machines. The two-way
trust relationship appears to be set up correctly, with no errors reported, and
everything looking normal in the GUI and the CLI. For
I gather that you are running some version of RHEL 6.x (you never stated
your exact setup). What do you get with
Yes, this is RHEL 6.6
# wbinfo -m
wbinfo -i 'AD\user'
# wbinfo -i 'MIDD\testuser'
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
Could not get
yes, I'm quite certain this is the client.
Actually, it isn't, or at least it's not supposed to be. I've only ever
installed IPA on one machine, and the command I used to install it was
ipa-server-install (followed by ipa dnsconfig-mod, ipa-adtrust-install, and ipa
trust-add, as described in
The most likely reason for 'Protocol error' is that the server this client is
connected to does not support the special LDAP extended operation used by
SSSD on IPA clients to get the data for users and groups from trusted
domains. And the most likely reason for this is that ipa-adtrust-install is
I have three IPA servers set up (master and two replicas) and they're all
behaving normally. AD users can log in, AD group restrictions are honored, etc.
Now I'm trying to set up clients, and running into problems. I have three
clients set up, and all three behave differently.
On one of the
I would like to just clarify tis a bit. The support to lookup up secondary
(the group list the id command shows) for user which never authenticated
was added in 7.1/6.7.
Thanks. This makes sense, and indeed with Client 1 I can indeed log in, and id
'MIDD\juser' shows all the groups
The sequence to emulate what SSSD does would be
kinit -k host/`hostname`
ldapsearch -Y GSSAPI -H ldap://genet.ipa.middlebury.edu \
-b cn=compat,dc=ipa,dc=middlebury,dc=edu -s sub \
As result, we have 'ad...@middlebury.edu' inserted in the
What slapi-nis and ipa packages are on the IPA master side?
This all looks like IPA masters don't have RHEL 7.1 update 1 packages from
https://rhn.redhat.com/errata/RHSA-2015-0728.html where exactly this
problem with initgroups was fixed.
Yes, that was it! I had not applied those updates. I just
I have a mixed environment of RHEL 5 and RHEL 6 clients, and three RHEL 7 IPA
servers (one master and two duplicates). I'm trying to ensure that if one
server goes down, the remain server(s) will still allow logins. With the RHEL 6
clients this is easy -- the line
ipa_server = _srv_,
I've just set up an IPA domain that is working with our RHEL 6 clients. (The
servers are running RHEL 7.) But about half of our Linux servers are running
RHEL 5, and I'd like to be able to add these as clients as well. Unfortunately
I haven't been able to get it working. Before I get too deep
The 5.x ipa-client should work fine. What isn't working?
I cannot SSH in as an AD user. (Sorry, I should have mentioned that in my
original post.) The client installs without errors, and I can get a Kerberos
ticket for the admin user. But when I try to SSH in as an AD domain user, the
Ah so you are using it with trust. Then you should change the configuration to
not use kerberos but rather LDAP instead.
More details are here.
Thanks. When I ran ipa-adtrust-install on the servers, I hadn't used the
i.e. they both contain both sss and ldap, with sss first. The client was
installed with the script generated by running ipa-advise config-redhat-
sssd-before-1-9 on the server. This script contains:
# Use the authconfig to configure nsswitch.conf and the PAM stack
We have a trust relationship set up between our IPA domain and our AD domain.
When ad AD user logs in to an IPA client, they are given a home directory of
/home/ad-domain/username. I would like to change this to /home/username.
(I'm not interested in automatically creating the home firectory on
If your clients are RHEL 7.1, remove all of the hacks and use ID Views instead.
ID view 'Default Trust View' will be applied automatically -- on RHEL7.1
clients by SSSD picking
Since the trusted AD domain is a 'subdomain' in SSSD lingo, you need to
change the 'subdomain_homedir' parameter in sssd.conf
Perfect! That's exactly what I was looking for.
Manage your subscription for the Freeipa-users mailing list:
If that works it means that you are not using SSSD on RHEL5 clients.
Please check your nsswitch and pam.conf to see what modules are actually
Hmm. /etc/nsswitch.conf contains:
passwd: files sss ldap
shadow: files sss ldap
group: files sss ldap
Can you try searching the compat tree with ldapsearch to see if an entry turns
up? IIRC you need to search for a particular entry, not for any (not ie cn=*),
but if you crank up the debug_level in the domain section, then sssd should
log the searches to /var/log/sssd/sssd_default.log
Mail list logo