We are pleased to be able to release privacyIDEA 3.9. This release is an example of how privacyIDEA is ment to centrally manage all you authentication in one place – since successful authentication is a matter of smooth workflows.

privacyIDEA aims to be a management system where the administrator can easily manage the authentication topic for the users. You as an administrator can manage the OTP tokens (TOTP, HOTP apps, Yubikeys), tokentype like SMS or Email, even FIDO2. All you need for two factor authentication.

And privacyIDEA is able to also verify the first factor. The static password.

Old authentication – new token types

But sometimes you might see, that two factor authentication does not work out as expected. That applications do not play well with FIDO2/WebAuthn. Yes, sometimes applications do not play well even with OTP tokens. Take an Email client, that caches the user password and sends it, every time it fetches the emails from the server. The request will fail if it is sent with the same OTP value a second time.

Successful Authentication is not always a matter of choose the most modern cryptographic algorithm or the latest authentication method.

Sometimes there is an old, nasty application that refuses to work well with the 2FA method you are enrolling in your company. But privacyIDEA wants to help you as administrator to manage all these challenges in one system.

With privacyIDEA 3.9 we introduce two new token types which might sound old and insecure, but which are supposed to enable you to take a step forward, even if some old applications want to hold you back.

The application specific password token is simply a static password that can be bound to a specific application. The old application will send an authentication request against privacyIDEA and privacyIDEA will realize, that this auth request originated from this application and allow such application specific password tokens enrolled for this application to be used for authentication. A user can have a specific password for e.g. his email client, save this in his smartphone and privacyIDEA will accept this only for login requests by this email client resp. mail server.
You may check the conceptual evolution of this feature on Github.

The day password token is a similar quirky thing. In certain situations having an OTP token that changes all 30 seconds or 60 seconds may be to changeable for some users or use cases. But using no second factor and relying on a never changing static password is also not an option.

Why not have a token, that can be used for one hour? Or one day? The day password token in privacyIDEA 3.9 is a token type with a variable time window between one second and many days. During this time window the given code is valid during the whole time window and can be used as often as needed. It is similar to TOTP (in fact it is inherited from the TOTP token class), but has the above mentioned special effects.

This token type has its counter part in the privacyIDEA Authenticator App, which you can find in the Google Play Store and Apple App Store. The day password token is supported in the privacyIDEA Authenticator App starting with version 4.2.

Improving SSH Key Management

Managing SSH keys has been a bit cumbersome in the past. You as the administrator had to assign each SSH server to the SSH key, so that the user could use the SSH key to log to this server.

With privacyIDEA 3.9 you can now define service identifiers, which represent the servers. E.g. you could define an identifier “web servers” and assign SSH keys to this identifier.

Now you can simply have the SSH server identify as “web servers” to allow the login with this SSH key. This way it is easy as configuring the corresponding server, to add a new SSH server to the “web servers”.

The helper script privacyidea-authorizedkeys, which is supposed to run on the SSH servers has been modified so that it queires privacyIDEA for the corresponding service identifier.

Changelog

A new event handler can set the application assignment during enrollment. This helps with definding HOTP tokens as Offline-Tokens for the privacyIDEA Credential Provider. The PUSH token can do a decline, so that the authentication process is cancelled.

You can find the complete changelog at Github.

Install and Update

You can download and update privacyIDEA 3.9 via the community repositories for Ubuntu 20.04LTS and Ubuntu 22.04LTS or via the Python Package Index.

If you want to get involved, you can join the discussion at the Forum or coding at Github.

The first question we asked ourselves was: What exactly do we want to find out? As we worked a lot on optimizing the LDAP resolver, we first wanted to know if privacyIDEA 2.19 by itself processes authentication requests faster than privacyIDEA 2.18.1. The next question was whether performance can be further improved by enabling the new user cache feature of privacyIDEA 2.19. Here, we wanted to differentiate between a worst-case scenario with an empty cache and a best-case scenario with an already-populated cache. For each scenario, we wanted to get an idea of the time that privacyIDEA needs to handle an incoming authentication request. Having cleared our objective, the next step was creating a suitable lab environment that resembles the real world as closely as possible to run our benchmarks in.

