Re: [Freeipa-users] Sudo entry not found by sssd in the cache db

2015-09-15 Thread Jakub Hrozek 
On Tue, Sep 15, 2015 at 07:25:17AM +0200, Molnár Domokos wrote:
> On 09/14/2015 03:08 PM, Pavel Březina wrote:
> >On 09/11/2015 02:40 PM, Molnár Domokos wrote:
> 
> >>Full log attached.
> >>"Molnár Domokos"  írta:
> >>
> >>
> >>"Pavel Březina"  írta:
> >>
> >>On 09/09/2015 09:31 PM, Molnár Domokos wrote:
> >> > I have a working IPA server and a working client config on an 
> >> OpenSuse
> >> > 13.2 with the following versions:
> >> > nappali:~ # rpm -qa |grep sssd
> >> > sssd-tools-1.12.2-3.4.1.i586
> >> > sssd-krb5-1.12.2-3.4.1.i586
> >> > python-sssd-config-1.12.2-3.4.1.i586
> >> > sssd-ipa-1.12.2-3.4.1.i586
> >> > sssd-1.12.2-3.4.1.i586
> >> > sssd-dbus-1.12.2-3.4.1.i586
> >> > sssd-krb5-common-1.12.2-3.4.1.i586
> >> > sssd-ldap-1.12.2-3.4.1.i586
> >> > sssd is confihured for nss, pam, sudo
> >> > There is a test sudo rule defined in the ipa server, which 
> >> applies to
> >> > user "doma".  However when the user tries to use sudo the rule 
> >> does not
> >> > work.
> >> > doma@nappali:/home/doma> sudo ls
> >> > domas password:
> >> > doma is not allowed to run sudo on nappali.  This incident will 
> >> be reported.
> >> > The corresponding log in the sssd_sudo.log is this:
> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] 
> >> (0x0200):
> >> > Received client version [1].
> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] 
> >> (0x0200):
> >> > Offered version [1].
> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
> >> [sss_parse_name_for_domains]
> >> > (0x0200): name doma matched without domain, user is 
> >> doma
> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
> >> [sss_parse_name_for_domains]
> >> > (0x0200): name doma matched without domain, user is 
> >> doma
> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
> >> [sudosrv_cmd_parse_query_done]
> >> > (0x0200): Requesting default options for [doma] from []
> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] 
> >> (0x0200):
> >> > Requesting info about [doma@szilva]
> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
> >> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb 
> >> with
> >> > 
> >> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
> >> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb 
> >> with
> >> > [(&(objectClass=sudoRule)(|(name=defaults)))]
> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
> >> [sss_parse_name_for_domains]
> >> > (0x0200): name doma matched without domain, user is 
> >> doma
> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
> >> [sss_parse_name_for_domains]
> >> > (0x0200): name doma matched without domain, user is 
> >> doma
> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
> >> [sudosrv_cmd_parse_query_done]
> >> > (0x0200): Requesting rules for [doma] from []
> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] 
> >> (0x0200):
> >> > Requesting info about [doma@szilva]
> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
> >> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb 
> >> with
> >> > 
> >> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
> >> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb 
> >> with
> >> > 
> >> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]
> >> > (Wed Sep  9 21:25:30 2015) [sssd[sudo]] [client_recv] (0x0200): 
> >> Client
> >> > disconnected!
> >> > This seems perfectly OK with one exception. The query against 
> >> the sysdb
> >> > does not find the entry. This is strange because the entry is 
> >> there.
> >> > Log in sssd.log:
> >> > (Wed Sep  2 08:52:13 2015) [sssd] [sysdb_domain_init_internal] 
> >> (0x0200):
> >> > DB File for szilva: /var/lib/sss/db/cache_szilva.ldb
> >> > So we know that the sysdb is /var/lib/sss/db/cache_szilva.ldb
> >> > Running the exact same query seen above in the sssd_sudo.log 
> >> against the
> >> > db returns:
> >> > ldbsearch -H /var/lib/sss/db/cache_szilva.ldb
> >> > 
> >>

Re: [Freeipa-users] vsftpd PAM setup problem

2015-09-15 Thread Jakub Hrozek 
On Mon, Sep 14, 2015 at 08:04:09PM -0400, j...@use.startmail.com wrote:
> > Is there anything for /var/log/secure for vsftpd ? I would look for
> > messages from pam_sss.so
> 
> Sep 14 19:50:11 fds vsftpd[27097]: pam_unix(vsftpd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ftp ruser=admin rhost=::1  user=admin
> (END)
> 
> Nothing from pam_sss.so
> 
> Found a temporary workaround - turn off selinux, pam_sss now shows up in log 
> files and admin login succeeds.
> Seems like problem is not related to freeipa itself.

Posting the AVC might be helpful here -- chances are just some files are
mislabaled.

I tried a quick:
# getsebool -a | grep ftp
but didn't find anything relevant that would need toggling to make
non-unix auth working.

-- 
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] AD Trust Issues

2015-09-15 Thread Martin Kosek 
Rough FreeIPA 4.2.1 equivalent should be in RHEL-7.2 - Beta is already out:

https://www.redhat.com/en/about/blog/red-hat-enterprise-linux-72-beta-now-available

