[Freeipa-users] OTP: using external validation server for Yubikeys?

[Jochen Hein]

Hi,

I'm running my own privacyidea instance to manage my Yubikey and other
OTP tokens. Right now I have to decide, in which system my Yubikey is
managed - right now it is in privacyidea. My token is in yubico mode, so
no HOTP/TOTP for now.

For now I run a FreeRADIUS as a frontend to privacyidea and use that in
FreeIPA to authenticate my user, but I think it is too complex and
fragile for my small installation. And FreeIPA is dependent on an
external userstore (for me Kolab's dirsrv right now) as well.

What I'd find useful is something like the following:

- A yubikey token generates a 44 character OTP, the first 12 characters
  identify the token. This could be a factory initialized token or a
  locally initialized one.

- A user has a yubikey token assigned (the 12 characters identifier) and
  a validation server that will check the OTP. Default servers could be
  yubico's validation servers
  (https://api.yubico.com/wsapi/2.0/verify?id=%d=%s) while it should
  be possible to use a self hosted infrastructure with yubico's software
  or something like privacyidea or linotp (somewhat similar to the
  RADIUS configuration)

  The validation protokoll is explained at
  https://developers.yubico.com/yubikey-val/Validation_Protocol_V2.0.html
  and is quite simple.
  
  Authentication option for the user would be password+OTP.

- When logging in the user is first asked for the first factor
  (password), and then the second factor (OTP). ipa-otp would hand off
  the validation to the external server and act according to the
  response.

That way a yubikey token you be used for other applications (like
Kolab/Roundcube, pam_yubico etc.) as well as for FreeIPA, because the
secret and counter are stored in one central system that is queried by
all applications.

Something like that would possibly require changes to the LDAP schema[1]
in addition to changes to ipa-otp, ipa, and the webui.  Do you think
something like that would be useful?

Jochen

[1] Kolab documents this at https://git.kolab.org/T414:
The Roundcube plugin is basically functional to run locally as of commit
rRPK9cd117d7. There's some documentation about the kolab_2fa plugin, its
components, installation and configuration in the README.md. Please note
that the Yubikey driver doesn't work with the LDAP storage due to
missing coverage in the FreeIPA schema.

-- 
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] is ipa-client-automount idempotent?

[William Muriithi]

Hi

On 30 October 2016 at 03:26, William Muriithi
 wrote:
> Morning,
>
> I am curious to know if ipa-client-automount would be safe to rerun
> multiple times.  I have done a bit of google search and this don't
> seem to have been discussed previously in this list.
>

Ignore this question please.  I have figured the answer to my
question.  Its not idempotent

Regards,

William

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

[Freeipa-users] is ipa-client-automount idempotent?

[William Muriithi]

Morning,

I am curious to know if ipa-client-automount would be safe to rerun
multiple times.  I have done a bit of google search and this don't
seem to have been discussed previously in this list.

I have attempted to rerun it on a system multiple time and don't seem
to break anything, but that don't mean its not messing around with
configuration file somehow.

Regards,
William

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

Re: [Freeipa-users] ipa automount bug?

[William Muriithi]

Rob,

>>>
>>> 2. How would one import an existing maps to ipa auto.home map.  Import
>>> seem to be only capable of importing to auto.master, which make its
>>> utility doubtful
>>>
>>> [root@hydrogen ~]# ipa automountlocation-import  default
>>> /tmp/2016-10-26/auto.home
>>>
>>> Imported maps:
>>> Imported keys:
>>>
>>> Added adam to auto.master
>>> ..
>>>
>>> I think we should have a flag that allow importation of key to other
>>> other maps other than auto.master
>
>
> You're right, auto.master is hardcoded. Please open an RFE for this if you
> need to be able to specify the mount.

Thanks for confirming a problem.  Will open a ticket on it this morning
>
> rob
>
Regards,

William

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

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

[Petr Vobornik]

On 10/21/2016 02:13 PM, Sébastien Julliot wrote:
> Hi everyone,
> 
> 
> In order to prevent administrators to make mistakes that could have
> 
> silly consequences, I would like to set "preserve" as the default selected
> 
> action in freeipa's webui.
> 
> What do you think would be the best way to achieve this ?

1. Quick, more work:

Create Web UI plugin which would change the hardcoded default to the
other value:
  related code:
https://git.fedorahosted.org/cgit/freeipa.git/tree/install/ui/src/freeipa/user.js#n989
  example plugins: https://pvoborni.fedorapeople.org/plugins/
  plugin info: https://pvoborni.fedorapeople.org/doc/#!/guide/Plugins

2. Uncertain delivery:
File a ticket to change default or make it configurable(IMO better). Let
core team to implement it. But note that there is quite a big number of
other tickets which we prioritize.

https://fedorahosted.org/freeipa/newticket

3. Do #2 and contribute patch for it. When reviewed, it would then go to
currently developed version(4.5). This might be more work then #1.

4. dirty: change the default directly in Web UI code. Doesn't work well
with upgrades, not supported, hard to find it in minimized code.

> 
> 
> Thank you in advance,
> 
> Sebastien Julliot.
> 
-- 
Petr Vobornik

-- 
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 domains and sub-domains

[Brian Candler]

On 27/10/2016 10:07, Brian Candler wrote:
To the OP: in that case, I'd still recommend that you choose a 
distinct kerberos realm like IPA.YOURCOMPANY.COM, with associated 
primary domain "ipa.yourcompany.com", and let FreeIPA manage that 
domain so that it sets up all the right SRV records for 
auto-discovery.  But you don't need to put any hosts inside that DNS 
domain at all. 


Aside: I have just been trying this out.

What's slightly confusing is that the ipa server-install process 
requires you to set a "domain name" as well as a realm, and it's not 
clear to me which "domain" to put here. Is this the domain which 
corresponds to the realm, or the domain which the clients normally 
reside in, or something else?


For example, suppose I have realm IPA.MYCOMPANY.COM but my servers are 
xxx.int.mycompany.com.  Should I set the FreeIPA "domain" to 
ipa.mycompany.com or int.mycompany.com, or mycompany.com ?


After some experimentation, it seems that the LDAP baseDN is always 
taken from the realm (dc=ipa,dc=mycompany,dc=com). But the DNS domain is 
used for:


- nisDomain and associatedDomain
- ipaDefaultEmailDomain
- crucially, the SRV records are published under the DNS domain

So it looks like really you should put "ipa.mycompany.com" as the DNS 
domain, even if the IPA servers are in a different domain.


Regards,

Brian.

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

Re: [Freeipa-users] PWM password self-service integration with FreeIPA

[Elwell, Jason]

I have updated the gist using the PWM documentation I found to do just
that.  Let me know if that is more acceptable.  I'm feeling my way through
this, please pardon my lack of savoir-faire.

See latest at
https://gist.github.com/PowerWagon/d794a1233d7943f1614d2ae5223e678a

*Jason Elwell*

*Office: 205-298-3731 *

*Cell: 205-603-4195 *

elwe...@vmcmail.com

E-mail Confidentiality Footer

Privileged/Confidential Information may be contained in this message. If
you are not the addressee indicated in this message (or responsible for
delivery of the message to such person), you may not copy or deliver this
message to anyone. In such case, you should destroy this message, and
notify the sender immediately. If you or your employer does not consent to
e-mail messages of this kind, please advise the sender immediately.
Opinions, conclusions and other information expressed in this message are
not given or endorsed by employer unless otherwise indicated by an
authorized representative independent of this message

On Tue, Oct 25, 2016 at 9:01 AM, Simo Sorce  wrote:

> On Sun, 2016-10-23 at 12:22 -0500, Elwell, Jason wrote:
> > I posted this on the PWM boards, and figured I'd send this along here,
> > too.  I'm looking for feedback on this.  Let me know if you find this
> > accurate and/or valuable.  Thanks!
> >
> >
> > PWM setup for FreeIPA
> > https://gist.github.com/PowerWagon/d794a1233d7943f1614d2ae5223e678a
> >
> > PwmConfiguration-template.xml
> > https://gist.github.com/PowerWagon/0e83a0c5b67316a6987944b76eb103bc
>
> Jason,
> It seems to me your ACIs are too lax, you should also make the PWM user
> a password synchronization agent and not just give it blanket access to
> read everything from the directory and write every password, you should
> limit it to users for example and not allow it to change service's or
> host's "passwords".
>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] cn=deleted users,cn=accounts

[Pavel Vomacka]

Hello Michael,

Yes, the deleter dialog on details page was extended in version 4.4 ( 
https://fedorahosted.org/freeipa/ticket/5370 ).


On 10/27/2016 02:45 PM, Michael Ströder wrote:

Michael Ströder wrote:

I wonder which action in the FreeIPA Web UI (4.2.0) moves an active user to
this container:

cn=deleted users,cn=accounts,cn=provisioning,dc=example,dc=com

Selecting [Delete] as action really deletes the LDAP entry.

Ah, found it myself:
It makes a difference choosing action [Delete] when displaying a single user
entry or from the user overview table. The latter asks whether to preserve the
entry or not.

Is this UI inconsistency fixed in a later release?

Ciao, Michael.






--
Pavel^3 Vomacka

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