Re: [Freeipa-users] FreeOTP

[Nathaniel McCallum]

https://bodhi.fedoraproject.org/updates/FEDORA-2016-0b966047e1

Please test and provide your feedback.

On Wed, 2016-06-22 at 13:21 +0200, Winfried de Heiden wrote:
> Hi all,
> Great news, can't wait for it to be available in Fedora ARM en test.
> Winny
> 
> Op 21-06-16 om 22:23 schreef Nathaniel McCallum:
> > I have found and fixed what I believe to be the issue. I have
> > submitted
> > a patch upstream for review: https://github.com/krb5/krb5/pull/471
> > 
> > Once merged, we will backport the fix into all existing Fedora
> > releases. So you should get an update via a simple: dnf update.
> > 
> > On Thu, 2016-06-16 at 10:28 +0200, Winfried de Heiden wrote:
> > > Hi all,
> > > 
> > > "So it looks a bit like a libverto 32bit issue"; any news or
> > > progress
> > > on 
> > > this? Bugzilla?
> > > 
> > > Winny
> > > 
> > > 
> > > Op 09-06-16 om 18:51 schreef Sumit Bose:
> > > > On Thu, Jun 09, 2016 at 08:42:59AM -0400, Nathaniel McCallum
> > > > wrote:
> > > > > On Thu, 2016-06-09 at 10:46 +0200, Sumit Bose wrote:
> > > > > > On Thu, Jun 09, 2016 at 08:16:13AM +0200, Winfried de
> > > > > > Heiden
> > > > > > wrote:
> > > > > > > Hi all,
> > > > > > > 
> > > > > > > I can install libvert-libev but removing libverto-tevent
> > > > > > > will
> > > > > > > remove 123
> > > > > > > dependencies also. (wget, tomcat and much more...)
> > > > > > > 
> > > > > > > Hence, I installed libverto-libev, but dit not remove
> > > > > > > libverto-
> > > > > > > tevent to give
> > > > > > > it a try. After ipactl restart still the same problem:
> > > > > > fyi, I think I can reproduce the issue on 32bit Fedora. I
> > > > > > tried
> > > > > > libverto-libev as well but I removed libverto-tevent after
> > > > > > installing
> > > > > > libverto-libev with 'rpm -e --nodeps ' to make sure
> > > > > > libverto has
> > > > > > no
> > > > > > other chance.
> > > > > > 
> > > > > > So it looks a bit like a libverto 32bit issue. I used
> > > > > > libverto-0.2.6-4.fc22. Since I knew that is was working
> > > > > > before
> > > > > > on
> > > > > > 32bits
> > > > > > I tried libverto-0.2.5 and libverto-0.2.4 as well with no
> > > > > > lock.
> > > > > > 
> > > > > > Nathaniel, do you have any suggestions what to check with
> > > > > > gdb?
> > > > > It may not be a libverto issue at all. Just to summarize,
> > > > > krb5kdc
> > > > > sends
> > > > > the otp request to ipa-otpd using RADIUS-over-UNIX-socket.
> > > > > 
> > > > > It appears that ipa-otpd receives the request and sends the
> > > > > appropriate
> > > > > response. However, krb5kdc never appears to receive the
> > > > > request
> > > > > and
> > > > > times out. Once it times out, it closes the socket and ipa-
> > > > > otpd
> > > > > exits.
> > > > > 
> > > > > The question is: why?
> > > > > 
> > > > > This could be a bug in krb5kdc, libkrad or libverto. Does the
> > > > > event
> > > > > actually fire from libverto? Does libkrad process it
> > > > > correctly?
> > > > > Does
> > > > > krb5kdc process it correctly?
> > > > > 
> > > > > There are lots of places to attach gdb. I would probably
> > > > > start
> > > > > here:
> > > > > https://github.com/krb5/krb5/blob/master/src/lib/krad/client.
> > > > > c#L1
> > > > > 93
> > > > It looks like the 3rd argument of recv(), the buffer length,
> > > > becomes
> > > > negative aka very big in on_io_read()
> > > > 
> > > >  i = recv(verto_get_fd(rr->io), rr->buffer.data + rr-
> > > > > buffer.length,
> > > >   pktlen - rr->buffer.length, 0);
> > > > 
> > > > because pktlen is 4 and rr->buffer.length is 16 on my 32bit
> > > > system.
> > > > I
> > > > wonder if pktlen isn't sufficient here because it already is
> > > > the
> > > > result
> > > > of 'len - buffer->length' which is calculated in
> > > > krad_packet_bytes_needed() ?
> > > > 
> > > > bye,
> > > > Sumit
> > > > 
>  

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

[Nathaniel McCallum]

I have found and fixed what I believe to be the issue. I have submitted
a patch upstream for review: https://github.com/krb5/krb5/pull/471

Once merged, we will backport the fix into all existing Fedora
releases. So you should get an update via a simple: dnf update.

On Thu, 2016-06-16 at 10:28 +0200, Winfried de Heiden wrote:
> Hi all,
> 
> "So it looks a bit like a libverto 32bit issue"; any news or progress
> on 
> this? Bugzilla?
> 
> Winny
> 
> 
> Op 09-06-16 om 18:51 schreef Sumit Bose:
> > On Thu, Jun 09, 2016 at 08:42:59AM -0400, Nathaniel McCallum wrote:
> > > On Thu, 2016-06-09 at 10:46 +0200, Sumit Bose wrote:
> > > > On Thu, Jun 09, 2016 at 08:16:13AM +0200, Winfried de Heiden
> > > > wrote:
> > > > > Hi all,
> > > > > 
> > > > > I can install libvert-libev but removing libverto-tevent will
> > > > > remove 123
> > > > > dependencies also. (wget, tomcat and much more...)
> > > > > 
> > > > > Hence, I installed libverto-libev, but dit not remove
> > > > > libverto-
> > > > > tevent to give
> > > > > it a try. After ipactl restart still the same problem:
> > > > fyi, I think I can reproduce the issue on 32bit Fedora. I tried
> > > > libverto-libev as well but I removed libverto-tevent after
> > > > installing
> > > > libverto-libev with 'rpm -e --nodeps ' to make sure
> > > > libverto has
> > > > no
> > > > other chance.
> > > > 
> > > > So it looks a bit like a libverto 32bit issue. I used
> > > > libverto-0.2.6-4.fc22. Since I knew that is was working before
> > > > on
> > > > 32bits
> > > > I tried libverto-0.2.5 and libverto-0.2.4 as well with no lock.
> > > > 
> > > > Nathaniel, do you have any suggestions what to check with gdb?
> > > It may not be a libverto issue at all. Just to summarize, krb5kdc
> > > sends
> > > the otp request to ipa-otpd using RADIUS-over-UNIX-socket.
> > > 
> > > It appears that ipa-otpd receives the request and sends the
> > > appropriate
> > > response. However, krb5kdc never appears to receive the request
> > > and
> > > times out. Once it times out, it closes the socket and ipa-otpd
> > > exits.
> > > 
> > > The question is: why?
> > > 
> > > This could be a bug in krb5kdc, libkrad or libverto. Does the
> > > event
> > > actually fire from libverto? Does libkrad process it correctly?
> > > Does
> > > krb5kdc process it correctly?
> > > 
> > > There are lots of places to attach gdb. I would probably start
> > > here:
> > > https://github.com/krb5/krb5/blob/master/src/lib/krad/client.c#L1
> > > 93
> > It looks like the 3rd argument of recv(), the buffer length,
> > becomes
> > negative aka very big in on_io_read()
> > 
> >  i = recv(verto_get_fd(rr->io), rr->buffer.data + rr-
> > >buffer.length,
> >   pktlen - rr->buffer.length, 0);
> > 
> > because pktlen is 4 and rr->buffer.length is 16 on my 32bit system.
> > I
> > wonder if pktlen isn't sufficient here because it already is the
> > result
> > of 'len - buffer->length' which is calculated in
> > krad_packet_bytes_needed() ?
> > 
> > bye,
> > Sumit
> > 
> 

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

[Nathaniel McCallum]

On Thu, 2016-06-09 at 10:46 +0200, Sumit Bose wrote:
> On Thu, Jun 09, 2016 at 08:16:13AM +0200, Winfried de Heiden wrote:
> > Hi all,
> > 
> > I can install libvert-libev but removing libverto-tevent will
> > remove 123
> > dependencies also. (wget, tomcat and much more...)
> > 
> > Hence, I installed libverto-libev, but dit not remove libverto-
> > tevent to give
> > it a try. After ipactl restart still the same problem:
> 
> fyi, I think I can reproduce the issue on 32bit Fedora. I tried
> libverto-libev as well but I removed libverto-tevent after installing
> libverto-libev with 'rpm -e --nodeps ' to make sure libverto has
> no
> other chance.
> 
> So it looks a bit like a libverto 32bit issue. I used
> libverto-0.2.6-4.fc22. Since I knew that is was working before on
> 32bits
> I tried libverto-0.2.5 and libverto-0.2.4 as well with no lock.
> 
> Nathaniel, do you have any suggestions what to check with gdb?

It may not be a libverto issue at all. Just to summarize, krb5kdc sends
the otp request to ipa-otpd using RADIUS-over-UNIX-socket.

It appears that ipa-otpd receives the request and sends the appropriate
response. However, krb5kdc never appears to receive the request and
times out. Once it times out, it closes the socket and ipa-otpd exits.

The question is: why?

This could be a bug in krb5kdc, libkrad or libverto. Does the event
actually fire from libverto? Does libkrad process it correctly? Does
krb5kdc process it correctly?

There are lots of places to attach gdb. I would probably start here:
https://github.com/krb5/krb5/blob/master/src/lib/krad/client.c#L193

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

[Nathaniel McCallum]