Our lab environment

We created a lab environment as follows. First, we set up an Univention Corporate Server and added 1000 users to its directory, which we simply called user000 to user999, as well as a privacyIDEA service account. In the same network, we prepared two Ubuntu 16.04 virtual machines and installed privacyIDEA 2.18.1 on the first and privacyIDEA 2.19-dev5 on the second machine. On both instances, we added a realm with a LDAP resolver connecting to the Univention Corporate Server via LDAPS.

In order to keep our environment as close to the real world as possible, we would need to enroll HOTP or TOTP tokens for our 1000 users. However, we ultimately decided against it. For one, we suspected that the time spent calculating and checking the next OTP value on the server is relatively small in comparison to the time spent communicating with the LDAP server. Enrolling real OTP tokens would also require us to keep track of secrets and counter values on our benchmark client, which would complicate our setup a lot. To keep things simple, we instead decided to enroll one simple password (SPASS) token for each user.

Our benchmarking approach

Now, we had set up two privacyIDEA instances with 1000 tokens. The next question was: How exactly do we now measure the performance of one authentication request? We decided to settle on the following approach: One benchmark consists of 2000 successful authentication requests, performed one after another for the users user000 to user999. This means that each user is authenticated twice during one benchmark. For each authentication request, we measured the time from sending the request until receiving the response using a simple benchmarking script in Python based on python-requests. We copied the script to the virtual machines and performed all authentication requests against https://localhost in order to exclude the network delay from our measurements. Running the script then produces 2000 measurements of response time, of which we computed the median response time.

We decided to measure the response times for the following scenarios:

• Scenario #1: Authentication against privacyIDEA 2.18.1
• Scenario #2: Authentication against privacyIDEA 2.19, with the user cache feature disabled
• Scenario #3: Authentication against privacyIDEA 2.19, with the user cache enabled and initially empty
• Scenario #4: Authentication against privacyIDEA 2.19, with an already-populated user cache. This means
  that the user cache contains valid 1000 entries, one for each user from user000 to
  user999.

The scenarios 2, 3 and 4 were carried out on the privacyIDEA 2.19 machine. For scenarios 3 and 4, we enabled the user cache with a timeout of one day (corresponding to 86400 seconds).

Our results

Now, we had everything in place to start our benchmarks! In total, running the benchmark for all four scenarios took roughly one hour and we obtained the following results.

