Re: [Freeipa-users] Why OTP not working

[Jochen Hein]

Andrey Dudin  writes:

> I trying to use OTP auth in Freeipa but have some problems.

OTP (with RADIUS) works for me.

> I have user *test:*
>
> [root@ipa-centos]# ipa user-show test
...

Did you enable --user-auth-type=otp with "ipa config-mod"?  I have:

[root@freeipa1 log]# ipa config-show --raw
...
  ipauserauthtype: otp
  ipauserauthtype: password
  ipauserauthtype: radius

Look at the mouse-over-docs in Webui -> IPA-Server -> Configuration ->
User Authentication Types for more info.

Otherwise, you need to enable --user-auth-type=otp for your user.  I
have for RADIUS both password and radius for my OTP user:

[root@freeipa1 log]# ipa user-show jochen --raw
...
  ipauserauthtype: password
  ipauserauthtype: radius

If you need both password and otp, use both --user-auth-type=password
and --user-auth-type=otp for "ipa user-mod" or "ipa config-mod".

When I do a "su - jochen", I get asked for "First Factor" and "Second
Factor", since sssd knows I use RADIUS for OTP.  That might be easier to
first test that you can authenticate with OTP.

> Server with FreeIpa:
>
> [root@ipa-centos]# ipa host-show ipa-centos.mydomain.com
...
>   Authentication Indicators: otp

Is there a simple way to check on the command line, whether or not an
authentication indicator was set when authenticating?  I can't remember
anything from reading the docs - I expected some option for klist.

Jochen

-- 
This space is intentionally left blank.

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

[Jochen Hein]

"B.harries"  writes:

> Second attempt
> We then tried to install a fresh CentOS server, having FreeIPA version
> 4.4 and attaching it as a second master to our IPA instance. This
> however didn't work out as well,

I did that to move my installation from Fedora to CentOS - it worked
quite well.  First adding a replica failed, because python-jwcrypto on
CentOS is quite old.  I've installed the package from Fedora
(python-jwcrypto-0.3.2-1.fc23.noarch.rpm) and all went well.  After I
decomissioned the Fedora system I've downgraded the package again.

That's what I found:
https://www.redhat.com/archives/freeipa-users/2016-December/msg00024.html
(Re: [Freeipa-users] Add 4.4 replica to 4.3 server fails)

Can you provide logs/messages what didn't work?

Jochen

-- 
This space is intentionally left blank.

-- 
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-replica-manage failing to delete a node

[Jochen Hein]

"Linder, Rolf"  writes:

> mainly our synchronization stopped with uspidm02 (replica) logging:
>
> "[27/Mar/2017:11:57:39.756880208 +0200] NSMMReplicationPlugin -
> agmt="cn=meTouspidm01.[domainname].[tld]" (uspidm01:389): Data
> required to update replica has been purged from the changelog. The
> replica must be reinitialized."
>
> We tried to re-initialize using "ipa-replica-manage re-initialize
> --from uspidm01.[domain].[tld]" but this failed. After this we headed
> for a "clean" first remove then add again solution (knowing that we
> will temporarily loss the replica and loss any unsynchronized
> changes).

I had these messages too, and also failed to get it running with
ipa-replicate-manage.  But later I realiazed that the failing replica
was a CA replica, and using ipa-careplica-manage I could reinitialize
the replica.

I found it also mildly confusing, which server was ok and which server
needed the replica reinitialized. Could we add a hint to the log what
the admin needs to do?  Something like:

,
|  Data required to update replica has been purged from the
|  changelog. The replica  must be reinitialized.
|  Use "ipa-(ca)?replica-manage ... --from " on "".
`

Jochen

-- 
This space is intentionally left blank.

-- 
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] Ubuntu client 2FA not working

[Jochen Hein]

Tommy Nikjoo  writes:

> I'm having some issues with 2FA PAM config's on Ubuntu clients. 
> Currently, I'm guessing that the PAM module doesn't know how to talk to
> the 2FA protocol.  Is anyone able to give an in site into how to get
> this working correctly?

Can you provide logs what doesn't work? See also my report in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856307
In short: without _kerberos._udp entries it should work out-of-the-box.

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] Ubuntu client 2FA not working

[Jochen Hein]

Tommy Nikjoo  writes:

> I'm having some issues with 2FA PAM config's on Ubuntu clients. 
> Currently, I'm guessing that the PAM module doesn't know how to talk to
> the 2FA protocol.  Is anyone able to give an in site into how to get
> this working correctly?

I'm not finished with my quest, but I think I got at least some hints.
Right now I'm not trying with pam/sss, but with kinit alone. I do have
two IPA servers and in the default configuration I see:

$ KRB5_TRACE=/dev/stderr kinit -T KEYRING:persistent:1004:krb_ccache_UhNqkJ3 
jochen
[15136] 1488197822.55857: Resolving hostname freeipa1.example.org.
[15136] 1488197822.57587: Sending initial UDP request to dgram 192.168.30.121:88
[15136] 1488197822.60106: Received answer (546 bytes) from dgram 
192.168.30.121:88
[15136] 1488197822.60994: Response was from master KDC
[15136] 1488197822.61069: Received error from KDC: -1765328359/zusätzlich 
Vorauthentifizierung erforderlich
[15136] 1488197822.61093: Decoding FAST response
[15136] 1488197822.61282: Processing preauth types: 136, 141, 133, 137
[15136] 1488197822.61298: Received cookie: MIT
Enter your OTP password: 
[15136] 1488197829.991232: Preauth module otp (141) (real) returned: 0/Success
[15136] 1488197829.991271: Produced preauth for next request: 133, 142
[15136] 1488197829.991289: Encoding request body and padata into FAST request
[15136] 1488197829.991518: Sending request (1221 bytes) to EXAMPLE.ORG
[15136] 1488197829.993141: Resolving hostname freeipa1.example.org.
[15136] 1488197829.993873: Sending initial UDP request to dgram 
192.168.30.121:88
[15136] 1488197830.994965: Resolving hostname freeipa2.example.org.
[15136] 1488197830.995866: Sending initial UDP request to dgram 
192.168.30.122:88
[15136] 1488197831.128141: Received answer (546 bytes) from dgram 
192.168.30.121:88
[15136] 1488197831.129630: Response was from master KDC
[15136] 1488197831.129731: Received error from KDC: 
-1765328360/Vorauthentifizierung fehlgeschlagen
[15136] 1488197831.129764: Decoding FAST response
[15136] 1488197831.129953: Preauth tryagain input types: 136, 141, 133, 137
kinit: Vorauthentifizierung fehlgeschlagen bei Anfängliche Anmeldedaten werden 
geholt.

We ask the first ipa server for preauth, after I've entered the
password+OTP we ask the first server with UDP, but don't get an answer
within one second. So we ask the other server. Shortly after we get the
answer from the first server.

If I use only one KDC in krb5.conf:
  dns_lookup_kdc = false
...
kdc = freeipa1.example.org

we only ask that server and get the correct answer.

So I see two questions for now:
- Why do we ask both servers with such a short timeout?
- Why do we use UDP when using dns_lookup_kdc, even if I have 
"udp_preference_limit = 1" set?

My FreeIPA servers ask themselves, so they don't use DNS. I'll try to check a 
normal client.
Hm, one CentOS client has krb5-workstation-1.14.1-27.el7_3.x86_64 and works 
fine.
My Debian host I analyzed here has krb5-user 1.15-1.

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

[Freeipa-users] named-pkcs11: dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute; cnamerecord': unknown class/type

[Jochen Hein]

When reloading named I get the following message 8 times:

Feb 26 05:30:27 freeipa2 named-pkcs11[4935]: dns_rdatatype_fromtext()
failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown
class/type

I do have cnames in my zones, but what is missing here?
DNS seems to work fine for CNAMEs.

I'm running CentOS 7.3.

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] named-pkcs11: option 'serial_autoincrement' is not supported, ignoring

[Jochen Hein]

Jochen Hein <joc...@jochen.org> writes:

> I'm implementing logcheck on my server and found the following message
> in my logs:
>
>> Feb 26 05:30:26 freeipa2 named-pkcs11[4935]: option 'serial_autoincrement' 
>> is not supported, ignoring

> | Updates and Upgrades
> | 
> | Replace serial_autoincrement option in /etc/named.conf with serial_remote 
> option.
> | Dependencies
> `