Can you please try:
  # dnf install libverto-libev
  # dnf remove libverto-tevent
  # ipactl restart

On Wed, 2016-06-08 at 18:30 +0200, Winfried de Heiden wrote:
> Well, here your are:
> rpm -qa 'libverto*' 'krb5*'
> krb5-pkinit-1.14.1-6.fc23.armv7hl
> libverto-tevent-0.2.6-5.fc23.armv7hl
> krb5-libs-1.14.1-6.fc23.armv7hl
> krb5-workstation-1.14.1-6.fc23.armv7hl
> libverto-0.2.6-5.fc23.armv7hl
> krb5-server-1.14.1-6.fc23.armv7hlfedora
> I'm wondering if this is a Fedora ARM issue, I can't reproduce it on
> Fedora x86_64...
> 
> Winny
> 
> 
> Op 08-06-16 om 15:53 schreef Nathaniel McCallum:
> > No, we need to know what libverto *backend* you are using. Please
> > provide the output from this command: rpm -qa 'libverto*' 'krb5*'
> > 
> > On Wed, 2016-06-08 at 08:34 +0200, Winfried de Heiden wrote:
> > > Hi all,
> > > 
> > > 
> > > Well, the libverto is there some time allready (yep, it's running
> > > on
> > > a Bananapi!), doesn't feel like a recent update, so a 
> > > 
> > > 
> > > Name    : libverto
> > > Version : 0.2.6
> > > Release : 5.fc23
> > > Architecture: armv7hl
> > > Install Date: Thu Jan  1 01:08:24 1970
> > > Group   : Unspecified
> > > Size    : 21896
> > > License : MIT
> > > Signature   : RSA/SHA256, Sun Jun 21 06:24:46 2015, Key ID
> > > 32474cf834ec9cba
> > > Source RPM  : libverto-0.2.6-5.fc23.src.rpm
> > > Build Date  : Wed Jun 17 20:37:05 2015
> > > Build Host  : arm04-builder19.arm.fedoraproject.org
> > > 
> > > No, no previous build available...
> > > 
> > > [root@ipa boot]# dnf downgrade libverto
> > > Last metadata expiration check: 0:10:21 ago on Wed Jun  8
> > > 08:19:53
> > > 2016.
> > > Package libverto of lowest version already installed, cannot
> > > downgrade it.
> > > Error: Nothing to do.
> > > 
> > > 
> > > My first guess is that you are hitting this bug: https://github.c
> > > om/k
> > > rb5/krb5/commit/051a31aac553defb2ef0ed4354b799090899904e
> > > 
> > > What to do about it...? 
>  

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

[Nathaniel McCallum]

No, we need to know what libverto *backend* you are using. Please
provide the output from this command: rpm -qa 'libverto*' 'krb5*'

On Wed, 2016-06-08 at 08:34 +0200, Winfried de Heiden wrote:
> Hi all,
> 
> 
> Well, the libverto is there some time allready (yep, it's running on
> a Bananapi!), doesn't feel like a recent update, so a 
> 
> 
> Name    : libverto
> Version : 0.2.6
> Release : 5.fc23
> Architecture: armv7hl
> Install Date: Thu Jan  1 01:08:24 1970
> Group   : Unspecified
> Size    : 21896
> License : MIT
> Signature   : RSA/SHA256, Sun Jun 21 06:24:46 2015, Key ID
> 32474cf834ec9cba
> Source RPM  : libverto-0.2.6-5.fc23.src.rpm
> Build Date  : Wed Jun 17 20:37:05 2015
> Build Host  : arm04-builder19.arm.fedoraproject.org
> 
> No, no previous build available...
> 
> [root@ipa boot]# dnf downgrade libverto
> Last metadata expiration check: 0:10:21 ago on Wed Jun  8 08:19:53
> 2016.
> Package libverto of lowest version already installed, cannot
> downgrade it.
> Error: Nothing to do.
> 
> 
> My first guess is that you are hitting this bug: https://github.com/k
> rb5/krb5/commit/051a31aac553defb2ef0ed4354b799090899904e
> 
> What to do about it...? 

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

[Nathaniel McCallum]

On Wed, 2016-04-27 at 10:22 +0200, Martin Kosek wrote:
> On 04/22/2016 10:40 PM, Jeremy Utley wrote:
> > Hello all!
> > 
> > I'm quite close to reaching the ideal point with our new FreeIPA
> > setup, but one 
> > thing that is standing in the way is 2FA.  I know FreeIPA has
> > support for Google 
> > Auth, FreeOTP, and Yubikey.  We'd like to go with Yubikeys over the
> > phone-based 
> > systems, but a lot of the docs regarding Yubikey seem to either be
> > out-dated, or 
> > not real clear (at least to me).  So I'd like to ask a few
> > questions to make 
> > sure I'm understanding correctly.
> > 
> > 1) It looks like the normal setup of a Yubikey is to plug it into a
> > machine and 
> > run the "ipa otptoken-add-yubikey" command.  This implies that the
> > machine that 
> > sets up the Yubikey needs to be part of the FreeIPA domain, which
> > presents 
> > somewhat of a problem for us, as our current IPA setup has no
> > desktops, and is 
> > in a remote "lights-out" datacenter an hour's drive from our
> > office.  I did see 
> > a post recently in the archives of someone figuring out how to set
> > up a Yubikey 
> > via the web interface 
> > (https://www.redhat.com/archives/freeipa-users/2016-March/msg00114.
> > html) - would 
> > this be viable?
> 
> Interesting question/suggestion, CCing Nathaniel on this one, he
> authored the
> feature.

Yes, this is completely viable. The otptoken-add-yubikey is just a
convenience wrapper. It simply programs the Yubikey with the secret
that is also contained in the qr code. If you program this secret
directly yourself, there is no need to use the otptoken-add-yubikey
command.

> > 2) Does the otptoken-add-yubikey command actually change the
> > programming of the 
> > Yubikey, or does it simply read it's configuration?  We have some
> > users who are 
> > already using a Yubikey for personal stuff, and we'd like to allow
> > those users 
> > to continue to use their existing Yubikey to auth to our IPA
> > domain, but if the 
> > add command changes the programming of the key, that may not be
> > possible without 
> > using the second slot, and if users are already using the second
> > slot, they are 
> > out of luck.

The command programs the YubiKey with the secret value that is in the
QR code. You can do this yourself using Yubico's utilities if you don't
want to use our tool.

However, if users are already using both slots, you're out of luck
anyway since there is no place to store the new secret key. This is a
limitation of YubiKey, not FreeIPA. It would be most unwise to try to
share secrets with another authenticator to overcome this limitation.

> > 3) Does Yubikey auth require talking to the outside world to
> > function?  Our IPA 
> > setup is within a secure zone, with no direct connectivity to the
> > outside world, 
> > so if this is necessary, it would be a possible deal-breaker for
> > these.
> 
> None of the FreeIPA setup should require communication with the
> outside world,
> maybe except some of the current DNS checks during validation. If it
> does, it
> sounds as a bug to me, as I know about multiple deployments of
> FreeIPA in such
> environments.

No, YubiKey - when used with FreeIPA - uses the HOTP protocol. No
network connectivity is required.

-- 
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] YUbiKey for HOTP auth

[Nathaniel McCallum]

On Wed, 2016-03-16 at 14:31 +0100, Martin Kosek wrote:
> On 03/12/2016 04:47 PM, Brad Bendy wrote:
> > 
> > Hi,
> > 
> > YubiKey supports HOTP it appears, but im having a heck of a time
> > getting the token to add FreeIPA. The YubiKey tool gives me the
> > OATH
> > Token which is 6 bytes and the secret key in 20 bytes hex. Ive
> > entered
> > the secret key and OATH token into the "key" field, ive tried all
> > algorithms and get the error of "invalid 'ipatokenotpkey': Non-
> > base32
> > digit found"
> > 
> > Am I missing something? Or is this just not possible at all? I
> > can't
> > find any documentation on Google saying how to set these up.
> > 
> > Thanks!
> Just for the record, you are adding the Yubikey via FreeIPA Web UI?
> We also
> have otptoken-add-yubikey command that makes adding tokens easy.
> 
> CCing Nathaniel to consider what we could do to make your use case
> easier.

I will second the use of otptoken-add-yubikey. Just insert the token
and run the command. :)

-- 
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] otpd heavy load?

[Nathaniel McCallum]

On Thu, 2015-12-10 at 09:34 -0800, Janelle wrote:
> Hi,
> 
> Hope everyone is enjoying the holiday season. Been away for sometime,
> and wanted to jump in with a new question.  I am seeing otpd have
> high 
> resource usage (from just monitoring via top, sar and uptime)
> however, I 
> can not seem to find any logging from it, nor how I might be able to 
> enable some in order to find out why it is using so much CPU? Any 
> thoughts/suggestions?

Log messages should be available through journalctl.

Which libverto backend are you running? If you are on Fedora, please
provide the output of the 'rpm -qa libverto*' command.

-- 
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] otpd heavy load?

[Nathaniel McCallum]

Please provide the output of the 'rpm -qa libverto*' command.

On Thu, 2015-12-10 at 10:13 -0800, Janelle wrote:
> RHEL 7.1
> 
> On 12/10/15 9:55 AM, Nathaniel McCallum wrote:
> > On Thu, 2015-12-10 at 09:34 -0800, Janelle wrote:
> > > Hi,
> > > 
> > > Hope everyone is enjoying the holiday season. Been away for
> > > sometime,
> > > and wanted to jump in with a new question.  I am seeing otpd have
> > > high
> > > resource usage (from just monitoring via top, sar and uptime)
> > > however, I
> > > can not seem to find any logging from it, nor how I might be able
> > > to
> > > enable some in order to find out why it is using so much CPU? Any
> > > thoughts/suggestions?
> > Log messages should be available through journalctl.
> > 
> > Which libverto backend are you running? If you are on Fedora,
> > please
> > provide the output of the 'rpm -qa libverto*' command.
> 

