Re: [Freeipa-users] Certmonger (or similar) for FreeBSD?

[David Kupka]

On 24/10/16 19:26, Gilbert Wilson wrote:



On Oct 24, 2016, at 5:51 AM, David Kupka  wrote:

On 22/10/16 00:15, Gilbert Wilson wrote:

We have a lot of FreeBSD systems that I would like to streamline certificate 
issuance and renewal. Ideally, we could leverage our FreeIPA system's CA to do 
this. But, certmonger doesn't run on FreeBSD (or does it?). What other means 
have other people tried, or would you recommend investigating, to enable 
automated certificate issuance and renewal for FreeBSD FreeIPA clients?

Any pointers are appreciated!

Gil



Hello Gil!

I've very limited experiences with *BSD systems so the question may be 
completely off.
Have you tried to install and run certmonger using FreeBSD's Linux Binary 
Compatibility [1]? Though I don't know what are the limitations or possible 
issues it could be a way.

[1] http://www.freebsd.cz/doc/handbook/linuxemu.html

--
David Kupka



You know… I haven’t ever tried LBC! I suppose it’s worth a sacrificial virtual 
machine to see if it works. It also occurred to me that FreeIPA might have some 
sort of API given the web interface, and sure enough that made the Google-fu 
turn up more useful results.

* https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/
* https://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/
* http://www.admin-magazine.com/Archive/2016/34/A-REST-interface-for-FreeIPA

There doesn’t appear to be a manual for the API but those examples seem to 
“show the way”. My initial thought is to create a script that uses kinit with a 
keytab to authenticate against FreeIPA and then create/renew permissible 
certificates for the system before they expire. This seems reasonable since the 
certificate creation/renewal is the scope of what I’m interested in doing. Do 
you see any reason not to do it this way or have any other alternative 
suggestions? Another way to think about it, perhaps, is what would you do on a 
Linux system if you didn’t have access to the FreeIPA client or certmonger?

Thanks for the pointer/reminder about LBC!

Gil





You're right, FreeIPA has JSON RPC API. It's used in WebUI and also in 
'ipa' CLI. If you've FreeIPA server 4.2 and above there's API Browser in 
WebUI (IPA Server - API Browser). There you can find all commands and 
their parameters.
Just obligatory disclaimer, talking directly to the API is not 
officially supported. This means that the API can change in future versions.


Good luck!
--
David Kupka

--
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] Why does a SAN field on a CSR require a host to be in IPA?

[Fraser Tweedale]

On Tue, Oct 25, 2016 at 08:01:59AM +0300, Alexander Bokovoy wrote:
> On ti, 25 loka 2016, Fraser Tweedale wrote:
> > On Mon, Oct 24, 2016 at 12:30:10AM -0700, Fil Di Noto wrote:
> > > On Sun, Oct 23, 2016 at 9:53 PM, Fraser Tweedale  
> > > wrote:
> > > > On Sun, Oct 23, 2016 at 08:37:15PM -0700, Fil Di Noto wrote:
> > > >> Hello,
> > > >>
> > > >>
> > > >>
> > > >> I would like to better understand why IPA requires SAN (subject 
> > > >> alternative
> > > >> name) entries to have a backing host record. In order to sign a 
> > > >> certificate
> > > >> with a SAN that corresponded to a user friendly CNAME I had to add a 
> > > >> host
> > > >> record (ipa host) for that DNS name (use force option to create 
> > > >> without an
> > > >> A/ record) as well as a service principle.
> > > >>
> > > >>
> > > >>
> > > >> I'm sure I'm not alone when I say I don't like doing that because it 
> > > >> means
> > > >> that a "Host" in FreeIPA is not a computer, it's a host record that 
> > > >> may or
> > > >> may not be the only record that corresponds to a computer. It gets
> > > >> confusing.
> > > >>
> > > >>
> > > >>
> > > >> I assume things are this way to ensure integrity at some level. But I 
> > > >> can't
> > > >> picture it. What is the potential danger of simply bypassing the
> > > >> host/principal checks and just signing the certificate with whatever 
> > > >> SAN
> > > >> field we like?
> > > >>
> > > > In this specific case, it is because certmonger requests service
> > > > certificates with host credentials.  Therefore it is not just human
> > > > administrators issuing certs.  And we MUST validate SAN against
> > > > information in the directory (the only "source of truth" available
> > > > to the CA / IPA cert-request command).  Otherwise you could put e.g.
> > > > `google.com' into SAN, and we would issue the cert, and that would
> > > > be Very Bad.
> > > >
> > > 
> > > In my case it's always human administrators issuing certs. I can see
> > > how validation is a great way to prevent a scenario like the one you
> > > described. But couldn't that be accommodated by tinkering with the
> > > roles/privileges so that you could impose the restriction on external,
> > > less-trusted applications but allow a trusted human administrator to
> > > bypass it?
> > > 
> > > Admin group by default would be nice. It would be unfortunate if
> > > someone added a service account to the admin group, but I don't see
> > > that as justification for ruling it out. How many other poor security
> > > decisions has someone made already before they decided to add a
> > > service account to the domain admin group? To that I would say that
> > > degree of administrative negligence is not something that the project
> > > should design around. But, I don't work at RedHat and I don't have to
> > > take the support calls so my opinion means nothing.
> > > 
> > > But if I'm an admin, enforcing the SAN restriction doesn't prevent me
> > > from doing anything I couldn't already do by creating a couple host
> > > records. It's just making things difficult for admins who ultimately
> > > are securely deploying a service.
> > > 
> > The question is not really one of privilege, but sanity.  FreeIPA
> > has to make sure that certs issued by it correspond to the CA's view
> > of reality, i.e. what is in the FreeIPA directory, at the time the
> > request is made.  IMO to disable these checks for human users with a
> > particular permission is a mistake waiting to happen.
> > 
> > Yes, enforcing the restriction forces a human to put to created the
> > needed objects before the cert request will be considered valid.
> > Not a bad thing, IMO.
> > 
> > All this said, I think there is a valid RFE in allowing Kerberos
> > principal aliases to be consulted when validating a CSR.  This would
> > mean you do not have to create new objects, just add more principal
> > names to the existing one.  I filed a ticket:
> > 
> > https://fedorahosted.org/freeipa/ticket/6432
> > 
> > Alexander, Simo, what do you think?
> Certainly principal aliases should be checked if they were asked to be
> in SAN. The question is what type of the SAN extension should be
> considered for them in addition to Kerberos principal. The aliases are
> stored in their full format (alias@REALM), so either you need to do full
> match or consider dropping the realm for some types. This needs to be
> clarified before any implementation happens.
> 
Right, UPN and KR5PrincipalName can be checked as-is.

We should check dnsNames by affixing around the dnsName the same
service type (e.g. `HTTP') and realm as the nominated principal, and
looking for that in the aliases. e.g. for nominated principal
`HTTP/web.example@example.com', if there is a SAN dnsName
`www.example.com', we look for `HTTP/www.example@example.com' in
its aliases.

