Re: [Freeipa-users] config sudo with ipa

[Lukas Slebodnik]

On (27/03/15 14:56), Benoit Rousselle wrote:
>hi,
>
>I setup a sudo config in client ipa and set rule in ipa server.
>sudo rules from ipa are not found : it return 0 rules for the user
>
>This config is ambiguous. Is there a method to check if everything is OK ?
>The best way for this moment is to set debug_level on sssd. But I'm not
>sure that the problem come from there.
>
>
>(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Ending timer event
>0x1cba830 "ltdb_callback"
>
>(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
>(0x0200): Searching sysdb with
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=my_user)(sudoUser=#161)(sudoUser=%utilisateur_a)(sudoUser=%adupont)(sudoUser=+*)))]
>(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Added timed event
>"ltdb_callback": 0x1cb9000
>
>(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Added timed event
>"ltdb_timeout": 0x1cb9240
>
>(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Destroying timer
>event 0x1cb9240 "ltdb_timeout"
>
>(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Ending timer event
>0x1cb9000 "ltdb_callback"
>
>(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
>(0x0400): Returning 0 rules for [my_user@my_domain.com]
>(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle
>timer re-set for client [0x1cb30e0][18]
>
>
>My client config :
>[domain/my_domain.com]
>debug_level = 6
>cache_credentials = True
>krb5_store_password_if_offline = True
>krb5_realm = MY_IDMDOMAIN.COM
>ipa_domain = my_domain.com
>id_provider = ipa
>auth_provider = ipa
>access_provider = ipa
>ipa_hostname = myserver.my_domain.com
>chpass_provider = ipa
>ipa_server = _srv_, idm.my_domain.com
>ldap_tls_cacert = /etc/ipa/ca.crt
>[sssd]
>services = nss, pam, ssh, sudo
>config_file_version = 2
>
>domains = addcnet.com
>[nss]
>
>[pam]
>
>[sudo]
>debug_level = 9
>
>[autofs]
>
>[ssh]
>
>[pac]
>
>
>server redhat : LINUX 6.4

rhel 6.4 has old version of sssd which does not have native ipa sudo provider.
You will need to configure sudo with sudo_provider = ldap.

Please 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] Ubuntu sssd client -- FreeIPA Server fed from AD

[Lukas Slebodnik]

On (30/03/15 05:36), g.fer.or...@unicyber.co.uk wrote:
>
>Hey Guys
>
>Not sure if I am missing any bit but this was the thing in the end:
>
>
>http://generations.menteyarte.org/archives/195-freeipa-server-and-SSSD-on-Ubuntu.html
>
>I managed to have it working and I have documented all those nasty bits which
>might save people's time. The whole weekend gone but for the less has been
>productive.
>
>I am including the SUDO bit which is usually a pain in my experience..
>
Do you relly have to enabled enumeration?
"enumerate = True"

It would be good if you could remove it from the post.

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

[Freeipa-users] [RFC] COPR drop support for old distribution

[Lukas Slebodnik]

ehlo,

CentOS 7.1 was finally released[1]. Yupi.
Fedora 21 was rewleased[2] few months ago.

People can use FreeIPA 4.1 without any problem.

So there's no more reason to maintain COPR repositories for older
distributions. It will significantly reduce extra dependencies in repositories.

It would be better to focus on backporting FreeIPA 4.2 in COPR.
I know it has not been released yet.

LS

[1] http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html
[2] https://fedoraproject.org/wiki/Releases/21/Schedule

-- 
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] RHEL 5 client?

[Lukas Slebodnik]

On (03/04/15 17:13), Guertin, David S. wrote:
>>I don't see any request going to sssd.
>>
>>Can you try with ju...@middlebury.edu? Old SSSD is incapable to see
>>MIDD\juser being the same as ju...@middlebury.edu.
>
>When I try:
>
>ssh -l 'ju...@middlebury.edu' yakko.ipa.middlebury.edu
>
>There is no response for two minutes, followed by "Connection closed".
>
>I've attached the resulting sssd_default.log and sssd_nss.log.
>

There seems to be problem with initgroups:

[sdap_get_initgr_user] (9): Process user's groups
[sdap_get_generic_step] (6): calling ldap_search_ext with 
[(&(memberuid=ju...@middlebury.edu)(objectclass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0][cn=compat,dc=ipa,dc=middlebury,dc=edu].
[sdap_get_generic_step] (7): Requesting attrs: [objectClass]
[sdap_get_generic_step] (7): Requesting attrs: [cn]
[sdap_get_generic_step] (7): Requesting attrs: [userPassword]
[sdap_get_generic_step] (7): Requesting attrs: [gidNumber]
[sdap_get_generic_step] (7): Requesting attrs: [memberuid]
[sdap_get_generic_step] (7): Requesting attrs: [modifyTimestamp]
[sdap_get_generic_step] (7): Requesting attrs: [entryUSN]
[sdap_get_generic_step] (8): ldap_search_ext called, msgid = 4
[sdap_process_result] (8): Trace: sh[0x1a204860], connected[1], 
ops[0x1a21c510], ldap[0x1a204310]
[sdap_process_result] (8): Trace: ldap_result found nothing!
[sbus_dispatch] (9): dbus conn: 1A1E97A0
[sbus_dispatch] (9): Dispatching.
[sbus_message_handler] (9): Received SBUS method [ping]
[sdap_get_initgr_done] (9): Initgroups done
[sdap_get_initgr_done] (9): Error in initgroups: [110][Connection timed out]
[sdap_id_op_done] (5): communication error on cached connection, moving to next 
server
[sdap_id_op_done] (9): too many communication failures, giving up...
[sdap_id_op_done] (9): releasing operation connection

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 configuration on FreeIPA, version: 4.1.0

[Lukas Slebodnik]

On (07/04/15 12:57), Jakub Hrozek wrote:
>On Tue, Apr 07, 2015 at 12:48:37PM +0200, Chamambo Martin wrote:
>> Sorry for the confusion about that one ,that client I used to aunthenticate
>> to a pure 389 directory server and I have since changed it to free ipa and
>> below is the correct configuration.
>> 
>> I managed to add the line sudo_provider = ipa and im getting the below error
>> on my client
>
>I don't see it added to the config.
>
It's not necessary to add "sudo_provider = ipa" into domain section.
because if sudo_provider is not specified then it is automatically inherited
from "id_provider".

It is described in documentation [1] (point 4) and also in the manual page
sssd-sudo.

IIRC ipa-client-install should configure all necessary things on rhel 7.1

>If it's added, the next steps would be to add debug_level to the sudo
>and domain sections. https://fedorahosted.org/sssd/wiki/Troubleshooting
>has some notes on gathering the debug logs.
>
+1

LS

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/Configuring_Services.html#configuring-sssd-sudo

-- 
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, version: 4.1.0 and sudo configuration

[Lukas Slebodnik]

On (08/04/15 09:25), Chamambo Martin wrote:
>Good day 
>
>I am running FreeIPA, version: 4.1.0 and everything is working well except
>SUDO configuration.
>
ipa-client-install on CentOS 7.1 should configure sudo by default.

>I have 3 questions
>
>   1: I have configured the bare minimum sudo configuration without
>hostgroups and netgroups , just sudo commands and sudo command groups that
>have been added as sudo rules .this should work right
yes.

and sudo rules with netgroups shuld work on CentOS 7.1 as well
because nisdomainname should be configured.

>2: I have centos 6.6 and redhat 6.6 clients using the sssd
>service  ,is that enough for sudo to work if the configs are as below
>
>
>cat /etc/nsswitch.conf
>
>sudoers: files sss
>
>cat /etc/sssd/sssd.conf
>
>[domain/ai.co.zw]
>
>debug_level=6
>cache_credentials = True
>krb5_store_password_if_offline = True
>ipa_domain = ai.co.zw
>id_provider = ipa
>auth_provider = ipa
>access_provider = ipa
>ipa_hostname = ironhide.ai.co.zw
>chpass_provider = ipa
>ipa_server = _srv_, cyclops.ai.co.zw
>ldap_tls_cacert = /etc/ipa/ca.crt
>
>[sssd]
>services = nss, sudo, pam, ssh
>config_file_version = 2
>
>
>domains = ai.co.zw
>[nss]
>homedir_substring = /home
The default value of this option is "/home"
You can remove it. Where did you find it?

>
>[pam]
>
>[sudo]
>
>[autofs]
>
>[ssh]
>

If you do not use netgroups (or hostgroups) in sudo rules
then this configuration should work on rhel 6.6 (sssd >= 1.10)
The same steps are decribed 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] Configuring SUDO on centos and RHEL 5 clients

[Lukas Slebodnik]

On (09/04/15 01:04), Martin Chamambo wrote:
>I managed to install my ipa client on centos 5 using this command below
>
> ipa-client-install --server cyclops.ai.co.zw --domain ai.co.zw
>
Pease follow instruction for rhel 5
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Configuring_Identity_Management/configuring-rhel5.html#Setting_up_sudo_Rules-Client_Configuration_for_sudo_Rules

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] Slow user logon with IPA

[Lukas Slebodnik]

On (15/04/15 08:53), Jakub Hrozek wrote:
>On Tue, Apr 14, 2015 at 05:36:16PM +0200, Mateusz Malek wrote:
>> 
>> 
>> On Fri, Apr 10, 2015 at 08:48 PM, Jakub Hrozek wrote:
>> >On Fri, Apr 10, 2015 at 12:39:20PM -0400, Dmitri Pal wrote:
>> >>On 04/10/2015 08:13 AM, Mateusz Malek wrote:
>> >>>I'm about to migrate my OpenLDAP-based environment to FreeIPA, however
>> >>>I've hit some weird performance problems. When I'm using IPA, it takes
>> >>>about 5-7 (or even more) seconds to get shell prompt after entering user
>> >>>password (...)
>> >>(...)
>> >>Do authentication and see where the time is spent by examining the logs.
>> >>Correlate it to the logs on the server. (...)
>> >I spent the better part of today fixing this issue:
>> > https://fedorahosted.org/sssd/ticket/2624
>> >
>> >You might want to check if you're hit by this bug by setting:
>> > selinux_provider=none
>> >temporarily.
>> 
>> With selinux_provider=none things seems faster.
>> 
>> It's still not as fast as with existing OpenLDAP, but logon times seem
>> acceptable now (they mostly vary from 0.5 to 2 seconds, sometimes they go up
>> to 3 seconds). It seems that most time is spent in Kerberos authentication
>> (logs just "stop flowing" for a while) and on HBAC processing - on the 389
>> DS side it seems that LDAP is busy with requests (it looks like it sometimes
>> "hangs" on MOD operation - is it updating user last logon time?).
>
>I pushed the selinux performance patches upstream yesterday. They will make
>their way to 7.2, 6.7 and I guess Lukas might also cherry-pick them for
>Fedora.
>
Packages for fedora 21,22 are built.
You just need to wait utill they are available in updates testing
or you can download packages from koji.

https://admin.fedoraproject.org/updates/sssd-1.12.4-4.fc22
https://admin.fedoraproject.org/updates/sssd-1.12.4-3.fc21

Please test and provide karma.

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] Freeipa4 - AD SSH logins

[Lukas Slebodnik]

On (15/04/15 13:43), Aric Wilisch wrote:
>Today I managed to finally get a trust established between my AD Domain and my 
>FreeIPA 4 environment. 
>
>However I’m noticing a couple issues and hope someone might be able to give me 
>some help.
>
>First when the user logs in it creates their home directory in 
>/home/fioptics/ rather than /home/. I read that you had to 
>put 
>subdomain_homedir= /home in /etc/sssd/sssd.conf but that didn’t seem to fix it.
^
The value of this option is template.
The default is "/home/%d/%u"

You can find details in man sssd.conf -> subdomain_homedir
  -> override_homedir

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] Stuck getting sudo working with Ubuntu client

[Lukas Slebodnik]

On (17/04/15 11:32), Andrew Sacamano wrote:
>Hi everyone,
>
>
>I've spent a couple of days digging around the web, watching logs, and
>poking things, and I'm stuck getting sudo working with IPA on a new box
>I've just set up. I have had it working in the past on a test box, but
>something about this box is blocking me, and I can't for the life of me
>figure out what.
>
>
>The basic symptom is that I can log into the Ubuntu box as an IPA user, but
>sudo is always denied:
>
>
>[root@security-core-1 log]# ssh dru@jenkins
>
>dru@jenkins's password:
>
>...
>
>Could not chdir to home directory /home/dru: No such file or directory
>
>dru@jenkins:/$ sudo -l
>
>[sudo] password for dru:
>
>Sorry, user dru may not run sudo on jenkins.
>
>
>I've appended version output, config files, sample logs, and ipa config -
>which I think is all of the relevant material, but I'll gladly share more
>if it's needed.
>
>
>Thanks so much in advance for any debugging advice, hints, or help!
>
>

I looked to the configuration files and they look good.

I have few hints which might help you with troubleshooting
* please ensure you have installed package sudo and not sudo-ldap.
  The second one is not build with sssd support.
* please read about sudo caching in sssd
  man sssd-sudo -> THE SUDO RULE CACHING MECHANISM
* please test simple sudo rules first.
  (all hosts, one user instead of groups, ...)
* check whether sudo rules are cached by sssd (use ldb-tools)

If previous hints does not help then you need to enable
debugging in sudo and analyse log file.
@see slide 18 in presentation[1]

LS

[1] http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf

-- 
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] Stuck getting sudo working with Ubuntu client

[Lukas Slebodnik]

On (19/04/15 12:51), Andrew Sacamano wrote:
>Thanks again Lukas,
>
>These turned out to be very helpful debugging suggestions, and were the
>critical part of getting the problem solved - the pointer to ldb-tools was
>extremely helpful in identifying where the issue was happening!
>
>With them, I was able to see the right sudo rules were being cached, and
>that the change from sudo working to sudo not working happened not because
>of the host, but because of the user, and in particular, the user being a
>listed explicitly, or only as part of a group.  The user's groups were
>being listed in the user's entry in the cache, but not when running the
>"id" command.  Some quick googling, and I discovered that in Ubuntu 14.04,
>the sssd option "enumerate" defaults to false, which meant that the group
>memberships were not taking effect, which meant that sudo rules based on
>membership in a group weren't working. Setting enumerate to true got
>everything working.
>
If you have a problem with "id" might be caused by
https://fedorahosted.org/sssd/ticket/2471

You can fix the bug with ammending configuration.
put ldap_group_object_class = ipaUserGroup
into domain section of sssd.conf

It should work even with disabled enumeration.

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] Stuck getting sudo working with Ubuntu client

[Lukas Slebodnik]

On (20/04/15 17:54), Andrew Sacamano wrote:
>Thanks again, Lukas!
>
>I was wondering if the overlaps of names was a problem, so I redid parts of
>my IPA setup to rename them - thanks for pointing out the ticket!
>
>Also, your suggestion to use ldap_group_object_class = ipaUserGroup worked
>- which saves me the trouble of tracking that down in six months when my
>IPA domain grows and the performance issues associated with enumerate begin
>to manifest.
>
>Many thanks - you are extraordinarily helpful. My colleagues and I are
>quite grateful for all your advice!
>
You are welcome,
I'm glad I could help.

You can file a ticket to backport patch for ticket #2471 in your distribution.

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] RHEL5 clients not getting ssh key

[Lukas Slebodnik]

On (30/04/15 15:34), Jakub Hrozek wrote:
>On Thu, Apr 30, 2015 at 03:13:44PM +0200, Martin Kosek wrote:
>> On 04/30/2015 02:56 PM, Aric Wilisch wrote:
>> > Is there a trick to getting a users SSH key that’s attached to their 
>> > FreeIPA account to work on RHEL 5 servers? users can ssh into the RHEL 6 
>> > clients with no issues but they still get prompted for their passwords on 
>> > the RHEL 5 server, so it’s not pushing down their ssh keys. 
>> > 
>> > Thanks!
>> > 
>> > Regards,
>> > --
>> > Aric Wilisch
>> > awili...@gmail.com
>> 
>> Well, RHEL-5's latest build should be sssd-1.5.1-71.el5, but the SSH public 
>> key
>> support was added in SSSD 1.8:
>> 
>> https://fedorahosted.org/sssd/ticket/610
>> 
>> So I do not know any way besides upgrading to RHEL-6/RHEL-7 or backporting 
>> the
>> SSSD 1.8+ yourself (which I do not expect to be an easy task).
>
>The 1.9 branch should build and work on RHEL-5.
>
But IIRC openssh-server should be patched 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] HBAC rules don't work with PAM - problem

