Re: [Freeipa-users] user certificate ldap EXTERNAL authentication

[Rob Crittenden]

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.

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

Re: [Freeipa-users] user certificate ldap EXTERNAL authentication

[Natxo Asenjo]

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.
-- 
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 Fri, Mar 4, 2016 at 11:00 PM, Simo Sorce  wrote:

> On Fri, 2016-03-04 at 14:34 -0500, Rob Crittenden wrote:
> > Natxo Asenjo wrote:
>
> > > when I go to http://www.freeipa.org/page/Special:OpenIDLogin to login
> > > with the fedora account I get
> > >
> > >
> > >   OpenID error
> > >
> > > An error occurred: an invalid token was found.
> > >
> > > Return to Main Page .
> > >
> > >
> > > So, sorry, I cannot edit the contribute to the wiki. I will write
> > > something down in my own wiki and post the link here, search engines
> > > will index this mailing list posts as well, so this knowledge will not
> > > go lost.
> >
> > It's not just you. I can't login either. I think Martin will need to
> > poke at this on Monday.
>
> I tried this just now and it worked, maybe there was an issue that has
> since resolved itself ?
>

no, same error.

O well, I have this howto, just copy paste it from my mediawiki (public
domain):

https://asenjo.nl/wiki/index.php/Client_certificate_authentication_ipa

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

[Simo Sorce]

On Fri, 2016-03-04 at 14:34 -0500, Rob Crittenden wrote:
> Natxo Asenjo wrote:
> > 
> > 
> > On Fri, Mar 4, 2016 at 4:58 PM, Natxo Asenjo  > > wrote:
> > 
> > 
> > 
> > On Fri, Mar 4, 2016 at 3:43 PM, Rob Crittenden  > > wrote:
> > 
> > Ah right. Because all the subjects are the same base the same
> > map will
> > be used for both DS and the CA.
> > 
> > Any chance you could write up a HOWTO on this?
> > 
> > 
> > Gladly, but I seem unable to login using my recently created fedora
> > account. I will try later in the evening again.
> > 
> > 
> > when I go to http://www.freeipa.org/page/Special:OpenIDLogin to login
> > with the fedora account I get
> > 
> > 
> >   OpenID error
> > 
> > An error occurred: an invalid token was found.
> > 
> > Return to Main Page .
> > 
> > 
> > So, sorry, I cannot edit the contribute to the wiki. I will write
> > something down in my own wiki and post the link here, search engines
> > will index this mailing list posts as well, so this knowledge will not
> > go lost.
> 
> It's not just you. I can't login either. I think Martin will need to
> poke at this on Monday.

I tried this just now and it worked, maybe there was an issue that has
since resolved itself ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

[Rob Crittenden]

Natxo Asenjo wrote:
> 
> 
> On Fri, Mar 4, 2016 at 4:58 PM, Natxo Asenjo  > wrote:
> 
> 
> 
> On Fri, Mar 4, 2016 at 3:43 PM, Rob Crittenden  > wrote:
> 
> Ah right. Because all the subjects are the same base the same
> map will
> be used for both DS and the CA.
> 
> Any chance you could write up a HOWTO on this?
> 
> 
> Gladly, but I seem unable to login using my recently created fedora
> account. I will try later in the evening again.
> 
> 
> when I go to http://www.freeipa.org/page/Special:OpenIDLogin to login
> with the fedora account I get
> 
> 
>   OpenID error
> 
> An error occurred: an invalid token was found.
> 
> Return to Main Page .
> 
> 
> So, sorry, I cannot edit the contribute to the wiki. I will write
> something down in my own wiki and post the link here, search engines
> will index this mailing list posts as well, so this knowledge will not
> go lost.

It's not just you. I can't login either. I think Martin will need to
poke at this on Monday.

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

Re: [Freeipa-users] user certificate ldap EXTERNAL authentication

[Natxo Asenjo]

On Fri, Mar 4, 2016 at 4:58 PM, Natxo Asenjo  wrote:

>
>
> On Fri, Mar 4, 2016 at 3:43 PM, Rob Crittenden 
> wrote:
>
>> Ah right. Because all the subjects are the same base the same map will
>> be used for both DS and the CA.
>>
>> Any chance you could write up a HOWTO on this?
>
>
> Gladly, but I seem unable to login using my recently created fedora
> account. I will try later in the evening again.
>
>
when I go to http://www.freeipa.org/page/Special:OpenIDLogin to login with
the fedora account I get

