Re: [Freeipa-users] Replica issue / Certificate Authority

[Fraser Tweedale]

On Fri, Dec 16, 2016 at 05:29:18PM -0500, Rob Crittenden wrote:
> Christopher Young wrote:
> > Ok.  I think I have a 'hint' here, but I could use some help getting this 
> > fixed.
> > 
> > Comparing the two IPA servers, I found the following (modified SOME of
> > the output myself):
> 
> You're right about the ipaCert. I'd export the renewed cert from your
> working server using the same certutil command, just direct it to a file
> instead. Then import it into the non-working server and restart the
> httpd service. That should do it.
> 
I agree that this should fix it.

You could also try running `ipa-certupdate' as root, if the correct
certificate is to be found in cn=certificates,cn=ipa,cn=etc,{basedn}

Once everything is working again, you should check:

1. renewal master configuration is correct

2. certmonger tracking requests for the IPA RA cert are correct on
   both servers

3. the correct certificate is in
   cn=certificates,cn=ipa,cn=etc,{basedn}

Thanks,
Fraser

> Or you can try restarting certmonger on the non-working server to see if
>
> that triggers it to pull in the updated cert. Theoretically this should
> do it as well but given potential past replication problems it is
> possible the entry doesn't exist.
> 
> getcert list -n ipaCert on each will show some basic information. The
> important thing is to see if there is some root cause that will make
> this blow up again at renewal time.
> 
> rob
> 
> > 
> > on 'ipa02' (the 'good' one):
> > -
> > ipa cert-show 1
> >   Issuing CA: ipa
> >   Certificate: <<>>
> >   Subject: CN=Certificate Authority,O=.LOCAL
> >   Issuer: CN=Certificate Authority,O=.LOCAL
> >   Not Before: Thu Jan 01 06:23:38 2015 UTC
> >   Not After: Mon Jan 01 06:23:38 2035 UTC
> >   Fingerprint (MD5): a6:aa:88:d4:66:e2:70:c1:e3:8c:37:0b:f3:eb:19:7d
> >   Fingerprint (SHA1):
> > 11:c2:5a:58:bc:77:55:37:39:9b:13:b1:1a:a2:02:50:be:2e:a0:7f
> >   Serial number: 1
> >   Serial number (hex): 0x1
> >   Revoked: False
> > --
> > 
> > 
> > on 'ipa01'
> > -
> > ipa cert-show 1
> > ipa: ERROR: Certificate operation cannot be completed: EXCEPTION
> > (Invalid Credential.)
> > -
> > 
> > Thinking about this, I decided to just start checking for
> > inconsistencies and I noticed the following:
> > 
> > ipa02:
> > ---
> > [root@ipa02 ~]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a |
> > openssl x509 -text  | head
> > Certificate:
> > Data:
> > Version: 3 (0x2)
> > Serial Number: 268304413 (0xffe001d)
> > Signature Algorithm: sha256WithRSAEncryption
> > Issuer: O=x.LOCAL, CN=Certificate Authority
> > Validity
> > Not Before: Nov 23 18:19:31 2016 GMT
> > Not After : Nov 13 18:19:31 2018 GMT
> > Subject: O=x.LOCAL, CN=IPA RA
> > 
> > --
> > ipa01:
> > --
> > [root@ipa01 tmp]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a |
> > openssl x509 -text  | head
> > Certificate:
> > Data:
> > Version: 3 (0x2)
> > Serial Number: 7 (0x7)
> > Signature Algorithm: sha256WithRSAEncryption
> > Issuer: O=.LOCAL, CN=Certificate Authority
> > Validity
> > Not Before: Jan  1 06:24:23 2015 GMT
> > Not After : Dec 21 06:24:23 2016 GMT
> > Subject: O=.LOCAL, CN=IPA RA
> > 
> > --
> > 
> > So, it looks like somewhere in the process, the certificate got
> > renewed but not updated on 'ipa01'?  I apologize as I'm trying to
> > understand this.  I believe that my end goal is probably still the
> > same (verify replication and get things working properly on the
> > 'ipa01' system.
> > 
> > Any help is very much appreciated!
> > 
> > -- Chris
> > 
> > 
> > On Fri, Dec 16, 2016 at 3:35 PM, Christopher Young
> >  wrote:
> >> I'm hoping to provide enough information to get some help to a very
> >> important issue that I'm currently having.
> >>
> >> I have two IPA servers at a single location that recently had a
> >> replication issue that I eventually resolved by reinitializing one of
> >> the masters/replicas with one that seemed to be the most 'good'.
> >>
> >> In any case, somewhere in this process, the new IPA 4.4 was release
> >> with/for CentOS 7.3.
> >>
> >> At this moment, regular replication seems to be working properly (in
> >> that I don't have any obvious issues and web interfaces on both
> >> systems seem to be consistent for updates EXCEPT when it comes to the
> >> certificates).
> >>
> >> Before I get to the errors, here is the output of some of the commands
> >> that I would expect anyone would need:
> >>
> >> --
> >> [root@ipa01 ~]# ipa-replica-manage list
> >> ipa01.passur.local: master
> >> ipa02.passur.local: master
> >> -
> >> [root@ipa01 ~]# ipa-replica-manage list -v ipa01.passur.local
> >> ipa02.passur.local: replica
> >>   last init status: None
> >>   last init ended: 1970-01-01 00:00:00+00:00
> >>   last update status: Error (0) Replica 

Re: [Freeipa-users] How to implement sudo rules

[Jakub Hrozek]

I hope this helps pinpoint the issue:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO 


> On 18 Dec 2016, at 10:04, Ben .T.George  wrote:
> 
> Hi List,
> 
> please help me to implement sudo rules.
> 
> i have did below steps and still not working for me.
> 
> 1. created "Sudo Command Groups"
> 2. Added some command (/bin/yum) and included in sudo group
> 3. created "sudo Rule" on that
> * added sudo Option as "!authenticate"
>   * Added User Group.
>   * Added one Host
>   * And under Run command, selected the Sudo Rule Group.
> 
> I tried logout and login again on client with IPA user which is member of 
> user group. 
> 
> When i am running yum, getting error that user is not allowed to execute 
> command.
> 
> 
> Please anyone help to correct my steps.
> 
> Regards
> Ben
> -- 
> 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] Valid Sender ? - Re: ipa-otpd: timeout from kerberos when talking to an external 'slow' RADIUS server

[Alexander Bokovoy]

On su, 18 joulu 2016, Jochen Hein wrote:

Alexander Bokovoy  writes:


So I've added the following to /var/kerberos/krb5kdc/kdc.conf and restarted kdc:

,
| [otp]
|  DEFAULT = {
|   timeout = 15
|   retries = 0
|   strip_realm = false
|  }
`