[Lukas Slebodnik]

On (11/05/15 14:57), Vangass wrote:
>Hi,
>
>I try to access Cisco switch via ssh. Cisco has tacacs login configured.
>
># tail /var/log/secure
>May 11 14:18:46 freeipa tac_plus[29096]: pam_sss(tac_plus:auth):
>authentication success; logname=bartosz uid=0 euid=0 tty= ruser= rhost=
>user=bartosz
>May 11 14:18:53 freeipa tac_plus[29096]: pam_sss(tac_plus:auth):
>authentication success; logname=bartosz uid=0 euid=0 tty= ruser= rhost=
>user=test
>
>User bartosz is added in HBAC rule as Specified Users and Groups.
>User test exist in FreeIPA but isn't in HBAC rule and shouldn't be
>autheniticated.
>
># cat /etc/sssd/sssd.conf
>[domain/test.example.com]
>debug_level = 6
>cache_credentials = True
>krb5_store_password_if_offline = True
>ipa_domain = test.example.com
>id_provider = ipa
>auth_provider = ipa
>access_provider = ipa
>ipa_hostname = freeipa.test.example.com
>chpass_provider = ipa
>ipa_server = freeipa.test.example.com
>ipa_server_mode = True
>ldap_tls_cacert = /etc/ipa/ca.crt
>
>[sssd]
>services = nss, sudo, pam, ssh
>config_file_version = 2
>domains = test.example.com
>
>[nss]
>homedir_substring = /home
>
>[pam]
>debug_level = 6
>domains = test.example.com
>
>[sudo]
>
>[autofs]
>
>[ssh]
>
>[pac]
>
>[ifp]
>
>
>#cat /var/log/sssd/sssd_pam.log
>(Mon May 11 14:40:28 2015) [sssd[pam]] [accept_fd_handler] (0x0400): Client
>connected to privileged pipe!
>(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200):
>Received client version [3].
>(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200):
>Offered version [3].
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100):
>entering pam_cmd_authenticate
>(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_parse_name_for_domains]
>(0x0200): name 'test' matched without domain, user is test
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): command:
>PAM_AUTHENTICATE
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): domain:
>not set
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): service:
>tac_plus
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: not
>set
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser:
>not set
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost:
>not set
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok
>type: 1
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100):
>newauthtok type: 0
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid:
>29218
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): logon
>name: test
>(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_issue_request] (0x0400):
>Issuing request for [0x7f4f20215ed0:3:t...@test.example.com]
>(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_get_account_msg] (0x0400):
>Creating request for [test.example.com][3][1][name=test]
>(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_internal_get_send] (0x0400):
>Entering request [0x7f4f20215ed0:3:t...@test.example.com]
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_check_user_search] (0x0100):
>Requesting info for [t...@test.example.com]
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_check_user_search] (0x0400):
>Returning info for user [t...@test.example.com]
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending
>request with the following data:
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): command:
>PAM_AUTHENTICATE
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): domain:
>test.example.com
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): service:
>tac_plus
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: not
>set
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser:
>not set
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost:
>not set
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok
>type: 1
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100):
>newauthtok type: 0
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid:
>29218
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): logon
>name: test
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100):
>pam_dp_send_req returned 0
>(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_req_destructor] (0x0400):
>Deleting request: [0x7f4f20215ed0:3:t...@test.example.com]
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100):
>received: [0][test.example.com]
>(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply
>called with res

Re: [Freeipa-users] trusted user groups

[Lukas Slebodnik]

On (14/05/15 15:53), Andy Thompson wrote:
>> -Original Message-
>> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
>> boun...@redhat.com] On Behalf Of Jakub Hrozek
>> Sent: Thursday, May 14, 2015 11:46 AM
>> To: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] trusted user groups
>> 
>> On Thu, May 14, 2015 at 03:33:28PM +, Andy Thompson wrote:
>> > I've noticed that trusted users supplementary ad groups don't show up
>> until after the users login to the box at least once.
>> 
>> That's expected with the versions you're running. Prior to 6.7, we could only
>> read the trusted users' group membership from the PAC blob attached to
>> the Kerberos ticket.
>> 
>> 
>> > Is there a chance that information will be dropped again at any point going
>> forward?
>> 
>> No, otherwise it's a bug.
>> 
>> >
>> > The reason I ask is that on our sftp boxes we chroot users based on
>> > group membership.  I set that up as an external group in freeIPA and
>> > the first time the user logs in to the sftp box, they are dropped in
>> > their normal home directory as opposed to the chroot environment.  If
>> > there is a chance the group membership will not show up correctly
>> > again in the future, I'm inclined to change the chroot stanzas to match on
>> user as opposed to group.
>> >
>> > Is that by design?
>> 
>> If you can't see the correct group memberships after a login, then something
>> is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and there's so many
>> fixes and enhancements in this area..is there a chance you could try out 6.7
>> beta or some custom packages?
>> 
>
>Group memberships show up fine after the first login so it is working as 
>expected then.  The accounts are very controlled so it shouldn't be a huge 
>sticking point.  I could try out some custom packages on this box but I can't 
>move to 6.7 until we upgrade the entire environment.  
>
Here you are
https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/

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] username case sensitivity

[Lukas Slebodnik]

On (15/05/15 17:27), Andy Thompson wrote:
>Is there a way to enforce case sensitivity for trusted AD users?  I am trying 
>to use username for ssh chroots and I can authenticated with any case 
>combination of  but if ssh is set to match on  then the 
>chroot is not enforced and the user is dropped to their usual home directory.  
>I found a case_sensitive option for sssd but it does not seem to have any 
>affect.   Running RHEL6.6 clients.
>

IPA domain is by default case sensitive.
So You will not change anything if you put "case_sensitive = true" into domain
section of sssd.conf.

But SSSD will create subdomains for each AD domain. It is different id_provider
therefore different default values are used for subdomains and for AD provider
it is case *insensitive* by default.

Currently there's no way how to change it for subdomains (AD trusted 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] trusted user groups

[Lukas Slebodnik]

On (18/05/15 13:55), Andy Thompson wrote:
>> -Original Message-
>> From: Lukas Slebodnik [mailto:lsleb...@redhat.com]
>> Sent: Thursday, May 14, 2015 4:41 PM
>> To: Andy Thompson
>> Cc: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] trusted user groups
>> 
>> On (14/05/15 15:53), Andy Thompson wrote:
>> >> -Original Message-
>> >> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
>> >> boun...@redhat.com] On Behalf Of Jakub Hrozek
>> >> Sent: Thursday, May 14, 2015 11:46 AM
>> >> To: freeipa-users@redhat.com
>> >> Subject: Re: [Freeipa-users] trusted user groups
>> >>
>> >> On Thu, May 14, 2015 at 03:33:28PM +, Andy Thompson wrote:
>> >> > I've noticed that trusted users supplementary ad groups don't show
>> >> > up
>> >> until after the users login to the box at least once.
>> >>
>> >> That's expected with the versions you're running. Prior to 6.7, we
>> >> could only read the trusted users' group membership from the PAC blob
>> >> attached to the Kerberos ticket.
>> >>
>> >>
>> >> > Is there a chance that information will be dropped again at any
>> >> > point going
>> >> forward?
>> >>
>> >> No, otherwise it's a bug.
>> >>
>> >> >
>> >> > The reason I ask is that on our sftp boxes we chroot users based on
>> >> > group membership.  I set that up as an external group in freeIPA
>> >> > and the first time the user logs in to the sftp box, they are
>> >> > dropped in their normal home directory as opposed to the chroot
>> >> > environment.  If there is a chance the group membership will not
>> >> > show up correctly again in the future, I'm inclined to change the
>> >> > chroot stanzas to match on
>> >> user as opposed to group.
>> >> >
>> >> > Is that by design?
>> >>
>> >> If you can't see the correct group memberships after a login, then
>> >> something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and
>> >> there's so many fixes and enhancements in this area..is there a
>> >> chance you could try out 6.7 beta or some custom packages?
>> >>
>> >
>> >Group memberships show up fine after the first login so it is working as
>> expected then.  The accounts are very controlled so it shouldn't be a huge
>> sticking point.  I could try out some custom packages on this box but I can't
>> move to 6.7 until we upgrade the entire environment.
>> >
>> Here you are
>> https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/
>> 
>
>To just bring this full circle, the latest sssd release reads group membership 
>correctly without a Kerberos ticket.  I tested this release on 6.6 and tested 
>a 7.1 box and both worked without issue.
>
I'm glad it works for you.

