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 11:02:44AM -0700, Fil Di Noto wrote:
> On Mon, Oct 24, 2016 at 9:55 PM, 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.
> 
> Help me understand. Assuming that the SAN in the CSR are
> valid/intended/non-malicious, can you give me an example scenario
> where sanity becomes a problem? Is IPA going to examine the cert at
> some point in the future and get confused when it doesn't recognize
> the entries in the SAN field?
> 
> In my imagination, I see IPA for whatever reason comes accross a cert
> it signed in the past and decides it needs to compare the SAN to the
> directory. Then it sees the SAN doesn't have an associated principal
> in the directory. Who does IPA trust? (the directory obviously). IPA
> says, "is this SAN in the directory? No. Did I sign the cert? Yes.
> Should I trust the cert? Yes because I signed it."
> 
> I've got a hundred related questions, but maybe an example would help
> me answer them myself.
> 
A CA must ensure that the assertions it makes have some relationship
to (its view of) reality.  If it issues a cert with `google.com' in
the SAN, the holder of the key can pretend to be `google.com' to
anyone who trusts the CA.  If `alice' tricks an admin into issuing a
cert with `b...@example.com' as a SAN rfc822Name, then alice can
pretend to be Bob.  Entities consuming these certs do not
necessarily have access to the IPA directory to check if the data on
the cert makes sense - they will simply trust whatever assertions
are 

Re: [Freeipa-users] Can't login with on client after password-auth modification

[Matthew Carter]

Works perfectly now! Thank you!


On 10/25/2016 03:34 PM, Alexander Bokovoy wrote:
pam_faillock.so preauth 


--
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] Can't login with on client after password-auth modification

[Alexander Bokovoy]

On ti, 25 loka 2016, Matthew Carter wrote:

So a Gov't STIG has had me add to /etc/pam.d/password-auth:

auth required pam_faillock.so preauth silent deny=3 unlock_time=604800 
fail_interval=900
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 
fail_interval=900

account required  pam_faillock.so

So that it looks like this:

authrequired  pam_env.so
auth required pam_faillock.so preauth silent deny=3 unlock_time=604800 
fail_interval=900
authsufficientpam_unix.so nullok try_first_pass
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 
fail_interval=900
authrequisite pam_succeed_if.so uid >= 500 quiet
authrequired  pam_deny.so

account required  pam_faillock.so
account required  pam_unix.so
account sufficientpam_localuser.so
account sufficientpam_succeed_if.so uid < 500 quiet
account required  pam_permit.so

and now IPA users get a permission denied. Local users can still log in.

I'm not even sure where to start . . .

You don't have pam_sss.so anywhere so any IPA password check could not
be done, only pam_unix.so which checks /etc/passwd or /etc/shadow.

Then you'd need to wrap pam_sss use in 'auth' with pam_faillock.so too:

pam_faillock.so preauth
pam_sss.so 
pam_faillock.so authfail


--
/ 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] Can't login with on client after password-auth modification

[Matthew Carter]

So a Gov't STIG has had me add to /etc/pam.d/password-auth:

auth required pam_faillock.so preauth silent deny=3 unlock_time=604800 
fail_interval=900
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 
fail_interval=900

account required  pam_faillock.so

So that it looks like this:

authrequired  pam_env.so
auth required pam_faillock.so preauth silent deny=3 unlock_time=604800 
fail_interval=900

authsufficientpam_unix.so nullok try_first_pass
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 
fail_interval=900

authrequisite pam_succeed_if.so uid >= 500 quiet
authrequired  pam_deny.so

account required  pam_faillock.so
account required  pam_unix.so
account sufficientpam_localuser.so
account sufficientpam_succeed_if.so uid < 500 quiet
account required  pam_permit.so

and now IPA users get a permission denied. Local users can still log in.

I'm not even sure where to start . . .

Thanks for any hints and help!

/R

Matthew

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

[Fil Di Noto]

On Mon, Oct 24, 2016 at 9:55 PM, 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.

Help me understand. Assuming that the SAN in the CSR are
valid/intended/non-malicious, can you give me an example scenario
where sanity becomes a problem? Is IPA going to examine the cert at
some point in the future and get confused when it doesn't recognize
the entries in the SAN field?

In my imagination, I see IPA for whatever reason comes accross a cert
it signed in the past and decides it needs to compare the SAN to the
directory. Then it sees the SAN doesn't have an associated principal
in the directory. Who does IPA trust? (the directory obviously). IPA
says, "is this SAN in the directory? No. Did I sign the cert? Yes.
Should I trust the cert? Yes because I signed it."

I've got a hundred related questions, but maybe an example would help
me answer them myself.

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

Re: [Freeipa-users] Replica Problem (Errors)

[Günther J . Niederwimmer]

Hello Ludwig,

Thanks for the help.

