Re: [Freeipa-users] password resets - errors

[Janelle]

On 9/28/15 11:33 AM, Rob Crittenden wrote:

Simo Sorce wrote:

On 27/09/15 09:21, Janelle wrote:

Hello,

I continue to see these a lot, but only on some servers. It causes a lot
of confusions with my users. There must be a way to troubleshoot this
and find the issue. Also, there is nothing wrong with the password
policies. They are all set to default, and this occurs even when a
user's password has expired.  The only thing I can say is it tends to
happen on more heavily loaded servers than lightly loaded ones. And
perhaps the most important point - the password *IS* changed
successfully!

Changing password for user expired-user.
Current Password:
New password:
Retype new password:
Password change failed. Server message: Current password's minimum life
has not expired

Password not changed.
passwd: Authentication token manipulation error

Thoughts? Anything?

This may be due to an implementation issue in the client.
libkrb5 tends to wait only 1 second for an operation to succeed/fail and
will send a new (identical) message if it gets back no answer, this is
due to the fact historically KRB5 has used UDP in preference which
doesn't guarantee message delivery, so the only option is to retry.

However if the first message actually went through and the only problem
is that the server was busy and slower a second message will be received
and processed just the same, only to find out the password has just been
changed and can't be changed again, hence the error message.

I guess one way to handle this would be to disable clients from using
UDP completely, although I am not 100% certain this will avoid the
problem, IIRC at least in some versions the client library would retry
after 1 second even on TCP.

Simo.



udp_preference_limit 0 was added to /etc/krb5.conf in 4.2 to prefer TCP
for the initial request anyway. According to the man page it will always
fall back to UDP upon failure.

rob

This value appears to be set in 4.1.x as well, at least it is on my 
configurations.


Policy is set:
 Group: global_policy
  Max lifetime (days): 90
  Min lifetime (hours): 1

and this is true for ALL users.

I will try disabling UDP completely.
~J

--
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 with third-party wildcard certificate

[Brian Mathis]

No.  FreeIPA requires a *CA* certificate, which is a cert that has the
ability to sign other certs.  Unless you're in a large company with an
expensive agreement in place with GoDaddy, that is not a permission they
grant to regular certs.  A wildcard cert is only allowed to be used on
simple things like a web site, and does not have the ability to sign other
certs.


~ Brian Mathis
@orev


On Tue, Sep 29, 2015 at 5:35 AM, Srdjan Dutina  wrote:

> Hi!
>
> I'm testing FreeIPA 4.1.0 on Centos 7 (1503).
> I have a *wildcard *certificate for my domain issued by GoDaddy.
> Could I use it with FreeIPA primary and replica servers instead of
> self-signed certificate?
> If yes, how could I replace the self-signed certificate in existing two
> servers installation?
>
> Thank you.
>
> Srdjan.
>
> --
> 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

Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo

[Pavel Březina]

On 09/21/2015 10:42 PM, Andy Thompson wrote:

On Mon, Sep 21, 2015 at 07:39:01PM +, Andy Thompson wrote:

-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Monday, September 21, 2015 3:29 PM
To: Andy Thompson 
Cc: freeipa-users@redhat.com; pbrez...@redhat.com
Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo

On Mon, Sep 21, 2015 at 02:22:54PM +, Andy Thompson wrote:


On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson wrote:

I've narrowed it down a bit doing some testing.  The sudo
rules work when

I remove the user group restriction from them.  My sudo rules
all have my ad groups in the rule


   Rule name: ad_linux_admins
   Enabled: TRUE
   Host category: all
   Command category: all
   RunAs User category: all
   RunAs Group category: all
   User Groups: ad_linux_admins  <- if I remove this then the
rule gets

applied

Nice catch. Is the group visible after you login and run id?

What is the exact IPA server version?


Ok I also figured out if I rename my AD groups to match my IPA
groups then

the sudo rules are applied.


I tested a couple things though, if I put a rule in the local
sudoers file on a server running sssd 1.11

%@   "sudo commands"

That rule was not applied.  If I remove the  then the
rule got

applied.


On a server running sssd 1.12 that rule works, but does not work
if I

remove the .  And none of the IPA sudo rules work.  So
something changed with the domain suffix between versions it would
appear.


They key to making the IPA sudo rules work in 1.12 is to remove
the

