I looked into this a bit more. Currently we’re using a kerberos pwqual plugin. That is
called by both “IPA passwd” and “kpasswd”. You’ve described an interface that I know
nothing about and can’t find any documentation for. I’d be happy either to clean up our
pwqual plugin, or create a pwqual plugin that talks to a a pipe and supply a dictionary
check as an example.
The difference is that a pwqual plugin has to be done in C. A small C plugin that talks to
a pipe would make it easy to write a policy module in something like python. The advantage
of the pipe is that it avoids having to start the program each time there’s a request.
Another option, which I might do if it were just for me, is to call python from C. Of
course that requires you to commit to python, while any language can support pipes.
On Jan 28, 2020, at 4:34 PM, Charles Hedrick
<hedrick(a)rutgers.edu> wrote:
If you’d prefer an interface to ds389 I’d be wiling to work on that. But it’s not clear
from your reference whether the API is finished. If so, could you point to documentation,
or at least source?
> On Jan 28, 2020, at 4:12 PM, Charles Hedrick via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
>
> I can clean up our code, but it’s for a Kerberos pwqual plugin. That doesn’t seem to
be the approach you’re using. We’re actually using code from Stanford that’s configurable
for all kinds of policies, but we’re only using it for the database. Code that just checks
the database would be much simpler. I’m using an sqlite database, but I’d be happy with
other formats if you have a preference. (Stanford was doing additional checks that really
needed something as powerful as SQL. We’d implementing the NIST recommendation strictly,
and don’t need those other checks._
>
>> On Jan 28, 2020, at 2:40 PM, Rob Crittenden <rcritten(a)redhat.com> wrote:
>>
>> Charles Hedrick via FreeIPA-users wrote:
>>> The NIST recommendations for passwords say they don’t think character classes
and expiration are useful. Instead, they recommend using a blacklist of known common
passwords. There’s no way to implement this policy without writing your own plugin. It
would be useful for IPA’s password policy to allow you to specify a database of forbidden
passwords.
>>>
>>> We’ve done this using a plugin, but I’d rather not have to write C code to
implement policy.
>>
>> This sort of falls under the long-standing upstream issue
>>
https://pagure.io/freeipa/issue/5948 , the idea being that socket
>> activation is used to pass off policy onto some configurable daemon
>> which would return a yes/no.
>>
>> Password policy is very much hardcoded in IPA for old, legacy reasons.
>>
>> And I'll just throw out that patches are welcome, even if they need some
>> additional work.
>>
>> rob
>>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...