-- 
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] otp issue: can't log in with password+otp

[Nathaniel McCallum]

On Fri, 2015-09-25 at 09:22 +0200, Jan Pazdziora wrote:
> On Fri, Sep 25, 2015 at 10:09:55AM +0300, Alexander Bokovoy wrote:
> > > 
> > > Well, we have separate daemon listening on the
> > > /var/run/krb5kdc/DEFAULT.socket in the container which should
> > > start
> > > the ipa-otpd@.service when there's a connection made to it. But
> > > somehow it does not seem to be happening even if I fix the
> > > parsing of
> > > /etc/ipa/default.conf that ipa-otpd@.service is doing.
> > As I wrote earlier, ipa-otpd relies on socket activation feature of
> > systemd -- systemd opens this socket and listens for incoming
> > connections. Any incoming connection causes to start ipa-otpd
> > daemon and
> > connects its stdin/stdout to the socket's client.
> 
> And in the container there is no systemd so I emulate it there by
> just
> running a separate daemon listening on that socket which will fork
> that ipa-otpd daemon.

Is it in the same container? Because ipa-otpd uses ldapi.

> > > What is the simplest way to trigger the connection to
> > > /var/run/krb5kdc/DEFAULT.socket, for debugging purposes?
> > Use socat. Something like
> > socat UNIX-LISTEN:/var/run/krb5kdc/DEFAULT.socket,unlink-
> > early,fork EXEC:/usr/libexec/ipa-otpd
> 
> I meant, how do I cause the IPA stack (KDC?) to make the connection
> and communication with the ipa-otpd daemon?
> 
> Also, does the Sync OTP Token operation invoke the ipa-otpd daemon
> path (so if Duncan managed to sync the token, it worked for him at
> least once) in any way or does it bypass it?
> 

-- 
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] otp issue: can't log in with password+otp

[Nathaniel McCallum]

Running IPA in a container is very bleading edge. I would not be
surprised at all if you run into lots of problems.

On Tue, 2015-09-22 at 12:10 -0600, Duncan McNaught wrote:
> Thanks Nathaniel,
>   I am running with Jan's Centos-7 container and I'd like to have
> Multi-factor Authentication/2FA enabled.
> He mentioned that systemd is not running in the container, so I
> guess that explains why 2FA is failing. I wonder if I can get
> systemd running there.
> --Duncan
> 
> 
> Thanks
> --Duncan
> 
> Duncan McNaught
> Infrastructure Engineer
>  Technologies | www.bitnet.io
> +1 720 240 6575
> 
> On Tue, Sep 22, 2015 at 6:55 AM, Nathaniel McCallum  t.com> wrote:
> > On Mon, 2015-09-21 at 16:49 -0600, Duncan McNaught wrote:
> > > Dear freeipa-users,
> > >
> > > I'm having an issue with otp in freeipa. I can set up the
> > service as
> > > described in the blog post for TOTP or HOTP, and sync the token
> > fine.
> > > When I try to login to the admin tools or an ipa-managed client
> > > (with ) , I get a password incorrect message.
> > > Here are some more details: https://github.com/adelton/docker-fre
> > eipa
> > > /issues/34
> > > Can anyone help me to debug/get this working?
> > 
> > I'm very unclear as to what you are trying to do. Are you trying to
> > run FreeIPA in a container? If so, Jan is probably your man. AFAIK,
> > ipa-otpd will require systemd in the container.
> > 
> > If you are trying to run this on CentOS 7.1 (not a container), it
> > seems to me that your LDAP server isn't running or something is
> > wrong
> > with ldapi.
> > 
> > Can you explain your setup in more detail?
> > 
> > Nathaniel
> > 

-- 
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] otp issue: can't log in with password+otp

[Nathaniel McCallum]

On Mon, 2015-09-21 at 16:49 -0600, Duncan McNaught wrote:
> Dear freeipa-users,
> 
> I'm having an issue with otp in freeipa. I can set up the service as
> described in the blog post for TOTP or HOTP, and sync the token fine.
> When I try to login to the admin tools or an ipa-managed client
> (with ) , I get a password incorrect message.
> Here are some more details: https://github.com/adelton/docker-freeipa
> /issues/34
> Can anyone help me to debug/get this working?

I'm very unclear as to what you are trying to do. Are you trying to
run FreeIPA in a container? If so, Jan is probably your man. AFAIK,
ipa-otpd will require systemd in the container.

If you are trying to run this on CentOS 7.1 (not a container), it
seems to me that your LDAP server isn't running or something is wrong
with ldapi.

Can you explain your setup in more detail?

Nathaniel

-- 
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] OTP - Google Authenticator - iPhone - Invalid barcode

[Nathaniel McCallum]

The change that you made might break other things.

On Wed, 2015-06-17 at 22:45 +0530, Prashant Bapat wrote:
> Hi Nathaniel, 
> 
> I think your patch should work. Please give me a day to test and 
> confirm. 
> 
> However, I changed this section in otptoken.py:
> 
> StrEnum('ipatokenotpalgorithm?',
> cli_name='algo',
> label=_('Algorithm'),
> doc=_('Token hash algorithm'),
> default=u'sha1',
> autofill=True,
> flags=('no_update'),
> values=(u'sha1', u'sha256', u'sha384', u'sha512'),
> )
> 
> to 
> 
> StrEnum('ipatokenotpalgorithm?',
> cli_name='algo',
> label=_('Algorithm'),
> doc=_('Token hash algorithm'),
> default=u'SHA1',
> autofill=True,
> flags=('no_update'),
> values=(u'SHA1', u'SHA256', u'SHA384', u'SHA512'),
> )
> 
> And the Google Authenticator installed on a iPhone was able to scan 
> the QR code and work as expected. 
> 
> Thanks for looking into this. 
> 
> Regards. 
> --Prashant
> 
> On 17 June 2015 at 20:00, Nathaniel McCallum  
> wrote:
> > Prashant,
> > 
> > I have proposed a patch for the issue:
> > https://www.redhat.com/archives/freeipa-devel/2015
> > -June/msg00505.html
> > 
> > Please test it and let me know if it works for you.
> > 
> > Nathaniel
> > 
> > On Wed, 2015-06-17 at 12:35 +0530, Prashant Bapat wrote:
> > > Simo is right! This issue is same as
> > > https://fedorahosted.org/freeipa/ticket/5047
> > >
> > > If I change the algorithm in the otp url to uppercase it scans in
> > > Google authenticator/iPhone.
> > >
> > > Further more I manually edited the /usr/lib/python2.7/site
> > > -packages/ipalib/plugins/otptoken.py and uppercases the 'sha' to
> > > 'SHA' in a test VM and it works as expected. I hate to do this in 
> > the
> > > production server though.
> > >
> > >
> > > On 12 June 2015 at 23:32, Prashant Bapat  
> > wrote:
> > > > Hi,
> > > >
> > > > Has anyone seen this ? When a user tries to scan the QR code he
> > > > gets a message saying "invalid barcode". This happens only with
> > > > iPhone + Google Authenticator.
> > > >
> > > > Thanks for your help.
> > > >
> > > > --Prashant
> > > >
> > > --
> > > 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] OTP - Google Authenticator - iPhone - Invalid barcode

[Nathaniel McCallum]

Prashant,

I have proposed a patch for the issue: 
https://www.redhat.com/archives/freeipa-devel/2015-June/msg00505.html

Please test it and let me know if it works for you.

Nathaniel

On Wed, 2015-06-17 at 12:35 +0530, Prashant Bapat wrote:
> Simo is right! This issue is same as 
> https://fedorahosted.org/freeipa/ticket/5047
> 
> If I change the algorithm in the otp url to uppercase it scans in 
> Google authenticator/iPhone. 
> 
> Further more I manually edited the /usr/lib/python2.7/site
> -packages/ipalib/plugins/otptoken.py and uppercases the 'sha' to 
> 'SHA' in a test VM and it works as expected. I hate to do this in the 
> production server though. 
> 
> 
> On 12 June 2015 at 23:32, Prashant Bapat  wrote:
> > Hi, 
> > 
> > Has anyone seen this ? When a user tries to scan the QR code he 
> > gets a message saying "invalid barcode". This happens only with 
> > iPhone + Google Authenticator. 
> > 
> > Thanks for your help. 
> > 
> > --Prashant
> > 
> -- 
> 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] ipa spamming radius with otp token?

[Nathaniel McCallum]