On 09/14/2015 04:13 PM, Matt Wells wrote:
> Is the fix in CentOS or RHEL yet?
> 
> On Fri, Sep 11, 2015 at 1:34 PM, Alexander Bokovoy 
> wrote:
> 
>> On Fri, 11 Sep 2015, Matt Wells wrote:
>>
>>> I've been working on an AD trust with our freeipa servers but have run
>>> into
>>> some of the same issues others have had.
>>> It's well documented here however I feel I've mitigated these -
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1219832
>>>
>>> Freeipa Servers are Fedora 22 / freeipa-server-4.2.0
>>> The Samba version i'm on is well past the patched version.  It seems the
>>> patch is in samba-4.2.1-7.fc22 and I'm on samba-4.2.3-0 (assuming the
>>> patch
>>> is in this version).
>>>
>>> I run
>>> # echo Password123 | ipa trust-add --type=ad ad.example.com
>>> --trust-secret
>>> ipa: ERROR: CIFS server configuration does not allow access to
>>> \\pipe\lsarpc
>>>
>> This was looking like a partial fix. The full fix is in Fedora 23 with
>> FreeIPA 4.2.1 release (we didn't yet officially announced it).
>>
>> We were all busy at FreeIPA/SSSD gathering in Brno this week so there
>> wasn't really time to do Fedora 22 backport of the fixes yet.
>>
>> --
>> / Alexander Bokovoy
>>
> 
> 
> 
> 
> 

-- 
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 entry not found by sssd in the cache db

2015-09-15 Thread Molnár Domokos 
 
"Molnár Domokos"  írta:
>On 09/14/2015 03:08 PM, Pavel Březina wrote:

>>On 09/11/2015 02:40 PM, Molnár Domokos wrote:

>>>Full log attached.
>>>"Molnár Domokos"  írta:
>>>
>>>
>>>"Pavel Březina"  írta:
>>>
>>>On 09/09/2015 09:31 PM, Molnár Domokos wrote:
>>> > I have a working IPA server and a working client config on an 
>>> OpenSuse
>>> > 13.2 with the following versions:
>>> > nappali:~ # rpm -qa |grep sssd
>>> > sssd-tools-1.12.2-3.4.1.i586
>>> > sssd-krb5-1.12.2-3.4.1.i586
>>> > python-sssd-config-1.12.2-3.4.1.i586
>>> > sssd-ipa-1.12.2-3.4.1.i586
>>> > sssd-1.12.2-3.4.1.i586
>>> > sssd-dbus-1.12.2-3.4.1.i586
>>> > sssd-krb5-common-1.12.2-3.4.1.i586
>>> > sssd-ldap-1.12.2-3.4.1.i586
>>> > sssd is confihured for nss, pam, sudo
>>> > There is a test sudo rule defined in the ipa server, which 
>>> applies to
>>> > user "doma".  However when the user tries to use sudo the rule 
>>> does not
>>> > work.
>>> > doma@nappali:/home/doma> sudo ls
>>> > domas password:
>>> > doma is not allowed to run sudo on nappali.  This incident will 
>>> be reported.
>>> > The corresponding log in the sssd_sudo.log is this:
>>> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] 
>>> (0x0200):
>>> > Received client version [1].
>>> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] 
>>> (0x0200):
>>> > Offered version [1].
>>> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
>>> [sss_parse_name_for_domains]
>>> > (0x0200): name doma matched without domain, user is doma
>>> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
>>> [sss_parse_name_for_domains]
>>> > (0x0200): name doma matched without domain, user is doma
>>> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
>>> [sudosrv_cmd_parse_query_done]
>>> > (0x0200): Requesting default options for [doma] from []
>>> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] 
>>> (0x0200):
>>> > Requesting info about [doma@szilva]
>>> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>>> > 
>>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
>>> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>>> > [(&(objectClass=sudoRule)(|(name=defaults)))]
>>> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
>>> [sss_parse_name_for_domains]
>>> > (0x0200): name doma matched without domain, user is doma
>>> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
>>> [sss_parse_name_for_domains]
>>> > (0x0200): name doma matched without domain, user is doma
>>> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
>>> [sudosrv_cmd_parse_query_done]
>>> > (0x0200): Requesting rules for [doma] from []
>>> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] 
>>> (0x0200):
>>> > Requesting info about [doma@szilva]
>>> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>>> > 
>>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
>>> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>>> > 
>>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]
>>> > (Wed Sep  9 21:25:30 2015) [sssd[sudo]] [client_recv] (0x0200): 
>>> Client
>>> > disconnected!
>>> > This seems perfectly OK with one exception. The query against the 
>>> sysdb
>>> > does not find the entry. This is strange because the entry is 
>>> there.
>>> > Log in sssd.log:
>>> > (Wed Sep  2 08:52:13 2015) [sssd] [sysdb_domain_init_internal] 
>>> (0x0200):
>>> > DB File for szilva: /var/lib/sss/db/cache_szilva.ldb
>>> > So we know that the sysdb is /var/lib/sss/db/cache_szilva.ldb
>>> > Running the exact same query seen above in the sssd_sudo.log 
>>> against the
>>> > db returns:
>>> > ldbsearch -H /var/lib/sss/db/cache_szilva.ldb
>>> > 
>>> "(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))"
>>> >

Re: [Freeipa-users] Sudo entry not found by sssd in the cache db

