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.
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
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@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
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@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@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@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
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@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@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@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@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
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@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@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@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@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
On Jan 30, 2020, at 1:46:14 PM, Rob Crittenden rcritten@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.
At the moment it’s a pwqual plugin. There’s an API defined by MIT for a plugin to check password acceptabiity. It’s a sharable library. It’s declared in /etc/krb5.conf on the servers, in a [plugins] section. tt can reject a password or pass it on to the next module in the chain.
There’s an initialization section, so the database can be opened once, and anything necessary cached. They way that works is that the API allows a pointer to any state information. So init can allocate data structures, stick pointers to all the data into a single struct, and hand that back through the API as the state to be maintained. Either it would be readonly or you’d have to use a lock to change it. The only disadvantage I can see to this approach is that these plugins have to be written in C, and writing Kerberos code in C isn’t something you want novices to do, because there’s a lot of danger of memory leaks or corruption.
Obviously this handles kpasswd, since that goes through the normal Kerberos code. I was a bit surprised to see to a proposal to add something extra to ds389, since the pwqual interface is the standard way to do password policy. I wondered if maybe “ipa passwd” bypassed it, somehow talking directly to ds389. But I don’t think that’s the case. I tried setting a password in “ipa passwd” that our tests would reject, and it was rejected. (That was a password for myself. When authenticated as a passwd sync agent and changed someone else’s password, it seems to bypass the checks.)
Actually as I’ve looked a bit more, I’m thinking that this whole thing is unnecessary. I haven’t tested it yet, but there’s a standard MIT module pwqual_dict that already does dictionary checks. You just have to declare the dictionary file in kdc.conf. I’m going to try that shortly. If it works, there’s no reason to continue using our plugin, and you should just document this for Freeipa users. Ideally it might be interesting for the password policy to control whether to do a dictionary check. The way it currently works is the dictionary check is done if any password policy is in effect for that principal. That’s good enough for us.
It still might be useful to have a plugin that calls something like an external python program, to make it easier for people to write their own policies. But if the existing pwqual_dict works, we wouldn’t need it. If you’re interested in that kind of extension mechanism, the MIT approach would be to create a pwqual plugin. it could either talk to an external service through a pipe / socket, or if you’re willing to standardize on python, load a piece of python code. Since there’s a one-time initialization call, the python could open any databases or load any caches at that point, though maintaining state would require sone investigation into how C and python data structures interoperate. If you’re willing to say that password changes aren’t frequent enough to be a performance issue, you could just call a program and check the return code. That would make it easy to do a policy in any language, including a bash script. In our installation that would be OK, but you might have users whose sites are so big that password change becomes a performance concern.
rob
On Jan 28, 2020, at 4:34 PM, Charles Hedrick hedrick@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@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@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@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
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@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@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@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@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@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
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@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@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@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@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@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@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
freeipa-users@lists.fedorahosted.org
-
Charles Hedrick -
Rob Crittenden