OpenID error

An error occurred: an invalid token was found.

Return to Main Page .


So, sorry, I cannot edit the contribute to the wiki. I will write something
down in my own wiki and post the link here, search engines will index this
mailing list posts as well, so this knowledge will not go lost.


-- 

regards,

natxo

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

[Natxo Asenjo]

On Fri, Mar 4, 2016 at 3:43 PM, Rob Crittenden  wrote:

> Ah right. Because all the subjects are the same base the same map will
> be used for both DS and the CA.
>
> Any chance you could write up a HOWTO on this?


Gladly, but I seem unable to login using my recently created fedora
account. I will try later in the evening again.

--
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] Some high level questions (DNS & CA)

[Petr Spacek]

On 3.3.2016 13:26, Martin Basti wrote:
> Hello,
> 
> comments inline
> 
> On 03.03.2016 13:11, Geselle Stijn wrote:
>>
>> Hello,
>>
>> We have a large Windows environment and around 50 RHEL servers (which will
>> grow to a few hundred in the future). Our goal is to be able to login with
>> our AD credentials and have sudo centrally managed. To be able to manage
>> users and their access/permissions we are looking into IdM combined with a
>> unidirectional non-transitive AD-trust so our existing AD users can
>> authenticate on the RHEL servers.
>>
>> I have a few (high level) questions regarding the setup of IdM:
>>
>> 1)There is an integrated DNS component (BIND). Is this component required?
>> Because we would like to keep DNS managed by Windows (A and CNAME records).
>> I have seen that there’s a forward only policy, but what’s the point of
>> that? Can’t we just directly use the Windows DNS then instead of forwarding,
>> i.e. point the client’s nameservers to the Windows nameservers? I’m
>> obviously missing something crucial, sorry J
>>
> DNS subsytem is optional, you can use windows DNS for IPA (manual
> configuration needed for each replica)

Today we released new version of docs, please see

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/ipa-linux-services.html#dns

for further details regarding DNS.

-- 
Petr^2 Spacek

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

[Rob Crittenden]

Natxo Asenjo wrote:
> hi,
> 
> 
> On Thu, Mar 3, 2016 at 10:57 PM, Rob Crittenden  > wrote:
> 
> Natxo Asenjo wrote:
> 
>  
> 
> > Using EXTERNAL, no cookie:
> > $ ldapsearch -h kdc.sub.domain.tld -ZZ -Y EXTERNAL -LLL
> > objectclass=person -s sub -b dc=sub,dc=domain,dc=tld cn
> > SASL/EXTERNAL authentication started
> > ldap_sasl_interactive_bind_s: Invalid credentials (49)
> > additional info: client certificate mapping failed
> >
> > I came accross this page in the 389 wiki:
> >
> >
> http://directory.fedoraproject.org/docs/389ds/howto/howto-certmapping.html
> >
> > But I am not really sure how to accomplish this.
> >
> > Is this possible in freeipa?
> 
> I don't see why not. You just need to be able to map the subject of the
> cert to a single entry. That's what certmap.conf attempts to do.
>  
> 
> 
> ok, I got it working  but it took some effort.
> 
> Let's see, in certmap.conf the config is like this out of the box:
> 
> certmap default default
> #default:DNComps
> #default:FilterCompse, uid
> #default:verifycert on
> #default:CmapLdapAttr   certSubjectDN
> #default:library
> #default:InitFn 
> default:DNComps
> default:FilterComps uid
> certmap ipaca   CN=Certificate Authority,O=SUB.DOMAIN.TLD
> ipaca:CmapLdapAttr  seeAlso
> ipaca:verifycerton
>  
> So, there is an additional mapping for ipaca, which is handy. But the
> CmapLdapAttr points to 'seeAlso', and if you change that to
> usercertificate;binary (where the usercertificates are), the tomcat pki
> service will no longer start because
> 
> DN: uid=pkidbuser,ou=people,o=ipaca
> 
> has this seealso attribute: CN=CA Subsystem,O=SUB.DOMAIN.TLD
> 
> so we cannot change te cmapldapattr to something else, but we can add a
> seealso attribute to the user account, like cn=username,o=SUB.DOMAIN.TLD
> . And then it works.