Does this sound reasonable?

No other GeneralName types shall be checked against principal
aliases, unless/until we support 

Re: [Freeipa-users] Why does a SAN field on a CSR require a host to be in IPA?

[Alexander Bokovoy]

On ti, 25 loka 2016, Fraser Tweedale wrote:

On Mon, Oct 24, 2016 at 12:30:10AM -0700, Fil Di Noto wrote:

On Sun, Oct 23, 2016 at 9:53 PM, Fraser Tweedale  wrote:
> On Sun, Oct 23, 2016 at 08:37:15PM -0700, Fil Di Noto wrote:
>> Hello,
>>
>>
>>
>> I would like to better understand why IPA requires SAN (subject alternative
>> name) entries to have a backing host record. In order to sign a certificate
>> with a SAN that corresponded to a user friendly CNAME I had to add a host
>> record (ipa host) for that DNS name (use force option to create without an
>> A/ record) as well as a service principle.
>>
>>
>>
>> I'm sure I'm not alone when I say I don't like doing that because it means
>> that a "Host" in FreeIPA is not a computer, it's a host record that may or
>> may not be the only record that corresponds to a computer. It gets
>> confusing.
>>
>>
>>
>> I assume things are this way to ensure integrity at some level. But I can't
>> picture it. What is the potential danger of simply bypassing the
>> host/principal checks and just signing the certificate with whatever SAN
>> field we like?
>>
> In this specific case, it is because certmonger requests service
> certificates with host credentials.  Therefore it is not just human
> administrators issuing certs.  And we MUST validate SAN against
> information in the directory (the only "source of truth" available
> to the CA / IPA cert-request command).  Otherwise you could put e.g.
> `google.com' into SAN, and we would issue the cert, and that would
> be Very Bad.
>

In my case it's always human administrators issuing certs. I can see
how validation is a great way to prevent a scenario like the one you
described. But couldn't that be accommodated by tinkering with the
roles/privileges so that you could impose the restriction on external,
less-trusted applications but allow a trusted human administrator to
bypass it?

Admin group by default would be nice. It would be unfortunate if
someone added a service account to the admin group, but I don't see
that as justification for ruling it out. How many other poor security
decisions has someone made already before they decided to add a
service account to the domain admin group? To that I would say that
degree of administrative negligence is not something that the project
should design around. But, I don't work at RedHat and I don't have to
take the support calls so my opinion means nothing.

But if I'm an admin, enforcing the SAN restriction doesn't prevent me
from doing anything I couldn't already do by creating a couple host
records. It's just making things difficult for admins who ultimately
are securely deploying a service.


The question is not really one of privilege, but sanity.  FreeIPA
has to make sure that certs issued by it correspond to the CA's view
of reality, i.e. what is in the FreeIPA directory, at the time the
request is made.  IMO to disable these checks for human users with a
particular permission is a mistake waiting to happen.

Yes, enforcing the restriction forces a human to put to created the
needed objects before the cert request will be considered valid.
Not a bad thing, IMO.

All this said, I think there is a valid RFE in allowing Kerberos
principal aliases to be consulted when validating a CSR.  This would
mean you do not have to create new objects, just add more principal
names to the existing one.  I filed a ticket:

https://fedorahosted.org/freeipa/ticket/6432

Alexander, Simo, what do you think?

Certainly principal aliases should be checked if they were asked to be
in SAN. The question is what type of the SAN extension should be
considered for them in addition to Kerberos principal. The aliases are
stored in their full format (alias@REALM), so either you need to do full
match or consider dropping the realm for some types. This needs to be
clarified before any implementation happens.

--
/ 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] Why does a SAN field on a CSR require a host to be in IPA?

[Fraser Tweedale]

On Mon, Oct 24, 2016 at 12:30:10AM -0700, Fil Di Noto wrote:
> On Sun, Oct 23, 2016 at 9:53 PM, Fraser Tweedale  wrote:
> > On Sun, Oct 23, 2016 at 08:37:15PM -0700, Fil Di Noto wrote:
> >> Hello,
> >>
> >>
> >>
> >> I would like to better understand why IPA requires SAN (subject alternative
> >> name) entries to have a backing host record. In order to sign a certificate
> >> with a SAN that corresponded to a user friendly CNAME I had to add a host
> >> record (ipa host) for that DNS name (use force option to create without an
> >> A/ record) as well as a service principle.
> >>
> >>
> >>
> >> I'm sure I'm not alone when I say I don't like doing that because it means
> >> that a "Host" in FreeIPA is not a computer, it's a host record that may or
> >> may not be the only record that corresponds to a computer. It gets
> >> confusing.
> >>
> >>
> >>
> >> I assume things are this way to ensure integrity at some level. But I can't
> >> picture it. What is the potential danger of simply bypassing the
> >> host/principal checks and just signing the certificate with whatever SAN
> >> field we like?
> >>
> > In this specific case, it is because certmonger requests service
> > certificates with host credentials.  Therefore it is not just human
> > administrators issuing certs.  And we MUST validate SAN against
> > information in the directory (the only "source of truth" available
> > to the CA / IPA cert-request command).  Otherwise you could put e.g.
> > `google.com' into SAN, and we would issue the cert, and that would
> > be Very Bad.
> >
> 
> In my case it's always human administrators issuing certs. I can see
> how validation is a great way to prevent a scenario like the one you
> described. But couldn't that be accommodated by tinkering with the
> roles/privileges so that you could impose the restriction on external,
> less-trusted applications but allow a trusted human administrator to
> bypass it?
> 
> Admin group by default would be nice. It would be unfortunate if
> someone added a service account to the admin group, but I don't see
> that as justification for ruling it out. How many other poor security
> decisions has someone made already before they decided to add a
> service account to the domain admin group? To that I would say that
> degree of administrative negligence is not something that the project
> should design around. But, I don't work at RedHat and I don't have to
> take the support calls so my opinion means nothing.
> 
> But if I'm an admin, enforcing the SAN restriction doesn't prevent me
> from doing anything I couldn't already do by creating a couple host
> records. It's just making things difficult for admins who ultimately
> are securely deploying a service.
> 
The question is not really one of privilege, but sanity.  FreeIPA
has to make sure that certs issued by it correspond to the CA's view
of reality, i.e. what is in the FreeIPA directory, at the time the
request is made.  IMO to disable these checks for human users with a
particular permission is a mistake waiting to happen.