Am Dienstag, 25. Oktober 2016, 17:20:44 schrieb Ludwig Krispenz:
> On 10/25/2016 04:41 PM, Günther J. Niederwimmer wrote:
> > Hello Ludwig,
> > 
> > Thanks for the answer and help,

>  - 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
> > 
> > OK.
> > The first is
> > 
> > ipa-csreplica-manage list
> > Directory Manager password:
> > 
> > ipa.example.com: master
> > ipa1.example.com: master
> > 
> > The second is:
> > nsDS5ReplicaId: 96
> > nsds50ruv: {replicageneration} 5706b1a30060
> > nsds50ruv: {replica 96 ldap://ipa.example.com:389} 5706b1ab0060
> > 580f6a5f0060
> > nsds50ruv: {replica 91 ldap://ipa1.example.com:389} 5714ad01005b
> > 575c65140005005b
> > nsds50ruv: {replica 97 ldap://ipa1.example.com:389} 5706b1bd0061
> > 570803a90061
 
> you should do the same search on ipa1, it looks like you have to
> replicaids: 91 and 97 for the sane server: ipa1.example.com
> from the timestamps in the RUV I think you recreated the instance on
> ipa1 between Apr,8th and Apr,18th and since then have this in teh RUV.
> but it looks like changes on ipa1 for the o=ipaca suffix are rare (ruv
> output from ipa1 would tell more) and maybe missed the error messages so
> far.

but I don't remember to recreate ipa1 ? But it could be, I have a Error on 
creating the Replica (?).

OK, ipa1 is this

nsDS5ReplicaId: 91
nsds50ruv: {replicageneration} 5706b1a30060
nsds50ruv: {replica 91 ldap://ipa1.example.com:389} 5714ad01005b 
575c65140005005b
nsds50ruv: {replica 96 ldap://ipa.example.com:389} 5706b1ab0060 
580f6a5f0060
nsds50ruv: {replica 97 ldap://ipa1.example.com:389} 5706b1bd0061 
570803a90061


 
> I would suggest you follow the next steps in the doc abou cleaning the
> no longer active replicaID from the ruv

OK, I test it out and hope this is working !

But for me it is not really understandable why this is created ?

> > The domain is changed !!
> > 
> >>> 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] Impossible to renew certificate. pki-tomcat issue

[Bertrand Rétif]

- Mail original -

> De: "Florence Blanc-Renaud" 
> À: "Bertrand Rétif" , freeipa-users@redhat.com
> Envoyé: Jeudi 20 Octobre 2016 18:45:21
> Objet: Re: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue

> On 10/19/2016 08:18 PM, Bertrand Rétif wrote:
> > *De: *"Bertrand Rétif" 
> >
> > *À: *freeipa-users@redhat.com
> > *Envoyé: *Mercredi 19 Octobre 2016 15:42:07
> > *Objet: *Re: [Freeipa-users] Impossible to renew certificate.
> > pki-tomcat issue
> >
> >
> > 
> >
> > *De: *"Rob Crittenden" 
> > *À: *"Bertrand Rétif" ,
> > freeipa-users@redhat.com
> > *Envoyé: *Mercredi 19 Octobre 2016 15:30:14
> > *Objet: *Re: [Freeipa-users] Impossible to renew certificate.
> > pki-tomcat issue
> >
> > Bertrand Rétif wrote:
> > >> De: "Martin Babinsky" 
> > >> À: freeipa-users@redhat.com
> > >> Envoyé: Mercredi 19 Octobre 2016 08:45:49
> > >> Objet: Re: [Freeipa-users] Impossible to renew certificate.
> > pki-tomcat issue
> > >
> > >> On 10/18/2016 11:22 PM, Bertrand Rétif wrote:
> > >>> Hello,
> > >>>
> > >>> I had an issue with pki-tomcat.
> > >>> I had serveral certificate that was expired and pki-tomcat
> > did not start
> > >>> anymore.
> > >>>
> > >>> I set the dateon the server before certificate expiration
> > and then
> > >>> pki-tomcat starts properly.
> > >>> Then I try to resubmit the certificate, but I get below error:
> > >>> "Profile caServerCert Not Found"
> > >>>
> > >>> Do you have any idea how I could fix this issue.
> > >>>
> > >>> Please find below output of commands:
> > >>>
> > >>>
> > >>> # getcert resubmit -i 20160108170324
> > >>>
> > >>> # getcert list -i 20160108170324
> > >>> Number of certificates and requests being tracked: 7.
> > >>> Request ID '20160108170324':
> > >>> status: MONITORING
> > >>> ca-error: Server at
> > >>> "http://sdkipa01.a.skinfra.eu:8080/ca/ee/ca/profileSubmit;
> > replied:
> > >>> Profile caServerCert Not Found
> > >>> stuck: no
> > >>> key pair storage:
> > >>>
> > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
> > >>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> > >>> certificate:
> > >>>
> > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
> > >>> Certificate DB'
> > >>> CA: dogtag-ipa-ca-renew-agent
> > >>> issuer: CN=Certificate Authority,O=A.SKINFRA.EU
> > >>> subject: CN=IPA RA,O=A.SKINFRA.EU
> > >>> expires: 2016-06-28 15:25:11 UTC
> > >>> key usage:
> > >>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> > >>> eku: id-kp-serverAuth,id-kp-clientAuth
> > >>> pre-save command: /usr/lib64/ipa/certmonger/renew_ra_cert_pre
> > >>> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert
> > >>> track: yes
> > >>> auto-renew: yes
> > >>>
> > >>>
> > >>> Thanksby advance for your help.
> > >>> Bertrand
> > >>>
> > >>>
> > >>>
> > >>>
> > >
> > >> Hi Betrand,
> > >
> > >> what version of FreeIPA and Dogtag are you running?
> > >
> > >> Also perform the following search on the IPA master and post
> > the result:
> > >
> > >> """
> > >> ldapsearch -D "cn=Directory Manager" -W -b
> > >> 'ou=certificateProfiles,ou=ca,o=ipaca'
> > '(objectClass=certProfile)'
> > >> """
> > >
> > > Hi Martin,
> > >
> > > Thanks for your reply.
> > >
> > > Here is version:
> > > - FreeIPA 4.2.0
> > > - Centos 7.2
> > >
> > > I have been able to fix the issue with "Profile caServerCert
> > Not Found" by editing /var/lib/pki/pki-tomcat/ca/conf/CS.cfg
> > > I replace below entry
> > >
> > "subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem"
> > > by
> > > "subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem"
> > >
> > > and then launch "ipa-server-upgrade" command
> > > I found this solution in this post:
> > http://osdir.com/ml/freeipa-users/2016-03/msg00280.html
> > >
> > > Then I was able to renew my certificate.
> > >
> > > However I reboot my server to and pki-tomcat do not start and
> > provide with a new erreor in /var/log/pki/pki-tomcat/ca/debug
> > >
> > > [19/Oct/2016:11:11:52][localhost-startStop-1]: CertUtils:
> > verifySystemCertByNickname() passed: auditSigningCert cert-pki-ca
> > > [19/Oct/2016:11:11:52][localhost-startStop-1]:
> > SignedAuditEventFactory: create()
> > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$
> > > System$][Outcome=Success][CertNickName=auditSigningCert
> > cert-pki-ca] CIMC certificate verification
> > >
> > > java.lang.Exception: SystemCertsVerification: system certs
> > verification failure
> > > at
> > com.netscape.cms.selftests.common.SystemCertsVerification.runSelfTest(SystemCertsVerification.java:198)
> > > at
> > com.netscape.cmscore.selftests.SelfTestSubsystem.runSelfTestsAtStartup(SelfTestSubsystem.java:861)
> > > at
> > com.netscape.cmscore.selftests.SelfTestSubsystem.startup(SelfTestSubsystem.java:1797)
> > > at
> > 

Re: [Freeipa-users] Replica Problem (Errors)

[Günther J . Niederwimmer]

Hello Ludwig,

Thanks for the answer and help,

Am Montag, 24. Oktober 2016, 14:16:23 schrieb Ludwig Krispenz:
> On 10/24/2016 01:21 PM, Günther J. Niederwimmer wrote:
> > 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
> >>> 
> >>> 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

OK.
The first is

ipa-csreplica-manage list
Directory Manager password: 

ipa.example.com: master
ipa1.example.com: master

The second is:
nsDS5ReplicaId: 96
nsds50ruv: {replicageneration} 5706b1a30060
nsds50ruv: {replica 96 ldap://ipa.example.com:389} 5706b1ab0060 
580f6a5f0060
nsds50ruv: {replica 91 ldap://ipa1.example.com:389} 5714ad01005b 
575c65140005005b
nsds50ruv: {replica 97 ldap://ipa1.example.com:389} 5706b1bd0061 
570803a90061

The domain is changed !!
 
> > 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] free-ipa 389 own schema, cos, static and dynamic groups

[Alexander Bokovoy]

On ti, 25 loka 2016, Frank Munsche wrote:

Hi guys,

we are currently evaluating free-ipa. We've used the sun one ds, sun /
oracle dsee and 389 so far. All of those are easy to customize
respective the schema, class of service, dynamic groups,...
Unfortunately most applications like jenkins, jira, confluence, gitblit,
bitbucket, nexus and others don't have a native interface to
authenticate against free-ipa. But most of them can do ldap(s) / tls
and can connect to any ldap server with a proxy user configured. This
way and by using class of service and dynamic groups, we were able to
tie them to the directory and use it for authentication and sometimes
aothorization as well.

Have you checked http://www.freeipa.org/page/HowTos ?



As I've seen so far, the 389 as part of free-ipa is tightly coupled to
the rest of the components and it's schema and dit are structured to
fit the needs of ipa.
Some questions that come into my mind:

Would it be possible to extend the schema and configure the 389 ds for
my own needs?

Everything is possible but you'll be responsible for whatever would be
done.


Could the dit be restructured to match the logic of our
environments?

Most likely no. The flat DIT assumptions and naming of subtrees are
encoded in FreeIPA framework.


I remember the sun idm server which was a pretty complex product but
gave the user lots of possible customizations of the web ui and
included workflows. Is that possible with ipa also?

Read existing documentation.
http://www.freeipa.org/page/HowTo/Add_a_new_attribute
http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf
and overall links under http://www.freeipa.org/page/Documentation

--
/ 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] free-ipa 389 own schema, cos, static and dynamic groups

[Simo Sorce]

On Tue, 2016-10-25 at 15:49 +0200, Frank Munsche wrote:
> Hi guys,
> 
> we are currently evaluating free-ipa. We've used the sun one ds, sun /
> oracle dsee and 389 so far. All of those are easy to customize
> respective the schema, class of service, dynamic groups,... 
> Unfortunately most applications like jenkins, jira, confluence, gitblit,
> bitbucket, nexus and others don't have a native interface to
> authenticate against free-ipa. But most of them can do ldap(s) / tls
> and can connect to any ldap server with a proxy user configured. This
> way and by using class of service and dynamic groups, we were able to
> tie them to the directory and use it for authentication and sometimes
> aothorization as well. 
> As I've seen so far, the 389 as part of free-ipa is tightly coupled to
> the rest of the components and it's schema and dit are structured to
> fit the needs of ipa. 
> Some questions that come into my mind:
> 
> Would it be possible to extend the schema and configure the 389 ds for
> my own needs?

Yes, the schema can be extended.

> Could the dit be restructured to match the logic of our
> environments?

No, but we have a compat tree that can be used with clients that insist
on using other "views" of the directory. The compat tree carries
performance penalties and is not easy to change dramatically, but it is
a possible way to go.

> I remember the sun idm server which was a pretty complex product but
> gave the user lots of possible customizations of the web ui and
> included workflows. Is that possible with ipa also?

With the latest FreeIPA versions it is possible to write plugins to
extend the Web UI, we are working on making it more straightforward, but
it has been done already.

> thank you very much,

HTH,
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] PWM password self-service integration with FreeIPA

[Simo Sorce]

On Sun, 2016-10-23 at 12:22 -0500, Elwell, Jason wrote:
> I posted this on the PWM boards, and figured I'd send this along here,
> too.  I'm looking for feedback on this.  Let me know if you find this
> accurate and/or valuable.  Thanks!
> 
> 
> PWM setup for FreeIPA
> https://gist.github.com/PowerWagon/d794a1233d7943f1614d2ae5223e678a
> 
> PwmConfiguration-template.xml
> https://gist.github.com/PowerWagon/0e83a0c5b67316a6987944b76eb103bc

Jason,
It seems to me your ACIs are too lax, you should also make the PWM user
a password synchronization agent and not just give it blanket access to
read everything from the directory and write every password, you should
limit it to users for example and not allow it to change service's or
host's "passwords".

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

[Freeipa-users] Is this a bigger Problem DNSSEC ?

[Günther J . Niederwimmer]

Hello,

FreeIPA 4.3.1
CentOS 7.2


I found today in /var/log/messages this entries 

Is the DNSSEC now broken ?

Thanks for a answer

ct 25 15:41:29 ipa ipa-dnskeysyncd: Traceback (most recent call last):
Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/libexec/ipa/ipa-dnskeysyncd", 
line 112, in 
Oct 25 15:41:29 ipa ipa-dnskeysyncd: while 
ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):
Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib64/python2.7/site-
packages/ldap/syncrepl.py", line 405, in syncrepl_poll
Oct 25 15:41:29 ipa ipa-dnskeysyncd: self.syncrepl_refreshdone()
Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib/python2.7/site-
packages/ipapython/dnssec/keysyncer.py", line 118, in syncrepl_refreshdone
Oct 25 15:41:29 ipa ipa-dnskeysyncd: self.bindmgr.sync(self.dnssec_zones)
Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib/python2.7/site-
packages/ipapython/dnssec/bindmgr.py", line 209, in sync
Oct 25 15:41:29 ipa ipa-dnskeysyncd: self.sync_zone(zone)
Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib/python2.7/site-
packages/ipapython/dnssec/bindmgr.py", line 182, in sync_zone
Oct 25 15:41:29 ipa ipa-dnskeysyncd: self.install_key(zone, uuid, attrs, 
tempdir)
Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib/python2.7/site-
packages/ipapython/dnssec/bindmgr.py", line 117, in install_key
Oct 25 15:41:29 ipa ipa-dnskeysyncd: result = ipautil.run(cmd, 
capture_output=True)
Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib/python2.7/site-
packages/ipapython/ipautil.py", line 479, in run
Oct 25 15:41:29 ipa ipa-dnskeysyncd: raise CalledProcessError(p.returncode, 
arg_string, str(output))
Oct 25 15:41:29 ipa ipa-dnskeysyncd: subprocess.CalledProcessError: Command 
'/usr/sbin/dnssec-keyfromlabel-pkcs11 -K /var/named/dyndb-
ldap/ipa/master/4gjn.com/tmppaO_R2 -a RSASHA256 -l 
pkcs11:object=d7fe5c98d5f3f89aefb9e8dfb92ebcb1;pin-
source=/var/lib/ipa/dnssec/softhsm_pin -I 20160811091542 -D 20160825225503 -P 
20160513081600 -A 20160513081600 4gjn.com.' returned non-zero exit status 1
Oct 25 15:41:30 ipa systemd: ipa-dnskeysyncd.service: main process exited, 
code=exited, status=1/FAILURE
Oct 25 15:41:30 ipa systemd: Unit ipa-dnskeysyncd.service entered failed 
state.
Oct 25 15:41:30 ipa systemd: ipa-dnskeysyncd.service failed.

-- 
mit freundlichen Grüßen / best regards,

  Günther J. Niederwimmer

-- 
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] free-ipa 389 own schema, cos, static and dynamic groups

[Frank Munsche]

Hi guys,

we are currently evaluating free-ipa. We've used the sun one ds, sun /
oracle dsee and 389 so far. All of those are easy to customize
respective the schema, class of service, dynamic groups,... 
Unfortunately most applications like jenkins, jira, confluence, gitblit,
bitbucket, nexus and others don't have a native interface to
authenticate against free-ipa. But most of them can do ldap(s) / tls
and can connect to any ldap server with a proxy user configured. This
way and by using class of service and dynamic groups, we were able to
tie them to the directory and use it for authentication and sometimes
aothorization as well. 
As I've seen so far, the 389 as part of free-ipa is tightly coupled to
the rest of the components and it's schema and dit are structured to
fit the needs of ipa. 
Some questions that come into my mind:

Would it be possible to extend the schema and configure the 389 ds for
my own needs?

Could the dit be restructured to match the logic of our
environments?

I remember the sun idm server which was a pretty complex product but
gave the user lots of possible customizations of the web ui and
included workflows. Is that possible with ipa also?


thank you very much,


cheers, Frank

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

[Simo Sorce]

On Tue, 2016-10-25 at 09:02 +0300, Alexander Bokovoy wrote:
> On ti, 25 loka 2016, Fraser Tweedale wrote:
> >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 

Re: [Freeipa-users] Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired)

[bahan w]

Re.

There is no time difference between client and server.

I checked the httpd error log and saw no errors.
Same with the dirsrv error logs.

Any other idea ?

By looking at the  log, I'm wondering if this is a question of session ?

See there :
###
ipa: DEBUG: args=keyctl pipe 44063864
ipa: DEBUG: stdout=ipa_session=26a7252e4853374fc7439eae5926c584;
Domain=; Path=/ipa; Expires=Tue, 25 Oct 2016 08:15:09 GMT;
Secure; HttpOnly
ipa: DEBUG: stderr=
ipa: DEBUG: found session_cookie in persistent storage for principal
'@', cookie: 'ipa_session=26a7252e4853374fc7439eae5926c584;
Domain=; Path=/ipa; Expires=Tue, 25 Oct 2016 08:15:09 GMT;
Secure; HttpOnly'
ipa: DEBUG: setting session_cookie into context 'ipa_session=
26a7252e4853374fc7439eae5926c584;'
###

At that time, it was not yet expired but there was only a few minuts before
expiration (something like 10 minuts).
What is this persistent storage which is mentioned in the logs ?

Best regards.

Bahan



On Tue, Oct 25, 2016 at 12:18 PM, Martin Babinsky 
wrote:

> On 10/25/2016 10:27 AM, bahan w wrote:
>
>> Hello everyone !
>>
>> I have an ipa server and an ipa client both in 3.0.0-47.
>>
>> In order to connect via SSH to the host of the ipa-client, I use root.
>> When I'm connected to the ipa-client via ssh being root, I do a kinit of
>> a user with a keytab :
>> ###
>> kinit -kt /etc/security/keytabs/.headless.keytab 
>> ###
>>
>> And sometimes, once I have the TGT, when I do just an ipa user-show, I
>> got the following error :
>> ###
>> ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI
>> Error: Unspecified GSS failure.  Minor code may provide more information
>> (Ticket expired)
>> ###
>>
>> When I check the ticket, it is not expired :
>> ###
>> # klist
>> Ticket cache: FILE:/tmp/krb5cc_root_
>> Default principal: @
>>
>> Valid starting ExpiresService principal
>> 10/25/16 10:00:44  10/26/16 10:00:44  krbtgt/@
>> ###
>>
>> Do you know from where it can come and how I can solve this error please ?
>>
>> Here is more information with the debug option :
>> ###
>> ipa -d user-show 
>> ###
>>
>> Result :
>> ###
>> ipa: DEBUG: importing all plugin modules in
>> '/usr/lib/python2.6/site-packages/ipalib/plugins'...
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/permission.py'
>> ipa: DEBUG: importing plugin module
>> '/usr/lib/python2.6/site-packages/ipalib/plugins/ping.py'
>> ipa: DEBUG: importing plugin module
>> 

Re: [Freeipa-users] Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired)