Ah right. Because all the subjects are the same base the same map will
be used for both DS and the CA.

Any chance you could write up a HOWTO on this?

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

Re: [Freeipa-users] user certificate ldap EXTERNAL authentication

[Natxo Asenjo]

hi,


On Thu, Mar 3, 2016 at 10:57 PM, Rob Crittenden  wrote:

> Natxo Asenjo wrote:
>


> > Using EXTERNAL, no cookie:
> > $ ldapsearch -h kdc.sub.domain.tld -ZZ -Y EXTERNAL -LLL
> > objectclass=person -s sub -b dc=sub,dc=domain,dc=tld cn
> > SASL/EXTERNAL authentication started
> > ldap_sasl_interactive_bind_s: Invalid credentials (49)
> > additional info: client certificate mapping failed
> >
> > I came accross this page in the 389 wiki:
> >
> >
> http://directory.fedoraproject.org/docs/389ds/howto/howto-certmapping.html
> >
> > But I am not really sure how to accomplish this.
> >
> > Is this possible in freeipa?
>
> I don't see why not. You just need to be able to map the subject of the
> cert to a single entry. That's what certmap.conf attempts to do.
>
>

ok, I got it working  but it took some effort.

Let's see, in certmap.conf the config is like this out of the box:

certmap default default
#default:DNComps
#default:FilterCompse, uid
#default:verifycert on
#default:CmapLdapAttr   certSubjectDN
#default:library
#default:InitFn 
default:DNComps
default:FilterComps uid
certmap ipaca   CN=Certificate Authority,O=SUB.DOMAIN.TLD
ipaca:CmapLdapAttr  seeAlso
ipaca:verifycerton

So, there is an additional mapping for ipaca, which is handy. But the
CmapLdapAttr points to 'seeAlso', and if you change that to
usercertificate;binary (where the usercertificates are), the tomcat pki
service will no longer start because

DN: uid=pkidbuser,ou=people,o=ipaca

has this seealso attribute: CN=CA Subsystem,O=SUB.DOMAIN.TLD

so we cannot change te cmapldapattr to something else, but we can add a
seealso attribute to the user account, like cn=username,o=SUB.DOMAIN.TLD .
And then it works.

This could be very handy for web applications.

Nice. Thanks for the pointer.

Regards,
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] FreeIPA 4.2.0 / Replica / Join Issue

[Petr Spacek]