2015-09-15 Thread Jakub Hrozek 
On Tue, Sep 15, 2015 at 09:13:09AM +0200, Molnár Domokos wrote:
>  
> Jakub Hrozek  írta:
> >On Tue, Sep 15, 2015 at 07:25:17AM +0200, Molnár Domokos wrote:
> >> On 09/14/2015 03:08 PM, Pavel Březina wrote:
> >> >On 09/11/2015 02:40 PM, Molnár Domokos wrote:
> >> 
> >> >>Full log attached.
> >> >>"Molnár Domokos"  írta:
> >> >>
> >> >>
> >> >>"Pavel Březina"  írta:
> >> >>
> >> >>On 09/09/2015 09:31 PM, Molnár Domokos wrote:
> >> >> > I have a working IPA server and a working client config on an 
> >> >> OpenSuse
> >> >> > 13.2 with the following versions:
> >> >> > nappali:~ # rpm -qa |grep sssd
> >> >> > sssd-tools-1.12.2-3.4.1.i586
> >> >> > sssd-krb5-1.12.2-3.4.1.i586
> >> >> > python-sssd-config-1.12.2-3.4.1.i586
> >> >> > sssd-ipa-1.12.2-3.4.1.i586
> >> >> > sssd-1.12.2-3.4.1.i586
> >> >> > sssd-dbus-1.12.2-3.4.1.i586
> >> >> > sssd-krb5-common-1.12.2-3.4.1.i586
> >> >> > sssd-ldap-1.12.2-3.4.1.i586
> >> >> > sssd is confihured for nss, pam, sudo
> >> >> > There is a test sudo rule defined in the ipa server, which 
> >> >> applies to
> >> >> > user "doma".  However when the user tries to use sudo the 
> >> >> rule does not
> >> >> > work.
> >> >> > doma@nappali:/home/doma> sudo ls
> >> >> > domas password:
> >> >> > doma is not allowed to run sudo on nappali.  This incident 
> >> >> will be reported.
> >> >> > The corresponding log in the sssd_sudo.log is this:
> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] 
> >> >> (0x0200):
> >> >> > Received client version [1].
> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] 
> >> >> (0x0200):
> >> >> > Offered version [1].
> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
> >> >> [sss_parse_name_for_domains]
> >> >> > (0x0200): name doma matched without domain, user is 
> >> >> doma
> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
> >> >> [sss_parse_name_for_domains]
> >> >> > (0x0200): name doma matched without domain, user is 
> >> >> doma
> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
> >> >> [sudosrv_cmd_parse_query_done]
> >> >> > (0x0200): Requesting default options for [doma] from []
> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] 
> >> >> (0x0200):
> >> >> > Requesting info about [doma@szilva]
> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
> >> >> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb 
> >> >> with
> >> >> > 
> >> >> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
> >> >> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb 
> >> >> with
> >> >> > [(&(objectClass=sudoRule)(|(name=defaults)))]
> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
> >> >> [sss_parse_name_for_domains]
> >> >> > (0x0200): name doma matched without domain, user is 
> >> >> doma
> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
> >> >> [sss_parse_name_for_domains]
> >> >> > (0x0200): name doma matched without domain, user is 
> >> >> doma
> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
> >> >> [sudosrv_cmd_parse_query_done]
> >> >> > (0x0200): Requesting rules for [doma] from []
> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] 
> >> >> (0x0200):
> >> >> > Requesting info about [doma@szilva]
> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
> >> >> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb 
> >> >> with
> >> >> > 
> >> >> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
> >> >> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb 
> >> >> with
> >> >> > 
> >> >> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]
> >> >> > (Wed Sep  9 21:25:30 2015) [sssd[sudo]] [client_recv] 
> >> >> (0x0200): Client
> >> >> > disconnected!
> >> >> > This seems perfectly OK with one exception. The query against 
> >> >> the sysdb
> >> >> > does not find the entry. This is strange because the entry is 
> >> >> there.
> >> >> > Log in sssd.log:
> >> >> > (Wed Sep  2 08:52:13 2015) [sssd] 
> >>

Re: [Freeipa-users] ipa-client-install --request-cert fails

2015-09-15 Thread Jan Pazdziora 
On Mon, Sep 14, 2015 at 09:59:40AM +0200, Jan Pazdziora wrote:
> On Sat, Sep 12, 2015 at 03:14:35PM +0200, Natxo Asenjo wrote:
> > On Sat, Sep 12, 2015 at 12:18 PM, Natxo Asenjo 
> > wrote:
> > 
> > > on a a centos 7.1 host when enrolling it with (among other) the switch
> > > --request-cert it does not create a host certificate for it. The host is
> > > properly joined but not certificate is present.
> > >
> > > In the ipaclient-install.log file I see this:
> > >
> > > 2015-09-12T09:34:02Z ERROR certmonger request for host certificate failed
> > 
> > it's not working when joining a centos 6.7 realm either, same error.
> 
> Also reproduced on RHEL 7.1 and RHEL 7.2 (to be). I've filed
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1262718
> 
> now.
> 
> Thank you for bringing this to our attention.

It turns out it's wrong labeling if the /etc/ipa/nssdb directory that
the certificate should get stored in:

https://bugzilla.redhat.com/show_bug.cgi?id=1262718#c7

Giving it cert_t should help this particular issue but we need to
investigate if it has the potential to break something else.

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

-- 
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 entry not found by sssd in the cache db

2015-09-15 Thread Molnár Domokos 
 