[Martin Babinsky]

On 10/25/2016 10:27 AM, bahan w wrote:

Hello everyone !

I have an ipa server and an ipa client both in 3.0.0-47.

In order to connect via SSH to the host of the ipa-client, I use root.
When I'm connected to the ipa-client via ssh being root, I do a kinit of
a user with a keytab :
###
kinit -kt /etc/security/keytabs/.headless.keytab 
###

And sometimes, once I have the TGT, when I do just an ipa user-show, I
got the following error :
###
ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI
Error: Unspecified GSS failure.  Minor code may provide more information
(Ticket expired)
###

When I check the ticket, it is not expired :
###
# klist
Ticket cache: FILE:/tmp/krb5cc_root_
Default principal: @

Valid starting ExpiresService principal
10/25/16 10:00:44  10/26/16 10:00:44  krbtgt/@
###

Do you know from where it can come and how I can solve this error please ?

Here is more information with the debug option :
###
ipa -d user-show 
###

Result :
###
ipa: DEBUG: importing all plugin modules in
'/usr/lib/python2.6/site-packages/ipalib/plugins'...
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/config.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/group.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/host.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/permission.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/ping.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/privilege.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py'
ipa: DEBUG: args=klist -V
ipa: DEBUG: stdout=Kerberos 5 version 1.10.3