On Thu, 2015-06-04 at 21:48 +, Bahmer, Eric Vaughn wrote:
> Someone higher up decided that there was no time for me to resolve 
> this
> and I’ve been forced to implement a different method for now.
> 
> I can still continue to work on this, I'll just need to find 
> different
> hardware to troubleshoot with.
> 
> I have set up a kerberos.xml in /etc/firewalld/services restricting 
> to tcp
> 88.
> I have restricted the service to the specific interface via zone and 
> rich
> rule.
> 
> 
> ……..
> 
> 
> ….
> 
> 
> 
> 
> 
> 
> 
> 
> …..
> 
> 
> Same for kpasswd on port 464.
> 
> I’m also made sure that the krb5.conf has a line for 
> udp_preference_limit
> = 1
> 
> I’ve also made sure to turn caching off in sssd.conf and restarted 
> that.
> I set a 30 second timeout and 0 retries.
> 
> Attempting to SSH from the firewall/gateway as a user to the idm 
> server
> itself.
> 
> I’ve managed to get things down to just 2 copies with maybe 1 second
> difference:
> 
> Fri May 15 15:23:05
>   Packet-Type = Access-Request
>   NAS-Identifier = “idm2.manage.monitor.net”
>   Service-Type = Authenticate-Only
>   User-Name = “bahmer”
>   User-Password = “123-4567"
> 
> 
> On the Idm server /var/log/secure:
> May 15 15:23:03 idm2 unix_chkpwd[15103]: check pass; user unknown
> May 15 15:23:03 idm2 unix_chkpwd[15103]: password check failed for 
> user
> (bahmer)
> May 15 15:23:03 idm2 sshd[15101]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=gate1.manage.monitor.net  user=bahmer
> May 15 15:23:07 idm2 sshd[15101]: pam_sss(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=gate1.manage.monitor.net  user=bahmer
> May 15 15:23:07 idm2 sshd[15101]: pam_sss(sshd:auth): received for 
> user
> bahmer: 17 (Failure setting user credentials)
> May 15 15:23:09 idm2 sshd[15101]: Failed password for bahmer from
> 10.6.0.41 port 44347 ssh2
> 
> 
> 
> I’ve collected some tcpdump information, most of the kerberos traffic 
> is
> on the loopback interface and nothing stands out.
> I can see the two requests in the tcpdump on the interface the idm 
> server
> should be using to talk to radius.
> I probably need permission in order to send the captures after 
> sanitizing
> them for security policy reasons.
> 
> Is it possible that sssd is the culprit trying to do a pre-auth 
> before the
> real auth?
> 

Anything is possible. What you need to do is capture the incoming krb5
traffic and the outgoing RADIUS traffic from the KDC. The question you
need to answer from this data is: does the two output RADIUS requests
correspond to one or two incoming krb5 requests.

If there are two krb5 requests, then there is probably a bug in SSSD.
If there is only one krb5 request, then there is probably a bug or
configuration issue in the krb5-otp plugin.

Nathaniel

> On 5/13/15, 12:00 PM, "Nathaniel McCallum" 
> > wrote:
> > 
> > > On Wed, 2015-05-13 at 14:44 +, Bahmer, Eric Vaughn wrote:
> > > > Institutionally we have a hardware token set up, you use a pin 
> > > > to
> > > > unlock the device and it spits out a passcode.
> > > > The passcode allows access through kerberos, radius, or ldap 
> > > > binds
> > > > to linux servers, or with a custom apache module to websites.
> > > > 
> > > > I have an out-of-band private network set up that attaches to 
> > > > our
> > > > intranet using a firewall/gateway server which does some port
> > > > forwarding for various things like SSH, RDP.
> > > > I¹m attempting to set up RADIUS on this firewall/gateway to be 
> > > > used
> > > > as a proxy for freeipa to our token system which I¹d like to be 
> > > > able
> > > > to use behind the firewall.
> > > > However I seem to be getting nearly a dozen requests into the 
> > > > radius
> > > > server, about half are dropped as duplicate, but usually 3-6 
> > > > get
> > > > through and since it¹s a single use token the first attempt
> > > > succeeds, but the rest fail and cause the hardware token to be
> > > > blacklisted.
> > > > Is there a way to specify that the user radius login is a one
> > > > -time
> > > > token or is this something that sssd or pam is causing?
> > > > Or does the OTP support just not work in the way I need it to?
> > > > I have this issue wi

Re: [Freeipa-users] interesting Kerberos issue

[Nathaniel McCallum]

On Mon, 2015-05-18 at 09:45 -0500, Janelle wrote:
> Ok, let me ask this a different way, because maybe there is a way, 
> and I am just not seeing it.
> 
> I have 2 datacenters with typical bastions in each. I have enabled 
> OTP and that works fine via ssh. But the user has to login to both 
> and opening ssh tunnels is problematic at best.
> 
> Using all the creativity in this list, maybe someone knows of another 
> way to have a user authenticate from a Mac where they would only have 
> to do it once to get their ticket?
> 
> I guess I can't think of anything, but no harm in asking.

Without support for the OTP pre-authentication mechanism, I don't know
of any way to do this while still retaining the security properties of
Kerberos. Basically, you'll have to hand over your password to a third
party (which has OTP support). This is ill advised.

Nathaniel

-- 
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] interesting Kerberos issue

[Nathaniel McCallum]

On Mon, 2015-05-18 at 17:18 +0300, Alexander Bokovoy wrote:
> On Mon, 18 May 2015, Nathaniel McCallum wrote:
> > On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote:
> > > On Mon, 18 May 2015, Janelle wrote:
> > > > On 5/10/15 11:57 PM, Alexander Bokovoy wrote:
> > > > > On Sun, 10 May 2015, Janelle wrote:
> > > > > > On 5/5/15 6:47 AM, Dmitri Pal wrote:
> > > > > > > On 05/04/2015 09:38 PM, Janelle wrote:
> > > > > > > > On 5/4/15 6:06 PM, Nathaniel McCallum wrote:
> > > > > > > > > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote:
> > > > > > > > > > Happy Star Wars Day!
> > > > > > > > > > May the Fourth be with you!
> > > > > > > > > > 
> > > > > > > > > > So I have a strange Kerberos problem trying to 
> > > > > > > > > > figure
> > > > > > > > > > out. On a
> > > > > > > > > > CLIENT,  (CentOS 7.1) if I login to account "usera"
> > > > > > > > > > they get a
> > > > > > > > > > ticket as
> > > > > > > > > > expected.  However, if I login to a 6.6 client, it
> > > > > > > > > > doesn't seem to
> > > > > > > > > > work.
> > > > > > > > > > Both were enrolled the same, obviously one is 
> > > > > > > > > > newer.
> > > > > > > > > > 
> > > > > > > > > > Now, it gets stranger. The "servers" are CentOS 7.1
> > > > > > > > > > also. If I login
> > > > > > > > > > as
> > > > > > > > > > root, bypassing kerberos, and then do "kinit admin" 
> > > > > > > > > > it
> > > > > > > > > > works just
> > > > > > > > > > fine.
> > > > > > > > > > But if I do "kinit usera" I get:
> > > > > > > > > > 
> > > > > > > > > > kinit: Generic preauthentication failure while 
> > > > > > > > > > getting
> > > > > > > > > > initial
> > > > > > > > > > credentials
> > > > > > > > > > 
> > > > > > > > > > Which makes no sense. The account works with a 7.1
> > > > > > > > > > client but not a
> > > > > > > > > > 6.x
> > > > > > > > > > client?? And yet "admin" works, no matter what. 
> > > > > > > > > > What am
> > > > > > > > > > I missing
> > > > > > > > > > here?
> > > > > > > > > If I had to guess, usera is enabled for OTP-only 
> > > > > > > > > login.
> > > > > > > > > Is that
> > > > > > > > > correct?
> > > > > > > > > 
> > > > > > > > > If so, clients require RHEL 7.1 for OTP support. 
> > > > > > > > > Also,
> > > > > > > > > the error you
> > > > > > > > > are getting is the result of not enabling FAST 
> > > > > > > > > support
> > > > > > > > > for OTP
> > > > > > > > > authentication (see the -T option).
> > > > > > > > > 
> > > > > > > > > Nathaniel
> > > > > > > > Ok, this did give me an idea (Thanks Nathaniel)  -- the
> > > > > > > > account was set for BOTH "password" and OTP.
> > > > > > > > Apparently setting both does nothing. Yes a user can 
> > > > > > > > login
> > > > > > > > with their password-only, but trying to use kinit does 
> > > > > > > > not
> > > > > > > > work.
> > > > > > > > 
> > > > > > > > I am not sure I understand where the FAST support or 
> > > > > > > > the -T
> > > > > > > > 
> > > > > > > > option is to be applied. On kinit? That does not seem
>

Re: [Freeipa-users] interesting Kerberos issue

[Nathaniel McCallum]

