[Freeipa-users] Re: Setting up HBAC for external users

[Jakub Hrozek via FreeIPA-users]

> On 19 May 2018, at 19:53, Marc Boorshtein via FreeIPA-users 
>  wrote:
> 
> I'm trying to setup an HBAC rule for allowing users from a trust to
> access linux servers in a FreeIPA domain.  My setup:
> 
> 1.  rhelent.lan - FreeIPA 4.5.0-22
> 2.  ent2k12.domain.com - AD on windows 2012r2
> 3.  boz1 - centos7, member of rhelent.lan
> 4.  External group ad_ext_users
> 5.  POSIX group called hbac_access
> 6.. HBAC group that has the posix group hbac_access as a member
> 7.  IPA user dvader is a member of hbac_access posix group
> 8.  mmos...@ent2k12.domain.com is a member of ad_ext_users external group
> 
> When I login as dvader, everything works great.  When I login as
> mmos...@ent2k12.domain.com the connection is closed.  This is in
> /var/log/seccure:
> 
> May 19 13:43:11 box1 sshd[1398]: pam_sss(sshd:auth): authentication
> success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.8.0.2
> user=mmos...@ent2k12.domain.com
> May 19 13:43:11 box1 sshd[1398]: pam_sss(sshd:account): Access denied
> for user mmos...@ent2k12.domain.com: 6 (Permission denied)
> May 19 13:43:11 box1 sshd[1395]: error: PAM: User account has expired
> for mmos...@ent2k12.domain.com from 10.8.0.2
> May 19 13:43:12 box1 sshd[1395]: fatal: monitor_read: unpermitted request 104
> 
> So authentication is working, authorization is failing.  Am I missing 
> something?

Not from the description; the things I would look at are 1) is hbac_access 
printed if you run “id mmos...@ent2k12.domain.com” ? 2) bump the sssd debug 
level and see the groups and the rules the client is evaluating in the sssd 
logs.

> 
> Thanks
> Marc
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/NJV4OM4DAMWEB6OVYHJUGS5ZVCKIX35P/
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/L3EFYCS5RERLUMET2I5KKLYYD5QFNN6A/

[Freeipa-users] Re: Logon by ssh but not console?

[Jakub Hrozek via FreeIPA-users]

> On 3 Jun 2018, at 13:33, Bret Wortman via FreeIPA-users 
>  wrote:
> 
> I just realized that I never closed the loop on this problem and just 
> finished upgrading all my systems to use our new IPA servers. And this 
> problem is still with me.
> 
> I can log onto some workstations but not all. My only enabled hbac rule is 
> still "allow_all", and it's as permissive as it gets.
> 
> Is there anything else I can check? I'm trying to get this working before my 
> users arrive on Monday and carry off my head on a pikestaff…

Are you sure the issue is HBAC, then? Normally I first check either 
/var/log/secure or journald, search for pam_sss to see what kind of error sssd 
returned (if any..) and then work my way through the sssd logs, the 
sssd_pam.log/sssd_nss.log first and then the sssd_domain.log..

> 
> 
> Bret
> 
> 
> On 02/22/2018 09:30 AM, Bret Wortman wrote:
>> Back to this thread; I stood up a new VM and used ipa-client-install to 
>> subscribe it to the new server. I can log on to it from both ssh and 
>> console, so the problem on my original workstation appears to be in 
>> switching from one server to another.
>> 
>> Thoughts?
>> 
>> 
>> On 02/21/2018 10:29 AM, Bret Wortman wrote:
>>> My only hbac rule is "allow_all", and it's enabled. I hadn't gotten around 
>>> to setting up any additional ones yet.
>>> 
>>> 
>>> On 02/21/2018 10:14 AM, Rob Crittenden wrote:
 Bret Wortman via FreeIPA-users wrote:
> Any ideas why I might be prevented from logging in on a system through
> GDM and the console, but if I log in as root and:
> 
> # ssh bretw@localhost
> 
> I'm able to log in without issues? And it'll tell me about failed logins
> for every time I try through GDM or the console.
> 
> This is on a brand new IPA server I'm setting up using data from our
> older ones but it's not set up as a replica.
 Check HBAC rules. Logging into console is a different pam service than ssh.
 
 rob
>>> 
>> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/SJBUVQTSKRNFLMKFUNFY7UUYE52OGVOB/
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/7F7WJA3F5B3NXHTKUXCDFTJPGE442QEM/

[Freeipa-users] Re: Cannot log in as an AD user to FreeIPA client but can log in to server

[Jakub Hrozek via FreeIPA-users]

On Tue, Jun 05, 2018 at 03:06:44PM -, Bart via FreeIPA-users wrote:
> Hi all,
> 
> I've set up two FreeIPA servers without CA (I provided 3rd party certificates 
> during the installation process). I also established trust to an AD domain as 
> below:
> 
> ipa trust-add --type=ad AD.DOMAIN --external=True --all
> 
> I checked that I can successfully obtain cross-realm ticket (kvno -S host 
> ...) as described below:
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/trust-during#create-a-trust
> I also can ssh to either of the two FreeIPA servers as user@ad.domain.
> 
> However, when I configured FreeIPA client and tried to ssh into it / su 
> inside it as the same ad user then it fails (I cannot ssh, when I try to su - 
> as the ad user it fails with user@ad.domain does not exist.
> 
> I increased sssd log level on both client and servers but I cannot find 
> anything spooky there (but I might as well not know what to look for :)).
> Can someone please advise on how to narrow this down?

First, can you resolve the user and all their groups on the client?

If yes, then I normally start with /var/log/secure or journal to see
what did pam_sss return and work my way from there to the sssd logs..
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/6WM3S76KVRBQJ7UM6AJZD2DDGSCBMF7R/

[Freeipa-users] Re: Cannot log in as an AD user to FreeIPA client but can log in to server

[Jakub Hrozek via FreeIPA-users]

On Wed, Jun 06, 2018 at 02:30:56PM -, Bart via FreeIPA-users wrote:
> Hi Jakub, thank you for help.
> 
> I cannot resolve all of the users nor their groups on a client hosts. getent 
> passwd doesn't return anything, su - user@ad.domain doesn't work either.
> 
> All AD users I tried get resolved on the FreeIPA servers. For the one account 
> it gets resolved on one client host but on another client host it fails. 

It's hard to say without the complete logs, but very often this reason
is that one or more of the user's groups can't be resolved on the
client.

If you do id $username on the client and then try their group on the
server, do at least some of them resolve (getent group $groupname)

Alternatively, you can look at the sssd_nss.log on the server and check
for getgrgid lookups and see if some of them fail.

> 
> Oddly, I can see in server's /var/log/sssd/ad_domain.log that upon issuing su 
> - user@ad.domain on a client host group membership is being resolved. User is 
> not resolved on the client host though. 
> 
> The only suspicious thing I can find in the logfiles is this entry but I do 
> not know if it is the culprit or not:
> 
> (Wed Jun  6 16:11:39 2018) [sssd[be[ipa.domain]]] [sysdb_error_to_errno] 
> (0x0020): LDB returned unexpected error: [No such attribute]
> (Wed Jun  6 16:11:39 2018) [sssd[be[ipa.domain]]] [sysdb_mod_group_member] 
> (0x0400): Error: 14 (Bad address)
> (Wed Jun  6 16:11:39 2018) [sssd[be[ipa.domain]]] [sysdb_update_members_ex] 
> (0x0020): Could not remove member [user@ad.domain] from group 
> [name=some_group@ad.domain,cn=groups,cn=ad.domain,cn=sysdb]. Skipping

Since the message says skipping, I'm quite certain that it's not the
problem.

> (Wed Jun  6 16:11:39 2018) [sssd[be[ipa.domain]]] [sss_domain_get_state] 
> (0x1000): Domain ipa.domain is Active
> (Wed Jun  6 16:11:39 2018) [sssd[be[ipa.domain]]] [sss_domain_get_state] 
> (0x1000): Domain ad.domain is Active
> (Wed Jun  6 16:11:39 2018) [sssd[be[ipa.domain]]] [ldb] (0x4000): start ldb 
> transaction (nesting: 1)
> (Wed Jun  6 16:11:39 2018) [sssd[be[ipa.domain]]] [ldb] (0x4000): Added timed 
> event "ltdb_callback": 0x55bdb
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/XM245EV3SEIUYDKNFNJNHDN6V2E6ST77/
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/PIBGTOUWOADVB5K6O6Z57LLI5BIVI2VN/

[Freeipa-users] Re: double domain?

[Jakub Hrozek via FreeIPA-users]

On Thu, Jun 07, 2018 at 12:33:56PM -0500, Kat via FreeIPA-users wrote:
> hi
> 
> Where would be a good place to look in either sssd or somewhere in the
> system if we are seeing a mixture of UserID lookups in this format:
> 
> usern...@domain.example.com  <--- this makes sense
> 
> BUT - also seeing:
> 
> usern...@domain.example.com@domain.eexample.com  <--- This does not??

Where do you see these? In some logs?

> 
> I am very confused as to how this might be getting sent to PAM for the
> lookups and because of it we see random PAM "System Error"s
> 
> I do have in krb5.conf
> 
> [domain_realm]
>   .domain.example.com = DOMAIN.EXAMPLE.COM
>   domain.example.com = DOMAIN.EXAMPLE.COM
>   prodhost1.domain.example.com = DOMAIN.EXAMPLE.COM
> 
> But this seems to have been set after the ipa-client-install - so I am a
> little confused?
> 
> Any suggestions?
> Kat
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/FZJTATOSN3CXH7WRYEIYVAJVZKEBV35P/
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/DUFVCZEFYNDHP722GUFNA2EA34MVMK4H/

[Freeipa-users] Re: Cannot log in as an AD user to FreeIPA client but can log in to server

[Jakub Hrozek via FreeIPA-users]

On Thu, Jun 07, 2018 at 03:48:16PM -, Bart via FreeIPA-users wrote:
> Thank you Alexander, that was the root cause. I added optimizations to my 
> setup that you together with Jakub described in this article: 
> https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/
>  and things started working on the client side.

This still points to a performance-like issue. From some related
customer cases I've been working on lately I remember that increasing
the negative timeout (entry_negative_timeout, set this to minutes or
even hours) and also the cache_first=true options made a difference.

There's a tradeoff though with these options, please see the man pages.