I just tried that and got a message that serial_remote is unknown.
I run a current CentOS 7.3 server.

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

[Freeipa-users] named-pkcs11: option 'serial_autoincrement' is not supported, ignoring

[Jochen Hein]

I'm implementing logcheck on my server and found the following message
in my logs:

> Feb 26 05:30:26 freeipa2 named-pkcs11[4935]: option 'serial_autoincrement' is 
> not supported, ignoring

>From reading
http://www.freeipa.org/page/V3/DNS_SOA_serial_auto-incrementation there
was an implementation in IPA, but it has been changed to
'serial_remote':

,
| Feature Management
| 
| Add new option like serial_remote to /etc/named.conf. This option should 
be mutually exclusive with serial_autoincrement option from IPA 3.0.
| Do not create UI for enabling/disabling this feature. We can provide some 
boolean directly in plugin configuration, but nothing else.
| 
| Replication
| 
| No change from IPA 3.0.
| Updates and Upgrades
| 
| Replace serial_autoincrement option in /etc/named.conf with serial_remote 
option.
| Dependencies
`

My servers started with FreeIPA 4 - is there some configuration/upgrade
change missing?

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] Ubuntu client 2FA not working

[Jochen Hein]

Tommy Nikjoo  writes:

> I'm having some issues with 2FA PAM config's on Ubuntu clients. 
> Currently, I'm guessing that the PAM module doesn't know how to talk to
> the 2FA protocol.  Is anyone able to give an in site into how to get
> this working correctly?

You may need to fix /etc/pam.d/common-auth, so that only pam_sss get's
called for IPA users:

# here are the per-package modules (the "Primary" block)
auth[default=1 success=ok] pam_localuser.so 
auth[success=3 default=ignore]  pam_unix.so nullok_secure try_first_pass
authrequisite pam_succeed_if.so uid >= 1000 quiet_success
auth[success=1 default=ignore]  pam_sss.so forward_pass
# here's the fallback if no module succeeds
authrequisite   pam_deny.so


I'm running a 14.04 client with an older IPA client - there I have to
enter password+OTP in one string and it works perfect.

On my 16.10 Laptop I use IPA 4.3.2 against CentOS 7.3 server. That
client had problems with OTP users which were not obvious to me.
The system asked for first and second factor but would give me system
error 7. I think the following entry in /etc/krb5.conf helped:

[libdefaults]
...
  default_ccache_name = KEYRING:persistent:%{uid}

[realms]
...

Otherwise please enable the debug trace and review the logs. They are
really verbose and you need to check both client and server for errors.
There is hope - I run Ubuntu clients with OTP user (OTP is via
privacyidea/radius, but that shouldn't matter).

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] unable to delete a user - which has a double??

[Jochen Hein]

Hi

lejeczek  writes:

> I think it had something to do with an initial(long time ago)
> migration.
> How to safely delete such a user? Or one of them?
>
> $ ipa user-del appmgr --no-preserve
> ipa: ERROR: The search criteria was not specific enough. Expected 1
> and found 2.

Did you try "--continue"?

You can check both users with "ipa user-find ... --all" and look for the
ipauniqueid. I think you'll can remove the user with ldapremove. 

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] RFE: Documentation for creating OpenVPN certificates.

[Jochen Hein]

Phil Ingram  writes:

> I use FreeIPA and I would like to create certificates for peer-to-peer
> and remote-access VPNs.

I tried to replace may manual easy-CA certificates with FreeIPA ones,
but that didn't work out (but my fallback also broke). My "productive"
VPN connection for now is ocserv, but I'd like to get OpenVPN running
again.

> In speaking with Fraser Tweedale, we agree that the best way forward
> is to create a secondary CA for insulation; but we may also need to
> create a custom certificate profile, which is non-trivial. As an end
> user of FreeIPA, I would like documentation on how to do this.

I'm happy to try something and give feedback.  I think I'll have time at
the end of this month to work on OpenVPN again.

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

[Freeipa-users] Debian: libpam-sss pam-configs update?

[Jochen Hein]

Hi,

I'm still working on my Debian systems to get local login to work with
OTP.

In /etc/pam.d/common-auth we have:
auth[success=2 default=ignore]  pam_unix.so nullok_secure
auth[success=1 default=ignore]  pam_sss.so use_first_pass

On CentOS we have something more complicated in /etc/pam.d/system-auth:

auth[default=1 success=ok] pam_localuser.so
auth[success=done ignore=ignore default=die] pam_unix.so nullok 
try_first_pass
authrequisite pam_succeed_if.so uid >= 1000 quiet_success
authsufficientpam_sss.so forward_pass

I think we need something more elaborated for debian to replicate the
(good!) experience from CentOS when asking for "First/Second Factor".
The four lines from above work well, but how can we get that into
pam-auth-update? Any ideas how this could be packaged?

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] Minimum SSSD version for 2 factor

[Jochen Hein]

"Sean Hogan"  writes:

>I have been trying to find documentation on the required min sssd
> version needed to run otp (2 factor) with no luck.  Was hoping you all
> might know.
> I see RHEL 6.8 comes with 1.13 SSSD so was wondering if that would be high
> enough version to work with IPA 4.X OTP.

I'm running 2FA/OTP on Ubuntu 14.04 with the following sssd:
ii  sssd 1.12.5-1~trusty1i386
System Security Services Daemon -- metapackage

What you miss is the prompt "First Factor"/"Second Factor" and you must
concatenate password and OTP at the password prompt. Otherwise it works
fine.

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] Valid Sender ? - Re: Using Privacyidea with FreeIPA - part 1/n

[Jochen Hein]

Martin Basti <mba...@redhat.com> writes:

> Hello, I have a few comments/questions related to HOTP inline

Sure :-)

> On 28.12.2016 13:54, Jochen Hein wrote:
>>
>> I've settled for the following usage of the slots:
>>
>> * Slot 1: This is a (reprogrammed) Yubico-AES token, which
>>authenticates against Privacyides yubico mode instead of Yubicos
>>cloud server.
>>
>>Why Yubico and not HOTP or TOTP?
>>
>>Here FreeIPA fails for me: Yubikey can't do TOTP, HOTP token can get
>>out of sync, when we use them for local authentication, FreeIPA and
>>Kolab (each application has a count, which needs to be "in near
>>sync" with the counter in the Yubikey. I wouldn't trust such a
>>setup.)
>
> AFAIK this is security feature to have "Window of allowed tokens" and
> counter is essential for HOTP,
> https://tools.ietf.org/html/rfc4226#section-7.2

Exactly. So it seems essential for me, that only one system can be the
owner of the token (has the secret and counter to check the validity of
an OTP).  This is for both HOTP and Yubico-AES (cloud validation).  So
at first they look more or less identical, but why did I choose Yubico?
Two usecases for me will work with yubico-AES, but not easily with HOTP
(or maybe as well...).

First is Kolab, my mailserver. With the current (development) release I
can use 2FA with HOTP/TOTP and yubico-AES.  Kolab wants to be the owner
of the HOTP/TOTP token, so the Yubikey couldn't be used for other
applications.  Right now there is no external validation for TOTP/HOTP
implemented.  But we can ask a yubico validation server
(e.g. privacyidea) which is the owner of my yubico AES token.

Second is pam_yubico, which asks my privacyidea server for validation.
For HOTP is might be possible to use something like
pam_googleauthenticator, but with Kolab I didn't see a solution.

So, one yubikey is enrolled privacyidea and can be used by multiple
applications with pam_yubico, yubico validation protocol and RADIUS, but
the secret and counter is only stored in privacyidea...


>>But providing access to a Yubico Token via privacyidea works for all
>>cases I have in mind.
>
> How they are checking the valid tokes if they don't use its counter?

Privacyidea is the "owner" of the token and has the secret and the
counter stored. Every other system (e.g. pam_yubico or FreeIPA) is
checking the validation against privacyiadea, either with the yubico
protocol, the privacyidey validation, or RADIUS.

Does this clarify the architecture of my system?

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

[Freeipa-users] Using Privacyidea with FreeIPA - part 1/n

[Jochen Hein]

[ This mail sets the stage for more parts, which will get into technical
details. Comments or suggestions are welcome, possibly we should add
refined texts in the relevant wikis/documentations. - Jochen ]

When I first looked at privacyidea I was quite unsure how it would
integrate into my existing network and what tokens and applications I
would use privacyidea for. After lots of thought and experiments I now
think I have a useful scenario to work with. I run a family network with
a local mail server (Kolab), webmail, ssh, and VPN access and think the
structure might also work for small or medium offices too.

Originally I had the userstore in Kolab's LDAP server which I wanted
to use for more applications, e.g. Linux logins.  pam_ldap and
pam_ldapd could access the userstore in LDAP, but require that the
server is available.  How should that work for a roadwarrior setup?
I've found sssd, but never had time to play with it.  So that idea
never got off the ground.

Former tries with Kerberos/LDAP have not been successful, but once I
found FreeIPA[1] I was kind of hooked.  FreeIPA has:

- LDAP as backend (e.g. userstore)
- a versatile command line interface ("ipa")
- a useful web interface
- client software to join a Linux machine into the FreeIPA realm
- sssd for clients by default
- works "out of the box"

If you need a central userstore with host based access control, SSO
and lots of other features - I can really recommend it.

I'll discuss later, what features I use with which software and why.

The latest FreeIPA version has some OTP features included, for example
Yubikeys or FreeOTP tokens.  So, why would you want to use another OTP
provider than FreeIPA?  I use (and plan to extend the usage) Yubikey
tokens. Since the Yubikeys only have two slots[2], we need to decide
what we want to use the slots for.

I want to have the following applications running with my Yubikeys:

- Second Factor for my keepass file
- Second Factor for login/ssh (later webmail access)
- Second Factor for sudo authentication

I've settled for the following usage of the slots:

* Slot 1: This is a (reprogrammed) Yubico-AES token, which
  authenticates against Privacyides yubico mode instead of Yubicos
  cloud server.

  Why Yubico and not HOTP or TOTP?

  Here FreeIPA fails for me: Yubikey can't do TOTP, HOTP token can get
  out of sync, when we use them for local authentication, FreeIPA and
  Kolab (each application has a count, which needs to be "in near
  sync" with the counter in the Yubikey. I wouldn't trust such a
  setup.)

  But providing access to a Yubico Token via privacyidea works for all
  cases I have in mind.

* Slot 2: Yubikey Challenge Response

  I use that as a second factor for my keepass file with
  keechallenge. The second application is my LUKS encrypted Laptop with
  privacyidea's privacyidea-luks-assign help. With pam_yubico I restrict
  access to Laptops with a second factor, without the need for a central
  authentication server[3]. For the laptops (local login) I skip
  entering a sudo password when a yubico is present and authenticated.

  Since there is no token count, the token will not get
  out of sync. 

For my local net u2f didn't seem useful, but I'll use it for remote
services.

I consider that design more secure than using only a password, but
also more convenient. Let's see how far that will take us.

[1] http://www.freeipa.org
[2] How does that relate to PIV, U2F, and smart card features?
[3] pam_python+privacyidea might help, but the packages are not in
distro repositories and even more of a niche product than pam_yubico.

The rest of this series expects that the PI host is enrolled in IPA.
On Debian/Ubuntu systems, add the ca.crt to the local ca store:

ln -s /etc/ipa/ca.crt /usr/local/share/ca-certificates update-ca-certificates


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

[Freeipa-users] Using Privacyidea with FreeIPA - use IPA as userstore

[Jochen Hein]

Jochen Hein <joc...@jochen.org> writes:

> [ This mail sets the stage for more parts, which will get into technical
> details. Comments or suggestions are welcome, possibly we should add
> refined texts in the relevant wikis/documentations. - Jochen ]

== Use IPA as our userstore in privacyidea ==

First we need an LDAP user to access the userstore. Store the
following in the file privacyidea-fetch.ldif on you IPA server:

dn: uid=privacyidea-fetch,cn=sysaccounts,cn=etc,dc=example,dc=org
changetype: add
objectclass: account
objectclass: simplesecurityobject
objectclass: top
uid: privacyidea-fetch
userPassword: 
passwordExpirationTime: 20380119031407Z
nsIdleTimeout: 0

Add the user to FreeIPAs 389-dirsrv [TODO: verify command]:

ldapadd -Y GSSAPI -f privacyidea-fetch.ldif

Define your LDAP resolver in Privacyidea as follows:

Server-URI: ldaps://.example.org
Base-DN:cn=users,cn=accounts,dc=example,dc=org
Bind-DN:uid=privacyidea-fetch,cn=sysaccounts,cn=etc,dc=example,dc=org
Bind-Type:  simple

Loginname Attribute:uid
Search Filter:  (uid=*)(objectClass=inetorgperson)
User Filter:(&(uid=%s)(objectClass=inetOrgPerson))
Attribute Mapping:  { "username": "uid", "phone" : "telephoneNumber",
"mobile" : "mobile", "email" : "mail",
"surname" : "sn", "givenname" : "givenName",
"description" : "gecos" }
UID Type:   ipaUniqueID

TODO:
Discuss options for UID Type. What should we recommend?
DN seems to work. Changing is a bad idea, because it invalidates the
token assignment to users.

ipaUniqueID has:

[2016-12-23
19:38:47,509][30665][140606770149120][WARNING][privacyidea.lib.resolvers.LDAPIdResolver:211]
failed to check password for
u'1c2ec066-648e-11e5-84ca-525400fe9f35'/u'uid=jochen,cn=users,cn=accounts,dc=jochen,dc=org':
Exception('Wrong credentials',)

TODO: when saving the resolver in privacyidea:
[2016-12-23
21:07:18,437][30665][140606770149120][WARNING][privacyidea.lib.resolver:130]
the passed key u'CACHE_TIMEOUT' is not a parameter for the resolver
u'ldapresolver'

Wishlist: Use SRV records from DNS to find the LDAP servers.

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

[Freeipa-users] Using Privacyidea with FreeIPA - SSL certificates for PI

[Jochen Hein]

Jochen Hein <joc...@jochen.org> writes:

> [ This mail sets the stage for more parts, which will get into technical
> details. Comments or suggestions are welcome, possibly we should add
> refined texts in the relevant wikis/documentations. - Jochen ]

== Get SSL certificate from IPA ==

Maintaining a local CA is cumbersome, certificates need to be
refreshed in regular intervals, and the CA certificate needs to be
available on all systems. And you need to chosse ciphers and other
parameters wisely (I didn't, so chrome complains about my local
certificates).

We need a couple of certificates anyway, so using some help is wise.
We need:

* SSL certificates for our local servers and services (letsencrypt might
  help, but I prefer my own CA.

* Certificates for user authentification for OpenVPN or OpenConnect.

Privacyidea has an option to connect to an external CA, but FreeIPA
has a well integrated and usable CA. We can get certificates for each
IPA-enrolled server, service, or user. The CA certificate is already
on each enrolled client, and the best of all: certmonger will refresh
certificates before they expire.

So, let's get a certificate from IPA for privacyidea. First we need 
to add a service principal to IPA, which will own the certificate:

ipa service-add HTTP/.example.org

Next we add a scipt to the privacyidea host to enable restarts after
the certificates have been refreshed
(e.g. /root/refresh_apache_certificate.sh):

#!/bin/bash
chmod 600 /etc/ssl/certs/privacyideaserver.pem
chown root:root /etc/ssl/certs/privacyideaserver.pem

chmod 600 /etc/ssl/private/privacyideaserver.key
chown root:root /etc/ssl/private/privacyideaserver.key

systemctl restart apache2.service

And now we are ready to request a certificate vom IPA:

ipa-getcert request -f /etc/ssl/certs/privacyideaserver.pem \
-k /etc/ssl/private/privacyideaserver.key \
-N "CN=$(hostname --fqdn)" -D $(hostname) \
-K HTTP/$(hostname --fqdn) \
-U 1.3.6.1.5.5.7.3.1 \
-C "/root/refresh_apache_certificate.sh"

Verify that the status is "MONITORING" with "ipa-getcert list".

When accessing your privacyidea server from an enrolled client you
should see a green lock and no certificate warnings.

I find that pretty impressive, after having fought with a local CA.

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

[Jochen Hein]

Alexander Bokovoy  writes:

>>* sssd has a default kerberos timeout of six seconds.
>>  Can be changed in /etc/sssd/sssd.conf: krb5_auth_timeout,
>>  which also seems to work for auth_provider = ipa, but is not
>>  documented in sssd-ipa(5).
> sssd-ipa(5) says:
> 
>   The IPA provider accepts the same options used by the
>   sssd-ldap(5) identity provider and the sssd-krb5(5)
>   authentication provider with some exceptions described
>   below.
> 
>
> I'm not sure how much we could improve here.

I just scanned the option list and did not read the complete text.

> It would be good to write an article on the wiki that covers privacyidea
> integration and explains the workflow.

Cornelius from Privacyidea already asked me for this, but I first wanted
to get something stable and useful running. Now it looks like that is
done I'll try to write something up.

> Technically, we have most of
> Kerberos client (SSS) -> KDC -> IPA-OTPD -> FreeRADIUS covered in
> http://www.freeipa.org/page/V4/OTP and
> http://www.freeipa.org/page/V4/OTP/Detail, but they lack timeouts
> description.

Yes, these pages helped my a lot.

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

[Jochen Hein]

Alexander Bokovoy  writes:

>>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:
>>`
>>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.