On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote:
> On Mon, 18 May 2015, Janelle wrote:
> > On 5/10/15 11:57 PM, Alexander Bokovoy wrote:
> > > On Sun, 10 May 2015, Janelle wrote:
> > > > On 5/5/15 6:47 AM, Dmitri Pal wrote:
> > > > > On 05/04/2015 09:38 PM, Janelle wrote:
> > > > > > On 5/4/15 6:06 PM, Nathaniel McCallum wrote:
> > > > > > > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote:
> > > > > > > > Happy Star Wars Day!
> > > > > > > > May the Fourth be with you!
> > > > > > > > 
> > > > > > > > So I have a strange Kerberos problem trying to figure 
> > > > > > > > out. On a
> > > > > > > > CLIENT,  (CentOS 7.1) if I login to account "usera" 
> > > > > > > > they get a
> > > > > > > > ticket as
> > > > > > > > expected.  However, if I login to a 6.6 client, it 
> > > > > > > > doesn't seem to
> > > > > > > > work.
> > > > > > > > Both were enrolled the same, obviously one is newer.
> > > > > > > > 
> > > > > > > > Now, it gets stranger. The "servers" are CentOS 7.1 
> > > > > > > > also. If I login
> > > > > > > > as
> > > > > > > > root, bypassing kerberos, and then do "kinit admin" it 
> > > > > > > > works just
> > > > > > > > fine.
> > > > > > > > But if I do "kinit usera" I get:
> > > > > > > > 
> > > > > > > > kinit: Generic preauthentication failure while getting 
> > > > > > > > initial
> > > > > > > > credentials
> > > > > > > > 
> > > > > > > > Which makes no sense. The account works with a 7.1 
> > > > > > > > client but not a
> > > > > > > > 6.x
> > > > > > > > client?? And yet "admin" works, no matter what. What am 
> > > > > > > > I missing
> > > > > > > > here?
> > > > > > > If I had to guess, usera is enabled for OTP-only login. 
> > > > > > > Is that
> > > > > > > correct?
> > > > > > > 
> > > > > > > If so, clients require RHEL 7.1 for OTP support. Also, 
> > > > > > > the error you
> > > > > > > are getting is the result of not enabling FAST support 
> > > > > > > for OTP
> > > > > > > authentication (see the -T option).
> > > > > > > 
> > > > > > > Nathaniel
> > > > > > Ok, this did give me an idea (Thanks Nathaniel)  -- the 
> > > > > > account was set for BOTH "password" and OTP.
> > > > > > Apparently setting both does nothing. Yes a user can login 
> > > > > > with their password-only, but trying to use kinit does not 
> > > > > > work.
> > > > > > 
> > > > > > I am not sure I understand where the FAST support or the -T 
> > > > > > 
> > > > > > option is to be applied. On kinit? That does not seem 
> > > > > > correct. 
> > > > > > Perhaps I am misunderstanding this option?
> > > > > > 
> > > > > > ~J
> > > > > > 
> > > > > If the user is enabled for OTP his credential are sent 
> > > > > differently than in the case when it is not enabled. 
> > > > > Effectively 
> > > > > instead of using encrypted timestamp the password and OTP are 
> > > > > 
> > > > > sent to the server as data. But they can't be sent in clear. 
> > > > > You 
> > > > > need to encrypt the data. To encrypt it you need another key 
> > > > > - 
> > > > > the host key. The encryption of the data in this context is 
> > > > > called tunneling . FAST is the Kerberos protocol feature to 
> > > > > provide tunneling of the data sent over the wire. To use FAST 
> > > > > 
> > > > > one needs to use -T on the kinit command line.
> > > > > Does this help?
> > > > > 
> > > > It helps -- thank you.
> > > > 
> > > > Now allow me to add a little more fun, and there may not be a 
> > > > solution.
> > > > > From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA
> > > > > -server
> > > > principal" and it works, gives me a ticket, and if I attempt to 
> > > > 
> > > > login to the web interface, since I already have my ticket - 
> > > > boom, 
> > > > works fine.
> > > > 
> > > > Now, I enable 2FA and setup a token and change my account to 
> > > > OTP 
> > > > (with TOTP).  But as previously discussed, can't seem to 
> > > > specify a 
> > > > -T option from OS X.
> > > > 
> > > > I know this sounds tricky -- Any ideas?
> > > Use
> > > kinit --fast-armor-cache /path/to/ccache to specify already 
> > > existing ccache to armor the FAST processing.
> > > 
> > > This is Heimdal-specific, and you should have Heimdal 1.6rc2 at 
> > > least.
> > > You can check version number by running 'kinit --version'.
> > Aha, so thee default on OS X Yosemite is
> > 
> > $ kinit --version
> > kinit (Heimdal 1.5.1apple1)
> > 
> > so this won't work?
> Yes, you have to have the feature in your Kerberos library.

Browsing the Heimdal source code, I don't even see any support for OTP
at all. :(

Nathaniel

-- 
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] 4.1.4 and OTP

[Nathaniel McCallum]

On Mon, 2015-05-18 at 07:59 -0500, Janelle wrote:
> > 
> > On May 18, 2015, at 04:31, Martin Kosek  wrote:
> > 
> > > On 05/18/2015 01:49 AM, Janelle wrote:
> > > > On 4/28/15 6:44 AM, Nathaniel McCallum wrote:
> > > > > On Fri, 2015-04-17 at 20:21 -0700, Janelle wrote:
> > > > > > On 4/17/15 5:59 PM, Dmitri Pal wrote:
> > > > > > > On 04/17/2015 08:07 PM, Janelle wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Apr 17, 2015, at 16:36, Dmitri Pal  
> > > > > > > wrote:
> > > > > > > 
> > >  for shorter thread
> > > > > > > Simple. And my test made it simple.
> > > > > > > Stand up new vm running fc21/freeipa.
> > > > > > > Configure user.
> > > > > > > Add password.
> > > > > > > Add token.
> > > > > > > 
> > > > > > > Login to the vm with the user created using password. 
> > > > > > > Kerberos
> > > > > > > ticket assigned, all is well.
> > > > > > > 
> > > > > > > Login to web interface with admin. Change user to OTP 
> > > > > > > only.
> > > > > > > Go to web UI and click sync OTP.
> > > > > > > Enter username, password and 2 OTP sequences. Click sync. 
> > > > > > > Error
> > > > > > > appears.
> > > > > > > 
> > > > > > > Now, ssh to same vm using OTP username. Enter password + 
> > > > > > > OTP
> > > > > > > value.
> > > > > > > Login successful.
> > > > > > I can reproduce this issue with demo instance.
> > > > > > I will file a bug later today.
> > > > > > I think it is a bug with sync.
> > > > > > Which token do you use time based or event based?
> > > > > TOTP...
> > > > > 
> > > > > Hmm, makes me wonder - with HOTP fail the same? Off to try 
> > > > > it.
> > > > This should just affect TOTP. I have posted a patch that should 
> > > > fix
> > > > this problem. Are you able to test it?
> > > > 
> > > > https://www.redhat.com/archives/freeipa-devel/2015
> > > > -April/msg00282.html
> > > > 
> > > > 
> > > Sorry - I just got around to testing this and it does resolve the 
> > > problem -
> > > HOWEVER, you took away the ability to "Name" the tokens? They are 
> > > now
> > > "assigned" unique IDs??
> > > 
> > > Was this intentional?
> > 
> > It was, we track this (half-done) change in this ticket:
> > https://fedorahosted.org/freeipa/ticket/4456
> > 
> > The main problem here is that user token names share the same name 
> > space and we
> > thus do not want to create completely arbitrary names as they would 
> > collide.
> > 
> > Applications like FreeOTP allow users to set own labels, so this is 
> > IMO the way
> > how to add friendly names to the OTP tokens.
> > 
> > Martin
> > 
> 
> Makes sense, my only concern is syncing tokens.  Once you add a 
> second to,en and want to sync it you have to give it a token ID, 
> otherwise it does not know which to sync. In the past if you named 
> it, that was easy, but it does not seem to take description field as 
> a token name. Guess I need to tell my users it is cut/paste time, or 
> is there another option perhaps?

You do not need to specify the token id when syncing. It is optional.
If you leave it blank, FreeIPA will do the right thing.

> Also, I was wondering, looking for a way to use both FreeOTP and 
> yubikey and wondering if anyone has tried this and possible caveats?

There shouldn't be any caveats. Yubikey is just an HOTP token.

Nathaniel

-- 
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 spamming radius with otp token?

[Nathaniel McCallum]

On Wed, 2015-05-13 at 14:44 +, Bahmer, Eric Vaughn wrote:
> Institutionally we have a hardware token set up, you use a pin to 
> unlock the device and it spits out a passcode.
> The passcode allows access through kerberos, radius, or ldap binds 
> to linux servers, or with a custom apache module to websites.
> 
> I have an out-of-band private network set up that attaches to our 
> intranet using a firewall/gateway server which does some port 
> forwarding for various things like SSH, RDP.
> I’m attempting to set up RADIUS on this firewall/gateway to be used 
> as a proxy for freeipa to our token system which I’d like to be able 
> to use behind the firewall.
> However I seem to be getting nearly a dozen requests into the radius 
> server, about half are dropped as duplicate, but usually 3-6 get 
> through and since it’s a single use token the first attempt 
> succeeds, but the rest fail and cause the hardware token to be 
> blacklisted.
> Is there a way to specify that the user radius login is a one-time 
> token or is this something that sssd or pam is causing?
> Or does the OTP support just not work in the way I need it to?
> I have this issue with both the inbox 4.1.0 in RHEL7.1 or the 
> upstream 4.1.4 rpms.
> 
> My only alternative is probably to set up a KDC on the firewall to 
> trust the institutional realm and have the IdM kerberos realm trust 
> that.
> This is also a mixed linux/windows environment behind the firewall, 
> I’ve enabled unix attributes in my AD and I’m using a script to sync 
> uid/gid with the external ldap.

I do think a cross realm trust is the right way to set this up.

However, let's look more closely at the RADIUS issue.

First, I want to ensure that you are using TCP for your kerberos
connections. If you are using UDP for kerberos, then the kerberos
client will send a new packet which will cause the KDC to fire off a
new set of RADIUS messages. The use of TCP should be enforced with
kerberos when using OTP.


How long does it take for the hardware token RADIUS server to respond?
Have you tried adjusting the number of retries and timeout for the
RADIUS server in FreeIPA? A longer timeout or fewer retries will
reduce the number of packets transmitted.

If you are able to setup a test user with fake credentials and could
perform a packet capture of kerberos and RADIUS traffic it would help
me understand what is going on here.

Nathaniel

PS - If I had to take a guess based on what I know now, I would
suspect that the real culprit is kinit sending too many requests. This
is based on your statement that the RADIUS server is dropping *some*
duplicates. This means that the other RADIUS packets are *not*
duplicates and probably represent a subsequent AS-REQ on the KDC from
kinit.

-- 
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] interesting Kerberos issue

[Nathaniel McCallum]

On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote:
> Happy Star Wars Day!
> May the Fourth be with you!
> 
> So I have a strange Kerberos problem trying to figure out.  On a 
> CLIENT,  (CentOS 7.1) if I login to account "usera" they get a 
> ticket as 
> expected.  However, if I login to a 6.6 client, it doesn't seem to 
> work. 
> Both were enrolled the same, obviously one is newer.
> 
> Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login 
> as 
> root, bypassing kerberos, and then do "kinit admin" it works just 
> fine. 
> But if I do "kinit usera" I get:
> 
> kinit: Generic preauthentication failure while getting initial 
> credentials
> 
> Which makes no sense. The account works with a 7.1 client but not a 
> 6.x 
> client?? And yet "admin" works, no matter what. What am I missing 
> here?

