Re: [Freeipa-users] Users directory Browsing -

[Prashant Bapat]

A user will be able to list all other users and be able to read their
attributes. But will not be able to change anything.

Is that an issue ? I mean on a Linux box you can read /etc/passwd file
which has info about all users on that box. This doesn't cause issues.

On 8 March 2016 at 03:03, Matt Wells  wrote:

> Hi all, I had a quick question.  I swear I had this before but that could
> be the voices telling me it's true
> A normal user is logging into IPA (4.2.0) and filling in their phone
> number and info no problem.  However when that user clicks on accounts
> above they are then able to peruse the entire directory and all the other
> user accounts.
> I'm trying to remove that but for the life of me can't recall the ACI or
> where that may be.
>
> I really appreciate it, I'll continue to search through the previous
> questions and if I find it before a reply will mark this closed with the
> link.
> Thank you all -
> Wells
>
> --
> 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] Users directory Browsing -

[Matt Wells]

Hi all, I had a quick question.  I swear I had this before but that could
be the voices telling me it's true
A normal user is logging into IPA (4.2.0) and filling in their phone number
and info no problem.  However when that user clicks on accounts above they
are then able to peruse the entire directory and all the other user
accounts.
I'm trying to remove that but for the life of me can't recall the ACI or
where that may be.

I really appreciate it, I'll continue to search through the previous
questions and if I find it before a reply will mark this closed with the
link.
Thank you all -
Wells
-- 
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-getcert and SELinux

[Rob Crittenden]

Thomas Raehalme wrote:
> Hi!
> 
> I have setup certificates for Puppet as described here:
> http://www.freeipa.org/page/Using_IPA's_CA_for_Puppet
> 
> Unfortunately SELinux is giving me hard time when invoking "ipa-getcert
> request" to generate the private/public key for the Puppet agent
> (permission denied when trying to write the key pair to
> /var/lib/puppet/ssl). 
> 
> Disabling SELinux temporarily solves the issue, but the same problem
> reappears when renewing the certificate (ipa-getcert reports status
> NEED_CERTSAVE_PERMS for the request). 
> 
> What would be the proper way to enable the necessary permissions on SELinux?

There is probably no rule that allows certmonger to read/write/etc in
/var/lib/puppet/ssl.

The short-term fix would be to use audit2allow to generate the rule:

# setenforce permissive
# getcert request ...
# ausearch -m AVC -ts recent | audit2allow -M puppet

# semodule -i puppet.pp
# setenforce enforcing
# getcert resubmit ...