default_domain_suffix setting in the sssd.conf, but that's not an
option in my environment.


So all the moving parts together, it appears that having AD groups
with a different name than the IPA groups in conjunction with the
default_domain_suffix setting breaks things right now in 1.12.
Appears since I renamed the ad group to match then the rule
without a domain suffix will get matched now


Hello Andy,

I'm sorry for the constant delays, but I was busy with some
trust-related fixes lately.

Did you have a chance to confirm that just swapping sssd /on the
client/ while keeping the same version on the server fixes the issue for

you?


Pavel (CC), can you help me out here, please? I have the setup ready
on my machine, so tomorrow we can take a look and experiment (I can
give you access to my environment via tmate maybe..), but I wasn't
able to reproduce the issue locally yet.


It's fine I understand the backlog.

I was not able to backrev the sssd due to dependency issues.  I tried

downgrading all the dependencies and got in a loop and stopped trying.  Are
there any tricks you can think of to downgrade the sssd cleanly?


-andy



What failures are you getting? I normally just download all \*sss\* packages
and then downgrade with rpm -U --oldpackage.



I'm just trying to use yum.  If I yum downgrade sssd I get a ton of deps.  If 
include all the deps it lists

yum downgrade sssd sssd-proxy sssd-ipa sssd-common-pac sssd-krb5 
sssd-krb5-common sssd-ldap sssd-ad libipa_hbac libipa_hbac-python 
python-sssdconfig

I get multilib errors with libsss_idmap.

Looks like my local repo doesn't have libsss_idmap 1.11 available.  Let me look 
into that and see what repo it sits in and see if I can figure out why it's not 
pulling in.

-andy



Hi, since none of us is able to reproduce this in house, can you give us 
more precise steps how to reproduce and more information? What I have in 
mind at this moment is:


1) How is membership defined? I suspect it goes as AD-USER -> AD-GROUP 
-> IPA->GROUP, right? What types of groups are used?


2) sssd.conf might also turn out to be useful

3) Remove SSSD and sudo logs, reproduce and send us all the logs please 
with the commands to reproduce. Not just snippets.


Do you have any test machine we can ssh to?

Thank you!

--
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] FreeIPA with third-party wildcard certificate

[Srdjan Dutina]

Hi!

I'm testing FreeIPA 4.1.0 on Centos 7 (1503).
I have a *wildcard *certificate for my domain issued by GoDaddy.
Could I use it with FreeIPA primary and replica servers instead of
self-signed certificate?
If yes, how could I replace the self-signed certificate in existing two
servers installation?

Thank you.

Srdjan.
-- 
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 options/sss_cache

[Pavel Březina]

On 09/25/2015 01:12 PM, Jakub Hrozek wrote:

On Fri, Sep 25, 2015 at 11:48:27AM +0200, Pavel Březina wrote:

On 09/25/2015 10:06 AM, Jakub Hrozek wrote:

On Thu, Sep 24, 2015 at 03:39:48PM +0200, Christoph Kaminski wrote:

Hi

I have 3 problems/questions with ipa and sudo...

1. How to make a GLOBAL sudo rule with all the options what I want to
have? (e.g. !authenticate). I have tried to make a sudo rule for all users
on all hosts whom all users but without command and it doesnt work... Do I
need to set it for each rule separately?


Pavel (CC) would know this better, in native sudo there is a global
entry but I keep forgetting what it is in IPA..


Hi, please, create a rule named "defaults".

I see this question is returning frequently. I think it should be supported
directly by user interface.


+1 care to file a ticket?

..and a good candidate for the troubleshooting guide in the works :-)



Hi, I filed a ticket:
https://fedorahosted.org/freeipa/ticket/5332

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

[Pavel Březina]

On 09/15/2015 09:10 AM, Molnár Domokos wrote:


"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
 > doma's 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
 >

[Freeipa-users] NFS Automount Domain Homedirs

[Sadettin Albasan]

I have a freeipa server and a trust relation with AD domain with almost
everything working the way I planned except automounting NFS home
directories for domain users. I have been reading about this on the net for
almost a week, ended up trying a lot of different configurations, but I had
no success to it. The closest I came to was removing krb5 authentication
from the export and mount options. it is only then able to mount the
directories. Since I have not seen any official guidelines  about it, is
this in works or any plan to implement? Thanks.
-- 
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 with third-party wildcard certificate