Yes, enforcing the restriction forces a human to put to created the
needed objects before the cert request will be considered valid.
Not a bad thing, IMO.

All this said, I think there is a valid RFE in allowing Kerberos
principal aliases to be consulted when validating a CSR.  This would
mean you do not have to create new objects, just add more principal
names to the existing one.  I filed a ticket:

https://fedorahosted.org/freeipa/ticket/6432

Alexander, Simo, what do you think?


> > The problem is slightly exacerbated in that 99% of the time you
> > really want to issue service certs, but FreeIPA does not permit the
> > creation of a service entry without a corresponding host entry.  So
> > you end up with spurious host entries that do not correspond to
> > actual hosts.  I have previously asked about relaxing this
> > restriction.  The idea was rejected (for reasons I don't remember).
> 
> To be fair, I don't think I ever read specifically that a Host in IPA
> was supposed to represent a single computer. But I imagine that the
> majority of people who are using it thought that was the case, at
> least at first. I don't think it would take much abstraction to
> maintain that logical representation for administrators.
> 
> >> If this actually is a necessity and is not likely to change, I think it
> >> would be beneficial to administrators to be able to manage "Hosts" that
> >> correspond to CNAMEs (call them "Alias Hosts"? ) separately from Hosts that
> >> are actually enrolled computers. They could be managed in a similar fashion
> >> to SUDO rules, like maybe:
> >>
> >>
> >>
> >> Alias Hosts = a single name
> >>
> >> Alias Host Groups = groups of names
> >>
> >> Alias Host Maps = associate Alias Host/Group with a Hosts or Host Groups
> >>
> >>
> >>
> >> I'm picturing Alias Hosts and Alias groups as a seperate tab under Identity
> >> (and some corresponding "ipa aliashost-*" CLI) 

Re: [Freeipa-users] Do expired passwords remain usable indefinitely?

[Prasun Gera]

I've seen some different behaviour. I've had errors for users (including
the admin user) trying to log in with possibly an expired password. Both
webui and ssh would fail, but kinit would work. I'm not sure if this is
related to the password's expiration or the account's expiration. My
/var/log/secure has messages like "pam_sss(sshd:auth): received for user
uname: 13 (User account has expired)". Is there a setting for default
expiration of user accounts ? I don't remember setting it anywhere.

On Mon, Oct 24, 2016 at 8:13 AM, David Kupka  wrote:

> On 21/10/16 15:17, Brian Candler wrote:
>
>> Question: when a password expires, does it remain in a usable state in
>> the database indefinitely? For example, if someone comes along a year
>> after their password has expired, can they still login once with that
>> password?
>>
>> This is actually what I want, but I just want to confirm there's not
>> some sort of secondary threshold which means that an expired password is
>> not usable X days after it has expired.  Or, if there is such a
>> secondary threshold, where I can find it.
>>
>> The scenario is a RADIUS server for wifi which reads NTLM password
>> hashes out of the database to authenticate - this continues to work
>> after expiry. However I want users to be able to do a self-reset later
>> if and when they want to.
>>
>> Thanks,
>>
>> Brian.
>>
>>
> Hello Brian!
>
> AFAIK, it will work. Your RADIUS server will retrieve the hash from LDAP
> and do the validation locally. So FreeIPA has no way to say the password is
> expired.
> When the user tries to obtain Kerberos ticket he will be forced to change
> the password and NTLM hash will be also regenerated.
>
> --
> David Kupka
>
>
> --
> 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] Certmonger (or similar) for FreeBSD?

