>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.
Thanks.
David Guertin
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/l
>If your clients are RHEL 7.1, remove all of the hacks and use ID Views instead.
>https://access.redhat.com/documentation/en-
>US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/id-
>views.html
>
>ID view 'Default Trust View' will be applied automatically -- on RHEL7.1
>clients by SSSD pi
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//. I would like to change this to /home/.
(I'm not interested in automatically creating the home firectory on login, I
just want to ch
>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
>authconfig --updateall --
>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
>used.
Hmm. /etc/nsswitch.conf contains:
--
passwd: files sss ldap
shadow: files sss ldap
group: files sss ldap
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_, server1.
>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 ju
> 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 \
> '(uid=ad...@middlebury.edu)'
>
>As result, we have 'ad...@middlebury.edu' inserted in th
>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
Here's th
>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.
>http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf
Thanks. When I ran ipa-adtrust-install on the servers, I hadn't used the
--enable-com
>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
login fa
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 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
>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 domai
>I would like to just clarify tis a bit. The support to lookup up secondary
>groups
>(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
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 ]
Starting sssd:
>What are the platforms and package versions of SSSD on these clients?
Client 1:
RHEL 6.6
sssd-1.11.6
Client 2:
RHEL 6.6
sssd-1.11.6
Client 3:
RHEL 5.11
sssd-1.5.1
David Guertin
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-use
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 cli
> 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
> rule?
>
> If yes, then you have to have an explicit rules allowing access to specific
> services.
Thanks! Yes, that was it exactly. I did disable th
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
shows:
--
Mar 18 13:59:08 genet sshd[21335]: pam_unix(sshd:auth): authentication failure;
lognam
> 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 documen
> 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.
David Guertin
> 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:
sss_cache -E
systemctl restart sssd
Still no change in the error: Could not convert objectSID
[S-1-5-21-1983215674-46037090-64680646
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]]] [sdap_sa
> 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 [guert
> 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 lo
> > 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
>>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 se
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.
> 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 -m
BUILTIN
CSNS
MIDD
> wbinfo -i 'AD\user'
# wbinfo -i 'MIDD\testuser'
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
Could not
> 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
> 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:
[domain/csns.middlebury.edu]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = csns.middlebury.edu
id_provider =
> 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
server.
> Can you paste (sanitized) logs from the sssd_be process as well? They would
> be located at /
> 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?
Yes.
> 2. What do SSSD logs say about the login attempt? You need to set
>debug_level = 10 in [domain/..], [nss] and [pam] sectio
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 exam
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 edit
id Guertin
Information Technology Services
Middlebury College
700 Exchange St.
Middlebury, VT 05753
(802)443-3143
From: Alexander Bokovoy
Sent: Tuesday, February 10, 2015 2:51 AM
To: Guertin, David S.
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users]
> For Active Directory cross-forest trusts to work, we need following records
> to be in place:
>
> _ldap._tcp.
> _kerberos._udp.
> _kerberos._tcp.
> _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.
> _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.
> _kerberos._tcp.Default-First-Site-
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
(https://www.redhat.com/archives/freeipa-users/2014-April/msg00039.html), but
the solution is not. In that case, it was solved by enabling IPv6 in the
kernel, and in this cas
39 matches
Mail list logo