It may be preferable to label the /var/lib/puppet/ssl/* directories as
certmonger_var_lib_t but I don't know what would do to puppet. You could
trade one problem for another. A BZ against selinux might be warranted
to see what they think.

Note that the first route would give certmonger access to anything
labeled as var_lib_t which might not be so nice.

And you'd probably want to resubmit with SELinux in permissive to see if
any additional perms are needed, like unlink perhaps.

rob

-- 
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] ipa-getcert and SELinux

[Thomas Raehalme]

Hi!

I have setup certificates for Puppet as described here:
http://www.freeipa.org/page/Using_IPA's_CA_for_Puppet

Unfortunately SELinux is giving me hard time when invoking "ipa-getcert
request" to generate the private/public key for the Puppet agent
(permission denied when trying to write the key pair to
/var/lib/puppet/ssl).

Disabling SELinux temporarily solves the issue, but the same problem
reappears when renewing the certificate (ipa-getcert reports status
NEED_CERTSAVE_PERMS for the request).

What would be the proper way to enable the necessary permissions on SELinux?

Best regards,
Thomas
-- 
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 does not fetch Sudo Rules anymore

[Alexander Bokovoy]

On Mon, 07 Mar 2016, Zoske, Fabian wrote:

Hi,

I looked in the sudo_debug log and found the following line:
Mar  7 11:00:08 sudo[31293] <- new_logline @ ./logging.c:867 := user NOT authorized 
on host ; TTY=pts/1 ; PWD=/home//f.zoske ; USER=root ; COMMAND=/bin/bash

On our IPA-Server I have following rules:

HBAC:
Name: allow_all_admins
Who: Group: admins
Accessing: Any Host
Via Service: Any Service

SUDO:
Name: allow_all_all
Who: Group: admins
Access this host: Any Host
Run Commands: Any Command
As Whom: Anyone

In our setup I have AD-Trust established to a multi domain forest and in our 
sssd.conf I had to adjust the UPN via the following lines (suggested by Jakub):
subdomain_inherit = ldap_user_principal
ldap_user_principal = nosuchattr

Is anything of this related to the problem?
Shall I send you the log files of sssd and sudo?

Off-list, please.

--
/ 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] user certificate ldap EXTERNAL authentication

[Sumit Bose]

On Mon, Mar 07, 2016 at 09:58:20AM +0100, Natxo Asenjo wrote:
> On Mon, Mar 7, 2016 at 9:14 AM, Martin Kosek  wrote:
> 
> > On 03/05/2016 06:00 AM, Rob Crittenden wrote:
> > > Natxo Asenjo wrote:
> > >>
> > >> By the way, revoking the certificate does not block applications using
> > >> it from ldap.
> > >>
> > >> I can still access the ldap server using this cert/key pair *after*
> > >> revoking the certificate using ipa cert-revoke . In order to
> > >> block it I need to remove the seeAlso value of the user account, or the
> > >> certificate attribute.
> > >>
> > >> I do not know if this is a security issue, but maybe worthwhile
> > >> documenting just in case.
> > >
> > > SSL/TLS servers don't automatically check for cert revocation. You need
> > > to add the CRL to the 389-ds NSS database periodically. I don't know for
> > > sure but I don't think 389-ds can use OCSP to validate incoming client
> > > certs. There is an IPA ticket in the backlog to investigate this for the
> > > web and ldap servers: https://fedorahosted.org/freeipa/ticket/3542
> > >
> > > And yeah, as you discovered, managing the value of CmapLdapAttr is a
> > > poor man's revocation.
> >
> > I saved Natxo's contributed article here:
> >
> > http://www.freeipa.org/page/Howto/Client_Certificate_Authentication_with_LDAP
> > for now.
> >
> 
> 
> Thanks!
> 
> 
> > My take on this is that it probably works, but I am curious actually what
> > problem you are solving. Are you interested only in allowing Certificate
> > authentication with FreeIPA LDAP or rather in allowing certificate
> > authentication in your application, whatever are the means?
> >
> 
> both :-). Having name/password combinations in application settings is less
> desirable than having certificate/key paths. I know both accomplish the
> same thing (authenticate to the directory), but having certificates is less
> controversial (no need for third parties to know *that* password that is
> probably being used somewhere else as well, for instance. Having a simple
> way to 'revoke' the access is nice as well.
> 
> 
> 
> > If this is the case, would leveraging SSSD Smart Card/certificate
> > authentication help? At minimum, it can lookup users by certificate:
> >
> > https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate
> >
> > With leveraging SSSD, you should be able to avoid manual user mapping in

Yes, but as you can see on the page SSSD currently requires that the whole
certificate is stored in the IPA user entry. But if your applications a
web-based mod_lookup_identity might be what you are looking for
http://www.adelton.com/apache/mod_lookup_identity/ .

> > FreeIPA LDAP. I am not sure though how the revocation would work. CCing
> > Sumit
> > on this one

SSSD itself can use OCSP or CRLs added to the systems NSS database
/etc/pki/nss when the authentication is run through SSSD which means
that SSSD must have access to the Smartcard. For other applications like
e.g. apache revocation must be configured in the application becasue
currently SSSD only checks if a certificate is valid during
authentication but not when the user is looked up by a certificate
because this check might delay the user lookup considerable.
Additionally e.g. in the apache use case the user lookup only happens
after the whole TLS/SSL handshake is finished and authentication is
successful but authentication should only be successful if the
certificate is valid.

bye,
Sumit

> 
> 
> Interesting, I did not know about this possibility of sssd. I need to read
> it through, it might address our needs. Thanks for pointing me to it.
> 
> What in my opinion would be really interesting would be to have something
> similar to the submission port on smtp servers. A different instance of the
> directory where only some kind of authentication are possible.
> 
> Right now when using port 389 I can choose between a combination of SASL
> mechanisms, and if in dse.ldif anonymous auth and minssf are modified, then
> I can force the usage of secure protocols. What I would like is to have a
> way to disable password authentication mechanisms on a ldap port, while
> keeping it enabled on the other. So we could close one port to the outside
> world, and keep it open on the LAN, for instance.
> 
> Is this even possible?
> 
> --
> Groeten,
> natxo

> -- 
> 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] SSSD does not fetch Sudo Rules anymore

[Zoske, Fabian]

Hi,

I looked in the sudo_debug log and found the following line:
Mar  7 11:00:08 sudo[31293] <- new_logline @ ./logging.c:867 := user NOT 
authorized on host ; TTY=pts/1 ; PWD=/home//f.zoske ; USER=root ; 
COMMAND=/bin/bash

On our IPA-Server I have following rules:

HBAC:
Name: allow_all_admins
Who: Group: admins
Accessing: Any Host
Via Service: Any Service

SUDO:
Name: allow_all_all
Who: Group: admins
Access this host: Any Host
Run Commands: Any Command
As Whom: Anyone

In our setup I have AD-Trust established to a multi domain forest and in our 
sssd.conf I had to adjust the UPN via the following lines (suggested by Jakub):
subdomain_inherit = ldap_user_principal 
ldap_user_principal = nosuchattr

Is anything of this related to the problem?
Shall I send you the log files of sssd and sudo?

Best regards,
Fabian


-Ursprüngliche Nachricht-
Von: Alexander Bokovoy [mailto:aboko...@redhat.com] 
Gesendet: Montag, 7. März 2016 09:55
An: Zoske, Fabian
Cc: freeipa-users@redhat.com
Betreff: Re: [Freeipa-users] SSSD does not fetch Sudo Rules anymore

On Mon, 07 Mar 2016, Zoske, Fabian wrote:
>Thank you for your explanation.
>
>I looked in the sssd_.log and found the actual LDAP-Filter.
>The problem seems to be the first part again: 
>(&(objectclass=sudoRole)(entryUSN>=485025)(!(entryUSN=485025))).
>In the LDAP-Tree I can't see any attribute named entryUSN.
>
>Is this related to the problem?
No, it is not. entryUSN is an attribute that is not stored in the entry, it is 
a feature that adds a monotonically increased value to any update of an entry. 
It is used to check whether entries were changed since last search.


--
/ 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] user certificate ldap EXTERNAL authentication

[Natxo Asenjo]

On Mon, Mar 7, 2016 at 9:14 AM, Martin Kosek  wrote:

> On 03/05/2016 06:00 AM, Rob Crittenden wrote:
> > Natxo Asenjo wrote:
> >>
> >> By the way, revoking the certificate does not block applications using
> >> it from ldap.
> >>
> >> I can still access the ldap server using this cert/key pair *after*
> >> revoking the certificate using ipa cert-revoke . In order to
> >> block it I need to remove the seeAlso value of the user account, or the
> >> certificate attribute.
> >>
> >> I do not know if this is a security issue, but maybe worthwhile
> >> documenting just in case.
> >
> > SSL/TLS servers don't automatically check for cert revocation. You need
> > to add the CRL to the 389-ds NSS database periodically. I don't know for
> > sure but I don't think 389-ds can use OCSP to validate incoming client
> > certs. There is an IPA ticket in the backlog to investigate this for the
> > web and ldap servers: https://fedorahosted.org/freeipa/ticket/3542
> >
> > And yeah, as you discovered, managing the value of CmapLdapAttr is a
> > poor man's revocation.
>
> I saved Natxo's contributed article here:
>
> http://www.freeipa.org/page/Howto/Client_Certificate_Authentication_with_LDAP
> for now.
>


Thanks!


> My take on this is that it probably works, but I am curious actually what
> problem you are solving. Are you interested only in allowing Certificate
> authentication with FreeIPA LDAP or rather in allowing certificate
> authentication in your application, whatever are the means?
>

both :-). Having name/password combinations in application settings is less
desirable than having certificate/key paths. I know both accomplish the
same thing (authenticate to the directory), but having certificates is less
controversial (no need for third parties to know *that* password that is
probably being used somewhere else as well, for instance. Having a simple
way to 'revoke' the access is nice as well.



> If this is the case, would leveraging SSSD Smart Card/certificate
> authentication help? At minimum, it can lookup users by certificate:
>
> https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate
>
> With leveraging SSSD, you should be able to avoid manual user mapping in
> FreeIPA LDAP. I am not sure though how the revocation would work. CCing
> Sumit
> on this one


Interesting, I did not know about this possibility of sssd. I need to read
it through, it might address our needs. Thanks for pointing me to it.

What in my opinion would be really interesting would be to have something
similar to the submission port on smtp servers. A different instance of the
directory where only some kind of authentication are possible.

Right now when using port 389 I can choose between a combination of SASL
mechanisms, and if in dse.ldif anonymous auth and minssf are modified, then
I can force the usage of secure protocols. What I would like is to have a
way to disable password authentication mechanisms on a ldap port, while
keeping it enabled on the other. So we could close one port to the outside
world, and keep it open on the LAN, for instance.

Is this even possible?

--
Groeten,
natxo
-- 
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 does not fetch Sudo Rules anymore

[Alexander Bokovoy]

On Mon, 07 Mar 2016, Zoske, Fabian wrote:

Thank you for your explanation.

I looked in the sssd_.log and found the actual LDAP-Filter.
The problem seems to be the first part again: 
(&(objectclass=sudoRole)(entryUSN>=485025)(!(entryUSN=485025))).
In the LDAP-Tree I can't see any attribute named entryUSN.

Is this related to the problem?

No, it is not. entryUSN is an attribute that is not stored in the entry,
it is a feature that adds a monotonically increased value to any update
of an entry. It is used to check whether entries were changed since last
search.


--
/ 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] SSSD does not fetch Sudo Rules anymore

[Zoske, Fabian]

Thank you for your explanation.

I looked in the sssd_.log and found the actual LDAP-Filter.
The problem seems to be the first part again: 
(&(objectclass=sudoRole)(entryUSN>=485025)(!(entryUSN=485025))).
In the LDAP-Tree I can't see any attribute named entryUSN.

Is this related to the problem?

Best regards,
Fabian

-Ursprüngliche Nachricht-
Von: Alexander Bokovoy [mailto:aboko...@redhat.com] 
Gesendet: Montag, 7. März 2016 09:07
An: Zoske, Fabian
Cc: freeipa-users@redhat.com
Betreff: Re: [Freeipa-users] SSSD does not fetch Sudo Rules anymore

On Mon, 07 Mar 2016, Zoske, Fabian wrote:
>Hi,
>
>in our environment server (ipa-server-4.2.0-15.el7_2.6.x86_64 and
>sssd-1.13.0-40.el7_2.1.x86_64  on CentOS 7.2) and client
>(ipa-client-4.2.0-15.el7_2.6.x86_64 and sssd-1.13.0-40.el7_2.1.x86_64 
>on CentOS 7.2) SUDO rules doesn’t get fetched anymore.
>
>I debugged SSSD and SUDO and found out, that the first LDAP filter is
>(objectClass=sudoRule) and in our IPA-LDAP every rule has the class 
>“sudoRole” not “sudoRule”.
This has nothing to do with your problem. sudoRole is a known artefact from 
SUDO LDAP support -- the schema SUDO uses to store data in LDAP has this object 
class. SSSD searches in its own cache first and in that cache it uses an object 
class named sudoRule.

These are searches against different databases and they are perfectly fine.

>Is there a way to fix this behavior?
You need to find out what exactly is failing in your case, the 'difference' 
above is not a problem.

See https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

--
/ 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] user certificate ldap EXTERNAL authentication

[Martin Kosek]

On 03/05/2016 06:00 AM, Rob Crittenden wrote:
> Natxo Asenjo wrote:
>>
>> By the way, revoking the certificate does not block applications using
>> it from ldap.
>>
>> I can still access the ldap server using this cert/key pair *after*
>> revoking the certificate using ipa cert-revoke . In order to
>> block it I need to remove the seeAlso value of the user account, or the
>> certificate attribute.
>>
>> I do not know if this is a security issue, but maybe worthwhile
>> documenting just in case.
> 
> SSL/TLS servers don't automatically check for cert revocation. You need
> to add the CRL to the 389-ds NSS database periodically. I don't know for
> sure but I don't think 389-ds can use OCSP to validate incoming client
> certs. There is an IPA ticket in the backlog to investigate this for the
> web and ldap servers: https://fedorahosted.org/freeipa/ticket/3542
> 
> And yeah, as you discovered, managing the value of CmapLdapAttr is a
> poor man's revocation.

I saved Natxo's contributed article here:
http://www.freeipa.org/page/Howto/Client_Certificate_Authentication_with_LDAP
for now.

My take on this is that it probably works, but I am curious actually what
problem you are solving. Are you interested only in allowing Certificate
authentication with FreeIPA LDAP or rather in allowing certificate
authentication in your application, whatever are the means?

If this is the case, would leveraging SSSD Smart Card/certificate
authentication help? At minimum, it can lookup users by certificate:

https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate

With leveraging SSSD, you should be able to avoid manual user mapping in
FreeIPA LDAP. I am not sure though how the revocation would work. CCing Sumit
on this one.

Martin

-- 
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 does not fetch Sudo Rules anymore

[Alexander Bokovoy]

On Mon, 07 Mar 2016, Zoske, Fabian wrote:

Hi,

in our environment server (ipa-server-4.2.0-15.el7_2.6.x86_64 and
sssd-1.13.0-40.el7_2.1.x86_64  on CentOS 7.2) and client
(ipa-client-4.2.0-15.el7_2.6.x86_64 and sssd-1.13.0-40.el7_2.1.x86_64
on CentOS 7.2) SUDO rules doesn’t get fetched anymore.

I debugged SSSD and SUDO and found out, that the first LDAP filter is
(objectClass=sudoRule) and in our IPA-LDAP every rule has the class
“sudoRole” not “sudoRule”.

This has nothing to do with your problem. sudoRole is a known artefact
from SUDO LDAP support -- the schema SUDO uses to store data in LDAP has
this object class. SSSD searches in its own cache first and in that
cache it uses an object class named sudoRule.

These are searches against different databases and they are perfectly
fine.


Is there a way to fix this behavior?

You need to find out what exactly is failing in your case, the
'difference' above is not a problem.

See https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

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