If I had to guess, usera is enabled for OTP-only login. Is that
correct?

If so, clients require RHEL 7.1 for OTP support. Also, the error you
are getting is the result of not enabling FAST support for OTP
authentication (see the -T option).

Nathaniel

-- 
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] 2fa with trusted AD users

[Nathaniel McCallum]

On Fri, 2015-05-01 at 13:03 +, Andy Thompson wrote:
> Is this possible or do they have to be local IPA accounts?  Looking 
> at options for setting up freeradius with IPA on the backend and 
> utilizing OTP, I've got a test case setup and working for local 
> accounts but a lot of our users are trusted accounts.
> 
> > From what I can tell it is not possible currently but I saw a 
> > reference along the line somewhere about external users.  Can't 
> > really find much  info otherwise.

It is not currently possible. However, I believe Alexander had some
ideas related to this. I've CC'd him.

Nathaniel

-- 
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] 4.1.4 and OTP

[Nathaniel McCallum]

On Fri, 2015-04-17 at 20:21 -0700, Janelle wrote:
> On 4/17/15 5:59 PM, Dmitri Pal wrote:
> > On 04/17/2015 08:07 PM, Janelle wrote:
> > > 
> > > 
> > > 
> > > 
> > > On Apr 17, 2015, at 16:36, Dmitri Pal  wrote:
> > > 
> > > > On 04/17/2015 04:52 PM, Janelle wrote:
> > > > >  On 4/17/15 1:19 PM, Dmitri Pal wrote:
> > > > > > On 04/17/2015 01:20 PM, Janelle wrote: 
> > > > > > > On 4/17/15 9:53 AM, Dmitri Pal wrote: 
> > > > > > > > On 04/17/2015 11:16 AM, Janelle wrote: 
> > > > > > > > > Hi, 
> > > > > > > > > 
> > > > > > > > > Is anyone else having issues with OTP since 
> > > > > > > > > upgrading? For the life of me I can't get it to 
> > > > > > > > > accept "Sync" for the tokens. No matter what is put 
> > > > > > > > > in, it just keeps saying the username, password or 
> > > > > > > > > tokens entered  are incorrect. 
> > > > > > > > > 
> > > > > > > > > To make it simple - I am tryign this on a brand new 
> > > > > > > > > CentOS 7.1 system with a clean/fresh install of 
> > > > > > > > > FreeIPA 4.1.4 and yet it just refuses to work. 
> > > > > > > > > 
> > > > > > > > > I create a user -- configure them. They work just 
> > > > > > > > > fine with a password. Then add a token. Sync with 
> > > > > > > > > FreeOTP and that all works. Then going back to the 
> > > > > > > > > web UI and do Sync OTP and it simply refuses to 
> > > > > > > > > accept any values. And yet the same user can login 
> > > > > > > > > to the regular web UI with their password. 
> > > > > > > > > 
> > > > > > > > > I have tried setting the user to both Password and 
> > > > > > > > > OTP for auth methods. And also just OTP and nothing 
> > > > > > > > > works. 
> > > > > > > > Please look in the logs to see what is going on. 
> > > > > > > > You would need to look at the KDC, http and DS logs on 
> > > > > > > > the server to sort out what is going on. 
> > > > > > > > 
> > > > > > > > Do you change the password for the user first after 
> > > > > > > > creating him? 
> > > > > > > > 
> > > > > > > > Can you reproduce the problem with demo instance? 
> > > > > > > > http://www.freeipa.org/page/Demo 
> > > > > > > > If you can then we can take a look at the logs right 
> > > > > > > > away. 
> > > > > > > > Hints? Am I missing  a step? 
> > > > > > > > 
> > > > > > > > ~J 
> > > > > > > > 
> > > > > > > It appears to be the UI. If I go through the steps and 
> > > > > > > let it "fail", I can still login using OTP to servers. I 
> > > > > > > made the assumption that the error itself was not an 
> > > > > > > error.. :-) 
> > > > > > > 
> > > > > > > ~J 
> > > > > > > 
> > > > > > I am not sure I get what you are saying. Do you still see 
> > > > > > the problem or you misinterpreted the UI and now the 
> > > > > > problem is gone? If you did is there any recommendation 
> > > > > > how to improve the UI not to confuse people? 
> > > > > > 
> > > > > The problem exists -- this is what it shows:
> > > > > HOWEVER, it is still WORKING. Meaning, even if you get this 
> > > > > error, if you attempt to login with your FreeOTP token, it 
> > > > > WORKS.
> > > > > 
> > > > > ~J
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > Does it give you this error when you use password or password 
> > > > and token?
> > > > Can you please describe the flow of steps in more details?
> > > > I start browser, go here, click here, enter this, etc.
> > > > 
> > > > Are you using SSSD to login to servers? Is SSSD configured 
> > > > with IPA provider or you configured it for LDAP manually. 
> > > > There is a difference between LDAP and Kerberos authentication.
> > > > 
> > > > May be the following article will help you to understand the 
> > > > expectations:
> > > > https://access.redhat.com/documentation/en
> > > > -US/Red_Hat_Enterprise_Linux/7/html/System
> > > > -Level_Authentication_Guide/authconfig-addl-auth.html#enable
> > > > -otp
> > > > 
> > > > 
> > > > 
> > > Simple. And my test made it simple.
> > > Stand up new vm running fc21/freeipa.
> > > Configure user.
> > > Add password.
> > > Add token.
> > > 
> > > Login to the vm with the user created using password. Kerberos 
> > > ticket assigned, all is well.
> > > 
> > > Login to web interface with admin. Change user to OTP only.
> > > Go to web UI and click sync OTP. 
> > > Enter username, password and 2 OTP sequences. Click sync. Error 
> > > appears.
> > > 
> > > Now, ssh to same vm using OTP username. Enter password + OTP 
> > > value.
> > > Login successful.
> > I can reproduce this issue with demo instance.
> > I will file a bug later today.
> > I think it is a bug with sync.
> > Which token do you use time based or event based?
> TOTP... 
> 
> Hmm, makes me wonder - with HOTP fail the same? Off to try it.

This should just affect TOTP. I have posted a patch that should fix
this problem. Are you able to test it?

https://www.redhat.com/archives/freeipa-devel/2015-April/msg00282.html

> ~J
> 
> PS - is there a way to sync a token from command line? I can't think 
> of a wa

Re: [Freeipa-users] Host based 2FA ?

[Nathaniel McCallum]

On Fri, 2014-12-12 at 14:46 -0500, Dmitri Pal wrote:
> On 12/12/2014 02:40 PM, Nathaniel McCallum wrote:
> > On Fri, 2014-12-12 at 13:07 -0500, Simo Sorce wrote:
> >> On Thu, 11 Dec 2014 18:30:06 -0500
> >> Dmitri Pal  wrote:
> >>
> >>> On 12/11/2014 06:32 PM, free...@pettyvices.com wrote:
> >>>> I'd like to be able to require 2FA on *certain* hosts and allow
> >>>> just passwords on others.
> >>>>
> >>>> It seems you can check both "passwords" and "2FA" under the user.
> >>>>
> >>>> I was hoping I could create a HBAC such that certain hosts would
> >>>> only allow 2FA, but I can't see an obvious way to do that.
> >>>>
> >>>> Is it possible?  Help on how would be great.  If not, feature
> >>>> request?
> >>>>
> >>>> thanks,
> >>>>
> >>>> -t
> >>>>
> >>> We have several tickets:
> >>>
> >>> https://fedorahosted.org/freeipa/ticket/433
> >>>
> >>> https://fedorahosted.org/freeipa/ticket/3659
> >>>
> >>> https://fedorahosted.org/freeipa/ticket/4498
> >>>
> >>> If you see https://fedorahosted.org/freeipa/ticket/4498#comment:6 we
> >>> discussed this use case.
> >>> And I was about to fork it as said but then I realized that there is
> >>> not good way on the KDC to determine the host you are coming from.
> >>> So IMO it should be a policy decision on SSSD.
> >>> There are two options:
> >>> - short term solution: allow SSSD to have a local overwrite to
> >>> require OTP if server offers different options.
> >>> - longer term solution: actually have a per host policy that is
> >>> centrally managed that is fetched per host and enforced by SSSD.
> >>>
> >>> Before filing tickets I would like to hear opinions on the matter.
> >> If we are using a FAST channel using the credentials of the host then
> >> you may be able to know (probably requires changes in the KDC to
> >> internally retain/convey the information).
> >> This is possible via SSSD, but will not work via kinit done by a
> >> generic user, so normal kinit's would require 2FA all the time.
> 
> I do not understand how kinit will require 2FA if kinit does not use 
> FAST (because it does not have access to the host keys).
> OTP is possible only over the armored tunnel.
> 
> > This was my exact thought. But this technically isn't HBAC so much as
> > "choose preauth mechs based upon the principal used to secure the FAST
> > channel." It would also be somewhat useless if using anonymous pkinit to
> > secure the FAST channel.
> >
> > Besides, long-term, we want FAST to go away. It is too cumbersome.
> 
> But there will be other way to create armor tunnel and you would need 
> some other principal in the exchange, right?

No. Long-term, with PAKE preauth, the second factor will be dynamically
encrypted in the session key calculated from two public keys (client and
server) and the long-term shared secret. There will be no other
principal involved.

> So what would be a short term and long term solution?
> SSSD override seems like a simple thing to do.
> AFAIR we already design it couple years ago but I suspect not 
> implemented yet.

Long-term, there is no way to restrict this from the KDC-side.

As I see it, long-term we have auth indicators, optional 2FA and PAKE
+OTP. The user can be configured for password OR password+otp. Then SSSD
can be told via something like an HBAC which it should prompt for. But
this would be purely voluntary since the KDC will allow both logins.