Jakub Hrozek  írta:
>On Tue, Sep 15, 2015 at 09:13:09AM +0200, Molnár Domokos wrote:
>>  
>> Jakub Hrozek  írta:
>> >On Tue, Sep 15, 2015 at 07:25:17AM +0200, Molnár Domokos wrote:
>> >> On 09/14/2015 03:08 PM, Pavel Březina wrote:
>> >> >On 09/11/2015 02:40 PM, Molnár Domokos wrote:
>> >> 
>> >> >>Full log attached.
>> >> >>"Molnár Domokos"  írta:
>> >> >>
>> >> >>
>> >> >>"Pavel Březina"  írta:
>> >> >>
>> >> >>On 09/09/2015 09:31 PM, Molnár Domokos wrote:
>> >> >> > I have a working IPA server and a working client config on 
>> >> >> an OpenSuse
>> >> >> > 13.2 with the following versions:
>> >> >> > nappali:~ # rpm -qa |grep sssd
>> >> >> > sssd-tools-1.12.2-3.4.1.i586
>> >> >> > sssd-krb5-1.12.2-3.4.1.i586
>> >> >> > python-sssd-config-1.12.2-3.4.1.i586
>> >> >> > sssd-ipa-1.12.2-3.4.1.i586
>> >> >> > sssd-1.12.2-3.4.1.i586
>> >> >> > sssd-dbus-1.12.2-3.4.1.i586
>> >> >> > sssd-krb5-common-1.12.2-3.4.1.i586
>> >> >> > sssd-ldap-1.12.2-3.4.1.i586
>> >> >> > sssd is confihured for nss, pam, sudo
>> >> >> > There is a test sudo rule defined in the ipa server, which 
>> >> >> applies to
>> >> >> > user "doma".  However when the user tries to use sudo the 
>> >> >> rule does not
>> >> >> > work.
>> >> >> > doma@nappali:/home/doma> sudo ls
>> >> >> > domas password:
>> >> >> > doma is not allowed to run sudo on nappali.  This incident 
>> >> >> will be reported.
>> >> >> > The corresponding log in the sssd_sudo.log is this:
>> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
>> >> >> [sss_cmd_get_version] (0x0200):
>> >> >> > Received client version [1].
>> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
>> >> >> [sss_cmd_get_version] (0x0200):
>> >> >> > Offered version [1].
>> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
>> >> >> [sss_parse_name_for_domains]
>> >> >> > (0x0200): name doma matched without domain, user 
>> >> >> is doma
>> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
>> >> >> [sss_parse_name_for_domains]
>> >> >> > (0x0200): name doma matched without domain, user 
>> >> >> is doma
>> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
>> >> >> [sudosrv_cmd_parse_query_done]
>> >> >> > (0x0200): Requesting default options for [doma] from []
>> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] 
>> >> >> (0x0200):
>> >> >> > Requesting info about [doma@szilva]
>> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>> >> >> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching 
>> >> >> sysdb with
>> >> >> > 
>> >> >> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
>> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>> >> >> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching 
>> >> >> sysdb with
>> >> >> > [(&(objectClass=sudoRule)(|(name=defaults)))]
>> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
>> >> >> [sss_parse_name_for_domains]
>> >> >> > (0x0200): name doma matched without domain, user 
>> >> >> is doma
>> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
>> >> >> [sss_parse_name_for_domains]
>> >> >> > (0x0200): name doma matched without domain, user 
>> >> >> is doma
>> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
>> >> >> [sudosrv_cmd_parse_query_done]
>> >> >> > (0x0200): Requesting rules for [doma] from []
>> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] 
>> >> >> (0x0200):
>> >> >> > Requesting info about [doma@szilva]
>> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>> >> >> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching 
>> >> >> sysdb with
>> >> >> > 
>> >> >> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
>> >> >> > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>> >> >> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching 
>> >> >> sysdb with
>> >> >> > 
>> >> >> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]
>> >> >> > (Wed Sep  9 21:25:30 2015) [sssd[sudo]] [client_recv] 
>> >> >> (0x0200): Client
>> >> >> > disconnected!
>> >> >> > This seems perfectly OK with one exception. The query 
>> >> >> against the sysdb
>> >> >> > does not find the entry. This is

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

2015-09-15 Thread Alexandre Ellert 
So, here is the recap :
I migrate a single IPA server Centos 6.6 to dual IP server Centos 7.1. The
PKI was only installed on server two.
Everything was working fine, replication OK, new enrollements OK,
authentication with Kerberos and LDAP OK.
After some time, I discover that pki tomcatd service didn't restart
automatically after reboot on server two.

Now I want to repair things, but I can't deploy a new PKI and I can't
delete the existing broken PKI...

Maybe I should use ipa-backup and then rebuilt an IPA infrastructure and
then ipa-restore ?

Please advice.


2015-09-07 13:36 GMT+02:00 Alexandre Ellert :