[Rob Crittenden]

Brian Mathis wrote:
> No.  FreeIPA requires a *CA* certificate, which is a cert that has the
> ability to sign other certs.  Unless you're in a large company with an
> expensive agreement in place with GoDaddy, that is not a permission they
> grant to regular certs.  A wildcard cert is only allowed to be used on
> simple things like a web site, and does not have the ability to sign
> other certs.

You can replace the web and/or LDAP certificates with a 3rd party cert,
see http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP

There be dragons (and countless corner cases).

rob

> 
> 
> ~ Brian Mathis
> @orev
> 
> 
> On Tue, Sep 29, 2015 at 5:35 AM, Srdjan Dutina  > wrote:
> 
> Hi!
> 
> I'm testing FreeIPA 4.1.0 on Centos 7 (1503).
> I have a *wildcard *certificate for my domain issued by GoDaddy.
> Could I use it with FreeIPA primary and replica servers instead of
> self-signed certificate?
> If yes, how could I replace the self-signed certificate in existing
> two servers installation?
> 
> Thank you.
> 
> Srdjan.
> 
> --
> 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

Re: [Freeipa-users] NFS Automount Domain Homedirs

[Alexander Bokovoy]

On Tue, 29 Sep 2015, Sadettin Albasan wrote:

I have a freeipa server and a trust relation with AD domain with almost
everything working the way I planned except automounting NFS home
directories for domain users. I have been reading about this on the net for
almost a week, ended up trying a lot of different configurations, but I had
no success to it. The closest I came to was removing krb5 authentication
from the export and mount options. it is only then able to mount the
directories. Since I have not seen any official guidelines  about it, is
this in works or any plan to implement? Thanks.

As usual, more details are required about server and client
configuration/software in order to even guess your problems.

What provides NFS storage? What is used on the client machines? How
identity mapping is configured. Give examples of your configuration.

There are some issues in NFS identity mapping code that were fixed
relatively recently and which prevented use of POSIX users with '@' in
the name, for example.

--
/ 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] HBAC

[Alexander Bokovoy]

On Tue, 29 Sep 2015, TomK wrote:

Hey Guy's,

(Sending this again as I didn't have this email included in the 
freeipa-users mailing list so not sure if the other message will get 
posted.)


Before I post a ticket to RH Support for an RFE, I'll post the request 
here to get some feedback on options and what ideas folks have.  I've 
a situation as follows.  I have the following setup in WS 2012 AD DC:


TomK (user)
TomK Groups:
   unixg
   windowsg

unixg has the 'host' attribute defined 'lab01,lab02,lab03,lab04'
windowsg has the 'host' attribute defined 'lab06,lab07,lab08,lab09'

TomK(user) also has the 'host' attribute defined as per the proper RFC 
for LDAP.  With SSSD rules I can define the rules to read the user 
'host' attribute but not the group 'host' attribute:



|access_provider = ldap ldap_access_order = host 
ldap_user_authorized_host = host|



Essentially TomK to be given access to hosts listed in the 'host' 
attribute but denied entry into lab05 for example (not listed in any 
group 'host' attribute above) to the server.   If I have a new user 
that has joined that particular team at our organization, I can simply 
add her/him to the above groups and this user would get access only to 
the listed servers in 'host' attribute by default. I don't need to 
specify new groups in customized sssd.conf or ldap.conf files or in 
sshd config files.  Hence less to update with Salt or any other CM 
suite.  I've managed to setup SUDO rules and with the 
openssh-ldap.diff schema SSH public keys could be stored in AD as well 
and be read by OpenSSH.  So aside from the HBAC capability on groups, 
virtually all our needs are handled by the WS2012 AD DC as it has to 
follow the OpenLDAP standard anyway.  Now to get this we considered 
and are still considering FreeIPA.  However this idea poses a set of 
challenges:


1) In large organizations where the AD support department are only 
trained in Windows AD setup and configuration (Only windows guy's) 
this would require a minimal of 3 bodies to support that know 
LDAP/Linux.  This is a large cost.


2) The additional server requires the same hardening as the Windows AD 
DC servers meaning a new procedure has to be carved out for the 2+ 
FreeIPA servers to be supported, hardened and maintained (upgraded).