Having different policies based on the source of a message is always bad
security design because such information can never be trusted by the
recipient.

Nathaniel

-- 
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] Host based 2FA ?

[Nathaniel McCallum]

On Fri, 2014-12-12 at 13:07 -0500, Simo Sorce wrote:
> On Thu, 11 Dec 2014 18:30:06 -0500
> Dmitri Pal  wrote:
> 
> > On 12/11/2014 06:32 PM, free...@pettyvices.com wrote:
> > >
> > > I'd like to be able to require 2FA on *certain* hosts and allow
> > > just passwords on others.
> > >
> > > It seems you can check both "passwords" and "2FA" under the user.
> > >
> > > I was hoping I could create a HBAC such that certain hosts would
> > > only allow 2FA, but I can't see an obvious way to do that.
> > >
> > > Is it possible?  Help on how would be great.  If not, feature
> > > request?
> > >
> > > thanks,
> > >
> > > -t
> > >
> > We have several tickets:
> > 
> > https://fedorahosted.org/freeipa/ticket/433
> > 
> > https://fedorahosted.org/freeipa/ticket/3659
> > 
> > https://fedorahosted.org/freeipa/ticket/4498
> > 
> > If you see https://fedorahosted.org/freeipa/ticket/4498#comment:6 we 
> > discussed this use case.
> > And I was about to fork it as said but then I realized that there is
> > not good way on the KDC to determine the host you are coming from.
> > So IMO it should be a policy decision on SSSD.
> > There are two options:
> > - short term solution: allow SSSD to have a local overwrite to
> > require OTP if server offers different options.
> > - longer term solution: actually have a per host policy that is 
> > centrally managed that is fetched per host and enforced by SSSD.
> > 
> > Before filing tickets I would like to hear opinions on the matter.
> 
> If we are using a FAST channel using the credentials of the host then
> you may be able to know (probably requires changes in the KDC to
> internally retain/convey the information).
> This is possible via SSSD, but will not work via kinit done by a
> generic user, so normal kinit's would require 2FA all the time.

This was my exact thought. But this technically isn't HBAC so much as
"choose preauth mechs based upon the principal used to secure the FAST
channel." It would also be somewhat useless if using anonymous pkinit to
secure the FAST channel.

Besides, long-term, we want FAST to go away. It is too cumbersome.

Nathaniel

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] [Freeipa-devel] Announcing FreeIPA 4.0.3

[Nathaniel McCallum]

On Mon, 2014-09-15 at 17:26 +0200, Petr Viktorin wrote:
> On 09/15/2014 04:45 PM, Nathaniel McCallum wrote:
> > FYI, for any Fedora testers out there, we have updated to 4.0.3 in
> > Fedora 21 in part because it substantially reduces the size of the
> > install media for the upcoming Alpha release. If you'd like to test and
> > provide feedback on the packages, the link is here:
> >
> > https://admin.fedoraproject.org/updates/FEDORA-2014-10811
> 
> Actually, this update came too late for the Alpha. It will be considered 
> for Beta.
> 
> 
> Use the updates-testing repo if you want to test FreeIPA in f21 Alpha.

https://qa.fedoraproject.org/blockerbugs/milestone/21/alpha/buglist

See bug: 1117432.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] [Freeipa-devel] Announcing FreeIPA 4.0.3

[Nathaniel McCallum]

FYI, for any Fedora testers out there, we have updated to 4.0.3 in
Fedora 21 in part because it substantially reduces the size of the
install media for the upcoming Alpha release. If you'd like to test and
provide feedback on the packages, the link is here:

https://admin.fedoraproject.org/updates/FEDORA-2014-10811

On Fri, 2014-09-12 at 22:26 +0200, Petr Viktorin wrote:
> The FreeIPA team would like to announce FreeIPA v4.0.3 bugfix release!
> 
> It can be downloaded from http://www.freeipa.org/page/Downloads. The 
> builds will be available for Fedora 21 Beta. Builds for Fedora 20 are 
> available in the official 
> [https://copr.fedoraproject.org/coprs/mkosek/freeipa/ COPR repository].
> 
> == Bug fixes in 4.0.3 ==
> * Several issues concerning integration with 389 Directory Server 1.3.3 
> were fixed.
> * An upgrade crash was fixed.
> 
> == Known Issues ==
> * On Fedora 21 Alpha, FreeIPA server configuration should be done after 
> upgrading packages from updates-testing.
> 
> == Upgrading ==
> An IPA server can be upgraded simply by installing updated rpms. The 
> server does not need to be shut down in advance.
> 
> Please note that if you are doing the upgrade in special environment 
> (e.g. FedUp) which does not allow running the LDAP server during upgrade 
> process, upgrade scripts need to be run manually after the first boot:
> 
>   # ipa-ldap-updater --upgrade
>   # ipa-upgradeconfig
> 
> Also note that the performance improvements require an extended set of 
> indexes to be configured. RPM update for an IPA server with a excessive 
> number of users may require several minutes to finish.
> 
> If you have multiple servers you may upgrade them one at a time. It is 
> expected that all servers will be upgraded in a relatively short period 
> (days or weeks, not months). They should be able to co-exist peacefully 
> but new features will not be available on old servers and enrolling a 
> new client against an old server will result in the SSH keys not being 
> uploaded.
> 
> Downgrading a server once upgraded is not supported.
> 
> Upgrading from 3.3.0 and later versions is supported. Upgrading from 
> previous versions is not supported and has not been tested.
> 
> An enrolled client does not need the new packages installed unless you 
> want to re-enroll it. SSH keys for already installed clients are not 
> uploaded, you will have to re-enroll the client or manually upload the keys.
> 
> == Feedback ==
> Please provide comments, bugs and other feedback via the freeipa-users 
> mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or 
> #freeipa channel on Freenode.
> 
> == Detailed Changelog since 4.0.2 ==
> === David Kupka (1) ===
> * Fix typo causing ipa-upgradeconfig to fail.
> 
> === Ludwig Krispenz (1) ===
> * Update SSL ciphers configured in 389-ds-base
> 
> === Nathaniel McCallum (1) ===
> * Update qrcode support for newer python-qrcode
> 
> === Petr Viktorin (4) ===
> * Update referential integrity config for DS 1.3.3
> * permission plugin: Auto-add operational atttributes to read permissions
> * Allow deleting obsolete permissions; remove operational attribute 
> permissions
> * Become IPA 4.0.3
> 
> ___
> Freeipa-devel mailing list
> freeipa-de...@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel


-- 
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] Using external KDC

[Nathaniel McCallum]

On Mon, 2014-03-10 at 14:50 -0400, Dmitri Pal wrote:
> On 03/10/2014 10:32 AM, Nathaniel McCallum wrote:
> > On Sat, 2014-03-08 at 18:53 -0500, Dmitri Pal wrote:
> >> On 03/08/2014 04:36 PM, Trey Dockendorf wrote:
> >>> I got a RHEL7-beta VM up and running with basic ipa install (no DNS and 
> >>> no NTP).
> >>>
> >>> IPA is 3.3.3-5.el7
> >>> SSSD is 1.11.2-1.el7
> >>> krb5 is 1.11.3-31.el7
> >>>
> >>> Based on the docs at http://www.freeipa.org/page/V3/OTP I attempted
> >>> the CLI commands under "Feature Management", with no luck.
> >>>
> >>> For example:
> >>>
> >>> ---
> >>> # ipa config-mod --user-auth-type=['password', 'otp', 'radius']
> >>> Usage: ipa [global-options] config-mod [options]
> >>>
> >>> ipa: error: no such option: --user-auth-type
> >>> ---
> >>>
> >>> The ipa subcommands "radiusproxy-*" do not exist either.
> >>>
> >>> What version of IPA should I use to test this proof of concept?  The
> >>> docs mention needing Kerberos no earlier than 1.12, which isn't
> >>> available in EL7.
> >>>
> >>> My understanding of Kerberos is not great, but is FreeIPA simply not
> >>> designed for external Kerberos (like the use of an external CA)?  Is
> >>> there possibly a way to utilize FreeIPA without Kerberos, and just
> >>> manage 389DS while still using the web interface (hard to find good
> >>> Identity Management Web UI) and CLI tools?  I'd still like to get this
> >>> working in FreeIPA, but am working on upgrading our HPC cluster to EL6
> >>> (or EL7) and moving to FreeIPA would be a great improvement over 389DS
> >>> in terms of manageability.
> >>>
> >> Nathaniel, do we have a build of the latest bits for RHEL7 somewhere?
> >> Can you help with this POC please?
> > None of those commands will be present in EL 7.0 and we don't currently
> > have EL 7.0 builds of FreeIPA 4.0 master to my knowledge.
> 
> I thought we have something that builds latest bits for RHEL. If not is 
> it hard to produce one?

http://koji.fedoraproject.org/koji/packageinfo?packageID=11554

Koji doesn't currently list an EPEL build of IPA, most likely because
such a package would disturb the EL packages. We could create a Copr
build for EL6, but I don't know how many dependencies it would drag in.
If the dependencies are minimal, the job would be fairly easy. I may
take a stab at this later this week.

> > It would be possible to do this via manual manipulation of the LDAP
> > entries. You'd need to create an ipatokenRadiusConfiguration object and
> > then add the ipatokenRadiusProxyUser class (ipatokenRadiusConfigLink
> > attribute) to each user you'd like to proxy.
> >
> > However, I don't think manual manipulation of LDAP like this is a
> > supported operation. I would also imagine that your University may look
> > down on an intentional man-in-the-middle password proxy.
> >
> > Nathaniel
> >
> Nathaniel. All the security disclaimers have been mentioned earlier in 
> the thread.
> While I agree with you from security POV proxy is a solution that 
> already in place so it is not worse than now.