I think I've won my fight...  Here's what I've learned.  The short story is
that probably no timeout should be changed. Shall I still file a ticket
concerning retry counts?

Authentication of IPA users against RADIUS were mostly failing, but
not always. There were hints about timeouts almost everywhere.
Multiple authentication requests from kerberos, timeouts from sssd,
but that should have sent me on the right track from the start:

Dec 19 22:11:51 freeipa1 ipa-otpd: LDAP: 
ldapi://%2Fvar%2Frun%2Fslapd-JOCHEN-ORG.socket
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: request received
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: user query start
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: user query end: 
uid=jkellner,cn=users,cn=accounts,dc=jochen,dc=org
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: radius query start: 
cn=athene,cn=radiusproxy,dc=jochen,dc=org
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: radius query end: 
athene.jochen.org
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: forward start: 
jkell...@jochen.org / athene.jochen.org
Dec 19 22:12:01 freeipa1 ipa-otpd: jkell...@jochen.org: forward end: Connection 
timed out
Dec 19 22:12:01 freeipa1 ipa-otpd: jkell...@jochen.org: response sent: 
Access-Reject

or:

Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: request received
Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: user query start
Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: user query end: 
uid=jkellner,cn=users,cn=accounts,dc=jochen,dc=org
Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: radius query start: 
cn=athene,cn=radiusproxy,dc=jochen,dc=org
Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: radius query end: 
athene.jochen.org
Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: forward start: 
jkell...@jochen.org / athene.jochen.org
Dec 20 22:40:31 freeipa1 ipa-otpd: jkell...@jochen.org: forward end: 
Access-Accept
Dec 20 22:40:31 freeipa1 ipa-otpd: jkell...@jochen.org: response sent: 
Access-Accept