Now I probably sound somewhat anti-FreeIPA, however the challenges of 
implementing it in large organizations surface after some 
deliberation, so probably better to list then as it may help direct 
development of the product to contend with the challenges (Like having 
a document fully dedicated to hardening a FreeIPA server with selinux 
and other technologies in easy to maintain configuration).   I could 
be mistaken but some folks mention that it's 'better' to implement 
this sort of HBAC through other means (?? iptables ??) but never tried 
the alternatives yet.


So, cutting to the end, would it be possible to add an attribute like:

|ldap_user_authorized_host|

but perhaps called 'ldap_group_authorized_host' to the SSSD code to 
enable reading the 'host' attribute on AD/LDAP defined groups?

In FreeIPA we support HBAC rules for AD users and groups. What exactly
is wrong with that?

See 'ipa help trust' for details how to map AD groups to IPA groups and
then 'ipa help hbacrule' for how to limit access of those groups to
specific hosts and services on them.

This is all covered well in the guide:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html

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

[Freeipa-users] HBAC

[TomK]

Hey Guy's,

(Sending this again as I didn't have this email included in the 
freeipa-users mailing list so not sure if the other message will get 
posted.)


Before I post a ticket to RH Support for an RFE, I'll post the request 
here to get some feedback on options and what ideas folks have.  I've a 
situation as follows.  I have the following setup in WS 2012 AD DC:


TomK (user)
TomK Groups:
unixg
windowsg

unixg has the 'host' attribute defined 'lab01,lab02,lab03,lab04'
windowsg has the 'host' attribute defined 'lab06,lab07,lab08,lab09'

TomK(user) also has the 'host' attribute defined as per the proper RFC 
for LDAP.  With SSSD rules I can define the rules to read the user 
'host' attribute but not the group 'host' attribute:



|access_provider = ldap ldap_access_order = host 
ldap_user_authorized_host = host|



Essentially TomK to be given access to hosts listed in the 'host' 
attribute but denied entry into lab05 for example (not listed in any 
group 'host' attribute above) to the server.   If I have a new user that 
has joined that particular team at our organization, I can simply add 
her/him to the above groups and this user would get access only to the 
listed servers in 'host' attribute by default. I don't need to specify 
new groups in customized sssd.conf or ldap.conf files or in sshd config 
files.  Hence less to update with Salt or any other CM suite.  I've 
managed to setup SUDO rules and with the openssh-ldap.diff schema SSH 
public keys could be stored in AD as well and be read by OpenSSH.  So 
aside from the HBAC capability on groups, virtually all our needs are 
handled by the WS2012 AD DC as it has to follow the OpenLDAP standard 
anyway.  Now to get this we considered and are still considering 
FreeIPA.  However this idea poses a set of challenges:


1) In large organizations where the AD support department are only 
trained in Windows AD setup and configuration (Only windows guy's) this 
would require a minimal of 3 bodies to support that know LDAP/Linux.  
This is a large cost.


2) The additional server requires the same hardening as the Windows AD 
DC servers meaning a new procedure has to be carved out for the 2+ 
FreeIPA servers to be supported, hardened and maintained (upgraded).


Now I probably sound somewhat anti-FreeIPA, however the challenges of 
implementing it in large organizations surface after some deliberation, 
so probably better to list then as it may help direct development of the 
product to contend with the challenges (Like having a document fully 
dedicated to hardening a FreeIPA server with selinux and other 
technologies in easy to maintain configuration).   I could be mistaken 
but some folks mention that it's 'better' to implement this sort of HBAC 
through other means (?? iptables ??) but never tried the alternatives yet.


So, cutting to the end, would it be possible to add an attribute like:

|ldap_user_authorized_host|

but perhaps called 'ldap_group_authorized_host' to the SSSD code to 
enable reading the 'host' attribute on AD/LDAP defined groups?


Cheers,
Tom



-- 
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] Antwort: Re: sudo options/sss_cache

[Christoph Kaminski]

oh thx! it would be really nice to have it...

Greetz
Christoph Kaminski

Pavel Březina  schrieb am 29.09.2015 13:48:14:

> 
> Hi, I filed a ticket:
> https://fedorahosted.org/freeipa/ticket/5332


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