[Gilbert Wilson]

> On Oct 24, 2016, at 5:51 AM, David Kupka  wrote:
> 
> On 22/10/16 00:15, Gilbert Wilson wrote:
>> We have a lot of FreeBSD systems that I would like to streamline certificate 
>> issuance and renewal. Ideally, we could leverage our FreeIPA system's CA to 
>> do this. But, certmonger doesn't run on FreeBSD (or does it?). What other 
>> means have other people tried, or would you recommend investigating, to 
>> enable automated certificate issuance and renewal for FreeBSD FreeIPA 
>> clients?
>> 
>> Any pointers are appreciated!
>> 
>> Gil
>> 
> 
> Hello Gil!
> 
> I've very limited experiences with *BSD systems so the question may be 
> completely off.
> Have you tried to install and run certmonger using FreeBSD's Linux Binary 
> Compatibility [1]? Though I don't know what are the limitations or possible 
> issues it could be a way.
> 
> [1] http://www.freebsd.cz/doc/handbook/linuxemu.html
> 
> -- 
> David Kupka


You know… I haven’t ever tried LBC! I suppose it’s worth a sacrificial virtual 
machine to see if it works. It also occurred to me that FreeIPA might have some 
sort of API given the web interface, and sure enough that made the Google-fu 
turn up more useful results.

* https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/
* https://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/
* http://www.admin-magazine.com/Archive/2016/34/A-REST-interface-for-FreeIPA

There doesn’t appear to be a manual for the API but those examples seem to 
“show the way”. My initial thought is to create a script that uses kinit with a 
keytab to authenticate against FreeIPA and then create/renew permissible 
certificates for the system before they expire. This seems reasonable since the 
certificate creation/renewal is the scope of what I’m interested in doing. Do 
you see any reason not to do it this way or have any other alternative 
suggestions? Another way to think about it, perhaps, is what would you do on a 
Linux system if you didn’t have access to the FreeIPA client or certmonger?

Thanks for the pointer/reminder about LBC!

Gil




-- 
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-AD trust group membership: display 'short' group names for *two* AD domains?

[Jakub Hrozek]

On Mon, Oct 24, 2016 at 11:29:06AM -0400, William Muriithi wrote:
> Morning Jakub,
> 
> >>  However, I would like to tune this configuration to drop the domain
> >>  component of the user and group names.  I tried to do this by adding
> >>  these settings to the [sssd] section in sssd.conf on the client:
> >>
> >>default_domain_suffix = example.au
> >> full_name_format = %1$s
> >>
> >>  With this configuration, I can login as a staff domain user (example.au)
> >> successfully and I then see the short-name form of the groups:
> >>
> >> $ ssh -l r...@student.example.au ipa-client-rh7.ipa.example.au
> >> [rnst@ipa-client-rh7 ~]$ groups
> >> rnst
> >>
> >> Is this expected behaviour?  Is there a possible client configuration that
> >> will support our AD forest setup or is this simply not possible?
> >
> > What you did is quite correct, but unfortunately works only with
> > RHEL-7.3 or newer as it requires sssd-1.14 or newer, sorry.
> 
> Does one need  sssd-1.14 on the IPA server only or is this required on
> all the IPA clients too?

I haven't tested since I was working in this area, but I belive the clients
as well.

-- 
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-AD trust group membership: display 'short' group names for *two* AD domains?

[William Muriithi]

Morning Jakub,

>>  However, I would like to tune this configuration to drop the domain
>>  component of the user and group names.  I tried to do this by adding
>>  these settings to the [sssd] section in sssd.conf on the client:
>>
>>default_domain_suffix = example.au
>> full_name_format = %1$s
>>
>>  With this configuration, I can login as a staff domain user (example.au)
>> successfully and I then see the short-name form of the groups:
>>
>> $ ssh -l r...@student.example.au ipa-client-rh7.ipa.example.au
>> [rnst@ipa-client-rh7 ~]$ groups
>> rnst
>>
>> Is this expected behaviour?  Is there a possible client configuration that
>> will support our AD forest setup or is this simply not possible?
>
> What you did is quite correct, but unfortunately works only with
> RHEL-7.3 or newer as it requires sssd-1.14 or newer, sorry.

Does one need  sssd-1.14 on the IPA server only or is this required on
all the IPA clients too?

Regards,
William

-- 
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] Certmonger (or similar) for FreeBSD?

[David Kupka]

On 22/10/16 00:15, Gilbert Wilson wrote:

We have a lot of FreeBSD systems that I would like to streamline certificate 
issuance and renewal. Ideally, we could leverage our FreeIPA system's CA to do 
this. But, certmonger doesn't run on FreeBSD (or does it?). What other means 
have other people tried, or would you recommend investigating, to enable 
automated certificate issuance and renewal for FreeBSD FreeIPA clients?

Any pointers are appreciated!