Why is there such a long delay?  The Log of the RADIUS server has:

Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Config File 
/opt/privacyIDEA/rlm_perl.ini found!
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Debugging config: true
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Default URL 
https://athene.jochen.org/validate/check 
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Looking for config for auth-type Perl
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Auth-Type: Perl
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: url: 
https://athene.jochen.org/validate/check
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: user sent to privacyidea: 
jkell...@jochen.org
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: realm sent to privacyidea: jochen.org
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: resolver sent to privacyidea: 
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: client sent to privacyidea: 
192.168.30.121
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: state sent to privacyidea: 
Tue Dec 20 22:40:31 2016 : Info: rlm_perl: privacyIDEA access granted
Tue Dec 20 22:40:31 2016 : Info: rlm_perl: return RLM_MODULE_OK

So RADIUS thinks, it got a request a 30 seconds, but why did we wait so long?
I took a tcpdump and saw:

22:40:23.364355 IP6 freeipa1.jochen.org.41198 > athene.jochen.org.radius: 
RADIUS, Access-Request (1), id: 0x10 length: 134
22:40:30.872136 IP freeipa1.jochen.org.44314 > athene.jochen.org.radius: 
RADIUS, Access-Request (1), id: 0x9c length: 134
22:40:31.572217 IP athene.jochen.org.radius > freeipa1.jochen.org.44314: 
RADIUS, Access-Accept (2), id: 0x9c length: 48