>
> > Le 4 sept. 2015 à 16:37, Martin Babinsky  a écrit :
> >
> > On 08/28/2015 05:46 PM, Alexandre Ellert wrote:
> >>
> >>> Le 28 août 2015 à 17:41, Alexander Bokovoy  a
> écrit :
> >>>
> >>> On Fri, 28 Aug 2015, Alexandre Ellert wrote:
> 
> > Le 28 août 2015 à 17:09, Alexander Bokovoy  a
> écrit :
> >
> > On Wed, 26 Aug 2015, Alexandre Ellert wrote:
> >>
> >>> Le 28 juil. 2015 à 05:59, Alexander Bokovoy 
> a écrit :
>  If the problem is too hard to solve, maybe I should try to deploy
> another
>  replica ?
> >>> You may try that. Sorry for not responding, I have some other
> tasks that
> >>> occupy my time right now.
> >>>
> >>
> >>
> >> Can you please tell me the procedure to decommission and re-create
> a new replica ?
> >> Are "ipa-server-install —uninstall" then "ipa-server-install" the
> only things to do ?
> > No, you need also to remove the server from the replication topology.
> >
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/removing-replica.html
> >
> > --
> > / Alexander Bokovoy
> 
>  I can’t remove the node on which I have problem with pki-tomcatd :
> 
>  # ipa-replica-manage del .example.com
>  Deleting a master is irreversible.
>  To reconnect to the remote master you will need to prepare a new
> replica file
>  and re-install.
>  Continue to delete? [no]: yes
>  Deleting this server is not allowed as it would leave your
> installation without a CA
> 
>  I seem that it’s the only node where CA is installed. What should I
> do now ?
> >>> Add a replica with CA using ipa-ca-install on existing replica.
> >>>
> >>> Read the guide, it has detailed coverage of these situations.
> >>> --
> >>> / Alexander Bokovoy
> >>
> >> On the first node (which is working and without pki-tomcatd service)
> >> # ipa-ca-install
> >> Directory Manager (existing master) password:
> >>
> >> CA is already installed.
> >>
> >> How is it possible ?
> >>
> >>
> > You must provide a replica file as an argument to ipa-ca-install if you
> want to setup CA on another replica.
> >
> > --
> > Martin^3 Babinsky
>
> I’m still stuck with the correct command line :
> [root@inf-ipa ~]# ipa-ca-install
> /var/lib/ipa/replica-info-inf-ipa.numeezy.fr.gpg
> Directory Manager (existing master) password:
>
> Run connection check to master
> Check connection from replica to remote master 'inf-ipa-2.numeezy.fr':
>Directory Service: Unsecure port (389): OK
>Directory Service: Secure port (636): OK
>Kerberos KDC: TCP (88): OK
>Kerberos Kpasswd: TCP (464): OK
>HTTP Server: Unsecure port (80): OK
>HTTP Server: Secure port (443): OK
>
> The following list of ports use UDP protocol and would need to be
> checked manually:
>Kerberos KDC: UDP (88): SKIPPED
>Kerberos Kpasswd: UDP (464): SKIPPED
>
> Connection from replica to master is OK.
> Start listening on required ports for remote master check
> Get credentials to log in to remote master
> ad...@numeezy.fr password:
>
> Check SSH connection to remote master
> Execute check on remote master
> Check connection from master to remote replica 'inf-ipa.numeezy.fr':
>Directory Service: Unsecure port (389): OK
>Directory Service: Secure port (636): OK
>Kerberos KDC: TCP (88): OK
>Kerberos KDC: UDP (88): WARNING
>Kerberos Kpasswd: TCP (464): OK
>Kerberos Kpasswd: UDP (464): WARNING
>HTTP Server: Unsecure port (80): OK
>HTTP Server: Secure port (443): OK
> The following UDP ports could not be verified as open: 88, 464
> This can happen if they are already bound to an application
> and ipa-replica-conncheck cannot attach own UDP responder.
>
> Connection from master to replica is OK.
>
> Connection check OK
> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30
> seconds
>   [1/21]: creating certificate server user
>   [2/21]: configuring certificate server instance
> ipa : CRITICAL failed to configure ca instance Command
> ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmp_KIouo'' returned non-zero
> exit status 1
>   [error] RuntimeError: Configuration of CA failed
>
> Your

[Freeipa-users] Partial replica

2015-09-15 Thread Nicola Canepa 

Hello list.
I'm trying to make a test deploy of FreeIPA, and I was wondering if it 
is possible to authenticate remote sites via LDAP by havong a partial 
replica based on saome filter (maybe a group, an attribute or similar).


Sorry if this is a silly question, but I am trying to explore the 
possibilities that I could have to slowly replace local authentications 
spread in various sites by having a central store (backed by FreeIPA) 
and many partial replicas which would contain what now I have in RADIUS 
or other authentication sources.


Thank you for any advice or pointer you can give to me.

Nicola

--

Nicola Canepa
canep...@mmfg.it
---
Il contenuto della presente comunicazione è riservato e destinato 
esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona 
diversa dal destinatario sono proibite la diffusione, la distribuzione e la 
copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e 
di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati 
contenuti. La presente comunicazione (comprensiva dei documenti allegati) non 
avrà valore di proposta contrattuale e/o accettazione di proposte provenienti 
dal destinatario, nè rinuncia o riconoscimento di diritti, debiti e/o crediti, 
nè sarà impegnativa, qualora non sia sottoscritto successivo accordo da chi può 
validamente obbligarci. Non deriverà alcuna responsabilità precontrattuale a 
ns. carico, se la presente non sia seguita da contratto sottoscritto dalle 
parti.

The content of the above communication is strictly confidential and reserved 
solely for the referred addressees. In the event of receipt by persons 
different from the addressee, copying, alteration and distribution are 
forbidden. If received by mistake we ask you to inform us and to destroy and/or 
delete from your computer without using the data herein contained. The present 
message (eventual annexes inclusive) shall not be considered a contractual 
proposal and/or acceptance of offer from the addressee, nor waiver recognizance 
of rights, debts  and/or credits, nor shall it be binding when not executed as 
a subsequent agreement by persons who could lawfully represent us. No 
pre-contractual liability shall apply to us when the present communication is 
not followed by any binding agreement between the parties.

--
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] add SubjectAltName (SAN) to IPA certificate