After that I can use my OTP tokens without problems. With the default
timeout of five seconds I had to have luck to get an authentication
back.  Would it be possible to raise the timeout to 10 seconds as a
default?  That sould work for me too.

Is there a better way to add my configuration to kdc.conf, so it will
survive upgrades?  I didn't find any obvious place, nor some place where
something for ipa-otp had been configured.



You don't state which FreeIPA version you are using: distribution,
package version, etc. There was a bug fixed in RHEL 7.3 / Fedora 25
about timeouts in OTP handling both in MIT Kerberos and FreeIPA's
ipa-otpd daemon.


I'm running my old master on Fedora 24
(freeipa-server-4.3.2-2.fc24.x86_64) and the new on CentOS 7.3
(ipa-server-4.4.0-14.el7.centos.x86_64). I've seen the bugs and checked
in CentOS git that the fix is in the package. And beside the timeout it
now seems to work.

We have two timeouts to consider:

1. KDC to ipa-otd: this can be changed in
/var/kerberos/krb5kdc/kdc.conf. I think the timeout should be larger
then the (largest) second timeout - and I think retries=0 is best.
This is for communication between KDC and ipa-otd.

2. There is a timeout in each RADIUS server config in IPA for the
communication from ipa-otp to external RADIUS servers:
,
| [root@freeipa krb5kdc]# ipa radiusproxy-find
| -
| 1 RADIUS proxy server matched
| -
|   RADIUS proxy server name: athene
|   Server: athene.jochen.org
|   Timeout: 10
|   Retries: 0
|   User attribute: User-Name
| -
| Anzahl der zurückgegebenen Einträge 1
| -
`
Again I think that for OTPs we are probably best with retries=0.

On older clients it might be helpful to add "udp_preference_limit = 0"
to /etc/krb5.conf - at least on my Debian/Ubuntu machines.

Ok. It would probably make sense to file a ticket to FreeIPA tracker to
get these changes in FreeIPA 4.5.

--
/ 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] Valid Sender ? - Re: ipa-otpd: timeout from kerberos when talking to an external 'slow' RADIUS server

[Jochen Hein]

Alexander Bokovoy  writes:

>>So I've added the following to /var/kerberos/krb5kdc/kdc.conf and restarted 
>>kdc:
>>
>>,
>>| [otp]
>>|  DEFAULT = {
>>|   timeout = 15
>>|   retries = 0
>>|   strip_realm = false
>>|  }
>>`
>>
>>After that I can use my OTP tokens without problems. With the default
>>timeout of five seconds I had to have luck to get an authentication
>>back.  Would it be possible to raise the timeout to 10 seconds as a
>>default?  That sould work for me too.
>>
>>Is there a better way to add my configuration to kdc.conf, so it will
>>survive upgrades?  I didn't find any obvious place, nor some place where
>>something for ipa-otp had been configured.