> 
> There is a one small glitch though. Upon a first getent passwd for a new user 
> (one that I didn't issue getent before) executed on a client it most likely 
> still times out. I can see that there is some communication on FreeIPA 
> servers going on (judging by the log file /var/log/sssd/sssd_ipa.domain.log). 
> getent command times out but entries in the log file keep on being added. 
> When the log entries stop from being added anymore and I issue the same 
> getent command then it succeeds.
> 
> Could you please point me to the timeout parameter that would allow to fix 
> this, if there is any? 
> For a reference I paste my client/server sssd configs:
> 
> server: 
> 
> [domain/ipa.domain]
> debug_level = 9
> id_provider = ipa
> ipa_server_mode = True
> ipa_server = ipa-server.ipa.domain
> ipa_domain = ipa.domain
> ipa_hostname = ipa-server.ipa.domain
> auth_provider = ipa
> chpass_provider = ipa
> access_provider = ipa
> cache_credentials = True
> ldap_tls_cacert = /etc/ipa/ca.crt
> krb5_store_password_if_offline = True
> 
> enumerate = False
> subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout
> ignore_group_members = True
> ldap_purge_cache_timeout = 0
> 
> [sssd]
> services = nss, pam, ifp, ssh, sudo
> ignore_group_members=True
> 
> domains = ipa.domain
> enumerate = False
> ldap_use_tokengroups = false

Please don't disable tokengroups unless you have a verified reason to do
so (this is just a general warning, I'm not even sure if disabling
tokengroups in the main domain section would disable them for the AD
subdomain).

> [nss]
> homedir_substring = /home
> memcache_timeout = 600
> 
> [pam]
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> [pac]
> 
> [ifp]
> 
> [secrets]
> 
> [session_recording]
> 
> 
> client:
> 
> [domain/ipa.domain]
> enumerate = False
> debug_level=9
> cache_credentials = True
> krb5_store_password_if_offline = True
> 
> ipa_domain = ipa.domain
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = ipa-client-centos6.shec.hrs.cc
> chpass_provider = ipa
> ipa_server = ipa-server.ipa.domain
> ldap_tls_cacert = /etc/ipa/ca.crt
> krb5_auth_timeout = 3600
> [sssd]
> services = nss, sudo, pam, ssh
> 
> domains = ipa.domain
> [nss]
> homedir_substring = /home
> 
> [pam]
> pam_id_timeout = 3600
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> [pac]
> 
> [ifp]
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/LJGAGZ4FAAKIFJD723NBFCKZNBADEBL4/
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/VDWTJCFA3SMAWERJQPRLF62ONGPB5XAC/

[Freeipa-users] Announcing SSSD 1.16.2

[Jakub Hrozek via FreeIPA-users]

SSSD 1.16.2
===

The SSSD team is proud to announce the release of version 1.16.2 of the
System Security Services Daemon.

The tarball can be downloaded from https://releases.pagure.org/SSSD/sssd/

RPM packages will be made available for Fedora shortly.

Feedback

Please provide comments, bugs and other feedback via the sssd-devel or
sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Highlights
--

New Features

 * The smart card authentication, or in more general certificate authentication
   code now supports OpenSSL in addition to previously supported NSS (#3489).
   In addition, the SSH responder can now return public SSH keys derived from
   the public keys stored in a X.509 certificate. Please refer to the
   ``ssh_use_certificate_keys`` option in the man pages.
 * The files provider now supports mirroring multiple passwd or group
   files. This enhancement can be used to use the SSSD files provider instead
   of the nss_altfiles module

Notable bug fixes
^
 * A memory handling issue in the ``nss_ex`` interface was fixed. This bug
   would manifest in IPA environments with a trusted AD domain as a crash of
   the ns-slapd process, because a ``ns-slapd`` plugin loads the ``nss_ex``
   interface (#3715)
 * Several fixes for the KCM deamon were merged (see #3687, #3671, #3633)
 * The ``ad_site`` override is now honored in GPO code as well (#3646)
 * Several potential crashes in the NSS responder's netgroup code were fixed
   (#3679, #3731)
 * A potential crash in the autofs responder's code was fixed (#3752)
 * The LDAP provider now supports group renaming (#2653)
 * The GPO access control code no longer returns an error if one of the
   relevant GPO rules contained no SIDs at all (#3680)
 * A memory leak in the IPA provider related to resolving external AD
   groups was fixed (#3719)
 * Setups that used multiple domains where one of the domains had its ID
   space limited using the ``min_id/max_id`` options did not resolve requests
   by ID properly (#3728)
 * Overriding IDs or names did not work correctly when the domain resolution
   order was set as well (#3595)
 * A version mismatch between certain newer Samba versions (e.g. those shipped
   in RHEL-7.5) and the Winbind interface provided by SSSD was fixed. To further
   prevent issues like this in the future, the correct interface is now detected
   at build time (#3741)
 * The files provider no longer returns a qualified name in case domain
   resolution order is used (#3743)
 * A race condition between evaluating IPA group memberships and AD group
   memberships in setups with IPA-AD trusts that would have manifested as
   randomly losing IPA group memberships assigned to an AD user was fixed
   (#3744)
 * Setting an SELinux login label was broken in setups where the domain
   resolution order was used (#3740)
 * SSSD start up issue on systems that use the libldb library with version
   1.4.0 or newer was fixed.

Packaging Changes
-
 * Several new build requirements were added in order to support the OpenSSL
   certificate authentication

Documentation Changes
-
 * The files provider gained two new configuration options ``passwd_files``
   and ``group_files.`` These can be used to specify the additional files
   to mirror.
 * A new ``ssh_use_certificate_keys`` option toggles whether the SSH responder
   would return public SSH keys derived from X.509 certificates.
 * The ``local_negative_timeout`` option is now enabled by default. This
   means that if SSSD fails to find a user in the configured domains,
   but is then able to find the user with an NSS call such as getpwnam,
   it would negatively cache the request for the duration of the
   local_negative_timeout option.


Tickets Fixed
-
 * `3752 `_ - 
/usr/libexec/sssd/sssd_autofs SIGABRT crash daily due to a double free
 * `3749 `_ - [RFE] sssd.conf should 
mention the FILES provider as valid config value for the 'id_provider'
 * `3748 `_ - home dir disappear in 
sssd cache on the IPA master for AD users
 * `3744 `_ - Race condition between 
concurrent initgroups requests can cause one of them to return incomplete 
information
 * `3743 `_ - Weirdness when using 
files provider and domain resolution order  

 
 * `3742 `_ - Change of: User may not 
run sudo --> a password is required 
  
 * `3741 

[Freeipa-users] Re: performance tuning IPA 4.5 and SSD for large AD integration

[Jakub Hrozek via FreeIPA-users]

> On 29 Jun 2018, at 16:12, Chris Dagdigian via FreeIPA-users 
>  wrote:
> 
> At long last I've got a brand new IPA cluster running in our AWS footprint 
> with a modern v4.5.4 install and a proper AD Trust in place to a complex 
> domain forest
> 
> In my older cluster I made use of a lot of the info here that Alexander and 
> Jakob had written up:
> 
> https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/
> 
> Just wanted to check and see if the advice in that post still holds true for 
> ipa-server-4.5.4-10 etc.  -- is there anything I should avoid or anything new 
> (links, blog posts, URLs) that I should read up on to tune v4.5.4?

I’ve been planning to update the post for some time but haven’t found the time 
so far. tl;dr it might be a good idea to:

1) increase the negative cache timeout for SSSD on the IPA masters to avoid 
repeated lookups in mutliple domains. Currently we don’t optimize lookups well 
enough in cases where we could infer the right domain from some properties of 
the input, e.g. given an ID we could figure out which domain this ID belongs to 
based on the ID ranges and only ask that domain. Increasing the negative 
timeout sort of works around this, because if some input ID (or name, or SID, 
..) is not found in that domain, it is negatively cached and the negative reply 
is quite fast.

2) Make use of the cache_first=true option of SSSD on the IPA masters. Again, 
this avoids asking the wrong domains, because if some entry is cached, its 
domain is queried first and all other preceding domains might be skipped.

Both options obviously are a trade-off, but I’ve seen some users and customers 
be quite a bit happier about performance after employing them.

HTH
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/LFTCD7WAG4R637VAWDTUJSCMYBZQOSFP/

[Freeipa-users] Re: Can see AD Users on the FreeIPA Server itself, but not on connected client

[Jakub Hrozek via FreeIPA-users]

On Tue, Jul 10, 2018 at 02:25:53PM -, tolotos--- via FreeIPA-users wrote:
> Hi,
> 
> we have a setup with a Forest Trust to an AD Domain.
> 
> Everything looks good on the FreeIPA Servers itself. We can see User 
> information if we do "getent passwd user@ad.domain" or "id user@ad.domain" or 
> "sssctl user-checks user@ad.domain".
> 
> But on a connected client, we get only the user of the ipa domain and no user 
> information on ad user.
> 
> In the logs, we found no obvious error.
> The only thing we see in sssd.log is:
> (Tue Jul 10 16:19:27 2018) [sssd[be[ipa.domain]]] 
> [delayed_online_authentication_callback] (0x0200): Backend is online, 
> starting delayed online authentication.
> (Tue Jul 10 16:19:28 2018) [sssd[be[ipa.domain]]] 
> [dp_get_account_info_handler] (0x0200): Got request for 
> [0x1][BE_REQ_USER][name=user@ad.domain]
> (Tue Jul 10 16:19:28 2018) [sssd[be[ipa.domain]]] [ipa_s2n_exop_done] 
> (0x0040): ldap_extended_operation result: No such object(32), (null).
> (Tue Jul 10 16:19:28 2018) [sssd[be[ipa.domain]]] [ipa_s2n_get_user_done] 
> (0x0040): s2n exop request failed.

Are all the groups the user is a member of resolvable by ID? (getent
group $GID) ?

A good way to debug this kind of issues is to enable debugging in the
[nss] section in sssd.conf on the IPA server and check if any of the
requests goes unanswered.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/5IZZCHS6DREIWR4ODRTMJHFSCQBWAWKU/

[Freeipa-users] Re: Client authentication against trusted AD broken

[Jakub Hrozek via FreeIPA-users]

On Wed, Jul 11, 2018 at 03:56:22PM -, Mike Conner via FreeIPA-users wrote:
> This is now working after adding a stanza for the AD realm in /etc/krb5.conf 
> file.  Should that be necessary?

Did you also add the KDCs for the AD realm?

I'm asking because by default, sssd on the client does not know which
KDCs to authenticate against and just calls into libkrb5 which discovers
the AD KDCs with DNS SRV calls. So maybe you added some DCs which are
known to be reachable which avoids SSSD going offline because the
authenticated otherwise times out?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/L3X2EUTV7FOSBGJ4GPNYH657XTDVAVMV/

[Freeipa-users] Re: Client authentication against trusted AD broken

[Jakub Hrozek via FreeIPA-users]

On Wed, Jul 11, 2018 at 08:30:16PM -, Mike Conner via FreeIPA-users wrote:
> So you're saying the client is probably not finding the AD KDC through DNS 
> SRV calls? 

Not necessarily not finding, but perhaps the AD KDCs the client
discovers are slow to respond?

What exactly were the changes to krb5.conf that helped you?

btw previously in the log snippet you sent, the AD domain was already
marked as Inactive, so I was mostly guessing as per what caused the AD
domain to flip to the Inactive state in the first place -- although on
the client, an authentication timeout is the most likely issue.

> I think that I've tested all the DNS configs that are called for in the 
> documentation. What could I do to test whether the AD realm's KDC is being 
> discovered?
> 
> Here's what I've tried to see if the dns is correctly configured:
> [root@freeipaclient ~]# dig +short -t SRV 
> _kerberos._tcp.dc._msdcs.cs.domain.dom
> 0 100 88 ipa.cs.domain.dom.
> [root@freeipaclient ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.domain.dom
> 0 100 88 kdc1.domain.dom.
> 0 100 88 kdc2.domain.dom.
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/AW2TLNXLWYGEESKU22FSBOM3Q6BP3U47/
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/SQ72NB5525CWEHAY5HQMKXXASPYGSAL7/

[Freeipa-users] Re: Only some AD users returned from lookups

[Jakub Hrozek via FreeIPA-users]

On Wed, Jul 11, 2018 at 08:36:43PM -, Mike Conner via FreeIPA-users wrote:
> I have an issue where i've established the AD trust and am able to lookup
> my own account and about 30 others, but all others fail.  I've compared
> AD attributes across accounts and can't find anything that is notably
> different. I've seen messages about making sure that groups can resolve,
> but I don't think that's what's happening. I have a user account that only
> has one group membership and that group resolves, but the account still
> is not returned on a lookup.  The only common thread I can find with the
> accounts that succeed is that they are older accounts - they were created
> a long time ago - more recently created accounts fail.  Where can I look
> to see what might be happening?

Are the users resolvable on the IPA server at least or do the lookups
fail on both the server an the client?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/CHWMI7ZCMZ2BY2U3M44OYPC26UOVKSCW/

[Freeipa-users] Re: Only some AD users returned from lookups

[Jakub Hrozek via FreeIPA-users]

On Wed, Jul 11, 2018 at 09:07:41PM -, Mike Conner via FreeIPA-users wrote:
> No, the lookups fail on both the server and the client.

Can you post logs of a failing lookup on the server? You would add
debug_level to the [nss] and [domain] section in sssd.conf and run the
lookup..
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/UO52RQMEHKR3R4CZM6QP7NXLZFHV6BRH/

[Freeipa-users] Re: Client authentication against trusted AD broken

[Jakub Hrozek via FreeIPA-users]

On Wed, Jul 11, 2018 at 09:16:19PM -, Mike Conner via FreeIPA-users wrote:
> To the /etc/krb5.conf file on the client, I changed from this:
> 
> [realms]
>   CS.GRINNELL.EDU = {
> kdc = ipa.cs.grinnell.edu:88
> master_kdc = ipa.cs.grinnell.edu:88
> admin_server = ipa.cs.grinnell.edu:749
> kpasswd_server = ipa.cs.grinnell.edu:464
> default_domain = cs.grinnell.edu
> pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
> pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
> 
>   }
> 
> 
> To this:
> [realms]
>   CS.DOMAIN.DOM = {
> kdc = ipa.cs.domain.dom:88
> master_kdc = ipa.cs.domain.dom:88
> admin_server = ipa.cs.domain.dom:749
> kpasswd_server = ipa.cs.domain.dom:464
> default_domain = cs.domain.dom
> pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
> pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
> 
>   }
>   DOMAIN.DOM = {
>kdc = kdc1.domain.dom
>admin_server = kdc1.domain.dom
>   }

OK and just to confirm the theory, does running kinit for a user from
DOMAIN.COM finish faster than when the DOMAIN.COM entry is commented
out?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/J4MDAEMRPFUTVAAYOPFUPAKGAVMFEZ3G/

[Freeipa-users] Re: Only some AD users returned from lookups

[Jakub Hrozek via FreeIPA-users]

On Wed, Jul 11, 2018 at 09:42:14PM -, Mike Conner via FreeIPA-users wrote:
> sssd_nss.log during attempted lookup of slyme...@grinnell.edu account:
> https://pastebin.com/gLFnhZ9s

This is somewhat helpful, at least this snippet:
(Wed Jul 11 16:33:22 2018) [sssd[nss]] [cache_req_search_cache]
(0x0400): CR #230: Object [slyme...@grinnell.edu] was not found in cache
(Wed Jul 11 16:33:22 2018) [sssd[nss]]
[cache_req_search_ncache_add_to_domain] (0x0400): CR #230: Adding
[slyme...@grinnell.edu] to negative cache
(Wed Jul 11 16:33

Shows the user was not found. The next step are the domain logs.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/34OZGC4AVNSXVSCHBBHELHEZ32TS2YWN/

[Freeipa-users] Re: authentication when first master is down

[Jakub Hrozek via FreeIPA-users]

On Thu, Jul 12, 2018 at 10:21:24AM +0300, Petros Triantafyllidis via 
FreeIPA-users wrote:
> Hi all,
>   I have a small setup with two masters and several clients at one location.
> I have noticed that when the first master goes down for maintenance or
> failure, the other server is unable to authenticate users. Is there a
> setting that needs to be made in order to achieve this as long as the first
> master is off? Shouldn't this be taken care of automatically?

That depends on how the clients are configured. You'll want 
"ipa_server" option is set to "_srv_, $ipaserver", then sssd on the
client would expand the _srv_ keyword with hostnames resolved using the
DNS SRV query and should fail over between them.

If that doesn't happen, the logs should be inspected..
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/FO3HWS22HQJRLLEFOBDF6A77MRGEGLPT/

[Freeipa-users] Re: Can see AD Users on the FreeIPA Server itself, but not on connected client

[Jakub Hrozek via FreeIPA-users]

On Thu, Jul 12, 2018 at 10:54:55AM +0300, Alexander Bokovoy via FreeIPA-users 
wrote:
> On to, 12 heinä 2018, tolotos--- via FreeIPA-users wrote:
> > Hi,
> > 
> > we have done some additional testing and debugging.
> > 
> > It seems there some problems with the extdom-extop plugin in the directory 
> > server.
> > 
> > If we set ignore_group_members, the first request get a good response.
> > (tested by: server: sssctl cache-remove -p -s -o ; sleep 1; stop-dirsrv ; 
> > sleep 1; start-dirsrv / client: sssctl cache-remove -p -s -o ; sleep 1; 
> > sssctl user-checks user@ad.domain)
> > 
> > However, starting with the second requests the extdom-extop returns every 
> > request with an err=32 Object Not Found.
> > 
> > We already tried to increase ipaextdommaxnssbufsize and 
> > ipaextdommaxnsstimeout.
> > (we increased error log level on dirsrv to be sure that the values are 
> > used: Maximal nss buffer size set to [268435456]! / Maximal nss timeout (in 
> > ms) set to [10]!)
> > 
> > Someone some ideas where to look from here?
> Setting ignore_group_members on IPA masters does not really allow extdom
> plugin to work well.

Are you sure? I've seen quite a few users enabling this switch..

(Maybe you meant the compat tree which also publishes the group
members?)

> 
> However, did you try to increase timeouts in sssd on IPA master? Extdom
> plugin calls out to SSSD on IPA master when any request comes to it via
> LDAP extended operation. So the plugin itself doesn't really do
> anything, sssd on IPA master does all the heavy lifting. Extdom plugin
> only translates an anwer given by SSSD.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/Q5BO5IFAFG4NXMX62ZIM3N7KFXIO23SE/

[Freeipa-users] Re: Can see AD Users on the FreeIPA Server itself, but not on connected client

[Jakub Hrozek via FreeIPA-users]

On Thu, Jul 12, 2018 at 08:49:37AM -, tolotos--- via FreeIPA-users wrote:
> Hi,
> 
> no we don't have special timeout settings in sssd.conf. Wich parameters you 
> would recommend to set?
> 
> Due to the assumption that all seem to work at the moment when all 
> caches/buffers are empty, we experiment with modifying the cache files in 
> /var/lib/sss/db/cache*.ldb with the ldb-tools. And if we remove all entries 
> in this cache file (ldbdel) the next requests work again.

This is really strange, are you nuking the cache on the client or the
server?

Can you paste some logs?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/FHPUZR6XHJ6OTXB6KOSWO6KRL6ELHCL6/

[Freeipa-users] Re: Can see AD Users on the FreeIPA Server itself, but not on connected client

[Jakub Hrozek via FreeIPA-users]

On Thu, Jul 12, 2018 at 09:50:14AM -, tolotos--- via FreeIPA-users wrote:
> Hi,
> 
> the *.ldb files are manipulated on the server. On the client, we have removed 
> the cache via sssctl.
> 
> What logs exactly, besides the logs i already posted?

SSSD NSS and domain logs of the failing lookup while the cache is in the
'bad' state.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/Z6O6JYORCWVUDBFL2TUDOLWLKYU26UUG/

[Freeipa-users] Re: AD and IPA integration

[Jakub Hrozek via FreeIPA-users]

On Thu, Jul 19, 2018 at 11:13:38PM +0700, Николай Савельев via FreeIPA-users 
wrote:
> I changed password AD users.
> I can't login on ipa servers with new password, but can - with old. Why?
> I tried restart ipa services and reinitializing trust. but it didn't help.

Are you sure sssd is not logging you offline?

sssctl domain-status can tell you the status of the domains..
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/FQY2EY6I52IIKKDYDHDSG4R2I33N5UDE/

[Freeipa-users] Re: IPA users and local groups question

[Jakub Hrozek via FreeIPA-users]

On Fri, Jul 20, 2018 at 09:55:37AM -, David McDaniel via FreeIPA-users 
wrote:
> > I’m afraid the answer is ‘possible in general, but not with the versions 
> > you are running’,
> > see https://sourceware.org/glibc/wiki/Proposals/GroupMerging and
> > https://sgallagh.wordpress.com/2016/01/28/remote-group-merging-for-fedora/
> 
> Jakub
> Our use case for group merge functionality is very much as Jeff describeds 
> above. Have been digging around looking for definitive requirements and 
> proper configuration.
> What are the required freeipa/sssd, RHEL and glibc versions for group merging 
> functionality? Our IdM servers are RHEL 7.4, freeipa 4.5, sssd 1.16 and 
> client's are mix of RHEL 6.9, 7.2 and 7.4. Thank you

glibc should support this since 7.4:
https://bugzilla.redhat.com/show_bug.cgi?id=1298975
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/INVKAD4MMCJY6YTT5OLNBDKC67IBIK43/

[Freeipa-users] Re: External AD Trust: Cannot get users/groups from AD

[Jakub Hrozek via FreeIPA-users]

> On 20 Jul 2018, at 17:51, Rene Trippen via FreeIPA-users 
>  wrote:
> 
> Hi there,
> 
> I´ve got a external trust established between the ipa server and a AD
> domain (child of parent)
> 
> ipa trust-add --type=ad subdomain.main.corp.com  --external=true
> Active Directory domain administrator: ipatrust0
> Active Directory domain administrator's password:
> -
> Added Active Directory trust for realm "subdomain.main.corp.com"
> -
>  Realm name: subdomain.main.corp.com
>  Domain NetBIOS name: SUBDOMAIN
>  Domain Security Identifier: S-1-5-21-653292258-51847207-622671684
>  Trust direction: Trusting forest
>  Trust type: Non-transitive external trust to a domain in another
> Active Directory forest
>  Trust status: Established and verified
> 
> But, when I try to get users or groups from the AD, nothing is returned
> 
> getent passwd us...@subdomain.main.corp.com  -> nothing
> 
> wbinfo -n "SUBDOMAIN\user1"
> failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND
> Could not lookup name SUBDOMAIN\user1
> 
> wbinfo -m
> BUILTIN
> IPA
> SUBDOMAIN
> 
> ipa dns-update-system-records --dry-run
> IIPA DNS records:
>  _kerberos-master._tcp.ipa.main.corp.com. 86400 IN SRV 0 100 88
> ipa1.ipa.main.corp.com.
>  _kerberos-master._udp.ipa.main.corp.com. 86400 IN SRV 0 100 88
> ipa1.ipa.main.corp.com.
>  _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.ipa.main.corp.com.
> 86400 IN SRV 0 100 88 ipa1.ipa.main.corp.com.
>  _kerberos._tcp.dc._msdcs.ipa.main.corp.com. 86400 IN SRV 0 100 88
> ipa1.ipa.main.corp.com.
>  _kerberos._tcp.ipa.main.corp.com. 86400 IN SRV 0 100 88
> ipa1.ipa.main.corp.com.
>  _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.ipa.main.corp.com.
> 86400 IN SRV 0 100 88 ipa1.ipa.main.corp.com.
>  _kerberos._udp.dc._msdcs.ipa.main.corp.com. 86400 IN SRV 0 100 88
> ipa1.ipa.main.corp.com.
>  _kerberos._udp.ipa.main.corp.com. 86400 IN SRV 0 100 88
> ipa1.ipa.main.corp.com.
>  _kerberos.ipa.main.corp.com. 86400 IN TXT "IPA.MAIN.CORP.COM"
>  _kpasswd._tcp.ipa.main.corp.com. 86400 IN SRV 0 100 464
> ipa1.ipa.main.corp.com.
>  _kpasswd._udp.ipa.main.corp.com. 86400 IN SRV 0 100 464
> ipa1.ipa.main.corp.com.
>  _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ipa.main.corp.com.
> 86400 IN SRV 0 100 389 ipa1.ipa.main.corp.com.
>  _ldap._tcp.dc._msdcs.ipa.main.corp.com. 86400 IN SRV 0 100 389
> ipa1.ipa.main.corp.com.
>  _ldap._tcp.ipa.main.corp.com. 86400 IN SRV 0 100 389 ipa1.ipa.main.corp.com.
>  _ntp._udp.ipa.main.corp.com. 86400 IN SRV 0 100 123 ipa1.ipa.main.corp.com.
>  ipa-ca.ipa.main.corp.com. 86400 IN A 10.1.17.123
> 
> The IPA server and the AD machines are in the same net, without
> firewall segemenatation
> The ADs are 2008R2
> The IPA Server is a CentOS (latest), got following ipa version installed:
> 
> ipa-common-4.5.4-10.el7.centos.3.noarch
> ipa-server-trust-ad-4.5.4-10.el7.centos.3.x86_64
> ipa-client-4.5.4-10.el7.centos.3.x86_64
> ipa-server-dns-4.5.4-10.el7.centos.3.noarch
> ipa-server-common-4.5.4-10.el7.centos.3.noarch
> ipa-client-common-4.5.4-10.el7.centos.3.noarch
> ipa-server-4.5.4-10.el7.centos.3.x86_64
> 
> I can provide you tons of logs, but I don´t know where to start.

Logs from sssd on the ipa master are usually a good point to start, see 
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html

> 
> Best regards,
> Rene
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/QF4JKRPVXMK6CW2KYFWNRFM7JDTBRDJ2/
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/MKPAK6KVHCJIV5TBUJ2TM3HKUPP2DOSP/

[Freeipa-users] Re: AD and IPA integration

[Jakub Hrozek via FreeIPA-users]

There are two errors I see in the logs. First, the ldap_child.log ends with:
(Sun Jul 22 16:07:37 2018) [[sssd[ldap_child[9680 [sss_child_krb5_trace_cb] 
(0x4000): [9680] 1532250457.238992: Initiating TCP connection to stream 
192.168.2.10:88

and nothing after that so I wonder if the child was subsequently killed due to 
a timeout after it tried to authenticate to the DC. But we don’t have the full 
logs so I’m just guessing.

The other issue I see is in krb5_child.log, first there is this:
(Sun Jul 22 15:54:36 2018) [[sssd[krb5_child[9331 [get_and_save_tgt] 
(0x0400): krb5_get_init_creds_password returned [-1765328174] during pre-auth.
but this is “just” preauth failed, then the authentication goes on about 6 
seconds later:
(Sun Jul 22 15:54:42 2018) [[sssd[krb5_child[9337 [unpack_buffer] (0x0100): 
cmd [241] uid [1837401456] gid [1837401456] validate [true] enterprise 
principal [false] offline [true] UPN [savelev@START-LINE.LOCAL]

but the interesting part here is “offline [true]” which indicates some 
connectivity issues. And btw the delay of 6 seconds matches the default 
timeouts.

It would be nice to see the complete logs, though.

> On 22 Jul 2018, at 11:48, Николай Савельев via FreeIPA-users 
>  wrote:
> 
> Here
> 
> 22.07.2018, 16:32, "Alexander Bokovoy" :
>> On su, 22 heinä 2018, Николай Савельев wrote:
>>> 22.07.2018, 14:16, "Alexander Bokovoy" :
>>> 
  Again, show sssd logs. I suspect it is something with communicating to
  your AD DCs because SSSD doesn't use anything else to authenticate.
>>> Here you are
>> 
>> So, SSSD is not able to communicate with AD DCs and puts the domain
>> offline. You can see in /var/log/sssd/krb5_child.log and ldap_child.log
>> for details on why thing fail.
>> 
> -- 
> С уважением, Николай.
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/XFHBZQS74ZSDWITJODWDPEU7XAZTYCAO/
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/RFLFCDHSPVDOZC3I37VKC3WIDPBTIAP5/

[Freeipa-users] Re: AD and IPA integration

[Jakub Hrozek via FreeIPA-users]

OK, maybe it’s this:
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_print_server] (0x2000): 
Searching 192.168.2.105:389
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_get_generic_ext_step] 
(0x0400): calling ldap_search_ext with 
[(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-1948593278-483253815-2868158363-1029))][cn=Default
 Trust View,cn=v
iews,cn=accounts,dc=fs,dc=lan].
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_get_generic_ext_step] 
(0x2000): ldap_search_ext called, msgid = 21
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_op_add] (0x2000): New 
operation 21 timeout 6
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_process_result] (0x2000): 
Trace: sh[0x56065d6cd580], connected[1], ops[0x56065d71df60], 
ldap[0x56065d6c4a10]
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_process_result] (0x2000): 
Trace: end of ldap_result list
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_process_result] (0x2000): 
Trace: sh[0x56065d6cd580], connected[1], ops[0x56065d71df60], 
ldap[0x56065d6c4a10]
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_process_message] (0x4000): 
Message type: [LDAP_RES_SEARCH_RESULT]
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_get_generic_op_finished] 
(0x0400): Search result: Success(0), no errmsg set
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_op_destructor] (0x2000): 
Operation 21 finished
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ipa_get_ad_override_done] 
(0x4000): No override found with filter 
[(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-1948593278-483253815-2868158363-1029))].
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_id_op_destroy] (0x4000): 
releasing operation connection
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ipa_initgr_get_overrides_step] 
(0x1000): Processing group 2/4
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ipa_initgr_get_overrides_step] 
(0x0040): The group name=domainus...@fs.lan,cn=groups,cn=fs.lan,cn=sysdb has no 
UUID attribute objectSIDString, error!

—> here

(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] 
[ipa_id_get_groups_overrides_done] (0x0040): IPA resolve user groups overrides 
failed [22].
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [be_mark_dom_offline] (0x1000): 
Marking subdomain start-line.local offline
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ldb] (0x4000): Added timed event 
"ltdb_callback": 0x56065d7255a0

(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ldb] (0x4000): Added timed event 
"ltdb_timeout": 0x56065d6f6dd0

(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ldb] (0x4000): Running timer 
event 0x56065d7255a0 "ltdb_callback"

(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ldb] (0x4000): Destroying timer 
event 0x56065d6f6dd0 "ltdb_timeout"

(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ldb] (0x4000): Ending timer 
event 0x56065d7255a0 "ltdb_callback"

(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [be_mark_subdom_offline] 
(0x1000): Marking subdomain start-line.local as inactive
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ipa_srv_ad_acct_lookup_done] 
(0x0040): ipa_get_*_acct request failed: [22]: Недопустимый аргумент.
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ipa_subdomain_account_done] 
(0x0040): ipa_get_*_acct request failed: [22]: Недопустимый аргумент.
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_id_op_destroy] (0x4000): 
releasing operation connection
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [dp_reply_std_set] (0x0080): DP 
Error is OK on failed request?
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [dp_req_done] (0x0400): DP 
Request [Initgroups #4]: Request handler finished [0]: Победа

So this group doesn’t have a SID (note that the objectSIDString is what SSSD 
saves into the database, not the actual LDAP attribute. On the IPA side, all 
groups a trusted object is a member of must have the attribute 
ipaNTSecurityIdentifier. Does the group domainusers have one? You can check 
with “ipa group-show —all —raw domainusers”.

btw when you established the trust, the ipa-adtrust-install command should have 
given you the option to generate SIDs for IPA objects.  I don’t know exactly 
how to generate the SIDs post-install, maybe one of the IPA developers would 
help me out. Looking at the —help output of ipa-adtrust-install there is an 
option —add-sids..

> On 24 Jul 2018, at 19:33, Николай Савельев via FreeIPA-users 
>  wrote:
> 
> Here logs after attempt autentication via ssh.
> 
> Also config files,
> 
> 
>> 23.07.2018, 14:49, "Jakub Hrozek" :
> 
> -- 
> С уважением, Николай.
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fed

[Freeipa-users] Re: External AD Trust: Cannot get users/groups from AD

[Jakub Hrozek via FreeIPA-users]

On Fri, Jul 27, 2018 at 12:53:33PM +0200, Rene Trippen wrote:
> > > I can provide you tons of logs, but I don´t know where to start.
> > 
> > Logs from sssd on the ipa master are usually a good point to start, see 
> > https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
> 
> Thank you, that helped me understanding some things better, but
> unfortunately, doesn´t help with my problem :/

Maybe if you post the debug logs someone will have an idea?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/TX526NZMW4BK7GCSBDBCPORAIG4AIP4T/

[Freeipa-users] Re: performance tuning IPA 4.5 and SSD for large AD integration

[Jakub Hrozek via FreeIPA-users]

> On 1 Aug 2018, at 06:08, Alexandre Pitre  wrote:
> 
> Hi Jakub,
> 
> I understand that cache_first=true is set in the [nss] section of 
> /etc/sssd/sssd.conf but what about the negative cache setting you are 
> referring to ? Could you please give an example ?
> 
> Looking at https://jhrozek.fedorapeople.org/sssd/1.16.2/man/sssd.conf.5.html 
> , there's a few settings referring to "negative cache”.

I meant entry_negative_timeout.

This is meant to work around https://pagure.io/SSSD/sssd/issue/3686 by making 
sure the extra lookups occur only once per negative cache timeout.

> 
> Thanks
> Alex
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/P37TUHMWYAMRTL4TFF2ZIOFKINZ2BM67/

[Freeipa-users] Re: sss_ssh_authorizedkeys returns empty list

[Jakub Hrozek via FreeIPA-users]

If you search the cache with ldbsearch -H /var/lib/sss/db/cache_domain.ldb does 
the user have the pubkey attribute?

> On 8 Aug 2018, at 11:02, Peter Viskup via FreeIPA-users 
>  wrote:
> 
> On Debian 9 client the sss_ssh_authorizedkeys command returns empty
> list. But the ipauser has SSH key in its IPA profile setup via web UI.
> Debug log does not point to any error:
> 
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [get_client_cred] (0x4000):
> Client creds: euid[65534] egid[65534] pid[11834].
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [get_client_cred] (0x0080): The
> following failure is expected to happen in case SELinux is disabled:
> SELINUX_getpeercon failed [92][Protocol not available].
> Please, consider enabling SELinux in your system.
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [setup_client_idle_timer]
> (0x4000): Idle timer re-set for client [0x56353b9b65a0][18]
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [accept_fd_handler] (0x0400):
> Client connected!
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_cmd_get_version] (0x0200):
> Received client version [0].
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_cmd_get_version] (0x0200):
> Offered version [0].
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [ssh_cmd_parse_request]
> (0x0400): Requested domain [DOMAIN]
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [ssh_cmd_parse_request]
> (0x0400): Parsing name [ipauser][DOMAIN]
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_parse_name_for_domains]
> (0x0200): name 'ipauser' matched without domain, user is ipauser
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_parse_name_for_domains]
> (0x0200): using default domain [DOMAIN]
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_ssh_cmd_get_user_pubkeys]
> (0x0400): Requesting SSH user public keys for [ipauser] from [DOMAIN]
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_dp_issue_request]
> (0x0400): Issuing request for [0x56353a7ea5f0:1:ipauser@DOMAIN@DOMAIN]
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_dp_get_account_msg]
> (0x0400): Creating request for
> [DOMAIN][0x1][BE_REQ_USER][name=ipauser@DOMAIN:-]
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sbus_add_timeout] (0x2000):
> 0x56353b9b8fc0
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_dp_internal_get_send]
> (0x0400): Entering request [0x56353a7ea5f0:1:ipauser@DOMAIN@DOMAIN]
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sbus_remove_timeout] (0x2000):
> 0x56353b9b8fc0
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sbus_dispatch] (0x4000): dbus
> conn: 0x56353b9af060
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sbus_dispatch] (0x4000): Dispatching.
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_dp_get_reply] (0x1000):
> Got reply from Data Provider - DP error code: 0 errno: 0 error
> message: Success
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [ssh_user_pubkeys_search_next]
> (0x0400): Requesting SSH user public keys for [ipauser@DOMAIN]
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [ldb] (0x4000): Added timed
> event "ltdb_callback": 0x56353b9bdcd0
> 
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [ldb] (0x4000): Added timed
> event "ltdb_timeout": 0x56353b9bdd90
> 
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [ldb] (0x4000): Running timer
> event 0x56353b9bdcd0 "ltdb_callback"
> 
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [ldb] (0x4000): Destroying
> timer event 0x56353b9bdd90 "ltdb_timeout"
> 
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [ldb] (0x4000): Ending timer
> event 0x56353b9bdcd0 "ltdb_callback"
> 
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [ldb] (0x4000): Added timed
> event "ltdb_callback": 0x56353b9b90e0
> 
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [ldb] (0x4000): Added timed
> event "ltdb_timeout": 0x56353b9b98e0
> 
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [ldb] (0x4000): Running timer
> event 0x56353b9b90e0 "ltdb_callback"
> 
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [ldb] (0x4000): Destroying
> timer event 0x56353b9b98e0 "ltdb_timeout"
> 
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [ldb] (0x4000): Ending timer
> event 0x56353b9b90e0 "ltdb_callback"
> 
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_dp_req_destructor]
> (0x0400): Deleting request: [0x56353a7ea5f0:1:ipauser@DOMAIN@DOMAIN]
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [client_recv] (0x0200): Client
> disconnected!
> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [client_close_fn] (0x2000):
> Terminated client [0x56353b9b65a0][18]
> 
> What could be the root cause?
> 
> -- 
> Peter
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/WGE63YYFIHYZNI3YJBCPC52F3WXZHT5Z/
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-use

[Freeipa-users] Re: sss_ssh_authorizedkeys returns empty list

[Jakub Hrozek via FreeIPA-users]

OK, then no wonder sssd can’t see load the attributes. Are the attributes 
present in the user entry? If you call ipa user-show you should see them.

If the attributes are there, but are not saved, then the sssd domain logs might 
have an idea what went wrong.

> On 9 Aug 2018, at 10:44, Peter Viskup  wrote:
> 
> No the pubkey attribute is not there. Tried to clean/invalidate the
> cache, but didn't help.
> This is the complete cache entry:
> 
> dn: name=ipauser@domain,cn=users,cn=domain,cn=sysdb
> createTimestamp: 1517403271
> fullName: Ipa User
> gecos: Ipa User
> gidNumber: 146231
> homeDirectory: /home/ipauser
> loginShell: /bin/bash
> name: ipauser@domain
> objectClass: user
> uidNumber: 146231
> originalDN: uid=ipauser,cn=users,cn=accounts,dc=domain,dc=com
> userPrincipalName: ipauser@domain
> mail: ipau...@domain.com
> nameAlias: ipauser@domain
> memberof: name=nou-jumpis-users@domain,cn=groups,cn=domain,cn=sysdb
> memberof: name=ou-internal-security@domain,cn=groups,cn=domain,cn=sysdb
> memberof: 
> name=nou-internal-security-builders@domain,cn=groups,cn=domain,cn=sysdb
> initgrExpireTimestamp: 1517403331
> originalMemberOf:
> cn=nou-internal-security-builders,cn=groups,cn=accounts,dc=domain,dc=com
> originalMemberOf:
> ipaUniqueID=e341f66a-e4c9-11e7-b40b-005056ab0ca4,cn=sudorules,cn=sudo,dc=domain,dc=com
> originalMemberOf: 
> cn=ou-internal-security,cn=groups,cn=accounts,dc=domain,dc=com
> originalMemberOf:
> ipaUniqueID=5acc123e-d5b5-11e7-9af8-005056ab0ca4,cn=hbac,dc=domain,dc=com
> originalMemberOf: cn=nou-jumpis-users,cn=groups,cn=accounts,dc=domain,dc=com
> originalMemberOf:
> ipaUniqueID=dd273a22-d5b7-11e7-88bc-005056ab0ca4,cn=hbac,dc=domain,dc=com
> originalMemberOf:
> ipaUniqueID=4af6ee94-d5bd-11e7-9d4a-005056ab0ca4,cn=hbac,dc=domain,dc=com
> originalMemberOf:
> ipaUniqueID=3a9d728a-e4c6-11e7-88bc-005056ab0ca4,cn=sudorules,cn=sudo,dc=domain,dc=com
> originalMemberOf:
> ipaUniqueID=d03e4b9a-fc4d-11e7-a5c4-005056ab0ca4,cn=sudorules,cn=sudo,dc=domain,dc=com
> originalMemberOf:
> ipaUniqueID=43cb7646-1198-11e8-891e-005056ab0ca4,cn=hbac,dc=domain,dc=com
> ccacheFile: FILE:/tmp/krb5cc_146231_Aqw31Q
> krbLastPwdChange: 20180530070315Z
> krbPasswordExpiration: 20180828070315Z
> originalModifyTimestamp: 20180808100017Z
> entryUSN: 252945251
> lastUpdate: 1533722422
> dataExpireTimestamp: 1533722482
> distinguishedName: name=ipauser@domain,cn=users,cn=domain,cn=sysdb
> 
> # returned 1 records
> # 1 entries
> # 0 referrals
> 
> On Thu, Aug 9, 2018 at 9:18 AM, Jakub Hrozek  wrote:
>> If you search the cache with ldbsearch -H /var/lib/sss/db/cache_domain.ldb 
>> does the user have the pubkey attribute?
>> 
>>> On 8 Aug 2018, at 11:02, Peter Viskup via FreeIPA-users 
>>>  wrote:
>>> 
>>> On Debian 9 client the sss_ssh_authorizedkeys command returns empty
>>> list. But the ipauser has SSH key in its IPA profile setup via web UI.
>>> Debug log does not point to any error:
>>> 
>>> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [get_client_cred] (0x4000):
>>> Client creds: euid[65534] egid[65534] pid[11834].
>>> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [get_client_cred] (0x0080): The
>>> following failure is expected to happen in case SELinux is disabled:
>>> SELINUX_getpeercon failed [92][Protocol not available].
>>> Please, consider enabling SELinux in your system.
>>> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [setup_client_idle_timer]
>>> (0x4000): Idle timer re-set for client [0x56353b9b65a0][18]
>>> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [accept_fd_handler] (0x0400):
>>> Client connected!
>>> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_cmd_get_version] (0x0200):
>>> Received client version [0].
>>> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_cmd_get_version] (0x0200):
>>> Offered version [0].
>>> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [ssh_cmd_parse_request]
>>> (0x0400): Requested domain [DOMAIN]
>>> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [ssh_cmd_parse_request]
>>> (0x0400): Parsing name [ipauser][DOMAIN]
>>> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_parse_name_for_domains]
>>> (0x0200): name 'ipauser' matched without domain, user is ipauser
>>> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_parse_name_for_domains]
>>> (0x0200): using default domain [DOMAIN]
>>> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_ssh_cmd_get_user_pubkeys]
>>> (0x0400): Requesting SSH user public keys for [ipauser] from [DOMAIN]
>>> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_dp_issue_request]
>>> (0x0400): Issuing request for [0x56353a7ea5f0:1:ipauser@DOMAIN@DOMAIN]
>>> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_dp_get_account_msg]
>>> (0x0400): Creating request for
>>> [DOMAIN][0x1][BE_REQ_USER][name=ipauser@DOMAIN:-]
>>> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sbus_add_timeout] (0x2000):
>>> 0x56353b9b8fc0
>>> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sss_dp_internal_get_send]
>>> (0x0400): Entering request [0x56353a7ea5f0:1:ipauser@DOMAIN@DOMAIN]
>>> (Wed Aug  8 10:54:01 2018) [sssd[ssh]] [sbus_remove_timeout] (0x2000):
>>>

[Freeipa-users] Announcing SSSD 1.16.3

[Jakub Hrozek via FreeIPA-users]

SSSD 1.16.3
===

The SSSD team is proud to announce the release of version 1.16.3 of the System 
Security Services Daemon.

The tarball can be downloaded from https://releases.pagure.org/SSSD/sssd/ 

RPM packages will be made available for Fedora shortly. 

Feedback
 
Please provide comments, bugs and other feedback via the sssd-devel or 
sssd-users mailing lists:
  https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
  https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Highlights
--

New Features

* The ``kdcinfo`` files that SSSD uses to inform libkrb5 about which KDCs
  were discovered for a Kerberos realm used to be only generated for the
  joined domain, not the trusted domains.  Starting with this release, the
  ``kdcinfo`` files are generated automatically also for trusted domains in
  setups that use ``id_provider=ad`` and IPA masters in a trust relationship
  with an AD domain.
* The SSSD Kerberos locator plugin which processes the kdcinfo files and
  actually tells libkrb5 about the available KDCs can now process multiple
  address if SSSD generates more than one. At the moment, this feature
  is only used on IPA clients (see below). Please see the
  ``sssd_krb5_locator_plugin(8)`` manual page for more information about
  the Kerberos locator plugin.
* On IPA clients, the AD DCs or the AD site which should be used to
  authenticate users can now be listed in a subdomain section. Please
  see `the feature design page 
`_
  or the section "trusted domains configuration" for more details.

Notable bug fixes
^
* SECURITY: The permissions on ``/var/lib/sss/pipes/sudo`` were set
  so that anyone could read anyone else's sudo rules. This was considered
  an information leak and assigned CVE-2018-10852 (#3766)
* IMPORTANT: The 1.16.2 release was storing the cached passwords without
  a salt prefix string. This bug was fixed in this release, but any
  password hashes generated by 1.16.2 are incompatible with the hashes
  generated by 1.16.3. The effect is that upgrade from 1.16.2 to 1.16.3
  should be done when the authentication server is reachable so that the
  first authentication after the upgrade fix the cached password.
* The ``sss_ssh`` proces leaked file descriptors when converting more than
  one x509 certificate to SSH public key (#3794)
* SSSD, when configured with ``id_provider=ad`` was using too expensive
  LDAP search to find out whether the required POSIX attributes
  were replicated to the Global Catalog. Instead, SSSD now consults
  the Partial Attribute Set, which is much more effective (#3755)
* The PAC responder is now able to process Domain Local in case the
  PAC uses SID compression. Typicaly this is the case with Windows Server
  2012 and newer (#3767)
* Some versions of OpenSSH (e.g. the one shipped in RHEL-7.5) would
  close the pipe towards ``sss_ssh_authorizedkeys`` when the matching
  key is found before the rest of the output is read. The
  ``sss_ssh_authorizedkeys`` helper was not handling this behaviour
  well and would exit with SIGPIPE, which also meant the public key
  authentication failed (#3747)
* User lookups no longer fail if user's e-mail address conflicts with
  another user's fully qualified name (#3607)
* The ``override_shell`` and ``override_homedir`` options are no longer
  applied to entries from the files domain. (#3758)
* Several bugs related  to the FleetCommander integration were fixed (#3773,
  #3774)
* The grace logins with an expired password when authenticating against
  certain newer versions of the 389DS/RHDS LDAP server did not work (#3597)
* Whitespace around netgroup triple separator is now stripped
* The ``sss_ssh_knownhostproxy`` utility can now print the host key without
  proxying the connection.
* Due to an overly restrictive check, the fast in-memory cache was sometimes
  skipped, which caused a high load on the ``sssd_nss`` process (#3776).


Packaging Changes
-
 * The python2 bindings are not built by default on Fedora 29 or newer
 * The sssd-secrets responder is now packaged in the sssd-kcm subpackage
   and might be removed in a future release

Documentation Changes
-
 * ``sss_ssh_knownhostsproxy`` has a new option `-k/--print`.

Tickets Fixed
-
* `3796 `_ - The IPA selinux provider 
can return an error if SELinux is completely disabled
* `3794 `_ - sssd_ssh leaks file 
descriptors when more than one certificate is converted into an SSH key
* `3791 `_ - The cached password does 
not store the salt prefix
* `3778 `_ - When sssd is running as 
non-root user, the sudo pipe is created as sssd:sssd but then the private pipe 
ownership fails
* `3777 `_ - If access 

[Freeipa-users] Announcing SSSD 2.0

[Jakub Hrozek via FreeIPA-users]

SSSD 2.0
===

The SSSD team is proud to announce the release of version 2.0 of the System 
Security Services Daemon.

The tarball can be downloaded from https://releases.pagure.org/SSSD/sssd/ 

RPM packages will be made available for Fedora shortly. 

Feedback
 
Please provide comments, bugs and other feedback via the sssd-devel or 
sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Highlights
--
This release removes or deprecates functionality from SSSD, therefore the SSSD
team decided it was time to bump the major version number. The sssd-1-16
branch will be still supported (most probably even as a LTM branch) so that
users who rely on any of the removed features can either migrate or ask for
the features to be readded.

Except for the removed features, this release contains a reworked internal IPC
and a new default storage back end for the KCM responder.

Platform support removal

 * Starting with SSSD 2.0, upstream no longer supports RHEL-6 and its 
derivatives.
   Users of RHEL-6 are encouraged to stick with the sssd-1-16 branch.

Removed features

 * The Python API for managing users and groups in local domains
   (``id_provider=local``) was removed completely. The interface
   had been packaged as module called ``pysss.local``
 * The LDAP provider had a special-case branch for evaluating group
   memberships with the RFC2307bis schema when group nesting was
   explicitly disabled. This codepath was adding needless additional
   complexity for little performance gain and was rarely used.
 * The ``ldap_groups_use_matching_rule_in_chain`` and
   ``ldap_initgroups_use_matching_rule_in_chain`` options and the code that
   evaluated them was removed. Neither of these options provided
   a significant performance benefit and the code implementing
   these options was complex and rarely used.

Deprecated features
^^^
 * The local provider (``id_provider=local``) and the command line
   tools to manage users and groups in the local domains, such as
   ``sss_useradd`` is not built by default anymore. There is a configure-time
   switch ``--enable-local-domain`` you can use to re-enable the local
   domain support. However, upstream would like to remove the local
   domain completely in a future release.
 * The ``sssd_secrets`` responder is not packaged by default. The responder
   was meant to provide a REST API to access user secrets as well as
   a proxy to Custodia servers, but as Custodia development all but
   stopped and the local secrets handling so far didn't gain traction,
   we decided to not enable this code by default. This also means that the
   default SSSD configuration no longer requires libcurl and http-parser.

Changed default settings

 * The ``ldap_sudo_include_regexp`` option changed its default value
   from ``true`` to ``false``. This means that wild cards in the ``sudoHost``
   LDAP attribute are no longer supported by default. The reason we
   changed the default was that the wildcard was costly to evaluate
   on the LDAP server side and at the same time rarely used.

New features

 * The KCM responder has a new back end to store credential caches
   in a local database. This new back end is enabled by default and
   actually uses the same storage as the ``sssd-secrets`` responder had used,
   so the switch from sssd-secrets to this new back end should be
   completely seamless. The ``sssd-secrets`` socket is no longer required for
   KCM to operate.
 * The list of PAM services which are allowed to authenticate using a
   Smart Card is now configurable using a new option
   ``pam_p11_allowed_services``.

Packaging Changes
-
 * The ``sss_useradd``, ``sss_userdel``, ``sss_usermod``, ``sss_groupadd``,
   ``sss_groupdel``, ``sss_groupshow`` and ``sss_groupmod`` binaries and their
   manual pages are no longer packaged by default unless
   ``--enable-local-provider`` is selected.
 * The sssd_secrets responder is no longer packaged by default unless
   ``--enable-secrets-responder`` is selected.
 * The new internal IPC mechanism uses several private libraries that
   need to be packaged - ``libsss_sbus.so``, ``libsss_sbus_sync.so``, 
``libsss_iface.so``,
   ``libsss_iface_sync.so``, ``libifp_iface.so`` and ``libifp_iface_sync.so``
 * The new KCM ccache back end relies on a private library
   ``libsss_secrets.so`` that must be packaged in case either the KCM responder
   or the secrets responder are enabled.

Documentation Changes
-
 * The ``ldap_groups_use_matching_rule_in_chain`` and
   ``ldap_initgroups_use_matching_rule_in_chain`` options were removed.
 * The ``ldap_sudo_include_regexp`` option changed its default value
   from ``true`` to ``false``.

Known issues

 * https://pagure.io/SSSD/sssd/issue/3807 - The sbus codegen script reli

[Freeipa-users] Re: selinux issues

[Jakub Hrozek via FreeIPA-users]

> On 23 Aug 2018, at 17:36, Kat via FreeIPA-users 
>  wrote:
> 
> Hi all -
> 
> So this is something I found and wanted to post it to the team - this is for 
> RHEL and/or CentOS 7.3 thru 5 so far. It has to do with selinux_provider and 
> having to explicitly disable it in sssd or things will randomly fail.
> 
> On heavily loaded clients, (and a fair load on IPA cluster) you find that 
> even if a client has selinux disabled (sometimes because of application 
> requirements) that ssh access is still randomly denied because of selinux 
> failures. You need to explicitly add selinux_provider=none to sssd.conf to 
> avoid seeing these:
> 
> sshd[58319]: fatal: Access denied for user  by PAM account 
> configuration [preauth]
> sshd[58319]: pam_sss(sshd:account): Access denied for user : 4 
> (System error)
> 
> If you look in detail you find that the authentication actually works but 
> when it is sent back to the client, there are random failures for the same 
> username from time to time. It all seems to be load related, as I have been 
> unable to find a root cause. An example is that I have a looping ssh job to 
> just login, create a folder and exit - all via ssh keys. If you run that for 
> a few hours with a few seconds interval, you find that out of 1000+ 
> successes, you might see 20-30 random "Access Denied".
> 
> This was confusing at first because sshd only returns that the authentication 
> failed without any details (return code is 255) but looking in detailed logs 
> finds the random errors as show above. This all connects back with the errors 
> I reported last week regarding the same thing and that I felt it was related 
> to DNS and other settings - it was not.
> 
> Hope this helps someone else..
> 

Do you happen to have the selinux_child.log for those failures? There was a bug 
where, if selinux called any of the NSS functions (e.g. getpwnam()) the user 
lookup might have failed because we normally prevent parts of SSSD to call back 
to sss_nss to avoid loops. This is a legit case, but we forgot to permit the 
loops.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/4A3OOXQ26CKU2YE6M5DIVUOM6XIHAUDS/

[Freeipa-users] Re: shortname in trusted ad domain

[Jakub Hrozek via FreeIPA-users]

> On 6 Sep 2018, at 09:03, Pieter Baele via FreeIPA-users 
>  wrote:
> 
> 
> I could resolve that with full_name_format = %1$s, but this breaks logon for 
> trusted AD users

btw I would expect this setting to break IDM servers, but not IDM clients.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: shortname in trusted ad domain

[Jakub Hrozek via FreeIPA-users]

On Thu, Sep 06, 2018 at 09:58:20AM +0200, Pieter Baele via FreeIPA-users wrote:
> @Jakub: not planning to use full_name_format on IDM servers, only on the
> (SAS Viya) CAS Worker Nodes (if this is the problem)
> Somehow I can no longer login directly using my AD user (which has an
> override in IPA) - once the db/mc/cache is cleared.
> 
> Sep  6 09:54:25 iictyibcls012 sshd[30884]: pam_sss(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x user=y
> Sep  6 09:54:25 iictyibcls012 sshd[30884]: pam_sss(sshd:auth): received for
> user x: 6 (Permission denied)

Hmm, this might be caused by a number of reasons, so I really need to
see the logs from that machine. The most probably causes are that either
sssd goes offline for one reason or another (sssctl domain-status is a
good help in this respect) or that HBAC is kicking you out.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: is running sssd and nscd in parallel a better option?

[Jakub Hrozek via FreeIPA-users]

On Wed, Sep 19, 2018 at 02:04:28PM +0200, Harald Dunkel via FreeIPA-users wrote:
> Hi folks,
> 
> I read somewhere that it is not recommended to run nscd to cache
> passwd on ipa clients, but I wonder: What if?

It's not technically impossible, but you'd get one more caching layer,
so the setup would be less predictable, e.g. knowing where did a NSS
reply come from is more complex, it could be from nscd, it could be from
sssd, ...

> 
> I still have the problem that sometimes some sssd components
> disappear somehow, e.g. sssd_pam. The logfile on our mail gateway
> said
> 
> :
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): pam_reply called 
> with result [0]: Success.
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [filter_responses] (0x0100): 
> [pam_response_filter] not available, not fatal.
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): blen: 74
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_dp_process_reply] (0x0010): Reply 
> error.
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): pam_reply called 
> with result [4]: System error.
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [filter_responses] (0x0100): 
> [pam_response_filter] not available, not fatal.
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): blen: 26
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_dp_process_reply] (0x0010): Reply 
> error.
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): pam_reply called 
> with result [4]: System error.
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [filter_responses] (0x0100): 
> [pam_response_filter] not available, not fatal.
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): blen: 26
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_dp_process_reply] (0x0080): 
> Client already disconnected
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_dp_process_reply] (0x0080): 
> Client already disconnected
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [sbus_dispatch] (0x0020): Performing 
> auto-reconnect
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
> reconnecting. Deferring.
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
> reconnecting. Deferring.
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
> reconnecting. Deferring.
> (Tue Sep 18 22:34:28 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
> reconnecting. Deferring.

This indicated a crash in sssd_be...I don't know Debian almost at all,
but I would check the syslog for evidence..

> :
> :
> (Tue Sep 18 22:34:29 2018) [sssd[pam]] [pam_dom_forwarder] (0x0100): 
> pam_dp_send_req returned 11
> (Tue Sep 18 22:34:29 2018) [sssd[pam]] [pam_reply] (0x0200): pam_reply called 
> with result [4]: System error.
> (Tue Sep 18 22:34:29 2018) [sssd[pam]] [filter_responses] (0x0100): 
> [pam_response_filter] not available, not fatal.
> (Tue Sep 18 22:34:29 2018) [sssd[pam]] [pam_reply] (0x0200): blen: 26
> (Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
> reconnecting. Deferring.
> (Tue Sep 18 22:34:29 2018) [sssd[pam]] [client_recv] (0x0200): Client 
> disconnected!
> (Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
> reconnecting. Deferring.
> (Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
> reconnecting. Deferring.
> (Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
> reconnecting. Deferring.
> (Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
> reconnecting. Deferring.
> (Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
> reconnecting. Deferring.
> :
> :
> (Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_reconnect] (0x0080): Making 
> reconnection attempt 1 to 
> [unix:path=/var/lib/sss/pipes/private/sbus-dp_aixigo.de]
> (Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_reconnect] (0x0080): Reconnected 
> to [unix:path=/var/lib/sss/pipes/private/sbus-dp_aixigo.de]
> (Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_conn_register_path] (0x0400): 
> Registering object path /org/freedesktop/sssd/responder with D-Bus connection
> (Tue Sep 18 22:34:29 2018) [sssd[pam]] [pam_dp_reconnect_init] (0x0020): 
> Reconnected to the Data Provider.
> :
> 
> Some EMails were bounced with user unknown at the same time, so I would
> guess there is a coincidence. Question is, could nscd be an option here,
> providing an additional cache for user accounts? What side effects could
> come up?
> 
> Platform is Debian 9, sssd is version 1.16.2, nscd version 2.24.
> 
> 
> Every helpful comment is highly appreciated.
> Regards
> Harri
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/ar

[Freeipa-users] Re: Only users that has 'su-l' service *enabled* can you su - [user] to - This seems backwards ? users with 'su-l' *disabled* can su - [user] that has service enabled ....

[Jakub Hrozek via FreeIPA-users]

On Mon, Oct 22, 2018 at 05:35:05PM +0100, Morgan Cox via FreeIPA-users wrote:
> Hi.
> 
> I have created a HBAC rule for sysadmins.. One that has all services
> enabled.
> 
> Logically I would expect only users with the service 'su-l' enabled to be
> able to su - [user].
> 
> However in reality it is working the opposite way ...
> 
> i.e I have 2 users - both are allowed on the server I am testing on
> 
> user 1 : mcox - this has all services enabled
> user 2: mcox3 - this only has sshd enabled
> 
> However - user mcox cannot 'su - mcox3', but user mcox3 can 'su - mcox' -
> which seems the wrong way round - I would expect only users with 'su-l'
> service to be able to su -  ??

Maybe the confusing part is that the rules apply to the user you're
logging in to, not logging in 'from' ?

> 
> - mcox -> mcox3 gets 'su: Permission denied'
> 
> hbactest shows I should be granted on mcox and fail on mcox3
> 
> Is it my understanding of the rule at fault or someone else ?
> 
> Note : user mcox can 'su - mcox' also..
> 
> Below are the rules
> 
> for user : mcox
> 
> # ipa hbactest --user mcox --host ipaclient2.cpgbpc.local --service su-l
> 
> Access granted: True
> 
>   Matched rules: allow_all_sysadmin
>   Not matched rules: allow_desktop
>   Not matched rules: allow_ssh_access
> ---
> 
> # ipa hbacrule-show allow_all_sysadmin
>   Rule name: allow_all_sysadmin
>   Host category: all
>   Service category: all
>   Enabled: TRUE
>   Users: mcox
>   User Groups: sysadmin

This matches with the second set of logs where you su to mcox and the
logs say:
> (Mon Oct 22 17:33:38 2018) [sssd[be[cpgbpc.local]]]
> [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule
> [allow_all_sysadmin]
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: can clients or servers be pinned to named Active Directory servers to bypass DNS auto-discovery?

[Jakub Hrozek via FreeIPA-users]

On Wed, Oct 24, 2018 at 08:53:10AM -0400, Chris Dagdigian via FreeIPA-users 
wrote:
> Thanks! Replies in line
> 
> 
> 
> 
> Alexander Bokovoy wrote on 10/24/18 8:40 AM:
> > On ke, 24 loka 2018, Chris Dagdigian via FreeIPA-users wrote:
> > > Is it possible to override the AD integration use of DNS queries to
> > > find AD controllers and replace the auto-discovery with a named list
> > > of domain controllers?
> > Where? In 'ipa trust-add' or in SSSD? The former has already a mechanism
> > by specifying a domain controller to contact.
> 
> Trust is already built and that took *months* to arrange with the mysterious
> AD admins who do not talk to mere mortals. Not going to mess with that!
> Looking to pin IDM interactions with named AD servers at the sssd.conf level
> I think
> > 
> > > We've got a setup in an AWS VPC and we've found that out of the 100
> > > or so domain controllers in DNS that a few of them refuse to talk to
> > > us or answer ldaps:// queries. After a lot of nmap and DNS probe
> > > work we think we've discovered a number of "bad" controllers that
> > > may be responsible for random password check / login failures in the
> > > AWS environment
> > > 
> > > Can the latest sssd/free-ipa be configured to use a list of "known
> > > good" domain controllers?
> > SSSD can be pinned down to the specific site and also to specific domain
> > controllers in 1.16+. Some of the configurations are possible with
> > earlier versions too, see manual page for sssd-ipa(5), section "Trusted
> > domains configuration".
> 
> Thank you ! We will research/test this
> 
> 
> Love this list and the resources on it!

A small correction to Alexander's mail:

On IPA masters themselves, setting something like:
[domain/ipa.domain/ad.domain]
ad_server = foo, bar, baz

or even just:
[domain/ipa.domain/ad.domain]
ad_site = my.site

was working since 1.15:
https://docs.pagure.org/SSSD.sssd/design_pages/subdomain_configuration.html

but clients were a different matter and the above configurations would
only work since versions that implement:
https://docs.pagure.org/SSSD.sssd/design_pages/kdcinfo_improvements.html
upstream-wise this is since 1.16.3, but the patches were also backported
to RHEL-7.6 (which should be released in short future)

If you have an older client, you can work around this issue by setting
the AD DCs in krb5.conf (yes, krb5.conf, not sssd.conf) directly.

HTH
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: smartcard auth + kerberos ticket?

[Jakub Hrozek via FreeIPA-users]

On Thu, Nov 15, 2018 at 06:06:01PM +0100, Sumit Bose via FreeIPA-users wrote:
> On Thu, Nov 15, 2018 at 04:17:20PM +0100, Natxo Asenjo via FreeIPA-users 
> wrote:
> > hi,
> > 
> > for posterity's sake, this appears to be a problem with kcm (whatever that
> > is, don't know yet, will look it up later).
> > 
> > I turned it off in /etc/krb5.conf.d/kcm_default_ccache (just comment the
> > two not comment lines) and after restart sssd or rebooting, with selinux
> > enabled, it works.
> 
> ah, sorry, I should have thought of this earlier. This is most probably
> https://pagure.io/SSSD/sssd/issue/3376.

Thank you for digging into this.

While the root access itself is easy to fix, there would be another
problem. MIT, unlike Heimdal doesn't allow you to refer to a collection
with KCM:%{uid}. You can either use KCM: and then libkrb5 should do the
right thing and either create a new subsidiary cache for this principal
or switch to an existing one. Alternatively you can point to a residual
cache with KCM:%{uid}:xyz

I thought this was a bug in MIT, but upstream disagreed.

> 
> SSSD'd krb5_child runs as root with the IPA provider, e.g. to be
> able to read the keytab for the Kerberos ticket validation. Due to the
> issue from above it cannot save the TGT for the user.

looking at the code it's not running as root in general, but only in the
SC case:

3323 /* pkinit needs access to pcscd */
3324 if ((sss_authtok_get_type(kr->pd->authtok) != SSS_AUTHTOK_TYPE_SC_PIN  
  
3325 && sss_authtok_get_type(kr->pd->authtok)
3326 != SSS_AUTHTOK_TYPE_SC_KEYPAD)) {  
  
3327 kerr = k5c_become_user(kr->uid, kr->gid, kr->posix_domain);
  
3328 if (kerr != 0) {   
  
3329 DEBUG(SSSDBG_CRIT_FAILURE, "become_user failed.\n");   
  
3330 ret = EFAULT;
3331 goto done; 
3332 }   
 }

I hope we would have heard someone complaining quite sooner if no IPA
logins were possible with KCM :)
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Mix and Match Local Users and Groups with IPA Users and Groups?

[Jakub Hrozek via FreeIPA-users]

On Thu, Nov 15, 2018 at 02:18:28PM -0500, Rob Crittenden via FreeIPA-users 
wrote:
> Ryan Slominski via FreeIPA-users wrote:
> > What is the recommended way to handle a local user in an IPA group?
> > 
> > For example, I have the standard local user "apache" that I'd like to add 
> > to an IPA group.  I don't really want to add an "apache" user to IPA as it 
> > isn't really a regular user.  Similarly, I don't want to create a local 
> > group of the same name and membership as the group in IPA.  NIS seems to 
> > allow groups that reference local users.  Can IPA?
> > 
> > An IPA User in a local group is a similar problem, what is the solution 
> > there?
> 
> https://pagure.io/SSSD/sssd/issue/3642

Yes, but this ticket only poses a problem if nsswitch.conf is configured
to use sss before files (which is the default on F-26+ and RHEL-8).

If you revert to "files sss", then you can use:
https://sgallagh.wordpress.com/2016/01/28/remote-group-merging-for-fedora/
by creating a group with the same name and GID both locally and in the
IPA directory, then the contents should be merged.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: New clients doesn't allow to use AD users with shortnames and showing the users/groups also with short names

[Jakub Hrozek via FreeIPA-users]

On Wed, Nov 21, 2018 at 02:22:51PM +, SOLER SANGUESA Miguel via 
FreeIPA-users wrote:
> I've been working for 1 year with a configuration that allow us to use AD 
> users with short names for login on RHEL 6 clients and also the information 
> on the client was showed with shortnames. Example:

This doesn't work in general on RHEL-6. I don't know why it ever did,
for you and I'm suprised it did, but in general, short name output is only
supported in never versions that RHEL-6 ships. And even in RHEL-7+ it is
/strongly/ discouraged to use shortnames in output.

The only thing that RHEL-6 supports in this respect is the
default_domain_suffix option, but the output will always be qualified.

Sorry.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Web app integration

[Jakub Hrozek via FreeIPA-users]

On Sun, Nov 25, 2018 at 06:51:36PM +0100, Alex Corcoles via FreeIPA-users wrote:
> I mean it still requires a sizable amount of elbow grease. I think
> there is no systemd unit file, it doesn't come as an RPM which can be
> easily upgraded, etc.

OTOH, creating the systemd unit file is not super complex either:
https://matthew-beliveau.github.io/How-to-Setup-Keycloak/
https://matthew-beliveau.github.io/Keycloak-and-FreeIPA/
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: different security policy for login(password+otp) and screenlock (password only) for workstation

[Jakub Hrozek via FreeIPA-users]

On Mon, Mar 18, 2019 at 06:14:16PM +0200, Alexander Bokovoy wrote:
> On ma, 18 maalis 2019, Jelle de Jong via FreeIPA-users wrote:
> > Hello everybody,
> > 
> > 
> > I am looking for a way to have different authentication policy for a
> > freeia-client logout and screenlock on linux workstations.
> > 
> > When a user logs in I want to use my password+otp (this is working)!
> > 
> > When a user locks it screen I want to be able unlock it with only the
> > password.
> > 
> > When a user logs out and back in then it needs to use the password+otp
> > again.
> > 
> > I am aware of the security implications for this.
> > 
> > How can I configure this policy?
> I don't think there is a way to deploy such policy through SSSD at all.
> 
> Jakub, do you have an idea how to make that possible?

Currently I can't think of anything clean either. Is the lock screen and the
login manager the same PAM service? If they are different, maybe some
hack like letting pam_unix to always read the password and then just
pass it on to pam_sss would work..

But I know Sumit is working on improving the 2FA prompting lately, so
maybe this will be improved in the upcoming release.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Announcing SSSD 1.16.4

[Jakub Hrozek via FreeIPA-users]

SSSD 1.16.4
===
The SSSD team is proud to announce the release of version 1.16.4 of the
System Security Services Daemon.

The tarball can be downloaded from https://releases.pagure.org/SSSD/sssd/

RPM packages will be made available for Fedora shortly.

Feedback


Please provide comments, bugs and other feedback via the sssd-devel or
sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Highlights
--

New Features

 * The list of PAM services which are allowed to authenticate using a
   Smart Card is now configurable using a new option
   ``pam_p11_allowed_services``. (#2926)
 * A new configuration option ``ad_gpo_implicit_deny`` was added. This option
   (when set to True) can be used to deny access to users even if there is
   not applicable GPO. Normally users are allowed access in this situation.
   (#3701)
 * The LDAP authentication provider now allows to use a different method of
   changing LDAP passwords using a modify operation in addition to the
   default extended operation. This is meant to support old LDAP servers
   that do not implement the extended operation. The password change using
   the modification operation can be selected with ``ldap_pwmodify_mode =
   "ldap_modify"`` (#1314)
 * The ``auto_private_groups`` configuration option now takes a new value
   ``hybrid``. This mode autogenerates private groups for user entries
   where the UID and GID values have the same value and at the same time
   the GID value does not correspond to a real group entry in LDAP (#3822)

Security issues fixed
^
 * CVE-2019-3811: SSSD used to return "/" in case a user entry had no home
   directory. This was deemed a security issue because this flaw could
   impact services that restrict the user's filesystem access to within
   their home directory.  An empty home directory field would indicate
   "no filesystem access", where sssd reporting it as "/" would grant full
   access (though still confined by unix permissions, SELinux etc).

Notable bug fixes
^
 * The IPA provider, in a setup with a trusted Active Directory domain,
   did not remove cached entries that were no longer present on
   the AD side (#3984)
 * The Active Directory provider now fetches the user information from the
   LDAP port and switches to using the Global Catalog port, if available
   for the group membership. This fixes an issue where some attributes
   which are not available in the Global Catalog, typically the home
   directory, would be removed from the user entry. (#2474)
 * The IPA SELinux provider now sets the user login context even if it is the
   same as the system default. This is important in case the user has
   a non-standard home directory, because then only adding the user to
   the SELinux database ensures the home directory will be labeled properly.
   However, this fix causes a performance hit during the first login
   as the context must be written into the semanage database.
 * The sudo responder did not reflect the case_sensitive domain option
   (#3820)
 * A memory leak when requesting netgroups repeatedly was fixed (#3870)
 * An issue that caused SSSD to sometimes switch to offline mode in case
   not all domains in the forest ran the Global Catalog service was
   fixed (#3902)
 * The SSH responder no longer fails completely if the ``p11_child`` times out
   when deriving SSH keys from a certificate (#3937)
 * The negative cache was not reloaded after new sub domains were discovered 
which
   could have lead to a high SSSD load (#3683)
 * The negative cache did not work properly for in case a lookup fell back to 
trying
   a UPN instead of a name (#3978)
 * If any of the SSSD responders was too busy, that responder wouldn't have
   refreshed the trusted domain list (#3967)
 * A potential crash due to a race condition between the fail over code 
refreshing
   a SRV lookup and back end using its results (#3976)
 * Sudo's runAsUser and runAsGroup attributes did not match properly when used 
in
   setups with domain_resolution_order
 * Processing of the values from the ``filter_users`` or ``filter_groups`` 
options
   could trigger calls to blocking NSS API functions which could in turn
   prevent the startup of SSSD services in case nsswitch.conf contained
   other modules than ``sss`` or ``files`` (#3963)

Tickets Fixed
-
 * `3967 `_ - NSS responder does no 
refresh domain list when busy
 * `2926 `_ - Make list of local PAM 
services allowed for Smartcard authentication configurable
 * `3819 `_ - sssd only sets the 
SELinux login context if it differs from the default
 * `3820 `_ - sudo: search with lower 
cased name for case insensitive domains
 * `3870 

[Freeipa-users] Re: IPA Client SSH under AD cross-forest trust not working

[Jakub Hrozek via FreeIPA-users]

On Mon, Apr 29, 2019 at 06:56:33PM +, D via FreeIPA-users wrote:
> Hello,
> 
> Apologies for the earlier premature post :)
> 
> This list helped me solve a number of issues getting a proof-of-concept 
> ipa-ad cross-forest trust working. I believe there is one final issue, 
> hopefully one of the experts here can have a look at the logs and let me know 
> if anything sticks out.
> 
> I am able to SSH into the ipa master using my AD creds, but have not yet been 
> able to ssh into a given ipa client using AD creds.
> 
> Here's some details:
> 1. domain.acme.com is the AD domain, ipa.domain.acme.com is the ipa domain. 
> All ipa clients belong to ipa.domain.acme.com, and they reside in a DNS zone 
> controlled by the ipa server.
> 2. It's using the posix id range scheme.
> 3. All configs are fairly stock, and everything set up quite happily using 
> srvs for autodiscovery. There are sites configured, which appear to be 
> working.
> 4. The ipa clients make no effort to contact the ad servers for KDC or PAC. I 
> have a feeling it doesn't get that far.
> 5. IPA users can ssh into the ipa clients just fine, ad users cannot.
> 
> Thank you for your time,
> D

> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] [sbus_dispatch] 
> (0x4000): dbus conn: 0x55b6a51cc380
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] [sbus_dispatch] 
> (0x4000): Dispatching.
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sbus_message_handler] (0x2000): Received SBUS method 
> org.freedesktop.sssd.dataprovider.getAccountInfo on path 
> /org/freedesktop/sssd/dataprovider
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [dp_get_account_info_handler] (0x0200): Got request for 
> [0x1][BE_REQ_USER][name=myu...@domain.acme.com]
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] [dp_attach_req] 
> (0x0400): DP Request [Account #31]: New request. Flags [0x0001].
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] [dp_attach_req] 
> (0x0400): Number of active DP request: 1
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sss_domain_get_state] (0x1000): Domain ipa.domain.acme.com is Active
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sss_domain_get_state] (0x1000): Domain domain.acme.com is Active
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sss_domain_get_state] (0x1000): Domain ipa.domain.acme.com is Active
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sss_domain_get_state] (0x1000): Domain domain.acme.com is Active
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sdap_id_op_connect_step] (0x4000): reusing cached connection
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sdap_id_op_connect_step] (0x4000): reusing cached connection
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view 
> [Default Trust View] with filter 
> [(&(objectClass=ipaUserOverride)(uid=myuser))].
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sdap_print_server] (0x2000): Searching 172.18.181.132:389
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with 
> [(&(objectClass=ipaUserOverride)(uid=myuser))][cn=Default Trust 
> View,cn=views,cn=accounts,dc=ipa,dc=domain,dc=acme,dc=com].
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 9
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] [sdap_op_add] 
> (0x2000): New operation 9 timeout 30
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sdap_process_result] (0x2000): Trace: sh[0x55b6a51e5060], connected[1], 
> ops[0x55b6a51d8680], ldap[0x55b6a51cb9c0]
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg 
> set
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sdap_op_destructor] (0x2000): Operation 9 finished
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [ipa_get_ad_override_done] (0x4000): No override found with filter 
> [(&(objectClass=ipaUserOverride)(uid=myuser))].
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sdap_id_op_destroy] (0x4000): releasing operation connection
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sss_domain_get_state] (0x1000): Domain ipa.domain.acme.com is Active
> (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> [sss_domain_get_state] (0x1000): Domain domain.acme.com is Active
> (Mon Apr 29 18:14:17 20

[Freeipa-users] Re: IPA Client SSH under AD cross-forest trust not working

[Jakub Hrozek via FreeIPA-users]

On Mon, Apr 29, 2019 at 07:48:30PM +, D wrote:
> Ah ok, I see the nss lookup fails on the client now.

What nss lookup exactly?

> 
> On the ipa master during failed client login, the only nss log entry says my 
> ad user matched the ad domain.

Did you crank up the debug logs? Chances are some entries are returned
from the memory cache, you might want to run sss_cache -E on the master
before the test.

> 
> When I log in to the master with ad creds (which works), I see all of the ad 
> groups properly resolving in the logs (at least the ones with proper 
> gidNumber attributes). The cache on the ipa master contains an entry for the 
> ad user with proper membership as well.
> 
> At this stage, is it failing to lookup the ad user against AD or against ipa? 
> I can see that during successful ad logins on the master, it looks first at 
> ipa but understands that it must then look at ad.

The client fetches the NSS information through the IPA master.

> 
> FWIW the ipa masters have the AD ldaps cert installed but the clients do not. 
> Not sure if that's related.
> 
> Thanks,
> D
> ‐‐‐ Original Message ‐‐‐
> On Monday, April 29, 2019 3:04 PM, Jakub Hrozek via FreeIPA-users 
>  wrote:
> 
> > On Mon, Apr 29, 2019 at 06:56:33PM +, D via FreeIPA-users wrote:
> >
> > > Hello,
> > > Apologies for the earlier premature post :)
> > > This list helped me solve a number of issues getting a proof-of-concept 
> > > ipa-ad cross-forest trust working. I believe there is one final issue, 
> > > hopefully one of the experts here can have a look at the logs and let me 
> > > know if anything sticks out.
> > > I am able to SSH into the ipa master using my AD creds, but have not yet 
> > > been able to ssh into a given ipa client using AD creds.
> > > Here's some details:
> > >
> > > 1.  domain.acme.com is the AD domain, ipa.domain.acme.com is the ipa 
> > > domain. All ipa clients belong to ipa.domain.acme.com, and they reside in 
> > > a DNS zone controlled by the ipa server.
> > > 2.  It's using the posix id range scheme.
> > > 3.  All configs are fairly stock, and everything set up quite happily 
> > > using srvs for autodiscovery. There are sites configured, which appear to 
> > > be working.
> > > 4.  The ipa clients make no effort to contact the ad servers for KDC or 
> > > PAC. I have a feeling it doesn't get that far.
> > > 5.  IPA users can ssh into the ipa clients just fine, ad users cannot.
> > >
> > > Thank you for your time,
> > > D
> >
> > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> > > [sbus_dispatch] (0x4000): dbus conn: 0x55b6a51cc380
> > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> > > [sbus_dispatch] (0x4000): Dispatching.
> > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> > > [sbus_message_handler] (0x2000): Received SBUS method 
> > > org.freedesktop.sssd.dataprovider.getAccountInfo on path 
> > > /org/freedesktop/sssd/dataprovider
> > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> > > [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
> > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> > > [dp_get_account_info_handler] (0x0200): Got request for 
> > > [0x1][BE_REQ_USER][name=myu...@domain.acme.com]
> > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> > > [dp_attach_req] (0x0400): DP Request [Account #31]: New request. Flags 
> > > [0x0001].
> > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> > > [dp_attach_req] (0x0400): Number of active DP request: 1
> > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> > > [sss_domain_get_state] (0x1000): Domain ipa.domain.acme.com is Active
> > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> > > [sss_domain_get_state] (0x1000): Domain domain.acme.com is Active
> > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> > > [sss_domain_get_state] (0x1000): Domain ipa.domain.acme.com is Active
> > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> > > [sss_domain_get_state] (0x1000): Domain domain.acme.com is Active
> > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> > > [sdap_id_op_connect_step] (0x4000): reusing cached connection
> > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] 
> > > [sdap_id_op_connect_step] (0x4000): reusing cached connection
> > > (Mon A

[Freeipa-users] Announcing SSSD 2.2.0

[Jakub Hrozek via FreeIPA-users]

SSSD 2.2.0
===
The SSSD team is proud to announce the release of version 2.2.0 of the
System Security Services Daemon. The tarball can be downloaded from:
https://releases.pagure.org/SSSD/sssd/

RPM packages will be made available for Fedora shortly.

Feedback

Please provide comments, bugs and other feedback via the sssd-devel or
sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Highlights
--

New features

 * The Kerberos provider (and composite authentication providers based on it,
   like AD or IPA) can now include more KDC addresses or host
   names when writing data for the Kerberos locator plugin (see
   ``sssd_krb5_locator_plugin(8)``). This means that Kerberos client
   applications, such as ``kinit`` would be able to switch between multiple
   KDC servers discovered by SSSD. Please see description of the option
   ``krb5_kdcinfo_lookahead`` in the ``sssd-krb5(5)`` manual page for more
   information or refer to `the design page 
   
`_
   (#3973, #3974, #3975)
 * The 2FA prompting can now be configured. The administrator can set custom
   prompts for first or second factor or select a single prompt for both
   factors. This can be configured per-service. Please see the section called
   "Prompting configuration" in the ``sssd.conf(5)`` manual page for more
   details or refer to `the design page 
   
`_
   (#3264).
 * The LDAP authentication provider now allows to use a different method of
   changing LDAP passwords using a modify operation in addition to the default
   extended operation. This is meant to support old LDAP servers that do not
   implement the extended operation. The password change using the modification
   operation can be selected with ``ldap_pwmodify_mode = "ldap_modify"``. More
   information can also be found in `the design page 
   
`_
   (#1314)
 * The ``auto_private_groups`` configuration option now takes a new value
   ``hybrid``. This mode autogenerates private groups for user entries where
   the UID and GID values have the same value and at the same time the GID
   value does not correspond to a real group entry in LDAP (#3822)
 * A new option ``ad_gpo_ignore_unreadable`` was added. This option,
   which defaults to false, can be used to ignore group policy containers in AD
   with unreadable or missing attributes. This is for the case when server
   contains GPOs that have very strict permissions on their attributes
   in AD but are unrelated to access control (#3867)
 * The ``cached_auth_timeout`` parameter is now inherited by trusted domains
   (#3960). The pre-authentication request is now cached as well when this
   option is in effect (#3960)
 * The ``ldap_sasl_mech`` option now accepts another mechanism ``GSS-SPNEGO``
   in addition to ``GSSAPI``. Using SPNEGO might be preferable with newer
   Active Directory servers especially with hardened configurations. SSSD might
   switch to using SPNEGO by default in a future release (#4006)
 * The ``sssctl`` tool has two new commands ``cert-show`` and ``cert-map``
   which can help in troubleshooting Smart-Card and in general user certificate
   related issues

Notable bug fixes
^
 * A potential race condition between SSSD receiving a notification to try
   switching to online mode and the network being actually reachable is
   now handled better. SSSD now tries to go online three times with an
   increasing delay between online checks up to 4s (#3467).
 * A potential deadlock in user resolution when the IPA provider fetches
   the keytab used to authenticate to a trusted AD domain was fixed (#3992)
 * When checking if objects that cannot be looked up exist locally and thus
   should be added to a negative cache with a longer negative TTL (see
   ``local_negative_timeout`` in ``sssd.conf(5)``), the blocking NSS API
   is no longer used. The blocking calls which might have caused a timeout
   especially during SSSD startup (#3963)
 * Some cache attributes used by the Kerberos ticket renewal code are
   now indexed, which speeds up the cache searches which might have otherwise
   caused SSSD to appear blocked and killed by the internal watchdog (#3968)
 * Cached objects from an Active Directory domain trusted by an IPA domain
   that no longer exist on the server are now properly removed from the
   cache (#3984)
 * The ``sudoRunAsUser/Group`` now work correctly with an IPA configuration
   that also uses the ``domain_resolution_order``, either set locally or
   centrally (#3957)
 * Certificates that are completely missing the Key Usage (KU) certificate
   extension are now handled graceful

[Freeipa-users] Re: Seeking URLs/docs/tips on handling UPN change in a complex already-trusted AD topology

[Jakub Hrozek via FreeIPA-users]

On Mon, Jul 22, 2019 at 07:26:19AM -0400, Chris Dagdigian via FreeIPA-users 
wrote:
> Hi folks,
> 
> Environment:   AWS-based FreeIPA cluster with it's own unique realm/domain
> that is bound to the AD domain of the real COMPANY.COM and a fairly complex
> forest
> 
> We have a functional FreeIPA system at the moment where AD users from
> COMPANY.COM can login
> 
> - via  @CHILD-DOMAIN.COMPANY.COM on older systems
> 
> - via @COMPANY.COM on newer systems with fresh SSSD (thank
> you AD search domains, heh!)
> 
> 
> But we've gotten word from AD admins that they want to change the UPN from
>  to ".@company.com" and although I
> did not witness it supposedly when they made the change, all SSH logins to
> our FreeIPA managed systems broke.

All logins or logins of the users that changed their UPN format? Do you
use the UPN to log in or do you use the samaccountname@domain login
format and still the login breaks?

> 
> I'm still not 100% convinced that things broke and we'll be testing more
> this week  --- but now I'm motivated to try to get ahead of any potential
> problems ...
> 
> Looking for documentation and URLS to read or general tips and advice
> regarding any impact or changes needed on FreeIPA when the UPN on Active
> Directory changes format.
> 
> In particular:
> 
> - What happens to existing IPA user groups of type "external" when we've
> listed those AD usernames via their @CHILD-DOMAIN.COMPANY.COM 
> and the UPN is now different? Do we have to go update/change/fix all of our
> external users?  If so, do those changes propagate into all of the other
> RBAC rules or are we looking at an entire rebuild/reset of our RBAC and user
> environment?

I don't think so, the links are stored as SIDs, which should remain the
same..

> 
> - Any FreeIPA changes or settings to look at or alter when UPN changes
> format?

As long as the UPN suffic was already known, I would /hope/ that you
shouldn't need to do anything. The only thing that comes to mind might
be to expire the caches, at least on the IPA masters. Otherwise the
clients, even if their cache is expired, might fetch the old UPN from
the masters and try to use that..

> 
> I'm probably missing other major questions to ask so any other tips or
> advice would be appreciated.
> 
> Regards
> Chris
> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Use IPA AD users in keycloak

[Jakub Hrozek via FreeIPA-users]

On Tue, Aug 20, 2019 at 01:13:09PM +0200, Ronald Wimmer via FreeIPA-users wrote:
> SSSD seems to work now and I can login to Keycloak with an IPA user.
> Unfortunately, when trying to use an AD user I get an exception:
> 
> Aug 20 13:10:46 keycloak-test.linux.mydomain.at standalone.sh[16537]:
> 13:10:46,967 WARN  [org.keycloak.services] (default task-52)
> KC-SERVICES0013: Failed authentication: org.keycloak
> 
> .federation.sssd.api.SSSDException: Failed to retrieve user's attributes.
> Check if SSSD service is active.
> 
> Aug 20 13:10:46 keycloak-test.linux.mydomain.at standalone.sh[16537]: at
> org.keycloak.federation.sssd.api.Sssd.getUser(Sssd.java:112)
> 
> Aug 20 13:10:46 keycloak-test.linux.mydomain.at standalone.sh[16537]: at 
> org.keycloak.federation.sssd.SSSDFederationProvider.importUserToKeycloak(SSSDFederationProvider.java:114)
> 
> Aug 20 13:10:46 keycloak-test.linux.mydomain.at standalone.sh[16537]: at 
> org.keycloak.federation.sssd.SSSDFederationProvider.findOrCreateAuthenticatedUser(SSSDFederationProvider.java:
> 
> 109)
> 
> 
> SSSD service is active.
> 

As far as I remember, Keycloak uses the D-Bus interface of SSSD to
retrieve the user's attribute. Can you check if the ifp service is up
and running and if there are any helpful logs in the sssd_ifp.log file?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Use IPA AD users in keycloak

[Jakub Hrozek via FreeIPA-users]

On Fri, Aug 23, 2019 at 01:07:23PM +0200, Ronald Wimmer via FreeIPA-users wrote:
> On 22.08.19 15:57, Jakub Hrozek via FreeIPA-users wrote:
> > [...]
> > As far as I remember, Keycloak uses the D-Bus interface of SSSD to
> > retrieve the user's attribute. Can you check if the ifp service is up
> > and running and if there are any helpful logs in the sssd_ifp.log file?
> 
> I do not get AD attributes apart from mail:
> 
> (Tue Aug 20 14:09:37 2019) [sssd[ifp]] [ifp_add_ldb_el_to_dict] (0x0400):
> element [mail] has value [ronald.wim...@mydomain.at]
> (Tue Aug 20 14:09:37 2019) [sssd[ifp]] [ifp_user_get_attr_handle_reply]
> (0x0080): Attribute givenname not present or has no values
> (Tue Aug 20 14:09:37 2019) [sssd[ifp]] [ifp_user_get_attr_handle_reply]
> (0x0080): Attribute sn not present or has no values
> (Tue Aug 20 14:09:37 2019) [sssd[ifp]] [ifp_user_get_attr_handle_reply]
> (0x0080): Attribute telephoneNumber not present or has no values
> 
> (Tue Aug 20 14:10:05 2019) [sssd[ifp]] [sbus_dispatch] (0x4000): dbus conn:
> 0x55a8f4758970 (Tue Aug 20 14:10:05 2019) [sssd[ifp]] [sbus_dispatch]
> (0x4000): Dispatching. (Tue Aug 20 14:10:05 2019) [sssd[ifp]]
> [sbus_signal_handler] (0x2000): Received D-Bus signal
> org.freedesktop.DBus.NameOwnerChanged (Tue Aug 20 14:10:05 2019) [sssd[ifp]]
> [sbus_signal_handler_got_caller_id] (0x0400): Got a signal from the bus..
> (Tue Aug 20 14:10:05 2019) [sssd[ifp]] [sbus_signal_name_owner_changed]
> (0x0400): Clearing UIDs cache (Tue Aug 20 14:10:05 2019) [sssd[ifp]]
> [sbus_dispatch] (0x4000): dbus conn: 0x55a8f4758970 (Tue Aug 20 14:10:05
> 2019) [sssd[ifp]] [sbus_dispatch] (0x4000): Dispatching. (Tue Aug 20
> 14:10:05 2019) [sssd[ifp]] [sbus_signal_handler] (0x2000): Received D-Bus
> signal org.freedesktop.DBus.NameOwnerChanged (Tue Aug 20 14:10:05 2019)
> [sssd[ifp]] [sbus_signal_handler_got_caller_id] (0x0400): Got a signal from
> the bus.. (Tue Aug 20 14:10:05 2019) [sssd[ifp]]
> [sbus_signal_name_owner_changed] (0x0400): Clearing UIDs cache
> 
> And here a keycloak log snippet:
> 
> Aug 20 13:10:46 keycloak-test.linux.mydomain.at standalone.sh[16537]:
> 13:10:46,967 WARN  [org.keycloak.services] (default task-52)
> KC-SERVICES0013: Failed authentication: org.keycloak
> .federation.sssd.api.SSSDException: Failed to retrieve user's attributes.
> Check if SSSD service is active.
> Aug 20 13:10:46 keycloak-test.linux.mydomain.at standalone.sh[16537]: at
> org.keycloak.federation.sssd.api.Sssd.getUser(Sssd.java:112)
> Aug 20 13:10:46 keycloak-test.linux.mydomain.at standalone.sh[16537]: at 
> org.keycloak.federation.sssd.SSSDFederationProvider.importUserToKeycloak(SSSDFederationProvider.java:114)
> Aug 20 13:10:46 keycloak-test.linux.mydomain.at standalone.sh[16537]: at 
> org.keycloak.federation.sssd.SSSDFederationProvider.findOrCreateAuthenticatedUser(SSSDFederationProvider.java:
> 109)

Hmm, I don't remember from the top of my head which attributes does KC
try to fetch, but e-mail sounds like what it would need, at least that's
what's most commonly used for claims and such.

If you correlate the KC lookup errors with ifp sssd logs, what is the
exact lookup that KC is doing but that is failing?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Use IPA AD users in keycloak

[Jakub Hrozek via FreeIPA-users]

On Fri, Aug 23, 2019 at 05:48:18PM +0200, Ronald Wimmer via FreeIPA-users wrote:
> On 23.08.19 15:53, Jakub Hrozek via FreeIPA-users wrote:
> > [...]
> > Hmm, I don't remember from the top of my head which attributes does KC
> > try to fetch, but e-mail sounds like what it would need, at least that's
> > what's most commonly used for claims and such.
> > 
> > If you correlate the KC lookup errors with ifp sssd logs, what is the
> > exact lookup that KC is doing but that is failing?
> 
> The four attributes KC is trying to fetch are mail, givenName, sn and
> telephoneNumber. The keycloak-sssd-configuration script adds somthing like
> 
> ldap_user_extra_attrs = mail:mail, sn:mail, givenname:mail,
> telephoneNumber:mail

Wait, do they really map all these attributes to mail? This seems wrong,
the format is externalname:ldapname and IIRC the last one wins, so the last
one is applied and stores mail as telephoneNumber.

So given the LDAP server is IPA, could you change the config to fetch
the proper LDAP attributes? Actually all the attribute names they use
for the cachename are the same in LDAP, so you could just use:
ldap_user_extra_attrs = mail, sn, givenname, telephonenumber

(Unless they also reversed the order of attrs..)
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Use IPA AD users in keycloak

[Jakub Hrozek via FreeIPA-users]

On Mon, Aug 26, 2019 at 09:19:36AM +0200, Ronald Wimmer via FreeIPA-users wrote:
> On 23.08.19 20:18, Jakub Hrozek via FreeIPA-users wrote:
> > [...]
> > Wait, do they really map all these attributes to mail? This seems wrong,
> > the format is externalname:ldapname and IIRC the last one wins, so the last
> > one is applied and stores mail as telephoneNumber.
> 
> Sorry. I pasted a config snippet we used to try if somthing would be mapped.
> (because mail attribute was mapped and the others not)

So how did the original config look like?

> 
> Why is the mail attribute mapped by default (without defining anything in
> sssd.conf) and the other attributes are not?

Sorry, it's not totally clear to me if all the attributes were mapped to
mail by the KC installer or by your snippet?

Does everything work if you remove the mappings?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Use IPA AD users in keycloak

[Jakub Hrozek via FreeIPA-users]

On Mon, Aug 26, 2019 at 02:17:29PM +0200, Ronald Wimmer via FreeIPA-users wrote:
> On 26.08.19 09:26, Jakub Hrozek via FreeIPA-users wrote:
> > [...]
> > Sorry, it's not totally clear to me if all the attributes were mapped to
> > mail by the KC installer or by your snippet?
> 
> The original config looked like it should after executing keycloak's
> federation-sssd-setup.sh:
> 
> [domain section]
> ldap_user_extra_attrs = mail:mail, sn:sn, givenname:givenname,
> telephoneNumber:telephoneNumber
> 
> [ifp]
> user_attributes = +mail, +telephoneNumber, +givenname, +sn

OK, this is what I would have expected. Is it possible to enable
debugging and run the KC operation to see exactly what is being looked
up and what fails?

> 
> > Does everything work if you remove the mappings?
> 
> Unfortunately not. Only "mail" is mapped for an AD user. The other three
> attributes are not.
> 
> Cheers,
> Ronald
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Use IPA AD users in keycloak

[Jakub Hrozek via FreeIPA-users]

On Wed, Aug 28, 2019 at 12:29:14PM +0200, Ronald Wimmer via FreeIPA-users wrote:
> On 28.08.19 08:39, Jakub Hrozek via FreeIPA-users wrote:
> > [...]
> > OK, this is what I would have expected. Is it possible to enable
> > debugging and run the KC operation to see exactly what is being looked
> > up and what fails?
> 
> (Tue Aug 20 14:09:37 2019) [sssd[ifp]] [ifp_add_ldb_el_to_dict] (0x0400):
> element [mail] has value [ronald.wim...@mydomain.at]
> (Tue Aug 20 14:09:37 2019) [sssd[ifp]] [ifp_user_get_attr_handle_reply]
> (0x0080): Attribute givenname not present or has no values
> (Tue Aug 20 14:09:37 2019) [sssd[ifp]] [ifp_user_get_attr_handle_reply]
> (0x0080): Attribute sn not present or has no values
> (Tue Aug 20 14:09:37 2019) [sssd[ifp]] [ifp_user_get_attr_handle_reply]
> (0x0080): Attribute telephoneNumber not present or has no values
> 
> This shows up in the logs without further configuration (no additional
> configuration on the IPA servers themselves). Why is the mail attribute
> showing up but the others do not?

Apparently then are not defined on the server side. btw is
ronald.wim...@mydomain.at a user in the trusted domain or the IPA
domain?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: /var/lib/sss/pubconf/known_hosts empty

[Jakub Hrozek via FreeIPA-users]

On Wed, Oct 09, 2019 at 12:25:33AM +, Vinícius Ferrão via FreeIPA-users 
wrote:
> Hello,
> 
> The /var/lib/sss/pubconf/known_hosts file is empty on a new installed FreeIPA 
> server. I’ve already joined a machine to the domain but the file is still 
> empty.
> 
> I can’t get it populated, already rebooted and/or restarted sssd without 
> success.
> 
> Looking on the web I came across this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1574778
> 
> It is Fedora related, but it’s the same version that I’m running, since I’m 
> on CentOS 7.6.
> 
> How can I check if is in fact this bug?
> 
> Here are some errors on sssd_ssh with debug_level = 9 enabled:
> 
> ==> /var/log/sssd/sssd_ssh.log <==
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [sbus_remove_timeout] (0x2000): 
> 0x55b758c55dc0
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [sbus_dispatch] (0x4000): dbus conn: 
> 0x55b758c56e10
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [sbus_dispatch] (0x4000): Dispatching.
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [sss_dp_get_reply] (0x1000): Got reply 
> from Data Provider - DP error code: 3 errno: 22 error message: Invalid 
> argument
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [cache_req_common_dp_recv] (0x0040): 
> CR #2: Data Provider Error: 3, 22, Invalid argument
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [cache_req_common_dp_recv] (0x0400): 
> CR #2: Due to an error we will return cached data
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [cache_req_search_cache] (0x0400): CR 
> #2: Looking up [hpclab01] in cache
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Added timed event 
> "ltdb_callback": 0x55b758c62d50
> 
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Added timed event 
> "ltdb_timeout": 0x55b758c62e10
> 
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Running timer event 
> 0x55b758c62d50 "ltdb_callback"
> 
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Destroying timer event 
> 0x55b758c62e10 "ltdb_timeout"
> 
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Ending timer event 
> 0x55b758c62d50 "ltdb_callback"
> 
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [sysdb_search_ssh_hosts] (0x0400): No 
> such host
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [cache_req_search_cache] (0x0400): CR 
> #2: Object [hpclab01] was not found in cache
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [cache_req_process_result] (0x0400): 
> CR #2: Finished: Not found
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Added timed event 
> "ltdb_callback": 0x55b758c60990
> 
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Added timed event 
> "ltdb_timeout": 0x55b758c63960
> 
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Running timer event 
> 0x55b758c60990 "ltdb_callback"
> 
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Destroying timer event 
> 0x55b758c63960 "ltdb_timeout"
> 
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Ending timer event 
> 0x55b758c60990 "ltdb_callback"
> 
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [sysdb_search_ssh_hosts] (0x0400): No 
> such host
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [unique_filename_destructor] (0x2000): 
> Unlinking [/var/lib/sss/pubconf/.known_hosts.yfSd2J]
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [unlink_dbg] (0x2000): File already 
> removed: [/var/lib/sss/pubconf/.known_hosts.yfSd2J]
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [ssh_protocol_done] (0x4000): Sending 
> reply: error [2]: No such file or directory
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [sss_dp_req_destructor] (0x0400): 
> Deleting request: 
> [0x55b7572d88e0:hpclab01:hpcla...@cluster.iq.ufrj.br]
> 
> ==> /var/log/sssd/sssd_cluster.iq.ufrj.br.log <==

Can you also enable debug_level for the domain to see why is sssd_be
replying with Invalid Argument?

> 
> ==> /var/log/sssd/sssd_ssh.log <==
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [client_recv] (0x0200): Client 
> disconnected!
> (Tue Oct  8 21:10:37 2019) [sssd[ssh]] [client_close_fn] (0x2000): Terminated 
> client [0x55b758c4f940][18]
> 
> 
> 
> 
> Installed versions:
> 
> [root@headnode ~]# rpm -qa | grep -i sssd
> sssd-client-1.16.4-21.el7.x86_64
> sssd-ldap-1.16.4-21.el7.x86_64
> sssd-common-pac-1.16.4-21.el7.x86_64
> sssd-dbus-1.16.4-21.el7.x86_64
> sssd-ipa-1.16.4-21.el7.x86_64
> sssd-proxy-1.16.4-21.el7.x86_64
> sssd-common-1.16.4-21.el7.x86_64
> sssd-ad-1.16.4-21.el7.x86_64
> python-sssdconfig-1.16.4-21.el7.noarch
> sssd-krb5-common-1.16.4-21.el7.x86_64
> sssd-1.16.4-21.el7.x86_64
> sssd-krb5-1.16.4-21.el7.x86_64
> 
> 
> Thanks,
> 
> 

> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/lis

[Freeipa-users] Re: Ipa user can't login via ssh

[Jakub Hrozek via FreeIPA-users]

On Wed, Oct 09, 2019 at 08:45:16AM -, Elhamsadat Azarian via FreeIPA-users 
wrote:
> ### Request for enhancement
> as a Linux admin i want to login into my ipa client with a user that is 
> defined in ipa-server UI.
> 
> ### Issue
> I installed Ipa-server and an Ipa-client on CentOS7.6
> I defined Internal DNS on ipa-server and i defined A and PTR records for 
> client on ipa-server.
> now i can see my client in ipa-UI and i defined a user with name "elham" and 
> i expect that it can login into ipa-client.
> when i login with root in ipa-client and i do sudo elham, it works and kinit 
> elham works too but
> when i do ssh into ipa-client with this user, it show "Access denied"
> i have errors with this context:
> pam_reply : authentication failure to the client
> pam_sss: authentication falure
> 
> im tired of this issue. please help me if you know the solution.

Please start here:
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
> 
>  Steps to Reproduce
> 1. define new user "elham" in ipa UI
> 2. SSH to ipa-client with elham
> 3. access denied
> 
>  Actual behavior
> (what happens)
> 
>  Expected behavior
> login into ipa-client successfully
> 
>  Version/Release/Distribution
>ipa-server 4.6.5-11.el7
>ipa-client 4.6.4-10.el7.centos.3
> Log files and config files are added below:
> 
> 
> 
> krb5.conf
> 
> #File modified by ipa-client-install
> 
> includedir /etc/krb5.conf.d/
> includedir /var/lib/sss/pubconf/krb5.include.d/
> 
> 
> [logging]
> default = FILE:/var/log/krb5libs.log
> kdc = FILE:/var/log/krb5kdc.log
> admin_server = FILE:/var/log/kadmind.log
> [libdefaults]
> default_realm = LSHS.DC
> dns_lookup_realm = false
> dns_lookup_kdc = false
> rdns = false
> ticket_lifetime = 24h
> forwardable = yes
> allow_weak_crypto = true
> default_ccache_name = KEYRING:persistent:%{uid}
> 
> [realms]
> LSHS.DC = {
> kdc = ipa-irvlt01.example.dc:88
> admin_server = ipa-irvlt01.example.dc:749
> default_domain = example.dc
> }
> [domain_realm]
> .example.com = LSHS.DC
> example.com = LSHS.DC
> 
> 
> 
> sssd.conf
> -
> [domain/example.dc]
> 
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = example.dc
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ldap_tls_cacert = /etc/ipa/ca.crt
> ipa_hostname = ipacli-irvlt01.example.dc
> chpass_provider = ipa
> dyndns_update = True
> ipa_server = _srv_, ipa-irvlt01.example.dc
> dyndns_iface = ens160
> dns_discovery_domain = example.dc
> 
> debug_level = 10
> [sssd]
> ### AFTER IPA ###
> #services = nss, sudo, pam, ssh
> services = nss, pam
> config_file_version = 2
> #
> domains = example.dc
> 
> debug_level = 10
> [nss]
> homedir_substring = /home
> 
> [pam]
> debug_level = 10
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> [pac]
> 
> [ifp]
> 
> [secrets]
> 
> [session_recording]
> 
> ##
> 
> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: [Freeipa-users]SSH Key replication time/issues

[Jakub Hrozek via FreeIPA-users]

On Tue, May 30, 2017 at 02:18:18PM -0400, Jake via FreeIPA-users wrote:
> Looks like this is applied immediately, but required a service sssd restart; 
> sss_cache -E 

This shouldn't be the case, can you describe step-by-step what exactly
are you doing, what are the unexpected results and what do you expect to
see?

> 
> Do these attributes have a TTL set? 
> 
> I know these are all SSSD Specific questions, and not directly related to 
> FreeIPA. 
> 
> Thanks, 
> Jake 
> 
> 
> From: "freeipa-users"  
> To: "freeipa-users"  
> Cc: "Jake"  
> Sent: Tuesday, May 30, 2017 1:15:32 PM 
> Subject: [Freeipa-users]SSH Key replication time/issues 
> 
> Hey again, 
> I'm trying to track down how to ensure ssh keys are added AND removed 
> quickly. 
> 
> Right now it seems I must restart ipa services or sss_cache -E to force them 
> to update, and there doesn't seem to be a determinate amount of time to allow 
> replication. 
> 
> Note, SSH keys are stored in the "Default View" for external users (external 
> one-way trust with AD). 
> 
> Thanks, 
> -Jake 
> 
> ___ 
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org 
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 

> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Compat tree question

[Jakub Hrozek via FreeIPA-users]

On Tue, May 30, 2017 at 09:27:05PM +0300, Alexander Bokovoy via FreeIPA-users 
wrote:
> On ti, 30 touko 2017, Robert Johnson via FreeIPA-users wrote:
> > So I took a brand new user that I have never used in the system before (I
> > checked that the entry was not in the compat tree) and just ran an "id"
> > command on Solaris system.  I then looked in the /var/log/dirsrv/slapd- > domain>/access log file on the ipa server, for the query and from the log
> > file, the query came in as all caps.
> > 
> > example:
> > [~]$: id 831...@win.mydomin.com
> > 
> > [~]$: cat /var/log/dirsrv/slapd-/access |grep 831413
> > [30/May/2017:13:34:38.637498942 -0400] conn=94124 op=622 SRCH
> > base="cn=users,cn=compat,dc=ipa,dc=mydomain,dc=com" scope=1
> > filter="(&(objectClass=posixAccount)(uid=831...@win.mydomin.com))"
> > attrs="cn uid uidNumber gidNumber gecos description homeDirectory
> > loginShell"
> > [30/May/2017:13:34:38.651811322 -0400] conn=94124 op=622 RESULT err=0
> > tag=101 nentries=1 etime=0
> > 
> > However, the entry in the compat tree is all lowercase just like I
> > reported.  I can reproduce this easily.
> memberUid value comes from SSSD look up. SSSD normalizes all names to
> low case.
> 
> For group names, I'm not sure they are normalized, though.

with id_provider=ad (which is what is running under the hood of the
sssd-on-idm-masters) everything should be normalized and there shouldn't
even be an option to turn the normalization off.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ipa-client-install combined with 'authconfig --enablenis --update'

[Jakub Hrozek via FreeIPA-users]

On Wed, May 31, 2017 at 10:18:46AM -, paul--- via FreeIPA-users wrote:
> Hi,
> I have boot problem when i combine a ipa-client-install with 'authconfig 
> --enablenis --update'
> According to the ovirt/RHEV docs [1] I have to do this to make SSO to the VM 
> possible.
> 
> Messages during boot are:
> Failed to start RealtimeKit for Policy Services
> Failed to start Authorization Manager
> Dependency failed for Dynamic System tuning deamon
> 
> My setup is:
> All systems Centos 7.3(1611)
> oVirt 4.1
> IPA server 4.4
> IPA client 4.4
> 
> If i use an old VM with Centos 7.2(1511) and ipa-client 4.2 there are no 
> problems and SSO is working so oVirt and IPA seem to be configured correct.
> 
> My findings so far:
> - Centos 7.3 does not include ypbind. If i install manually it sometimes 
> boots (but takes a long time) but the other times stops at same point as 
> mentioned before. This could imply some kind of race condition during boot.

Please note that the --enablenis switch has (confusingly) not much to do
with NIS. It 'just' configures the PAM stack so that the options are a
bit different and the password is passed through to pam_sss.

What you are really hitting is
https://bugzilla.redhat.com/show_bug.cgi?id=1327085

which will be fixed in 7.4.

But I'm not sure why wouldn't the workaround work. Installing ypbind is
definitely not the right thing to do and it's actually what causes the
issues during boot. The problem is really in the PAM stack.

If you don't install ypbind, but run the workaround, is there anything
in /var/log/secure coming from gdm-ovirtcred?

> - I tried different versions of ipa-client 
> (ipa-client-4.4.0-12.el7.centos.x86_64 up to 
> ipa-client-4.4.0-14.el7.centos.7.x86_64) none worked. Older versions i could 
> not find anymore.
> 
> Can anyone comfirm my findings or point me in some direction?
> 
> Kind regards,
> 
> Paul
> 
> 
> [1]https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/virtual_machine_management_guide/chap-additional_configuration#sect-Configuring_Single_Sign-On_for_Virtual_Machines
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Get rid of manually calling kinit with SSSD

[Jakub Hrozek via FreeIPA-users]

On Wed, May 31, 2017 at 02:36:58PM +0200, Ronald Wimmer via FreeIPA-users wrote:
> On 2017-05-31 13:25, Sumit Bose via FreeIPA-users wrote:
> > On Wed, May 31, 2017 at 11:24:48AM +0200, Ronald Wimmer via FreeIPA-users 
> > wrote:
> > > Hi,
> > > 
> > > I read Jakub Hrozeks post 
> > > https://jhrozek.wordpress.com/2015/07/17/get-rid-of-calling-manually-calling-kinit-with-sssds-help/
> > > and found that it is exactly what I need. The only problem is that I am
> > > using Ubuntu and not Fedora or CentOS.
> > > 
> > > In sssd_pamlog i only see a SSS_PAM_OPEN_SESSION but no 
> > > SSS_PAM_AUTHENTICATE
> > 
> > This would mean that pam_unix authenticated the user. Does the user
> > exists in /etc/passwd and /etc/shadow as well?
> 
> Of course. My local user exists in both files.

Did you use the local password or the remote password? Are they the same
or different?

> 
> sssd_pam.log shows 4 times SSS_PAM_OPEN_SESSION
> 1) User: lightdm
> 2) User: ligh...@my.domain.at
> 3) User: mylocaluser
> 4) User: mylocalu...@my.domain.at
> 
> Number 4 ist the most promising but mylocaluser should be
> myadu...@my.domain.at. Here's the log:
> 
> (Tue Apr 25 13:17:01 2017) [sssd[pam]] [pam_print_data] (0x0100): command:
> SSS_PAM_OPEN_SESSION
> (Tue Apr 25 13:17:01 2017) [sssd[pam]] [pam_print_data] (0x0100): domain:
> my.domain.at
> (Tue Apr 25 13:17:01 2017) [sssd[pam]] [pam_print_data] (0x0100): user:
> mylocalu...@my.domain.at
> (Tue Apr 25 13:17:01 2017) [sssd[pam]] [pam_print_data] (0x0100): service:
> lightdm
> (Tue Apr 25 13:17:01 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: :0
> (Tue Apr 25 13:17:01 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not
> set
> (Tue Apr 25 13:17:01 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: not
> set
> (Tue Apr 25 13:17:01 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok
> type: 0
> (Tue Apr 25 13:17:01 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok
> type: 0
> (Tue Apr 25 13:17:01 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
> (Tue Apr 25 13:17:01 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid:
> 2538
> (Tue Apr 25 13:17:01 2017) [sssd[pam]] [pam_print_data] (0x0100): logon
> name: mylocaluser
> (Tue Apr 25 13:17:01 2017) [sssd[pam]] [sbus_add_timeout] (0x2000):
> 0x55e6c039fa20
> (Tue Apr 25 13:17:01 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100):
> pam_dp_send_req returned 0
> (Tue Apr 25 13:17:01 2017) [sssd[pam]] [sss_dp_req_destructor] (0x0400):
> Deleting request: [0x55e6be26eea0:3:mylocalu...@my.domain.at@my.domain.at]
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ipa-client-install combined with 'authconfig --enablenis --update'

[Jakub Hrozek via FreeIPA-users]

On Wed, May 31, 2017 at 08:56:44PM -, paul--- via FreeIPA-users wrote:
> Hi Jakub,
> Thanks for clearing this out and pointing out ypbind is the wrong direction.
> What do you mean with 'the workaround'? Do mean use of 'authconfig 
> --enablenis --update'?
> The combination of Centos 7.3 with ipa-client 4.4 and that workaround results 
> in a hanging boot with the following errors and no login:
> Failed to start RealtimeKit for Policy Services 
> Failed to start Authorization Manager 
> Dependency failed for Dynamic System tuning deamon
> Failed to start Login Service
> Failed to start GNOME display Manager
> Starting terminate Plymouth boot screen
> 
> SSH works (but very slow login after 20 minutes) with the following content 
> of /var/log/secure:
> May 31 22:25:26 ad02 userhelper[15096]: 
> pam_succeed_if(ovirt-container-list:auth): requirement "user = ovirtagent" 
> was met by user "ovirtagent"
> May 31 22:25:26 ad02 userhelper[15096]: running 
> '/usr/share/ovirt-guest-agent/container-list' with root privileges on behalf 
> of 'ovirtagent'
> May 31 22:30:54 ad02 userhelper[688]: 
> pam_succeed_if(ovirt-container-list:auth): requirement "user = ovirtagent" 
> was met by user "ovirtagent"
> May 31 22:31:54 ad02 userhelper[688]: running 
> '/usr/share/ovirt-guest-agent/container-list' with root privileges on behalf 
> of 'ovirtagent'
> May 31 22:34:03 ad02 userhelper[695]: 
> pam_succeed_if(ovirt-container-list:auth): requirement "user = ovirtagent" 
> was met by user "ovirtagent"
> May 31 22:35:04 ad02 userhelper[695]: running 
> '/usr/share/ovirt-guest-agent/container-list' with root privileges on behalf 
> of 'ovirtagent'
> May 31 22:35:54 ad02 userhelper[707]: 
> pam_succeed_if(ovirt-container-list:auth): requirement "user = ovirtagent" 
> was met by user "ovirtagent"
> May 31 22:36:54 ad02 userhelper[707]: running 
> '/usr/share/ovirt-guest-agent/container-list' with root privileges on behalf 
> of 'ovirtagent'
> May 31 22:37:04 ad02 userhelper[708]: pam_succeed_if(diskmapper:auth): 
> requirement "user = ovirtagent" was met by user "ovirtagent"
> May 31 22:38:04 ad02 userhelper[708]: running 
> '/usr/share/ovirt-guest-agent/diskmapper.script' with root privileges on 
> behalf of 'ovirtagent'
> May 31 22:42:03 ad02 userhelper[722]: pam_succeed_if(ovirt-locksession:auth): 
> requirement "user = ovirtagent" was met by user "ovirtagent"
> May 31 22:42:54 ad02 userhelper[730]: 
> pam_succeed_if(ovirt-container-list:auth): requirement "user = ovirtagent" 
> was met by user "ovirtagent"
> May 31 22:43:03 ad02 userhelper[722]: running 
> '/usr/share/ovirt-guest-agent/LockActiveSession.py' with root privileges on 
> behalf of 'ovirtagent'
> May 31 22:43:51 ad02 userhelper[730]: running 
> '/usr/share/ovirt-guest-agent/container-list' with root privileges on behalf 
> of 'ovirtagent'
> May 31 22:44:51 ad02 userhelper[841]: pam_succeed_if(diskmapper:auth): 
> requirement "user = ovirtagent" was met by user "ovirtagent"
> May 31 22:44:51 ad02 userhelper[841]: running 
> '/usr/share/ovirt-guest-agent/diskmapper.script' with root privileges on 
> behalf of 'ovirtagent'
> May 31 22:45:51 ad02 userhelper[905]: 
> pam_succeed_if(ovirt-container-list:auth): requirement "user = ovirtagent" 
> was met by user "ovirtagent"
> May 31 22:45:51 ad02 userhelper[905]: running 
> '/usr/share/ovirt-guest-agent/container-list' with root privileges on behalf 
> of 'ovirtagent'
> May 31 22:47:51 ad02 userhelper[1138]: 
> pam_succeed_if(ovirt-container-list:auth): requirement "user = ovirtagent" 
> was met by user "ovirtagent"
> May 31 22:47:51 ad02 userhelper[1138]: running 
> '/usr/share/ovirt-guest-agent/container-list' with root privileges on behalf 
> of 'ovirtagent'
> May 31 22:48:22 ad02 sshd[1148]: Server listening on 0.0.0.0 port 22.
> May 31 22:48:22 ad02 sshd[1148]: Server listening on :: port 22.
> May 31 22:49:52 ad02 userhelper[2369]: 
> pam_succeed_if(ovirt-container-list:auth): requirement "user = ovirtagent" 
> was met by user "ovirtagent"
> May 31 22:49:52 ad02 userhelper[2369]: running 
> '/usr/share/ovirt-guest-agent/container-list' with root privileges on behalf 
> of 'ovirtagent'
> May 31 22:49:52 ad02 userhelper[2370]: pam_succeed_if(diskmapper:auth): 
> requirement "user = ovirtagent" was met by user "ovirtagent"
> May 31 22:49:52 ad02 userhelper[2370]: running 
> '/usr/share/ovirt-guest-agent/diskmapper.script' with root privileges on 
> behalf of 'ovirtagent'
> May 31 22:50:42 ad02 sshd[2392]: Accepted keyboard-interactive/pam for root 
> from 10.0.2.65 port 34866 ssh2
> May 31 22:51:08 ad02 sshd[2392]: pam_systemd(sshd:session): Failed to create 
> session: Activation of org.freedesktop.login1 timed out
> May 31 22:51:08 ad02 sshd[2392]: pam_unix(sshd:session): session opened for 
> user root by (uid=0)

I admit I'm getting a bit out of my depth, because I've actually never
tried this myself, only debugged on IRC with the engineer who hit the
issue first with RHEV-M. But these messages make it look 

[Freeipa-users] Re: [Freeipa-users]Re: [Freeipa-users]SSH Key replication time/issues

[Jakub Hrozek via FreeIPA-users]

On Wed, May 31, 2017 at 10:32:32AM -0400, Jake via FreeIPA-users wrote:
> Jakub/Sumit,
> 
> I'm using /usr/bin/sss_ssh_authorizedkeys to check keys as ssh access is my 
> primary concern. In my recent tests I changed the key listed on the local 
> upstream server from the server line in /etc/ipa/default.conf and the ssh-key 
> showed up after 8 minutes, remote servers (replica ipa servers) took another 
> 30 minutes.
> 
> Same process to delete the key, took 45 minutes from local change to remote 
> server via replica (deleted at 9:52, refreshed at 10:30) which makes me think 
> it's more the ldap replication over sss cache.
> 
> entry_cache_timeout is the default 5400 seconds (and it's children follow 
> that value)

Please note that since the cache expiration times are stored in the
cache, you should call sss_cache -E after changing the timeouts or nuke
the .ldb files completely.

> 
> I assume if I want/need this to expire/replicate faster, I would want to set 
> entry_cache_user_timeout to a value closer to a few minutes (300-900), can 
> you see any drawbacks to this?

Just more frequent LDAP lookups.

> 
> Is this value required on Server, Clients, Both.
> 
> As always, you guys are excellent and I really appreciate all the help!
> 
> Thanks,
> -Jacob
> 
> 
> - Original Message -
> From: "freeipa-users" 
> To: "freeipa-users" 
> Cc: "Sumit Bose" 
> Sent: Wednesday, May 31, 2017 5:01:22 AM
> Subject: [Freeipa-users]Re: [Freeipa-users]SSH Key replication time/issues
> 
> On Tue, May 30, 2017 at 02:18:18PM -0400, Jake via FreeIPA-users wrote:
> > Looks like this is applied immediately, but required a service sssd 
> > restart; sss_cache -E 
> > 
> > Do these attributes have a TTL set? 
> > 
> > I know these are all SSSD Specific questions, and not directly related to 
> > FreeIPA. 
> 
> The keys are stored in the SSSD cache and the cache objects have a
> lifetime. Please check entry_cache_timeout or entry_cache_user_timeout
> in man sssd.conf for details.
> 
> HTH
> 
> bye,
> Sumit
> 
> > 
> > Thanks, 
> > Jake 
> > 
> > 
> > From: "freeipa-users"  
> > To: "freeipa-users"  
> > Cc: "Jake"  
> > Sent: Tuesday, May 30, 2017 1:15:32 PM 
> > Subject: [Freeipa-users]SSH Key replication time/issues 
> > 
> > Hey again, 
> > I'm trying to track down how to ensure ssh keys are added AND removed 
> > quickly. 
> > 
> > Right now it seems I must restart ipa services or sss_cache -E to force 
> > them to update, and there doesn't seem to be a determinate amount of time 
> > to allow replication. 
> > 
> > Note, SSH keys are stored in the "Default View" for external users 
> > (external one-way trust with AD). 
> > 
> > Thanks, 
> > -Jake 
> > 
> > ___ 
> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org 
> > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 
> 
> > ___
> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Scripting a SSSD client to add SID to UIDnumbers from ad Trust into custom LDAP schema.

[Jakub Hrozek via FreeIPA-users]

On Fri, Jun 02, 2017 at 02:05:34PM -0600, Frank Rey via FreeIPA-users wrote:
> I have a Netapp that does not support SSSD or Windbind and i want to use
> IDM ldap to do permission/name mapping. 

I'm not sure I understand the problem, is the issue that the netapp only
supports plain LDAP? Would it then be possible to point it at the compat
tree?

> would using a Script on a SSSD
> client to populate a custom ldap schema in IPA with the SSSD uidnumber
> mappings be a bad idea? I know i would have to set up a cron job to run it
> at a reasonable interval. set it up to create and remove users added or
> removed from the Posix group i have mapped from the AD trust.
> 
> Ray

> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Access issues with SSH/IPA

[Jakub Hrozek via FreeIPA-users]

On Thu, Jun 15, 2017 at 04:28:13AM -, john.bowman--- via FreeIPA-users 
wrote:
> After upping the log levels on sssd on one of the failing servers I saw this 
> in one of the sssd log files:
> 
> from sssd_pamd.log:
> 
> (Wed Jun 14 23:16:05 2017) [sssd[pam]] [sss_ncache_check_str] (0x2000): 
> Checking negative cache for [NCE/USER/domain.tld/jbowman]
> (Wed Jun 14 23:16:05 2017) [sssd[pam]] [sss_dp_issue_request] (0x0400): 
> Issuing request for [0x41b5c0:3:jbow...@domain.tld]
> (Wed Jun 14 23:16:05 2017) [sssd[pam]] [sss_dp_get_account_msg] (0x0400): 
> Creating request for [domain.tld][3][1][name=jbowman]
> (Wed Jun 14 23:16:05 2017) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x20ef8a0
> (Wed Jun 14 23:16:05 2017) [sssd[pam]] [sss_dp_internal_get_send] (0x0400): 
> Entering request [0x41b5c0:3:jbow...@domain.tld]
> (Wed Jun 14 23:16:05 2017) [sssd[pam]] [sbus_remove_timeout] (0x2000): 
> 0x20ef8a0
> (Wed Jun 14 23:16:05 2017) [sssd[pam]] [sss_dp_get_reply] (0x1000): Got reply 
> from Data Provider - DP error code: 3 errno: 22 error message: Init Groups 
> Failed
> (Wed Jun 14 23:16:05 2017) [sssd[pam]] [pam_check_user_dp_callback] (0x0040): 
> Unable to get information from Data Provider
> Error: 3, 22, Init Groups Failed
> 
> 
> from sssd_domain.tld.log
> (Wed Jun 14 22:55:37 2017) [sssd[be[domain.tld]]] [hbac_eval_user_element] 
> (0x0080): Parse error on [cn=system: manage service 
> principals+nsuniqueid=e8d2f834-512111e7-9205b5bf-43202000,cn=permissions,cn=pbac,dc=domain,dc=tld]

Yes, only recent vresions of sssd can skip over the replication
conflicts. I would recommend to clear the conflicts manually.

> (Wed Jun 14 22:55:37 2017) [sssd[be[domain.tld]]] [hbac_ctx_to_rules] 
> (0x0020): Could not construct eval request
> (Wed Jun 14 22:55:37 2017) [sssd[be[domain.tld]]] [ipa_hbac_evaluate_rules] 
> (0x0020): Could not construct HBAC rules
> (Wed Jun 14 22:55:37 2017) [sssd[be[domain.tld]]] [sdap_id_op_destroy] 
> (0x4000): releasing operation connection
> (Wed Jun 14 22:55:37 2017) [sssd[be[domain.tld]]] [be_pam_handler_callback] 
> (0x0100): Backend returned: (3, 4, ) [Internal Error (System error)]
> (Wed Jun 14 22:55:37 2017) [sssd[be[domain.tld]]] [be_pam_handler_callback] 
> (0x0100): Sending result [4][domain.tld]
> (Wed Jun 14 22:55:37 2017) [sssd[be[domainn.tld]]] [be_pam_handler_callback] 
> (0x0100): Sent result [4][domain.tld]
> (Wed Jun 14 22:55:37 2017) [sssd[be[domain.tld]]] [sdap_process_result] 
> (0x2000): Trace: sh[0x7ea6b0], connected[1], ops[(nil)], ldap[0x844de0]
> (Wed Jun 14 22:55:37 2017) [sssd[be[domain.tld]]] [sdap_process_result] 
> (0x2000): Trace: ldap_result found nothing!
> (Wed Jun 14 22:55:38 2017) [sssd[be[domain.tld]]] [sbus_dispatch] (0x4000): 
> dbus conn: 7B2A00
> (Wed Jun 14 22:55:38 2017) [sssd[be[domain.tld]]] [sbus_dispatch] (0x4000): 
> Dispatching.
> (Wed Jun 14 22:55:38 2017) [sssd[be[domain.tld]]] [sbus_message_handler] 
> (0x4000): Received SBUS method [ping]
> 
> I saw a similar issue in a previous posting to the list:  
> https://www.redhat.com/archives/freeipa-users/2017-January/msg00286.html
> 
> I was wondering if these errors might be related to the issues I'm seeing 
> currently since they seem very similar so far...
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Access issues with SSH/IPA

[Jakub Hrozek via FreeIPA-users]

On Thu, Jun 15, 2017 at 01:07:27PM -, john.bowman--- via FreeIPA-users 
wrote:
> You'll have to forgive my ignorance here since I'm still fairly new to IPA 
> and fortunately haven't run in to many issues as of yet. 
> 
> The three IPA 3.0 servers all have what look to be following conflicts:
> 
> $ ldapsearch -D "cn=directory manager" -w secret -b "dc=domain,dc=tld" 
> "nsds5ReplConflict=*" \* nsds5ReplConflict | grep nsds5ReplConflict
> # filter: nsds5ReplConflict=*
> # requesting: * nsds5ReplConflict
> nsds5ReplConflict: namingConflict cn=ipa4-4.domain.tld,cn=masters,cn=ipa,cn
> nsds5ReplConflict: namingConflict dnahostname=ipa4-4.domain.tld+dnaportnum=
> nsds5ReplConflict: namingConflict cn=ipaservers,cn=hostgroups,cn=accounts,dc=z
> nsds5ReplConflict: namingConflict cn=ipaservers,cn=ng,cn=alt,dc=domain,dc=tld
> nsds5ReplConflict: namingConflict 
> cn=domain,cn=topology,cn=ipa,cn=etc,dc=domain,
> nsds5ReplConflict: namingConflict cn=locations,cn=etc,dc=domain,dc=tld
> nsds5ReplConflict: namingConflict cn=dns administrators,cn=privileges,cn=pbac,
> nsds5ReplConflict: namingConflict cn=dns 
> servers,cn=privileges,cn=pbac,dc=domain
> nsds5ReplConflict: namingConflict cn=cas,cn=ca,dc=domain,dc=tld
> nsds5ReplConflict: namingConflict 
> cn=dogtag,cn=custodia,cn=ipa,cn=etc,dc=domain,
> nsds5ReplConflict: namingConflict 
> cn=ca,cn=topology,cn=ipa,cn=etc,dc=domain,dc=u
> nsds5ReplConflict: namingConflict cn=system: add ca,cn=permissions,cn=pbac,dc=
> nsds5ReplConflict: namingConflict cn=system: delete ca,cn=permissions,cn=pbac,
> nsds5ReplConflict: namingConflict cn=system: modify ca,cn=permissions,cn=pbac,
> nsds5ReplConflict: namingConflict cn=system: read cas,cn=permissions,cn=pbac,d
> nsds5ReplConflict: namingConflict cn=system: modify dns servers configuration,
> nsds5ReplConflict: namingConflict cn=system: read dns servers configuration,cn
> nsds5ReplConflict: namingConflict cn=system: add ipa locations,cn=permissions,
> nsds5ReplConflict: namingConflict cn=system: modify ipa locations,cn=permissio
> nsds5ReplConflict: namingConflict cn=system: read ipa locations,cn=permissions
> nsds5ReplConflict: namingConflict cn=system: remove ipa locations,cn=permissio
> nsds5ReplConflict: namingConflict cn=system: read locations of ipa servers,cn=
> nsds5ReplConflict: namingConflict cn=system: read status of services on ipa se
> nsds5ReplConflict: namingConflict cn=system: manage service principals,cn=perm
> nsds5ReplConflict: namingConflict cn=system: manage user principals,cn=permiss
> nsds5ReplConflict: namingConflict dnahostname=ipa4-4.domain.tld+dnaportnum=
> 
> While the IPA 4.4 server shows no conflicts:
> $ ldapsearch -D "cn=directory manager" -w secret -b "dc=domain,dc=tld" 
> "nsds5ReplConflict=*" \* nsds5ReplConflict | grep nsds5ReplConflict
> # filter: nsds5ReplConflict=*
> # requesting: * nsds5ReplConflict

Depends on whether you need to keep the data on the v3 machine and
whether the data on the v4 machine is correct...

But the general guide to managing replication conflicts is:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html

> 
> So I would need to delete/modify the conflicts on the IPA 3.0 servers but the 
> IPA 4.4 server should be okay, correct?  Is there any impact to running the 
> ldapmodify command to remove these conflicts while services are running?  
> Would I need to do this on each of the IPA 3.x servers?
> 
> Looking at one of the conflicts on one of the IPA 3.0:
> $ ldapsearch -D "cn=directory manager" -w secret -b "dc=domain,dc=tld" 
> "cn=domain"
> # extended LDIF
> #
> # LDAPv3
> # base  with scope subtree
> # filter: cn=domain
> # requesting: ALL
> #
> 
> # domain, topology, ipa, etc, domain.us
> dn: cn=domain,cn=topology,cn=ipa,cn=etc,dc=domain,dc=tld
> cn: domain
> nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial
>   entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
> nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts
>  uccessfulauth krblastfailedauth krbloginfailedcount
> objectClass: top
> objectClass: iparepltopoconf
> ipaReplTopoConfRoot: dc=domain,dc=tld
> nsds5ReplicaStripAttrs: modifiersName modifyTimestamp internalModifiersName in
>  ternalModifyTimestamp
> 
> # domain + e8d2f70e-512111e7-9205b5bf-43202000, topology, ipa, etc, domain.us
> dn: cn=domain+nsuniqueid=e8d2f70e-512111e7-9205b5bf-43202000,cn=topology,cn=ip
>  a,cn=etc,dc=domain,dc=tld
> nsds5ReplicaStripAttrs: modifiersName modifyTimestamp internalModifiersName in
>  ternalModifyTimestamp
> ipaReplTopoConfRoot: dc=domain,dc=tld
> objectClass: top
> objectClass: iparepltopoconf
> nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts
>  uccessfulauth krblastfailedauth krbloginfailedcount
> nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial
>   entryusn krblastsuccessfulauth krblastfailedauth krb

[Freeipa-users] Re: Access issues with SSH/IPA

[Jakub Hrozek via FreeIPA-users]

On Thu, Jun 15, 2017 at 05:15:41PM -, john.bowman--- via FreeIPA-users 
wrote:
> Which path would be better?  Upgrading sssd on the older machines or 
> attempting to delete the ldap entries?   

I think you want to fix the server side, upgrading sssd is just a quick
kludge to let you access the systems.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: (no subject)

[Jakub Hrozek via FreeIPA-users]

On Wed, Jun 28, 2017 at 07:04:58AM -0700, Sean Hogan via FreeIPA-users wrote:
> 
> Hi All,
> 
>   We are having an issue performing RHEL 6.6 to 6.7 upgrade with SSSD.  The
> systems are already enrolled and working in IPA 3.0.0-50 using 6.6 client.
> We yum update and sssd gives this
>   
>  Non-fatal POSTTRANS scriptlet failure in rpm package 
>  sssd-1.12.4-47.el6_7.8.ppc64 
>  warning: %posttrans(sssd-1.12.4-47.el6_7.8.ppc64) scriptlet  
>  failed, exit status 1
>   

I'm sorry if this comes off as less than helpful, but unless you have a
critical reason to use 6.7, please upgrade to 6.8 or even 6.9. You don't
have to upgrade the whole distro, but at least the sssd stack.

There was a ton of bugfixes between 6.7 and 6.8..

> 
> 
> 
> Seems to install however sssd will no longer start.  I can run ldap
> searches against the IPA server and kinit without issue
> I have un-enrolled the client and re-enrolled to no avail... once enroll
> gets to starting sssd it says sssd restart failed and continues to enroll.
> I have reinstalled sssd, ipa client and c-ares, I have removed the sssd
> cache db.
> 
> The really strange part is if we wait approx 24 hours sssd starts working
> again which we have reproduced on 2 servers we are testing with... are we
> missing some sort of lease or cache?  Using this to remove the sssd db
> rm -rf /var/lib/sss/db/*
> 
> 
> 
> Here is a piece of the gdb core dump
> Core was generated by `/usr/libexec/sssd/sssd_pac --uid 0 --gid 0 -d 0x37f0

This is a bug in the sssd_pac responder. I couldn't find any related
bug report upstream or in RHBZ, but I would really suggest upgrading
first.

If the sssd_pac service still crashes, then we need to investiage the
problem further. Seeing that you're using ppc, chances are there might be
an endianess issue, but I can't think of any recent one.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: { possibly offtopic } -- can sssd.conf alone be configured to copy the custom AD ID Ranges used by IPA server?

[Jakub Hrozek via FreeIPA-users]

On Wed, Jun 28, 2017 at 01:03:45PM -0400, Chris Dagdigian via FreeIPA-users 
wrote:
> Hi folks,
> 
> 
> I have a set of servers that CANNOT become enrolled IDM clients due to a
> vendor refusing to support this type of config.
> 
> This server fleet is directly bound to an AD system via the standard non-IPA
> "realm join ..." type commands
> 
> Since I can't bring these servers "into the fold" so to speak at the very
> least I would love to offset at least one potential future problem by seeing
> if I can help them configure sssd.conf on their local machines to use the
> same AD SID-to-UID algorithm (complete with custom ID Range values that we
> have enabled on the IPA master) so that they at least get the same UID and
> GID values for their AD users as the same user would get if they logged into
> the much larger fleet of IDM-managed servers.
> 
> Hope I'm asking the question properly -- in a nutshell I'm wondering how to
> trick a standalone sssd.conf file so that it uses the same SID-to-UID
> algorithm that an IDM master would use. This would at least let me get
> consistent UID/GID values across my fleet of enrolled vs. non-enrolled IDM
> clients !  Tips or advice appreciated even if the response is "heck no; you
> can't do that .. "

So is the requirement absolutely to have the machines enrolled as part
of the AD domain?

If not, have you considered pointing the clients towards the compat tree
and using a plain LDAP setup, if your vendor supports that?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: { possibly offtopic } -- can sssd.conf alone be configured to copy the custom AD ID Ranges used by IPA server?

[Jakub Hrozek via FreeIPA-users]

On Thu, Jun 29, 2017 at 08:41:25AM -0400, Chris Dagdigian wrote:
> Jakub Hrozek via FreeIPA-users wrote:
> > If not, have you considered pointing the clients towards the compat tree
> > and using a plain LDAP setup, if your vendor supports that?
> 
> 
> Appreciate the replies to even a non-IPA usage question. This list has a
> tremendous signal:noise ratio.
> 
> The info above sounds promising but I don't quite understand it. Is there a
> chapter in the IDM Admin Guide you can point me to to read up on or some
> other reference I can check out? Thanks!

I'm sorry, I didn't find a chapter in the IDM guide, but I found:
https://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts
which has some examples.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: [SSSD-users] Re: 1.15.3/1.16 release timeframe?

[Jakub Hrozek via FreeIPA-users]

On Tue, Jul 04, 2017 at 12:38:46AM +0300, Timo Aaltonen wrote:
> On 31.05.2017 10:53, Jakub Hrozek wrote:
> > On Wed, May 31, 2017 at 08:19:56AM +1000, Lachlan Musicman wrote:
> >> Hi all,
> >>
> >> I noticed a while ago that 1.15.3 was versioned in the repo but I've not
> >> seen anything released? I'm mostly looking on the COPR
> >> (
> >> https://pagure.io/SSSD/sssd/c/012ee7c3fe24a5e75d9b0465268c1bb8187b8337?branch=master
> >> )
> >>
> >> This is purely selfish - I love all that you do, and I'm aware that there
> >> has been some fairly comprehensive infrastructural change.
> >>
> >> I'm just waiting on that one fix and have no roadmap visibility :)
> > 
> > Sorry, I agree our roadmap is not entirely clear.
> > 
> > 1.15.3 will be released during June, most fixes planned for that release
> > are either in or being reviewed.
> 
> Freeipa 4.5.2 depends on a feature not available in 1.15.2, which feels
> a bit backwards as it's a point-release which I think should not depend
> on a not-yet-released features..

You are right and I didn't realize that there was this dependency.

The current status of 1.15.3 release is that we need to fix:
https://pagure.io/SSSD/sssd/issue/3441 - secondary group membership
resolution of AD user fails if user information from other trusted
domain is fetched first - this is a regression I would really not
like to see in a release

Currently the 1.15.3 milestone also contains
https://pagure.io/SSSD/sssd/issue/3420 which is quite important but I
wouldn't hold the release over this bug and
https://pagure.io/SSSD/sssd/issue/3406 which is also a regression, but
at the same time a bit of a corner case, so I'd be personally fine with
moving this to 1.15.4..
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: sssd providing dns cache?

[Jakub Hrozek via FreeIPA-users]

On Fri, Jul 07, 2017 at 10:47:44AM +0200, Harald Dunkel via FreeIPA-users wrote:
> On Fri, 7 Jul 2017 08:27:53 +
> "wouter.hummelink--- via FreeIPA-users" 
>  wrote:
> 
> > No, 
> > 
> 
> I would suggest to add it.

Well, we are considering adding support for the hosts map in the next
version, but not as a means of DNS caching, but as a way to support
users who were running "hosts: ldap" with nslcd so that these users have
one less reason to mix and match nslcd and sssd on a single host.

I don't think DNS caching in general is something SSSD should do.

> 
> > But you can use nscd with [services passwd group netgroup] caches disabled.
> > 
> 
> I saw the documentation about this on RedHat's wiki, but I 
> would prefer having a single service. Apparently sss and nscd 
> are in conflict to each other (except for DNS).
> 
> 
> Regards
> Harri



> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: krb won't failover to alternative servers

[Jakub Hrozek via FreeIPA-users]

On Mon, Jul 10, 2017 at 02:10:48PM +, pgb205 via FreeIPA-users wrote:
> 
> 
> 
> we have 4 servers for redundancy in krb5.confkdc= server1kdc= server2kdc= 
> server3kdc= 
> server4master_kdc=server1master_kdc=server2master_kdc=server3master_kdc=server4admin_server=server1admin_server=server2admin_server=server3admin_server=server4
> servers 1 and 2 are shutdown. I am unable to get kinit  until I 
> comment their lines out and bounce sssd however. So the failover isn't 
> working  as expected. 
> Is there anything I need to do to make this happen?
> thank you
> 
>

Please take a look into /var/lib/sss/pubconf/. Is there a file called
kdcinfo_YOURREALM which contains the IP address of the KDC that is down?

See also
https://jhrozek.wordpress.com/2014/11/04/how-does-sssd-interact-with-tools-like-kinit/
for some more details.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: sssd went away, failed to restart

[Jakub Hrozek via FreeIPA-users]

Pavel, I think this looks a bit similar to
https://bugzilla.redhat.com/show_bug.cgi?id=1466934

do you agree? Do you have some suggestion to increase the wait timeout
in case the services are restarted?

On Thu, Jul 13, 2017 at 08:41:58AM +0200, Harald Dunkel wrote:
> Hi Jakub,
> 
> it happened again (using sssd 1.15.0). At 18.21 sssd became unavailable. See 
> below
> 
> On Wed, 24 Feb 2016 09:24:47 +0100
> Jakub Hrozek  wrote:
> 
> > > 
> > > Do you think this is OK? Did it try to terminate the unresponsive
> > > sssd_be, or did it just try to start a new one and ran into a
> > > conflict with the old?  
> > 
> > We should have started a new one. Again, I'm speculating, but I /think/
> > that because the system might have been under load, the sssd_be took too
> > long to restart and the monitor (sssd itself) gave up on it. Of course,
> > it's something we should fix, but without a better idea how to
> > reproduce the error in the first place, I'm not sure how to start to be
> > honest.
> > 
> 
> This time nss went away, AFAICS. sssd.log:
> 
> (Mon Jul 10 00:39:27 2017) [sssd] [monitor_hup] (0x0020): Received SIGHUP.
> (Mon Jul 10 00:39:27 2017) [sssd] [te_server_hup] (0x0020): Received SIGHUP. 
> Rotating logfiles.
> (Wed Jul 12 18:21:31 2017) [sssd] [svc_child_info] (0x0040): Child [1152] 
> exited with code [0]
> (Wed Jul 12 18:21:31 2017) [sssd] [sbus_dispatch] (0x0080): Connection is not 
> open for dispatching.
> (Wed Jul 12 18:21:32 2017) [sssd] [start_service] (0x0100): Queueing service 
> nss for startup
> (Wed Jul 12 18:21:32 2017) [sssd] [sbus_server_init_new_connection] (0x0200): 
> Entering.
> (Wed Jul 12 18:21:32 2017) [sssd] [sbus_server_init_new_connection] (0x0200): 
> Adding connection 0x10c4230.
> (Wed Jul 12 18:21:32 2017) [sssd] [sbus_server_init_new_connection] (0x0200): 
> Got a connection
> (Wed Jul 12 18:21:32 2017) [sssd] [svc_child_info] (0x0040): Child [117466] 
> exited with code [3]
> (Wed Jul 12 18:21:32 2017) [sssd] [svc_child_info] (0x0040): Child [1150] 
> exited with code [0]
> (Wed Jul 12 18:21:32 2017) [sssd] [sbus_dispatch] (0x0080): Connection is not 
> open for dispatching.
> (Wed Jul 12 18:21:32 2017) [sssd] [start_service] (0x0100): Queueing service 
> example.de for startup
> (Wed Jul 12 18:21:34 2017) [sssd] [start_service] (0x0100): Queueing service 
> nss for startup
> (Wed Jul 12 18:21:34 2017) [sssd] [sbus_server_init_new_connection] (0x0200): 
> Entering.
> (Wed Jul 12 18:21:34 2017) [sssd] [sbus_server_init_new_connection] (0x0200): 
> Adding connection 0x10c44a0.
> (Wed Jul 12 18:21:34 2017) [sssd] [sbus_server_init_new_connection] (0x0200): 
> Got a connection
> (Wed Jul 12 18:21:34 2017) [sssd] [svc_child_info] (0x0040): Child [117468] 
> exited with code [3]
> (Wed Jul 12 18:21:34 2017) [sssd] [sbus_dispatch] (0x0080): Connection is not 
> open for dispatching.
> (Wed Jul 12 18:21:38 2017) [sssd] [start_service] (0x0100): Queueing service 
> nss for startup
> (Wed Jul 12 18:21:38 2017) [sssd] [sbus_server_init_new_connection] (0x0200): 
> Entering.
> (Wed Jul 12 18:21:38 2017) [sssd] [sbus_server_init_new_connection] (0x0200): 
> Adding connection 0x10b29b0.
> (Wed Jul 12 18:21:38 2017) [sssd] [sbus_server_init_new_connection] (0x0200): 
> Got a connection
> (Wed Jul 12 18:21:38 2017) [sssd] [svc_child_info] (0x0040): Child [117469] 
> exited with code [3]
> (Wed Jul 12 18:21:38 2017) [sssd] [monitor_restart_service] (0x0010): Process 
> [nss], definitely stopped!
> (Wed Jul 12 18:21:38 2017) [sssd] [monitor_quit] (0x0040): Returned with: 1
> (Wed Jul 12 18:21:38 2017) [sssd] [monitor_quit] (0x0020): Terminating 
> [example.de][117467]
> (Wed Jul 12 18:21:39 2017) [sssd] [monitor_quit] (0x0020): Child [example.de] 
> exited gracefully
> (Wed Jul 12 18:21:39 2017) [sssd] [monitor_quit] (0x0020): Terminating 
> [pac][1156]
> (Wed Jul 12 18:21:40 2017) [sssd] [monitor_quit] (0x0020): Child [pac] 
> terminated with a signal
> (Wed Jul 12 18:21:40 2017) [sssd] [monitor_quit] (0x0020): Terminating 
> [ssh][1155]
> (Wed Jul 12 18:21:40 2017) [sssd] [monitor_quit] (0x0020): Child [ssh] 
> terminated with a signal
> (Wed Jul 12 18:21:40 2017) [sssd] [monitor_quit] (0x0020): Terminating 
> [pam][1154]
> (Wed Jul 12 18:21:40 2017) [sssd] [monitor_quit] (0x0020): Child [pam] 
> terminated with a signal
> (Wed Jul 12 18:21:40 2017) [sssd] [monitor_quit] (0x0020): Terminating 
> [sudo][1153]
> (Wed Jul 12 18:21:40 2017) [sssd] [monitor_quit] (0x0020): Child [sudo] 
> exited gracefully
> (Wed Jul 12 19:12:37 2017) [sssd] [sss_names_init_from_args] (0x0100): Using 
> re 
> [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P.+$))|(^(?P[^@\\]+)$))].
> (Wed Jul 12 19:12:37 2017) [sssd] [sss_fqnames_init] (0x0100): Using fq 
> format [%1$s@%2$s].
> 
> 
> sssd_nss.log:
> (Wed Jul 12 18:21:29 2017) [sssd[nss]] [orderly_shutdown] (0x0010): SIGTERM: 
> killing children
> (Wed Jul 12 18:21:32 2017) [sssd[nss]] [sss_dp_init] (0x0010): Failed to 
> connect to monitor services.
> (Wed Jul 12 

[Freeipa-users] Re: Cannot get a second FreeIPA client authentication working.

[Jakub Hrozek via FreeIPA-users]

On Fri, Jul 14, 2017 at 09:57:44AM +1200, Patrick McHale via FreeIPA-users 
wrote:
> Hi,
> 
> 
> 
> I have had a success with installing the FreeIPA system but I needed to add
> another client in order to reproduce the steps required for
> 
> building a client to authenticate with the server. I did the same steps as
> before but I cannot get "another" client to authenticate with the server.
> 
> 
> 
> The new client shows up in the hosts lists, and this indicates it has been
> enrolled.
> 
> 
> 
> Is there something else that needs to be run, on the new client in order
> for the FreeIPA server to take charge of the new client machine
> 
> authentication. I know the server is running correctly, because the
> original client works fine.

Just running ipa-client-install should be enough.

What exactly is not working? Retrieving or authenticating domains users?
If so, have you checked
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html ?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Unable to login as user

[Jakub Hrozek via FreeIPA-users]

On Fri, Jul 14, 2017 at 02:02:03AM -, patrick.mchale--- via FreeIPA-users 
wrote:
> Hi,
> 
> I am getting an error logging into a FreeIPA server from a new FreeIPA 
> client. I have reset the password for the user using "kinit admin" but still 
> no joy. Is there another password that is needing to be set?.
> 
> Jul 14 13:53:41 ipa-client [sssd[krb5_child[2457]]]: Password has expired
> Jul 14 13:53:41 ipa-client [sssd[krb5_child[2457]]]: Decrypt integrity check 
> failed
> Jul 14 13:54:40 ipa-client [sssd[krb5_child[2466]]]: Password has expired
> Jul 14 13:54:40 ipa-client [sssd[krb5_child[2466]]]: Decrypt integrity check 
> failed

sssd should have prompted you for the new password.. The "Decrypt
integrity check failed" sounds like the wrong password was entered,
though.

does kinit $user work?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Unable to login as user

[Jakub Hrozek via FreeIPA-users]

On Fri, Jul 14, 2017 at 08:10:39AM +, Callum Guy via FreeIPA-users wrote:
> Hi Jakub,
> 
> Apologies for hijacking the thread but you reminded me of a longstanding
> issue - I can't manually use kinit on my client nodes. As I operate a jump
> server that means I get a ticket on first login but when i login to other
> client systems the ticket gives me entry but doesn't follow me. When I try
> to run kinit for my user the following message is printed:
> 
> $ kinit callum
> kinit: Generic preauthentication failure while getting initial credentials
> 
> Not a single local log entry is generated. Any ideas?

kinit doesn't generate logs unless you set the KRB5_TRACE variable, e.g.
KRB5_TRACE=/dev/stderr kinit callum
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ipa-client-install generates bad sssd.conf

[Jakub Hrozek via FreeIPA-users]

On Thu, Jul 20, 2017 at 02:33:50PM +0200, John Keates via FreeIPA-users wrote:
> Hi,
> 
> Using SSSD 1.15.2-1 and FreeIPA Client 4.4.4-1 on Debian Stretch 9.0 
> generates a broken SSSD configuration.
> Adding the services manually to sssd.conf fixes this:
> 
> services = nss, sudo, pam, ssh
> 
> For some reason, ipa-client-install thinks we have socket-activated SSSD 
> services, but we don’t. From the SSSD package, we only get:
> 
> - sssd.service
> - sssd-secrets.socket
> - sssd-secrets.service
> 
> There seems to be a mismatch between what gets configured in sssd.conf and 
> what is actually on the system.
> I should probably report it as a bug against the Debian package, but I wonder 
> where the assumption for SSSD.conf is made. It is definitely generated by 
> ipa-client-install, but maybe it’s because it sees the socket-activated SSSD 
> components as a requirement?

There was a thread on Mar 3rd titled "ipa-client-install generates bad
sssd.conf", you might want to check it out although I didn't see any
conclusion in the thread..
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Two way trust problem

[Jakub Hrozek via FreeIPA-users]

On Thu, Jul 20, 2017 at 12:20:31PM -0400, Steve Weeks via FreeIPA-users wrote:
> We've setup a two-way trust with AD and it seems to have worked, but it
> doesn't look like it is working correctly.
> 
> The kerberos commands (kinit and kvno) work fine, but things like 'id
> adu...@addomain.example.com' and 'getent passwd adu...@addomain.example.com'
> don't work.
> 
> # ipa trust-add --type ad addomain.example.com --admin adadmin --password
> --two-way=true
> Active Directory domain administrator's password:
> -
> Added Active Directory trust for realm "addomain.example.com"
> -
>   Realm name: addomain.example.com
>   Domain NetBIOS name: ADDOMAIN
>   Domain Security Identifier: S-1-5-21-2229161606-873856335-779138662
>   Trust direction: Two-way trust
>   Trust type: Active Directory domain
>   Trust status: Established and verified
> 
> # kinit adu...@addomain.example.com
> Password for adu...@addomain.example.com:
> 
> # klist
> Ticket cache: KEYRING:persistent:0:krb_ccache_o3D2R5S
> Default principal: adu...@addomain.example.com
> 
> Valid starting   Expires  Service principal
> 07/20/2017 12:16:41  07/20/2017 22:16:41  krbtgt/
> addomain.example@addomain.example.com
> renew until 07/21/2017 12:16:38
> 
> # id adu...@addomain.example.com
> id: ‘adu...@addomain.example.com’: no such user
> 
> Is this the best way to test the trust?
> 
> We are running FreeIPA 4.4 and Windows Server 2012 R2
> 
> When setting up the trust we needed to modify /etc/hosts as described in
> https://bugzilla.redhat.com/show_bug.cgi?id=878168

Since the trust is two-way, can you kinit using the system keytab and
try searching the AD DC? e.g.

kinit -k
ldapsearch -Y GSSAPI -H ldap://your.ad.dc -s base -b ""

that should return the rootDSE and give you the ldap/your.ad.dc ticket
in the process if the trust works OK..
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Two way trust problem

[Jakub Hrozek via FreeIPA-users]

On Fri, Jul 21, 2017 at 05:53:57AM -0400, Steve Weeks via FreeIPA-users wrote:
> Looks like I got the rootDSE, 109 lines of information and got the
> following at the end.  I don't know much about ldap so I'm guessing this
> was successful

Yes, so the trust indeed works.

>.  And, yes I did get a ldap/ad.cd ticket.  What should I
> look at next?

SSSD on the server itself. Please check out
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html, hopefully
the server-side sssd logs would help..
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: diskless workstations in an IPA domain

[Jakub Hrozek via FreeIPA-users]

On Fri, Jul 21, 2017 at 05:12:20PM +0200, Jacquelin Charbonnel wrote:
> Hi everybody,
> 
>   At now, I enroll diskless Fedora26 workstations (with stateless Linux) 
> into
> my IPA domain.
>   Inside the readonly root image, /etc/sysconfig/selinux points :
> 
> SELINUX=disabled
> SELINUXTYPE=targeted
> 
> and /etc/sssd/sssd.conf points :
> 
> [domain/math]
> selinux_provider = none
> debug_level=0x0070
> ...
> 
>   So, authentication of a domain account seems well working, but 
> nevertheless
> at each time, journalctl says :
> 
> juil. 21 16:11:32 pc-f26.math systemd-coredump[22019]:
> Process 22017 (selinux_child) of user 0 dumped core.
> 
> Stack trace of thread 22017:
> #0  0x7f60bac8dd24 semanage_seuser_key_free (libsemanage.so.1)
> #1  0x5639b0b5326d set_seuser (selinux_child)
> #2  0x5639b0b52a3f main (selinux_child)
> #3  0x7f60ba8b94da __libc_start_main (libc.so.6)
> #4  0x5639b0b52dba _start (selinux_child)

Can you file a bug against sssd and add the core there? This shouldn't
happen.

(Also, adding logs would be nice to find out why is selinux child being
called despite selinux_provider=none)

> 
> Hope this helps...
> Jacquelin
> 
> Le 14/10/2016 à 10:02, Jakub Hrozek a écrit :
> > On Fri, Oct 14, 2016 at 09:44:11AM +0200, Sumit Bose wrote:
> > > On Fri, Oct 14, 2016 at 12:41:23AM +0200, Jacquelin Charbonnel wrote:
> > > > Thank you for this information. Yes, /tmp is writable.
> > > > 
> > > > My problem is : access are sometimes definitively refused for 
> > > > random user
> > > > who wants to log in diskless workstations.
> > > > But if this banned user tries to connect to the single machine 
> > > > which mounts
> > > > the fs in rw mode, it's work, and this solve immediately its problem on 
> > > > all
> > > > the other stateless machines !? Strange...
> > > 
> > > Maybe it is the selinux_provider, iirc at least in older version it used
> > > to write some data somewhere below /etc/selinux/. You can easily test
> > > this by setting 'selinux_provider = none' in the domain section in
> > > ssd.conf.
> > 
> > Aah, that's probably it. We no longer write to the directory directly,
> > but we call libsemanage functions that do.
> > 
> 
> -- 
> Jacquelin Charbonnel - (+33)2 4173 5397
> CNRS Mathrice/LAREMA - Campus universitaire d'Angers
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: AD trust setup woes

[Jakub Hrozek via FreeIPA-users]

On Fri, Jul 21, 2017 at 03:43:58PM -0400, Jason Beck via FreeIPA-users wrote:
> I have been trying to reliably get an AD trust setup for a few weeks and no
> matter what I try, when I goto add AD users to an external group in
> FreeIPA, I get:
> 
> "trusted domain object not found"
> 
> Googling around tends to always yield the same suggestions:
> 
> 1) Check time sync
> 2) Check DNS
> 3) Check firewall
> 
> I have done all of this ad nauseam in several different environments with
> several different versions of FreeIPA and Windows servers.  I have gotten a
> setup to work maybe 2% of the time out of hundreds of attempts.
> 
> I am currently using FreeIPA 4.5.2 on Fedora 25 (out of the COPR repo).  I
> am trying to establish trust with a mixed Windows 2012 & 2008 forest. I
> have tried both one and two way trusts.  Everything seems to work fine up
> until I try to add AD users to FreeIPA.
> 
> I have verified all of the requisite DNS records exist and return the
> proper information on both sides, there are no firewalls between any of the
> hosts, and the AD servers and FreeIPA servers are synchronized by the same
> NTP servers.
> 
> What could I possibly be missing?

Can you resolve the object you're trying to add with sssd?

e.g. id foo@windows.domain
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: AD trust setup woes

[Jakub Hrozek via FreeIPA-users]

On Mon, Jul 24, 2017 at 09:05:59AM -0400, Jason Beck wrote:
> On Jul 24, 2017 4:14 AM, "Jakub Hrozek via FreeIPA-users" <
> freeipa-users@lists.fedorahosted.org> wrote:
> 
> > On Fri, Jul 21, 2017 at 03:43:58PM -0400, Jason Beck via FreeIPA-users
> > wrote:
> > > I have been trying to reliably get an AD trust setup for a few weeks and
> > no
> > > matter what I try, when I goto add AD users to an external group in
> > > FreeIPA, I get:
> > >
> > > "trusted domain object not found"
> > >
> > > Googling around tends to always yield the same suggestions:
> > >
> > > 1) Check time sync
> > > 2) Check DNS
> > > 3) Check firewall
> > >
> > > I have done all of this ad nauseam in several different environments with
> > > several different versions of FreeIPA and Windows servers.  I have
> > gotten a
> > > setup to work maybe 2% of the time out of hundreds of attempts.
> > >
> > > I am currently using FreeIPA 4.5.2 on Fedora 25 (out of the COPR repo).
> > I
> > > am trying to establish trust with a mixed Windows 2012 & 2008 forest. I
> > > have tried both one and two way trusts.  Everything seems to work fine up
> > > until I try to add AD users to FreeIPA.
> > >
> > > I have verified all of the requisite DNS records exist and return the
> > > proper information on both sides, there are no firewalls between any of
> > the
> > > hosts, and the AD servers and FreeIPA servers are synchronized by the
> > same
> > > NTP servers.
> > >
> > > What could I possibly be missing?
> >
> > Can you resolve the object you're trying to add with sssd?
> >
> > e.g. id foo@windows.domain
> > ___
> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> 
> 
> No.  I can login via Kerberos, kinit user@ad.domain.  But neither id
> user@ad.domain nor getent passwd user@ad.domain are successful.

Then please follow
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: AD trust setup woes

[Jakub Hrozek via FreeIPA-users]

On Mon, Jul 24, 2017 at 01:53:20PM -0400, Jason Beck wrote:
> On Mon, Jul 24, 2017 at 9:25 AM, Jakub Hrozek  wrote:
> 
> > On Mon, Jul 24, 2017 at 09:05:59AM -0400, Jason Beck wrote:
> > > On Jul 24, 2017 4:14 AM, "Jakub Hrozek via FreeIPA-users" <
> > > freeipa-users@lists.fedorahosted.org> wrote:
> > >
> > > > On Fri, Jul 21, 2017 at 03:43:58PM -0400, Jason Beck via FreeIPA-users
> > > > wrote:
> > > > > I have been trying to reliably get an AD trust setup for a few weeks
> > and
> > > > no
> > > > > matter what I try, when I goto add AD users to an external group in
> > > > > FreeIPA, I get:
> > > > >
> > > > > "trusted domain object not found"
> > > > >
> > > > > Googling around tends to always yield the same suggestions:
> > > > >
> > > > > 1) Check time sync
> > > > > 2) Check DNS
> > > > > 3) Check firewall
> > > > >
> > > > > I have done all of this ad nauseam in several different environments
> > with
> > > > > several different versions of FreeIPA and Windows servers.  I have
> > > > gotten a
> > > > > setup to work maybe 2% of the time out of hundreds of attempts.
> > > > >
> > > > > I am currently using FreeIPA 4.5.2 on Fedora 25 (out of the COPR
> > repo).
> > > > I
> > > > > am trying to establish trust with a mixed Windows 2012 & 2008
> > forest. I
> > > > > have tried both one and two way trusts.  Everything seems to work
> > fine up
> > > > > until I try to add AD users to FreeIPA.
> > > > >
> > > > > I have verified all of the requisite DNS records exist and return the
> > > > > proper information on both sides, there are no firewalls between any
> > of
> > > > the
> > > > > hosts, and the AD servers and FreeIPA servers are synchronized by the
> > > > same
> > > > > NTP servers.
> > > > >
> > > > > What could I possibly be missing?
> > > >
> > > > Can you resolve the object you're trying to add with sssd?
> > > >
> > > > e.g. id foo@windows.domain
> > > > ___
> > > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > > > To unsubscribe send an email to freeipa-users-leave@lists.
> > fedorahosted.org
> > >
> > >
> > > No.  I can login via Kerberos, kinit user@ad.domain.  But neither id
> > > user@ad.domain nor getent passwd user@ad.domain are successful.
> >
> > Then please follow
> > https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
> >
> 
> Jakub,
> 
>   Thank you for the support thus far.  I have followed some suggestions in
> the sssd troubleshooting link you provided.  I am seeing these errors
> whenever I try to perform an operation that would lookup an AD user, e.g.
> id user@ad.domain.  I am performing the user lookups on the primary IPA
> server itself.
> 
> *sssd.conf:*
> 
> [domain/ipa.domain]
> 
> debug_level = 10
> 
> cache_credentials = True
> 
> enumerate = False
> 
> krb5_store_password_if_offline = True
> 
> ipa_domain = ipa.domain
> 
> id_provider = ipa
> 
> auth_provider = ipa
> 
> access_provider = ipa
> 
> ipa_hostname = ipa01.ipa.domain
> 
> chpass_provider = ipa
> 
> ipa_server = _srv_
> 
> ldap_tls_cacert = /etc/ipa/ca.crt
> 
> [sssd]
> 
> services = sudo, nss, ifp, pam, ssh, pac
> 
> debug_level = 10
> 
> domains = ipa.domain
> 
> [nss]
> 
> debug_level = 10
> 
> [pam]
> 
> debug_level = 10
> 
> [sudo]
> 
> debug_level = 10
> 
> [autofs]
> 
> debug_level = 10
> 
> [ssh]
> 
> debug_level = 10
> 
> [pac]
> 
> debug_level = 10
> 
> [ifp]
> 
> debug_level = 10
> 
> [secrets]
> 
> debug_level = 10
> 
Are you sure it's the server itself? Because for one, I would expect to
see ipa_server_mode=True in sssd.conf and also ipa_server set to fqdn of
'self', not to _srv_.

Also the s2n exop failed messages make it look like the debug messages
are from a client.

Anyway, one thing to examine is:
> Jul 24 13:20:04 ipa01.ipa.domain sssd[6535]: (Mon Jul 24 13:20:04 2017)
> [sssd[nss]] [cache_req_common_dp_recv] (0x0040): CR #49: Data Provider
> Error: 3, 5, Failed to get reply from Data Provider
> 
> Jul 24 13:20:04 ipa01.ipa.domain sssd[6535]: (Mon Jul 24 13:20:04 2017)
> [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data Provider returned an
> error [org.freedesktop.sssd.Error.DataProvider.Offline]
> 

This indicates a communication issue towards the server. You should look
for messages that say that 'a port is not working'.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: AD trust setup woes

[Jakub Hrozek via FreeIPA-users]

On Mon, Jul 24, 2017 at 04:25:14PM -0400, Jason Beck via FreeIPA-users wrote:
> On Mon, Jul 24, 2017 at 2:53 PM, Jason Beck  wrote:
> 
> > On Mon, Jul 24, 2017 at 2:23 PM, Jakub Hrozek  wrote:
> >
> >> On Mon, Jul 24, 2017 at 01:53:20PM -0400, Jason Beck wrote:
> >> > On Mon, Jul 24, 2017 at 9:25 AM, Jakub Hrozek 
> >> wrote:
> >> >
> >> > > On Mon, Jul 24, 2017 at 09:05:59AM -0400, Jason Beck wrote:
> >> > > > On Jul 24, 2017 4:14 AM, "Jakub Hrozek via FreeIPA-users" <
> >> > > > freeipa-users@lists.fedorahosted.org> wrote:
> >> > > >
> >> > > > > On Fri, Jul 21, 2017 at 03:43:58PM -0400, Jason Beck via
> >> FreeIPA-users
> >> > > > > wrote:
> >> > > > > > I have been trying to reliably get an AD trust setup for a few
> >> weeks
> >> > > and
> >> > > > > no
> >> > > > > > matter what I try, when I goto add AD users to an external
> >> group in
> >> > > > > > FreeIPA, I get:
> >> > > > > >
> >> > > > > > "trusted domain object not found"
> >> > > > > >
> >> > > > > > Googling around tends to always yield the same suggestions:
> >> > > > > >
> >> > > > > > 1) Check time sync
> >> > > > > > 2) Check DNS
> >> > > > > > 3) Check firewall
> >> > > > > >
> >> > > > > > I have done all of this ad nauseam in several different
> >> environments
> >> > > with
> >> > > > > > several different versions of FreeIPA and Windows servers.  I
> >> have
> >> > > > > gotten a
> >> > > > > > setup to work maybe 2% of the time out of hundreds of attempts.
> >> > > > > >
> >> > > > > > I am currently using FreeIPA 4.5.2 on Fedora 25 (out of the COPR
> >> > > repo).
> >> > > > > I
> >> > > > > > am trying to establish trust with a mixed Windows 2012 & 2008
> >> > > forest. I
> >> > > > > > have tried both one and two way trusts.  Everything seems to
> >> work
> >> > > fine up
> >> > > > > > until I try to add AD users to FreeIPA.
> >> > > > > >
> >> > > > > > I have verified all of the requisite DNS records exist and
> >> return the
> >> > > > > > proper information on both sides, there are no firewalls
> >> between any
> >> > > of
> >> > > > > the
> >> > > > > > hosts, and the AD servers and FreeIPA servers are synchronized
> >> by the
> >> > > > > same
> >> > > > > > NTP servers.
> >> > > > > >
> >> > > > > > What could I possibly be missing?
> >> > > > >
> >> > > > > Can you resolve the object you're trying to add with sssd?
> >> > > > >
> >> > > > > e.g. id foo@windows.domain
> >> > > > > ___
> >> > > > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahost
> >> ed.org
> >> > > > > To unsubscribe send an email to freeipa-users-leave@lists.
> >> > > fedorahosted.org
> >> > > >
> >> > > >
> >> > > > No.  I can login via Kerberos, kinit user@ad.domain.  But neither
> >> id
> >> > > > user@ad.domain nor getent passwd user@ad.domain are successful.
> >> > >
> >> > > Then please follow
> >> > > https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
> >> > >
> >> >
> >> > Jakub,
> >> >
> >> >   Thank you for the support thus far.  I have followed some suggestions
> >> in
> >> > the sssd troubleshooting link you provided.  I am seeing these errors
> >> > whenever I try to perform an operation that would lookup an AD user,
> >> e.g.
> >> > id user@ad.domain.  I am performing the user lookups on the primary IPA
> >> > server itself.
> >> >
> >> > *sssd.conf:*
> >> >
> >> > [domain/ipa.domain]
> >&

[Freeipa-users] Announcing SSSD 1.15.3

[Jakub Hrozek via FreeIPA-users]

SSSD 1.15.3
===

The SSSD team is proud to announce the release of version 1.15.3 of the
System Security Services Daemon.

The tarball can be downloaded from https://releases.pagure.org/SSSD/sssd/

RPM packages will be made available for Fedora shortly.

Feedback

Please provide comments, bugs and other feedback via the sssd-devel or
sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Highlights
--

New Features

 * In a setup where an IPA domain trusts an Active Directory domain,
   it is now possible to define the domain resolution order
   (see http://www.freeipa.org/page/Releases/4.5.0#AD_User_Short_Names).
   Starting with this version, SSSD is able to read and honor the domain
   resolution order, providing a way to resolve Active Directory users by
   just their short name.  SSSD also supports a new option
   "domain_resolution_order" applicable in the "[sssd]" section
   that allows to configure short names for AD users in setup with
   "id_provider=ad" or in a setup with an older IPA server that doesn't
   support the "ipa config-mod --domain-resolution-order"
   configuration option. Also, it is now possible to use
   "use_fully_qualified_names=False" in a subdomain configuration, but
   please note that the user and group output from trusted domains will
   always be qualified to avoid conflicts.

   * Design page - Shortnames in trusted domains 


 * SSSD ships with a new service called KCM. This service acts as a
   storage for Kerberos tickets when "libkrb5" is configured to use
   "KCM:" in "krb5.conf". Compared to other Kerberos credential
   cache types, KCM is better suited for containerized environments and
   because the credential caches are managed by a stateful daemon, in
   future releases will also allow to renew tickets acquired outside SSSD
   (e.g. with "kinit") or provide notifications about ticket changes.
   This feature is optional and can be disabled by selecting
   "--without-kcm" when configuring the SSSD build.

   * Design page - KCM server for SSSD 


   * NOTE: There are several known issues in the "KCM" responder that
 will be handled in the next release such as
 issues with very large tickets 
 or tracking the SELinux label of the peer 

 or even one intermittent crash 
 There are also some differences between how SSSD's KCM server works 
compared to
 Heimdal's KCM server such as visibility of ccaches by root
 .

 * Support for user and group resolution through the D-Bus interface and
   authentication and/or authorization through the PAM interface even
   for setups without UIDs or Windows SIDs present on the LDAP directory
   side. This enhancement allows SSSD to be used together with apache
   modules  to provide
   identities for applications

   * Design page - Support for non-POSIX users and groups 


 * SSSD ships a new public library called "libsss_certmap" that allows
   a flexible and configurable way of mapping a certificate to a user
   identity. This is required e.g. in environments where it is not possible
   to add the certificate to the LDAP user entry, because the certificates
   are issued externally or the LDAP schema cannot be modified. Additionally,
   specific matching rules allow a specific certificate on a smart card to
   be selected for authentication.

   * Design page - Matching and Mapping Certificates 


 * The Kerberos locator plugin can be disabled using an environment variable
   "SSSD_KRB5_LOCATOR_DISABLE". Please refer to the
   "sssd_krb5_locator_plugin" manual page for mode details.

 * The "sssctl" command line tool supports a new command "user-checks"
   that enables the administrator to check whether a certain user should be
   allowed or denied access to a certain PAM service.

 * The "secrets" responder now forwards requests to a proxy Custodia
   back end over a secure channel.

Notable bug fixes
^

 * The IPA HBAC evaluator no longer relies on "originalMemberOf"
   attributes to construct the list of groups the user is a member of.
   Maintaining the "originalMemberOf" attribute was unreliable and
   was causing intermittent HBAC issues.

 * A bug where the cleanup operation might erroneously remove cached users
   during their cache validation in case SSSD was set up with
   "enumerate=True" was fixed.

 * Sever

[Freeipa-users] Re: AD trust setup woes

[Jakub Hrozek via FreeIPA-users]

On Tue, Jul 25, 2017 at 10:12:38AM -0400, Jason Hensley via FreeIPA-users wrote:
> On Tue, Jul 25, 2017 at 2:29 AM, Jakub Hrozek via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
> 
> > On Mon, Jul 24, 2017 at 04:25:14PM -0400, Jason Beck via FreeIPA-users
> > wrote:
> > > On Mon, Jul 24, 2017 at 2:53 PM, Jason Beck 
> > wrote:
> > >
> > > > On Mon, Jul 24, 2017 at 2:23 PM, Jakub Hrozek 
> > wrote:
> > > >
> > > >> On Mon, Jul 24, 2017 at 01:53:20PM -0400, Jason Beck wrote:
> > > >> > On Mon, Jul 24, 2017 at 9:25 AM, Jakub Hrozek 
> > > >> wrote:
> > > >> >
> > > >> > > On Mon, Jul 24, 2017 at 09:05:59AM -0400, Jason Beck wrote:
> > > >> > > > On Jul 24, 2017 4:14 AM, "Jakub Hrozek via FreeIPA-users" <
> > > >> > > > freeipa-users@lists.fedorahosted.org> wrote:
> > > >> > > >
> > > >> > > > > On Fri, Jul 21, 2017 at 03:43:58PM -0400, Jason Beck via
> > > >> FreeIPA-users
> > > >> > > > > wrote:
> > > >> > > > > > I have been trying to reliably get an AD trust setup for a
> > few
> > > >> weeks
> > > >> > > and
> > > >> > > > > no
> > > >> > > > > > matter what I try, when I goto add AD users to an external
> > > >> group in
> > > >> > > > > > FreeIPA, I get:
> > > >> > > > > >
> > > >> > > > > > "trusted domain object not found"
> > > >> > > > > >
> > > >> > > > > > Googling around tends to always yield the same suggestions:
> > > >> > > > > >
> > > >> > > > > > 1) Check time sync
> > > >> > > > > > 2) Check DNS
> > > >> > > > > > 3) Check firewall
> > > >> > > > > >
> > > >> > > > > > I have done all of this ad nauseam in several different
> > > >> environments
> > > >> > > with
> > > >> > > > > > several different versions of FreeIPA and Windows servers.
> > I
> > > >> have
> > > >> > > > > gotten a
> > > >> > > > > > setup to work maybe 2% of the time out of hundreds of
> > attempts.
> > > >> > > > > >
> > > >> > > > > > I am currently using FreeIPA 4.5.2 on Fedora 25 (out of the
> > COPR
> > > >> > > repo).
> > > >> > > > > I
> > > >> > > > > > am trying to establish trust with a mixed Windows 2012 &
> > 2008
> > > >> > > forest. I
> > > >> > > > > > have tried both one and two way trusts.  Everything seems to
> > > >> work
> > > >> > > fine up
> > > >> > > > > > until I try to add AD users to FreeIPA.
> > > >> > > > > >
> > > >> > > > > > I have verified all of the requisite DNS records exist and
> > > >> return the
> > > >> > > > > > proper information on both sides, there are no firewalls
> > > >> between any
> > > >> > > of
> > > >> > > > > the
> > > >> > > > > > hosts, and the AD servers and FreeIPA servers are
> > synchronized
> > > >> by the
> > > >> > > > > same
> > > >> > > > > > NTP servers.
> > > >> > > > > >
> > > >> > > > > > What could I possibly be missing?
> > > >> > > > >
> > > >> > > > > Can you resolve the object you're trying to add with sssd?
> > > >> > > > >
> > > >> > > > > e.g. id foo@windows.domain
> > > >> > > > > ___
> > > >> > > > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahost
> > > >> ed.org
> > > >> > > > > To unsubscribe send an email to freeipa-users-leave@lists.
> > > >> > > fedorahosted.org
> >

[Freeipa-users] Re: Krb5.conf only sees first two kdc servers

[Jakub Hrozek via FreeIPA-users]

On Thu, Jul 27, 2017 at 02:15:33AM +, Michael Papet via FreeIPA-users wrote:
> >If the _srv_ is enabled then am i correct in assuming that we wouldn't even 
> >need kdc= records in krb5.conf ??>I tried removing kdc= linesand was unable 
> >to authenticate.
> In my experience, sssd relies upon the local kerberos stack.  Maybe others 
> have different experiences.
> mpapet

This really depends on what domain the user is authenticating from.

If the user comes from the joined domain, then currently sssd resolves
the KDC on its own and puts the address of the KDC server into the list
of KDC addresses known by libkrb5 via a locator plugin:

https://jhrozek.wordpress.com/2014/11/04/how-does-sssd-interact-with-tools-like-kinit/

But for users from trusted domains (typically when talking about IPA-AD
trusts), this is currently not done and sssd just calls a kinit
equivalent and pretty much relies on what is already configured in
krb5.conf.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

[Jakub Hrozek via FreeIPA-users]

On Thu, Jul 27, 2017 at 02:34:06AM -0400, Alexandre Pitre via FreeIPA-users 
wrote:
> I uploaded krb5_child.log and ldap_child.log to
> https://1drv.ms/f/s!AlZwwyQE2ZZ5p2b5ROa15PBkAEQD

I think the child just times out during TGT validation, see:
(Thu Jul 27 06:01:20 2017) [[sssd[krb5_child[2765 [sss_child_krb5_trace_cb] 
(0x4000): [2765] 1501135280.837647: Sending request (2132 bytes) to AD.COM
(Thu Jul 27 06:01:20 2017) [[sssd[krb5_child[2765 [sss_child_krb5_trace_cb] 
(0x4000): [2765] 1501135280.838622: Resolving hostname RO1-INF-ADS-002.ad.com.
(Thu Jul 27 06:01:20 2017) [[sssd[krb5_child[2765 [sss_child_krb5_trace_cb] 
(0x4000): [2765] 1501135280.839154: Sending initial UDP request to dgram 
10.248.40.11:88
(Thu Jul 27 06:01:21 2017) [[sssd[krb5_child[2765 [sss_child_krb5_trace_cb] 
(0x4000): [2765] 1501135281.840215: Resolving hostname ns1-inf-ads-001.ad.com.
(Thu Jul 27 06:01:21 2017) [[sssd[krb5_child[2765 [sss_child_krb5_trace_cb] 
(0x4000): [2765] 1501135281.841223: Sending initial UDP request to dgram 
10.3.200.10:88
(Thu Jul 27 06:01:22 2017) [[sssd[krb5_child[2765 [sss_child_krb5_trace_cb] 
(0x4000): [2765] 1501135282.842291: Resolving hostname inf-p-sy2-ad-01.ad.com.
(Thu Jul 27 06:01:22 2017) [[sssd[krb5_child[2765 [sss_child_krb5_trace_cb] 
(0x4000): [2765] 1501135282.843245: Sending initial UDP request to dgram 
192.168.1.10:88
(Thu Jul 27 06:01:23 2017) [[sssd[krb5_child[2765 [sss_child_krb5_trace_cb] 
(0x4000): [2765] 1501135283.844311: Resolving hostname inf-p-sy2-ad-02.ad.com.
(Thu Jul 27 06:01:23 2017) [[sssd[krb5_child[2765 [sss_child_krb5_trace_cb] 
(0x4000): [2765] 1501135283.845251: Sending initial UDP request to dgram 
192.168.1.11:88
(Thu Jul 27 06:01:24 2017) [[sssd[krb5_child[2765 [sss_child_krb5_trace_cb] 
(0x4000): [2765] 1501135284.846318: Resolving hostname RO1-INF-ADS-001.ad.com.
(Thu Jul 27 06:01:24 2017) [[sssd[krb5_child[2765 [sss_child_krb5_trace_cb] 
(0x4000): [2765] 1501135284.847243: Sending initial UDP request to dgram 
10.248.40.10:88
(Thu Jul 27 06:01:25 2017) [[sssd[krb5_child[2765 [sss_child_krb5_trace_cb] 
(0x4000): [2765] 1501135285.848311: Resolving hostname ns1-inf-ads-002.ad.com.
(Thu Jul 27 06:01:25 2017) [[sssd[krb5_child[2765 [sss_child_krb5_trace_cb] 
(0x4000): [2765] 1501135285.849256: Sending initial UDP request to dgram 
10.3.200.11:88

(This is the last message from PID 2765, so it was probably killed)

If the servers are reachable you can just increase the krb5_child timeout
in sssd.conf..
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Krb5.conf only sees first two kdc servers

[Jakub Hrozek via FreeIPA-users]

On Thu, Jul 27, 2017 at 02:19:38PM +, pgb205 via FreeIPA-users wrote:
> Jacub, yes we do have a one way trust between AD->FreeIPA. That explainswhy 
> krb5.conf is used instead of the sssd.conf _srv_ to retrieve DNS records.
> Can you also please comment on why I'm only getting lookups on the first two 
> kdc's listed in krb5.conf

I'm really not sure. I would say the same what Sumit did in his reply
(and he actually tested his setup) and same as Sumit, I'm not aware of
any limits.

It would be nice to illustrate the problems you are seeing with logs..
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Krb5.conf only sees first two kdc servers

[Jakub Hrozek via FreeIPA-users]

On Fri, Jul 28, 2017 at 02:05:05AM -, pgb 205 via FreeIPA-users wrote:
> Here is the log that I sent in yesterday. With
> server1 and server2 down, but server3 up.
> 
> kdc=server1
> kdc=server2
> kdc=server3
> kdc_master=server1
> kdc_master=server2
> kdc_master=server3
> 
> kinit tries server1 and server2 but never even attempts server3
> KRB5_TRACE=/dev/stdout kinit user(a)test.domain 
> [12536] 1501112935.251721: Getting initial credentials for user(a)test.domain 
> [12536] 1501112935.251917: Sending request (181 bytes) to test.domain
> [12536] 1501112935.251956: Resolving hostname server1
> [12536] 1501112935.252875: Sending initial UDP request to dgram server1_ip:88
> [12536] 1501112936.253962: Resolving hostname server2
> [12536] 1501112936.255680: Retrying AS request with master KDC
> [12536] 1501112936.255699: Getting initial credentials for user(a)test.domain
> [12536] 1501112936.255763: Sending request (181 bytes) to test.domain (master)
> [12536] 1501112936.255779: Resolving hostname server1
> [12536] 1501112936.256379: Sending initial UDP request to dgram server1_ip:88
> [12536] 1501112937.257451: Resolving hostname server2
> kinit: Invalid argument while getting initial credentials
> 
> kinit with following configuration will work, however.
> kdc=server1
> kdc=server2
> kdc=server3
> kdc_master=server1
> # kdc_master=server2
> kdc_master=server3

Interesting, but I admit I'm getting out of my depth here..

Perhaps some of the kerberos maintainers would like to chime in here?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

[Jakub Hrozek via FreeIPA-users]

On Mon, Jul 31, 2017 at 05:47:11PM -0400, Alexandre Pitre wrote:
> Bull-eye Jakub, that did the trick. I should have posted for help on the
> mailing list sooner. Thanks you so much, you are saving my ass.
> 
> It makes sense to increase the krb5_auth_timeout as my AD domain
> controllers servers are worldwide. Currently they exist in 3 regions: North
> America, Europe and Asia.
> 
> The weird thing is it seems that when a linux host try to authenticate
> against my AD, it just randomly select an AD DC from the _kerberos  SRV
> records. Normally, on the windows side, if "sites and services" are setup
> correctly with subnet defined and binded to sites, a windows client
> shouldn't try to authenticate against an AD DC that isn't local to his
> site. This mechanism doesn't  seem to apply to my linux hosts. Is it
> because it's only available for windows hosts ? Is there another way to
> force linux clients to authenticate against AD DC local to their site ?

We haven't implemented the site selection for the clients yet, only for
servers, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1416528

> 
> For now, I set the krb5_auth_timeout to 120 seconds. I had to completely
> stop sssd and start it again. A colleague mentioned that sssd has a known
> issue with restart apparently.

I'm not aware of any such issue..

> 
> Also, I'm curious about ports requirements. Going from linux hosts to AD, I
> only authorize 88 TCP/UDP. I believe that's all I need.

Yes, from the clients, that should be enough. The servers need more
ports open:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#prereq-ports
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: AD trust setup woes

[Jakub Hrozek via FreeIPA-users]

On Tue, Aug 01, 2017 at 11:20:16AM -, Igor Sever via FreeIPA-users wrote:
> I have the same error.
> I established two-way trust with AD which went fine.
> Authentication with Kerberos to AD is working.
> Since I have one test FreeIPA which is working correctly (relatively) I 
> compared logs and pinpointed problem to strange LDAP search which is FreeIPA 
> sending to DC:
> (&(sAMAccountName=domain\20admins)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)(!(gidNumber=0
> This LDAP query is of course not working on AD. I don’t know why FreeIPA is 
> sending this kind of query to AD in this case?
> Only difference that I can think of in this case is that I didn’t establish 
> trust in two steps, but in one step from FreeIPA using command switch 
> --two-way=true.

Pardon my ignorance, but what part of that query doesn't work?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: AD trust setup woes

[Jakub Hrozek via FreeIPA-users]

On Wed, Aug 02, 2017 at 11:40:46AM -, Igor Sever via FreeIPA-users wrote:
> There is no gidNumber attribute on AD group objects. If I want to apply
> posix attributes directly in AD, then I don't need FreeIPA, do I...

Many users and customers have an existing environment where some
machines are enrolled directly to AD and new ones are being added
directly to IPA and they want to use the same POSIX IDs every where.

Others choose to ID-map. 

As per why the idrange was selected as posix, see Justin's answer.

> https://blogs.technet.microsoft.com/activedirectoryua/2016/02/09/identity-management-for-unix-idmu-is-deprecated-in-windows-server/

Well, only the tools are deprecated, the schema is there to stay.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: SUDO Rules not getting processed

[Jakub Hrozek via FreeIPA-users]

On Fri, Aug 04, 2017 at 09:05:20AM -0300, Felipe Barreto Volpone via 
FreeIPA-users wrote:
> Hi Alka,
> 
> I think you can get useful info here: https://www.redhat.com/
> archives/freeipa-users/2017-May/msg00028.html

Also this might be useful to pinpoint the issue:
https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

[Jakub Hrozek via FreeIPA-users]

> On 4 Aug 2017, at 23:08, Alexandre Pitre via FreeIPA-users 
>  wrote:
> 
> Turns out, I'm still getting the same problem. It works right away after I 
> force clean the sssd cache: systemctl stop sssd ; rm -f /var/lib/sss/db/* 
> /var/log/sssd/* ; systemctl start sssd
> 
> After some time, trying to log back on the same system I see the login prompt 
> is much quicker when I type adu...@ad.com 
> Instead of getting a simple "Password:" prompt  I get adu...@ad.com 
> @centos.domain.ad.com 's 
> password.
> 
> If I login as root and stop/start and clean the sssd cache, it start working 
> again.
> 

Are you sure cleaning the cache is needed? Because I think your issue is 
different. The fact that you get a faster login prompt and the “Server not 
found…” message both point to the sssd going offline.

You could run ‘sssctl domain-status’ to show if the domain is online or offline 
(requires the ‘ifp’ service to be enabled until RHEL-7.4/upstream 1.15.x) or 
look into the logs for messages like “Going offline”.

> /var/log/messages is filled with:
> 
> centos sssd_be: GSSAPI Error: Unspecified GSS failure.  Minor code may 
> provide more information (Server krbtgt/ad@ipa.ad.com 
>  not found in Kerberos database)

This is the trust principal. Are you sure all your replicas are either trust 
agents or you ran “ipa-adtrust-install” on them?

> 
> 
> Any thoughts ?
> 
> Thanks,
> Alex
> 
> 
> On Tue, Aug 1, 2017 at 2:58 AM, Jakub Hrozek  > wrote:
> On Mon, Jul 31, 2017 at 05:47:11PM -0400, Alexandre Pitre wrote:
> > Bull-eye Jakub, that did the trick. I should have posted for help on the
> > mailing list sooner. Thanks you so much, you are saving my ass.
> >
> > It makes sense to increase the krb5_auth_timeout as my AD domain
> > controllers servers are worldwide. Currently they exist in 3 regions: North
> > America, Europe and Asia.
> >
> > The weird thing is it seems that when a linux host try to authenticate
> > against my AD, it just randomly select an AD DC from the _kerberos  SRV
> > records. Normally, on the windows side, if "sites and services" are setup
> > correctly with subnet defined and binded to sites, a windows client
> > shouldn't try to authenticate against an AD DC that isn't local to his
> > site. This mechanism doesn't  seem to apply to my linux hosts. Is it
> > because it's only available for windows hosts ? Is there another way to
> > force linux clients to authenticate against AD DC local to their site ?
> 
> We haven't implemented the site selection for the clients yet, only for
> servers, see:
> https://bugzilla.redhat.com/show_bug.cgi?id=1416528 
> 
> 
> >
> > For now, I set the krb5_auth_timeout to 120 seconds. I had to completely
> > stop sssd and start it again. A colleague mentioned that sssd has a known
> > issue with restart apparently.
> 
> I'm not aware of any such issue..
> 
> >
> > Also, I'm curious about ports requirements. Going from linux hosts to AD, I
> > only authorize 88 TCP/UDP. I believe that's all I need.
> 
> Yes, from the clients, that should be enough. The servers need more
> ports open:
> 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#prereq-ports
>  
> 
> 
> 
> 
> -- 
> Alexandre Pitre
> alexandre.pi...@gmail.com 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org 
> 
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: FreeIPA AD Trust. Clarifying Doubts before I proceed

[Jakub Hrozek via FreeIPA-users]

> On 7 Aug 2017, at 07:01, Sameer Gurung via FreeIPA-users 
>  wrote:
> 
> Hi All,
> 
> I have a network consisting of both windows and linux clients running windows 
> server 2008 (active directory) and centos 7 (freeipa). Obviously, the windows 
> clients authenticate against the AD DC (domain windows.foo) and the linux 
> clients against FreeIPA (Domain linux.bar) .  This setup is working fine. 
> However I now want to setup cross domain trust between the two domains and 
> had few doubts which I wanted to clear before I proceed.
> 
> I have gone through the steps of setting up this trust but I am not clear 
> about the following questions: 
> 
> 1. Am I right in thinking that I will have to add forwarders to the two 
> domains in the respective dns servers?
> 

This is described in http://www.freeipa.org/page/Active_Directory_trust_setup 
 (section 5.3)

> 2. Which DNS do I set in my linux clients? Do they still resolve against the 
> free IPA dns or the AD Dns? 

See the link above, it really depends on your infrastructure but if you already 
have the IPA server acting as a DNS server, then I would guess it would be IPA 
DNS and in the IPA DNS you would configure a conditional forwarder to the AD 
DNS.

> 
> 3. Also what will usernames will people use to login to the linux machines? 
> Do they need to specify only the username or the full usern...@windows.foo? 
> 

This depends on the IPA and SSSD version you are using. Up to IPA 4.5 and SSSD 
1.15, you would either use qualified names (u...@windows.foo 
) or ‘pin’ the short usernames to one domain with the 
default_domain_suffix. Starting with IPA 4.5 and SSSD 1.15 you can also set the 
domain resolution order:
http://www.freeipa.org/page/V4/AD_User_Short_Names 

https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html

> 4. What about the existing freeipa users? and what if there are same 
> usernames in freeipa and AD DC
> 

Conflicting usernames are distinguished between by qualifying them with the 
domain suffix (u...@windows.foo  versus u...@linux.bar 
)

> Any help will be much appreciated.
> with regards,
> 
> ---
> Sameer Kr. Gurung
> ---
> 
> This message contains confidential information and is intended only for the 
> individual named. If you are not the named addressee you should not 
> disseminate, distribute or copy this e-mail. Please notify the sender 
> immediately by e-mail if you have received this e-mail by mistake and delete 
> this e-mail from your system. E-mail transmission cannot be guaranteed to be 
> secure or error-free as information could be intercepted, corrupted, lost, 
> destroyed, arrive late or incomplete, or contain viruses. The sender 
> therefore does not accept liability for any errors or omissions in the 
> contents of this message, which arise as a result of e-mail transmission. If 
> verification is required please request a hard-copy version. 
> Saint Mary's College, Shillong, Meghalaya, India-793003,
> smcs.ac.in ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Unable to SSH into Linux machine using AD user

[Jakub Hrozek via FreeIPA-users]

> On 7 Aug 2017, at 07:38, Supratik Goswami via FreeIPA-users 
>  wrote:
> 
> 

Judging by:
(Mon Aug  7 05:30:14 2017) [[sssd[krb5_child[26789 [create_ccache] 
(0x0020): 735: [13][Permission denied]

I would check the permissions on the /tmp directory.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Unable to SSH into Linux machine using AD user

[Jakub Hrozek via FreeIPA-users]

Which sssd version is this on what OS?

stracing the sssd processes might help, using this in the [domain] section:
command = strace -ff -o /tmp/sssd_be_strace /usr/libexec/sssd/sssd_be 
--debug-level=10 --domain ipa.example.com --uid=0 --gid=0
(You’d need to substitute ipa.example.com  for your 
domain, just see how the processes are invoked normally in systemctl status 
sssd)

> On 7 Aug 2017, at 08:37, Supratik Goswami  wrote:
> 
> Hi Jakub
> 
> /tmp directory has permission 
> 
> drwxrwxrwt 7 root root 4096 Aug  7 05:46 /tmp
> 
> On Mon, Aug 7, 2017 at 11:57 AM, Jakub Hrozek  > wrote:
> 
> > On 7 Aug 2017, at 07:38, Supratik Goswami via FreeIPA-users 
> >  > > wrote:
> >
> > 
> 
> Judging by:
> (Mon Aug  7 05:30:14 2017) [[sssd[krb5_child[26789 [create_ccache] 
> (0x0020): 735: [13][Permission denied]
> 
> I would check the permissions on the /tmp directory.
> 
> 
> 
> 
> -- 
> Warm Regards
> 
> Supratik

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Unable to SSH into Linux machine using AD user

[Jakub Hrozek via FreeIPA-users]

> On 7 Aug 2017, at 10:42, Supratik Goswami  wrote:
> 
> SSSD version: sssd-1.13.0-40.7.amzn1.x86_64
> Linux OS: Amazon Linux 
> 
> I am seeing only these messages repeated continuously. 
> 
> (Mon Aug  7 08:37:49 2017) [sssd[be[ipa.corp.example.com 
> ]]] [sbus_message_handler] (0x2000): Received 
> SBUS method org.freedesktop.sssd.service.ping on path 
> /org/freedesktop/sssd/service
> (Mon Aug  7 08:37:49 2017) [sssd[be[ipa.corp.example.com 
> ]]] [sbus_get_sender_id_send] (0x2000): Not a 
> sysbus message, quit
> (Mon Aug  7 08:37:59 2017) [sssd[be[ipa.corp.example.com 
> ]]] [sbus_dispatch] (0x4000): dbus conn: 
> 0x12e4650
> (Mon Aug  7 08:37:59 2017) [sssd[be[ipa.corp.example.com 
> ]]] [sbus_dispatch] (0x4000): Dispatching.
> 
> 

This means sssd is idle and just receiving heartbeat pings from the monitor, 
did you attempt the login?

Btw the messages look like the debug logs, not the strace..

> On Mon, Aug 7, 2017 at 1:52 PM, Jakub Hrozek  > wrote:
> Which sssd version is this on what OS?
> 
> stracing the sssd processes might help, using this in the [domain] section:
> command = strace -ff -o /tmp/sssd_be_strace /usr/libexec/sssd/sssd_be 
> --debug-level=10 --domain ipa.example.com  --uid=0 
> --gid=0
> (You’d need to substitute ipa.example.com  for your 
> domain, just see how the processes are invoked normally in systemctl status 
> sssd)
> 
>> On 7 Aug 2017, at 08:37, Supratik Goswami > > wrote:
>> 
>> Hi Jakub
>> 
>> /tmp directory has permission 
>> 
>> drwxrwxrwt 7 root root 4096 Aug  7 05:46 /tmp
>> 
>> On Mon, Aug 7, 2017 at 11:57 AM, Jakub Hrozek > > wrote:
>> 
>> > On 7 Aug 2017, at 07:38, Supratik Goswami via FreeIPA-users 
>> > > > > wrote:
>> >
>> > 
>> 
>> Judging by:
>> (Mon Aug  7 05:30:14 2017) [[sssd[krb5_child[26789 [create_ccache] 
>> (0x0020): 735: [13][Permission denied]
>> 
>> I would check the permissions on the /tmp directory.
>> 
>> 
>> 
>> 
>> -- 
>> Warm Regards
>> 
>> Supratik
> 
> 
> 
> 
> -- 
> Warm Regards
> 
> Supratik

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

[Jakub Hrozek via FreeIPA-users]

> On 7 Aug 2017, at 18:11, Alexandre Pitre  wrote:
> 
> Clearing the sssd cache make the AD login works for a short while, it's 
> probably not necessary nor "production" ready. Looking at 
> /var/log/sssd/sssd_domain.ad.com .

Sure, but that’s not what I meant. What I meant is that just “systemctl restart 
sssd” clears the online/offline state.

Removing the sssd cache is not needed and can actually be quite dangerous. I 
wish people just stopped doing that, because in case credentials are cached, 
removing the cache also removes the credentials, leaving users with no way to 
authenticate.

> I do see offline messages:
> 
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
> [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 
> [Input/output error])
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
> [be_mark_offline] (0x2000): Going offline!
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
> [be_mark_offline] (0x2000): Enable check_if_online_ptask.
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
> [be_ptask_enable] (0x0400): Task [Check if online (periodic)]: enabling task
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
> [be_ptask_schedule] (0x0400): Task [Check if online (periodic)]: scheduling 
> task 65 seconds from now [1502119252]
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
> [be_run_offline_cb] (0x0080): Going offline. Running callbacks.
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
> [sdap_id_op_connect_done] (0x4000): notify offline to op #1
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
> [ipa_subdomains_refresh_connect_done] (0x0020): Unable to connect to LDAP 
> [11]: Resource temporarily unavailable
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
> [ipa_subdomains_refresh_connect_done] (0x0080): No IPA server is available, 
> cannot get the subdomain list while offline
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
> [be_ptask_done] (0x0040): Task [Subdomains Refresh]: failed with 
> [1432158212]: SSSD is offline
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
> [be_ptask_schedule] (0x0400): Task [Subdomains Refresh]: scheduling task 
> 14400 seconds from now [1502133587]
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
> [sdap_id_release_conn_data] (0x4000): releasing unused connection
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
> [be_ptask_online_cb] (0x0400): Back end is online
> 
> I uploaded  the full log file /var/log/sssd/sssd_domain.ad.com 
>  https://1drv.ms/f/s!AlZwwyQE2ZZ5p2ZmHLzmeKN7mBJ3 
> 
> 
> Both my IPA servers looks healthy.AD trust agent/controller server role are 
> installed on both.
> 
> ipa trustdomain-find ad.com  does return all of my AD domains 
> on both IPA servers.
> 

This is the failure in the logs:
(Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sdap_process_result] 
(0x2000): Trace: end of ldap_result list
(Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [write_pipe_handler] 
(0x0400): All data has been sent!
(Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [read_pipe_handler] 
(0x0400): EOF received, client finished
(Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sdap_get_tgt_recv] 
(0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_IPA.AD.COM], expired 
on [1502203793]
(Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sdap_cli_auth_step] 
(0x0100): expire timeout is 900
(Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sdap_cli_auth_step] 
(0x1000): the connection will expire at 1502118293
(Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send] (0x0100): 
Executing sasl bind mech: GSSAPI, user: host/centos.domain.ad.com
(Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send] (0x0020): 
ldap_sasl_bind failed (-2)[Local error]
(Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send] (0x0080): 
Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified 
GSS failure.  Minor c
ode may provide more information (Server krbtgt/ad@ipa.ad.com not found in 
Kerberos database)]

Is your client hostname in the AD domain (centos.domain.ad.com 
) or in the IPA domain (ipa.ad.com 
) ?

> Thanks,
> Alex
> 
> 
> 
> 
> 
> 
> 
> 
> On Sun, Aug 6, 2017 at 11:07 AM, Jakub Hrozek  > wrote:
> 
>> On 4 Aug 2017, at 23:08, Alexandre Pitre via FreeIPA-users 
>> > > wrote:
>> 
>> Turns out, I'm still getting the 

[Freeipa-users] Re: ID view is not overriding user attributes

[Jakub Hrozek via FreeIPA-users]

> On 9 Aug 2017, at 14:37, Supratik Goswami via FreeIPA-users 
>  wrote:
> 
> Can someone please help me to figure out the issue? 
> 
> Please let me know if any other information is required
> 

Describing how you set up the idview and providing SSSD logs is a good start.

-  idoverrideuser-show “Default Trust View” supratik.gos...@ad.corp.example.com 

- the same with —all —raw
- enable sssd logs on the client
- run: date; sss_ssh_authorizedkeys supratik.gos...@ad.corp.example.com 
; date
- attach the sssd logs

> On Wed, Aug 9, 2017 at 9:54 AM, Supratik Goswami  > wrote:
> (Wed Aug  9 04:20:14 2017) [sssd[be[ipa.corp.example.com 
> ]]] [sdap_get_generic_ext_step] (0x0400): 
> calling ldap_search_ext with 
> [(&(objectClass=ipaUserOverride)(uid=supratik.goswami))][cn=Default Trust 
> View,cn=views,cn=accounts,dc=ipa,dc=corp,dc=example,dc=com]
> 
> What I could see here is that it is searching as 'supratik.goswami' and not 
> 'supratik.gos...@ad.corp.example.com 
> ' which is the ID View user in 
> the IPA.
> 
> How do I fix this?
> 
> On Wed, Aug 9, 2017 at 8:53 AM, Supratik Goswami  > wrote:
> Hello everyone,
> 
> I have a trust setup between AD and IPA, I have created a user in the 
> "Default Trust View" and
> updated the ssh public keys for that user.
> 
> When I am trying to login to any Linux system using the ad user it is not 
> able to find the keys.
> 
> Here is the sshd debug log.
> 
> Aug  9 03:04:01 host01 sshd[20102]: debug3: Running AuthorizedKeysCommand: 
> "/usr/bin/sss_ssh_authorizedkeys supratik.gosw...@ad.corp.example.com 
> " as "nobody"
> Aug  9 03:04:01 host01 sshd[20102]: debug1: restore_uid: 0/0
> Aug  9 03:04:01 host01 sshd[20102]: debug1: temporarily_use_uid: 99/99 (e=0/0)
> Aug  9 03:04:01 host01 sshd[20106]: debug3: sshd_selinux_setup_variables: 
> setting execution context
> Aug  9 03:04:01 host01 sshd[20102]: debug2: key not found
> Aug  9 03:04:01 host01 sshd[20102]: debug1: restore_uid: 0/0
> 
> My sshd_config file has the following entries
> 
> AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
> AuthorizedKeysCommandUser nobody
> 
> What could be the issue?
> 
> 
> Thanks
> 
> -- 
> Warm Regards
> 
> Supratik
> 
> 
> 
> -- 
> Warm Regards
> 
> Supratik
> 
> 
> 
> -- 
> Warm Regards
> 
> Supratik
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org 
> 
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Unable to login with AD users

[Jakub Hrozek via FreeIPA-users]

> On 8 Aug 2017, at 16:58, Eddleman, David via FreeIPA-users 
>  wrote:
> 
> Hello,
>  
> I have created a FreeIPA solution using Red Hat’s IDM product.
> FreeIPA version: 4.5.0
> OS version: RHEL 7.4
>  
> I have successfully installed the server portion and can authenticate to it 
> using local IDM users, such as the ‘admin’ user. I have created a one-way 
> trust between the IPA realm and an AD realm successfully, as `ipa trust-show` 
> demonstrates, returning the SID of the domain. I have also created the local 
> POSIX and external groups and mapped them. `ipa group-show ` 
> returns the external member SID just fine.
>  
> However, I cannot authenticate in the server over SSH using one of those AD 
> users. I’ve checked the HBAC rules and they are fine. One thing I noticed 
> when monitoring the securelog when testing is that the IDM users make a call 
> to pam_sss, as expected, but the AD users do not.

This probably means the user can’t be resolved at all, so the authentication 
process doesn’t even make it to the PAM phase. Does ‘getent passwd 
user@domainfqdn’ work?

Are you testing on the IDM server itself or on one of the clients? I would 
suggest to make the IDM server work first.

Either way, you’ll want to enable the SSSD debug logs and take a look there.

> I have tried multiple ways of passing the user and all are rejected -- 
> user@netbios, user@domainfqdn, netbios\user, and domainfqdn\user.

Either netbios\user or user@domainfqdn work, the others do not.

>  
> The user in question is in a single group in AD, and it has been tested with 
> the group being both Domain Local and Universal with the same results. There 
> is only one member of the group, the user that I am attempting login with.

Don’t use domain-local groups. Domain-local groups can only be assigned to a 
cross-forest group membership by accident, IPA needs to be fixed to disallow 
that.

Domain-local groups are just that, local to the domain they are defined in and 
during login, the membership to a domain local group from a non-local domain is 
stripped from the PAC and would remove the group membership of the user in that 
group during login.

>  
> Have I missed something?
>  
> David Eddleman
>  
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org 
> 
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 
> 

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org