2015-09-15 Thread Brian J. Murrell 
On Sat, 2015-09-12 at 08:57 -0400, Brian J. Murrell wrote:
> Due to the bug in mod_nss that prevents SNI from functioning (i.e.
> limits a port to a single certificate) I need to add SANs
> (SubjectAltName) to the certificate that freeipa created for the
> webserver (Server-Cert) so that I can add more virtual hosts to the
> same Apache instance (yes, I know this is not advised but budgetary
> constraints are at play here).
> 
> How do I go about that?  Do I want to resubmit the certificate
> request
> with some -D alt.name1 -D alt.name2, etc. parameters as such:
> 
> # ipa-getcert resubmit -i  -D alt.name1 -D alt.name2
> 
> Is that the correct operation?  If so, is there anything more I need
> to
> do after that?

Nobody knows?  I would have thought that this would be one of the
easier routines in IPA certificate handling, no?

Cheers,
b.


signature.asc
Description: This is a digitally signed message part
-- 
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] add SubjectAltName (SAN) to IPA certificate

2015-09-15 Thread Brian J. Murrell 
On Tue, 2015-09-15 at 13:01 +0200, Martin Kosek wrote:
> BTW, there was related thread on freeipa-users in the past, with some
> links to
> related information:
> 
> https://www.redhat.com/archives/freeipa-users/2012-June/msg00216.html

So this writeup seems to ignore the fact that Apache and the
certificate store have already been established with mod_nss by the
time you are finished a FreeIPA installation and does nothing about
that in consideration of the fact that mod_nss and mod_ssl are mutually
exclusive (AFAIU) for a single port.

But yeah.  I did consider ditching mod_nss and replacing it with
mod_ssl but that seems like quite an extensive disruption to the
default FreeIPA Apache configuration.  In my experience, the further
you get out of the box with integration projects like FreeIPA, the more
fragile things are for future upgrading.

> I assume the only change since then is that FreeIPA now supports
> proper SAN
> extension.

Indeed, which seems to provide for a cleaner hack.  It leaves the
Apache configuration for FreeIPA intact and makes the future reversion,
when mod_nss properly supports SNI easier.

Cheers,
b.


signature.asc
Description: This is a digitally signed message part
-- 
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 entry not found by sssd in the cache db

2015-09-15 Thread Jakub Hrozek 
On Tue, Sep 15, 2015 at 01:58:07PM +0300, Alexander Bokovoy wrote:
> On Tue, 15 Sep 2015, Molnár Domokos wrote:
> >>#hostnamectl set-hostname nappali.silva
> >>on modern systems.
> >>
> >>>doma@nappali:/home/doma> hostname --fqdn
> >>>nappali.szilva
> >doma@nappali:/home/doma> su
> >Password:
> >nappali:/home/doma # hostnamectl set-hostname nappali.szilva
> >nappali:/home/doma # hostname
> >nappali.szilva
> >nappali:/home/doma # hostname --fqdn
> >nappali.szilvanappali:/home/doma # su doma
> >sh-4.2$ sudo ls
> >domas password:
> >20140921.ZIP
> >Oracle_VM_VirtualBox_Extension_Pack-4.3.26-98988.vbox-extpack
> >42646515_eb8d7dcabe416247463f1bc8652adced.pdf
> > Now it works, the rule is matched.Im not sure this is the
> > intended way especially seeing the fqdn mechanism in the sudo code
> > but Ill just keep it that way.Thank you.
> sudo doesn't do normalization and IPA's way of exposing host names is
> by using by default fqdn. So sudo compares local hostname with
> fqdn-based one, guess which way it will succeed?
> 
> You theoretically could have every hostname in IPA registered non-fqdn
> but what you cannot have is a mix between fqdn- and non-fqdn names.

You can have registered a different hostname with IPA than what
hostname(1) reports, we have an ipa_hostname parameter for that. But
there's no way for sudo to learn about it..

> -- 
> / Alexander Bokovoy

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

2015-09-15 Thread Steven Jones 
Hi,


I am in a similar boat, well RHEL6.7 to RHEL7.1.  I joined a RHEL7.1 / IPA4.1 
to the 6.7 / IPA3.0 --self-cert domain, got rid of all the 6.7's so I was 
ca-less.  Did a full backup on the RHEL7.1 / IPA 4.1.  Blew away the ipa 
server, installed fresh, pki-tomcat runs, did a restore and pki-tomcat doesnt 
run.


btw what does --data do?  I tried that before a full restore and no passwords 
worked ie i could not login and no users worked at all, so it seems pointless? 
or maybe rather what is it for? and when to use it?



regards

Steven


From: freeipa-users-boun...@redhat.com  on 
behalf of Alexandre Ellert 
Sent: Wednesday, 16 September 2015 12:09 a.m.
To: Martin Babinsky
Cc: freeipa-users@redhat.com; Alexander Bokovoy
Subject: Re: [Freeipa-users] Failed to start pki-tomcatd Service

So, here is the recap :
I migrate a single IPA server Centos 6.6 to dual IP server Centos 7.1. The PKI 
was only installed on server two.
Everything was working fine, replication OK, new enrollements OK, 
authentication with Kerberos and LDAP OK.
After some time, I discover that pki tomcatd service didn't restart 
automatically after reboot on server two.

Now I want to repair things, but I can't deploy a new PKI and I can't delete 
the existing broken PKI...

Maybe I should use ipa-backup and then rebuilt an IPA infrastructure and then 
ipa-restore ?

Please advice.


2015-09-07 13:36 GMT+02:00 Alexandre Ellert 
>:

> Le 4 sept. 2015 à 16:37, Martin Babinsky 
> > a écrit :
>
> On 08/28/2015 05:46 PM, Alexandre Ellert wrote:
>>
>>> Le 28 août 2015 à 17:41, Alexander Bokovoy 
>>> > a écrit :
>>>
>>> On Fri, 28 Aug 2015, Alexandre Ellert wrote:

> Le 28 août 2015 à 17:09, Alexander Bokovoy 
> > a écrit :
>
> On Wed, 26 Aug 2015, Alexandre Ellert wrote:
>>
>>> Le 28 juil. 2015 à 05:59, Alexander Bokovoy 
>>> > a écrit :
 If the problem is too hard to solve, maybe I should try to deploy 
 another
 replica ?
>>> You may try that. Sorry for not responding, I have some other tasks that
>>> occupy my time right now.
>>>
>>
>>
>> Can you please tell me the procedure to decommission and re-create a new 
>> replica ?
>> Are "ipa-server-install —uninstall" then "ipa-server-install" the only 
>> things to do ?
> No, you need also to remove the server from the replication topology.
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/removing-replica.html
>
> --
> / Alexander Bokovoy

 I can’t remove the node on which I have problem with pki-tomcatd :

 # ipa-replica-manage del .example.com
 Deleting a master is irreversible.
 To reconnect to the remote master you will need to prepare a new replica 
 file
 and re-install.
 Continue to delete? [no]: yes
 Deleting this server is not allowed as it would leave your installation 
 without a CA

 I seem that it’s the only node where CA is installed. What should I do now 
 ?
>>> Add a replica with CA using ipa-ca-install on existing replica.
>>>
>>> Read the guide, it has detailed coverage of these situations.
>>> --
>>> / Alexander Bokovoy
>>
>> On the first node (which is working and without pki-tomcatd service)
>> # ipa-ca-install
>> Directory Manager (existing master) password:
>>
>> CA is already installed.
>>
>> How is it possible ?
>>
>>
> You must provide a replica file as an argument to ipa-ca-install if you want 
> to setup CA on another replica.
>
> --
> Martin^3 Babinsky

I’m still stuck with the correct command line :
[root@inf-ipa ~]# ipa-ca-install 
/var/lib/ipa/replica-info-inf-ipa.numeezy.fr.gpg
Directory Manager (existing master) password:

Run connection check to master
Check connection from replica to remote master 
'inf-ipa-2.numeezy.fr':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
ad...@numeezy.fr password:

Check SSH connection to remote master
Execute check on remote master
Check connection from master to remote

Re: [Freeipa-users] Sudo entry not found by sssd in the cache db

2015-09-15 Thread Molnár Domokos 

On 09/15/2015 01:37 PM, Jakub Hrozek wrote:
>On Tue, Sep 15, 2015 at 01:58:07PM +0300, Alexander Bokovoy wrote:

>>On Tue, 15 Sep 2015, Molnár Domokos wrote:



#hostnamectl set-hostname nappali.silva on modern systems.

>doma@nappali:/home/doma> hostname --fqdn nappali.szilva



>>>doma@nappali:/home/doma> su Password: nappali:/home/doma # hostnamectl 
>>>set-hostname nappali.szilva nappali:/home/doma # hostname nappali.szilva 
>>>nappali:/home/doma # hostname --fqdn nappali.szilvanappali:/home/doma # su 
>>>doma sh-4.2$ sudo ls domas password: 20140921.ZIP 
>>>Oracle_VM_VirtualBox_Extension_Pack-4.3.26-98988.vbox-extpack 
>>>42646515_eb8d7dcabe416247463f1bc8652adced.pdf Now it works, the rule is 
>>>matched.Im not sure this is the intended way especially seeing the fqdn 
>>>mechanism in the sudo code but Ill just keep it that way.Thank you.

>>sudo doesnt do normalization and IPAs way of exposing host names is 
>>by using by default fqdn. So sudo compares local hostname with fqdn-based 
>>one, guess which way it will succeed? You theoretically could have every 
>>hostname in IPA registered non-fqdn but what you cannot have is a mix between 
>>fqdn- and non-fqdn names.

>You can have registered a different hostname with IPA than what hostname(1) 
>reports, we have an ipa_hostname parameter for that. But theres no way 
>for sudo to learn about it..
You may well be right but I still think this is a bug in sudo/sssd plugin. 
Heres why I think so:

@line  582 in sssd.c when calling hostname_matches it is a clear intention of 
the code that the hostname matching is done both against the fqdn and the naked 
hostname.

@lines 773-790 the implementation of hostname_matches(..) is done correctly. It 
guesses intelligently and chooses to match either against the fqdn or the naked 
hostname based on the format of the hostname provided by IPA. If there is a 
. in the IPA provided hostname name then the hostname compared to the 
fqdn otherwise it is compared to the bare hostname.

@line 805 in sudoers.c in set_fqdn the fqdn is correctly retrieved for the host 
during initialization - so sudo is indeed aware of both host name versions. I 
tested this part it it works OK.

The bug - I think - is that the information correctly retrieved during init 
through set_fqdn in sudoers.c somehow does not make its way to line 582 in 
sssd.c. There both user_shost and user_host seem to contain the naked hostname 
unless the bare hostaname contains the fqdn itself.

I do not have enough time to find out why this happens but the above evidence 
suggests that there is a bug somewhere in the process.
 -- 
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 entry not found by sssd in the cache db

2015-09-15 Thread Alexander Bokovoy 

On Tue, 15 Sep 2015, Molnár Domokos wrote:

#hostnamectl set-hostname nappali.silva
on modern systems.


