OK, I was wrong.
First, it doesn't appear the dict_file in kdc.conf does anything, at least not with
the code used in freeipa. I suspect it’s because it only applies to users with password
policies, and the standard kerberos code probably doesn’t see the freeipa global policy as
a policy for specific users. kadmin.local getprinc says there’s no policy for my users.
Second, the pwqual plugin works for kpasswd but not for IPA passwd.
That ipa bypasses that plugin seems like a bug. I’m going to look at fixing it with a
python site-specific plugin.
On Jan 30, 2020, at 3:11 PM, Charles Hedrick via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
One thing that concerns me about pipe / socket connection is that ds389, and I assume
kadmind, are multithreaded. If you’re going to send queries to a separate process you
either have to serialize it or use a protocol that lets several queries be done at the
same time asynchronously. Any approach other than calling an external program and checking
the return code is likely to have that issue. Obviously most programming languages can
support this kind of thing, but the moment you require code to be asynchronous and use
locking you’re putting it beyond a typical sysadmin to write the code. If you want
sysadmins to be able to write policy, the cleanest approach is to call a separate process.
That would allow a simple shell script. The threading would all be handled in the C plugin
that does the call. But there would be more overhead, because for each password change
you’d have to start a process and open any files.
> On Jan 30, 2020, at 1:46:14 PM, Rob Crittenden <rcritten(a)redhat.com> wrote:
>
> Charles Hedrick wrote:
>> 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.
>
> Where have you done the integration to date?
>
> Your pipe idea is similar to the idea of sockets, so that it is more
> easily user-configurable. The socket would be on the server side as that
> is where policy is enforced.
>
> rob
>
>>
>>
>>> 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...
>>>
>>
>
_______________________________________________
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...