ipa: DEBUG: stderr=
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/role.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/service.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/user.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py'
ipa: DEBUG: 

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

[Brian Candler]

On 25/10/2016 10:50, Prasun Gera wrote:
When is principal expiration triggered ? I haven't set it explicitly 
for any user, and ipa user-show doesn't show that attribute either. 
I'm not very familiar with kerberos. 

It doesn't show it unless it has been set. You can set it like this:

# ipa help user-mod
...
  --principal-expiration=DATETIME
Kerberos principal expiration

(This is from IPA under CentOS 7. Older versions might not have this 
feature at all).


And as you and David said earlier, if the principal expires, kinit 
shouldn't work either, right ?


Yes I agree. I have just tried setting krbPasswordExpiration to a very 
old time, using ldapmodify.


# ldapmodify -D 'cn=Directory Manager' -W
Enter LDAP Password:
dn: uid=bcandler,cn=users,cn=accounts,dc=ipa,dc=example,dc=com
changetype: modify
replace: krbPasswordExpiration
krbPasswordExpiration: 2001010100Z
-

^D

But this works for me:

$ sudo -s

[sudo] password for bcandler:
Password expired. Change your password now.
sudo: Account or password is expired, reset your password and try again
Current Password:
New password:
Retype new password:

#


But actually, I didn't try the web UI with an expired password yet. I'll 
try that later.