Gil



Hello Gil!

I've very limited experiences with *BSD systems so the question may be 
completely off.
Have you tried to install and run certmonger using FreeBSD's Linux 
Binary Compatibility [1]? Though I don't know what are the limitations 
or possible issues it could be a way.


[1] http://www.freebsd.cz/doc/handbook/linuxemu.html

--
David Kupka

--
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] Replica Problem (Errors)

[Ludwig Krispenz]

On 10/24/2016 01:21 PM, Günther J. Niederwimmer wrote:

Hello Ludwig,

thanks for the answer,


Am Montag, 24. Oktober 2016, 09:53:21 schrieb Ludwig Krispenz:

On 10/23/2016 03:01 PM, Günther J. Niederwimmer wrote:

I have added on my ipa (Master) Server this user and ACI with a ldif file

ldapmodify -x -D 'cn=Directory Manager' -W
dn: uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com
changetype: add
objectclass: account
objectclass: simplesecurityobject
uid: system
userPassword: secret123
passwordExpirationTime: 20380119031407Z
nsIdleTimeout: 0

^D

dn: cn=users,cn=accounts,dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr="mailAlternateAddress")
(targetfilter="(objectClass=mailrecipient)")

(version
3.0; acl "Allow system account to read mail address"; allow(read,
search, compare) userdn =
"ldap:///uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com;;)

This Ends with a
modifying entry "cn=users,cn=accounts,dc=example,dc=com"

these changes are not related to the errors you report below (I would be
really surprised) and you only need to apply them on one server, that's
what replication is good for.

There are a couple of different types of messages:
- failed to delete changelog record: this is from retro changelog
trimming, when miscalculation of the starting point for trimming starts
with changenumber lower than what's in the retro changelog.
In my experience this can happen after a crash/kill/reboot and should
stop after som time

OK, nothing to do ;-).
  

- attrlist_replace errors: looks like you have recreated a replica on a
machine and not cleaned the RUV, please see:
http://www.freeipa.org/page/Troubleshooting#Obsolete_RUV_records

I don't have add or remove a replica ? this two servers running now I mean
over three month ?
that is strange, could you perform step 1] and 2] of this recipe: 
https://www.redhat.com/archives/freeipa-users/2016-May/msg00043.html

but add the option "-o ldif-wrap=no" to the ldapsearch to get the full ruv


The last I remember I add a 3rd Party Certificate ?

but I don't found before so much Errors :-(.

Is there a possible way to check a freeIPA Installation, to find out for a
"normal" user to have a consistent System ?


- keep-alive already exists: this is also an indication of a new
replica, the keep alive entry was in the database, but the supplier
tries to send it again, this should also disappear once some real
changes from replica 4 are replicated


but now I have on the changed master this 100... Errors

[23/Oct/2016:13:27:58 +0200] DSRetroclPlugin - delete_changerecord: could
not delete change record 396504 (rc: 32)
[23/Oct/2016:13:27:58 +0200] DSRetroclPlugin - delete_changerecord: could
not delete change record 396505 (rc: 32)
[23/Oct/2016:13:27:58 +0200] DSRetroclPlugin - delete_changerecord: could
not delete change record 396506 (rc: 32)
[23/Oct/2016:13:37:08 +0200] NSMMReplicationPlugin - replication keep
alive
entry 

Re: [Freeipa-users] Do expired passwords remain usable indefinitely?

[David Kupka]

On 21/10/16 15:17, Brian Candler wrote:

Question: when a password expires, does it remain in a usable state in
the database indefinitely? For example, if someone comes along a year
after their password has expired, can they still login once with that
password?

This is actually what I want, but I just want to confirm there's not
some sort of secondary threshold which means that an expired password is
not usable X days after it has expired.  Or, if there is such a
secondary threshold, where I can find it.

The scenario is a RADIUS server for wifi which reads NTLM password
hashes out of the database to authenticate - this continues to work
after expiry. However I want users to be able to do a self-reset later
if and when they want to.

Thanks,

Brian.



Hello Brian!

AFAIK, it will work. Your RADIUS server will retrieve the hash from LDAP 
and do the validation locally. So FreeIPA has no way to say the password 
is expired.
When the user tries to obtain Kerberos ticket he will be forced to 
change the password and NTLM hash will be also regenerated.


--
David Kupka

--
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] Replica Problem (Errors)

[Günther J . Niederwimmer]

Hello Ludwig,

thanks for the answer,


Am Montag, 24. Oktober 2016, 09:53:21 schrieb Ludwig Krispenz:
> On 10/23/2016 03:01 PM, Günther J. Niederwimmer wrote:
> > I have added on my ipa (Master) Server this user and ACI with a ldif file
> > 
> > ldapmodify -x -D 'cn=Directory Manager' -W
> > dn: uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com
> > changetype: add
> > objectclass: account
> > objectclass: simplesecurityobject
> > uid: system
> > userPassword: secret123
> > passwordExpirationTime: 20380119031407Z
> > nsIdleTimeout: 0
> > 
> > ^D
> > 
> > dn: cn=users,cn=accounts,dc=example,dc=com
> > changetype: modify
> > add: aci
> > aci: (targetattr="mailAlternateAddress")
> > (targetfilter="(objectClass=mailrecipient)")
> > 
> >(version
> >3.0; acl "Allow system account to read mail address"; allow(read,
> >search, compare) userdn =
> >"ldap:///uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com;;)
> > 
> > This Ends with a
> > modifying entry "cn=users,cn=accounts,dc=example,dc=com"
> 
> these changes are not related to the errors you report below (I would be
> really surprised) and you only need to apply them on one server, that's
> what replication is good for.
> 
> There are a couple of different types of messages:
> - failed to delete changelog record: this is from retro changelog
> trimming, when miscalculation of the starting point for trimming starts
> with changenumber lower than what's in the retro changelog.
> In my experience this can happen after a crash/kill/reboot and should
> stop after som time

OK, nothing to do ;-).
 