So, we received an IPv6 packet, but didn't react. Some seconds later IPA-OTP
retried with IPv4 and succeeded.  A quick check showed that freeradius
did not listen on IPv6. After fixing that, a request looks like this:

Dec 20 22:54:57 freeipa2 ipa-otpd: jkell...@jochen.org: request received
Dec 20 22:54:57 freeipa2 ipa-otpd: jkell...@jochen.org: user query start
Dec 20 22:54:57 freeipa2 ipa-otpd: jkell...@jochen.org: user query end: 
uid=jkellner,cn=users,cn=accounts,dc=jochen,dc=org
Dec 20 22:54:57 freeipa2 ipa-otpd: jkell...@jochen.org: radius query start: 
cn=athene,cn=radiusproxy,dc=jochen,dc=org
Dec 20 22:54:57 

Re: [Freeipa-users] Valid Sender ? - Re: ipa-otpd: timeout from kerberos when talking to an external 'slow' RADIUS server

[Jochen Hein]

Alexander Bokovoy <aboko...@redhat.com> writes:

> On su, 18 joulu 2016, Jochen Hein wrote:
> Ok. It would probably make sense to file a ticket to FreeIPA tracker to
> get these changes in FreeIPA 4.5.

I'm now fighting against my privacyidea server, but if I can test
something more and am sure about the needed changes I'll file a ticket.

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

[Freeipa-users] ipa-otpd: timeout from kerberos when talking to an external 'slow' RADIUS server

[Jochen Hein]

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.

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] Certificates missing

[Jochen Hein]

Jochen Hein <joc...@jochen.org> writes:

> I'm unsure if it is related to ticket 6397...

It seems it was. CentOS 7.3/CR had new packages today and both problems
are fixed for me. Thanks!

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

[Freeipa-users] Certificates missing (was: Re: Services missing in web-ui)

[Jochen Hein]

I'm unsure if it is related to ticket 6397...

Pavel Vomacka  writes:

> it is caused by missing canonical name on services which were created
> in older versions of FreeIPA. Fixed ticket here:
> https://fedorahosted.org/freeipa/ticket/6397 .

Symptom:
In the web UI on 4.3 on Fedora 24 I have 43 certificates, 
on the 4.4 replica on CentOS 7.3(CR) I see only 16 certificates.

System history:
Old master is 4.3, upgraded from 4.2. Both replicas are new
with CentOS. Yesterday I moved the CA from 4.3 to a 4.4 IDM.
After that I created a certificate for a new service principal.
I can see the new certificate I can see in both web UIs.

Analysis:
Looking at the ipa cli tool, cert-find is consistent with the web UI:

4.3:
-
Number of entries returned 43
-

4.4:
--
Anzahl der zurückgegebenen Einträge 16
--

Looking at both LDAP servers, I do find the same number of entries.
I looked at ou=ca,ou=requests,o=ipaca.
So replications seems to work fine (and ipa-replica-manage confirms it).

Right now I have two guesses:

My system is hit with https://fedorahosted.org/freeipa/ticket/6397
I do have some certificates for services, and some for hosts.
So my hope would be that updated packages might fix it.
But analysing the certificates in the web UI is futil:

- On CentOS(freeipa 4.4) the certificate list in web UI only displays
  serial number, subject, issuing CA(empty), and status(empty).
  That's not quite correct. In the certificate list I can not select
  a certificate and can get more details...

  4.3 has only serial number, subject, and status, but with valid values.
  I can click on the serial number and get more details about the
  certficate.

  Since I can't see all services in 4.4 due to ticket 6397
  more analysis is hard.

- using "ipa cert-show --all" on 4.4 has more infos about the
  certificates, but on 4.3 it doesn't show more info. 

So right now I'm somewhat stuck how to proceed further.  4.3 seems
to be ok, so I hesitate to update the fredora system to 25 (with IPA 4.4).

I didn't find the files from #6397 to manually apply the patch,
so I'm more or less stuck.  Any ideas?

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] Add 4.4 replica to 4.3 server fails

[Jochen Hein]

Jochen Hein <joc...@jochen.org> writes:

> I'm running a single IPA master 4.3 on an up-to-date Fedora 24. That
> server has been updated from earlier Fedoras and runs DNS and CA.
> I've updated domainlevel to 1 manually.
>
> Now I'd like to switch to a CentOS install, so I installed CentOS 7.2
> on a new VM and updated to the CR repo, so I'll get IPA 4.4.
> When installing a replica with "ipa-replica-install --setup-ca" I get:
...
>   [3/5]: Importing RA Key
> /usr/lib/python2.7/site-packages/urllib3/connection.py:251: SecurityWarning: 
> Certificate has no `subjectAltName`, falling back to check for a `commonName` 
> for now. This feature is being removed by major browsers and deprecated by 
> RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.)
> SecurityWarning
> [error] HTTPError: 406 Client Error: Failed to validate message: No recipient 
> matched the provided key["Failed: [ValueError('Multibackend cannot be 
> initialized with no backends. If you are seeing this error when trying to use 
> default_backend() please try uninstalling and reinstalling cryptography.',)]"]
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.

> ipa.ipapython.install.cli.install_tool(Replica): ERROR406 Client Error: 
> Failed to validate message: No recipient matched the provided key["Failed: 
> [ValueError('Multibackend cannot be initialized with no backends. If you are 
> seeing this error when trying to use default_backend() please try 
> uninstalling and reinstalling cryptography.',)]"]
> ipa.ipapython.install.cli.install_tool(Replica): ERRORThe 
> ipa-replica-install command failed. See /var/log/ipareplica-install.log for 
> more information
>

In CentOS 7.2/7.3 we have python-jwcrypto-0.2.1-1.el7, in Fedora 23 we
have 0.3.2-1.
https://github.com/latchset/jwcrypto/issues/47 talks about problems with
FreeIPA and custodia, and that downgrading python-jwcrypto helped. Since
I consider the way forward a better choice I upgraded python-jwcrypto on
CentOS to 0.3.2, and now I have new replicas with FreeIPA 4.4 attached
to my 4.3 master.  Yeah!  It might be a good idea to get the package in
CentOS/RHEL upgraded...

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] Valid Sender ? - Re: Add 4.4 replica to 4.3 server fails

[Jochen Hein]

Martin Babinsky  writes:

>>> 2016-11-27T21:07:26Z ERROR The ipa-replica-install command failed. See 
>>> /var/log/ipareplica-install.log for more information
>>>
>>> Any idea what's wrong?
> can you please check the version of python-cryptography on master and
> replica? I remember there used to be problem with pre-0.9 versions
> breaking Custodia.

Both are newer.  Master:
[root@freeipa ca]# rpm -qa | grep python.*cryptogra
python2-cryptography-1.5.3-3.fc24.x86_64

Replica:
[root@freeipa1 pki]# rpm -qa | grep python.*cryptogra
python2-cryptography-1.3.1-3.el7.x86_64

I've found https://github.com/latchset/jwcrypto/issues/47,
https://github.com/pyinstaller/pyinstaller/issues/2013, and
https://github.com/pyca/cryptography/issues/2907. But nothing that
stands out for me. I'll wait for GA of CentOS 7.3 and will try again
later, and also browse reports I may find.

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] Add 4.4 replica to 4.3 server fails

[Jochen Hein]

Jochen Hein <joc...@jochen.org> writes:

> 2016-11-27T21:07:26Z DEBUG The ipa-replica-install command failed, exception: 
> HTTPError: 406 Client Error: Failed to validate message: No recipient matched 
> the provided key["Failed: [ValueError('Multibackend cannot be initialized 
> with no backends. If you are seeing this error when trying to use 
> default_backend() please try uninstalling and reinstalling cryptography.',)]"]
> 2016-11-27T21:07:26Z ERROR 406 Client Error: Failed to validate message: No 
> recipient matched the provided key["Failed: [ValueError('Multibackend cannot 
> be initialized with no backends. If you are seeing this error when trying to 
> use default_backend() please try uninstalling and reinstalling 
> cryptography.',)]"]
> 2016-11-27T21:07:26Z ERROR The ipa-replica-install command failed. See 
> /var/log/ipareplica-install.log for more information
>
> Any idea what's wrong?

Around that time the pki on the old master has this:

0.Thread-17 - [27/Nov/2016:22:06:47 MEZ] [8] [3] Publishing: Could not
publish certificate serial number 0x1a. Error Failed to publish using
rule: No rules enabled

Debug has:
[27/Nov/2016:22:06:47][Thread-17]: RunListeners:: Queue: 1 noSingleRequest
[27/Nov/2016:22:06:47][Thread-17]: getRequest  mRequests=1 
mSearchForRequests=false
[27/Nov/2016:22:06:47][Thread-17]: getRequest  getting request: 29
[27/Nov/2016:22:06:47][Thread-17]: In LdapBoundConnFactory::getConn()
[27/Nov/2016:22:06:47][Thread-17]: masterConn is connected: true
[27/Nov/2016:22:06:47][Thread-17]: getConn: conn is connected true
[27/Nov/2016:22:06:47][Thread-17]: getConn: mNumConns now 4
[27/Nov/2016:22:06:47][Thread-17]: returnConn: mNumConns now 5
[27/Nov/2016:22:06:47][Thread-17]: getRequest  request 29 found
[27/Nov/2016:22:06:47][Thread-17]: getRequest  mRequests=0 
mSearchForRequests=false done
[27/Nov/2016:22:06:47][Thread-17]: RunListeners: IRequestListener = 
com.netscape.cms.listeners.CertificateIssuedListener
[27/Nov/2016:22:06:47][Thread-17]: CertificateIssuedListener: accept 29
[27/Nov/2016:22:06:47][Thread-17]: RunListeners: IRequestListener = 
com.netscape.ca.CRLIssuingPoint$RevocationRequestListener
[27/Nov/2016:22:06:47][Thread-17]: RunListeners: IRequestListener = 
com.netscape.cmscore.ldap.LdapRequestListener
[27/Nov/2016:22:06:47][Thread-17]: LdapRequestListener handling publishing for 
enrollment request id 29
[27/Nov/2016:22:06:47][Thread-17]: Checking publishing for request 29
[27/Nov/2016:22:06:47][Thread-17]: In  PublisherProcessor::publishCert
[27/Nov/2016:22:06:47][Thread-17]: Publishing: can't find publishing 
rule,exiting routine.
[27/Nov/2016:22:06:47][Thread-17]: PublishProcessor::publishCert : Failed to 
publish using rule: No rules enabled
[27/Nov/2016:22:06:47][Thread-17]: RunListeners: IRequestListener = 
com.netscape.cms.listeners.CertificateRevokedListener
[27/Nov/2016:22:06:47][Thread-17]: RunListeners: mRequest = 29
[27/Nov/2016:22:06:47][Thread-17]: updatePublishingStatus 
mSavePublishingCounter: 3 mSavePublishingStatus: 200
[27/Nov/2016:22:06:47][Thread-17]: RunListeners:  noQueue  SingleRequest
[27/Nov/2016:22:06:47][Thread-17]: RequestRepository: setPublishingStatus  
mBaseDN: ou=ca,ou=requests,o=ipaca  status: -1
[27/Nov/2016:22:06:47][Thread-17]: In LdapBoundConnFactory::getConn()
[27/Nov/2016:22:06:47][Thread-17]: masterConn is connected: true
[27/Nov/2016:22:06:47][Thread-17]: getConn: conn is connected true
[27/Nov/2016:22:06:47][Thread-17]: getConn: mNumConns now 4
[27/Nov/2016:22:06:47][Thread-17]: returnConn: mNumConns now 5
[27/Nov/2016:22:06:47][Thread-17]: Number of publishing threads: 0

Maybe something in dogtag is missing?

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

[Freeipa-users] Add 4.4 replica to 4.3 server fails

[Jochen Hein]

I'm running a single IPA master 4.3 on an up-to-date Fedora 24. That
server has been updated from earlier Fedoras and runs DNS and CA.
I've updated domainlevel to 1 manually.

Installed packages in IPA master:
[root@freeipa ~]# rpm -qa | grep freeipa
freeipa-admintools-4.3.2-2.fc24.noarch
freeipa-server-common-4.3.2-2.fc24.noarch
freeipa-server-4.3.2-2.fc24.x86_64
freeipa-client-common-4.3.2-2.fc24.noarch
freeipa-server-trust-ad-4.3.2-2.fc24.x86_64
freeipa-client-4.3.2-2.fc24.x86_64
freeipa-common-4.3.2-2.fc24.noarch
freeipa-python-compat-4.3.2-2.fc24.noarch

Now I'd like to switch to a CentOS install, so I installed CentOS 7.2
on a new VM and updated to the CR repo, so I'll get IPA 4.4.

Installed packages in new VM:
[root@freeipa1 ~]# rpm -qa | grep ipa
python2-ipaserver-4.4.0-12.el7.centos.noarch
python2-ipalib-4.4.0-12.el7.centos.noarch
ipa-server-4.4.0-12.el7.centos.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-server-dns-4.4.0-12.el7.centos.noarch
ipa-client-common-4.4.0-12.el7.centos.noarch
libipa_hbac-1.14.0-43.el7.x86_64
ipa-common-4.4.0-12.el7.centos.noarch
ipa-admintools-4.4.0-12.el7.centos.noarch
sssd-ipa-1.14.0-43.el7.x86_64
ipa-client-4.4.0-12.el7.centos.x86_64
ipa-python-compat-4.4.0-12.el7.centos.noarch
python-libipa_hbac-1.14.0-43.el7.x86_64
python2-ipaclient-4.4.0-12.el7.centos.noarch
python-ipaddress-1.0.16-2.el7.noarch
ipa-server-common-4.4.0-12.el7.centos.noarch

When installing a replica with "ipa-replica-install --setup-ca" I get:

[root@freeipa1 ~]# ipa-replica-install --setup-ca
Run connection check to master
Connection check OK
Configuring NTP daemon (ntpd)
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
  Done configuring NTP daemon (ntpd).
  Configuring directory server (dirsrv). Estimated time: 1 minute
  [1/44]: creating directory server user
  [2/44]: creating directory server instance
  [3/44]: updating configuration in dse.ldif
  [4/44]: restarting directory server
  [5/44]: adding default schema
  [6/44]: enabling memberof plugin
  [7/44]: enabling winsync plugin
  [8/44]: configuring replication version plugin
  [9/44]: enabling IPA enrollment plugin
  [10/44]: enabling ldapi
  [11/44]: configuring uniqueness plugin
  [12/44]: configuring uuid plugin
  [13/44]: configuring modrdn plugin
  [14/44]: configuring DNS plugin
  [15/44]: enabling entryUSN plugin
  [16/44]: configuring lockout plugin
  [17/44]: configuring topology plugin
  [18/44]: creating indices
  [19/44]: enabling referential integrity plugin
  [20/44]: configuring certmap.conf
  [21/44]: configure autobind for root
  [22/44]: configure new location for managed entries
  [23/44]: configure dirsrv ccache
  [24/44]: enabling SASL mapping fallback
  [25/44]: restarting directory server
  [26/44]: creating DS keytab
  [27/44]: retrieving DS Certificate
  [28/44]: restarting directory server
  [29/44]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 8 seconds elapsed
Update succeeded

  [30/44]: adding sasl mappings to the directory
  [31/44]: updating schema
  [32/44]: setting Auto Member configuration
  [33/44]: enabling S4U2Proxy delegation
  [34/44]: importing CA certificates from LDAP
  [35/44]: initializing group membership
  [36/44]: adding master entry
  [37/44]: initializing domain level
  [38/44]: configuring Posix uid/gid generation
  [39/44]: adding replication acis
  [40/44]: enabling compatibility plugin
  [41/44]: activating sidgen plugin
  [42/44]: activating extdom plugin
  [43/44]: tuning directory server
  [44/44]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Configuring ipa-custodia
  [1/5]: Generating ipa-custodia config file
  [2/5]: Generating ipa-custodia keys
  [3/5]: Importing RA Key
/usr/lib/python2.7/site-packages/urllib3/connection.py:251: SecurityWarning: 
Certificate has no `subjectAltName`, falling back to check for a `commonName` 
for now. This feature is being removed by major browsers and deprecated by RFC 
2818. (See https://github.com/shazow/urllib3/issues/497 for details.)
SecurityWarning
[error] HTTPError: 406 Client Error: Failed to validate message: No recipient 
matched the provided key["Failed: [ValueError('Multibackend cannot be 
initialized with no backends. If you are seeing this error when trying to use 
default_backend() please try uninstalling and reinstalling cryptography.',)]"]
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERROR406 Client Error: 
Failed to validate message: No recipient matched the provided key["Failed: 
[ValueError('Multibackend cannot be initialized with no backends. If you are 
seeing this error when trying to use default_backend() please try uninstalling 
and reinstalling cryptography.',)]"]
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe 

[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] Ubuntu 16.04 released with FreeIPA 4.3.1

[Jochen Hein]

Timo Aaltonen <tjaal...@ubuntu.com> writes:

> On 16.10.2016 08:00, Jochen Hein wrote:
>> Timo Aaltonen <tjaal...@ubuntu.com> writes:
>> 
>>> On 15.10.2016 22:33, Jochen Hein wrote:
>>>> Timo Aaltonen <tjaal...@ubuntu.com> writes:
>>>
>>> Looks like it was due to a misunderstanding.. it got removed from Debian
>>> first (because of new uploads getting blocked due to minified javascript
>>> not being actual source), then added back and synced to yakkety, but
>>> again removed from there for the same reason it got removed from Debian..
>
> The dropped binaries are back, you can find them from yakkety-updates.

Thanks!

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] Ubuntu 16.04 released with FreeIPA 4.3.1

[Jochen Hein]

Timo Aaltonen <tjaal...@ubuntu.com> writes:

> On 15.10.2016 22:33, Jochen Hein wrote:
>> Timo Aaltonen <tjaal...@ubuntu.com> writes:
>> 
>>>   Ubuntu 16.04 LTS got released today, and it comes with FreeIPA 4.3.1!
>> 
>> Thanks for your work on packaging FreeIPA for Ubuntu (and Debian). I've
>> just updated my laptop to Ubuntu 16.10, and now the freeipa packages are
>> "orphaned", because these packages seems to be missing from yakkety. Is
>> there a reason for this? I didn't see a bugreport for it.
>
> Looks like it was due to a misunderstanding.. it got removed from Debian
> first (because of new uploads getting blocked due to minified javascript
> not being actual source), then added back and synced to yakkety, but
> again removed from there for the same reason it got removed from Debian..

That's what I've feared.

> I'll check if it can be added back.

Thanks for looking into it.

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] Ubuntu 16.04 released with FreeIPA 4.3.1

[Jochen Hein]

Timo Aaltonen  writes:

>   Ubuntu 16.04 LTS got released today, and it comes with FreeIPA 4.3.1!

Thanks for your work on packaging FreeIPA for Ubuntu (and Debian). I've
just updated my laptop to Ubuntu 16.10, and now the freeipa packages are
"orphaned", because these packages seems to be missing from yakkety. Is
there a reason for this? I didn't see a bugreport for it.

I guess for an already enrolled client an actual package for sssd and
kerberos will be ok, but freeipa for new clients would be fine.

BTW, most of my servers run Debian - freeipa packages would be most
welcome. Right now I use older packages to enroll Debian hosts.

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] OTP authentication without Password

[Jochen Hein]

"Master P."  writes:

> Is it possible to authenticate a user with only OTP and ssh-pubkeys?

Yes, but you need some tool managing OTP without password/PIN, which
FreeIPA doesn't seem to support.  I use privacyidea to manage my OTP
tokens and have a working configuration.

> So far I have successfully configured FreeIPA to use Two factor
> authentication (password + OTP).  I had to change the sshd_config to
> achieve this by modifying the AuthenticationMethods to be:
>
> AuthenticationMethods publickey,password:pam
> publickey,keyboard-interactive-pam

I do use:

Match Group otpusers
AuthenticationMethods publickey,keyboard-interactive:pam gssapi-with-mic

When authenticating with ssh key, also require PAM. Having a kerberos
ticket grants access.

My PAM configuration is:

# If the user is in group otpusers, we use the next rule, otherwise we skip
# the call to pam_yubico.
auth [default=1 success=ignore] pam_succeed_if.so quiet user ingroup otpusers
auth sufficient pam_yubico.so id= key= 
urllist=https://privacyidea.jochen.org/ttype/yubikey 
authfile=/etc/yubikeys/authorized_yubikeys

I use Yubikeys in mode YUBICO, but my own privacyidea authentication
server. It should be also possible to use privacyidea as a backend
behind a RADIUS server for FreeIPA (I do use it for OpenVPN, but not
FreeIPA).

If find it more flexible to hand off OTP to a special tool like
privacyidea oder linotp - a token on FreeIPA, Kolab, or another
application is only a single purpose token.

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] Problem with ipa-getkeytab ?

[Jochen Hein]

Günther J. Niederwimmer  writes:

> but on the second Server when I start
>
> kinit admin
> ipa-getkeytab   -r  -s ipa.example.com -p imap/mail.example.com -k /etc/
> dovecot/dovecot.keytab
>
> for the same keytab,
> I become a Error with not access is possible ?

You need special authorization to retrieve a keytab, AFAIK. Please have
a look at http://www.freeipa.org/page/V4/Keytab_Retrieval_Management and
http://www.freeipa.org/page/V4/Keytab_Retrieval

Hope that helps,
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

[Freeipa-users] Cockpit Integration part II - SSL certificates

[Jochen Hein]

Hi,

Right now cockpit still uses a locally created TLS certificate, that
should be changed to a IPA issued certificate.  What I understood is
that a certificate is for a host (e.g. ipa.example.com), so apache and
cockpit should use the same certificate. Is that understanding correct?

So this is what I did:

# cp cert8.db key3.db secmod.db pwdfile.txt /tmp/
# cd /tmp
# pk12util -o keys.p12 -n 'Server-Cert' -d . -k /etc/httpd/alias/pwdfile.txt
# openssl pkcs12 -in keys.p12 -out freeipa.key -nodes -clcerts
# cp freeipa.key /etc/cockpit/ws-certs.d/freeipa.cert
# systemctl restart cockpit.service

Now Cockpit and apache use the same certificate, but the cockpit
certificate is not tracked by certmonger.  Any idea how that could
work?

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

[Freeipa-users] Cockpit integration part I - Single Sign On

[Jochen Hein]

Hi,

here is what I did on my system - may be helpful to others as well.

Cockpit: enable Single-Sign-On with FreeIPA
===

I wanted to use SSO to access the Cockpit already installed on my
freeipa server.

Upstream documentation is on
http://cockpit-project.org/guide/latest/sso.html, so we only add some
remarks here.

Upstream:
,
| There must be a valid Kerberos host key for the server in the
| /etc/krb5.keytab file. It may be necessary to create a kerberos
| service principal and update the keytab if it is not
| present. Depending on your domain type different service names are
| required:
|
| Active Directory  HOST/server.example@example.com
| IPA and MIT   HTTP/server.example@example.com
`

This has already happened - apache on my server uses the service
HTTP/server.example@example.com, but the service is not present in
the server keytab. So we need to add the service principal there.

If we just generate a new keytab, we invalidate the keytab used by
apache. So we need to only retrieve the keytab, not regenerate
it. This is only possible after we allowed the retrieval of the
keytab for either the admin principal, the host principal or some
users/host groups. Here we go for the host principal:

# kinit admin
# ipa service-allow-retrieve-keytab HTTP/freeipa.jochen@jochen.org 
--hosts=freeipa.jochen.org

Finally we retrieve the service keytab into /etc/krb5.keytab:

# ipa-getkeytab -r -s freeipa.jochen.org -p HTTP/freeipa.jochen@jochen.org 
-k /etc/krb5.keytab

After that Single Sign On works as expected.

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] FreeIPA and DHCP

[Jochen Hein]

William Brown  writes:

> On Fri, 2015-10-16 at 15:01 +0200, Nicola Canepa wrote:
>> Hello.
>> Is there a suggested way to have DHCP IP/MAC associations managed 
>> through the IPA web interface?
>
> There is currently no way to manage DHCP with FreeIPA.

Freeipa hosts do have MAC values as a field and there is an IP address
assigned.  I've found a script to extract the info for isc DHCP at
http://lesloueizeh.com/jdieter/freeipa-dhcpd/generate_dhcp.py

I've implemented a script for using with dnsmasq:

-- cut here -
#!/bin/bash

out=/etc/dnsmasq.d/dynamic-hosts.conf
#out=/tmp/xxx
tmp=/etc/dnsmasq.d/dynamic-hosts.conf.tmp

KRBPRINC='host/echidna.jochen@jochen.org'

kinit -k $KRBPRINC

cat > $tmp <> $tmp

if cmp -s $out $tmp; then
rm -f $tmp
else
mv $tmp $out
systemctl restart dnsmasq.service
fi

kdestroy

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