Regards,

Brian.

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

[Rob Crittenden]

David Kupka wrote:

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!


And this is sort of reinventing the wheel. certmonger uses the API already.

Have you tried building certmonger on BSD? It should be pretty portable 
C code, it just might require installing additional dependencies like 
libcurl (with GSSAPI support) and probably a few others.


You'd also need to manually configure Kerberos, get a keytab for it and 
create a basic /etc/ipa/default.conf.


rob
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] Do expired passwords remain usable indefinitely?

[Prasun Gera]

>
> There appears to be only one case where NAME_EXP is returned: when the
> client.expiration field is passed (not client.pw_expiration)
>
> I think "expiration" must equate to the "principal expiration" in IPA. But
> only regular password expiry would give you the option of changing it.
>
>
Thanks Brian. Can you explain a bit more ? When is principal expiration
triggered ? I haven't set it explicitly for any user, and ipa user-show
doesn't show that attribute either. I'm not very familiar with kerberos.
And as you and David said earlier, if the principal expires, kinit
shouldn't work either, right ?



> Regards,
>
> Brian.
>
> === from src/kdc/kdc_util. c ===
>
> /* The client must not be expired */
> if (client.expiration && client.expiration < kdc_time) {
> *status = "CLIENT EXPIRED";
> if (vague_errors)
> return(KRB_ERR_GENERIC);
> else
> return(KDC_ERR_NAME_EXP);
> }
>
> /* The client's password must not be expired, unless the server is
>a KRB5_KDC_PWCHANGE_SERVICE. */
> if (client.pw_expiration && client.pw_expiration < kdc_time &&
> !isflagset(server.attributes, KRB5_KDB_PWCHANGE_SERVICE)) {
> *status = "CLIENT KEY EXPIRED";
> if (vague_errors)
> return(KRB_ERR_GENERIC);
> else
> return(KDC_ERR_KEY_EXP);
> }
>
-- 
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] Do expired passwords remain usable indefinitely?