>I just can't roll them in production yet :/
>
I see.

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] User Can't Authenticate

[Lukas Slebodnik]

On (21/05/15 18:56), Dmitri Pal wrote:
>On 05/21/2015 05:54 PM, John Williams wrote:
>>I've got a freeIPA client where a user account cannot authenticate.
>>
>>The log entry for IPA looks like:
>>
>>audit/audit.log.4:type=USER_AUTH msg=audit(1425316592.375:38090): user
>>pid=16485 uid=0 auid=4294967295 ses=4294967295
>>subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication
>>acct="aswanda" exe="/usr/sbin/sshd" hostname=172.31.0.162 addr=172.31.0.162
>>terminal=ssh res=failed'
>>
>>When I try to sudo to the user account, I get the following error:
>>
>>[root@myhost ~]# sudo su - testuser
>>su: user testuser does not exist
>>
>>However, all that works for my account.
>>
>>Please help.  Thanks in advance.
>>
>>
>>
>What do you use on the client? SSSD?
>What is the OS version?
>What SSSD logs show?
>
For sssd related issues see https://fedorahosted.org/sssd/wiki/Troubleshooting

Firstly, ensure you can get user information (getent passwd user)
Secondly, troubleshoot authentication and access control.

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 groups not shown on client

[Lukas Slebodnik]

On (22/05/15 09:37), Nikola Kržalić wrote:
>I have a ubuntu system running IPA client. I am able to log in via ssh
>using IPA users, but I do not get any group memberships or sudo rules.
>Same configuration works on a different system (running CentOS).
>
>sssd domain log output shows that the groups are retrieved from server
>successfully:
>
>(Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element]
>(0x1000): Added group [admins] for user [nkrzalic]
>(Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element]
>(0x1000): Added group [ipausers] for user [nkrzalic]
>(Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element]
>(0x1000): Added group [editors] for user [nkrzalic]
>(Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element]
>(0x1000): Added group [trust admins] for user [nkrzalic]
>(Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element]
>(0x1000): Added group [devops_team] for user [nkrzalic]
>(Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element]
>(0x1000): Added group [dev_team] for user [nkrzalic]
>(Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element]
>(0x1000): Added group [sys_team] for user [nkrzalic]
>
>However, these groups are not shown on the user upon login:
>
>nkrzalic@ircsrv1:~$ id
>uid=281200051(nkrzalic) gid=281200051(nkrzalic) groups=281200051(nkrzalic)
>
>I tried cleaning sssd cache but that didn't help.
>
>sssd conf is as follows:
>
>[sssd]
>services = nss, pam, ssh, sudo
>config_file_version = 2
>
>nsswitch.conf seems to be correct as well:
>
># /etc/nsswitch.conf
>
>passwd: compat sss
>group:  compat sss
>shadow: compat
>
>hosts:  files dns
>networks:   files
>
>protocols:  db files
>services:   db files
>ethers: db files
>rpc:db files
>
>netgroup:   nis sss
>sudoers:files sss
>
>Interestingly after I do "getent group devops_team" this group shows up:
>
>nkrzalic@ircsrv1:~$ id
>uid=281200051(nkrzalic) gid=281200051(nkrzalic)
>groups=281200051(nkrzalic),28121(devops_team)

Missing groups on ubuntu (sssd-1.11) can be caused by bug
https://fedorahosted.org/sssd/ticket/2471.
This bug is fixed on CentOS.

Workaround is to amend configuration of domain section.
ldap_group_object_class = ipaUserGroup

If it does not help then please follow instruction from 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] Antwort: FreeIPA groups not shown on client

[Lukas Slebodnik]

