Versions

privacyIDEA: 2.17

Installation method:

• from source / github

more details:

OS: AmazonLinux

Webserver: nginx

Tokendatabase: PostgreSQL

======

Hi Cornelinux,

We are seeing some issue with the Validity Period settings:

1. WebUI format mismatch with database If you try to select a date from the calendar only, the date format string shown in the UI as a result is DD/MM/YY, and is recorded fine as DD/MM/YY in the token info (database)

However, if you try to select a date from the calendar and then insert a time string after, the date/time format shown in the UI is DD/MM/YY hh:mm, yet is recorded as MM/DD/YY hh:mm in the token info (database)

This is very confusing for user experience. The calendar selection format should agree with the string entering format.

2. Timezone The time enter in the webUI is likely local time zone for the user (for example PST), but it is always converted to GMT when saved in the database. And when the user authenticate, it is matched with local time zone against the literal-saved validity time in the token info.

For example: If the validity is entered as 08/03/17 04:43 (PST), it will be saved as 03/08/17 11:43 in the token info, and displayed in token details as so. (date and month is switched, and time is converted to GMT)

Provided that I manually fix the date so that the token info now is 08/03/17 11:43 (GMT). When a user authenticates at 11:00 PST it is failed due to out side of validity window because it is matching against the literal 11:43 GMT in the token info.

Because there is no timezone is shown, it is further confusing, especially for organization that has users across multiple timezones.

I am not sure if I may be missing some configuration to adjust this issue. I am looking forward to your input!

Thank you.

We need to be able to define recurring tasks every minute, 5 minutes, hour...

This can be used to