[Brian Candler]

Looking in MIT krb5 source:

$ grep -R ERR_NAME_EXP .
./src/include/k5-int.h:#define KDC_ERR_NAME_EXP1 /* 
Client's entry in DB expired */

./src/kdc/kdc_util.c:return(KDC_ERR_NAME_EXP);
./src/lib/krb5/error_tables/krb5_err.et:error_code 
KRB5KDC_ERR_NAME_EXP,"Client's entry in database has expired"


There appears to be only one case where NAME_EXP is returned: when the 
client.expiration field is passed (not client.pw_expiration)


The fields are defined in krb5_db_entry in src/include/kdb.h:

krb5_timestampexpiration;   /* When the client 
expires */
krb5_timestamppw_expiration;/* When its passwd 
expires */


I think "expiration" must equate to the "principal expiration" in IPA. 
But only regular password expiry would give you the option of changing it.


Regards,

Brian.

=== from src/kdc/kdc_util. c ===

/* The client must not be expired */
if (client.expiration && client.expiration < kdc_time) {
*status = "CLIENT EXPIRED";
if (vague_errors)
return(KRB_ERR_GENERIC);
else
return(KDC_ERR_NAME_EXP);
}

/* The client's password must not be expired, unless the server is
   a KRB5_KDC_PWCHANGE_SERVICE. */