On 3.3.2016 22:05, de...@pabstatencio.com wrote:
> Rob,
> 
> Yeah i forgot to attach the file when I initially sent. I also attached the 
> output from all the nodes. I guess what i realized is that my agreements are 
> a little different than i originally thought. What is also strange is on a 
> few hosts that initially did enroll from AWS, when I look at the host via the 
> GUI the host shows:
> 
> Kerberos Key Present, Host Provisioned
> One-Time-Password Not Present
> Host Certificate, No Valid Certificate
> 
> So the few that enrolled, they don't show having any Host certificates but 
> they show Kerberos Key present and Host provisioned. Is there a problem with 
> the way I provisioned the Replicas? I'm just using subdomains for human 
> clarification but they all use the same Kerberos domain, etc.
> 
> 
> [root@ipa02-ore ~]# ipa-replica-manage list -v `hostname`
> Directory Manager password:
> 
> ipa01-ore.prod.cloud.myinc.local: replica
>   last init status: None
>   last init ended: 1970-01-01 00:00:00+00:00
>   last update status: 0 Replica acquired successfully: Incremental update 
> succeeded
>   last update ended: 2016-03-03 20:39:30+00:00
> 
> 
> [root@ipa01-ore ~]# ipa-replica-manage list -v `hostname`
> ipa02-ore.prod.cloud.myinc.local: replica
>   last init status: None
>   last init ended: 1970-01-01 00:00:00+00:00
>   last update status: 0 Replica acquired successfully: Incremental update 
> succeeded
>   last update ended: 2016-03-03 20:41:20+00:00
> rspsna-ipa01.prod.i2x.myinc.local: replica
>   last init status: None
>   last init ended: 1970-01-01 00:00:00+00:00
>   last update status: 0 Replica acquired successfully: Incremental update 
> succeeded
>   last update ended: 2016-03-03 20:41:29+00:00
> 
> [root@rspsna-ipa01 ~]# ipa-replica-manage list -v `hostname`
> 
> ipa01-ore.prod.cloud.myinc.local: replica
>   last init status: None
>   last init ended: 1970-01-01 00:00:00+00:00
>   last update status: 0 Replica acquired successfully: Incremental update 
> succeeded
>   last update ended: 2016-03-03 20:43:35+00:00
> rspsna-ipa02.prod.i2x.myinc.local: replica
>   last init status: None
>   last init ended: 1970-01-01 00:00:00+00:00
>   last update status: 0 Replica acquired successfully: Incremental update 
> succeeded
>   last update ended: 2016-03-03 20:43:35+00:00
> 
> [root@rspsna-ipa02 ~]# ipa-replica-manage list -v `hostname`
> 
> rspsna-ipa01.prod.i2x.myinc.local: replica
>   last init status: None
>   last init ended: 1970-01-01 00:00:00+00:00
>   last update status: 0 Replica acquired successfully: Incremental update 
> succeeded
>   last update ended: 2016-03-03 20:44:14+00:00
> 
> See attached file for the initial fail. Thanks very much for your help.
> 
> Devin Acosta
> 
> arch 3 2016 1:34 PM, "Rob Crittenden"  wrote:
>> de...@pabstatencio.com wrote:
>>
>>> I am running the latest patched CentOS 7.2, with FreeIPA 4.2.0, and I
>>> the Master node in the Data Center, then i created 3 replica's, one in
>>> the DC for High Availability, and then 2 Replica's in the AWS Cloud. I'm
>>> having major issues with the Replica's in the AWS Cloud. I am trying to
>>> have it so it auto-discovers the servers automatically so the failover
>>> is dynamic. I created the replica's as well to have a Certificate
>>> Authority. When I attempt to join a virtual machine in AWS to the domain
>>> it fails half way thru the process. I have attached a full debug of my
>>> ipa-client-install, hoping someone can assist me. I know prior to
>>> joining the 2 replicas in AWS I had absolutely no issues with joining
>>> servers in the DC to IDM. I built all my replica's from the Master
>>> server (rspsna-ipa01), so rspsna-ipa02, ipa01-ore, ipa02-ore were built
>>> from rspsna-ipa01.
>>>
>>> The main part that seems to fail during the (client) join is:
>>
>> The important bits are needed. This part of the log is just trying to
>> clean things up (so failures are expected and ok). We'd really need to
>> see a full ipaclient-install.log.

Hmm, I'm not sure if realm name "myinc.LOCAL" is a obfuscation artifact or
real configuration. As usual, attempts to obfuscate things make debugging
harder :-)

Generally it is not a good idea to have realm != uppercase primary IPA DNS 
domain.

It seems that for some reason client is failing to find KDC's addresses.

Try to run kinit in debug mode. Before you try that you might need to replace
krb5.conf on the client with following values (taken form client install log):

[libdefaults]
  default_realm = myinc.LOCAL
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes
  udp_preference_limit = 0
  default_ccache_name = KEYRING:persistent:%{uid}


[realms]
  myinc.LOCAL = {
pkinit_anchors = FILE:/etc/ipa/ca.crt

  }


[domain_realm]
  .prod.cloud.myinc.local = myinc.LOCAL
  prod.cloud.myinc.local = myinc.LOCAL


Then you might try following command on the not-yet-enrolled host:
KRB5_TRACE=/dev/stdout kinit
'host/bean

Re: [Freeipa-users] Version name changed?

[Martin Basti]

On 04.03.2016 01:13, Simpson Lachlan wrote:

Hi,

I have just installed Spacewalk to manage my servers and I noticed that the 
FreeIPA wanted to update some packages.

My FreeIPA server is Centos 7.

I notices in Spacewalk that the ipa-server package (and various bits) wanted to 
update, and the relevant versions were:

Installed packages:

ipa-server-4.2.0-15.el7.centos.3.x86_64

Update candidates:

ipa-server-4.2.0-15.el7_2.6.x86_64


Why has the naming structure changed from

*el7.centos.3.*

to

*el7_2.6*

?

Cheers
L.  

Hello,

I do not know why this change was done in centos, please ask directly on 
centos related lists.


However, version ipa-server-4.2.0-15.el7_2.6.x86_64 is the latest 
version in RHEL and it should be valid.


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