Yup, I just wanted to make sure I covered the disclaimers in full in the
same email detailing how to enable it. :)

Nathaniel

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Using external KDC

[Nathaniel McCallum]

On Sat, 2014-03-08 at 18:53 -0500, Dmitri Pal wrote:
> On 03/08/2014 04:36 PM, Trey Dockendorf wrote:
> > I got a RHEL7-beta VM up and running with basic ipa install (no DNS and no 
> > NTP).
> >
> > IPA is 3.3.3-5.el7
> > SSSD is 1.11.2-1.el7
> > krb5 is 1.11.3-31.el7
> >
> > Based on the docs at http://www.freeipa.org/page/V3/OTP I attempted
> > the CLI commands under "Feature Management", with no luck.
> >
> > For example:
> >
> > ---
> > # ipa config-mod --user-auth-type=['password', 'otp', 'radius']
> > Usage: ipa [global-options] config-mod [options]
> >
> > ipa: error: no such option: --user-auth-type
> > ---
> >
> > The ipa subcommands "radiusproxy-*" do not exist either.
> >
> > What version of IPA should I use to test this proof of concept?  The
> > docs mention needing Kerberos no earlier than 1.12, which isn't
> > available in EL7.
> >
> > My understanding of Kerberos is not great, but is FreeIPA simply not
> > designed for external Kerberos (like the use of an external CA)?  Is
> > there possibly a way to utilize FreeIPA without Kerberos, and just
> > manage 389DS while still using the web interface (hard to find good
> > Identity Management Web UI) and CLI tools?  I'd still like to get this
> > working in FreeIPA, but am working on upgrading our HPC cluster to EL6
> > (or EL7) and moving to FreeIPA would be a great improvement over 389DS
> > in terms of manageability.
> >
> 
> Nathaniel, do we have a build of the latest bits for RHEL7 somewhere?
> Can you help with this POC please?

None of those commands will be present in EL 7.0 and we don't currently
have EL 7.0 builds of FreeIPA 4.0 master to my knowledge.

It would be possible to do this via manual manipulation of the LDAP
entries. You'd need to create an ipatokenRadiusConfiguration object and
then add the ipatokenRadiusProxyUser class (ipatokenRadiusConfigLink
attribute) to each user you'd like to proxy.

However, I don't think manual manipulation of LDAP like this is a
supported operation. I would also imagine that your University may look
down on an intentional man-in-the-middle password proxy.

Nathaniel

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] i could use some help with installing FreeIPA

[Nathaniel McCallum]

On Mon, 2013-12-16 at 22:30 -0500, Rob Crittenden wrote:
> Dmitri Pal wrote:
> > On 12/16/2013 06:46 PM, Galen Brownsmith wrote:
> >> My install fails on the invocation of pkispawn with a Socket Error in
> >> the pki-ca-spawn log  ; anyone have any ideas?  (It isn't the issue
> >> with special characters in the DM's password, as my Directory Manager
> >> and IPA Admin passwords may be 32 characters long, but only contain
> >> [A-Za-z0-9_] )
> >>
> >> Configuration and Error Messages follow.
> >>
> >> Target System: Fedora19 64bit LXC Container running on top of a
> >> Fedora19 64bit host.  Kernel 3.11.10, Q9550 Intel CPU.
> >> Attempting to install freeipa server 3.3.3 .  SEllinux has been set to
> >> 'disabled' on the host and container.
> >>
> >> /etc/hosts:
> >> # IPFQDNAlias(es)
> >> 127.0.0.1   localhost.localdomain   localhost localhost4
> >> 192.168.253.94 woeg.marphod.net  woeg
> >>
> >> # Peers
> >> 192.168.253.99 skete.marphod.net  skete
> >> wiki.marphod.net  wiki www.marphod.net
> >>  www
> >> [... several more machines]
> >>
> >> /etc/resolv.conf
> >> ; generated by /usr/sbin/dhclient-script
> >> search marphod.net 
> >> nameserver 192.168.253.1
> >>
> >> /etc/sysconfig/network:
> >> NETWORKING=yes
> >> HOSTNAME=woeg.marphod.net 
> >>
> >> No software firewall on the Container:
> >> # iptables -L
> >> Chain INPUT (policy ACCEPT)
> >> target prot opt source destination
> >>
> >> Chain FORWARD (policy ACCEPT)
> >> target prot opt source destination
> >>
> >> Chain OUTPUT (policy ACCEPT)
> >> target prot opt source   destination
> >>
> >>
> >> Not using NetworkManager.  The machine has a virtual nic, and is
> >> connected to the bridge on the host, and can interact with the outside
> >> world.
> >>
> >> Installation commands:
> >> # ipa-server-install --uninstall -U
> >> # pkidestroy -s CA -i pki-tomcat
> >> # ipa-server-install -N -d --no-host-dns
> >>
> >> I select the defaults during the interactive install.
> >>
> >> During installation, everything seems to run fine up to the invocation
> >> of pkispawn.   I then get the errors:
> >> 
> >> Installing CA into /var/lib/pki/pki-tomcat.
> >> Storing deployment configuration into
> >> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
> >> Installation failed.
> >>
> >> ipa : DEBUGstderr=Job for pki-tomcatd@pki-tomcat.service
> >> failed. See 'systemctl status pki-tomcatd@pki-tomcat.service' and
> >> 'journalctl -xn' for details.
> >> pkispawn: ERROR... server failed to restart
> >>
> >> ipa : CRITICAL failed to configure ca instance Command
> >> '/usr/sbin/pkispawn -s CA -f /tmp/tmpwNB5bU' returned non-zero exit
> >> status 1
> >> ipa : DEBUG  File
> >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
> >> line 622, in run_script
> >> return_value = main_function()
> >>
> >>   File "/usr/sbin/ipa-server-install", line 1074, in main
> >> dm_password, subject_base=options.subject)
> >>
> >>   File
> >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
> >> line 478, in configure_instance
> >> self.start_creation(runtime=210)
> >>
> >>   File
> >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line
> >> 364, in start_creation
> >> method()
> >>
> >>   File
> >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
> >> line 604, in __spawn_instance
> >> raise RuntimeError('Configuration of CA failed')
> >>
> >> ipa : DEBUGThe ipa-server-install command failed,
> >> exception: RuntimeError: Configuration of CA failed
> >> Configuration of CA failed
> >> 
> >>
> >> the relevant errors from /var/log/pki/pki-ca-spawn.timestamp.log: (the
> >> ... skipping... is from the file)
> >> 
> >> ...skipping...
> >> y still be down
> >> 2013-12-16 18:12:23 pkispawn: DEBUG... No connection -
> >> exception thrown: Cannot connect to proxy. Socket error: [Errno 111]
> >> Connection refused.
> >> 2013-12-16 18:12:24 pkispawn: DEBUG... No connection -
> >> server may still be down
> >> 2013-12-16 18:12:24 pkispawn: DEBUG... No connection -
> >> exception thrown: Cannot connect to proxy. Socket error: [Errno 111]
> >> Connection refused.
> >> 2013-12-16 18:12:25 pkispawn: DEBUG... No connection -
> >> server may still be down
> >> ...
> >> (error repeated 12 more times)
> >> ...
> >> 2013-12-16 18:12:39 pkispawn: ERROR... server failed to
> >> restart
> >> 2013-12-16 18:12:39 pkispawn: DEBUG... Error Type: SystemExit
> >> 2013-12-16 18:12:39 pkispawn: DEBUG... Error Message: 1
> >> 2013-12-16 18:12:39 pkispawn: DEBUG...   File
> >> "/usr/sbin/pkispawn", line 374, in main
> >> rv = instance.

[Freeipa-users] Announcing FreeOTP for Android

[Nathaniel McCallum]

I’d like to announce the general availability of FreeOTP for Android. It
is available for install now in the Google Play store[1].

FreeOTP is a multi-factor authentication client based on the HOTP and
TOTP standards. FreeOTP features:

* A FLOSS code base
* Support for HOTP or TOTP
* Native QR code scanning
* Adherence to the Android UI design principles
* Tablet support

We anticipate that FreeOTP should work with any server providing HOTP or
TOTP support, including the upcoming OTP support[2] in FreeIPA.

So, if you fancy a bit of adventure, please try FreeOTP! We welcome your
feedback. Please also don’t forget to leave your positive reviews on
Google Play so that it will be easier for other Android users to find
out about FreeOTP.

We have also developed FreeOTP for iOS and are currently working to
bring it to the Apple App Store. Please stay tuned for future news!

The FreeOTP project is hosted on Fedora Hosted[3]. We welcome your
feedback and contributions.

[1]
https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp

[2] http://www.freeipa.org/page/V3/OTP

[3] http://freeotp.fedorahosted.org

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Can FreeIPA use FreeRADIUS as users provider

[Nathaniel McCallum]

On Sat, 2012-03-03 at 18:09 -0500, Dmitri Pal wrote:
> On 03/01/2012 09:21 AM, Pavel Zhukov wrote:
> > Simo, thank you for your answer 
> > FreeRADIUS uses very customized (for complex network ACLs)  MySQL schema 
> > and network team
> > manages it. Unfortunately, I cannot change FreeRADIUS related
> > infrastructure. 
> >
> AuthHub is your friend then.
> https://fedorahosted.org/AuthHub/
> 
> I am CC Nathaniel who is the developer on this project. I know he is
> looking into RADIUS integration. Any help would be appreciated.

So the answer is that AuthHub will support RADIUS very soon (it is
currently our highest priority). This means that krb5 >= 1.10 + AuthHub
will soon support RADIUS. When this support will hit FreeIPA directly,
I'm not sure. But we can definitely use as much help testing AuthHub as
possible.

Nathaniel


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users