• process statistics counters (#990)
• rotate audit
• clean-up user cache
• measure other counters based on sql statements (Like count all not assigned hardware tokens #986

Such cron definitions would consist of

• time to repeat the task
• condition
• module to handle the task

This could be implemented in a similar modular way like the event handler.

Split from #829

I think this is also a good idea! If we do not want to change the audit table schema, we could also add a DEBUG logging output that sums up the activated policies for each request in a first step.

On the technical side, I think we have to differentiate between pre- and postpolicies:

I noticed that the prepolicies all return True in any case, but the return value doesn't seem to be processed. Couldn't we use the return value to indicate whether the policy was activated? The prepolicy decorator could then construct a list of activated policies in the request context (e.g. g.activated_prepolicies), i.e. a list of all policy functions that returned True. For postpolicies, it seems to be a bit harder because they return the new response. Maybe the postpolicy decorator could check whether the response was modified by the postpolicy? (e.g. if new_response != old_response or new_response.data != old_data: ...). Or we make this explicit and add a function announce_policy_activation() or something like that. We would just need to insert calls to that function at the right places.

Since last update to version 2.15 we have seen the following notification when viewing user information:

This occurs now and then and only occurred since last update. Closing the browser and logging back on seems to resolve the issue temporary.

We need the possiblitiy to run audit logs to sql audit and to a file.

We either could

• create a new audit module, that does both, inherited from SQLAudit
• enhance the SQLAudit module
• or allow the audit framework to write to multiple audit modules in parallel (sqlaudit and fileaudit)

Is your feature request related to a problem? Please describe. What are you trying to achieve?

Currenlty, pi supports sql, ldap, passwd and scim user's resolvers. A useful case for microservices is retrieving users from an external API. For example, http://domain.com/users/<userId>

Describe the solution you'd like A clear and concise description of what you want to happen.

• What is the purpose of the resolver

Use third party HTTP API for retrieving user data without follows the SCIM specs.

• How it works

Since PI does not store users, it uses resolvers like LDAP, SCIM, SQL, etc. Today, there is no way to resolve user information through an API but SCIM. SCIM uses an authorization server to authenticate the request, HTTP resolver will not. HTTP resolver could authenticate users via Authorization headers instead.

• How it is configured

The user would create an HTTP resolver only adding an HTTP endpoint under Add httpresolver UI. The endpoint must contain the '%s' symbol inside, symbol where pi will replace with their userId.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Add inversion control in order to be the user able to create custom resolvers instead of modifying pi code directly.

Additional context Add any other context or screenshots, that might help us to better understand your idea, your need and your circumstances.

The two step enrollment has to work with the privacyIDEA authenticator.

See

• https://github.com/privacyidea/privacyidea-authenticator/issues/4
• https://github.com/privacyidea/privacyidea-authenticator/issues/5

These things have to be done on the server side:

1. Implement the better key generation function based of pbkdf2
2. Create testvectors for the key generation, so that we can have tests on server side and on app side
3. Allow to choose 2step enrolment in enrollment ui. In case of 2step enrollment the enrollment ui needs to display an entry field (for the nonce) in addition to the QR code.
4. Add configuration option for
   • information to be put into the QR code (?pin=true, ?2step=true)
   • if at all/how and when to use 2step. So that not the admin or use can choose to enroll 2step but a policy will define this. The config options are probably best defined in an enrollment policy.

What did you try to do?

I wanted to upgrade privacyIDEA from version 2.11.3 to newest 2.19 or 2.18.1 version. I did everything as written in this website: http://privacyidea.readthedocs.io/en/latest/installation/upgrade.html but after upgrading I discovered problems with ldapresolver

What outcome did you expect?

What do you think, how the system should have worked?

Update should work without any problem.

What did acutally happen?

Users from Active directory are not able to log via VPN because of errors. The second issue is that privacyIDEA is running after update in debug mode, but in config file is still set to INFO.

Configuration

• privacyIDEA Version: 2.11.3 -> 2.19

• Installation method: pip install in virtualenv

more details:

• OS: CentOS 7

• Webserver: HTTPD 2.4.6-31.el7

• Tokendatabase: 5.5.44-MariaDB

Log file

Update LOG update.txt Database update LOG update_db.txt privacyidea.log [2017-06-26 11:30:14,202][3303][139998652352256][ERROR][privacyidea.lib.token:424] User information can not be retrieved: 'ascii' codec can't encode character u'\u0144' in position 27: ordinal not in range(128) [2017-06-26 11:30:14,202][3303][139998652352256][ERROR][privacyidea.lib.token:424] User information can not be retrieved: 'ascii' codec can't encode character u'\u0144' in position 27: ordinal not in range(128) [2017-06-26 11:30:14,793][3303][139998652352256][ERROR][privacyidea.lib.token:424] User information can not be retrieved: 'ascii' codec can't encode character u'\u0144' in position 14: ordinal not in range(128) [2017-06-26 11:30:14,793][3303][139998652352256][ERROR][privacyidea.lib.token:424] User information can not be retrieved: 'ascii' codec can't encode character u'\u0144' in position 14: ordinal not in range(128)

Currently, this is just an idea and I would be interested in your opinions :-)

There are currently three ways to install privacyIDEA (please correct me if I'm wrong):

• via native distribution packages, currently only Ubuntu
• via distribution packages using virtualenv (e.g. centos and debian-virtualenv)
• manually in a virtualenv via pip install privacyidea

In the past, we often had problems when there were new versions of dependencies which were incompatible with our codebase (e.g. ldap3/pyasn #912).

This can still happen, e.g. assume there is a dependency X which releases a new version 1.1 today that is incompatible with privacyIDEA 2.22. Then, all users who use pip install privacyidea today to install privacyIDEA 2.22 will get the newest version 1.1 of dependency X, which will cause problems, and will need to manually downgrade X to get a working installation. We can react by putting X<1.1 in our setup.py, but this requires us to make a new release.

In case of Ubuntu packages, the package repositories don't get updated too often, so the risk of incompatible new versions is pretty low here. The risk is higher for virtualenv packages and pip installations, because privacyidea-pip-update will upgrade all installed dependencies to their latest versions by default (though we can still explicitly exclude versions in setup.py).

So it might be nice to have "deterministic" installations in the sense that all versions of dependencies installed on user's machines are pinned and known to work with our current stable version.

Currently, I'm not sure how to do that nicely: Putting pinned dependencies in setup.py is discouraged. requirements.txt contains pinned versions, but pip install privacyidea installs dependencies from setup.py, not requirement.txt.

What do you think? :)

The conditions for a policy and event handler to apply could depend on any arbitrary user attribute (like a group membership)

See https://community.privacyidea.org/t/resolver-and-user-token-relation/941

Use RRDTool for data in time series.

https://oss.oetiker.ch/rrdtool/prog/rrdpython.en.html

We can do timeseries over:

• successfull authentications (all or per user, serial, resolver, realm)
• failed authentications (all or per user, serial, resolver, realm)
• API calls (all or per user)
• users, who issued calls
• ...

Top-level intent

I tried to upgrade my PI instance from 3.7.4 to 3.8.

Steps to reproduce

1. Install PI at version 3.7.4
2. Update to 3.8
3. Run pi-manage db upgrade

Expected outcome

Upgrade working fine without any issues.

Actual outcome

DB migration failed like this:

(psycopg2.errors.DuplicateTable) relation "customuserattribute_seq" already exists

Context

This was probably introduced by #3384 which also creates the db sequence customuserattribute_seq even though the corresponding data-structures seem to exist since 3.6 which seems questionable on its own already.

I just installed another instance of PrivacyIDEA at version 3.7.4 and on that instance the sequence customuserattribute_seq also existed already, so updating this test instance to 3.8 would cause the same problem.

Configuration

• privacyIDEA version: 3.7.4, issue occurred while upgrading to 3.8
• Installation method: NixOS module (services.privacyidea
• Python version: 3.9.16
• Operating system: NixOS
• Webserver: nginx
• Token database: PostgreSQL 13.9

Log file

n/a

Hi,

as I see, the server response has 2 image fields. One is called image (new, to show the QR Code) and another called img, which can contain any image assigned to the given challenge.

Can you consider using only one field for both of these? That will make our work easier and cleaner. And though, by token enrollment, we don't need to show any other image than this QR Code. E.g.: if "qrcode" is not empty -> replace the "img"

Or maybe I miss something?

We'd like to introduce PrivacyIdea in our environment, mainly to secure local Windows logins, but during brainstorming people quickly raised the issue that they'd get very annoyed with it if they had to enter their second factor every time they unlock their computer.

We've got a system policy set that locks a computer after X number of minutes of inactivity, and because of that a bunch of people would be forced to enter not only their password, but also their second factor multiple times per day. We do not want to disable the second factor for unlocking the system entirely though. We just want it to not be required every time the system is unlocked.

Our idea to combat this was to basically set things up in a way that will make the second factor absolutely mandatory if the system has been (these rules beat any others):

• just booted
• woken from standby (suspend to ram)
• woken from hibernation (suspend to disk)

However, if the system was only locked then the client should NOT require the second factor if the following condition is met:

• the user is just unlocking the system within XX minutes after having last used the second factor for login (or unlocking if XX had already expired before; we considered a value of something like 4 hours for XX; though obviously that should be configurable)

Further, the system should fall back to requiring the second factor under certain circumstances even if XX has not expired yet:

• If the system has been locked more than XY times in the last XZ minutes (our default was 10 times in 1 hour; both values should be configurable)
• If the user has entered a wrong password YY times while trying to unlock the system with the second factor disabled (our default value here was 3; again should be configurable)

I've got the whole ruleset written down as a Powershell script that gets executed by a scheduled tasks triggered on a number of eventlog IDs from the system and security eventlogs. Following the rules outlined above the script then modifies the "cpus_logon" and "cpus_unlock" registry keys to either enable or disable the second factor requirement. It also keeps track (in the registry) of when the second factor was last used (to calculate when XX has expired), when it was locked (MultiString with a list of timestamps) and number of unlocks to calculate when XY in XZ is exceeded, and obviously number of failed unlocks to reenable the second factor again after YY is exceeded.

The whole thing works but it adds an additional level of complexity I'd rather avoid if possible. However, we feel it is necessary to add such a feature to get not only our users but also management and VIPs on board with introducing PrivacyIDEA in our environment.

Instead of having a custom Powershell script trigger on eventlog entries I'd much rather have the client natively support all these features and pull the configured values (XX, XY, XZ and YY) from a central configuration point allowing us to easily change and adjust values.

Is this something you could/would consider to implement? Would be very much appreciated and surely very useful not only to us but others as well. On top of that it would add a nice feature to the list that other competitors in this field might not have and set PrivacyIDEA apart in that regard.

The QR-code sent to the client after enrollment during validate/check was incorrect, it just contained the token secret without the necessary HOTP/TOTP parameter.