doma@nappali:/home/doma> hostname --fqdn
nappali.szilva

doma@nappali:/home/doma> su
Password:
nappali:/home/doma # hostnamectl set-hostname nappali.szilva
nappali:/home/doma # hostname
nappali.szilva
nappali:/home/doma # hostname --fqdn
nappali.szilvanappali:/home/doma # su doma
sh-4.2$ sudo ls
domas password:
20140921.ZIP
Oracle_VM_VirtualBox_Extension_Pack-4.3.26-98988.vbox-extpack
42646515_eb8d7dcabe416247463f1bc8652adced.pdf
 Now it works, the rule is matched.Im not sure this is the
 intended way especially seeing the fqdn mechanism in the sudo code
 but Ill just keep it that way.Thank you.

sudo doesn't do normalization and IPA's way of exposing host names is
by using by default fqdn. So sudo compares local hostname with
fqdn-based one, guess which way it will succeed?

You theoretically could have every hostname in IPA registered non-fqdn
but what you cannot have is a mix between fqdn- and non-fqdn names.
--
/ Alexander Bokovoy

--
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] add SubjectAltName (SAN) to IPA certificate

2015-09-15 Thread Martin Kosek 
On 09/15/2015 12:35 PM, Brian J. Murrell wrote:
> On Sat, 2015-09-12 at 08:57 -0400, Brian J. Murrell wrote:
>> Due to the bug in mod_nss that prevents SNI from functioning (i.e.
>> limits a port to a single certificate) I need to add SANs
>> (SubjectAltName) to the certificate that freeipa created for the
>> webserver (Server-Cert) so that I can add more virtual hosts to the
>> same Apache instance (yes, I know this is not advised but budgetary
>> constraints are at play here).
>>
>> How do I go about that?  Do I want to resubmit the certificate
>> request
>> with some -D alt.name1 -D alt.name2, etc. parameters as such:
>>
>> # ipa-getcert resubmit -i  -D alt.name1 -D alt.name2
>>
>> Is that the correct operation?  If so, is there anything more I need
>> to
>> do after that?
> 
> Nobody knows?  I would have thought that this would be one of the
> easier routines in IPA certificate handling, no?

BTW, there was related thread on freeipa-users in the past, with some links to
related information:

https://www.redhat.com/archives/freeipa-users/2012-June/msg00216.html

I assume the only change since then is that FreeIPA now supports proper SAN
extension.

-- 
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 6.7 upgrade - sssd/sudo

2015-09-15 Thread Jakub Hrozek 
Sorry for not replying sooner, many of us were mostly offline last week.

I'll try to reproduce locally..

On Tue, Sep 15, 2015 at 12:24:45PM +, Andy Thompson wrote:
> I just updated several machines to RHEL 6.7 and seem to have broken my sudo 
> rules.  I've tracked the problem down to having
> 
> Default_domain_suffix = ad.domain
> 
> In the sssd.conf.  If I remove that I can login using the fqn from AD and 
> sudo rules are applied as configured.  However I don't want to force my users 
> to change to using their fqn to login, and due to having db2 in the 
> environment our usernames are limited to 8 characters so we cannot use the 
> fqn regardless.
> 
> I tested adding a local sudo rule for %ad_domain_group@ipa.domain and it 
> worked, but any IPA rules are not working.  A rule in the sudoers would not 
> work unless it was a fqn either which I expected with the default domain 
> suffix set.
> 
> Update installed sssd-1.12.4-47.el6.x86_64.  Redhat wants me to test 
> downgrading my sssd, which I'm not entirely opposed to in order to get things 
> working, but there are some fixes in this release I kinda want to keep.
> 
> -andy
> 
> 
> 
> *** This communication may contain privileged and/or confidential 
> information. It is intended solely for the use of the addressee. If you are 
> not the intended recipient, you are strictly prohibited from disclosing, 
> copying, distributing or using any of this information. If you received this 
> communication in error, please contact the sender immediately and destroy the 
> material in its entirety, whether electronic or hard copy. ***
> 
> 
> --
> 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
> 
> 
> *** This communication may contain privileged and/or confidential 
> information. It is intended solely for the use of the addressee. If you are 
> not the intended recipient, you are strictly prohibited from disclosing, 
> copying, distributing or using any of this information. If you received this 
> communication in error, please contact the sender immediately and destroy the 
> material in its entirety, whether electronic or hard copy. ***
> 
> 
> -- 
> 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

-- 
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] rhel 6.7 upgrade - sssd/sudo

2015-09-15 Thread Andy Thompson 
I just updated several machines to RHEL 6.7 and seem to have broken my sudo 
rules.  I've tracked the problem down to having

Default_domain_suffix = ad.domain

In the sssd.conf.  If I remove that I can login using the fqn from AD and sudo 
rules are applied as configured.  However I don't want to force my users to 
change to using their fqn to login, and due to having db2 in the environment 
our usernames are limited to 8 characters so we cannot use the fqn regardless.

I tested adding a local sudo rule for %ad_domain_group@ipa.domain and it 
worked, but any IPA rules are not working.  A rule in the sudoers would not 
work unless it was a fqn either which I expected with the default domain suffix 
set.

Update installed sssd-1.12.4-47.el6.x86_64.  Redhat wants me to test 
downgrading my sssd, which I'm not entirely opposed to in order to get things 
working, but there are some fixes in this release I kinda want to keep.

-andy



*** This communication may contain privileged and/or confidential information. 
It is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. ***


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


*** This communication may contain privileged and/or confidential information. 
It is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. ***


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