> - attrlist_replace errors: looks like you have recreated a replica on a
> machine and not cleaned the RUV, please see:
> http://www.freeipa.org/page/Troubleshooting#Obsolete_RUV_records

I don't have add or remove a replica ? this two servers running now I mean 
over three month ?

The last I remember I add a 3rd Party Certificate ?

but I don't found before so much Errors :-(.

Is there a possible way to check a freeIPA Installation, to find out for a 
"normal" user to have a consistent System ?

> - keep-alive already exists: this is also an indication of a new
> replica, the keep alive entry was in the database, but the supplier
> tries to send it again, this should also disappear once some real
> changes from replica 4 are replicated
> 
> > but now I have on the changed master this 100... Errors
> > 
> > [23/Oct/2016:13:27:58 +0200] DSRetroclPlugin - delete_changerecord: could
> > not delete change record 396504 (rc: 32)
> > [23/Oct/2016:13:27:58 +0200] DSRetroclPlugin - delete_changerecord: could
> > not delete change record 396505 (rc: 32)
> > [23/Oct/2016:13:27:58 +0200] DSRetroclPlugin - delete_changerecord: could
> > not delete change record 396506 (rc: 32)
> > [23/Oct/2016:13:37:08 +0200] NSMMReplicationPlugin - replication keep
> > alive
> > entry 

Re: [Freeipa-users] Setting "preserve" as default action when deleting in webUI

[Pavel Vomacka]

Hello Sebastien,

the safest way is to create a WebUI plugin which rewrite definition of 
radiobutton in deleter dialog. You can find radiobutton code in user.js, 
line 989 (method IPA.user.create_active_user_del_dialog), where you need 
to set default_value to true.


Several examples of plugins can be found here: 
https://pvoborni.fedorapeople.org/plugins/ . I recommend to look at 
employeenumber or association_search_fix. And here is documentation 
about plugins: https://pvoborni.fedorapeople.org/doc/#!/guide/Plugins


On 10/20/2016 11:43 AM, Sébastien Julliot wrote:

Hi everyone,


In order to prevent administrators to make mistakes that could have

silly consequences, I would like to set "preserve" as the default selected

action in freeipa's webui.

What do you think would be the best way to achieve this ?


Thank you in advance,

Sebastien Julliot.





--
Pavel^3 Vomacka

--
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-cacert-manage install failing with subject public key info mismatch

[David Dejaeghere]

These are both the subjects for the old and new root ca cert.

Subject: "CN=tokio-PAPRIKA-CA,DC=tokio,DC=local"
Subject Public Key Info:
Public Key Algorithm: PKCS #1 RSA Encryption
RSA Public Key:
Modulus:
d5:51:19:a0:7e:2f:b6:4b:cb:71:42:cb:38:bc:50:0a:
18:16:58:07:11:c6:d3:ea:66:91:a8:52:02:54:93:28:
78:a1:89:36:7a:0f:1e:2a:35:8a:da:85:05:c4:fe:de:
e8:6a:e8:fd:1b:89:44:8f:8c:62:d6:56:f7:9e:16:d5:
fd:b4:44:65:71:4f:1a:7d:d6:28:2d:5e:ad:c9:da:60:
54:98:02:87:d9:43:62:ab:1b:93:c1:af:0b:b9:80:2e:
08:f0:65:46:bf:de:78:c5:d2:19:b8:07:52:d6:01:ab:
d0:b2:7d:0a:7f:9f:fa:e8:8c:55:86:e0:d3:d5:ef:e7:
ad:6a:12:a2:b8:75:be:93:c2:05:df:99:a9:d8:a2:cc:
7c:2b:49:d6:a3:65:0c:c8:ef:c3:a4:b6:f6:86:1d:c2:
56:56:1b:0d:70:7a:67:15:49:2f:b7:92:8e:2a:94:57:
53:26:ef:9a:af:89:fe:cb:1e:e7:ac:72:9a:cd:b4:22:
b1:22:02:fd:95:23:e0:65:d0:36:e8:e1:88:2b:35:02:
99:1c:ee:84:10:80:84:a8:e5:61:04:6b:a3:6b:da:c5:
49:36:ef:f6:48:09:2c:0d:7c:b2:52:4f:a6:72:cc:e6:
30:b5:dd:a0:5b:0e:96:49:78:9d:1e:27:4e:02:40:a1
Exponent: 65537 (0x10001)