if (client.pw_expiration && client.pw_expiration < kdc_time &&
!isflagset(server.attributes, KRB5_KDB_PWCHANGE_SERVICE)) {
*status = "CLIENT KEY EXPIRED";
if (vague_errors)
return(KRB_ERR_GENERIC);
else
return(KDC_ERR_KEY_EXP);
}

--
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] Do expired passwords remain usable indefinitely?

[Prasun Gera]

David & Brian,
I'm familiar with the usual password expiration message that shows up which
forces you to change the password. I've seen that before. However, I didn't
see it this time, which is odd. Since I was able to kinit, I reset the
password, and it started working again. I don't have an account in this
failed state currently, but is it possible to force password expiration in
order to reproduce this again ? Something like "ipa user-mod myuser
--setattr=krbpasswordexpiration=" should work, right ?

On Tue, Oct 25, 2016 at 3:54 AM, Brian Candler  wrote:

> On 25/10/2016 00:02, Prasun Gera wrote:
>
> 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.
>
> By "account expiration" do you mean the "--principal-expiration" option to
> ipa user-xxx? Or is there another setting?
> Code 13 is PAM_ACCT_EXPIRED, at least in the "new" constants
>
> $ egrep '\b13\b' /usr/include/security/*pam*
> /usr/include/security/_pam_compat.h:# define PAM_USER_UNKNOWN
> 13
> /usr/include/security/_pam_types.h:#define PAM_ACCT_EXPIRED 13/* User
> account has expired */
> /usr/include/security/_pam_types.h:#define PAM_AUTHTOK_TYPE   13   /* The
> type for pam_get_authtok */
>
> This to me implies it's not looking at the krbPasswordExpiration
> attribute, because it could (or should) use PAM_AUTHTOK_EXPIRED (27) for
> that instead.
>
> For me, pam_sss seems to handle expiry correctly. For example if I reset
> an account password (which in turn causes it to expire immediately), and
> then someone logs in their ssh private key, and subsequently does "sudo",
> sudo prompts them for the password, tells them it has expired, but gives
> them the opportunity to change it.
>
> However it's not impossible that the PAM module has some buried logic,
> e.g. it refuses to use a password which expired more than X days ago. That
> was the reason for my original question.  I guess I should try setting some
> expiry date way in the past.
>
> The other thing is to look in the source code for pam_sss to see under
> which conditions it returns PAM_ACCT_EXPIRED.  The answer is: when it gets
> ERR_ACCOUNT_EXPIRED from parse_krb5_child_response. Which in turn is when
> we get KRB5KDC_ERR_NAME_EXP from Kerberos. Which in turn is "Client's entry
> in database has expired".
>
> http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-
> admin/Kerberos-V5-Library-Error-Codes.html
>
> But as has already been said - if the *principal* has expired you
> shouldn't be able to login with kinit at all.
>
> Regards,
>
> Brian.
>
-- 
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] Do expired passwords remain usable indefinitely?

[Brian Candler]

On 25/10/2016 08:29, David Kupka wrote:
If I understood Brian correctly he was asking about expiration of NTLM 
password hashes.


Partly.

As long as the hash remains in the database and is readable via LDAP, I 
know it will continue to work for authentication.  However I was also 
asking whether a long-expired password would prevent a user from logging 
into the webUI or obtaining a kerberos ticket.