Interesting! According to our measurements, an update to privacyIDEA 2.19 alone seems to reduce the median response time by roughly 57% (Scenario #2), even without enabling the user cache. This speedup can probably be attributed to some performance improvements in the LDAP resolver (see issues 655 and 664).

Furthermore, if the user cache is enabled and fully populated (Scenario #4), the median response time is reduced by another 33%. In comparison to privacyIDEA 2.18.1, this corresponds to a reduction by 71%. Of course, this models a best-case scenario in which the LDAP server does not need to be queried any more at all. This may not be the case in the real world, e.g. if an otppin=userstore policy is enabled.

Scenario #3 is quite interesting, as the user cache is initially empty and is subsequently populated during the first 1000 authentication requests. For the second round of 1000 authentications, privacyIDEA can rely on the user cache instead of querying the LDAP server. We can also observe this if we plot our measurements:

The horizontal axis denotes our measurements and the vertical axis gives the median response time in milliseconds. We can observe that the median response time drops dramatically after the thousandth measurement, from which we can conclude that the user cache does have a measurable positive impact on the performance of authentication requests.

Of course, our benchmark is not perfect and leaves room for improvement due to multiple reasons. Firstly, the measurements also include the round-trip time between LDAP server and privacyIDEA instance, which significantly depends on the network setup. Secondly, we have only enrolled SPASS tokens and no real OTP tokens. Thirdly, we have not performed any concurrent requests and cannot, for example, say anything about the maximum number of authentication requests per second. Finally, two authentication requests by the same user are several minutes apart. If the same user sends two authentication requests during the timespan configured by the cache timeout option of the LDAP resolver (which defaults to 2 minutes), privacyIDEA queries an in-memory cache, which may be even faster than the query to the local database performed by the user cache.

However, we believe that our benchmark shows that privacyIDEA 2.19 improves the performance of authentication requests quite significantly even without the user cache. Additionally, enabling the user cache may bring significant performance improvements in case a large number of users are expected to send authentication requests over a large timespan. Finally, we noticed that the LDAP connection in our test setup is quite fast (a LDAP search takes just unter 30 milliseconds), so the user cache may provide an even better speedup in case of slower LDAP servers or connections. You are welcome to try it out for yourself! If you have any further questions, pleask ask them on our community site.

Cash Money

In Germany certain disoriented politicians suggest the abolition of cash money. Arguing that cash money is used by criminals and terrorists. Abolishing cash money and only allowing electronical transactions, these transactions can be tracked and controlled. Crimes will be avoided and terrorism ended. Luckily there are other prominent statements to contradict this wired ideas.

But what does the abolition of cash money have to do with privacyIDEA?

Central Book Keeping

In the European Union we usually like to travel to other EU countries and pay with the same Euro, not having to change money or bother about any exchange rate. Usually this is very convenient.

Electronic transactions could be great and convenient, too. We do not need to care about bringing enough money, everything would be smooth and easy and one central book keeping instance would take care to transfer 100 credits from person A to person B. After the transfer is approved and completed, person B could hand person A the goods of interest.

But such a central book keeping instance would not only know, what money was spent by whom on what, but it could also restrict the amount of money person A is allowed to spent or person B is allowed to receive. Even worse this controlling instance could also disallow person A to spent money for certain goods or to buy from certain sellers at all. Thus people could be banned from buying cigarettes, certain medicine or unpleasant newspapers.

Again, what does this have to do with privacyIDEA?

No Central Book Keeping

We do not like to be controlled and we do not want you to be controlled either. Many two factor authentication services are running two factor authentication as — guess what — a service.  This in fact is such a central book keeping. Such a central service knows, who of your users authenticated where and when. And they could easily allow or disallow access based on other decisions than the right OTP value sent by your smartphone. You do not know and do not control the algorithms used.

This is why we offer privacyIDEA to run on premise. Under your control. With no central book keeping and with no fear, that conditions or laws might change tomorrow.

And this is why it makes me shiver, when I read about any idea for centrally controlled anything or the abolition of cash money.

Fight for your informational self-determination and stand up to keep your cash money!

…and use privacyIDEA!

To do openess and transparancy the honour I would like to elaborate on what has happened.

The empire strikes back

The subdirectory authmodules in the privacyIDEA github repository contained a module for ownCloud. In ownCloud speak an “app”. This tried to support ownCloud 8. It failed with ownCloud 9. This was due to the fact, that ownCloud <= 9 had no concept or API for attaching two factor authentication system. It even had no concept of passing authentication to another module. It only allowed to change the complete user module. I.e. authentication, user existance and authorization was not separated like you would be used to e.g. from PAM. And this is why providing a module for two factor authentication for ownCloud 8 and 9 was the biggest pain in the ass I ever experienced.

Now several simple users came around and popped up on the mailing list or at github. I call them simple, because they were not able to look behind the scenes, analyze problems, look at a line of code or even add a line of code. I experienced several occasions when such users complained about, that the old privacyIDEA “app” for 8 and 9 was not working as they expected.

Finally I got really sick of those users with this simple cosuming attitude. I got sick of claiming having a two factor solution for an application, which did not provide a decently designed and documented authentication interface. And this is why I happily deleted the old ownCloud plugin from the privacyIDEA github repository.

A new hope

Finally, ownCloud 9.1 was said to come with a new authentication API – which unfortunately again was designed without asking someone, who knows some things about two factors — like me! Big mistake! Nevertheless – I decided to give it a second chance. Thanks to the help of Christoph Wurst and Thomas Müller I was able to implement a new privacyIDEA ownCloud app for ownCloud 9.1.

As I am still very disappointed in any kind of “community” regarding the old ownCloud app (for privacyIDEA itself it is a complete other picture!!!), the privacyIDEA ownCloud App for 9.1 is not publically available, yet. I don’t want to hear any comsumers complaining about things they don’t understand or are not willing to dive into! But this is no problem. ownCloud users with a handful of accounts can happily use the TOTP app which probably willl run very well for them.

These words might sound hard to some of you. But you may appreciate that they are the real truth of mine!

The return of the Jedi

Power users or companies with many users have different requirements. They will also do two factor authentication a the firewall, at portals, terminal servers or the VPN. In this case it makes no sense to manage TOTP tokens within ownCloud. Because these tokens can not be used for the VPN. Other tokens would again have to be managed for the VPN somewhere else… And for the terminal servers…

Enterprise environments require to manage the tokens of the users at one central place. All users, for all applications. In this case privacyIDEA and the privacyIDEA ownCloud app make absolute sense. Customers should contact NetKnights GmbH, because this is the place where they will receive the privacyIDEA ownCloud App!

Kind regards

Cornelius

• Affected version: up to privacyIDEA 2.11.2
• Propability: Medium
• Security Severity: High

Technical Background

The passOnNoUser policy is supposed to check if an authenticating user exists. If the user exists, normal authentication is performed. If the user does not exist in the user store authentication is immediately successful. This is useful in special scenarios, where the Application has several levels of authentication and privacyIDEA is just the second level. Users that do not exist in privacyIDEA will only authenticate with the first level and users, that have an account in privacyIDEA will need to authenticate with the second level.

The Bug: If the policy passOnNoUser is set, it is not checked, if the user exists. I.e. even users that do exist are successfully authenticated, without checking their OTP value or password.

Advisory

You need to disable a policy containing the passOnNoUser action or remove the passOnNoUser action from you policies immediately.

Fix

You should update to version 2.11.3 which is released today.

These SSSD offline functionalities is intended to increase performance to not contact the IdM server all the time. I wonder if the timeout can not only set to some seconds but also to go offline with the client.

The same blog post also talks about OTP multistep prompting. But when going offline you do not want to decrease security by just requiring the first factor. This is why privacyIDEA provides the hashed OTP values to the client to be able to authenitcate with two factors while offline.

Admitted, going online again is a bit tricky, since the concept of resynchronizating the offline client with the authentication backend also contains possible attack vectors.

I am curious how SSSD will face this problem.

Data Privacy Day

This day is foremost ment to sensitize companies and users to take care when handling with private data. Especially in social media. But you can not devide your social life from your work life. Many attacks may start in social networks and end up in the heart of the company where the original victim is employed.

This is why you should protect information, that can be used to initiate attacks. This can be personal information, that only you and your personal contacts know, addresses (Read this very interesting story), dates, usernames and of course any hints to passwords.

Data Privacy with privacyIDEA

The job of privacyIDEA is to keep the data in your organization safe. privacyIDEA does this by introducing a second factor for authentication. Credentials for any account gained from social engineering in social networks or phishing will not get the attacker in. If you are using a hardware second factor like a Yubikey or a Smartdisplayer OTP card the classic cracker is in a mess, since he would have to get out and perform a real life action like stealing the hardware possession.

When using privacyIDEA it respects your privacy. privacyIDEA is 100% Open Source and 100% Back door free. This way you can know every second what the system is doing and all your data and all your authentication decisions belong to you!

Also do Encryption

An additional measure to protect your data is encryption. To get help with authentication and encryption you may ask the company NetKnights.

This is a cheap way to establish two-factor authentication with something you know and something you have.

Several attack vectors for Two-Factor Authentication with SMS OTP

But lateley there are again some news about the vularability of OTP values sent via SMS. There are different attack vectors. In one scenario the attacker can reroute or “steal” the SIM card by doing social engineering at the telephone provider. In another scenario a malicious software is installed on the smartphone, that can sniff the OTP value.

Yes, privacyIDEA also supports sending OTP values via SMS and privacyIDEA is also vulnarable to these attacks – since it is the basic concept that lacks the necessary security.

Security is shades of grey — or white

But you might have heard that “there is no 100% security”. And that “security is a process”. And now I add to these idioms “Security is Shades of Grey”.

You gain security by using a password on your account to lock the desktop. But are you secure? You gain further security by adding a second factor during authentication. But is your data secure, now? You gain further security by encrypting the harddisk (a.k.a. your data) of your desktop. But is it secure?

Yes, it is good to use a password. You should not use none.

And yes, it is goot to use SMS OTP. It is better than to not use it. In certain cases it might be OK to use SMS OTP being aware of the possible risks.

But there are further steps or other possiblities to increase security.

Choice of Security Level

With privacyIDEA you have the choice, which security level you are going to use. And this may even depend on the application and the client.

You may use SMS OTP, Email OTP, Smartphone Apps like the Google Authenticator, hardware key fobs and seedable tokens like the Yubikey. Using privacyIDEA’s policy definitions, you can define which token type is allowed to be used for authentication at which application. This way you can accept the risk of using e.g. SMS OTP for low security applications and hardware devices like the yubikey for applications requiring higher confidentiality.

See the online documentation on policies for more information or come to the Google Group mailing list.

If you require any professional assistance you may contact the maintainer of privacyIDEA.

Thus you have the following authentication factors:

1. SSH Key (soft possession factor – copyable!)
2. optional passphrase on the SSH Key, which is not controlled by the server! (knowledge)
3. OTP token supported by privacyIDEA like Google Authenticator or preferable a Yubikey (hard possession factor – not copyable)
4. an optional OTP PIN controlled by privacyIDEA (knowledge)

Connect SSH to privacyIDEA

Connecting SSH to privacyIDEA is described in this video. It uses the privacyIDEA PAM Module in the online documentation.

In the SSH configuration you need to set

UsePAM yes

This way SSH will authenticate the user against the PAM stack using /etc/pam.d/sshd.

This howto will assume you are using a Ubuntu system. Other systems like CentOS use slightly different PAM configuration, but the idea is the same.

Install privacyIDEA PAM

To use PAM with privacyIDEA you need the privacyIDEA PAM authentication module. On a Ubuntu 14.04 you can install it like

add-apt-repository ppa:privacyidea/privacyidea
apt-get update
apt-get install privacyidea-pam

In other cases you can get it from github with the above mentioned link.

Configure SSH PAM

Now lets take a look at the PAM config for SSH. The file /etc/pam.d/sshd contains a line

@include common-auth

Change this line to

@include common-auth-pi

By creating such a new file it is easier for us to add two factors to every PAM enabled service.

Copy the file /etc/pam.d/common-auth to /etc/pam.d/common-auth-pi. The file /etc/pam.d/common-auth-pi will look like this:

auth     [success=1 default=ignore] pam_python.so /lib/security/privacyidea_pam.py url=https://yourserver \ 
                                                  nosslverify debug
auth    requisite   pam_deny.so
auth    required    pam_permit.so
auth    optional    pam_cap.so

In the file common-auth-pi we replace pam_unix.so with privacyidea_pam. You need to specify the URL of your privacyIDEA server. If everything is working out fine, you can remove the debug parameter. If you have a trusted certificate you can remove nosslverify.

Please assure, that you are logged in to your system or that you have other mean to login like ssh keys. Modifying the PAM stack for SSH can result in not being able to login with a password via SSH anymore.

Now that you have configured

• /etc/ssh/sshd_config
• /etc/pam.d/common-auth-pi
• /etc/pam.d/sshd

you can restart the SSH server for the changes to take effect.

When you now try to login via SSH, the username and password will be sent to privacyIDEA for verification. You can not use you OTP PIN and Yubikey to login.

If you experience any problems, take a look at /var/log/auth.log.

If everything is working fine, you are now authenticating with:

1. OTP token supported by privacyIDEA like Google Authenticator or preferable a Yubikey (hard possession factor – not copyable)
2. an optional OTP PIN controlled by privacyIDEA (knowledge)

Add SSH Keys

You may realize, that if you have an SSH key in the authorized_keys you will not be asked for the OTP. At the moment you either login with SSH key or with OTP. Let’s change this now, that you can use SSH key and OTP.

The current OpenSSH comes with the options AuthenticationMethods. This is used to concatenate required authentication methods. See the man page of sshd_config for more details.

In the file /etc/ssh/sshd_config we add this line:

AuthenticationMethods publickey,password

This means that SSH will require that you pass a trusted SSH key and after this ask you for a password (PIN+OTP), which will be verified by privacyIDEA.

The login will look like this:

root@gawain ~ # ssh root@privacyidea
Authenticated with partial success.
root@privacyidea's password: 
Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.13.0-66-generic x86_64)

The “Authenticated with partial success” means, that the authentication with the SSH key succeeded. Now you need to specify the One Time Password to be sent to privacyIDEA.

Note: If you want to login as user “root”, be sure to add “PermitRootLogin yes” to your sshd_config.

Finally we managed to authenticate the users with:

1. SSH Key (soft possession factor – copyable!)
2. optional passphrase on the SSH Key, which is not controlled by the server! (knowledge)
3. OTP token supported by privacyIDEA like Google Authenticator or preferable a Yubikey (hard possession factor – not copyable)
4. an optional OTP PIN controlled by privacyIDEA (knowledge)

Manage SSH Keys with privacyIDEA

Wait! Are you still there? One thing might still strike you:

While all OTP tokens are centrally managed by privacyIDEA, users still put their public SSH keys on all the machines and you are wondering where the SSH keys of all the users are floating around.

There is no easy way for you to revoke a compromized SSH key.

But you can also solve this with privacyIDEA. Users can upload their public SSH keys to privacyIDEA with the tokentype SSH Key.

This way you can also manage all SSH keys in privacyIDEA. In sshd_config you need to use the AuthorizedKeysCommand to retrieve the SSH keys from privayyIDEA just in time. Deleting an SSH key in privacyIDEA will deny access for this user immediatly.

You can read SSH Key Management with privacyIDEA to set this up.

This way you have three strong factors to secure the access to SSH.

This Howto describes the setup of privacyIDEA on CentOS 7 including a FreeRADIUS 3 configuration.

This Howto is provided by Patrick Hirschbühl. Thanks a lot for this contribution!

privacyIDEA + MySQL on CentOS 7

Minimal Installation of CentOS 7

yum -y install net-tools
yum -y install wget NetworkManager-tui

Example for /etc/hosts

 192.168.1.2 privacyideaserver privacyideaserver.domain

/etc/selinux/config

SELINUX=disabled

Install necessary software:

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY*
yum -y install epel-release
yum -y install yum-priorities

Edit /etc/yum.repos.d/epel.repo

[epel]
 name=Extra Packages for Enterprise Linux 7 - $basearch
 #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
 mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch
 failovermethod=priority
 priority=10
 enabled=1
 gpgcheck=1
 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7

Install further software:

yum update
yum -y groupinstall 'Development Tools'
yum -y install open-vm-tools net-tools; reboot
yum install ntp -y

Optional Tools:

yum install links nmap rkhunter

privacyIDEA

yum install mariadb-server httpd mod_wsgi mod_ssl python-devel gcc mariadb-devel libjpeg-devel \
freeradius freeradius-utils freeradius-perl openldap-devel perl-libwww-perl perl-Config-IniFiles \
perl-Try-Tiny perl-Data-Dump perl-JSON perl-LWP-Protocol-http* python-virtualenv libffi-devel \
freetype-devel libpng-devel postgresql-devel

 systemctl enable radiusd.service
 systemctl start radiusd
 systemctl enable mariadb.service
 systemctl start mariadb
 systemctl enable httpd.service
 systemctl start httpd

Create Database

mysql_secure_installation
echo 'create database privacyidea;' | mysql -u root -p
echo 'grant all privileges on privacyidea.* to "privacyidea"@"localhost" identified by "unknown";' \
   | mysql -u root -p

Install privacyIDEA

virtualenv /opt/privacyIDEA
cd /opt/privacyIDEA
source bin/activate

Install further requirements for building packages with pip:

yum -y install libxslt-devel libxml2-devel

Download requirements.txt from https://github.com/privacyidea/privacyidea/blob/master/requirements.txt

pip install -r requirements.txt
pip install MySQL-python
pip install privacyidea
mkdir /etc/privacyidea
mkdir /var/log/privacyidea

Edit /etc/privacyidea/pi.cfg:

# The realm, where users are allowed to login as administrators
SUPERUSER_REALM = ['super', 'administrators']
# Your database
SQLALCHEMY_DATABASE_URI = 'mysql://privacyidea:unknown@localhost/privacyidea'
# This is used to encrypt the auth_token
SECRET_KEY = 't0p s3cr3t'
# This is used to encrypt the admin passwords
PI_PEPPER = "Never know..."
# This is used to encrypt the token data and token passwords
PI_ENCFILE = '/etc/privacyidea/enckey'
# This is used to sign the audit log
PI_AUDIT_KEY_PRIVATE = '/etc/privacyidea/private.pem'
PI_AUDIT_KEY_PUBLIC = '/etc/privacyidea/public.pem'
PI_LOGFILE = '/var/log/privacyidea/privacyidea.log'
# PI_LOGLEVEL = 20
# PI_INIT_CHECK_HOOK = 'your.module.function'

Run further commands:

pi-manage.py create_enckey
pi-manage.py create_audit_keys
pi-manage.py createdb
pi-manage.py admin add admin -e admin@localhost

Add firewall rules

firewall-cmd --permanent --zone=public --add-service=http --add-service=https --add-service=radius
firewall-cmd --reload
firewall-cmd --zone=public --list-all

Test

systemctl stop httpd
pi-manage.py runserver -h Hostname-or-IP -p 80
systemctl start httpd

Create user

useradd -r -m privacyidea -d /opt/privacyIDEA

Fix rights privacyIDEA

chown -R privacyidea:root /etc/privacyidea
/opt/privacyIDEA/bin/privacyidea-fix-access-rights -f /etc/privacyidea/pi.cfg -u privacyidea
chmod 400 /etc/privacyidea/enckey
chmod 400 /etc/privacyidea/*.pem
chown -R privacyidea:root /var/log/privacyidea

privacyIDEA Apache config

mkdir -p /var/run/wsgi
cp /opt/privacyIDEA/etc/privacyidea/privacyideaapp.wsgi /etc/privacyidea
mv /etc/httpd/conf.d/welcome.conf /etc/httpd/conf.d/welcome.conf.disabled

Edit /etc/httpd/conf/httpd.conf:

ServerName Hostname-or-IP:80

Edit /etc/httpd/conf.d/privacyidea.conf:

TraceEnable off
ServerSignature Off
ServerTokens Prod
WSGIPythonHome /opt/privacyIDEA
WSGISocketPrefix /var/run/wsgi

<VirtualHost _default_:80>
  ServerAdmin webmaster@localhost
  ServerName localhost
  RewriteEngine On
  RewriteCond %{HTTPS} !=On
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

<VirtualHost _default_:443>
  ServerAdmin webmaster@localhost
  ServerName localhost
  DocumentRoot /var/www
  <Directory />
    Require all granted
    Options FollowSymLinks
    AllowOverride None
  </Directory>
  # The daemon is running as user 'privacyidea'
  # This user should have access to the encKey database encryption file
  WSGIDaemonProcess privacyidea python-path=/etc/privacyidea:/opt/privacyIDEA/lib/python2.7/site-packages processes=1 threads=15 display-name=%{GROUP} user=privacyidea
  WSGIProcessGroup privacyidea
  WSGIPassAuthorization On
  WSGIScriptAlias / /etc/privacyidea/privacyideaapp.wsgi
  SSLEngine On
  SSLProtocol All -SSLv2 -SSLv3
  SSLHonorCipherOrder On
  SSLCipherSuite EECDH+AES256:DHE+AES256:EECDH+AES:EDH+AES:-SHA1:EECDH+RC4:EDH+RC4:RC4-SHA:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5
  SSLCertificateFile /etc/pki/tls/certs/privacyideaserver.pem
  SSLCertificateKeyFile /etc/pki/tls/private/privacyideaserver.key
</VirtualHost>

Enable Apache config:

/opt/privacyIDEA/bin/privacyidea-create-certificate -f /etc/httpd/conf.d/privacyidea.conf
apachectl configtest
systemctl restart httpd

Config Freeradius 3 for privacyIDEA

cp /opt/privacyIDEA/lib64/privacyidea/authmodules/FreeRADIUS/privacyidea_radius.pm \
  /etc/raddb/mods-config/perl/

Edit /etc/raddb/mods-available/perl:

perl {
 filename = ${modconfdir}/${.:instance}/privacyidea_radius.pm
}

ln -s /etc/raddb/mods-available/perl /etc/raddb/mods-enabled/

Edit /etc/raddb/clients.conf:

client Radius-Client {
  ipaddr = 192.168.1.1/32
  secret = shared_secret_key
  require_message_authenticator = no
  nas_type = other
}

Edit /etc/raddb/sites-available/privacyidea:

server default {
 listen {
   type = auth
   ipaddr = *
   port = 0
   limit {
      max_connections = 16
      lifetime = 0
      idle_timeout = 30
   }
 }
 listen {
   ipaddr = *
   port = 0
   type = acct
   limit {
   }
 }

authorize {
   preprocess
   digest
   suffix
   ntdomain
   files
   expiration
   logintime
   pap
   update control {
      Auth-Type := Perl
   }
}

authenticate {
   Auth-Type Perl {
     perl
   }
   digest
}

preacct {
   suffix
   files
}

accounting {
   detail
}

session {
}
post-auth {
}
pre-proxy {
}
post-proxy {
}
}

ln -s /etc/raddb/sites-available/privacyidea /etc/raddb/sites-enabled/
rm /etc/raddb/sites-enabled/default
rm /etc/raddb/sites-enabled/inner-tunnel

Edit /etc/privacyidea/rlm_perl.ini:

[Default]
URL = https://127.0.0.1/validate/check
#REALM = someRealm
#RESCONF = someResolver
SSL_CHECK = false
#DEBUG = true

Edit /etc/raddb/mods-config/perl/privacyidea_radius.pm

our $CONFIG_FILE = “/etc/privacyidea/rlm_perl.ini”;
cp /opt/privacyIDEA/etc/privacyidea/dictionary /etc/raddb/

Test Freeradius

systemctl stop radiusd
radiusd -X
echo "User-Name=user, User-Password=password" | radclient -sx localhost auth testing123
systemctl restart radiusd

Fix rights privacyIDEA and Freeradius

chown -R privacyidea:root /etc/privacyidea
chgrp -R radiusd /etc/raddb
cd /etc/raddb
ll -Z
restorecon /etc/raddb/*

reboot

Change Password Admin User

cd /opt/privacyIDEA
source bin/activate
pi-manage.py admin change -p admin

Update privacyIDEA

cd /opt/privacyIDEA
source bin/activate
pip install --upgrade cffi
pip install --upgrade bcrypt
pip install --upgrade privacyidea