Subject: DC=local, DC=tokio, CN=tokio-PAPRIKA-CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ae:32:35:fa:b5:f4:2d:b8:0c:c3:d9:b0:9f:a8:
5d:21:90:58:a9:79:79:7d:85:7e:f1:f2:36:9d:ef:
9f:8c:a8:3a:bf:57:5c:2e:6b:5d:2e:91:ba:c6:b7:
b2:b1:dd:45:de:e6:d4:fe:01:f4:d2:bd:99:9f:9a:
71:1d:d4:e4:a7:cd:9e:f3:36:a7:a0:73:55:6b:04:
66:ab:c3:63:b3:41:06:ac:c8:c8:3a:4c:eb:83:78:
6e:e8:b6:0f:94:fa:a8:7e:7d:89:44:d1:bd:be:14:
df:0c:ce:4d:b4:e6:0a:e2:d7:84:95:4b:a1:3e:53:
c9:04:3f:7b:de:1b:fd:7b:b5:b0:69:3b:f9:f2:b5:
a7:fe:6d:9d:62:6e:9a:fc:1e:32:69:ad:4c:ae:e3:
61:dd:92:99:34:4b:bf:6b:02:88:18:88:a2:0f:ca:
e8:6e:91:f0:e6:2e:4d:83:f6:05:7e:ed:f2:f1:3e:
b2:36:3f:de:3f:db:93:73:5b:60:ee:8c:48:e0:c0:
4c:0e:6a:63:1a:16:af:9e:28:93:40:39:23:bf:d0:
77:9c:b7:80:d3:c3:42:d8:27:db:d7:4b:e5:3f:b4:
d2:ad:57:c2:01:73:c8:45:26:f1:00:93:50:3e:cf:
7a:2d:25:d5:43:b6:a7:75:a1:ef:58:f9:c9:11:e8:
09:1d
Exponent: 65537 (0x10001)

2016-10-24 5:49 GMT+02:00 Fil Di Noto :

> Hi,
>
> Can you give an example of what's different between the two subjects?
>
> On Sun, Oct 23, 2016 at 9:03 AM, David Dejaeghere <
> david.dejaegh...@gmail.com> wrote:
>
>> Does somebody have an idea how to replace our certificates when the new
>> ROOT ca certificate has a different subject?
>> The UI is down because of this.
>>
>> 2016-10-19 11:42 GMT+02:00 David Dejaeghere :
>>
>>> Hello,
>>>
>>> When installing FreeIPA we used the CA from our Windows servers.
>>> This one recently expired and we created a new one.  It seems that the
>>> new root CA has another subject name and this seems to be an issue when we
>>> want to install new certs on our FreeIPA hosts.
>>>
>>> ipa-cacert-manage install certnew.pem -n mycert -t C,,
>>>
>>> Installing CA certificate, please wait
>>> Failed to install the certificate: subject public key info mismatch
>>>
>>> After validating the subjects are indeed different.
>>>
>>> How can we replace the required certs for dirsrv and http when the ca is
>>> not installable?
>>>
>>> Kind Regards,
>>>
>>> David
>>>
>>>
>>>
>>
>> --
>> 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] Replica Problem (Errors)

[Ludwig Krispenz]

Hi,
On 10/23/2016 03:01 PM, Günther J. Niederwimmer wrote:

Hello,

I have added on my ipa (Master) Server this user and ACI with a ldif file

ldapmodify -x -D 'cn=Directory Manager' -W
dn: uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com
changetype: add
objectclass: account
objectclass: simplesecurityobject
uid: system
userPassword: secret123
passwordExpirationTime: 20380119031407Z
nsIdleTimeout: 0

^D