Scenario is: a user who is mostly wireless-only, who very rarely uses 
IPA for anything else. Their password expires, and they never notice 
because it keeps working. However, (say) a year later, they decide to 
login to IPA for some reason - maybe because they've decided it's time 
to change their wireless password.  Will their old expired password 
still be usable for this?  I'm hoping it would simply tell them that the 
account has expired and force a password change.


Aside: I realise there are other ways I can handle this. Perhaps I 
*should* make passwords expire for wireless too, by checking the 
krbPasswordExpiration field in the RADIUS server. But then I need some 
way to warn people that their passwords are about to expire and give 
them an opportunity to change it - e.g. by mailing out a warning a 
couple of weeks before it does.


Regards,

Brian.

--
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] Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired)

[bahan w]

Hello everyone !

I have an ipa server and an ipa client both in 3.0.0-47.

In order to connect via SSH to the host of the ipa-client, I use root.
When I'm connected to the ipa-client via ssh being root, I do a kinit of a
user with a keytab :
###
kinit -kt /etc/security/keytabs/.headless.keytab 
###

And sometimes, once I have the TGT, when I do just an ipa user-show, I got
the following error :
###
ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure.  Minor code may provide more information (Ticket
expired)
###

When I check the ticket, it is not expired :
###
# klist
Ticket cache: FILE:/tmp/krb5cc_root_
Default principal: @

Valid starting ExpiresService principal
10/25/16 10:00:44  10/26/16 10:00:44  krbtgt/@
###

Do you know from where it can come and how I can solve this error please ?

Here is more information with the debug option :
###
ipa -d user-show 
###

Result :
###
ipa: DEBUG: importing all plugin modules in
'/usr/lib/python2.6/site-packages/ipalib/plugins'...
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/config.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/group.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/host.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/permission.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/ping.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/privilege.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py'
ipa: DEBUG: args=klist -V
ipa: DEBUG: stdout=Kerberos 5 version 1.10.3

ipa: DEBUG: stderr=
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/role.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/service.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/user.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py'
ipa: DEBUG: args=keyctl search @s user 

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

[Brian Candler]

On 25/10/2016 00:02, Prasun Gera wrote:
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.


By "account expiration" do you mean the "--principal-expiration" option 
to ipa user-xxx? Or is there another setting?


Code 13 is PAM_ACCT_EXPIRED, at least in the "new" constants

$ egrep '\b13\b' /usr/include/security/*pam*
/usr/include/security/_pam_compat.h:# define PAM_USER_UNKNOWN 13
/usr/include/security/_pam_types.h:#define PAM_ACCT_EXPIRED 13/* 
User account has expired */
/usr/include/security/_pam_types.h:#define PAM_AUTHTOK_TYPE   13 /* The 
type for pam_get_authtok */


This to me implies it's not looking at the krbPasswordExpiration 
attribute, because it could (or should) use PAM_AUTHTOK_EXPIRED (27) for 
that instead.


For me, pam_sss seems to handle expiry correctly. For example if I reset 
an account password (which in turn causes it to expire immediately), and 
then someone logs in their ssh private key, and subsequently does 
"sudo", sudo prompts them for the password, tells them it has expired, 
but gives them the opportunity to change it.


However it's not impossible that the PAM module has some buried logic, 
e.g. it refuses to use a password which expired more than X days ago. 
That was the reason for my original question.  I guess I should try 
setting some expiry date way in the past.


The other thing is to look in the source code for pam_sss to see under 
which conditions it returns PAM_ACCT_EXPIRED.  The answer is: when it 
gets ERR_ACCOUNT_EXPIRED from parse_krb5_child_response. Which in turn 
is when we get KRB5KDC_ERR_NAME_EXP from Kerberos. Which in turn is 
"Client's entry in database has expired".


http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Kerberos-V5-Library-Error-Codes.html

But as has already been said - if the *principal* has expired you 
shouldn't be able to login with kinit at all.


Regards,

Brian.

-- 
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] Do expired passwords remain usable indefinitely?

[David Kupka]

On 25/10/16 01:02, Prasun Gera wrote:

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





Hello Prasun!
If I understood Brian correctly he was asking about expiration of NTLM 
password hashes. In his case there is no checking for password or 
account expiration. It would need to be done in RADIUS server itself 
because RADIUS server just fetches the attributes from LDAP and does 
whatever it is programmed to do.


The situation that you're describing looks weird to me. When user's 
Kerberos Password expires kinit and WebUI forces password change on next 
login attempt. I don't know how ssh client behaves.


When user's Kerberos Principal ("account") expires neither WebUI nor 
kinit would allow login or password change. Administrator must prolong 
or remove the Kerberos Principal expiration.


By default Kerberos Password expiration is set according relevant to 
password policy (global_policy by default) and Kerberos Principal 
expiration is not set.


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

[Alexander Bokovoy]

On ti, 25 loka 2016, Fraser Tweedale wrote:

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

Sounds reasonable for me, thanks.
--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to