Re: [Freeipa-users] ipa-client-install: please look for SELINUX=disabled

[Lukas Slebodnik]

On (13/05/17 06:52), Harald Dunkel wrote:
>Hi folks,
>
>RHEL 7.3, sssd 1.14.0:
>
>If /etc/selinux/config says "SELINUX=disabled", then pam seems to fail
>(without telling why) and users cannot login. *Extremely* painful.
>
>Do you think ipa-client-install could add
>
>   selinux_provider = none
>
This is just a temporary workaround and not a solution.
And it is already fixed in upstream
https://pagure.io/SSSD/sssd/issue/3297

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] EL5 sudo and IdM

[Lukas Slebodnik]

On (02/05/17 00:36), Z D wrote:
>Hi, we've been using the IdM server 4.4.0 but still have some EL5 (build 
>system) we'd like to be ipa-clients. The ipa-client v2.1.3 has been installed, 
>that works well.
>
>And I believe that with EL5, there is no sssd support for sudo, hence it's 
>configured via /etc/ldap.conf
>
A little bit offtopic.

If you meant el5 == CentOS 5 then I would recommend to upgrade to el6

CentOS Linux 5 has reached End of Life, as of 31 March 2017
http://centosfaq.org/centos-announce/centos-linux-5-eol/

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Fedora 25 - SSSD: Smart card login is broken

[Lukas Slebodnik]

On (26/04/17 11:37), Sumit Bose wrote:
>On Tue, Apr 25, 2017 at 12:38:11PM -0500, Michael Rainey (Contractor) wrote:
>> Hello,
>> 
>> While using Fedora 25 we noticed smart card login is broken with the latest
>> update to SSSD.  A month or so ago a patch was created to fix the same
>> issue.  Here are some of the details:
>> 
>> Before Update:
>> 
>> sssd.x86_641.15.2-1.fc25sb1(was 1.15.2-1.fc25 before patch)
>> 
>> After Update:
>> 
>> sssd.x86_641.15.2-2.fc25
>> 
>> I was able to compared this to a freshly updated system to a system which
>> didn't receive the same update so I am confident lies with the package
>> update.
>
>ah, sorry, this is my fault, I forgot to create a Fedora bugzilla
>ticket, there is one for RHEL but not for Fedora. I just created
>https://bugzilla.redhat.com/show_bug.cgi?id=1445680 to track this for
>Fedora.
>
https://bodhi.fedoraproject.org/updates/FEDORA-2017-ac43ea8522

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Malformed representation of principal - krb5_child.log

[Lukas Slebodnik]

On (28/04/17 16:21), Sullivan, Daniel [CRI] wrote:
>Jakub,
>
>Thank you for your email.  We maintain our own repo that we populate from 
>Copr; your question led me to realize that the repo was broken and this 
>particular system was running an older version of sssd.   I upgraded it to 
>1.14.2-2.el6 and the problem was resolved.  Thank you Sumit and Jakub for your 
>help.  Have a nice weekend.
>
Do you really maintain own copr?
Or do you use https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/

I am just curious :-)

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SSSD setting memcache_timeout on ipa master

[Lukas Slebodnik]

On (04/04/17 09:41), Ronald Wimmer wrote:
>On 2017-03-31 13:35, Lukas Slebodnik wrote:
>> On (29/03/17 10:47), Ronald Wimmer wrote:
>> > Hi,
>> > 
>> > yesterday I suddenly was unable to use the webinterface of my ipa master. 
>> > SSH
>> > login (with root user) did not work also.
>> > 
>> > When I uncommented the setting "memcache_timeout = 600" in the sssd config
>> > file of the master everything seemed to work fine again. (my ipa setup has 
>> > a
>> > trust to AD)
>> > 
>> I doubt it had anything to do memcache_timeout.
>> I would say that restart of sssd helped. But it difficult to say
>> without log files. either sssd logs or at least /var/log/secure
>> (journald for pam).
>You were right. I uncommented the setting and the problem ocurred again.
>
Did you find anything suspicious in journald?
Is sssd_be busy (or any other process)?
high CPU, IO operations ...

It would be good to know more details. Restarting sssd is not a solution.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SSSD hangs on IPA master

[Lukas Slebodnik]

On (06/04/17 11:06), Ronald Wimmer wrote:
>On 2017-04-04 11:19, Jakub Hrozek wrote:
>> On Tue, Apr 04, 2017 at 09:51:04AM +0200, Ronald Wimmer wrote:
>> > Hi,
>> > 
>> > my IPA master has an AD trust (several thousand users). Since the trust has
>> > been set up I am experiencing that I cannot login on the web interface. 
>> > Even
>> > connecting via SSH does not work or takes extremely long. When I managed to
>> > log in as root via SSH (after waiting and trying several times or rebooting
>> > the machine) I could not restart SSSD (systemctl restart sssd). I had to
>> > kill the SSSD processes manually and then everything seemed to work fine
>> > again.
>> > 
>> > What could be going on? Could the SSSD cache be to big (122M)? Where should
>> > I take a deeper look?
>> > 
>> > Any hints are highly appreciated!
>> SSSD logs that capture the problem are always a good start.
>> 
>I found out that the CPU was quite busy (sssd_be process) and that there was
>a lot I/O in the cache directory. So I upgraded from 1 to 4 virtual CPUs and
>followed your recommendations regarding large deployments: 
>https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/
>
>No problems so far...
>
May I ask which version of sssd do you use?

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] libsemanage updates fail due to AD user with space

[Lukas Slebodnik]

On (04/04/17 09:32), Lukas Slebodnik wrote:
>On (04/04/17 10:13), Lachlan Musicman wrote:
>>On 3 April 2017 at 19:11, Jakub Hrozek <jhro...@redhat.com> wrote:
>>
>>> On Mon, Apr 03, 2017 at 11:00:21AM +1000, Lachlan Musicman wrote:
>>> >
>>> > With SSSD/IPA in use, in a one way trust to AD, and AD users have spaces
>>> in
>>> > their names, libsemanage fails to update:
>>> >
>>> > eg from recent monthly upgrade cycle:
>>> >
>>> > Updating   :
>>> > selinux-policy-targeted-3.13.1-102.el7_3.16.noarch
>>> > 3/14
>>> > libsemanage.parse_assert_ch: expected character ':', but found 'f'
>>> > (/etc/selinux/targeted/tmp/seusers.local: 5):
>>> > lastname firstn...@domain.com:unconfined_u:s0-s0:c0.c1023 (No such file
>>> or
>>> > directory).
>>> > libsemanage.seuser_parse: could not parse seuser record (No such file or
>>> > directory).
>>> > libsemanage.dbase_file_cache: could not cache file database (No such file
>>> > or directory).
>>> > libsemanage.semanage_base_merge_components: could not merge local
>>> > modifications into policy (No such file or directory).
>>> >
>>>
>>> Hi,
>>> according to my quick testing this is solved with this PR:
>>> https://github.com/SSSD/sssd/pull/189
>This patch will not help with spaces in name.
>
>it need to be fixed in selinux-policy or libsemanage.
>

It looks like it happen with each upgrade of selinux-policy.
I assume it might be some missing quoting in rpm bash scriptlet.

It should not be difficult to reproduce and file a bug.
Feel free to add to CC my mail.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] libsemanage updates fail due to AD user with space

[Lukas Slebodnik]

On (04/04/17 10:13), Lachlan Musicman wrote:
>On 3 April 2017 at 19:11, Jakub Hrozek  wrote:
>
>> On Mon, Apr 03, 2017 at 11:00:21AM +1000, Lachlan Musicman wrote:
>> >
>> > With SSSD/IPA in use, in a one way trust to AD, and AD users have spaces
>> in
>> > their names, libsemanage fails to update:
>> >
>> > eg from recent monthly upgrade cycle:
>> >
>> > Updating   :
>> > selinux-policy-targeted-3.13.1-102.el7_3.16.noarch
>> > 3/14
>> > libsemanage.parse_assert_ch: expected character ':', but found 'f'
>> > (/etc/selinux/targeted/tmp/seusers.local: 5):
>> > lastname firstn...@domain.com:unconfined_u:s0-s0:c0.c1023 (No such file
>> or
>> > directory).
>> > libsemanage.seuser_parse: could not parse seuser record (No such file or
>> > directory).
>> > libsemanage.dbase_file_cache: could not cache file database (No such file
>> > or directory).
>> > libsemanage.semanage_base_merge_components: could not merge local
>> > modifications into policy (No such file or directory).
>> >
>>
>> Hi,
>> according to my quick testing this is solved with this PR:
>> https://github.com/SSSD/sssd/pull/189
This patch will not help with spaces in name.

it need to be fixed in selinux-policy or libsemanage.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] 389-console and IPA

[Lukas Slebodnik]

On (29/03/17 14:05), Josh wrote:
>Hi Mark,
>
>Thanks for responding.
>
>Essentially I would like to change access log file size from 100Meg to 10Meg
>and change number of  log files down to 5 for example.
>
If you are a vi-user then you can try to use ldapvi.
It can even shouw you ldif which can be used with ldapmodify.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SSSD setting memcache_timeout on ipa master

[Lukas Slebodnik]

On (29/03/17 10:47), Ronald Wimmer wrote:
>Hi,
>
>yesterday I suddenly was unable to use the webinterface of my ipa master. SSH
>login (with root user) did not work also.
>
>When I uncommented the setting "memcache_timeout = 600" in the sssd config
>file of the master everything seemed to work fine again. (my ipa setup has a
>trust to AD)
>
I doubt it had anything to do memcache_timeout.
I would say that restart of sssd helped. But it difficult to say
without log files. either sssd logs or at least /var/log/secure
(journald for pam).

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certificate Access issue

[Lukas Slebodnik]

On (21/03/17 17:35), Alexander Bokovoy wrote:
>On ti, 21 maalis 2017, Lukas Slebodnik wrote:
>> On (21/03/17 16:29), Alexander Bokovoy wrote:
>> > On ti, 21 maalis 2017, Artem Golubev wrote:
>> > > We use sssd version 1.13.4 on our linux clients
>> > > A user from ipa successfully authorizes on a linux client via ssh 
>> > > without a
>> > > certificate. But then if we add a certificate - connection gets lost.
>> > If Lukas is correct, 1.13.4 does not have the fix for broken
>> > certificate-as-ssh public key:
>> > 
>> It has.
>> https://pagure.io/SSSD/sssd/issue/2977#comment-222198
>> https://pagure.io/SSSD/sssd/c/4dbb3bec93cda57e8336847dff0822f31425004d
>> 
>> It will be part of upstream release 1.13.5
>That's my point -- it is *not* part of 1.13.4, therefore, this is the
>problem Artem sees.
>
>Artem, what is your Linux distribution? Can you move to a newer version?
>
I would gues ubuntu :-)

You might file a bug to your distribution to backport patch from
the ticket https://pagure.io/SSSD/sssd/issue/2977

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certificate Access issue

[Lukas Slebodnik]

On (21/03/17 16:29), Alexander Bokovoy wrote:
>On ti, 21 maalis 2017, Artem Golubev wrote:
>> We use sssd version 1.13.4 on our linux clients
>> A user from ipa successfully authorizes on a linux client via ssh without a
>> certificate. But then if we add a certificate - connection gets lost.
>If Lukas is correct, 1.13.4 does not have the fix for broken
>certificate-as-ssh public key:
>
It has.
https://pagure.io/SSSD/sssd/issue/2977#comment-222198
https://pagure.io/SSSD/sssd/c/4dbb3bec93cda57e8336847dff0822f31425004d

It will be part of upstream release 1.13.5

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certificate Access issue

[Lukas Slebodnik]

On (20/03/17 16:39), Alexander Bokovoy wrote:
>On ma, 20 maalis 2017, Artem Golubev wrote:
>> Good day!
>> 
>> We use freeipa server 4.3.1, we usually grant access via ssh keys to linux
>> clients.
>> We currently face the following issue with access on certificate: when we
>> add certificate to user's account, user is not able to login via ssh.
>> How can we solve this problem? We would like to have  a possibility to
>> access linux clients via ssh keys and access to other resources using
>> certificates.
>You need to provide logs, obviously. Start with level 3 debug logs in
>sshd, and debug_level=9 in sssd. Also show user's entry (as in 'ipa
>user-show --raw --all username').
>
>When you access SSH with ssh keys, SSSD is involved in account and
>session phases of PAM authentication. This means either user does not
>exist to sshd (it would then don't exist on system level at all) or
>something prevents session phase from success. In session phase SSSD
>does verify HBAC rules, for example.
>
>See https://fedorahosted.org/sssd/wiki/Troubleshooting for
>troubleshooting instructions.
>
The most important is to know version of sssd.
Because one related bug is already fixed.
https://pagure.io/SSSD/sssd/issue/2977

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] compat and nested groups for Unix system

[Lukas Slebodnik]

On (20/03/17 17:00), Alexander Bokovoy wrote:
>On ma, 20 maalis 2017, Iulian Roman wrote:
>> Hello,
>> 
>> I noticed that nested group feature do not work with the unix ldap clients
>> (AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used. If
>> i use the cn=compat and change the mapping the nested groups are listed
>> properly.
>Compat tree implements RFC2307 schema which doesn't have nested groups.
>
>Main tree in FreeIPA uses RFC2307bis schema which supports nested
>groups.
>
But "Compat tree" is generated from "Main tree".
Therefore users must have the same groups in both cases.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] shadow netgroups with wrong domains - sudo problem

[Lukas Slebodnik]