dn: cn=users,cn=accounts,dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr="mailAlternateAddress")
(targetfilter="(objectClass=mailrecipient)")
   (version
   3.0; acl "Allow system account to read mail address"; allow(read,
   search, compare) userdn =
   "ldap:///uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com;;)

This Ends with a
modifying entry "cn=users,cn=accounts,dc=example,dc=com"


these changes are not related to the errors you report below (I would be 
really surprised) and you only need to apply them on one server, that's 
what replication is good for.


There are a couple of different types of messages:
- failed to delete changelog record: this is from retro changelog 
trimming, when miscalculation of the starting point for trimming starts 
with changenumber lower than what's in the retro changelog.
In my experience this can happen after a crash/kill/reboot and should 
stop after som time


- attrlist_replace errors: looks like you have recreated a replica on a 
machine and not cleaned the RUV, please see: 
http://www.freeipa.org/page/Troubleshooting#Obsolete_RUV_records


- keep-alive already exists: this is also an indication of a new 
replica, the keep alive entry was in the database, but the supplier 
tries to send it again, this should also disappear once some real 
changes from replica 4 are replicated


but now I have on the changed master this 100... Errors

[23/Oct/2016:13:27:58 +0200] DSRetroclPlugin - delete_changerecord: could not
delete change record 396504 (rc: 32)
[23/Oct/2016:13:27:58 +0200] DSRetroclPlugin - delete_changerecord: could not
delete change record 396505 (rc: 32)
[23/Oct/2016:13:27:58 +0200] DSRetroclPlugin - delete_changerecord: could not
delete change record 396506 (rc: 32)
[23/Oct/2016:13:37:08 +0200] NSMMReplicationPlugin - replication keep alive
entry 

Re: [Freeipa-users] Why does a SAN field on a CSR require a host to be in IPA?

[Fil Di Noto]

On Sun, Oct 23, 2016 at 9:53 PM, Fraser Tweedale  wrote:
> On Sun, Oct 23, 2016 at 08:37:15PM -0700, Fil Di Noto wrote:
>> Hello,
>>
>>
>>
>> I would like to better understand why IPA requires SAN (subject alternative
>> name) entries to have a backing host record. In order to sign a certificate
>> with a SAN that corresponded to a user friendly CNAME I had to add a host
>> record (ipa host) for that DNS name (use force option to create without an
>> A/ record) as well as a service principle.
>>
>>
>>
>> I'm sure I'm not alone when I say I don't like doing that because it means
>> that a "Host" in FreeIPA is not a computer, it's a host record that may or
>> may not be the only record that corresponds to a computer. It gets
>> confusing.
>>
>>
>>
>> I assume things are this way to ensure integrity at some level. But I can't
>> picture it. What is the potential danger of simply bypassing the
>> host/principal checks and just signing the certificate with whatever SAN
>> field we like?
>>
> In this specific case, it is because certmonger requests service
> certificates with host credentials.  Therefore it is not just human
> administrators issuing certs.  And we MUST validate SAN against
> information in the directory (the only "source of truth" available
> to the CA / IPA cert-request command).  Otherwise you could put e.g.
> `google.com' into SAN, and we would issue the cert, and that would
> be Very Bad.
>

In my case it's always human administrators issuing certs. I can see
how validation is a great way to prevent a scenario like the one you
described. But couldn't that be accommodated by tinkering with the
roles/privileges so that you could impose the restriction on external,
less-trusted applications but allow a trusted human administrator to
bypass it?

Admin group by default would be nice. It would be unfortunate if
someone added a service account to the admin group, but I don't see
that as justification for ruling it out. How many other poor security
decisions has someone made already before they decided to add a
service account to the domain admin group? To that I would say that
degree of administrative negligence is not something that the project
should design around. But, I don't work at RedHat and I don't have to
take the support calls so my opinion means nothing.

But if I'm an admin, enforcing the SAN restriction doesn't prevent me
from doing anything I couldn't already do by creating a couple host
records. It's just making things difficult for admins who ultimately
are securely deploying a service.

> The problem is slightly exacerbated in that 99% of the time you
> really want to issue service certs, but FreeIPA does not permit the
> creation of a service entry without a corresponding host entry.  So
> you end up with spurious host entries that do not correspond to
> actual hosts.  I have previously asked about relaxing this
> restriction.  The idea was rejected (for reasons I don't remember).

To be fair, I don't think I ever read specifically that a Host in IPA
was supposed to represent a single computer. But I imagine that the
majority of people who are using it thought that was the case, at
least at first. I don't think it would take much abstraction to
maintain that logical representation for administrators.

>> If this actually is a necessity and is not likely to change, I think it
>> would be beneficial to administrators to be able to manage "Hosts" that
>> correspond to CNAMEs (call them "Alias Hosts"? ) separately from Hosts that
>> are actually enrolled computers. They could be managed in a similar fashion
>> to SUDO rules, like maybe:
>>
>>
>>
>> Alias Hosts = a single name
>>
>> Alias Host Groups = groups of names
>>
>> Alias Host Maps = associate Alias Host/Group with a Hosts or Host Groups
>>
>>
>>
>> I'm picturing Alias Hosts and Alias groups as a seperate tab under Identity
>> (and some corresponding "ipa aliashost-*" CLI) and Alias Host Maps tab
>> under policy.
>>
> Now that we have kerberos principal aliases, we might be able to
> leverage that, perhaps even directly for service principals.  Any
> devs want to chime in on this idea?
>
> Cheers,
> Fraser

-- 
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] Why does a SAN field on a CSR require a host to be in IPA?

[Alexander Bokovoy]

On ma, 24 loka 2016, Fraser Tweedale wrote:

On Sun, Oct 23, 2016 at 08:37:15PM -0700, Fil Di Noto wrote:

Hello,



I would like to better understand why IPA requires SAN (subject alternative
name) entries to have a backing host record. In order to sign a certificate
with a SAN that corresponded to a user friendly CNAME I had to add a host
record (ipa host) for that DNS name (use force option to create without an
A/ record) as well as a service principle.



I'm sure I'm not alone when I say I don't like doing that because it means
that a "Host" in FreeIPA is not a computer, it's a host record that may or
may not be the only record that corresponds to a computer. It gets
confusing.



I assume things are this way to ensure integrity at some level. But I can't
picture it. What is the potential danger of simply bypassing the
host/principal checks and just signing the certificate with whatever SAN
field we like?


In this specific case, it is because certmonger requests service
certificates with host credentials.  Therefore it is not just human
administrators issuing certs.  And we MUST validate SAN against
information in the directory (the only "source of truth" available
to the CA / IPA cert-request command).  Otherwise you could put e.g.
`google.com' into SAN, and we would issue the cert, and that would
be Very Bad.

The problem is slightly exacerbated in that 99% of the time you
really want to issue service certs, but FreeIPA does not permit the
creation of a service entry without a corresponding host entry.  So
you end up with spurious host entries that do not correspond to
actual hosts.  I have previously asked about relaxing this
restriction.  The idea was rejected (for reasons I don't remember).

The host entries are not "spurious" as you call them. They are objects
that participate in the access control. Services always belong to hosts
and are managed by them. Whether there are DNS entries corresponding to
the controlling objects is irrelevant, their primary use is to be used
as something that could be defined as owning the service. The fact that
host object is also a service in itself (for host/) is an
obvious optimization for Kerberos infrastructure

As you know, on x.509 certificate level there are no differences between
services running on the same host, so technically all Kerberos services
could share the same certificate associated with the host that controls
them. You could just keep the certificate in the host entry and be done
with it. This, of course, has own issues -- mostly related to rotation
of the certificates and access to the private keys from multiple
applications -- but this has nothing to do with the way how IPA presents
hosts in the database.


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