> You don't state which FreeIPA version you are using: distribution,
> package version, etc. There was a bug fixed in RHEL 7.3 / Fedora 25
> about timeouts in OTP handling both in MIT Kerberos and FreeIPA's
> ipa-otpd daemon.

I'm running my old master on Fedora 24
(freeipa-server-4.3.2-2.fc24.x86_64) and the new on CentOS 7.3
(ipa-server-4.4.0-14.el7.centos.x86_64). I've seen the bugs and checked
in CentOS git that the fix is in the package. And beside the timeout it
now seems to work.

We have two timeouts to consider:

1. KDC to ipa-otd: this can be changed in
/var/kerberos/krb5kdc/kdc.conf. I think the timeout should be larger
then the (largest) second timeout - and I think retries=0 is best.
This is for communication between KDC and ipa-otd.

2. There is a timeout in each RADIUS server config in IPA for the
communication from ipa-otp to external RADIUS servers:
,
| [root@freeipa krb5kdc]# ipa radiusproxy-find
| -
| 1 RADIUS proxy server matched
| -
|   RADIUS proxy server name: athene
|   Server: athene.jochen.org
|   Timeout: 10
|   Retries: 0
|   User attribute: User-Name
| -
| Anzahl der zurückgegebenen Einträge 1
| -
`
Again I think that for OTPs we are probably best with retries=0.

On older clients it might be helpful to add "udp_preference_limit = 0"
to /etc/krb5.conf - at least on my Debian/Ubuntu machines.

Jochen

-- 
The only problem with troubleshooting is that the trouble shoots back.

-- 
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-otpd: timeout from kerberos when talking to an external 'slow' RADIUS server

[Alexander Bokovoy]

On la, 17 joulu 2016, Jochen Hein wrote:


I'm running a privacyidea server, which has my tokens and provides
external RADIUS access for other services like FreeIPA.  When a user
authenticates I have the following communications:

1. IPA Client -> IPA server (Kerberos)
2. IPA Server (kdc) -> ipa-otpd (internal radius) [*]
3. ipa-otpd -> FreeRADIUS for privacyidea
4. FreeRADIUS -> privacyidea (OTP-PIN/yubikey OTP)
5. privacyidea -> privacyidea (yubico validation server)

[*] Here is where the trouble starts: Since we have a couple of TCP/IP
sessions with SSL handshakes it takes a couple of seconds (mostly 6-8
seconds) to establish communication and get the answer from privacyidea
back.

man kdc.conf has:
,
|[otp]
|   timeout   An integer which specifies the time in seconds
| during which the KDC should attempt to contact the
| RADIUS server.  This tag is the total time across
| all retries and should be less than the time which
| an OTP value remains valid for.  The default is 5
| seconds.
|
|retries  This tag specifies the number of retries to make to
| the RADIUS server.  The default is 3 retries (4
| tries).
`

So I've added the following to /var/kerberos/krb5kdc/kdc.conf and restarted kdc:

,
| [otp]
|  DEFAULT = {
|   timeout = 15
|   retries = 0
|   strip_realm = false
|  }
`

After that I can use my OTP tokens without problems. With the default
timeout of five seconds I had to have luck to get an authentication
back.  Would it be possible to raise the timeout to 10 seconds as a
default?  That sould work for me too.

Is there a better way to add my configuration to kdc.conf, so it will
survive upgrades?  I didn't find any obvious place, nor some place where
something for ipa-otp had been configured.

You don't state which FreeIPA version you are using: distribution,
package version, etc. There was a bug fixed in RHEL 7.3 / Fedora 25
about timeouts in OTP handling both in MIT Kerberos and FreeIPA's
ipa-otpd daemon.
--
/ 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] How to implement sudo rules

[Ben .T.George]

Hi List,

please help me to implement sudo rules.

i have did below steps and still not working for me.

1. created "Sudo Command Groups"
2. Added some command (/bin/yum) and included in sudo group
3. created "sudo Rule" on that
* added sudo Option as "!authenticate"
  * Added User Group.
  * Added one Host
  * And under Run command, selected the Sudo Rule Group.

I tried logout and login again on client with IPA user which is member of
user group.

When i am running yum, getting error that user is not allowed to execute
command.


Please anyone help to correct my steps.

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