On (22/05/15 18:28), Christoph Kaminski wrote:
>freeipa-users-boun...@redhat.com schrieb am 22.05.2015 09:37:04:
>
>> Von: Nikola Kržalić 
>> An: freeipa-users@redhat.com
>> Datum: 22.05.2015 15:05
>> Betreff: [Freeipa-users] FreeIPA groups not shown on client
>> Gesendet von: freeipa-users-boun...@redhat.com
>> 
>> I have a ubuntu system running IPA client. I am able to log in via ssh
>> using IPA users, but I do not get any group memberships or sudo rules.
>> Same configuration works on a different system (running CentOS).
>> 
>> sssd domain log output shows that the groups are retrieved from server
>> successfully:
>> 
>> (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element]
>> (0x1000): Added group [admins] for user [nkrzalic]
>> (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element]
>> (0x1000): Added group [ipausers] for user [nkrzalic]
>> (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element]
>> (0x1000): Added group [editors] for user [nkrzalic]
>> (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element]
>> (0x1000): Added group [trust admins] for user [nkrzalic]
>> (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element]
>> (0x1000): Added group [devops_team] for user [nkrzalic]
>> (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element]
>> (0x1000): Added group [dev_team] for user [nkrzalic]
>> (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element]
>> (0x1000): Added group [sys_team] for user [nkrzalic]
>> 
>> However, these groups are not shown on the user upon login:
>> 
>> nkrzalic@ircsrv1:~$ id
>> uid=281200051(nkrzalic) gid=281200051(nkrzalic) 
>groups=281200051(nkrzalic)
>> 
>> I tried cleaning sssd cache but that didn't help.
>> 
>> sssd conf is as follows:
>> 
>> [sssd]
>> services = nss, pam, ssh, sudo
>> config_file_version = 2
>> 
>> nsswitch.conf seems to be correct as well:
>> 
>> # /etc/nsswitch.conf
>> 
>> passwd: compat sss
>> group:  compat sss
>> shadow: compat
>> 
>> hosts:  files dns
>> networks:   files
>> 
>> protocols:  db files
>> services:   db files
>> ethers: db files
>> rpc:db files
>> 
>> netgroup:   nis sss
>> sudoers:files sss
>> 
>> Interestingly after I do "getent group devops_team" this group shows up:
>> 
>> nkrzalic@ircsrv1:~$ id
>> uid=281200051(nkrzalic) gid=281200051(nkrzalic)
>> groups=281200051(nkrzalic),28121(devops_team)
>> nkrzalic@ircsrv1:~$
>> 
>> 
>> Any ideas?
>> 
>> 
>
>try to kill the cache with:
>(stop sssd) rm -rf /var/lib/sss/db/* (start sssd)
>
>we has had the same problems often here and only really kill the cache has
>fixed it (sss_cache -A hasnt help)
>
I'm sorry it is not a solution.
If you still have a problem and you are able to reproduce it
then please file a bug with log files.

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] Any thoughts on sssd_sudo memory usage ?

[Lukas Slebodnik]

On (25/05/15 07:30), Vaclav Adamec wrote:
>Hi,
> after last update I see this:
>
> PID USERPR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
> 5918 root  20   0 4413m 4.1g 1596 S  2.8 35.4  31:12.72 sssd_sudo
>
>sssd-common-1.11.6-30.el6_6.4.x86_64 on CentOS release 6.6 final (up2date)
>
>restart, sync + swap cleanup and in less then 24h I get same memory usage.
>
Could you draw a graph of sssd_sudo memory usage?
or at least gather data
 (ps -eo pid,cmd,size,rss | grep sssd_sudo)

Can you see any errors in sssd_sudo log after enabling verbose logging?
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] Any thoughts on sssd_sudo memory usage ?

[Lukas Slebodnik]

On (26/05/15 06:44), Vaclav Adamec wrote:
>With higher debug level I see that sssd sudo trying to resolve local
>account (for nagios monitoring)
>
There was/is a bug which does not respect filter_user in sudo provider
https://fedorahosted.org/sssd/ticket/2625. (It's already fixed in fedora >= 22)

It would be a workaround for you.

>On Tue, May 26, 2015 at 6:39 AM, Vaclav Adamec
> wrote:
>> ps -eo pid,cmd,size,rss | grep sssd_sudo
>> 1533 /usr/libexec/sssd/sssd_sudo 4245972 4247700
>>
>> and huge amount of this (trying again and again):
>>
>> (Tue May 26 06:35:47 2015) [sssd[sudo]]
>> [sudosrv_check_user_dp_callback] (0x0040): Could not look up the user
>> [2]: No such file or directory
>> (Tue May 26 06:35:47 2015) [sssd[sudo]] [sudosrv_get_user] (0x0080):
>> No results for getpwnam call
>>
>> but other servers in same datacenter looks ok in the same time, but
>> later this error was visible also on others, it's just question of
>> time.
I assume you have sssd-1.11 because such bug was fixed in sssd-1.12
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=09579ae252c181c7884defc0612c36108f6cf509

You can test with my pre-release of sssd-1.12.5
https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/
(It already contains fix for #2625)

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-backup and ipa-restore

[Lukas Slebodnik]

On (25/05/15 10:00), Bob Hinton wrote:
>Hi Martin,
>
>Yes. This fixes the problem on a newly recreated ipamaster - it didn't
>work on the one I'd been playing around with.
>
>So the complete rebuild sequence was...
>
>1) On old ipamaster VM ipa004 (did this on 22/05/2015)
> login as an admin user with sudo to root access
> sudo -i
> ipa-backup
> tar cvfPz ipa004_backups_22052015.tgz /var/lib/ipa/backup
> scp ipa004_backups_22052015.tgz to a backup system, destroy old
>ipamaster VM
>
>2) Recreate ipamaster VM (identical configuration to original)
>From backup system -
>scp ipa004_backups_22052015.tgz admin@ipa004:
>ssh admin@ipa004
>su (enter root password - no users with sudo
>access exist yet)
>tar xvfPz ipa004_backups_22052015.tgz
>ipa-restore ipa-full-2015-05-22-17-28-01
>systemctl stop sssd
>rm -f /var/lib/sss/db/*
>systemctl start sssd
Could  ipa-restore do previous 3 operations?

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] dereference processing failed : Invalid argument

[Lukas Slebodnik]

On (27/05/15 14:22), nat...@nathanpeters.com wrote:
>I have a CentOS 6.3 client with sssd 1.11.6-30.el6_6.4 installed and when
>one of my FreeIPA users tries to sudo (he has permissions via group
>membership) I get the following error in /var/log/messages
>
>May 27 20:51:34 ipaclient sssd[be[mydomain.net]]: dereference processing
>failed : Invalid argument
>
>I have read that this is a known bug
>(https://bugzilla.redhat.com/show_bug.cgi?id=1154042) and that the
>suggested fix is to add the following line to the domain section of the
>sssd.conf :
>
>ldap_group_object_class = ipaUserGroup
>
You cannot hit BZ1154042, because it is already fixed in 1.11.6-30.el6_6.4
@see https://bugzilla.redhat.com/show_bug.cgi?id=1165074

>I tried adding that and then restarting the client, but it did not fix the
>problem.  I have also read that this problem may only apply to POSIX
>groups so I removed my user from all POSIX groups, added him to non posix
>groups and then created some new sudo rules and hbac rules. I restarted
>the client again and still had the same issue where I could login but not
>sudo.
>
>Is there a known workaround that actually works?
>
>I see this bug is supposed to be fixed in sssd 1.11.8.  Is this version of
>sssd going to be released into any repo for CentOS 6?
>
No 1.11.8 will not be release in CentOS 6. CentOS just rebuild rhel src.rpm
packages. However rhel 6.7-beta has already sssd-1.12.4-x.

If you want you can test with pre-release of upstream 1.12.5
https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/

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] Problem to install FreeIPA Server 3.0 on a RedHat 6.4

[Lukas Slebodnik]

On (29/05/15 18:56), bahan w wrote:
>Hm.
>
>@Jakub :
>I cannot upgrade, because I am not the hosting provider managing this VM
>unfortunately.
>I need to make it work with RHEL 6.4.
>
>@Sam :
>Selinux is deactivated :
>
>cat /etc/selinux/config
># This file controls the state of SELinux on the system.
># SELINUX=disabled
>#   enforcing - SELinux security policy is enforced.
>#   permissive - SELinux prints warnings instead of enforcing.
>#   disabled - SELinux is fully disabled.
>SELINUX=disabled
We do not test with disabled SELinux.
Could you try with "permissive" ?

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] login delay with sssd

[Lukas Slebodnik]

On (01/06/15 15:42), Ivars Strazdiņš wrote:
>Hi,
>how could I possibly trace why there is a noticeable delay when logging into 
>sssd enabled server?
>With ssh there is a 2-3 second delay before users logs in. But most users 
>notice this with webmail, which uses dovecot->pam->sssd as authentication 
>backend.
>Environment is Centos 7.1 and FreeIPA 4.1.0 servers, two redundant.
>Client also running Centos 7.1 with sssd.
>Installation as per IPA handbook. DNS is proper (or so I think :) ).
>Nothing special in logs that I could attribute to this problem except maybe 
>that for each successful login there is a pam_unix failure entry in 
>/var/log/secure log like:
>Jun  1 17:38:36 mail auth: pam_unix(dovecot:auth): authentication failure; 
>logname= uid=0 euid=0 tty=dovecot ruser=us...@company.com rhost=::1  
>user=us...@company.com
>Jun  1 17:38:37 mail auth: pam_sss(dovecot:auth): authentication success; 
>logname= uid=0 euid=0 tty=dovecot ruser=us...@company.com rhost=::1 
>user=us...@company.com
>
>But when user is logged in, “id” command result is instantaneous.
>All machines have selinux enabled, of course.
How many groups does problematic user have?

Some performance degradation caused by semanage.
Here is an upstream ticket
https://fedorahosted.org/sssd/ticket/2624.

It is already fixed in fedora,
but you can test with prerelease of sssd-1.12.5
https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/

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] sssd not caching public keys in sss_authorized_keys file

[Lukas Slebodnik]

On (02/06/15 15:25), nat...@nathanpeters.com wrote:
>I am running FreeIPA 4.1.3 on CentOS 7 for the server and on the client is
>CentOS 6.5 with client 3.0.0-42 (sssd 1.11.6-30).
>
>I have created a user in FreeIPA and he has access to a server through
>HBAC rules.  This user has created a public / private keypair and uploaded
>the public key from his personal machine to the IPA server so it shows up
>in his user record.  The record was saved and he successfully logged into
>the IPA client using the keys.
>
>According to the docs here (Yes, I know it's a little old but I could not
>find any newer info that conflicted with this) :
>https://docs.fedoraproject.org/en-US/Fedora/18/html/System_Administrators_Guide/openssh-sssd.html
>
Aa you already notice it isquite old documetation.

>2.Stores the user key in a custom file, .ssh/sss_authorized_keys, in the
>standard authorized keys format.
>
There's bug in documentation.

>However, when he logs in, there is no sss_authorized_keys file created and
>as far as I can tell, the key is never cached in his account.
>
The better test would be to authenticate with ssh keys online,
so they can be fetched from FreeIPA
then block connection to FreeIPA (simmulate offline state)
and re-test one more time.

>How do I get the keys to actually save on login like the manual says?
Keys are already cached in different file /var/lib/sss/pubconf/known_hosts.
@see rhel7 documentation [1]

rhel7 documentation[1] should contain valid and recent information.
If you found any issues plese report them.

LS

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/System-Level_Authentication_Guide/index.html#openssh-sssd-hosts

-- 
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 handle users with multiple homedirs on different machines?

[Lukas Slebodnik]

On (02/06/15 17:07), swartz wrote:
>I have a environment that spans across multiple physical locations where
>there is a mix of Linux and Solaris workstations/servers. So far we've been
>managing accounts (/etc/password) via Puppet.
>
>Problem: FreeIPA allows to store only one homedir path.
>Q: Is there a way to store/set a different home path based on the system
>that the user is logged into?
>
sssd configuration is quite flexible in this way.
You can override homedir with configuration option
man sssd.conf -> "override_homedir"

However sssd is available just on linux (or FreeBSD)
I'm not sure which clients do you use on Solaris or other
old system, maybe there is a way how to override homedir as well.
Or you can configure home directory attribute to the non-existing
attribute in FreeIPA and use some fallback (if possible)

>As an example, I have user Bob.
>On a Linux box Bob has homedir at /home/b/bob
 ^
Unfortunatelly, there's no way how to say
sssd to use just first letter from name.
>On a Solaris this is likely /export/home/bob
>While on some other odd system it could be /mnt/nas/users/bob
Different "prefix" for homedir "/export/home", "/home", "/mnt/nas/users"
could be addresed with the option homedir_substring in sssd conf.
https://fedorahosted.org/sssd/ticket/1853

So you could store "%H" in ldap attribute,
but clients need to understand such value.
(sssd >= 1.11.6). I'm not sure about other clients.

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 handle users with multiple homedirs on different machines?

[Lukas Slebodnik]

On (03/06/15 12:54), Coy Hile wrote:
>
>
>For solaris, just use the standard automounter config in auto_home:
>*  /export/home/&
I thought that automount and "getent passwd user"
are two different thigs on Solaris (the same as on Linux)

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 not caching public keys in sss_authorized_keys file

[Lukas Slebodnik]

On (03/06/15 11:48), nat...@nathanpeters.com wrote:
>> On Wed, 2015-06-03 at 09:57 -0700, nat...@nathanpeters.com wrote:
>>> Comments inline
>>>
>>> > On (02/06/15 15:25), nat...@nathanpeters.com wrote:
>>> >>I am running FreeIPA 4.1.3 on CentOS 7 for the server and on the
>>> client
>>> >> is
>>> >>CentOS 6.5 with client 3.0.0-42 (sssd 1.11.6-30).
>>> >>
>>> >>I have created a user in FreeIPA and he has access to a server through
>>> >>HBAC rules.  This user has created a public / private keypair and
>>> >> uploaded
>>> >>the public key from his personal machine to the IPA server so it shows
>>> up
>>> >>in his user record.  The record was saved and he successfully logged
>>> into
>>> >>the IPA client using the keys.
>>> >>
>>> >>According to the docs here (Yes, I know it's a little old but I could
>>> not
>>> >>find any newer info that conflicted with this) :
>>> >>https://docs.fedoraproject.org/en-US/Fedora/18/html/System_Administrators_Guide/openssh-sssd.html
>>> >>
>>> > Aa you already notice it isquite old documetation.
>>> >
>>> >>2.Stores the user key in a custom file, .ssh/sss_authorized_keys, in
>>> the
>>> >>standard authorized keys format.
>>> >>
>>> > There's bug in documentation.
>>> >
>>> >>However, when he logs in, there is no sss_authorized_keys file created
>>> >> and
>>> >>as far as I can tell, the key is never cached in his account.
>>> >>
>>> > The better test would be to authenticate with ssh keys online,
>>> > so they can be fetched from FreeIPA
>>> > then block connection to FreeIPA (simmulate offline state)
>>> > and re-test one more time.
>>>
>>> Ok, so I looked at the newer documentation you linked below (RH7
>>> version)
>>> and it makes the exact same statement "Stores the user key in a custom
>>> file, .ssh/sss_authorized_keys, in the standard authorized keys format.
>>> "
>>>
>>> Are you saying the newer documentation is also bugged?
>>>
>>> Unfortunately, that type of test will not be conclusive for the people I
>>> am trying to convince.  They want me to actually show them the file on
>>> disk where that thing is cached to prove that if the machine was
>>> rebooted,
>>> and the ipa connection is lost, that key was not only in memory
>>> somewhere
>>> but actually saved to storage.
>>>
>>> >
>>> >>How do I get the keys to actually save on login like the manual says?
>>> > Keys are already cached in different file
>>> > /var/lib/sss/pubconf/known_hosts.
>>> > @see rhel7 documentation [1]
>>>
>>> The known_hosts file does not sound like the right place,  It has a
>>> completely different function of caching host keys for when I make an
>>> outgoing connection from the server for the purpose of verifying someone
>>> is not spoofing a host, not for caching individual user keys for
>>> passwordless login for when I'm trying to make an ingoing connection to
>>> the server.
>>>
>>> In addition, you can see from my search below that there is no
>>> sss_authorized_keys file anywhere on the server and that the known_hosts
>>> file you referenced has no data in it because it is zero size.
>>>
>>> [root@ipaclient sss]# find / -name sss_authorized_keys
>>> [root@ipaclient sss]# cd pubconf
>>> [root@ipaclient pubconf]# ls -al
>>> total 16
>>> drwxr-xr-x 3 root root 4096 Jun  3 16:42 .
>>> drwxr-xr-x 6 root root 4096 May 27 22:49 ..
>>> -rw-r--r-- 1 root root   11 Jun  3 16:42 kdcinfo.MYDOMAIN.NET
>>> -rw-r--r-- 1 root root0 Jun  2 16:05 known_hosts
>>> drwxr-xr-x 2 root root 4096 May 28 01:13 krb5.include.d
>>> [root@ipaclient pubconf]#
>>>
>>> So... I am still looking for the actual location on disk that this is
>>> apparently being cached and cannot find it.
>>
>> You won't find a "file" because user's public keys are not stored in a
>> file.
>> They are stored in the ldb cache with all other user information, and
>> then extracted from the cache (or queried from the server if online and
>> the cache is expired) on request.
>>
>> You can use the ldbsearch tool against the sssd ldb cache file and look
>> for entries with the sshPublicKey attribute.
>>
>> HTH,
>> Simo.
>>
>> --
>> Simo Sorce * Red Hat, Inc * New York
>>
>>
>
>Oh this is great information.  Thank you.
>
>It appears that the documentation should state that the user keys are
>cached not in .ssh/sss_authorized_keys
I didn't notice it in documentation. We fixed info about known_hosts.
Thank you for a report.

>but actually in
>/var/lib/sss/db/cache_yourdomain.ldb as I was able to search and
>successfully find the user key by running 'ldbsearch -H
>cache_mydomain.net.ldb  sshPublicKey'
Simpler way for checking cached public ssh key is to use the same utility as
sssd/sshd

# go offline and run next command.
sh$ sss_ssh_authorizedkeys usersssd

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 started crashing suddenly

[Lukas Slebodnik]

On (05/06/15 07:35), Rich Megginson wrote:
>On 06/05/2015 03:40 AM, Dawid Rabiega wrote:
>>Hi,
>>One of my ipa server on fedora 19 since yesterday started to crash, with
>>following message to dmesg:
>>
>>$ dmesg | tail -n 20
>>[6706148.291648] ns-slapd[3212]: segfault at 0 ip 7f6fc9a84421 sp
>>7f6f8f7eb928 error 4 in libc-2.17.so
>>[7f6fc99fe000+1b6000]
>>[6706170.887926] ns-slapd[3359]: segfault at 0 ip 7f923ce89421 sp
>>7f91fd7e7928 error 4 in libc-2.17.so
>>[7f923ce03000+1b6000]
>>[6706264.491787] ns-slapd[3463]: segfault at 0 ip 7f2d9020d421 sp
>>7f2d527e9928 error 4 in libc-2.17.so
>>[7f2d90187000+1b6000]
>>[6706311.092133] ns-slapd[4015]: segfault at 0 ip 7f62287d7421 sp
>>7f61efff4928 error 4 in libc-2.17.so
>>[7f6228751000+1b6000]
>>[6706500.581441] ns-slapd[4361]: segfault at 0 ip 7facbe1e1421 sp
>>7fac807e5928 error 4 in libc-2.17.so
>>[7facbe15b000+1b6000]
>>[6706690.693958] ns-slapd[4932]: segfault at 0 ip 7f8d72cbc421 sp
>>7f8d3d7f7928 error 4 in libc-2.17.so
>>[7f8d72c36000+1b6000]
>>[6715473.156094] ns-slapd[18406]: segfault at 0 ip 7f22fedea421 sp
>>7f22c1fe8928 error 4 in libc-2.17.so
>>[7f22fed64000+1b6000]
>>[6716455.653949] ns-slapd[20571]: segfault at 0 ip 7f190695e421 sp
>>7f18dcff6928 error 4 in libc-2.17.so
>>[7f19068d8000+1b6000]
>>[6716646.006961] ns-slapd[21375]: segfault at 0 ip 7ffb9c889421 sp
>>7ffb64ff6928 error 4 in libc-2.17.so
>>[7ffb9c803000+1b6000]
>>[6717027.574362] ns-slapd[22082]: segfault at 0 ip 7f9fdbda7421 sp
>>7f9faeffa928 error 4 in libc-2.17.so
>>[7f9fdbd21000+1b6000]
>>[6751004.788596] ns-slapd[9779]: segfault at 0 ip 7f0398f48421 sp
>>7f03617f7928 error 4 in libc-2.17.so
>>[7f0398ec2000+1b6000]
>>[6751019.360517] ns-slapd[10018]: segfault at 0 ip 7f267852c421 sp
>>7f263afea928 error 4 in libc-2.17.so
>>[7f26784a6000+1b6000]
>>[6751154.258362] ns-slapd[10179]: segfault at 0 ip 7f2c6d854421 sp
>>7f2c31ff0928 error 4 in libc-2.17.so
>>[7f2c6d7ce000+1b6000]
>>[6751208.966127] ns-slapd[10520]: segfault at 0 ip 7f9a31a59421 sp
>>7f99f87ed928 error 4 in libc-2.17.so
>>[7f9a319d3000+1b6000]
>>[6751305.469969] ns-slapd[10608]: segfault at 0 ip 7f6e9348b421 sp
>>7f6e55ff0928 error 4 in libc-2.17.so
>>[7f6e93405000+1b6000]
>>[6751328.997404] ns-slapd[10736]: segfault at 0 ip 7f8c936b1421 sp
>>7f8c5d7f7928 error 4 in libc-2.17.so
>>[7f8c9362b000+1b6000]
>>[6751432.356753] ns-slapd[10835]: segfault at 0 ip 7f7dffd84421 sp
>>7f7dca7f9928 error 4 in libc-2.17.so
>>[7f7dffcfe000+1b6000]
>>[6751454.826551] ns-slapd[11107]: segfault at 0 ip 7f03621d5421 sp
>>7f0326fea928 error 4 in libc-2.17.so
>>[7f036214f000+1b6000]
>>[6751549.459424] ns-slapd[11414]: segfault at 0 ip 7f9e0f74b421 sp
>>7f9dd2fea928 error 4 in libc-2.17.so
>>[7f9e0f6c5000+1b6000]
>>[6751573.611284] ns-slapd[11567]: segfault at 0 ip 7f044fd73421 sp
>>7f0419ff8928 error 4 in libc-2.17.so
>>[7f044fced000+1b6000]
>>
>>$ rpm -qa | grep 389
>>389-ds-base-1.3.1.22-1.fc19.x86_64
>>389-ds-base-libs-1.3.1.22-1.fc19.x86_
>>
>>$ rpm -qa | grep ipa
>>libipa_hbac-python-1.11.5.1-1.fc19.x86_64
>>sssd-ipa-1.11.5.1-1.fc19.x86_64
>>freeipa-client-3.3.5-1.fc19.x86_64
>>freeipa-admintools-3.3.5-1.fc19.x86_64
>>freeipa-server-3.3.5-1.fc19.x86_64
>>python-iniparse-0.4-7.fc19.noarch
>>libipa_hbac-1.11.5.1-1.fc19.x86_64
>>freeipa-python-3.3.5-1.fc19.x86_64
>>
>>I have no idea what happened, and what check next. Any idea?
>
>We'll need to get a core, and see a good stacktrace from the core.
>http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
>Since this is IPA, you'll need to
>
># debuginfo-install 389-ds-base ipa-server slapi-nis
>
Fedora 19 is not supported since 2015-01-06

Could you try to test with fedora 20?
It might be possible that bug is already fixed in newer versions.

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] ssh known hosts gets recreated on client

[Lukas Slebodnik]

On (10/06/15 11:33), Bob Hinton wrote:
>Hello,
>
>If I uninstall the ipa client with "ipa-client-install --uninstall" then
>reinstall it to the same ipa master then most functions work fine.
>However, if I attempt to ssh from the client to the master then I get.
>
>@@@
>@WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
>@@@
>IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
>Someone could be eavesdropping on you right now (man-in-the-middle attack)!
>It is also possible that the RSA host key has just been changed.
>The fingerprint for the RSA key sent by the remote host is
>86:c1:d7:96:8d:a3:b6:54:69:7c:cf:79:55:b3:14:c1.
>Please contact your system administrator.
>Add correct host key in /home/gbob/.ssh/known_hosts to get rid of this
>message.
>Offending key in /var/lib/sss/pubconf/known_hosts:1
>RSA host key for ipa004.jackland.co.uk has changed and you have
>requested strict checking.
>Host key verification failed.
>
>I've tried stopping the sssd service on the client, removing
>/var/lib/sss/pubconf/known_hosts and /var/lib/sss/db/* then restarting
>sssd, but /var/lib/sss/pubconf just gets recreated with the old contents
>and I get the same error (it seems odd that it's reporting that the host
>key of the master has changed when it's the client that has been
>reinstalled). How do I clear-out the client's knowledge of the old host
>keys?
>
>In this case I'm using ipa-client v3.0.0 on RHEL6.6
>
You removed /var/lib/sss/pubconf/known_hosts
and also sssd cache, but you still have problem after restarting sssd.

So the only explanation is that wrong host public key is stored in FreeIPA.
Could you try to check host public key with ldapsearch in FreeIPA.
I think you wold need to do it as an admin.

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] newer sssd on centos 5?

[Lukas Slebodnik]

On (11/06/15 18:21), Janelle wrote:
>Has anyone built a newer version of sssd for RHEL/centos 5.x?? Currently only
>1.5.x
>
There is also 1.9 in COPR repo[1]
>Just wondering if maybe it is limited due to some library or compatibility
>issues?
It's possible to build sssd-1.11 on el5 as well but without samba libraries
an thus without ipa and ad provider.

LS

[1] https://copr.fedoraproject.org/coprs/sgallagh/sssd-1.9-rhel5/

-- 
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] 4.x on CentOS 6?

[Lukas Slebodnik]

On (13/06/15 16:04), Janelle wrote:
>Hi everyone,
>
>Does anyone know if it is possible to install the 4.1 ipa-CLIENT (not the
>server - just the client) on a CentOS 6.6 system? My guess is this is really
>just based on sssd, or am I missing something?
>
If you want newer version of sssd you can test backported version
from fedora. Here is a COPR repo [1].
It is a stable branch sssd-1.12, so it contains many fixes for bugs
in el 6.6.

>I would like to get OTP on 6.6 system, just not sure if that is possible.
>
IIRC you would need a support or OTP in kerberos as well.
So you would need to backport it yourself or to find
newer packages somewhere.

LS

[1] https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12/

-- 
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] hesitate to deploy freeipa

[Lukas Slebodnik]

On (26/06/15 01:29), Prasun Gera wrote:
>I've found that if you are setting up a new environment from scratch which
>is mostly going to involve RHEL/Fedora systems, and that you have full
>control over your network including DNS, DHCP etc., it should mostly be
>smooth sailing. However, if you already have a network of old and new
>machines running different versions and flavours of unix, there is
>significantly more work involved. That is, there is significant complexity
>on client side code as well which should not be discounted. Do a survey of
>the state of client side support on different distributions. From my
>experience, Ubuntu 12.04 is iffy. There's also an open ticket pushed to
ipa-client-install is not properly ported to ubuntu 12.04 and
moreover there is quite there quite old version of sssd 1.11.5-1
which contains may bugs. Lots of them are fixed in upstream 1.11.7
and some of them in 1.11.8 which we would like to release in few weeks.
so If you hit bugs on ubuntu 12.04 please try latest upstream version (1.11)
or file bugs to ubuntu.

>'future' on FreeNAS, which is BSD based. IMO this is one of the major
>hurdles for wider adoption.
>
FreeNAS is based on FreeBSD and ipa-client-install is not available there.
The only benefit is newer version of sssd (1.11.7) than in ubuntu 12.04.
There was also thread here(freeipa-users) with document describing steps
for configuration on FreeBSD.

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 FAILING TO START ON CENTOS 6.6 32BIT

[Lukas Slebodnik]

On (26/06/15 09:32), Martin Chamambo wrote:
>This is my sssd.conf file and I have that config_file_version = 2
>
>[root@server sssd]# vim sssd.conf 
>
> [domain/ai.co.zw]
>
>debug_level = 10
>cache_credentials = True
>krb5_store_password_if_offline = True
>ipa_domain = ai.co.zw
>id_provider = ipa
>auth_provider = ipa
>access_provider = ipa
>ipa_hostname = nimbus.ai.co.zw
>chpass_provider = ipa
>ipa_server = _srv_, ipaserver.ai.co.zw
>ldap_tls_cacert = /etc/ipa/ca.crt

>[sssd]
>services = nss, sudo, pam, autofs, ssh
>config_file_version = 2
>
>domains = default, ai.co.zw
   
You have non existing domain listed here.
Try to remove it. But I do not see a reason why it should cause
troubles for domain "ai.co.zw"

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] hesitate to deploy freeipa

[Lukas Slebodnik]

On (26/06/15 12:48), Petr Spacek wrote:
>On 26.6.2015 12:18, Lukas Slebodnik wrote:
>> On (26/06/15 01:29), Prasun Gera wrote:
>>> I've found that if you are setting up a new environment from scratch which
>>> is mostly going to involve RHEL/Fedora systems, and that you have full
>>> control over your network including DNS, DHCP etc., it should mostly be
>>> smooth sailing. However, if you already have a network of old and new
>>> machines running different versions and flavours of unix, there is
>>> significantly more work involved. That is, there is significant complexity
>>> on client side code as well which should not be discounted. Do a survey of
>>> the state of client side support on different distributions. From my
>>> experience, Ubuntu 12.04 is iffy. There's also an open ticket pushed to
>> ipa-client-install is not properly ported to ubuntu 12.04 and
>> moreover there is quite there quite old version of sssd 1.11.5-1
>> which contains may bugs. Lots of them are fixed in upstream 1.11.7
>> and some of them in 1.11.8 which we would like to release in few weeks.
>> so If you hit bugs on ubuntu 12.04 please try latest upstream version (1.11)
>> or file bugs to ubuntu.
>> 
>>> 'future' on FreeNAS, which is BSD based. IMO this is one of the major
>>> hurdles for wider adoption.
>>>
>> FreeNAS is based on FreeBSD and ipa-client-install is not available there.
>> The only benefit is newer version of sssd (1.11.7) than in ubuntu 12.04.
>> There was also thread here(freeipa-users) with document describing steps
>> for configuration on FreeBSD.
>
>More importantly, ipa-client-install is just a thin configuration tool. If
>ipa-client-install is not available on your platform you can configure
>everything manually and it will work (as long as the client is
>standard-compliant).
>
>I.e. the client side is *in the worst case* (without ipa-client-install)
>equally hard to setup as for any home-made solution.
>
There is a ticket[1] for description of steps done by ipa-client-install.
One use-case is "containers world" and another is to help others to manually
configure machine against FreeIPA. It is planned fo FreeIPA 4.2 release
So I hope it will be finished on time.

LS

[1] https://fedorahosted.org/freeipa/ticket/4993

-- 
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] hesitate to deploy freeipa

[Lukas Slebodnik]

On (26/06/15 10:10), Prasun Gera wrote:
>>
>> More importantly, ipa-client-install is just a thin configuration tool. If
>> ipa-client-install is not available on your platform you can configure
>> everything manually and it will work (as long as the client is
>> standard-compliant).
>>
>> I.e. the client side is *in the worst case* (without ipa-client-install)
>> equally hard to setup as for any home-made solution.
>>
>>
>>
>
>Yes, on Ubuntu 12.04, the issue is probably more related to the script than
>the underlying packages, which I upgraded from their respective ppas. The
>most complete documentation for getting ipa running, ironically, comes from
>this bug report
>https://bugs.launchpad.net/ubuntu/+source/freeipa/+bug/1280215 which is
>marked as won't fix. (This affects 12.04 btw which is lts).
>
>On FreeNAS, it has to do with Hiemdal v/s MIT kerberos.
>https://bugs.pcbsd.org/issues/2147
SSSD on FreeBSD is compiled with MIT kerberos (/usr/local/*)
and not with default Heimdal which is in standard paths.

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 sudden stop

[Lukas Slebodnik]

On (30/06/15 11:17), Umarzuki Mochlis wrote:
>Every once in a week suddenly IPA service would failed and only
>realized when zimbra that using authentication with it failed during
>user log in.
>
>So I had to type in below commands one by one each time this happened.
>
>systemctl start dirsrv@DOMAIN-COM.service
>systemctl start krb5kdc.service
>systemctl start kadmin.service
>systemctl start ipa_memcached.service
>systemctl start httpd.service
>
># cat /etc/redhat-release
>Fedora release 18 (Spherical Cow)
>
End  of life for Fedora 18 was 2014-01-14.
See https://fedoraproject.org/wiki/End_of_life

Could you try to upgrade to recent release (fedora 21)?
If you did not want to upgrade very often then it would
be better to use distribution with longer support time.
RHEL/CentOS

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 client on ubuntu and sudo rules

[Lukas Slebodnik]

On (10/07/15 16:19), Karl Forner wrote:
>Hello,
>
>I setup an ubuntu client for freeIPA 4.1.4, and sudo rules do not seem to
>work.
>I then realized that I used ipa-client-install version 3.3.4.
>Is this a plausible cause ?
>And if so, where can I get a more recent version for ubuntu/debian ?
Never version of ipa-client configures sssd integration with sudo by default.
Please follow intructions from manual page sssd-sudo and you should be able
to configure it yourself. Different version of sssd requires different
configuration with ipa provider.

IIRC sssd > 1.10 nas native ipa sudo provider so you need't to
configure sudo ldap provider with IPA. That's the reason why it's better to
follow instruction form man 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] ipa client on ubuntu and sudo rules

[Lukas Slebodnik]

On (13/07/15 14:49), Karl Forner wrote:
>For reference:
>I could not make the sudo rules on ubuntu 12.04, I tried many many things.
>
Ahh,
Default version of sssd in ubuntu 12.04 is 1.8.2
http://packages.ubuntu.com/precise/sssd
it's better to use newer version which contains fixes for sudo.
I would suggest at least the latest 1.9.

But there is another problem.
The default version of sudo in ununtu 12.04 (1.8.3p1) does not contain sssd
support.
http://packages.ubuntu.com/precise/sudo.

The support for sssd in sudo code was added in upstream sudo 1.8.6
http://www.sudo.ws/stable.html#1.8.6

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] Failed to start pki-tomcatd Service

[Lukas Slebodnik]

On (10/07/15 17:28), Alexandre Ellert wrote:
>
>> Le 30 juin 2015 à 10:16, Alexandre Ellert  a écrit :
>> 
>> 
>>> Could you please provide the content of logfile:
>>> `/var/log/pki/pki-tomcat/ca/debug', around the time the error
>>> occurs?
>>> 
>>> Thanks,
>>> Fraser
>> 
>> When the pki-tomcatd service is trying to start, I see this message in 
>> /var/log/pki/pki-tomcat/ca/debug
>> 
>> [30/Jun/2015:10:02:13][localhost-startStop-1]: 
>> 
>> [30/Jun/2015:10:02:13][localhost-startStop-1]: =  DEBUG SUBSYSTEM 
>> INITIALIZED   ===
>> [30/Jun/2015:10:02:13][localhost-startStop-1]: 
>> 
>> [30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: done init id=debug
>> [30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: initialized debug
>> [30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: initSubsystem 
>> id=log
>> [30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: ready to init 
>> id=log
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: done init id=log
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initialized log
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initSubsystem 
>> id=jss
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: ready to init 
>> id=jss
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: done init id=jss
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initialized jss
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initSubsystem 
>> id=dbs
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: ready to init 
>> id=dbs
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: DBSubsystem: init()  
>> mEnableSerialMgmt=true
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: LdapBoundConnFactory: init 
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: 
>> LdapBoundConnFactory:doCloning true
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: LdapAuthInfo: init()
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: LdapAuthInfo: init begins
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: LdapAuthInfo: init ends
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: init: before makeConnection 
>> errorIfDown is true
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: makeConnection: errorIfDown 
>> true
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: LdapJssSSLSocket set client 
>> auth cert nicknamesubsystemCert cert-pki-ca
>> [30/Jun/2015:10:02:14][localhost-startStop-1]: CMS:Caught EBaseException
>> Internal Database Error encountered: Could not connect to LDAP server host 
>> ipa.mydomain.org  port 636 Error 
>> netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1)
>>  at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:658)
>>  at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:934)
>>  at 
>> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:865)
>>  at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:362)
>>  at com.netscape.certsrv.apps.CMS.init(CMS.java:189)
>>  at com.netscape.certsrv.apps.CMS.start(CMS.java:1585)
>>  at 
>> com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:96)
>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>  at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>  at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>  at java.lang.reflect.Method.invoke(Method.java:606)
>>  at 
>> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
>>  at 
>> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
>>  at java.security.AccessController.doPrivileged(Native Method)
>>  at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
>>  at 
>> org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
>>  at 
>> org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
>>  at 
>> org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123)
>>  at 
>> org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272)
>>  at 
>> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
>>  at 
>> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
>>  at 
>> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210)
>>  at 
>> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493)
>>  at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>>  at 
>> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
>>  at 
>> org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
>>  at 
>> org.apache.catalina.core.ContainerBase$Privil

Re: [Freeipa-users] Failed to start pki-tomcatd Service

[Lukas Slebodnik]

On (16/07/15 09:56), Alexandre Ellert wrote:
>
>> Le 16 juil. 2015 à 09:29, Lukas Slebodnik  a écrit :
>>
>> I had a similar issue on fedora 21 or fedora 22.
>> The workarounds from freeipa ticket #4666 did not help for me either.
>> I found out that there was some problem with upgrading dogtag configuration.
>>
>> You can try up ru upgrade manually. It might help you.
>> [root@vm-114 ~]# rpm -q --scripts pki-server
>> postinstall scriptlet (using /bin/sh):
>> ## NOTE:  At this time, NO attempt has been made to update ANY PKI subsystem
>> ##from EITHER 'sysVinit' OR previous 'systemd' processes to the new
>> ##PKI deployment process
>>
>>echo "Upgrading server at `/bin/date`." >>
>>/var/log/pki/pki-server-upgrade-10.2.4.log 2>&1
>>/sbin/pki-server-upgrade --silent >>
>>/var/log/pki/pki-server-upgrade-10.2.4.log 2>&1
>>echo >> /var/log/pki/pki-server-upgrade-10.2.4.log 2>&1
>>
>>systemctl daemon-reload
>>
>>
>> In my case, it didn't help. So I updated freeipa to the latest version.
>> then I install similar new freeipa on another machine. So I had functional
>> dogtag. Then I tried to fix broken dogtag configuration using functional
>> configuration from 2nd freeipa. I would definitely recommend to backup data
>> from old freeipa before any manual updates.
>>
>> Maybe Fraser would have a better advice.
>>
>> LS
>
>I tried the suggested solution with pki-server-upgrade script but it didn’t 
>fix, the output was :
># cat /var/log/pki/pki-server-upgrade-10.1.2.log
>Upgrading from version 10.1.2 to 10.1.2:
>1. Add TLS Range Support
>
>Upgrade complete.
>
>I will try the second solution and install a fresh new IPA server to compare 
>dogtag configuration.
>Do you know what files/directory I should check ?
>
I filtered my bash history and here is an output. I hope the history contains
all files. Please do not forget to backup all data.

[root@vm-114 ~]# history | grep vimdiff
  272  vimdiff pki/pki-tomcat/pki.policy /etc/pki/pki-tomcat/pki.policy
  275  vimdiff pki/pki-tomcat/context.xml /etc/pki/pki-tomcat/context.xml
  277  vimdiff pki/pki-tomcat/tomcat-users.xml pki/pki-tomcat/tomcat-users.xml
  278  vimdiff pki/pki-tomcat/tomcat-users.xml 
/etc/pki/pki-tomcat/tomcat-users.xml
  280  vimdiff pki/pki-tomcat/log4j.properties 
/etc/pki/pki-tomcat/log4j.properties
  288  vimdiff pki/pki-tomcat/password.conf /etc/pki/pki-tomcat/password.conf
  290  vimdiff pki/pki-tomcat/password.conf /etc/pki/pki-tomcat/password.conf
  293  vimdiff pki/pki-tomcat/tomcat.conf /etc/pki/pki-tomcat/tomcat.conf
  299  vimdiff pki/pki-tomcat/server.xml /etc/pki/pki-tomcat/server.xml
  302  vimdiff pki/pki-tomcat/Catalina/localhost/ca.xml 
/etc/pki/pki-tomcat/Catalina/localhost/ca.xml
  304  vimdiff pki/pki-tomcat/ca/vlvtasks.ldif 
/etc/pki/pki-tomcat/ca/vlvtasks.ldif
  306  vimdiff pki/pki-tomcat/ca/caOCSPCert.profile 
/etc/pki/pki-tomcat/ca/caOCSPCert.profile
  307  vimdiff pki/pki-tomcat/ca/acl.ldif /etc/pki/pki-tomcat/ca/acl.ldif
  309  vimdiff pki/pki-tomcat/ca/adminCert.profile 
/etc/pki/pki-tomcat/ca/adminCert.profile
  312  vimdiff pki/pki-tomcat/ca/database.ldif 
/etc/pki/pki-tomcat/ca/database.ldif
  314  vimdiff pki/pki-tomcat/ca/db.ldif /etc/pki/pki-tomcat/ca/db.ldif
  316  vimdiff pki/pki-tomcat/ca/index.ldif /etc/pki/pki-tomcat/ca/index.ldif
  318  vimdiff pki/pki-tomcat/ca/manager.ldif 
/etc/pki/pki-tomcat/ca/manager.ldif
  320  vimdiff pki/pki-tomcat/ca/proxy.conf /etc/pki/pki-tomcat/ca/proxy.conf
  322  vimdiff pki/pki-tomcat/ca/registry.cfg 
/etc/pki/pki-tomcat/ca/registry.cfg
  325  vimdiff pki/pki-tomcat/ca/schema.ldif /etc/pki/pki-tomcat/ca/schema.ldif
  613  vimdiff pki/java/cacerts /etc/pki/java/cacerts
  623  vimdiff pki/default.cfg /etc/pki/default.cfg
  626  vimdiff pki/pki.version /etc/pki/pki.version
  632  vimdiff pki/pki-tomcat/logging.properties 
/etc/pki/pki-tomcat/logging.properties
  635  vimdiff pki/pki-tomcat/catalina.policy 
/etc/pki/pki-tomcat/catalina.policy
  638  vimdiff pki/pki-tomcat/web.xml /etc/pki/pki-tomcat/web.xml
  654  vimdiff pki/pki-tomcat/ca/CS.cfg /etc/pki/pki-tomcat/ca/CS.cfg
  666   vimdiff pki/ca-trust/ca-legacy.conf /etc/pki/ca-trust/ca-legacy.conf
  677  vimdiff pki/nssdb/pkcs11.txt /etc/pki/nssdb/pkcs11.txt
  684  vimdiff pki/default.cfg /etc/pki/default.cfg
  707  vimdiff pki/tls/openssl.cnf etc/pki/tls/openssl.cnf
  708  vimdiff pki/tls/openssl.cnf /etc/pki/tls/openssl.cnf
  871  vimdiff slapd-IDM-EXAMPLE-COM/dse.ldif 
/etc/dirsrv/slapd-IDM-EXAMPLE-COM/dse.ldif
 1005  vimdiff pki/pki-tomcat/ca/schema.ldif /etc/pki/pki-tomcat/ca/schema.ldif


It is also possible that some certificates might be expired because dogtag
was not functional for soem time. So please take a look into wiki:
https://www.freeipa.org/page/Howto/CA_Certificate_Renewal

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] Rename or not to rename (packages only)? freeipa-server -> ipa-server?

[Lukas Slebodnik]

On (17/07/15 11:15), Jan Pazdziora wrote:
>On Fri, Jul 17, 2015 at 10:47:37AM +0200, Petr Spacek wrote:
>> 
>> This rename would remove the inconsistency which drives me crazy when I need
>> to script something universally for RHEL and Fedora.
>
>Wouldn't rpm Provides solve this particular issue?
>
I would prefer this way as well.

and BTW packages in debian use names: freeipa-*
https://packages.debian.org/search?suite=sid&searchon=names&keywords=freeipa

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] Another Migration from 3.0 (CentOS 6.6) to 4.1 (CentOS 7.1)

[Lukas Slebodnik]

On (29/07/15 10:52), Guillermo Fuentes wrote:
>Thanks so much for the info David!
>We're using the latest version available via EPEL, which is 10.1.2.
>
pki-core is not available in epel7
https://admin.fedoraproject.org/pkgdb/package/pki-core/

So you have the latest version from base CentOS 7.1
CentOS rebuild rhel packages. So you will need
to wait for CentOS 7.2 for update.

>List, any idea where to grab pki 10.2.6 for CentOS 7? Source or binary
>would be fine. Or, if it isn't available, where can I start
>contributing to the port of pki 10.2.6 to CentOS 7?

You might try to backport pki-core from Fedora.
Good luck.

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] Ubuntu Samba Server Auth against IPA

[Lukas Slebodnik]

On (31/07/15 16:03), Matt . wrote:
>Hi Guys,
>
>I'm really struggeling getting a NON AD Samba server authing against a
>FreeIPA server:
>
>Ubuntu 14.04 -> Samba (no AD) / SSD 1.12.5
>CentOS 7.1 -> FreeIPA 4.1
>
>Now this seems to be the way:
>
>https://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA
>
As you can see this howto is mainly written for rpm based distributions.
The most important difference between sssd 1.12.5 for ubuntu[1]
and sssd >= 1.12 in fedora[2] is packaging of sssd-libwbclient.

sssd-libwbclient and libwbclient(from samba) use alternatives
to switch between these libraries.


Ubuntu 14.04
root@48c613c6a3fc:/# ls -l /usr/lib/x86_64-linux-gnu/libwbclient*
lrwxrwxrwx. 1 root root19 Jul  1 15:38
/usr/lib/x86_64-linux-gnu/libwbclient.so.0 -> libwbclient.so.0.11
-rw-r--r--. 1 root root 43216 Jul  1 15:38
/usr/lib/x86_64-linux-gnu/libwbclient.so.0.11

root@48c613c6a3fc:/# ls -l /usr/lib/x86_64-linux-gnu/sssd/modules/libwbclient*
lrwxrwxrwx. 1 root root21 Jun 15 18:14
/usr/lib/x86_64-linux-gnu/sssd/modules/libwbclient.so.0 ->
libwbclient.so.0.12.0
-rw-r--r--. 1 root root 30800 Jun 15 18:14
/usr/lib/x86_64-linux-gnu/sssd/modules/libwbclient.so.0.12.0


Fedora 21
bash-4.3# alternatives --display libwbclient.so.0.11-64
libwbclient.so.0.11-64 - status is auto.
 link currently points to /usr/lib64/samba/wbclient/libwbclient.so.0.11
/usr/lib64/samba/wbclient/libwbclient.so.0.11 - priority 10
/usr/lib64/sssd/modules/libwbclient.so.0.12.0 - priority 5
Current `best' version is /usr/lib64/samba/wbclient/libwbclient.so.0.11.


So if you want to use this howto on ubuntu then you need to create
symbolic links on your own.


Feel free to update Howto page with additional information
if you manage solve it on ubuntu.

LS

[1] https://launchpad.net/~sssd/+archive/ubuntu/updates
[2] https://admin.fedoraproject.org/updates/sssd

-- 
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] Ubuntu Samba Server Auth against IPA

[Lukas Slebodnik]

On (31/07/15 18:15), Matt . wrote:
>Hi Lucas,
>
>Thank you for this reply.
>
>In this case it simply should work as it shoul by creating the
>symlinks, Or are there other issues we might get ?
>
1st problem: current samba version of libwbclient need to be moved ot other
place.

2nd problem: manualy created symbolic links will be broken with next
update of sssd or samba (e.g. security update)

3rd problem: such changes in might cause troubles for other application
they need to be carefully tested (which are not on ubuntu)


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 (CentOS6) known to be unstable?

[Lukas Slebodnik]

On (04/08/15 07:56), Torsten Harenberg wrote:
>just realized that it's probably not an instablity, but some process is
>killing sssd:
>
>[root@wn113 sssd]# zcat sssd.log-20150804.gz
>(Mon Aug  3 20:30:55 2015) [sssd] [mt_svc_sigkill] (0x0010):
>[pleiades.uni-wuppertal.de][5957] is not responding to SIGTERM. Sending
>SIGKILL.
>(Mon Aug  3 20:31:31 2015) [sssd] [mt_svc_sigkill] (0x0010): [nss][7211]
>is not responding to SIGTERM. Sending SIGKILL.
This line says that the process sssd_nss was busy with some task
and was not responding to ping from the monitor process (sssd)
Therefore it was restarted.

>No one of the admins were logged in during that time and also "last"
>doesn't show any login.
>
>sssd was installed as a dependency from ipa-client and was
>autoconfigured by ipa-client-install. The config file looks normal to me:
>
>[domain/pleiades.uni-wuppertal.de]
>
>cache_credentials = True
>krb5_store_password_if_offline = True
>ipa_domain = pleiades.uni-wuppertal.de
>id_provider = ipa
>auth_provider = ipa
>access_provider = ipa
>ipa_hostname = wn113.pleiades.uni-wuppertal.de
>chpass_provider = ipa
>ipa_server = _srv_, ipa2.pleiades.uni-wuppertal.de,
>ipa.pleiades.uni-wuppertal.de
>ldap_tls_cacert = /etc/ipa/ca.crt
>[sssd]
>services = nss, sudo, pam, ssh
>config_file_version = 2
>
>domains = pleiades.uni-wuppertal.de
>[nss]
>homedir_substring = /home
>
>[pam]
>
>[sudo]
>
>[autofs]
>
>[ssh]
>
>[pac]
>
>[ifp]
>
>sssd.conf (END)
>
>
>Anybody seen something like this already?
It's hard to say. Without full log files.
I would recommend to follow intructions from upstream wiki[1].

In 1st mail you mention using newer version of sssd.
You can try the latest upstream version[2]
oryou can wait for CentOS6.7

LS

[1] https://fedorahosted.org/sssd/wiki/Troubleshooting
[2] https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12/

-- 
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 user ID differs

[Lukas Slebodnik]

On (04/08/15 07:11), Janelle wrote:
>I too have seen this same unique "bug".  My guess is, you have compatibility
>mode enabled AND you used the GUI to manipulate the group memberships. I have
>found this to be buggy. Using  CLI based commands did not have the same
>results. However, once the 2 trees - "cn=accounts" and "cn=compat" are no
>longer in sync, I have found the only way to fix this is with ldapmodify
>commands, since neither the GUI nor the command line tools believe the users
>are in the groups in question anymore.
>
It really sounds like a bug.

Did you try to call "id user" on ipa server?
I'm curious which uid/gid are returned from sssd.

If the uid/gid are correct does it help to restart
directory server (or 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] FreeIPA user ID differs

[Lukas Slebodnik]

On (05/08/15 13:02), markus@mc.ingenico.com wrote:
>Hey,
>
>I´ve wiped sss_cache before I tried again and restarted the service.
sss_cache just invalidate cache. It does not wipe out it.
It means that sssd must not return value from cache but it shoudl refresh it
from LDAP server

>Nevertheless the problem still persists. Beyond the problem is only located
>on one FreeIPA host. Other hosts have received the updates
>or see the correct values.
What do you mean by "FreeIPA host"?
Is it ipa server/replica or ipa client?

As it was already mantioned int is thread the compat tree is generated
dynamically based on the cn=accounts tree and from information retrieved
by server-mode SSSD.

I would suggest try following steps
1) invalidate sssd cache on ipa server
2) check UID/GID on ipa server (id, getent passwd, getent group ...)
3) check compat tree with ldapsearch
4) invalidate sssd cache on ipa client
5) check UID/GID on ipa client (id, getent passwd, getent group ...)

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 (CentOS6) known to be unstable?

[Lukas Slebodnik]

On (06/08/15 07:47), Torsten Harenberg wrote:
>Am 06.08.15 um 07:37 schrieb Torsten Harenberg:
>> (see plot attached 
>
>forgot the attachment
>
Is the high IO caused by sssd or by other aplication?

If it is casued by other application then you can mount
directory with sss cache (/var/lib/sss or just the /var/lib/sss/db)
to the different device/disk or filesystem.
You can use tmpfs if you do not care about offline 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] Error while Enrolling Client

[Lukas Slebodnik]

On (11/08/15 20:53), Jakub Hrozek wrote:
>On Tue, Aug 11, 2015 at 09:29:46PM +0530, Yogesh Sharma wrote:
>> Yes Jakub...That was the issue. We have fixed it and update to List.
>> 
>> Thanks Jakub.
>> 
>> Would like to have one suggestion.
>> 
>> We have implemented sudo, but every time we need to restart sssd to take
>> the changes. We have try implementing the cache timeout also, but not
>> working as expected.
>> 
>> Any other config changes required?
>
>No, this is not expected. Can you get logs after you've added the sudo
>rule but before the client is restarted in order to capture the issue?
>It would be best to add debug_level=7 to sudo, nss and domain sections.
>
I thought it is an side effect of sudo rule caching mechanism
and periodic tasks. So it might be an expected behaviour.

Periodic task are fired few seconds after start of sssd.
It might explain why restarting sssd works.

@see more details in man sssd-sudo -> "THE SUDO RULE CACHING MECHANISM"

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] Having problem with pwd_expiration

[Lukas Slebodnik]

On (13/08/15 15:39), Dewangga Bachrul Alam wrote:
>Hello!
>
>I've been discovered something about pwd_expiration on freeipa 4.1.4,
>I got a line from sssd_DOMAIN.log :
>
>... snip ...
>(Thu Aug 13 12:25:39 2015) [sssd[be[mydomain.co.id]]]
>[confdb_get_domain_internal] (0x1000): pwd_expiration_warning is -1
>... snip ...
>
>$ ipa pwpolicy-find
>  Group: global_policy
>  Max lifetime (days): 90
>  Min lifetime (hours): 1
>  History size: 0
>  Character classes: 0
>  Min length: 8
>  Max failures: 6
>  Failure reset interval: 60
>  Lockout duration: 600
>
>The password policy should be available on next 90 days after I creating
>the password, isn't it? But I tried to login, the password was expired.
>
>$ sudo su -
>[sudo] password for subhan:
>Password expired. Change your password now.
>sudo: Account or password is expired, reset your password and try again
>Current Password:
>New password:
>Retype new password:
>sudo: pam_chauthtok: Authentication token manipulation error
>
>Every time I reset the password from ipa server, the password always
>expired before 90 days (based on global_policy).
>
If you reset password from web UI (or command line)
then the user need to change that password.
It's by design. The administrator should not know your password.

However,
situation is different if the password was changed with command line utility
"passwd".

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 v4 on CentOS6

[Lukas Slebodnik]

On (17/08/15 14:37), Alexander Bokovoy wrote:
>On Mon, 17 Aug 2015, Ramy Allam wrote:
>>Hello,
>>
>>I'm running ipa-server-4.1.0-18.el7.centos.4.x86_64 on a CentoOS 7 machine.
>>And need to setup ipa-4.1.0 on a CentOS 6 machine.
>>
>>CentOS 6 repo has ipa-client-3 available. Where can i find v4 for CentOS 6
>>please ?
>Nowhere. Read this thread:
>https://www.redhat.com/archives/freeipa-users/2014-February/msg00255.html
>
>>The reason i need to setup ipa-clientv4 on CentOS6 is clientv3 doesn't
>>support OTP authentication.
>Regardless of IPA version, the lack of OTP authentication will not be
>fixed with a backport of IPA4. OTP authentication needs newer Kerberos
>library with changed ABI so it will not appear on RHEL6/CentOS6.
>
>Ideally you need newer SSSD which understands newer Kerberos API for
>pre-auth conversations and may be even more. This is definitely going
>outside of any sensible support scope, upstream or downstream.
>
rhel6.7 already contains sufficient version of sssd
sssd-1.12.4-4x.el6

It just does not contain separate prompting for password and token.
https://fedorahosted.org/sssd/ticket/2335

I'm also not aware of dependency on special feature from libkrb5 on sssd side.
At least, we do not detect it at compile time.

SSSD is not a blocker for rhel6 client with ipa-server-4.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] User AD can not Login Client Linux

[Lukas Slebodnik]

On (23/08/15 17:53), alireza baghery wrote:
>Hi i install Centos 7.1 (IDM Server)
>and integrate with Windows SERVER 2008 R2 Trust
>USER AD can not Login on client (OLE 6.6) but User create idm can login
>
>name IDM SERVER= ipasrv.l.infotechpsp.net
>domain Windows = infotechpsp.net
>
>i execute [ kinit abagh...@infotechpsp.net] on IDM Server
>and klist and show keytab abagheri
>but execute kvno abag...@infotechpsp.net
>get ERROR kvno Server not found in kerberos database
>please help me and thank you
>
>KLIST
>
>
>Valid starting ExpiresService principal
>08/23/15 17:09:53  08/24/15 03:11:34  krbtgt/infotechpsp@infotechpsp.net
>renew until 08/24/15 17:09:53
>
>=
>
>Tail LOG /var/log/sssd/ssd_l.infotechpsp.net debug_level = 6
>=
>[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
>[(objectclass=*)][].
>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
>set
>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [sdap_kinit_send]
>(0x0400): Attempting kinit (default, host/ussd7.l.infotechpsp.net,
>L.INFOTECHPSP.NET, 86400)
>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA'
>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [resolve_srv_send]
>(0x0200): The status of SRV lookup is resolved
>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>[be_resolve_server_process] (0x0200): Found address for server
>ipasrv.l.infotechpsp.net: [10.30.160.19] TTL 1200
>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>[set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child
>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>[write_pipe_handler] (0x0400): All data has been sent!
>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>[read_pipe_handler] (0x0400): EOF received, client finished
>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>[sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/
>ccache_L.INFOTECHPSP.NET], expired on [1440420165]
>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>[sdap_cli_auth_step] (0x0100): expire timeout is 900
>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [sasl_bind_send]
>(0x0100): Executing sasl bind mech: GSSAPI, user: host/
>ussd7.l.infotechpsp.net
>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>[child_sig_handler] (0x0100): child [13370] finished successfully.
>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>[fo_set_port_status] (0x0100): Marking port 389 of server '
>ipasrv.l.infotechpsp.net' as 'working'
>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>[set_server_common_status] (0x0100): Marking server '
>ipasrv.l.infotechpsp.net' as 'working'
>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
>[objectclass=ipaNTTrustedDomain][cn=trusts,dc=l,dc=infotechpsp,dc=net].
>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [be_run_online_cb]
>(0x0080): Going online. Running callbacks.
>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
>set
>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
>[objectclass=ipaIDRange][cn=ranges,cn=etc,dc=l,dc=infotechpsp,dc=net].
>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
>set
>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
>[objectclass=ipaNTDomainAttrs][cn=ad,cn=etc,dc=l,dc=infotechpsp,dc=net].
>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
>set
>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>[get_subdomains_callback] (0x0400): Backend returned: (0, 0, )
>[Success]
>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>[be_get_account_info] (0x0100): Got request for [4097][1][name=abagheri]
>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>[ipa_s2n_exop_send] (0x0400): Executing extended operation
>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>[ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Operations
>error(1), (null)
There seems to be a problem on server side.
It's is a very likely bug in sssd on FreeIPA server.

Some AD related fixes are included in latest update in el7.1
(1.12.2-58.el7_1.14)

If it does not help please try to upgrade to the latest upstream version
of sssd[1]. I hope it will help otherwise we will need to see log files
from IPA server.

LS

[1] https://copr.fedoraprojec

Re: [Freeipa-users] ipa-client on aws (amazon linux)

[Lukas Slebodnik]

On (02/09/15 11:22), Prashant Bapat wrote:
>Hi,
>
>Running a freeipa-client on Amazon Linux is a huge challenge. This is
>because the client depends on SSSD which in turn uses Samba libraries which
>Amazon Linux does not support.
sssd >= 1.11 can be compiled without samba libraries.
But result is missing ad and ipa provider.
So you would need to manually configure sssd with ldap provider against
FreeIPA.

>I tried this sometime back and gave up.
>Instead we went with pam-nss-ldap route which works great with compat ldap
>schema. Run the "ipa-advise" command for more details.
>
>I'm running the pam-nss-ldap client on 2000+ servers in AWS with Amazon
>Linux.
>
ipa-client install has option "--no-sssd"
-S, --no-sssd   Do not configure the client to use SSSD for
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] User AD can not Login Client Linux

[Lukas Slebodnik]

On (28/08/15 08:44), Lukas Slebodnik wrote:
>On (23/08/15 17:53), alireza baghery wrote:
>>Hi i install Centos 7.1 (IDM Server)
>>and integrate with Windows SERVER 2008 R2 Trust
>>USER AD can not Login on client (OLE 6.6) but User create idm can login
>>
>>name IDM SERVER= ipasrv.l.infotechpsp.net
>>domain Windows = infotechpsp.net
>>
>>i execute [ kinit abagh...@infotechpsp.net] on IDM Server
>>and klist and show keytab abagheri
>>but execute kvno abag...@infotechpsp.net
>>get ERROR kvno Server not found in kerberos database
>>please help me and thank you
>>
>>KLIST
>>
>>
>>Valid starting ExpiresService principal
>>08/23/15 17:09:53  08/24/15 03:11:34  krbtgt/infotechpsp@infotechpsp.net
>>renew until 08/24/15 17:09:53
>>
>>=
>>
>>Tail LOG /var/log/sssd/ssd_l.infotechpsp.net debug_level = 6
>>=
>>[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
>>[(objectclass=*)][].
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
>>set
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [sdap_kinit_send]
>>(0x0400): Attempting kinit (default, host/ussd7.l.infotechpsp.net,
>>L.INFOTECHPSP.NET, 86400)
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>>[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA'
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [resolve_srv_send]
>>(0x0200): The status of SRV lookup is resolved
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>>[be_resolve_server_process] (0x0200): Found address for server
>>ipasrv.l.infotechpsp.net: [10.30.160.19] TTL 1200
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>>[set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>>[write_pipe_handler] (0x0400): All data has been sent!
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>>[read_pipe_handler] (0x0400): EOF received, client finished
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/
>>ccache_L.INFOTECHPSP.NET], expired on [1440420165]
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_cli_auth_step] (0x0100): expire timeout is 900
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [sasl_bind_send]
>>(0x0100): Executing sasl bind mech: GSSAPI, user: host/
>>ussd7.l.infotechpsp.net
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[child_sig_handler] (0x0100): child [13370] finished successfully.
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[fo_set_port_status] (0x0100): Marking port 389 of server '
>>ipasrv.l.infotechpsp.net' as 'working'
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[set_server_common_status] (0x0100): Marking server '
>>ipasrv.l.infotechpsp.net' as 'working'
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
>>[objectclass=ipaNTTrustedDomain][cn=trusts,dc=l,dc=infotechpsp,dc=net].
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [be_run_online_cb]
>>(0x0080): Going online. Running callbacks.
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
>>set
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
>>[objectclass=ipaIDRange][cn=ranges,cn=etc,dc=l,dc=infotechpsp,dc=net].
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
>>set
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
>>[objectclass=ipaNTDomainAttrs][cn=ad,cn=etc,dc=l,dc=infotechpsp,dc=net].
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
>>set
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[get_subdomains_callback] (0x0400): Backend returned: (0, 0, )
>>[Success]
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[be_get_accou

Re: [Freeipa-users] FreeIPA Sudo Error: Resource temporarily unavailable

[Lukas Slebodnik]

On (01/09/15 18:18), Yogesh Sharma wrote:
>Hi,
>
>This is fixed. On digging more found that my resolv.conf was updated and it
>was not able to find the domain. Fixing the resolv.conf with right
>nameserver, fixed the issue.
>
I know it was solved but you would not miss important debug
message with lover debug level.

>>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_issue_request] (0x0400):
>>> Issuing request for [0x40bc10:3:vg4...@klikpay.int]
>>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_get_account_msg]
>>> (0x0400): Creating request for [klikpay.int][3][1][name=vg4381]
>>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_internal_get_send]
>>> (0x0400): Entering request [0x40bc10:3:vg4...@klikpay.int]
>>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_check_user_dp_callback]
>>> (0x0020): Unable to get information from Data Provider
>>> Error: 1, 11, Offline
sssd was in offine mode because it was not able to connect to IPA 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] ipa-client on aws (amazon linux)

[Lukas Slebodnik]

On (02/09/15 12:58), Prashant Bapat wrote:
>Lukas,
>
>ipa-client-install is part of the freeipa-client rpm. On Amazon Linux this
>rpm cannot be installed. This is the basic issue.
>
Indeed.
there is a strict requires for sssd

Requires: sssd >= 1.12.3  #from fedora spec file

Using ipa-advise might be more comfortable way rather then
patch spec file or create modified rpms.

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] 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] 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] 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] 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] 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] 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] 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 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 (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
>(Th

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 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 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 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] 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] 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] 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] sssd shows deleted users as well

[Lukas Slebodnik]

On (22/07/16 13:25), Rakesh Rajasekharan wrote:
>Hi,
>
>I am running freeipa version 4.2.0 and sssd version 1.13.0
>
>I have set "enumerate=True" to show IPA users as well in getent passwd.
>
>However, the getent passwd continues to show users that have got deleted as
>well.
>
>Heres my sssd config file
>[domain/xyz.com]
>enumerate = TRUE
>krb5_auth_timeout = 30
>
>cache_credentials = True
>krb5_store_password_if_offline = True
>ipa_domain = xyz.com
>id_provider = ipa
>auth_provider = ipa
>access_provider = ipa
>ldap_tls_cacert = /etc/ipa/ca.crt
>ipa_hostname = 10.16.11.134
>chpass_provider = ipa
>ipa_server = _srv_, ipa-master-int.xyz.com
>dns_discovery_domain = xyz.com
>[sssd]
>services = nss, sudo, pam, ssh
>config_file_version = 2
>
>domains = xyz.com
>[nss]
>homedir_substring = /home
>
>[pam]
>
>[sudo]
>
>[autofs]
>
>[ssh]
>
>[pac]
>
>[ifp]
>
>Is this an expected behaviour or am i missing something in my config
>
When user is removed from IPA then it is not automatically removed from sssd.
SSSD has few levels of caches which are indirectly used by "getent passwd".
The user or group will be removed after next look-up in IPA which
is usually after extpiration of entry in sssd cache.

Another way how to force removing entries from sssd cache is
to authenticate with user. SSSD fetch latest data from LDAP/IPA
with each authentication for security reasons.

You can also invalidate user in sssd cache "sss_cache -u someuser"
and SSSD will detect removed user in IPA after attempt to refresh data
in sssd 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] 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] 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] 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] 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] 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] 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 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] 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] 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] 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] 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] 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] 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] 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] 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] 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 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] 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] 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] 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] sssd.conf - the server and host-client relationship

[Lukas Slebodnik]

On (20/09/16 15:06), Lachlan Musicman wrote:
>Hola,
>
>What is the relationship between the IPA server, host-clients and the
>sssd.conf?
>
>>From what I can tell, sssd.conf is edited/changed by the ipa-client-install
>process on the host-client.
>
>What level of similarity does there need to be between the two sssd.confs?
>
>My server's sssd.conf has a significant number of extra parameters set that
>are not getting put onto the clients.
>
>Debug levels are the most obvious, and understandable, omissions - but some
>others are frustrating.
>
>The (non debug_level) parameters missing are:
>--
>[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

>selinux_provider = none
It was probably set as a workaround of bug which have been already
fixed.

>ipa_server_mode = True
that's specific option for sssd 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

>
>[sssd]
>config_file_version = 2
>domains = unixdev.etc
>
>[nss]
>memcache_timeout = 600
This option is se by ipa-*-install on ipa server mode.

>--
>
>The other diff is that the
>
>host has: ipa_server = vmdv-linuxidm1.unixdev.petermac.org.au
>client has: ipa_server = _srv_, vmdv-linuxidm1.unixdev.petermac.org.au
>
>Which I presume is expected/desired.
>
>And the reason I ask is because we have selinux disabled, and without the
Do you eman disabled or permissive?
BTW freeIPA works well with SELinux in enforcing mode
>"selinux_provider = none" line, we would get kicked out as soon as freeipa
>had logged us in with message:
>
disabled SELinux should not affected authentication; but I didn't test that.

>Connection to test_client.unixdev.petermac.org.au closed by remote host.
>
>and on that host-client there was a brand new selinux_child.log that I'd
>never seen before.
>

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  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] sss / nsswitch

[Lukas Slebodnik]

On (13/09/16 16:18), Rob Verduijn wrote:
>2016-09-13 15:07 GMT+02:00 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
>>
>
>
>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