On (17/03/17 13:52), Bob Hinton wrote:
>On 17/03/2017 12:48, Lukas Slebodnik wrote:
>> On (17/03/17 10:40), Bob Hinton wrote:
>>> On 17/03/2017 08:41, Jakub Hrozek wrote:
>>>> On Fri, Mar 17, 2017 at 06:50:34AM +, Bob Hinton wrote:
>>>>> Morning,
>>>>>
>>>>> We have a collection of hosts within prod1.local.lan. However, the
>>>>> domain section of the shadow netgroups for the hosts is
>>>>> mgmt.prod.local.lan. This seems to prevent sudo rules working on these
>>>>> hosts unless they specify all hosts -
>>>>>
>>>>> -sh-4.2$ getent netgroup oepp_hosts
>>>>> oepp_hosts   
>>>>> (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan)
>>>>> (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan)
>>>>> (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan)
>>>>> (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan)
>>>>> (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan)
>>>>> -sh-4.2$ hostname
>>>>> oeppredis001.z4.prod1.local.lan
>>>>> -sh-4.2$ nisdomainname
>>>>> local.lan
>>>>> -sh-4.2$ domainname
>>>>> local.lan
>>>>>
>>>>> The VMs associated with these hosts have recently been migrated and
>>>>> re-enrolled against a new IPA server. The originals all had netgroup
>>>>> domains of local.lan so something must have gone wrong in the migration
>>>>> process. Is there a way to correct the netgroup domains of these hosts,
>>>>> or is the only option to run ipa-client-install --uninstall followed by
>>>>> ipa-client-install to reattach them ?
>>>> Did you remove the sssd cache after the migration?
>>>> rm -f /var/lib/sss/db/*.ldb
>>>>
>>>> (please make sure the clients can reach the server or maybe mv the cache
>>>> instead of rm so you can restore cached credentials if something goes
>>>> wrong..)
>>>>
>>> Hi Jakub,
>>>
>>> I've now tried removing the sssd cache on one of the offending servers
>>> and it's not made any difference.
>>>
>>> getent netgroup oepp_hosts
>>>
>>> when run from any host enrolled to the new IPA servers, including the
>>> IPA masters themselves produces the results with "mgmt.prod" included
>>> and the same thing run on any of the pre-migrated servers that are still
>>> commissioned produces them without, so I assume that the netgroup domain
>>> information is coming from the IPA masters rather than the local host.
>>>
>> Could you provide content of LDIF from IPA server?
>> For this netgroup/hostgroup
>>
>> LS
>
>Hi Jakub,
>
>I extracted the following from the userRoot ldif produced by "ipa-backup
>--data".
>
>It appears to have the incorrect domain set against nisDomainName. Could
>this be changed with ldapmodify ?
>
>Thanks
>
>Bob
>
># entry-id: 1485
>dn: cn=oepp_hosts,cn=ng,cn=alt,dc=local,dc=lan
>ipaUniqueID: 186461fa-f91d-11e6-b43d-06642ebde14b
>modifyTimestamp: 20170222163643Z
>createTimestamp: 20170222163643Z
>modifiersName: cn=Managed Entries,cn=plugins,cn=config
>creatorsName: cn=Managed Entries,cn=plugins,cn=config
>mepManagedBy: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan
>description: ipaNetgroup oepp_hosts
>memberHost: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan
>cn: oepp_hosts
>nisDomainName: mgmt.prod.local.lan
And value of this attribute is an explanation to your question
why there is a different domain in netgroups.

>objectClass: ipanisnetgroup
>objectClass: ipaobject
>objectClass: mepManagedEntry
>objectClass: ipaAssociation
>objectClass: top
>nsUniqueId: f834f7a7-f91c11e6-a7d5eda5-d52d2b10

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] shadow netgroups with wrong domains - sudo problem

[Lukas Slebodnik]

On (17/03/17 10:40), Bob Hinton wrote:
>On 17/03/2017 08:41, Jakub Hrozek wrote:
>> On Fri, Mar 17, 2017 at 06:50:34AM +, Bob Hinton wrote:
>>> Morning,
>>>
>>> We have a collection of hosts within prod1.local.lan. However, the
>>> domain section of the shadow netgroups for the hosts is
>>> mgmt.prod.local.lan. This seems to prevent sudo rules working on these
>>> hosts unless they specify all hosts -
>>>
>>> -sh-4.2$ getent netgroup oepp_hosts
>>> oepp_hosts   
>>> (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan)
>>> (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan)
>>> (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan)
>>> (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan)
>>> (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan)
>>> -sh-4.2$ hostname
>>> oeppredis001.z4.prod1.local.lan
>>> -sh-4.2$ nisdomainname
>>> local.lan
>>> -sh-4.2$ domainname
>>> local.lan
>>>
>>> The VMs associated with these hosts have recently been migrated and
>>> re-enrolled against a new IPA server. The originals all had netgroup
>>> domains of local.lan so something must have gone wrong in the migration
>>> process. Is there a way to correct the netgroup domains of these hosts,
>>> or is the only option to run ipa-client-install --uninstall followed by
>>> ipa-client-install to reattach them ?
>> Did you remove the sssd cache after the migration?
>> rm -f /var/lib/sss/db/*.ldb
>>
>> (please make sure the clients can reach the server or maybe mv the cache
>> instead of rm so you can restore cached credentials if something goes
>> wrong..)
>>
>Hi Jakub,
>
>I've now tried removing the sssd cache on one of the offending servers
>and it's not made any difference.
>
>getent netgroup oepp_hosts
>
>when run from any host enrolled to the new IPA servers, including the
>IPA masters themselves produces the results with "mgmt.prod" included
>and the same thing run on any of the pre-migrated servers that are still
>commissioned produces them without, so I assume that the netgroup domain
>information is coming from the IPA masters rather than the local host.
>
Could you provide content of LDIF from IPA server?
For this netgroup/hostgroup

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] install freeipa amazon Linux

[Lukas Slebodnik]

On (13/03/17 00:16), barry...@gmail.com wrote:
>Hi:
>
>anyone has exp install freeipa in amazon linx base on fredora?
>
>I tried install repo myself but it fail only say no such freeipa
>
>which repo ishould use ...I already tried many difference source still fail.
>
>it seem it has its own amaz limux repo.
>
According to Amazon, they have issues with packaging Samba. I'd let them
to respond themselves, given they are the only ones who can respond on
why they are so insisting on not packaging Samba while providing one of
key infrastructure parts of AWS via Samba AD.

https://forums.aws.amazon.com/thread.jspa?threadID=164971

I would recommend either to use compat tree + nslcd
or use CentOS, RHEL, other distribution which has ipa-client

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Debian client installation

[Lukas Slebodnik]

On (22/02/17 17:35), Per Qvindesland wrote:
>Hi 
>
>Thanks for the answer.
>
>Is there any workaround for this that anyone can suggest?
>
There are two vesions of sudo packages in debian
sudo and sudo-ldap. IIRC the 1st one is compiled with sssd support
and 2nd one just with ldap support.

Which one do you use ?
You can check output of sudo --version | grep sss.

If neither of pacakges are compiled with sssd by default in wheezy
then you can try install packages from wheezy-backports.

And then I would recommend to follow instructions in manual page
sssd-sudo.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA Fedora 25 and IPA CentOS 7.3

[Lukas Slebodnik]

On (22/02/17 12:59), Alexander Bokovoy wrote:
>On ke, 22 helmi 2017, Ente Trompete wrote:
>> The next question which I have is: can I install a Fedora 25 and use
>> the included FreeIPA v4.4.1-3 to create a replica of the existing
>> 4.4.0-14? My problem is that I will use an ARM32 computer as replica
>> and Centos 7.3 runs properly on it but the repositories includes only
>> ipa-client packages. No ipa-server* package (BTW also for ARM64 is only
>> ipa-server-common available). But in the repositories of Fedora 25
>> ARM32 I can found all.
>Packages in Fedora are 'freeipa-*', packages in RHEL/CentOS are 'ipa-*'.
>
There is not any problem to install ipa-server on fedora.
There are provides.

sh# cat /etc/os-release
NAME=Fedora
VERSION="26 (Server Edition)"
ID=fedora
VERSION_ID=26
PRETTY_NAME="Fedora 26 (Server Edition)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:26"
HOME_URL="https://fedoraproject.org/;
BUG_REPORT_URL="https://bugzilla.redhat.com/;
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=rawhide
PRIVACY_POLICY_URL=https://fedoraproject.org/wiki/Legal:PrivacyPolicy
VARIANT="Server Edition"
VARIANT_ID=server

sh# dnf install ipa-server
Last metadata expiration check: 1:48:26 ago on Wed Feb 22 19:33:40 2017 CET.
Dependencies resolved.

 Package ArchVersion Repository
   Size

Installing:
 freeipa-server  x86_64  4.4.3-4.fc26rawhide  380 k
Installing dependencies:

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Client for CoreOS

[Lukas Slebodnik]

On (20/02/17 12:44), Igor Leão wrote:
>Is it possible to run a FreeIPA client on CoreOS?
>The OS misses some libraries and I didn't succeeded installing them.
>
>Has anyone faced this scenario?
>
You need to run everything in container even installer.

You might inspire in docker version of container.
https://hub.docker.com/r/fedora/sssd/

I am not sure whether it's possible to run with rocket.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] How to change kerberos key lifetime?

[Lukas Slebodnik]

On (16/02/17 18:05), William Muriithi wrote:
>> The fact that your desktops are using SSSD changes the situation 
>> dramatically.
>>
>> SSSD (with ipa or krb5 provider) obtains ticket for user when he is 
>> logging-in.
>> And can be configured to renew the ticket for the user until the ticket renew
>> life time expires.
>>
>> Given this you can keep ticket life time reasonable short (~1 day) set ticket
>> renewable life time to longer period (~2 weeks) and maintain reasonable
>> security level without negative impact on user's daily work.
>>
>> Look for krb5_renew_interval, krb5_lifetime, krb5_renewable_lifetime options
>> in sssd-krb5 man page.
>>
>Thanks a lot.  I did actually end up using this.   Will wait for a
>couple of days and see if anybody if the situation is better and
>update you.
>
>Curious though, why isn't renewal interval setup by default?  Is there
>a negative consequence of having SSSD renewing tickets by default?  I
>can't think of any and hence a bit lost on explaining the default
>setup

Desktop/laptop user usually does not need automatic renewal.
They authenticate/login/unlock screen quite often and for each
action sssd authenticate against IPA server which automatically get/renew
krb5 ticket. Unless machine is offline.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Cannot login after patching on LXC Container

[Lukas Slebodnik]

On (14/02/17 20:06), Nuno Higgs wrote:
>Hello all,
>
>I will reproduce the issue tomorrow morning on a fresh LXC container.
>For the sestatus:
>
># sestatus
>SELinux status: disabled
>
>That isn’t surprising for the host is not se-enabled, or even a RHEL/CentOS.
>The underlining distro supports apparmor profiles.
FYI: It is not about distribution but about kernel.

>The crappy part is before we did this patch update, everything worked
>perfectly, although with SE Disabled.
>
>I will keep you posted on the LXC test
>
It would be good to find out which package/update broke it.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Cannot login after patching on LXC Container

[Lukas Slebodnik]

On (14/02/17 18:52), Lukas Slebodnik wrote:
>On (14/02/17 18:28), Alexander Bokovoy wrote:
>>On ti, 14 helmi 2017, Nuno Higgs wrote:
>>> Hello,
>>> 
>>> It worked perfecty.
>>> I am wondering why this just popped up now with this patch update. Almost
>>> none of our containers hosts (and by inherence the containers) have SELINUX
>>> enabled for they are primary for testing, and they are on a secure network.
>>> With this version of ipa-client, the host has to have SE enabled for the
>>> container to inherit the definitions and policies of it?
>>As I said, this was an update in SELinux-related libraries and change of
>>behavior there, not in SSSD. It is reproducible in other environments as
>>well, see, f.e. https://bugzilla.redhat.com/show_bug.cgi?id=1415167
>>
>Sorry you are wrong.
>This is a different bug.
>https://bugzilla.redhat.com/show_bug.cgi?id=1412717
>which is unfortunatelly private.
>
I thought a little bit and I am not sure which bug is this case.
What do "sestatus" inside container?

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Cannot login after patching on LXC Container

[Lukas Slebodnik]

On (14/02/17 16:19), Nuno Higgs wrote:
>Hello,
>
>It worked perfecty.
>I am wondering why this just popped up now with this patch update. Almost
>none of our containers hosts (and by inherence the containers) have SELINUX
>enabled for they are primary for testing, and they are on a secure network.
>With this version of ipa-client, the host has to have SE enabled for the
>container to inherit the definitions and policies of it?
>
Could you try to downdrade some packages and find you which package trigger
this bug?

Or could you provide a reliable reproducer with lxc contianers?

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Cannot login after patching on LXC Container

[Lukas Slebodnik]

On (14/02/17 18:28), Alexander Bokovoy wrote:
>On ti, 14 helmi 2017, Nuno Higgs wrote:
>> Hello,
>> 
>> It worked perfecty.
>> I am wondering why this just popped up now with this patch update. Almost
>> none of our containers hosts (and by inherence the containers) have SELINUX
>> enabled for they are primary for testing, and they are on a secure network.
>> With this version of ipa-client, the host has to have SE enabled for the
>> container to inherit the definitions and policies of it?
>As I said, this was an update in SELinux-related libraries and change of
>behavior there, not in SSSD. It is reproducible in other environments as
>well, see, f.e. https://bugzilla.redhat.com/show_bug.cgi?id=1415167
>
Sorry you are wrong.
This is a different bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1412717
which is unfortunatelly private.

Here is an upstream ticket https://fedorahosted.org/sssd/ticket/3308

The interesting is that some user reported that downgrade of
ipa python packages fixed the bug as well.

12:23 < lfisher> lslebodn: well the problematic users seem to be ones that
haven't been on the host before
12:23 < lfisher> I also noticed if I updated the package, so I did an ipa
downgrade on the host (or version change) it started working temporarily
12:24 < lslebodn> which package?
12:25 < lslebodn> sssd?
12:25 < lslebodn> libsemanage?
12:27 < lfisher> well, the ipa-client package and everything that it depends
on, so it's like 7 packages
12:27 < lfisher> which may have libsemanage in it, let me check
12:27 < lslebodn> ipa-client is just an installator
12:28 < lslebodn> all important things are done by sssd
12:29 < lfisher> lslebodn: Give me a sec and I'll pull the package list out
...
12:34 < lfisher> ipa-client, ipa-client-common, ipa-common, python2-ipalib,
python2-ipaclient
12:34 < lfisher> a downgrade of those solved the problem tempoarily
12:40 < lslebodn> that's weird
12:41 < lslebodn> they are not used by sssd
12:41 < lslebodn> and they should not affect sssd
12:45 < lfisher> lslebodn: yeah, it didn't really make sense, but since
  even a restart sometimes solves
  the problem, it just probably kicked something

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Cannot login after patching on LXC Container

[Lukas Slebodnik]

On (14/02/17 13:00), Nuno Higgs wrote:
>Hello All,
>
> 
>
>I have a LXC container running Centos7, fully patched that i can't login
>into in a standard IPA usage configuration:
>
>
>Feb 13 19:42:07 lxc1 sshd[1536]: pam_sss(sshd:account): Access denied for
>user nuno 4 (System error)
>
System error means unexpected state for sssd.

I would recommend to follow sssd troubleshooting wiki
https://fedorahosted.org/sssd/wiki/Troubleshooting#TroubleshootingAuthenticationPasswordChangeandAccessControl


>Feb 13 19:42:07 lxc1 sshd[1536]: Failed password for nuno from 172.16.0.10
>port 54461 ssh2
>
>Feb 13 19:42:07 lxc1 sshd[1536]: fatal: Access denied for user nuno by PAM
>account configuration [preauth]
>
>Feb 13 19:43:42 lxc1 sshd[1553]: Connection closed by 172.16.3.253 [preauth]
>
>Feb 13 19:53:04 lxc1 sshd[1635]: pam_sss(sshd:auth): authentication success;
>logname= uid=0 euid=0 tty=ssh ruser= rhost=172.16.3.253 user=nuno
>
>Feb 13 19:53:04 lxc1 sshd[1632]: error: PAM: User account has expired for
>nuno from 172.16.3.253
>
This error is little bit later but I think it is clear enough.
The account is expired.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] performance scaling of sssd / freeipa

[Lukas Slebodnik]

On (20/01/17 20:18), Sullivan, Daniel [CRI] wrote:
>Sorry to clutter people's inboxes.  I found another piece of what I believe to 
>be useful information.  When this occurs the following entry also appears in 
>/var/log/messages.
>
>Jan 20 13:54:33 xxx.xxx.uchicago.edu winbindd[7090]: [2017/01/20 
>13:54:33.942448,  0] ipa_sam.c:4193(bind_callback_cleanup)
>Jan 20 13:54:33 xxx.xxx.uchicago.edu winbindd[7090]:   kerberos error: 
>code=-1765328228, message=Cannot contact any KDC for realm 
>‘XXX.XXX.UCHICAGO.EDU'
>Jan 20 13:54:33 xxx.xxx.uchicago.edu winbindd[7090]: [2017/01/20 
>13:54:33.943497,  0] ../source3/lib/smbldap.c:998(smbldap_connect_system)
>Jan 20 13:54:33 xxx.xxx.uchicago.edu winbindd[7090]:   failed to bind to 
>server ldapi://%2fvar%2frun%2fslapd-XXX-XXX-UCHICAGO-EDU.socket with 
>dn="[Anonymous bind]" Error: Local error
>Jan 20 13:54:33 xxx.xxx.uchicago.edu winbindd[7090]:   #011(unknown)
>Jan 20 13:55:16 xxx.xxx.uchicago.edu winbindd[7090]: [2017/01/20 
>13:55:16.970304,  0] ipa_sam.c:4193(bind_callback_cleanup)
>Jan 20 13:55:16 xxx.xxx.uchicago.edu winbindd[7090]:   kerberos error: 
>code=-1765328228, message=Cannot contact any KDC for realm 
>‘XXX.XXX.UCHICAGO.EDU'
>Jan 20 14:00:01 xxx.xxx.uchicago.edu systemd[1]: Created slice user-0.slice.
>
May I ask why you have configure sssd and winbind on the same machine?
Do you have configured winbind also in /etc/nsswitch.conf?

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]

[Lukas Slebodnik]

On (17/01/17 11:38), Sumit Bose wrote:
>On Tue, Jan 17, 2017 at 10:44:14AM +0100, Harald Dunkel wrote:
>> It seems something got corrupted in my ipa setup. I found this in the
>> sssd log file on Wheezy:
>> 
>> (Tue Jan 17 10:19:02 2017) [hbac_shost_attrs_to_rule] (0x0400): Processing 
>> source hosts for rule [allow_all]
>> (Tue Jan 17 10:19:02 2017) [hbac_eval_user_element] (0x0080): Parse error on 
>> [cn=System: Manage Host 
>> Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de]
>
>Looks like there was a replication conflict, please see
>https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
>how to resolve it.
>
>We already have a ticket for SSSD to ignore those object, but
>unfortunately there is currently no patch available for SSSD so you have
>to resolve the replication conflict to get it working again.
>
HBAC replication conflicts are already ignored in sssd.
But debian wheezy (oldstable) has very old version of sssd 1.8.4-2.
I would recommend to use at least 1.11.7-3 from jessie (debian stable)

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] report abuse

[Lukas Slebodnik]

On (16/01/17 07:53), Alexander Bokovoy wrote:
>On su, 15 tammi 2017, Jeff Clay wrote:
>> Not sure how this stuff is usually reported, but the person below needs 
>> removed from the group.
>This is a spam bot and it is *not* on the list of subscribers. We ran
>few experiments to find out that, you can check mailing list archives.
>
>The spam bot actually mines the mailing list archives and sends emails
>based on that one.
>
>We could close down mail archives from the non-subscribers. As a negative
>result, search engines will not be able to index it and this will reduce
>your ability to search FreeIPA-related solutions via search engines.
>
Maybe it would help to obfuscate email addresses in HTML version of
archive (at least domain part).
And hide gzipped text version for non-subscribers.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1

[Lukas Slebodnik]

On (09/01/17 12:44), James Harrison wrote:
>All,debian 1.8.19-1 doesnt work, but Ubuntu 1.8.12-1ubuntu3 does.
>
Could you provide sudo logs with 1.8.19-1
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

sssd log files will be helpfull as well.


LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [6]: Permission denied.

[Lukas Slebodnik]

On (08/01/17 17:13), TomK wrote:
>On 1/8/2017 12:22 AM, TomK wrote:
>> Hey All,
>> 
>> Wanted to tap your experience a bit.  Do you recall under which
>> conditions this error can be triggered under?
>> 
>> (Sun Jan  8 00:15:17 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200):
>> received: [6 (Permission denied)][mds.xyz]
>> (Sun Jan  8 00:15:17 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply
>> called with result [6]: Permission denied.
>> 
>> Pass is OK (tested) and UNIX Login for AD users works on the servers but
>> not the clients.
>> 
>Resolved.  It was multiple domains being listed in sssd.conf that caused
>this.
>
Could you be more specific?
sssd works well with multiple domains.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1

[Lukas Slebodnik]

On (06/01/17 17:15), James Harrison wrote:
>Any ideas?
>  From: James Harrison 
> To: "freeipa-users@redhat.com"  
> Sent: Thursday, 5 January 2017, 13:36
> Subject: FreeIPA sudo not working on ububtu xenial sssd version 
> 1.13.4-1ubuntu1.1
>   
>Hi all,I having problems with a FreeIPA client running Ububtu Xenial.
>I can authenticate OK, I get a kerberos ticket, but cannot run sudo.
>I get 1 rule returned, which I expect.
>Many thanks,James Harrison
>
>
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning 
>info for user [x_james.harri...@domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_rules] (0x0400): 
>Retrieving rules for [x_james.harrison] from [domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
>"ltdb_callback": 0x1c11d70
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
>(0x0200): Searching sysdb with 
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=x_james.harrison)(sudoUser=#1082600012)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%x_james.harrison)(sudoUser=+*))(&(dataExpireTimestamp<=1483618197)))]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to 
>get sudo rules from cache
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
>(0x0200): Searching sysdb with 
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=x_james.harrison)(sudoUser=#1082600012)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%x_james.harrison)(sudoUser=+*)))]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting 
>rules with higher-wins logic
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] 
>(0x0400): Returning 1 rules for [x_james.harri...@domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle 
>timer re-set for client [0x1c0e770][18]
>
Yes, 1 rule was returned for user x_james.harrison.
Can you see something in output of "sudo -l"


>==> sssd/sssd_pam.log <==
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [get_client_cred] (0x4000): Client 
>creds: euid[0] egid[1082600012] pid[5470].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [accept_fd_handler] (0x0400): Client 
>connected!
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): 
>Received client version [3].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered 
>version [3].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>
>==> auth.log <==
>Jan  5 12:10:17 pul-lp-sql-00 sudo: pam_unix(sudo:auth): authentication 
>failure; logname=x_james.harrison uid=1082600012 euid=0 tty=/dev/pts/1 
>ruser=x_james.harrison rhost=  user=x_james.harrison
>
I do not understand a reason why there is a failure in auth.log;
because there isn't sssd_pam.log @see above.

>==> sssd/sssd_pam.log <==
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_cmd_authenticate] (0x0100): 
>entering pam_cmd_authenticate
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): 
>name 'x_james.harrison' matched without domain, user is x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): command: 
>SSS_PAM_AUTHENTICATE
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: not 
>set
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): user: 
>x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sudo
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: 
>/dev/pts/1
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: 
>x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: not 
>set
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok 
>type: 1
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok 
>type: 0
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 0
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 5470
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: 
>x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_ncache_check_str] (0x2000): 
>Checking negative cache for [NCE/USER/domain.com/x_james.harrison]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_initgr_check_timeout] (0x4000): 
>User [x_james.harrison] not found in PAM cache.
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_dp_issue_request] (0x0400): 
>Issuing 

Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1

[Lukas Slebodnik]

On (05/01/17 15:38), Jakub Hrozek wrote:
>On Thu, Jan 05, 2017 at 01:36:56PM +, James Harrison wrote:
>> Hi all,I having problems with a FreeIPA client running Ububtu Xenial.
>> I can authenticate OK, I get a kerberos ticket, but cannot run sudo.
>> I get 1 rule returned, which I expect.
>> Many thanks,James Harrison
>
>I would check if (with the help of ldbsearch against the sssd cache or
>with the help of the sudo logs) if the rule is really the one you are
>expecting or if it's just the cn=defaults rule.
>
>If it's just cn=defaults, then I would check if the rules are downloaded
>(sssd always downloads all rules applicable for the host IIRC) or if
>they just don't match the filter that you can see in the debug message
>from sudosrv_get_sudorules_query_cache. Keep in mind that this is a
>filter that applies for the sssd cache, not LDAP.
>
>And lastly, if the rules are downloaded as expected, the sudo rules
>would tell you why the rule didn't match.
>
>All in all, this document:
>https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
>describes how to troubleshoot the sudo integration.
>
Or you might check older thread
https://www.redhat.com/archives/freeipa-users/2016-August/msg00489.html

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] nfsv4+kerberos: group ID not mapped on newly create users, however user id is correct

[Lukas Slebodnik]

On (08/12/16 10:24), Bjarne Blichfeldt wrote:
>> -Original Message-
>> From: David Kupka [mailto:dku...@redhat.com]
>> Sent: 8. december 2016 09:40
>> To: Bjarne Blichfeldt ; freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] nfsv4+kerberos: group ID not mapped on newly
>> create users, however user id is correct
>> 
>> On 08/12/16 08:57, Bjarne Blichfeldt wrote:
>> > Anybody have any suggestion as how to continue debugging this? The nfs 
>> > server
>> resolves usernames by loopkup in free-ipa lda.
>> >
>> > After a lot of digging, I see the 4.4 introduced "krbcanonicalname", no 
>> > idea if that
>> is relevant. Are there some update ldap procedure I am missing? Just in case 
>> I ran
>> a ipa-server-upgrade, which did not resolve the issue.
>> >
>> >
>:snip
>> >
>> >
>> 
>> Hello,
>> I'm almost sure that 'krbcanonicalname' has nothing to do with this.
>> Adding krbcanonicalname attribute was done to allow principal aliases 
>> (multiple
>> kerberos principals for one user/host/service), see [1] for details.
>> 
>> Unfortunately, I don't know what's wrong. SSSD is taking care of resolving 
>> users
>> and groups on enrolled systems. "id mgm" should output something like
>> "id=1414(mgm) gid=1414(mgm) groups=1414(mgm)" if it works properly.
>> 
>> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases
>> 
>> --
>> David Kupka
>
>Thank you for that info. That led me somewhat further by increasing the debug 
>on sssd which led me to :
>
>Dec  8 10:42:48 client nfsidmap[6663]: key: 0xae72f5 type: uid value: 
>m...@realm.com timeout 600
>Dec  8 10:42:48 client nfsidmap[6663]: nfs4_name_to_uid: calling 
>nsswitch->name_to_uid
>Dec  8 10:42:48 client nfsidmap[6663]: nss_getpwnam: name 'm...@realm.com' 
>domain 'REALM.COM': resulting localname 'mqm2'
>Dec  8 10:42:48 client nfsidmap[6663]: nfs4_name_to_uid: nsswitch->name_to_uid 
>returned 0
>Dec  8 10:42:48 client nfsidmap[6663]: nfs4_name_to_uid: final return value is >0
>
>Dec  8 10:42:48 client nfsidmap[6665]: key: 0xf56593 type: gid value: Null 
>timeout 600
>   
> ^
>Dec  8 10:42:48 client nfsidmap[6665]: nfs4_name_to_gid: calling 
>nsswitch->name_to_gid
>Dec  8 10:42:48 client nfsidmap[6665]: nfs4_name_to_gid: nsswitch->name_to_gid 
>returned -22
>Dec  8 10:42:48 client nfsidmap[6665]: nfs4_name_to_gid: final return value is 
>-22Seems nfsidmap is not called with a gid value.
>
>It seems nfsidmap is not called with a proper gid.
>hm, the saga continues...
>
You might want to use sss nfsidmap plugin.
* set method in /etc/idmap.conf to sss
* restart nfsidmapd

BTW In fedora and sssd-1.14 + it is part of recomended
package sssd-nfs-idmap (weak dependency)
older versions and other distributions might have packages in sssd-common
   /usr/lib64/libnfsidmap/sss.so

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Kerberos authentication failed: kinit: Included profile directory could not be read while initializing Kerberos 5 library

[Lukas Slebodnik]

On (03/01/17 20:35), Alan Latteri wrote:
>Well on new installs of Cent 7.2, when I do `yum install ipa-client`, that is 
>the version provided.
>Unfortunately, most of our systems have to be on Cent 7.2, not 7.3, and it is 
>out of our control.
>
You will install el7.3 on CentOS 7.2 by default.
If you want to stay on 7.2 you need to change repositories

sh# yum install --setopt=debuglevel=1 --assumeno sssd-client
Ignored option -q, -v, -d or -e (probably due to merging: -yq != -y -q)


 Package   ArchVersion   RepositorySize

Installing:
 sssd-client   x86_64  1.14.0-43.el7_3.4 updates  171 k
Installing for dependencies:
 libsss_idmap  x86_64  1.14.0-43.el7_3.4 updates  118 k
 libsss_nss_idmap  x86_64  1.14.0-43.el7_3.4 updates  116 k

Transaction Summary

Install  1 Package (+2 Dependent packages)

sh# yum-config-manager --disable base extras updates
sh# yum-config-manager --enable "C7.2.1511*"
sh# yum repolist
Loaded plugins: fastestmirror, ovl
Loading mirror speeds from cached hostfile
repo id repo name
status
C7.2.1511-base/x86_64   CentOS-7.2.1511 - Base9007
C7.2.1511-centosplus/x86_64 CentOS-7.2.1511 - CentOSPlus   134
C7.2.1511-extras/x86_64 CentOS-7.2.1511 - Extras   393
C7.2.1511-fasttrack/x86_64  CentOS-7.2.1511 - CentOSPlus 0
C7.2.1511-updates/x86_64CentOS-7.2.1511 - Updates 2560


sh# yum install --setopt=debuglevel=1 --assumeno sssd-client


 Package Arch  Version   RepositorySize

Installing:
 sssd-client x86_641.13.0-40.el7_2.12C7.2.1511-updates158 k
Installing for dependencies:
 libsss_idmapx86_641.13.0-40.el7_2.12C7.2.1511-updates104 k
 libsss_nss_idmapx86_641.13.0-40.el7_2.12C7.2.1511-updates103 k

Transaction Summary

Install  1 Package (+2 Dependent packages)


LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Minimum SSSD version for 2 factor

[Lukas Slebodnik]

On (03/01/17 10:15), Sean Hogan wrote:
>
>Morning,
>
>   Hope the Holidays went well for you all.
>
>   I have been trying to find documentation on the required min sssd
>version needed to run otp (2 factor) with no luck.  Was hoping you all
>might know.
>I see RHEL 6.8 comes with 1.13 SSSD so was wondering if that would be high
>enough version to work with IPA 4.X OTP.
>
sssd 1.13 could handle OTP but there is old MIT krb5
and therefore sssd is compiled without OTP feature in rhel6

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Upgrade to 4.4.0 Breaks login.

[Lukas Slebodnik]

On (27/12/16 10:08), Alan Latteri wrote:
>Can you provide an example of what file this entry should go into and what it 
>look like in file? Do you have to do this on the client side/ server or both?
>
Do you have the same problem?
Could you provide steps how do you run lxc container?

>Thanks,
>Alan
>
>> On Dec 23, 2016, at 4:43 AM, Dan Kemp  wrote:
>> 
>> That did it, thanks! I could have sworn I tried that, maybe I ended up 
>> putting it in in the wrong section. I wish whatever changed going from 4.2.0 
>> to 4.4.0 that made SELinux required, took the selinux enforcement level into 
>> account and updated the file accordingly.
>> 
BTW this bug is not related to ipa-client 4.2 or 4.4.
It might be caused by changes in sssd or libsemanage.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Upgrade to 4.4.0 Breaks login.

[Lukas Slebodnik]

On (23/12/16 10:29), Jakub Hrozek wrote:
>On Thu, Dec 22, 2016 at 08:38:38PM -0500, Dan Kemp wrote:
>> Hello,
>> 
>> I recently ran an upgrade of my freeipa servers, and most of the clients to
>> 4.4.0 (Current with CentOS 7 repos) from version 4.2.0. After the install
>> and server update, I can no longer log in to update clients via ssh. Login
>> to non-update clients works as before.
>> 
>> The SSH connections fail with:
>> 
>> Connection closed by UNKNOWN
>> 
>> I ran sssd with debugging on a failing 4.4.0 client and got this error log:
>> 
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit
>> ldb transaction (nesting: 2)
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit
>> ldb transaction (nesting: 1)
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit
>> ldb transaction (nesting: 0)
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]]
>> [selinux_child_create_buffer] (0x4000): buffer size: 45
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup]
>> (0x2000): Setting up signal handler up for pid [437]
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup]
>> (0x2000): Signal handler set up for pid [437]
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result]
>> (0x2000): Trace: sh[0x560c04c37790], connected[1], ops[(nil)],
>> ldap[0x560c04c32d60]
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result]
>> (0x2000): Trace: end of ldap_result list
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [write_pipe_handler]
>> (0x0400): All data has been sent!
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400):
>> selinux_child started.
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x2000):
>> Running with effective IDs: [0][0].
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x2000):
>> Running with real IDs [0][0].
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400):
>> context initialized
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
>> (0x2000): seuser length: 12
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
>> (0x2000): seuser: unconfined_u
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
>> (0x2000): mls_range length: 14
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
>> (0x2000): mls_range: s0-s0:c0.c1023
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
>> (0x2000): username length: 7
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
>> (0x2000): username: ipauser
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400):
>> performing selinux operations
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [sss_semanage_init]
>> (0x0020): SELinux policy not managed
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [get_seuser]
>> (0x0020): Cannot create SELinux handle
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437
>> [seuser_needs_update] (0x2000): get_seuser: ret: 5 seuser: unknown mls:
>> unknown
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [sss_semanage_init]
>> (0x0020): SELinux policy not managed
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [set_seuser]
>> (0x0020): Cannot init SELinux management
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0020):
>> Cannot set SELinux login context.
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0020):
>> selinux_child failed!
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [read_pipe_handler]
>> (0x0400): EOF received, client finished
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_done]
>> (0x0020): selinux_child_parse_response failed: [22][Invalid argument]
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_done] (0x0400):
>> DP Request [PAM SELinux #3]: Request handler finished [0]: Success
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [_dp_req_recv]
>> (0x0400): DP Request [PAM SELinux #3]: Receiving request data.
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor]
>> (0x0400): DP Request [PAM SELinux #3]: Request removed.
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor]
>> (0x0400): Number of active DP request: 0
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_pam_reply]
>> (0x1000): DP Request [PAM Account #2]: Sending result [4][domain.local]
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler]
>> (0x1000): Waiting for child [437].
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler]
>> (0x0020): child [437] failed with status [1].
>> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000):
>> 0x55f4be11f4c0
>> (Wed Dec 20 20:38:13 2016) [sssd[pam]] 

Re: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account

[Lukas Slebodnik]

On (08/12/16 16:10), James Harrison wrote:
>Hi,From this URL: https://launchpad.net/~sssd/+archive/ubuntu/updates
>i updated sssd on Trusty and I can now ssh to it using a FreeIPA user's  
>credentials. AD Still doesn't work.
>Thanks
>
That just mean that 1.12.5-1~trusty1 has still some bugs
which are fixed in sssd-1.13.4 (in ubuntu 16.04).
You mentioned that in different mail.

I would recommend to use LTS version of sssd-1.13
which is the oldest version maintaned by upstream.
You might file bugs to ubuntu for fixing old version of sssd in trusty
(1.11) but it will be much simpler to ask for backporting
1.13.4 into launchpad.

Based on ubuntu page[1] precise(12.04) will be EOL very soon
you should really consider to use newer version
The ideal would be to use ubuntu 16.04.

LS

[1] https://www.ubuntu.com/info/release-end-of-life

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account

[Lukas Slebodnik]

On (07/12/16 18:19), James Harrison wrote:
>Hi all,
>
>I am trying to authenticate an ubuntu Precise (12.06) fully patched system. 
>Its enrolled into a FreeIPA server. The following trace is the output of 
>syslog auth sssd/*.log and full debug (-ddd) from the sshd service.
>
Are you able to reproduce with ubuntu 14.04
and sssd from trusty-updates(1.11.8-0ubuntu0.3)
You might also consig=der to test sssd-1.13.4 (in ubuntu 16.04)
or at least 1.12.5-1~trusty1 from ppa
https://launchpad.net/~sssd

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Clonning VM

[Lukas Slebodnik]

On (28/11/16 13:10), Esdras La-Roque wrote:
>Hi Guys,
>
>What's the safe method to clone an virtual machine that is in IPA ?
>
>I tried do this already, but I had many troubles related with IPA to fix.
>
Why do you need to create clone?
IMHO, It's much simpler to create replica of IPA (including CA replica).

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ns-slapd segfault

[Lukas Slebodnik]

On (28/11/16 12:39), Giulio Casella wrote:
>Hello,
>
>I have a setup with two ipa server in replica, based on CentOS 7.
>On one server (since a couple of days) ipa cannot start, the failing service
>is dirsrv@.service.
>In journal I have:
>
>ns-slapd[4617]: segfault at 7fb53b1ce515 ip 7fb50126e1a6sp
>7ffc0b80d6c8 error 4 in libc-2.17.so[7fb501124000+1b7000]
>
>(just after a lot of SSL alerts complaining about some enabled cypher suite,
>but I cannot say if this could be related).
>
>I'm using ipa 4.2.0, and 389-ds-base 1.3.4.
>
It would be good to know the exact version.
rpm -q 389-ds-base

Please provide backtrace or coredump; other developers will know
wheter it's know bug or a new bug.

http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-crashes

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Shadow Utils appears in sssd.conf

[Lukas Slebodnik]

On (22/11/16 10:16), Lachlan Musicman wrote:
>Great - thank you. That worked.
>
I am not sure what is working now.
Did the domain "domain/shadowutils" cause any problems to you?

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] keytab kvno differs between ipa servers

[Lukas Slebodnik]

On (21/11/16 13:54), Bjarne Blichfeldt wrote:
>ok Thanks
>
>I will try to debug that.  No errors in the logs, the ldapsearch from your 
>link works fine..
>ok work ahead...
>
>Regards
>
>Bjarne Blichfeldt
>
man 1 ipa-getkeytab says:
   WARNING: retrieving the keytab resets the secret for the Kerberos prin‐
   cipal.  This renders all other keytabs for that principal invalid.

and also there is an option:
   -r Retrieve  mode. Retrieve an existing key from the server instead
  of generating a new one. This is incompatibile with the  --pass‐
  word  option,  and  will work only against a FreeIPA server more
  recent than version 3.3. The user  requesting  the  keytab  must
  have access to the keys for this operation to succeed.

HTH

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Shadow Utils appears in sssd.conf

[Lukas Slebodnik]

On (16/11/16 11:46), Lachlan Musicman wrote:
>I don't know what I've done wrong, but when I use ipa-client-install on a
>new host to add to my one way trust domain, I now have a
>[domain/shadowutils] stanza.
>
>This first happened a couple of weeks ago, I saw this bug and thought "it
>will be solved soon".
>
>https://bugzilla.redhat.com/show_bug.cgi?id=1369118
>
>The report says it's been resolved in a recent advisory but I'm still
>seeing the error.
>
It was fixed by reverting upstream commit which
introduced such seature.
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=59744cff6edb106ae799b2321cb8731edadf409a

>Is it because I'm using sssd 1.14.2-1 from COPR instead of the centrally
>supplied sssd?
>
Yes, theis feature is still available in upstream/fedora.

A) "domain/shadowutils" should not cause any problems.
   If yes then it should be also reproducible on fedora
   please filae a bug.

B) It does not happen with SELinux in enforcing mode.
   Another reason for "setenforce 1" :-)

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] system to pick up pa user-mod --uid change - how long?

[Lukas Slebodnik]

On (08/11/16 15:09), Brian Candler wrote:
>On 08/11/2016 13:57, lejeczek wrote:
>> I've changed an uid of a.user but system: $ id a.user - still shows old
>> id.
>> When is the system supposed to notice that change?
>
>You might want to force the cache to expire early. Try:
>
>sss_cache -U
>
>or
>
>sss_cache -u 
>
>(I'm afraid I don't know what the automatic expiry time is)
>
In worst case, it would be a 1.5 hour by default.
That's the reason why there is an utility sss_cache

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Configuring httpd error when selinux is permissive

[Lukas Slebodnik]

On (08/11/16 16:57), 郑磊 wrote:
>Command returns the result:
>root@ipaserver:/tmp/freeipa-4.3.1# /usr/sbin/setsebool -P 
>httpd_can_network_connect=on httpd_run_ipa=on httpd_manage_ipa=on
>Cannot set persistent booleans without managed policy.
>
>root@ipaserver:/tmp/freeipa-4.3.1# /usr/sbin/getsebool httpd_run_ipa
>Error getting active value for httpd_run_ipa
>
Then it just mean that selinux-policy on ununtu does not contain
such boolean.

You have few options:
* create your own SELinux rules
* backport SELinux rules from upstream/fedora
* Use freeIPA with SELinux on different distribution.
* use freeIPA without SELinux on ubuntu (IIRC the default is Apparmor)

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA Server installation on ubuntu 14.0

[Lukas Slebodnik]

On (13/10/16 08:15), Deepak Dimri wrote:
>
>Hi Alexander,
>
>I have tried it on ubuntu 16.04 as well but no luck either.  Getting the same 
>error:
>
>
>sudo apt-get install freeipa-server
>
>Reading package lists... Done
>
>Building dependency tree
>
>Reading state information... Done
>
>E: Unable to locate package freeipa-server
>
>any other ideas? I dont  find any good response to this issue either..
>
freeipa-server is only in xenial (16.04 + universe)
http://packages.ubuntu.com/xenial/freeipa-server

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sss / nsswitch

[Lukas Slebodnik]

On (23/09/16 10:31), Rob Verduijn wrote:
>2016-09-23 10:27 GMT+02:00 Lukas Slebodnik <lsleb...@redhat.com>:
>
>> On (13/09/16 16:18), Rob Verduijn wrote:
>> >2016-09-13 15:07 GMT+02:00 Lukas Slebodnik <lsleb...@redhat.com>:
>> >
>> >> On (13/09/16 10:39), Sumit Bose wrote:
>> >> >On Tue, Sep 13, 2016 at 10:13:12AM +0200, Rob Verduijn wrote:
>> >> >> Hi,
>> >> >>
>> >> >> Thanks that did it.
>> >> >>
>> >> >> Is there a less painfull way to be notified of these changes ?
>> >> >>
>> >> >> My nfs configuration gets broken much more than I like because of
>> >> changes
>> >> >> like these.
>> >> >> I know fedora is supposed to be testing grounds unstable software,
>> but I
>> >> >> would really like to hear a heads up more often.
>> >> >
>> >> >The change was mentioned in the upstream release notes of SSSD-1.14.1
>> >> >https://fedorahosted.org/sssd/wiki/Releases/Notes-1.14.1 but of
>> course I
>> >> >cannot be expected to read all upstream release note before running
>> 'dnf
>> >> >update'.
>> >> >
>> >> >The change was necessary because before the plugin was in the
>> >> >sssd-common package and this caused that some nfs dependencies were
>> >> >pulled in even on systems where nfs is not needed at all. Since neither
>> >> >SSSD nor nfs-idmap strictly require the plugin the new package is not
>> >> >automatically installed during update.
>> >> >
>> >>
>> >> Sorry for troubles. We can add weak dependency info sssd-common on
>> >> sssd-nfs-idmap and it might be installed by default.
>> >> IIRC dnf does not inform about suggested packages; but recommends minght
>> >> work. Feel free ot file a BZ.
>> >>
>> >> The reason why it is in separate package is "container world".
>> >> You need to have install packge sssd-nfs-idmap on host
>> >> but sssd can be running in container.
>> >>
>> >> LS
>> >>
>> >
>> >
>> >I probably should've noticed that the version number went from 1.13.x to
>> >1.14.x which usually is something noteworthy.
>> >I'll just add the release notes from sssd to my list of must reads when
>> >there is an update.
>> >
>> The package sssd-nfs-idmap should be installed with sssd-1.14.1-3
>> It needn't be due to weak dependencies. But recommended packages
>> are installed by default with dnf.
>>
>> rpm -q --recommends  sssd-common-1.14.1-3
>> libsss_autofs(x86-64) = 1.14.1-3.fc24
>> libsss_sudo = 1.14.1-3.fc24
>> sssd-nfs-idmap = 1.14.1-3.fc24
>>
>> LS
>>
>
>Does this also apply when you run dnf update ?
>
[root@38f0074bee78 /]# rpm -q sssd
sssd-1.13.4-3.fc24.x86_64
[root@38f0074bee78 /]# ls -l /usr/lib64/libnfsidmap/sss.so
-rwxr-xr-x. 1 root root 32232 May 13 09:42 /usr/lib64/libnfsidmap/sss.so

[root@38f0074bee78 /]# dnf update sssd
Last metadata expiration check: 0:13:13 ago on Fri Oct 14 19:28:24 2016.
Dependencies resolved.

 Package  Arch Version  Repository Size

Installing:
 adclix86_64   0.8.0-2.fc24 fedora 93 k
 http-parser  x86_64   2.7.1-2.fc24 updates34 k
 jansson  x86_64   2.9-1.fc24   updates40 k
 sssd-nfs-idmap   x86_64   1.14.1-3.fc24updates69 k
Upgrading:
 libini_configx86_64   1.3.0-29.fc24updates66 k
 libipa_hbac  x86_64   1.14.1-3.fc24updates76 k
 libsss_idmap x86_64   1.14.1-3.fc24updates80 k
 python3-sssdconfig   noarch   1.14.1-3.fc24updates   102 k
 sssd x86_64   1.14.1-3.fc24updates68 k
 sssd-ad  x86_64   1.14.1-3.fc24updates   188 k
 sssd-client  x86_64   1.14.1-3.fc24updates   132 k
 sssd-common  x86_64   1.14.1-3.fc24updates   1.2 M
 sssd-common-pac  x86_64   1.14.1-3.fc24updates   113 k
 sssd-ipa x86_64   1.14.1-3.fc24updates   260 k
 sssd-krb5x86_64   1.14.1-3.fc24updates

Re: [Freeipa-users] 2FA using FreeIPA

[Lukas Slebodnik]

On (21/09/16 08:49), Deepak Dimri wrote:
>hi LS,
>I am using IPA Server - VERSION: 4.2.0, API_VERSION: 2.156sssd version on my 
>IPA server: 1.13.0sssd version on my IPA client (ubuntu): 1.11.8
>I have new "testhip2user" created in IPA Server with 2FA enabled. My 
>/etc/ssh/sshd_config has this entry 
Could you try with newer version of sssd on client (ubuntu 16.04)

It is possible that libkrb5 (MIT) is too old and does not support OTP.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sss / nsswitch

[Lukas Slebodnik]

On (13/09/16 16:18), Rob Verduijn wrote:
>2016-09-13 15:07 GMT+02:00 Lukas Slebodnik <lsleb...@redhat.com>:
>
>> On (13/09/16 10:39), Sumit Bose wrote:
>> >On Tue, Sep 13, 2016 at 10:13:12AM +0200, Rob Verduijn wrote:
>> >> Hi,
>> >>
>> >> Thanks that did it.
>> >>
>> >> Is there a less painfull way to be notified of these changes ?
>> >>
>> >> My nfs configuration gets broken much more than I like because of
>> changes
>> >> like these.
>> >> I know fedora is supposed to be testing grounds unstable software, but I
>> >> would really like to hear a heads up more often.
>> >
>> >The change was mentioned in the upstream release notes of SSSD-1.14.1
>> >https://fedorahosted.org/sssd/wiki/Releases/Notes-1.14.1 but of course I
>> >cannot be expected to read all upstream release note before running 'dnf
>> >update'.
>> >
>> >The change was necessary because before the plugin was in the
>> >sssd-common package and this caused that some nfs dependencies were
>> >pulled in even on systems where nfs is not needed at all. Since neither
>> >SSSD nor nfs-idmap strictly require the plugin the new package is not
>> >automatically installed during update.
>> >
>>
>> Sorry for troubles. We can add weak dependency info sssd-common on
>> sssd-nfs-idmap and it might be installed by default.
>> IIRC dnf does not inform about suggested packages; but recommends minght
>> work. Feel free ot file a BZ.
>>
>> The reason why it is in separate package is "container world".
>> You need to have install packge sssd-nfs-idmap on host
>> but sssd can be running in container.
>>
>> LS
>>
>
>
>I probably should've noticed that the version number went from 1.13.x to
>1.14.x which usually is something noteworthy.
>I'll just add the release notes from sssd to my list of must reads when
>there is an update.
>
The package sssd-nfs-idmap should be installed with sssd-1.14.1-3
It needn't be due to weak dependencies. But recommended packages
are installed by default with dnf.

rpm -q --recommends  sssd-common-1.14.1-3
libsss_autofs(x86-64) = 1.14.1-3.fc24
libsss_sudo = 1.14.1-3.fc24
sssd-nfs-idmap = 1.14.1-3.fc24

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sssd.conf - the server and host-client relationship

[Lukas Slebodnik]

On (22/09/16 08:53), Lachlan Musicman wrote:
>My translations of your comments are in line, if you could correct, I'd
>appreciate that.
>
>On 20 September 2016 at 17:11, Lukas Slebodnik <lsleb...@redhat.com> wrote:
>
>> >--
>> >[domain/unixdev.etc]
>> >ignore_group_members = True
>> It was probably set as a result of performance tuning.
>>
>> >ldap_purge_cache_timeout = 0
>> That's default since 1.13.0
>>
>> >subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout
>> that's specific option for sssd on IPA server
>>
>
>
>I presume your comment suggests ignore_group_members is no longer needed,
>and since the lpct=0 is now default, then subdomain_inherit is also
>superfluous?
>
I have no idea why the option ignore_group_members was set.
My assumption is that you wanted to reduce loading data from IPA/AD
because they were many members in groups and it was slow.

>
>
>> >selinux_provider = none
>> It was probably set as a workaround of bug which have been already
>> fixed.
>>
>
>We set this because of an error in libsemanage, but I think that was an
>upstream (selinux) issue?
>https://www.redhat.com/archives/freeipa-users/2016-July/msg00244.html
>
>Not sure if I should disable just yet - was this fixed?
It should be fixed if not file a bug.

>>
>> >ipa_server_mode = True
>> that's specific option for sssd on IPA server
>>
>>
>I take it that this means it's still used.
>
yes, but it is used only on in sssd which is on IPA server.

>
>> >sudo_provider = ldap
>> >ldap_uri = ldap://vmdv-linuxidm1.unixdev.petermac.org.au
>> >ldap_sudo_search_base = or=sudoers,dc=unixdev,dc=petermac,dc=org,dc=au
>> >ldap_sasl_mech = GSSAPI
>> >ldap_sasl_authid = host/vmdv-linuxidm1.unixdev.petermac.org.au
>> >ldap_sasl_realm = UNIXDEV.PETERMAC.ORG.AU
>> >krb5_server = vmdv-linuxidm1.unixdev.petermac.org.au
>> Previous 7 options are not required since sssd-1.10
>>
>
>Yep, I added those because of disconnect between the different info sources
>made it hard to tell what was canonical, so I followed the red hat guide:
>
>https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-ldap-sudo.html
>
>mostly because I didn't quite understand the sssd-sudo man page (because
>sometimes I find man pages obtuse), but also there was an inconsistency
>with the local man page and the die.net mirror
>https://linux.die.net/man/5/sssd-sudo and this howto
>https://blog-rcritten.rhcloud.com/?p=52
>
The best is to check version of man page sssd-sudo on the machine
But as I wrote "sudo_provider = ldap" is not required for ipa client
since sssd-1.10 and most of current distributions has newer version
of sssd.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] HBAC doesn't work issues

[Lukas Slebodnik]

On (19/09/16 16:43), Lachlan Musicman wrote:
>I must have made an error again:
>
>- ipa hbactest gives seemingly correct answer on both server and client
>- user can't actually use sudo on client?
>
>Centos 7, freeipa 4.2.o/2.156; sssd 1.14.1 from COPR
>
>>From the server:
>
>[root@vmdv-linuxidm1 ~]# ipa hbactest --user=lsimp...@petermac.org.au
>--host=vmts-linuxclient1.unixdev.petermac.org.au --service=sudo
>
>Access granted: True
>
>  Matched rules: Cluster Admin Users (sudo)
>  Not matched rules: Cluster Users
>[root@vmdv-linuxidm1 ~]#
>
>
>>From the host in question:
>
>[root@vmts-linuxclient1 ~]# ipa hbactest --user lsimp...@petermac.org.au
>--host `hostname` --service sudo
>
>Access granted: True
>
>  Matched rules: Cluster Admin Users (sudo)
>  Not matched rules: Cluster Users
>[root@vmts-linuxclient1 ~]#
>
>
>[lsimp...@petermac.org.au@vmts-linuxclient1 ~]$ sudo reboot
>[sudo] password for lsimp...@petermac.org.au:
>lsimp...@petermac.org.au is not allowed to run sudo on vmts-linuxclient1.
>This incident will be reported.
>
Did you configure sudo rules for such user?
What is an output of "sudo -l"

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SELinux is preventing /usr/sbin/krb5kdc from write access on the sock_file /var/lib/sss/pipes/pac.

[Lukas Slebodnik]

On (17/09/16 12:02), lejeczek wrote:
>before I drop above onto SELinux team - do you guys think SE should be doing
>that? Does it impair IPA in some ways?
>
It would be god to see more details. Do you know which action trigger
AVCs?

Could you also provide detail about AVC?
ausearch -m avc -i ts recent

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Problems with mount and user logins

[Lukas Slebodnik]

On (17/09/16 08:20), Detlev Habicht wrote:
>Hi all,
>
>i am setting up IPA the first time for real life and have now
>some big problems.
>
>First for testing i setup an IPA-Server, a NFS server and up
>to 3 clients. The server are running Scientic Linux and the clients
>Federo 24 (setup via Cobbler server). The setup is based on the Red Hat Linux 
>7 IPA Docs.
>
>This was running well over several weeks. I can reinstall my clients
>via cobbler and everything was good.But mostly with one user (me).
>
>Now i was adding 20 hosts and the first time big problems
>are coming.
>
>First, one problem has nothing to do with IPA: I found bug reports
>about new autofs problems with Fedora 24. autofs is starting 
>at the wrong time and sssd too.
>
There are some patches pending review which should help in this case
https://lists.fedorahosted.org/archives/list/sssd-de...@lists.fedorahosted.org/message/UKWFVD7NBYTLW6VW5W6TBSTCWOMP5C2V/

I plan to backport them to fedora immediately after accepting in upstream.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Issues with FreeIPA SSH Key authentication

[Lukas Slebodnik]

On (15/09/16 11:46), Venkataramana Kintali wrote:
>Hi Lukas,
>ssh_config is also same on all servers.
>Our need is to do it both  ways, to be able to login with ssh public
>keys(uploaded in IPA) and disable password login, and be able to access
>allhosts within the same IPA domain silently from any host.
>Hoping the configs will help, I am including the configurations here.
>
>ssh_config file :  http://pastebin.com/MWHyH1Qw
>sshd_config file: http://pastebin.com/gpn5XhXM
>sssd_config file: http://pastebin.com/5Pby6xKp
>
Looks good to me

>I just used some placeholders for sssd_config file in pastebin instead of
>actual values.
>

In initial mail you wrote:
>I am able to login to some IPA clients but not able to login to other IPA
>clients with putty using private key and passphrase.
Therefore your previous test case is wrong.
If you want to test authentication with public keys
then you cannot obtain krb5 ticket with kinit.

I would also recommend to call kdestory before
authentication with ssh to be sure that gssapi
authentication will not be used.

I would recomment to set "debug_level = 7" in domain and ssh section
on the server where you woudl like to authenticate.
then restart sssd and try to authenticate with ssh + verbose mode
e.g. ssh -v u...@remote.host

Then I would recommend to compare logs from working server
and from broken server.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] 2FA using FreeIPA

[Lukas Slebodnik]

On (13/09/16 03:49), Deepak Dimri wrote:
>Hi All,
>I have below lines added to my sshd_config file for testuser.  
>
>
>
>Match User testuser
>AuthenticationMethods publickey,password:pam 
> publickey,keyboard-interactive:pam
>I have OTP enable for tapuser in IPA and i am able to login to GUI using the 
>password + OTP.  However when i try to ssh i am getting prompted for first 
>factor then second factor and then it ends with "Permission denied 
>(keyboard-interactive)." error.  What could be wrong here? 
>Regards,Deepak
>
Please provide versions of freeIPA server packages, version of sssd.
And it would be good to seed the exact output of ssh authentication.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Issues with FreeIPA SSH Key authentication

[Lukas Slebodnik]

On (15/09/16 09:56), Venkataramana Kintali wrote:
>Hi Lukas,
>Thank you for responding.
>I compared the configs.(sshd_config and sssd.conf ),they are same.
Is /etc/ssh/ssh_config the same as well?
NOTE: (ssh_config is not the same as sshd_config //extra 'd' in name)

>sssd  and sshd services are running on all the servers(IPA clients).
>PubKey Authentication is enabled on all the servers.
>I am not able to login with sshkeys.
>
>But I am able to ssh to these servers from the other IPA clients I am able
>to connect to with ssh keys(after doing a kinit).
>
If I remeber correctly GSSAPI has higher priority then public keys.
So the behaviour is expected.

You should decide whether you want to authenticate
with ssh keys stored in IPA or with kerberos ticket (GSSAPI)
or you can change sshd configuration to allow only authentication
with public keys.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] About AllowGroups with sshd

[Lukas Slebodnik]

On (14/09/16 08:37), Jose Alvarez R. wrote:
>Hi Jakub
>
>Thanks for your response.  It's an option, but my backups servers I will not
>add to the FreeIPA server.
>
>Then, I cannot use the option HBAC, because I want my backup server can
>connect with root to some client server of my FreeIPA Server.
>
root is not handled by sssd/freeIPA. It is a local user;
and thus access cannot be denied by HBAC.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sss / nsswitch

[Lukas Slebodnik]

On (13/09/16 10:39), Sumit Bose wrote:
>On Tue, Sep 13, 2016 at 10:13:12AM +0200, Rob Verduijn wrote:
>> Hi,
>> 
>> Thanks that did it.
>> 
>> Is there a less painfull way to be notified of these changes ?
>> 
>> My nfs configuration gets broken much more than I like because of changes
>> like these.
>> I know fedora is supposed to be testing grounds unstable software, but I
>> would really like to hear a heads up more often.
>
>The change was mentioned in the upstream release notes of SSSD-1.14.1
>https://fedorahosted.org/sssd/wiki/Releases/Notes-1.14.1 but of course I
>cannot be expected to read all upstream release note before running 'dnf
>update'. 
>
>The change was necessary because before the plugin was in the
>sssd-common package and this caused that some nfs dependencies were
>pulled in even on systems where nfs is not needed at all. Since neither
>SSSD nor nfs-idmap strictly require the plugin the new package is not
>automatically installed during update.
>

Sorry for troubles. We can add weak dependency info sssd-common on
sssd-nfs-idmap and it might be installed by default.
IIRC dnf does not inform about suggested packages; but recommends minght
work. Feel free ot file a BZ.

The reason why it is in separate package is "container world".
You need to have install packge sssd-nfs-idmap on host
but sssd can be running in container.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sssd stops after nss crashes

[Lukas Slebodnik]

On (12/09/16 21:47), Lachlan Musicman wrote:
>SELinux is disabled, updated to 1.14.1 today.
>
>This is the first crash in weeks, so we aren't that phased, although we'd
>love to know it wont happen again
BTW Did it really crashed? Do you have a coredump

We fixed few bad bugs(regressions) in 1.14.1 and in upstream.
e.g.
https://fedorahosted.org/sssd/ticket/3154
https://fedorahosted.org/sssd/ticket/3163


>- the servers are part of a cluster that
>executes automated tasks as the data comes off genome sequencing machines -
>clinical medical analyses that is important for the patients & etc.
>
I though it's prefered to use stable official release in such enviroment :-)
Copr repo[1] is not an official release. Anyway, this copr repo is backported
version from fedora and I do not know about any crash report or bug
from fedora users. 1.14.1-2 should work well.

LS

[1] https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sssd stops after nss crashes

[Lukas Slebodnik]

On (12/09/16 11:09), Lachlan Musicman wrote:
>We saw another sssd crash on the weekend (well, Friday night).
>
>Centos 7, sssd 1.14.0 from COPR
>
Please upgrade to 1.14.1 from copr.

>Everything has worked fine for over a month until Friday.
>
>According to the log sssd_nss on the host in question:
>
> - at about 16:18, watchdog_handler killed a process for a timer overflow.
> - there is some flopping about as nss/sssd tries to reconnect
> - at 16:19:12 we see this:
>
>(Fri Sep  9 16:19:12 2016) [sssd[nss]] [sbus_dispatch] (0x0400): SBUS is
>reconnecting. Deferring.
>
> - Which continues until 16:20:56
>
>(Fri Sep  9 16:20:56 2016) [sssd[nss]] [sbus_dispatch] (0x0400): SBUS is
>reconnecting. Deferring.
>
>Note that there are 9,573,091 lines of this, at about 80,000 msgs per
>second.
>
> - nss seems to stumble back to life at this point (there are no logs on
>the freeipa server unfortunately)
>
> - at every 15 min interval we see this (I think this might be zabbix
>polling sssd):
>
>(Fri Sep  9 18:30:01 2016) [sssd[nss]] [get_client_cred] (0x0020):
>SELINUX_getpeercon failed [-1][Unknown error -1].
What is a state of SELinux on your machine?
Please share output of "sestatus"

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Issues with FreeIPA SSH Key authentication

[Lukas Slebodnik]

On (07/09/16 17:39), Venkataramana Kintali wrote:
>Hi,
>Of late, I am learning FreeIPA . I have installed IPA server and few
>clients (Version 3.0.0)
>I am facing an issue with ssh key authentication in my setup.
>I generated a putty ssh private key (using putty keygen) ,and uploaded it
>under a user through IPA GUI.
I assume you uploaded public key to the IPA
otherwise you did something wrong and I wonder why it works on some machines.

>I am able to login to some IPA clients but not able to login to other IPA
>clients with putty using private key and passphrase.
>
Is sssd_ssh running on all clients? (Is sssd.conf almost the same on all
machines)
Is sshd configuration the same on all machines?
/etc/ssh/ssh_config /etc/ssh/sshd_config

>Public Key Authentication is enabled on all clients.
>I am able to from one client to other clients successfully (after doing
>kinit) without promting password.
>
>Can someone  please throw some light on this as to what the issue could be
>here and what else I can check to understand where  the problem is ?
>
>I searched this online but couldn't find any solution in the context of IPA.
>

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Default gid for AD trust users

[Lukas Slebodnik]

On (24/08/16 11:42), Orion Poplawski wrote:
>While that is definitely *a* convention, it's not the one we've used which
>puts users by default in shared groups (nwra, visitors, etc).  For example:
>
>uid=2941(user) gid=1991(nwra)
>
The user "user" should be a member "nwra" group.
If no then you have other issues.

Why does it matter whether it is a primary group or no?

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SUDO and group lookup in AD trust

[Lukas Slebodnik]

On (26/08/16 07:54), Jakub Hrozek wrote:
>On Thu, Aug 25, 2016 at 10:41:53PM +0200, Lukas Slebodnik wrote:
>> On (25/08/16 11:30), Troels Hansen wrote:
>> >Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade,
>> >getting a version 1.14.1, clean cache DB (complaing about cache being
>> >old version),
>> Upgrade to 1.14.1 should not require puring sssd cache.
>> If you are able to reproduce then please provide steps.
>> Or file a sssd bug https://fedorahosted.org/sssd/newticket
>> 
>> >I can getent users, but log log in for no obvious reason (system error in 
>> >secure.log).
>> >
>> system error sounds bad. Please provide log files with
>> high debug level in domain section sssd.conf
>> 
>> https://fedorahosted.org/sssd/wiki/Troubleshooting#SSSDdebuglogs
>
>We were debugging this yesterday with Troels and the logs said it's:
>https://fedorahosted.org/sssd/ticket/3127
>
Fixed version is in 1.14 copr

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SUDO and group lookup in AD trust

[Lukas Slebodnik]

On (25/08/16 11:30), Troels Hansen wrote:
>Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade,
>getting a version 1.14.1, clean cache DB (complaing about cache being
>old version),
Upgrade to 1.14.1 should not require puring sssd cache.
If you are able to reproduce then please provide steps.
Or file a sssd bug https://fedorahosted.org/sssd/newticket

>I can getent users, but log log in for no obvious reason (system error in 
>secure.log).
>
system error sounds bad. Please provide log files with
high debug level in domain section sssd.conf

https://fedorahosted.org/sssd/wiki/Troubleshooting#SSSDdebuglogs

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Questions about 1.14 software bugs

[Lukas Slebodnik]

On (25/08/16 18:30), Sullivan, Daniel [AAA] wrote:
>Hi, 
>
>I feel like I’ve been warned at least twice that sssd 1.14 has some known 
>regressions that make it unstable.  We’re in the process of rolling it out to 
>our production environment (we can’t use 1.13 due to another issue); so far it 
>seems pretty stable, although if possible I’d like any sort of highly informed 
>advisement if it is really stupid or insane to move forward with 1.14.  
>Specifically, we are implementing 1.14.0-3.el6.
>
May I know what is a blocker for using default version of sssd(1.13) in el6?
It is a stable version ready for production.

>Similarly, is it safe to say that this is a comprehensive list of known issues 
>or are there identified problems that aren’t documented in this report?
>
>https://fedorahosted.org/sssd/report/2
>
https://fedorahosted.org/sssd/report/3 would be better
and look directly into the bucket "SSSD 1.14.2"

>Any advise or recommendation that an expert in sssd 1.14 could provide would 
>be appreciated (as I said before so far it seems pretty stable).
>
We fixed many bugs in 1.14.1 and copr repository was updated
https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/
I would say it si 99% ready for production.

We will appreciate testing. And in case of any bugs, I can release
new version in copr immediately after fixing bug in upstream.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SUDO and group lookup in AD trust

[Lukas Slebodnik]

On (25/08/16 10:05), Troels Hansen wrote:
>Hmm, seems waiting for RHEL 7.3 and SSSD 1.14 will solve this problem
>
>https://fedorahosted.org/sssd/ticket/2919
>
Meanwhile, you can test upstream version
https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] can't get sudo to work.

[Lukas Slebodnik]

On (24/08/16 06:55), Tony Brian Albers wrote:
>And indeed the compat tree was disabled.
>
>Guess I forgot to reenable it after copying the db to a testing
>environment.
>
>Thanks guys, sudo is working fine now.
>
BTW it would work with upstream 1.13.4 even with disabled
compat tree (or 1.13.3 in el6)

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] 2FA with Sudo not working

[Lukas Slebodnik]

On (12/08/16 10:51), Jakub Hrozek wrote:
>Please keep the list in CC..
>
>On Fri, Aug 12, 2016 at 04:44:03AM -0400, Deepak Dimri wrote:
>> I am running on  "Red Hat Enterprise Linux Server release 7.2 (Maipo)"
>> I have seen that link and it says sssd-1.13.3-5.fc22sb.src.rpm &/or 
>> sssd-1.13.3-6.fc24.src.rpm  has the fix but then this rpm is not getting 
>> installed on my linux :(
>
>For RHEL, this bug will be fixed in 7.3.
>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> rpm -ivh sssd-1.13.3-6.fc24.src.rpm 
>> Updating / installing...
>>1:sssd-1.13.3-6.fc24   # 
>> [100%]
>> rpm -q sssd-1.13.3-6.fc24
>
>Installing a Fedora RPM on RHEL won't work, sorry..
>
For testing purposes, It would be better to use copr
https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-13/

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] freeipa 4.4 online repo is down

[Lukas Slebodnik]

On (08/08/16 09:06), Ben .T.George wrote:
>Hi List,
>
>always https://copr.fedorainfracloud.org/ is down, is there any alternative
>repo were i can get IPA 4.4?
>
Your link does not point to any specific repo?
Which copr reposiory did you mean?

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] change GID not work

[Lukas Slebodnik]

On (22/07/16 10:07), Rob Crittenden wrote:
>Junhe Jian wrote:
>> Hello,
>> 
>> i have a problem to change/set the GID.
>> 
>> I create a new Group with a GID 999 in GUI not work. IPA generate a new
>> GID within the Range.
>
>You are running into https://fedorahosted.org/freeipa/ticket/2886
>
>This is fixed in freeIPA 3.2.
>
>Basically 999 was the "magic" number that IPA used to know when to generate
>an ID value (as opposed to using one requested by the user).
>
>I don't believe there is a workaround for this.
>
IMHO, workaround is to use different GID than 999.
I do not see a reason why group docker could not have gid 998

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'

[Lukas Slebodnik]

On (16/07/16 10:19), Martin Štefany wrote:
>Hello Sumit,
>
>seems that upgrade to F24 broke things again. This time no AVCs, empty SSSD
>logs, but same problem: 'Error looking up public keys'.
>
>selinux-policy-3.13.1-191.fc24.3.noarch
>selinux-policy-targeted-3.13.1-191.fc24.3.noarch
>sssd-1.13.4-3.fc24.x86_64
>
Fedora 23 and fedora 24 has the same version of sssd
and almost the same version of openssh.
I have no idea what coudl broke it it there are not any AVCs.

>Using debug_level 0x0250 ::
>
For troubleshooting, it would be better to see all
debug messages. (debug_level = 0xfff0)
>$ /usr/bin/sss_ssh_authorizedkeys martin
>Error looking up public keys
>
And try to run strace with sss_ssh_authorizedkeys

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

[Lukas Slebodnik]

On (14/07/16 21:23), Sullivan, Daniel [AAA] wrote:
>Justin,
>
>Thank you for taking the time to reply to me; I really appreciate your 
>willingness to help.
>
>Upgrading to sssd1.14 (from the copr repo) on the client seems to have fixed 
>this problem across the board.  I don’t have a system that is currently broken 
>to capture this data, but if it is important for you to have the log data to 
>try and resolve this bug I could try to obtain it for you by purposely try to 
>induce the issue by upgrading another system and hoping the bug presents 
>itself, and then capture the data.  Please advise if you would like me to 
>attempt this.
>
>I was really frustrated by this bug and am happy that I can consider this 
>issue resolved.  Please let me know if you would like me to try and capture 
>the data as you described.
>
I am glad that 1.14 works for you :-)
But there might be other bugs. I know about few regressions.

BTW about the HBAC issue, did you use the default_domain_suffix previously?

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Error in selinux child: libsemanage can't parse spaces in AD user names

[Lukas Slebodnik]

On (15/07/16 12:56), Lachlan Musicman wrote:
>This line:
>
>We have SELinux disabled on all of our servers, but we hadn't disabled this
>check in sssd.conf. So we enabled it in sssd.conf and everything worked
>fine.
>
>Should read that we *disabled* selinux.
>
>selinux_provider = none
Could you also try another solution?
put "override_space = _" into "sssd" section in sssd.conf
and restart sssd.

As a result of this space will be replaced with underscore
and libsemanage should not complain.

@see man sssd.conf -> override_space

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

[Lukas Slebodnik]

On (14/07/16 13:52), Tomas Simecek wrote:
>Hi Lukas,
>sorry to say, but nothing helps.
>
>I have just updated IPA server, so that now it is:
>[root@svlxxipap ~]# cat /etc/redhat-release
>CentOS Linux release 7.2.1511 (Core)
>
>with:
>[root@svlxxipap ~]# rpm -qa|grep ipa
>ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.17.x86_64
>libipa_hbac-1.13.0-40.el7_2.9.x86_64
>ipa-python-4.2.0-15.0.1.el7.centos.17.x86_64
>ipa-server-dns-4.2.0-15.0.1.el7.centos.17.x86_64
>python-iniparse-0.4-9.el7.noarch
>ipa-server-4.2.0-15.0.1.el7.centos.17.x86_64
>sssd-ipa-1.13.0-40.el7_2.9.x86_64
>ipa-admintools-4.2.0-15.0.1.el7.centos.17.x86_64
>python-libipa_hbac-1.13.0-40.el7_2.9.x86_64
>ipa-client-4.2.0-15.0.1.el7.centos.17.x86_64
>
It has to work with IPA on CentOS 7.2
and sssd-1.13.3-22.el6_8.4 on client.

>I have also changed sudoers to sudo in sssd.conf as you suggested and
>restarted sssd.
>No difference, still:
>[simecek.to...@sd-stc.cz@zp-cml-test ~]$ sudo service sshd restart
>[sudo] password for simecek.to...@sd-stc.cz:
>simecek.to...@sd-stc.cz is not in the sudoers file.  This incident will be
>reported.
>
>I guess I will pilot some more IPA clients to make sure it works reliably
>and if yes, I guess we will be able to live with the fact that older
>Linuxes doe not offer sudo to AD clients.
>
I assume you meant AD users from trust.

But previously, you provided data and user was member of group which
should be alowed to use sudo rules.

I would like to find out why sudo rules were not fetched from IPA.

I would like to see full log file + dump of sssd cache.
Please:
* clean cache and log files on *IPA server*
  rm -f /var/lib/sss/db/* /var/log/sssd/*
* enable debug_level=9 in domain section and sudo
* restart sssd on *IPA server*

* clean cache and log files on *IPA client*
  rm -f /var/lib/sss/db/* /var/log/sssd/*
* enable debug_level=9 in domain section and sudo
* restart sssd *IPA client*


* authernticate with user simecek.to...@sd-stc.cz
* call id simecek.to...@sd-stc.cz
* try sudo.

* send all sssd log files + sssd.conf
* provide dump of sssd cache
  ldbsearch -H /var/lib/sss/db/cache_$domain.ldb
(utility ldbsearch is part of package ldb-tools


Please provide log files, sssd.conf and dump of sssd cache
from client and also from IPA server.

Thank you very much for patience.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

[Lukas Slebodnik]

On (14/07/16 13:06), Tomas Simecek wrote:
>Hi Lukas,
>I did as you said.
>Logs are attached to this mail.
>
Thank you very much for provided data.

The main problem is that full refresh of sudo rules did not store any rules.

It might be caused by following errors which might be caused by issues
with old buggy IPA server on CentOS 7.0

[ipa_s2n_save_objects] (0x2000): Updating memberships for borek.pa...@sd-stc.cz
[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such 
object](32)[ldb_wait: No such object (32)]
[sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
[sysdb_update_members_ex] (0x0020): Could not add member 
[borek.pa...@sd-stc.cz] to group 
[name=acco...@sd-stc.cz,cn=groups,cn=sd-stc.cz,cn=sysdb]. Skipping.
[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such 
object](32)[ldb_wait: No such object (32)]
[sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
[sysdb_update_members_ex] (0x0020): Could not add member 
[borek.pa...@sd-stc.cz] to group 
[name=borek.pa...@sd-stc.cz,cn=groups,cn=sd-stc.cz,cn=sysdb]. Skipping.

Attached is a reduced log.

You might try new feature in sssd-1.13 on el6 which will
avoid using compat tree for sudo.

Try to change ldap_sudo_search_base from
ou=sudoers,dc=linuxdomain,dc=cz -> cn=sudo,dc=linuxdomain,dc=cz

It does not mean that it will solve issue with extop plugin
on IPA server (ipa_s2n_save_objects)

If it does not help then please provide the same data as in previous mail.
BTW I strogly suspect issues on IPA server on CentOS 7.0.
It might work on CentOS 7.0 client only by chance.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

[Lukas Slebodnik]

On (14/07/16 12:43), Tomas Simecek wrote:
>Thanks Lukas,
>to be honest I am not sure what do you mean by "Please test with id
>simecek.to...@sd-stc.cz."
>It is the user I am testing with all the time.
>
>Here is what I see on client where sudo does not work:
>[simecek.to...@sd-stc.cz@zp-cml-test ~]$ id
>uid=988604700(simecek.to...@sd-stc.cz) gid=988604700(simecek.to...@sd-stc.cz)
>groups=988604700(simecek.to...@sd-stc.cz),43124(grpunixadmins),988600513(domain
>us...@sd-stc.cz),988604182(acco...@sd-stc.cz),988604754(mfcr_...@sd-stc.cz
>),988604825(unixadm...@sd-stc.cz),988604833(wifiadm...@sd-stc.cz)
>
hmm, the user is member of grpunixadmins. Then I wonder why sssd could not find
a sudo rules for the user.

I would like to see full log file + dump of sssd cache.
Please:
* clean cache and log files on client
  rm -f /var/lib/sss/db/* /var/log/sssd/*
* enable debug_level=9 in domain section and sudo
* restart sssd
* authernticate with usersimecek.to...@sd-stc.cz
* try sudo.
* send all sssd log files
* provide dump of sssd cache
  ldbsearch -H /var/lib/sss/db/cache_$domain.ldb
  (utility ldbsearch is part of package ldb-tools

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

[Lukas Slebodnik]

On (14/07/16 11:26), Tomas Simecek wrote:
>Hi Lukas,
>we have Active Directory group "UnixAdmins"
>.
>We have IPA external group ad_admins_external
>, which has
>Windows "UnixAdmins" group as a member.
>We have local IPA group grpunixadmins
>, which has
>ad_admins_external group as a member.
>So from that perspective user simecek.to...@sd-stc.cz is a member of
>grpunixadmins .
>That setup works for ssh logins and for sudo on Centos 7.0.
>
If user is member of group in IPA it does not mean that
it's properly propagated to client :-)

I can see few errors in log
>(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
>[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
>object](32)[ldb_wait: No such object (32)]
>(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
>[sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
>(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
>[sysdb_update_members_ex] (0x0020): Could not add member [
>simecek.to...@sd-stc.cz] to group [name=simecek.to...@sd-stc.cz
>,cn=groups,cn=sd-stc.cz,cn=sysdb]. Skipping.
>(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
>[ipa_s2n_save_objects] (0x2000): Updating memberships for
>simecek.to...@sd-stc.cz
>(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
>[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
>object](32)[ldb_wait: No such object (32)]
>(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
>[sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
>(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
>[sysdb_update_members_ex] (0x0020): Could not add member [
>simecek.to...@sd-stc.cz] to group [name=simecek.to...@sd-stc.cz
>,cn=groups,cn=sd-stc.cz,cn=sysdb]. Skipping.

Please test with id simecek.to...@sd-stc.cz.
I'm preatty sure that you will not see a group grpunixadmins.

BTW according to domain logs it looks like a bug with extop plugin
on freeipa server. I assume that ipa server is on CentOS 7.0
because you mention it works on Centos 7.0.

I would strongly recommend to upgrade server to 7.2

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

[Lukas Slebodnik]

On (14/07/16 10:09), Tomas Simecek wrote:
>Thanks all of you guys,
>I have updated to:
>sssd-krb5-common-1.13.3-22.el6_8.4.x86_64
>sssd-1.13.3-22.el6_8.4.x86_64
>sssd-ldap-1.13.3-22.el6_8.4.x86_64
>sssd-client-1.13.3-22.el6_8.4.x86_64
>sssd-ad-1.13.3-22.el6_8.4.x86_64
>sssd-proxy-1.13.3-22.el6_8.4.x86_64
>libsss_idmap-1.13.3-22.el6_8.4.x86_64
>sssd-common-1.13.3-22.el6_8.4.x86_64
>sssd-ipa-1.13.3-22.el6_8.4.x86_64
>python-sssdconfig-1.13.3-22.el6_8.4.noarch
>sssd-krb5-1.13.3-22.el6_8.4.x86_64
>sssd-common-pac-1.13.3-22.el6_8.4.x86_64
>(there does not seem to be libsss_sudo in Centos as suggested by Danila).
>and restarted sssd.
>
>There are two rules enabled. One HBAC as I presented earlier:
>  Rule name: Unixari na test servery
>  Enabled: TRUE
>  User Groups: grpunixadmins
>  Hosts: spcss-2t-www.linuxdomain.cz, zp-cml-test.linuxdomain.cz
>  Services: login, sshd, sudo, sudo-i, su, su-l
>
>and one sudo rule:
>Rule name: Pokusne
>  Enabled: TRUE
>  Command category: all
>  User Groups: grpunixadmins
>  Hosts: spcss-2t-www.linuxdomain.cz, zp-cml-test.linuxdomain.cz
>
>Default "all-access" rules are disabled.
>
>When I try to sudo as AD user (member of grpunixadmins) on Centos 6.6, I
>still get:
>
>[simecek.to...@sd-stc.cz@zp-cml-test ~]$ sudo cat /etc/nsswitch.conf
>[sudo] password for simecek.to...@sd-stc.cz:
>simecek.to...@sd-stc.cz is not in the sudoers file.  This incident will be
>reported.
>
>It works fine on Centos 7 (spcss-2t-www.linuxdomain.cz).
>
>sssd.conf:
>[domain/linuxdomain.cz]
>cache_credentials = True
>krb5_store_password_if_offline = True
>ipa_domain = linuxdomain.cz
>id_provider = ipa
>krb5_realm = LINUXDOMAIN.CZ
>auth_provider = ipa
>access_provider = ipa
>ipa_hostname = zp-cml-test.linuxdomain.cz
>chpass_provider = ipa
>ipa_server = svlxxipap.linuxdomain.cz
>ldap_tls_cacert = /etc/ipa/ca.crt
>override_shell = /bin/bash
>sudo_provider = ipa
>ldap_uri = ldap://svlxxipap.linuxdomain.cz
>ldap_sudo_search_base = ou=sudoers,dc=linuxdomain,dc=cz
>ldap_sasl_mech = GSSAPI
>#ldap_sasl_authid = host/zp-cml-test.linuxdomain...@linuxdomain.cz
>ldap_sasl_authid = host/zp-cml-test.linuxdomain.cz
>ldap_sasl_realm = LINUXDOMAIN.CZ
>krb5_server = svlxxipap.linuxdomain.cz
>debug_level = 0x3ff0
>[sssd]
>services = nss, sudo, pam, ssh
>config_file_version = 2
>domains = linuxdomain.cz
>[nss]
>homedir_substring = /home
>[pam]
>[sudo]
>debug_level = 0x3ff0
>[autofs]
>[ssh]
>[pac]
>[ifp]
>
>
>sssd_sudo.log from the moment I tried sudo:
>(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sysdb_search_group_by_gid]
>(0x0400): No such entry
>(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
>(0x0200): Searching sysdb with
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=
>simecek.to...@sd-stc.cz)(sudoUser=#988604700)(sudoUser=%domain\
>20us...@sd-stc.cz)(sudoUser=%unixadm...@sd-stc.cz
>)(sudoUser=%grpunixadmins)(sudoUser=%mfcr_...@sd-stc.cz)(sudoUser=%
>acco...@sd-stc.cz)(sudoUser=%wifiadm...@sd-stc.cz
>)(sudoUser=+*))(&(dataExpireTimestamp<=1468482821)))]
>(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About
>to get sudo rules from cache
>(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sysdb_search_group_by_gid]
>(0x0400): No such entry
>(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
>(0x0200): Searching sysdb with
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=simecek.to...@sd-stc.cz
>)(sudoUser=#988604700)(sudoUser=%domain\20us...@sd-stc.cz)(sudoUser=%
>unixadm...@sd-stc.cz)(sudoUser=%grpunixadmins)(sudoUser=%mfcr_...@sd-stc.cz
>)(sudoUser=%acco...@sd-stc.cz)(sudoUser=%wifiadm...@sd-stc.cz
>)(sudoUser=+*)))]
>(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
>(0x0400): Returning 0 rules for [simecek.to...@sd-stc.cz]
>(Thu Jul 14 09:53:47 2016) [sssd[sudo]] [client_recv] (0x0200): Client
>disconnected!
>(Thu Jul 14 09:53:47 2016) [sssd[sudo]] [client_destructor] (0x2000):
>Terminated client [0x260b690][17]
>(Thu Jul 14 09:53:51 2016) [sssd[sudo]] [sbus_message_handler] (0x2000):
>Received SBUS method org.freedesktop.sssd.service.ping on path
>/org/freedesktop/sssd/service
>(Thu Jul 14 09:53:51 2016) [sssd[sudo]] [sbus_get_sender_id_send] (0x2000):
>Not a sysbus message, quit
>(Thu Jul 14 09:53:55 2016) [sssd[sudo]] [accept_fd_handler] (0x0400):
>Client connected!
>(Thu Jul 14 09:53:55 2016) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
>Received client version [1].
>(Thu Jul 14 09:53:55 2016) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
>Offered version [1].
>(Thu Jul 14 09:53:55 2016) [sssd[sudo]] [sudosrv_cmd] (0x2000): Using
>protocol version [1]
>(Thu Jul 14 09:53:55 2016) [sssd[sudo]] [sss_parse_name_for_domains]
>(0x0200): name 'simecek.to...@sd-stc.cz' matched expression for domain '
>sd-stc.cz', user is simecek.tomas
>(Thu Jul 14 09:53:55 2016) [sssd[sudo]] [sss_parse_name_for_domains]
>(0x0200): name 'simecek.to...@sd-stc.cz' matched expression for domain '
>sd-stc.cz', user is simecek.tomas

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

[Lukas Slebodnik]

On (13/07/16 10:32), Danila Ladner wrote:
>Update to this one:
>It has been running smoothly on 6.5
>
>[root@dev-zlei.sec1 ~]# cat /etc/redhat-release
>CentOS release 6.5 (Final)
>
>[root@dev-zlei.sec1 ~]# rpm -qa | grep sssd
>sssd-client-1.12.4-47.el6.x86_64
>sssd-ldap-1.12.4-47.el6.x86_64
>sssd-ad-1.12.4-47.el6.x86_64
>python-sssdconfig-1.12.4-47.el6.noarch
>sssd-common-1.12.4-47.el6.x86_64
>sssd-proxy-1.12.4-47.el6.x86_64
>sssd-common-pac-1.12.4-47.el6.x86_64
>sssd-krb5-1.12.4-47.el6.x86_64
>sssd-ipa-1.12.4-47.el6.x86_64
>sssd-krb5-common-1.12.4-47.el6.x86_64
>sssd-1.12.4-47.el6.x86_64
>
+1 for latest sssd even on CentOS 6.5.

If you have a problem with 1.12 (from 6.7)
then we can look into log files.
Because there is a still a chance that oyu just hit
a bug in 1.11 which is solved in 1.12

If it will not work then please provide
sssd.conf + log files with high debug_level sssd_sudo.log
and sssd_$domain.log

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

[Lukas Slebodnik]

On (13/07/16 13:36), Tomas Simecek wrote:
>Lukas,
>yes, I went through that guide and I configured sssd.conf as per the doc
>(you can see it in the beginning of the thread).
>
>Actually the installation is:
>[root@zp-cml-test sssd]# cat /etc/redhat-release
>CentOS release 6.6 (Final)
>
>and versions are:
>[root@zp-cml-test sssd]# rpm -qa |grep sssd
>sssd-proxy-1.11.6-30.el6.x86_64
>sssd-common-pac-1.11.6-30.el6.x86_64
>sssd-ipa-1.11.6-30.el6.x86_64
>sssd-1.11.6-30.el6.x86_64
>sssd-common-1.11.6-30.el6.x86_64
>sssd-ad-1.11.6-30.el6.x86_64
>sssd-ldap-1.11.6-30.el6.x86_64
>python-sssdconfig-1.11.6-30.el6.noarch
>sssd-krb5-common-1.11.6-30.el6.x86_64
>sssd-krb5-1.11.6-30.el6.x86_64
>sssd-client-1.11.6-30.el6.x86_64
>
1.11 has sudo_provider=ipa

@see instructions in man sssd-sudo how to configure it.
It should avoid issues with two different providers (ipa and ldap)

>
>There are some reasons why not to upgrade to later versions, believe me, I
>would do it if I could :-)
>
You can at least try to upgrade sssd from 6.8 if you do not want
to upgrade whole OS.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

[Lukas Slebodnik]

On (13/07/16 11:18), Tomas Simecek wrote:
>Dear freeIPA gurus,
>in previous thread (
>https://www.redhat.com/archives/freeipa-users/2016-July/msg00046.html) you
>helped me make sudo working for AD users on Centos 7.0 (
>spcss-2t-www.linuxdomain.cz).
>It was caused by not knowing sudo needs to be enabled in HBAC rules.
>Now it works properly on Centos 7.0 client.
>But it does not work on Centos 6.5 (zp-cml-test.linuxdomain.cz) with the
>same sssd.conf setup.
>Error message is always:
>
A) I would not recommend to use such obsolete distribution as CentOS 6.5
   There is quite old version of sssd (1.9.x) which has some bugs which
   are solved in later versions. Better would be use the latest CentOS 6.8
   or at least CentOS 6.7

B) Have you tried to follow instructions
   https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

Please provide any comments how we can improve troubleshooting wiki.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Small bug in ipa-backup file naming

[Lukas Slebodnik]

On (04/07/16 09:01), Petr Spacek wrote:
>On 2.7.2016 22:00, Joshua J. Kugler wrote:
>> Was just playing around with the ipa-backup scripts for a client. Ran ipa-
>> backup, and the backup was successfully placed in /var/lib/ipa/backup/ipa-
>> full-2016-07-02-11-54-58. Went to view ipa-full.tar, and discovered it's 
>> actually a tar.gz file.  This is FreeIPA 4.2.0 on CentOS 7.
>> 
>> Is this known? Or should I open a bug?
>
>Please open a ticket:
>https://fedorahosted.org/freeipa/newticket
>
and ideal would be if you could provide a patch.
http://www.freeipa.org/page/Contribute

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPAv3 and SSSD // Disable automatic Kerberos authentication

[Lukas Slebodnik]

On (30/06/16 15:38), Sumit Bose wrote:
>On Wed, Jun 29, 2016 at 09:04:47AM +, tstorai@orange.com wrote:
>> Hello,
>> 
>> We are using FreeIPAv3 with SSSD with Hortonworks Cluster :
>> 
>> -  ipa-admintools-3.0.0-47
>> 
>> -  ipa-client-3.0.0-47
>> 
>> -  sssd-ipa-1.11.6-30
>> 
>> 
>> According with the following documentation, our users are automatically 
>> authenticated to Kerberos at every login :
>> https://www.freeipa.org/page/Kerberos
>> "When SSSD project is used, the ticket is get for a user automatically as he 
>> authenticates to client machine."
>> 
>> It's working pretty well but some of our users are using nominative accounts 
>> for ssh connection then access to Hadoop with an applicative keytab...
>> We are agreed than we have to perform a kinit at every connection but when 
>> theses users work on several sessions they lose the applicative account 
>> ticket :(
>
>If you use credential cache collections (type DIR: or KEYTAB:) SSSD
According to versions of sssd, it looks like el6.
And KEYRING collection ccache is not on el6.
I'm not sure about DIR collection ccache.

>would only update the individual cache matching the user principal
>stored in IPA. The caches for other principals would persist. But if the
>principal in the applicative keytab is from the same Kerberos realm you
>still might need to use the 'kswitch' command to set the primary
>principal. But it should be sufficient to call it only once because the
>information is stored in the collection and not overwritten by SSSD.
>
>If this does not work the affected users can add something like:
>
>export KRB5CCNAME=$HOME/my_cc_cache
  ^
Is FILE: considered as default or it need to be
written as well for KRB5CCNAME
LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] nss unrecognized name alert with SAN name

[Lukas Slebodnik]

On (26/06/16 20:37), John Obaterspok wrote:
>Hi,
>
>I've been running F23 + mod_nss 1.0.14-1 for months to get SubjectAltName
>to work.
>F24 update brings back mod_nss to 1.0.12-4 and now SubjectAltName doesn't
>work any more. Is there any chance 1.0.14 will make it in as an F24 update?
>(I can add karma if needed)
>
mod_nss-1.0.14-1 is only in rawhide (fc25)
I cannot see such package in fedora 23.

http://koji.fedoraproject.org/koji/packageinfo?packageID=2554

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ldap entry from an plugin

[Lukas Slebodnik]

On (20/06/16 20:20), gheorghita.butn...@tuiasi.ro wrote:
>yes i did, started from there.
>
>i have two new fields in user details and works as expected.
>now, based on those new entries i need to make an entry in ldap like this
>one:
>
>dn: cn=userid, cn=192.168.1.0, cn=shared_net_name,
>cn=config,dc=dhcp,dc=example,dc=com
>cn: userid
>objectClass: top
>objectClass: dhcpHost
>objectClass: dhcpOptions
>dhcpHWAddress: ethernet 00:a0:78:8e:9e:aa
>
>shared_net_name, dhcpHWAddress - added by users in those new fields.
>I was thinking that i can do it on the same plugin file but i don't know
>how exactly how to do it

If you want to enhace FreeIPA with DHCP
the I will recommend you to look into freeipa-user archives.
https://www.redhat.com/archives/freeipa-users/2016-May/msg00211.html
https://github.com/jefferyharrell/IPA-dhcp

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-ods-exporter failed ?

[Lukas Slebodnik]

On (16/06/16 11:54), Günther J. Niederwimmer wrote:
>Hello
>
>on my system the ods-exporter i mean have a problem.
>
>I have this in the logs
>CentOS 7.(2) ipa 4.3.1
>
>Jun 16 11:37:25 ipa systemd: ipa-ods-exporter.service holdoff time over, 
>scheduling restart.
>Jun 16 11:37:25 ipa systemd: Started IPA OpenDNSSEC Signer replacement.
>Jun 16 11:37:25 ipa systemd: Starting IPA OpenDNSSEC Signer replacement...
>Jun 16 11:37:25 ipa ipa-ods-exporter: ipa: WARNING: session memcached servers 
>not running
>Jun 16 11:37:26 ipa python2: GSSAPI Error: Unspecified GSS failure.  Minor 
>code 
>may provide more information (Ticket expired)
>Jun 16 11:37:26 ipa ipa-ods-exporter: Traceback (most recent call last):
>Jun 16 11:37:26 ipa ipa-ods-exporter: File "/usr/libexec/ipa/ipa-ods-
>exporter", line 656, in 
>Jun 16 11:37:26 ipa ipa-ods-exporter: ldap.gssapi_bind()
>Jun 16 11:37:26 ipa ipa-ods-exporter: File "/usr/lib/python2.7/site-packages/
>ipapython/ipaldap.py", line 1085, in gssapi_bind
>Jun 16 11:37:26 ipa ipa-ods-exporter: '', auth_tokens, server_controls, 
>client_controls)
>Jun 16 11:37:26 ipa ipa-ods-exporter: File "/usr/lib64/python2.7/
>contextlib.py", line 35, in __exit__
>Jun 16 11:37:26 ipa ipa-ods-exporter: self.gen.throw(type, value, traceback)
>Jun 16 11:37:26 ipa ipa-ods-exporter: File "/usr/lib/python2.7/site-packages/
>ipapython/ipaldap.py", line 992, in error_handler
>Jun 16 11:37:26 ipa ipa-ods-exporter: raise errors.ACIError(info=info)
>Jun 16 11:37:26 ipa ipa-ods-exporter: ipalib.errors.ACIError: Insufficient 
>access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  
>Minor code may provide more information (Ticket expired)
>Jun 16 11:37:26 ipa systemd: ipa-ods-exporter.service: main process exited, 
>code=exited, status=1/FAILURE
>Jun 16 11:37:26 ipa systemd: Unit ipa-ods-exporter.service entered failed 
>state.
>Jun 16 11:37:26 ipa systemd: ipa-ods-exporter.service failed.
>Jun 16 11:38:26 ipa systemd: ipa-ods-exporter.service holdoff time over, 
>scheduling restart.
>Jun 16 11:38:26 ipa systemd: Started IPA OpenDNSSEC Signer replacement.
>Jun 16 11:38:26 ipa systemd: Starting IPA OpenDNSSEC Signer replacement...
>Jun 16 11:38:27 ipa ipa-ods-exporter: ipa: WARNING: session memcached servers 
>not running
>Jun 16 11:38:28 ipa python2: GSSAPI Error: Unspecified GSS failure.  Minor 
>code 
>may provide more information (Ticket expired)
>Jun 16 11:38:28 ipa ipa-ods-exporter: Traceback (most recent call last):
>Jun 16 11:38:28 ipa ipa-ods-exporter: File "/usr/libexec/ipa/ipa-ods-
>exporter", line 656, in 
>Jun 16 11:38:28 ipa ipa-ods-exporter: ldap.gssapi_bind()
>Jun 16 11:38:28 ipa ipa-ods-exporter: File "/usr/lib/python2.7/site-packages/
>ipapython/ipaldap.py", line 1085, in gssapi_bind
>Jun 16 11:38:28 ipa ipa-ods-exporter: '', auth_tokens, server_controls, 
>client_controls)
>Jun 16 11:38:28 ipa ipa-ods-exporter: File "/usr/lib64/python2.7/
>contextlib.py", line 35, in __exit__
>Jun 16 11:38:28 ipa ipa-ods-exporter: self.gen.throw(type, value, traceback)
>Jun 16 11:38:28 ipa ipa-ods-exporter: File "/usr/lib/python2.7/site-packages/
>ipapython/ipaldap.py", line 992, in error_handler
>Jun 16 11:38:28 ipa ipa-ods-exporter: raise errors.ACIError(info=info)
>Jun 16 11:38:28 ipa ipa-ods-exporter: ipalib.errors.ACIError: Insufficient 
>access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  
>Minor code may provide more information (Ticket expired)
  ^^
   Here seems to be a reason why it failed.
   But I can't help you more.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] [FreeIPA 4.3.0] CentOS 6.8 sudo fails

[Lukas Slebodnik]

On (14/06/16 08:56), Jakub Hrozek wrote:
>On Mon, Jun 13, 2016 at 06:06:00PM -0400, Rob Crittenden wrote:
>> Nathan Peters wrote:
>> > I have confirmed that on both CentOS 6.8 and CentOS 6.7 that if the group 
>> > is a POSIX group, it can be used in sudo rules.
>> > If the group is a 'normal' group it will fail when used in sudo rules.
>> > 
>> > This is really silly because in a previous version of CentOS (6.3) sudo 
>> > rules would fail if the group was POSIX, and work if the group was 
>> > 'normal'.
>> > 
>> > I'm not sure when this changed because we still have CentOS 6.7 machines 
>> > that are working fine with the non posix groups.
>> > I did notice that in sssd 1.13.3-22.el6 sudo fails with non posix groups
>> > And with 1.12.4-47.el6_7.7 sudo works with non posix groups
>> > 
>> > So now FreeIPA exists in a really funky state where if you are below 
>> > CentOS 6.4 you MUST use non POSIX groups and If you are on CentOS 6.7 and 
>> > above, you must use POSIX groups.
>> > 
>> > So basically, you need to roll forward your entire infrastructure to 
>> > CentOS 6.7 or above or else your old machines will suddently start failing 
>> > sudo logins when you udate the groups or your new machines will simply 
>> > fail with groups that worked on your old ones.
>> > 
>> > Can you please confirm what the intended behavior is because I would 
>> > rather not go through the trouble of re-creating all our sudo / hbac rules 
>> > and user groups...
>> 
>> Jakub already stated that this would be bug if it only worked with POSIX
>> groups, so you've confirmed that.
>> 
>> If you have a Red Hat subscription I'd open a support case and ask to be
>> added to bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1336548
>
>Because that bug is private (sorry, there's some RH customer data there)
>and because you also confirmed it's an issue, I cloned the bugzilla to
>our upstream Trac:
>https://fedorahosted.org/sssd/ticket/3046
>
>I'm sceptical we will have a fix this week, we're trying to meet a
>deadline at the moment, but we will try to come up with a fix either late
>next week or the one after.
>
>I'm sorry about the inconvenience. I wonder if, as a temporary
>workaround, you could point sssd to the compat tree using
>ldap_sudo_search_base?
>
Yes, it worth a try.
We switched from compat search base to native search base for sudo
in 1.13.x

But many things were changed in sudo; it neend't help.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] [FreeIPA 4.3.0] CentOS 6.8 sudo fails

[Lukas Slebodnik]

On (08/06/16 18:14), Nathan Peters wrote:
>I'm pretty lost here.  I tried following the directions on that page but the 
>results still make no sense to me.  From what I can see, the account is 
>successfully authorized, and the groups that I am part of are found and some 
>sudo rules are found, but then I am denied access for no reason.  This is not 
>working on any CentOS 6.8 server, and working properly on all previous 
>versions of CentOS.  I have tried several steps including deleting and 
>re-creating the 6.8 hosts, and unjoining them and re-joining them to the 
>domain.  Nothing helps
>
>== /var/log/sudo_debug ==
>
>Jun  8 16:56:01 sudo[7277] <- sudo_pam_verify @ ./auth/pam.c:138 := 0
>Jun  8 16:56:01 sudo[7277] <- verify_user @ ./auth/sudo_auth.c:282 := 1
>Jun  8 16:56:01 sudo[7277] -> sudo_auth_cleanup @ ./auth/sudo_auth.c:160
>Jun  8 16:56:01 sudo[7277] -> sudo_pam_cleanup @ ./auth/pam.c:185
>Jun  8 16:56:01 sudo[7277] <- sudo_pam_cleanup @ ./auth/pam.c:189 := 0
>Jun  8 16:56:01 sudo[7277] <- sudo_auth_cleanup @ ./auth/sudo_auth.c:177 := 0
>Jun  8 16:56:01 sudo[7277] -> sudo_pw_delref @ ./pwutil.c:249
>Jun  8 16:56:01 sudo[7277] -> sudo_pw_delref_item @ ./pwutil.c:238
>Jun  8 16:56:01 sudo[7277] <- sudo_pw_delref_item @ ./pwutil.c:243
>Jun  8 16:56:01 sudo[7277] <- sudo_pw_delref @ ./pwutil.c:251
>Jun  8 16:56:01 sudo[7277] <- check_user @ ./check.c:189 := true
>Jun  8 16:56:01 sudo[7277] -> log_failure @ ./logging.c:318
>Jun  8 16:56:01 sudo[7277] -> log_denial @ ./logging.c:256
>Jun  8 16:56:01 sudo[7277] -> audit_failure @ ./audit.c:68
>Jun  8 16:56:01 sudo[7277] -> linux_audit_command @ ./linux_audit.c:70
>Jun  8 16:56:01 sudo[7277] -> linux_audit_open @ ./linux_audit.c:49
>Jun  8 16:56:01 sudo[7277] <- linux_audit_open @ ./linux_audit.c:61 := 15
>Jun  8 16:56:01 sudo[7277] <- linux_audit_command @ ./linux_audit.c:97 := 3
>Jun  8 16:56:01 sudo[7277] <- audit_failure @ ./audit.c:81
>Jun  8 16:56:01 sudo[7277] -> new_logline @ ./logging.c:746
>Jun  8 16:56:01 sudo[7277] <- new_logline @ ./logging.c:867 := user NOT 
>authorized on host ; TTY=pts/1 ; PWD=/home/nathan.peters ; USER=root ; 
>COMMAND=/bin/su -
>Jun  8 16:56:01 sudo[7277] -> should_mail @ ./logging.c:712
>Jun  8 16:56:01 sudo[7277] <- should_mail @ ./logging.c:717 := false
>Jun  8 16:56:01 sudo[7277] -> do_syslog @ ./logging.c:138
>Jun  8 16:56:01 sudo[7277] -> mysyslog @ ./logging.c:96
>Jun  8 16:56:01 sudo[7277] <- mysyslog @ ./logging.c:119
>Jun  8 16:56:01 sudo[7277] <- do_syslog @ ./logging.c:185
>Jun  8 16:56:01 sudo[7277] <- log_denial @ ./logging.c:309
>Jun  8 16:56:01 sudo[7277] <- log_failure @ ./logging.c:341
>Jun  8 16:56:01 sudo[7277] -> rewind_perms @ ./set_perms.c:90
>Jun  8 16:56:01 sudo[7277] -> restore_perms @ ./set_perms.c:363
>Jun  8 16:56:01 sudo[7277] restore_perms: uid: [756600344, 0, 0] -> 
>[756600344, 0, 0]
>Jun  8 16:56:01 sudo[7277] restore_perms: gid: [756600344, 756600344, 
>756600344] -> [756600344, 756600344, 756600344]
>Jun  8 16:56:01 sudo[7277] -> sudo_grlist_delref @ ./pwutil.c:816
>Jun  8 16:56:01 sudo[7277] -> sudo_grlist_delref_item @ ./pwutil.c:805
>Jun  8 16:56:01 sudo[7277] <- sudo_grlist_delref_item @ ./pwutil.c:810
>Jun  8 16:56:01 sudo[7277] <- sudo_grlist_delref @ ./pwutil.c:818
>Jun  8 16:56:01 sudo[7277] <- restore_perms @ ./set_perms.c:407
>Jun  8 16:56:01 sudo[7277] -> sudo_grlist_delref @ ./pwutil.c:816
>Jun  8 16:56:01 sudo[7277] -> sudo_grlist_delref_item @ ./pwutil.c:805
>Jun  8 16:56:01 sudo[7277] <- sudo_grlist_delref_item @ ./pwutil.c:810
>Jun  8 16:56:01 sudo[7277] <- sudo_grlist_delref @ ./pwutil.c:818
>Jun  8 16:56:01 sudo[7277] <- rewind_perms @ ./set_perms.c:96
>Jun  8 16:56:01 sudo[7277] -> sudo_endpwent @ ./pwutil.c:443
>Jun  8 16:56:01 sudo[7277] -> sudo_freepwcache @ ./pwutil.c:426
>Jun  8 16:56:01 sudo[7277] -> rbdestroy @ ./redblack.c:359
>Jun  8 16:56:01 sudo[7277] -> _rbdestroy @ ./redblack.c:341
>Jun  8 16:56:01 sudo[7277] -> _rbdestroy @ ./redblack.c:341
>Jun  8 16:56:01 sudo[7277] <- _rbdestroy @ ./redblack.c:349
>Jun  8 16:56:01 sudo[7277] -> _rbdestroy @ ./redblack.c:341
>Jun  8 16:56:01 sudo[7277] <- _rbdestroy @ ./redblack.c:349
>Jun  8 16:56:01 sudo[7277] -> sudo_pw_delref_item @ ./pwutil.c:238
>Jun  8 16:56:01 sudo[7277] <- sudo_pw_delref_item @ ./pwutil.c:243
>Jun  8 16:56:01 sudo[7277] <- _rbdestroy @ ./redblack.c:349
>Jun  8 16:56:01 sudo[7277] <- rbdestroy @ ./redblack.c:362
>Jun  8 16:56:01 sudo[7277] -> rbdestroy @ ./redblack.c:359
>Jun  8 16:56:01 sudo[7277] -> _rbdestroy @ ./redblack.c:341
>Jun  8 16:56:01 sudo[7277] -> _rbdestroy @ ./redblack.c:341
>Jun  8 16:56:01 sudo[7277] <- _rbdestroy @ ./redblack.c:349
>Jun  8 16:56:01 sudo[7277] -> _rbdestroy @ ./redblack.c:341
>Jun  8 16:56:01 sudo[7277] <- _rbdestroy @ ./redblack.c:349
>Jun  8 16:56:01 sudo[7277] -> sudo_pw_delref_item @ ./pwutil.c:238
>Jun  8 16:56:01 sudo[7277] <- sudo_pw_delref_item @ ./pwutil.c:243
>Jun  8 16:56:01 sudo[7277] <- _rbdestroy @ 

Re: [Freeipa-users] SSH login to client

[Lukas Slebodnik]

On (09/06/16 08:43), Pavel Picka wrote:
>
>
>- Original Message -
>From: "David Kupka" 
>To: "Pavel Picka" , freeipa-users@redhat.com
>Sent: Thursday, June 9, 2016 1:45:26 PM
>Subject: Re: [Freeipa-users] SSH login to client
>
>On 09/06/16 13:18, Pavel Picka wrote:
>> Hi,
>>
>> Have anyone experience, when create user on ipa-server, and want to login on 
>> client with this user I get :
>>
>> Permission denied, please try again.
>> Permission denied, please try again.
>> Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
>>
>> (with kinit [1st time change] was password changed to new one)
>> even with another change with ipa user-mod --password I am getting same 
>> result
>>
>> and on client in /var/log/messages found :
>>
>> Jun  9 12:36:02 rhel04 [sssd[krb5_child[4635]]]: Decrypt integrity check 
>> failed
>> Jun  9 12:36:02 rhel04 [sssd[krb5_child[4635]]]: Decrypt integrity check 
>> failed
>> Jun  9 12:36:05 rhel04 [sssd[krb5_child[4637]]]: Decrypt integrity check 
>> failed
>> Jun  9 12:36:05 rhel04 [sssd[krb5_child[4637]]]: Decrypt integrity check 
>> failed
>> Jun  9 12:36:28 rhel04 [sssd[krb5_child[4641]]]: Decrypt integrity check 
>> failed
>> Jun  9 12:36:28 rhel04 [sssd[krb5_child[4641]]]: Decrypt integrity check 
>> failed
>>
>>
>>
>> --
>> Pavel Picka
>>
>Hi Pavel!
>
>I have few questions that may help locating the issue:
>
>Are you able to kinit as the user on server and client?
>- kinit is ok on both
>Are you able to ssh to the client as the admin?
>- no I am not able to use 'admin' to ssh to client
>What is the output of "id user" on client?
>[root@rhel04 ~]# id tuser
>uid=41821(tuser) gid=41821(tuser) groups=41821(tuser)
>
>
>I have noticed I am able ssh when 'kinit user' is active
>
>For detailed logs here is ssh -vvv
>
>http://pastebin.test.redhat.com/382140
>
>@Sumit
>
>I found /var/log/sssd/krb5_child.log empty, but didn't set log level to 10, is 
>it done by krb5.conf or else?
/ets/sssd/sssd.conf and domian section.

You might find useful following wiki.
https://fedorahosted.org/sssd/wiki/Troubleshooting

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo 2FA not working

[Lukas Slebodnik]

On (21/05/16 15:07), Ken Bass wrote:
>Adding to my own question after doing some further research:
>
>This appears to be a bug in SSSD.
>https://bugzilla.redhat.com/show_bug.cgi?id=1276868
>It was fixed via commit 
>https://git.fedorahosted.org/cgit/sssd.git/commit/?id=4a01e6a6fd66e622b80739472a0aa06d1c79a6a9
>on 3/14/2016.
>
>I am wondering why this has yet to be released for centos 7.2 yet? There have
>been two sssd updates since then, the latest 9 days ago and it does not
>appear that it was included. I also wonder how something so basic could slip
>through the cracks? It would appear it has never worked. I understand weird /
>odd use case bugs, but this is out of the box clean install no modifications
>- simply turn on 2FA and test sudo.
>
If you have a Red Hat supscription then please open a case.
Meanwhilem you can use backported version from fedora which contains the fix.
https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-13/

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa -v ping lies about the cert database

[Lukas Slebodnik]

On (12/05/16 16:16), Harald Dunkel wrote:
>On 04/26/16 17:29, Timo Aaltonen wrote:
>> 
>> I guess 4.3.1 would need to be in sid first, and it just got rejected
>> because of the minified javascript (bug #787593). Don't know when
>> that'll get fixed.
>> 
>
>Since 24beta is out without fixing
>
>   https://fedorahosted.org/freeipa/ticket/5639
>
You might see in ticket that planned milestone is "Future Releases"
that isn't any particular release (4.4.x ...)

It basically mean that patches are welcome.
That's how it works in open source world.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

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

[Lukas Slebodnik]

On (12/05/16 15:35), Harald Dunkel wrote:
>On 05/12/16 13:48, Lukas Slebodnik wrote:
>> It would be nice if you could provide reliable reproducer.
>> I'm sorry we do not have a crystall ball and sssd log files
>> did not help either. They are truncated.
>> 
>
>Thats all I got.
>
and that's the reason why we cannot help more :-(

>> I would like to fix it but I do not know what to fix.
>> 
>> Is there anything interesting/suspicious in syslog/journald
>> from the same time?
>> 
>
>"journalctl -u sssd" says
>
It is not helpful either.
We asked to find *ANYTHING* interesting/suspicious in syslog/journald
So it needn't be related to sssd.

It can be realted to swapping, out of entropy, disk needs to spin up,
high load, DNS not responding, whatever

But it's task for you to find out what trigger the problem.
We do not have an access to problematic machines.

So try to find a reason which trigger the problem and provide
reasonable reproducer.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

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

[Lukas Slebodnik]

On (12/05/16 11:03), Harald Dunkel wrote:
>On 05/12/16 10:26, Lukas Slebodnik wrote:
>> On (12/05/16 09:42), Harald Dunkel wrote:
>>>
>>> It happened again :-(.This *really* needs to be fixed.
>>> I wouldn't like to move back to ypbind.
>>>
>> I would like to If I knew what to fix and how to reliably reproduce.
>> 
>
>It would be very nice if sssd could become more reliable at
>startup time. It gives up to easy. And it is not restarted
>in case of a problem, which is fatal for a service providing
>access to a user database.
>
It would be nice if you could provide reliable reproducer.
I'm sorry we do not have a crystall ball and sssd log files
did not help either. They are truncated.

I would like to fix it but I do not know what to fix.

Is there anything interesting/suspicious in syslog/journald
from the same time?

>>> Logfiles are attached. sssd is version 1.13.3. The server
>>> was rebooted at 05:56. At 06:03:18 sssd wrote the first
>>> logfile entries.
>>>
>> I cannot see in log files that sssd was started.
>
>:
>:
>(Thu May 12 05:56:12 2016) [sssd] [monitor_quit] (0x0020): Child [sudo] exited 
>gracefully
>(Thu May 12 05:56:12 2016) [sssd] [monitor_quit] (0x0020): Terminating 
>[nss][441]
>(Thu May 12 05:56:12 2016) [sssd] [monitor_quit] (0x0020): Child [nss] exited 
>gracefully
>(Thu May 12 06:03:18 2016) [sssd] [sysdb_domain_init_internal] (0x0200): DB 
>File for example.com: /var/lib/sss/db/cache_example.com.ldb
>(Thu May 12 06:03:20 2016) [sssd] [get_ping_config] (0x0100): Time between 
>service pings for [example.com]: [10]
>(Thu May 12 06:03:20 2016) [sssd] [get_ping_config] (0x0100): Time between 
>SIGTERM and SIGKILL for [example.com]: [60]
>(Thu May 12 06:03:20 2016) [sssd] [start_service] (0x0100): Queueing service 
>example.com for startup
>(Thu May 12 06:03:22 2016) [sssd] [sbus_server_init_new_connection] (0x0200): 
>Entering.
>:
>:
>
I saw these lines but I miss messages about startup of sssd.
something like:
  [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb
  [dp_get_options] (0x0400): Option lookup_family_order has value ipv4_first
  [dp_get_options] (0x0400): Option dns_resolver_timeout has value 6
  [dp_get_options] (0x0400): Option dns_resolver_op_timeout has value 6
  [dp_get_options] (0x0400): Option dns_discovery_domain has no value
  [be_res_get_opts] (0x0100): Lookup order: ipv4_first
  [recreate_ares_channel] (0x0100): Initializing new c-ares channel
  [fo_context_init] (0x0400): Created new fail over context, retry timeout is 30
  [confdb_get_domain_internal] (0x0400): No enumeration for [example.com]!
  [confdb_get_domain_internal] (0x1000): pwd_expiration_warning is -1
  [sysdb_domain_init_internal] (0x0200): DB File for example.com: 
/var/lib/sss/db/cache_example.com.ldb
  [sbus_init_connection] (0x0400): Adding connection 0x55b875a67cc0
  [sbus_add_watch] (0x2000): 0x55b875a68ae0/0x55b875a67590 (15), -/W (enabled)
  [sbus_toggle_watch] (0x4000): 0x55b875a68ae0/0x55b875a675e0 (15), R/- 
(disabled)
  [sbus_opath_hash_add_iface] (0x0400): Registering interface 
org.freedesktop.sssd.service with path /org/freedesktop/sssd/service
  [sbus_conn_register_path] (0x0400): Registering object path 
/org/freedesktop/sssd/service with D-Bus connection
  [sbus_opath_hash_add_iface] (0x0400): Registering interface 
org.freedesktop.DBus.Properties with path /org/freedesktop/sssd/service
  [sbus_opath_hash_add_iface] (0x0400): Registering interface 
org.freedesktop.DBus.Introspectable with path /org/freedesktop/sssd/service
  [monitor_common_send_id] (0x0100): Sending ID: (%BE_example.com,1)


>> Log files seems to be truncated and there seems to be probllem
>> with network communication.
>> 
>> [be_resolve_server_process] (0x0200): Found address for server 
>> ipa2.example.com: [172.29.96.4] TTL 7200
>> [init_timeout] (0x0040): Client timed out before Identification [0x12d50c0]!
>> [sdap_kinit_done] (0x0080): Communication with KDC timed out, trying the 
>> next one
>> [fo_set_port_status] (0x0100): Marking port 389 of server 'ipa2.example.com' 
>> as 'not working'
>> 
>
>You have cut off the time stamps. Here they are:
>
That was on purpose. Because it's clear that "Communication with KDC timed out"
The question is why?
6 seconds must be enough unless you try to connect the the server
which is located in opposite site of globe.

>(Thu May 12 06:03:31 2016) [sssd[be[example.com]]] [be_resolve_server_process] 
>(0x0200): Found address for server ipa2.example.com: [172.29.96.4] TTL 7200
>(Thu May 12 06:03:36 2016) [sssd[be[example.com]]] [init_timeout] (0x0040): 
>Client timed out before Identification [0x12d50c0]!
>(Thu May 12 06:03:37 2016) [sssd[be[example.com]]] [sdap_kinit_done] (0x0080)

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

[Lukas Slebodnik]

On (12/05/16 09:42), Harald Dunkel wrote:
>Hi folks,
>
>On 02/23/16 13:46, Lukas Slebodnik wrote:
>> On (23/02/16 13:01), Harald Dunkel wrote:
>>> On 02/23/2016 11:58 AM, Lukas Slebodnik wrote:
>>>> I would rather focus on different thing.
>>>> Why is sssd_be process blocked for long time?
>>>>
>>>
>>> I have no idea. Was it really blocked?
>>>
>> It needn't be blocked itself. But it was busy
>> with some non-blocking operation which main process
>> considered as bad state.
>> 
>> Would you mind to share sssd log files with
>> high debug level?
>> 
>
>It happened again :-(.This *really* needs to be fixed.
>I wouldn't like to move back to ypbind.
>
I would like to If I knew what to fix and how to reliably reproduce.

>Logfiles are attached. sssd is version 1.13.3. The server
>was rebooted at 05:56. At 06:03:18 sssd wrote the first
>logfile entries.
>
I cannot see in log files that sssd was started.
Log files seems to be truncated and there seems to be probllem
with network communication.

[be_resolve_server_process] (0x0200): Found address for server 
ipa2.example.com: [172.29.96.4] TTL 7200
[init_timeout] (0x0040): Client timed out before Identification [0x12d50c0]!
[sdap_kinit_done] (0x0080): Communication with KDC timed out, trying the next 
one
[fo_set_port_status] (0x0100): Marking port 389 of server 'ipa2.example.com' as 
'not working'

Do you have mounted nfs on /var/log/ or anywhere else?
It can explain a lot if there are network related issues.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] getent passwd returns usern...@domain.com for username

[Lukas Slebodnik]

On (11/05/16 17:17), Watson, Dan wrote:
>Hi All,
>
>I've run into some strangeness and I just haven't been able to find a solution 
>online.
>
>On my existing RHEL 6.5 servers everything runs fine. I do not use the IPA 
>client install but rather manually setup SSSD, LDAP and Kerberos. We've got a 
>RHEL 6.8 machine that just was added to IPA and it's showing some strangeness.
>
>RHEL 6.5:
>getent passwd
>...
>username:*:12345678:12345678:User Name:/home/username:/bin/bash
>...
>
The output looks like with disabled option
use_fully_qualified_names.

>RHEL 6.8:
>getent passwd
>...
>usern...@domain.com:*:12345678:12345678:User  Name:/home/username:/bin/bash
>...
>
The output looks like with enabled option
use_fully_qualified_names.

By default it should be false.
However, if you use default_domain_suffix then the default value is true.
https://fedorahosted.org/sssd/ticket/2569

This bug fix was introduced in 1.13.0

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] server 1 and server 2 cannot replicate now may be ssl cert expire

[Lukas Slebodnik]

On (10/05/16 08:19), barry...@gmail.com wrote:
>Do u meant the error related to OS?
I mean that there are known bugs in FreeIPA components.
389-ds, sssd 
CentOS 6.5 is quite old version.

I would really recommend to upgrade to the latest CentOS.
If there are still problems on latest CentOS then
we can try to continue with troubleshooting.

It does not worth to spend time with analyzing already fixed bugs.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] server 1 and server 2 cannot replicate now may be ssl cert expire

[Lukas Slebodnik]

On (09/05/16 12:14), Barry wrote:
>  Hello Barry,
>
>Can you provide more info?
>
>What is your IPA version, OS?
>
>CENTOS 6.5
>
Please upgrade to latest CentOS 6.7
there are known bugs in CentOS 6.5
which are already fixed in CentOS 6.7.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Free IPA Client in Docker

[Lukas Slebodnik]

On (03/05/16 21:27), Hosakote Nagesh, Pawan wrote:
>Our apps are running in a docker image based on Ubuntu 14.04 that cannot be 
>changed to redhat. We want to install freeipa-clietn within this docker so 
>that our app
>Uses freeipa ldap as against default ldap.
>
and that's the reason why you needn't care about base image
in container world.

sssd container can be based on fedora and other application
can be based on ubuntu. And they will share common directories
with unix pipes which are used communication with sssd.

In another words, you just need to install package  libnss-sss
and libpam-sss (if you need an authenticatio as well)
in client/application container
+ bind mount directories /var/lib/sss/pipes/ /var/lib/sss/mc/.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project