Re: [Freeipa-users] RFE: default hbac is too open
On 03/05/2013 10:13 PM, Matthew Barr wrote: On Mar 5, 2013, at 9:15 AM, Rob Crittenden rcrit...@redhat.com wrote: Артур Файзуллин wrote: What rule must be present for replica to work? :) (in order to remove allow-all rule) I mean may be there is somewhere a guide to write rules for strict allows? During the installation we check that communication works between the two servers, so ssh is needed between masters (https://fedorahosted.org/freeipa/ticket/3298). You should be able to use --skip-conncheck to avoid this. I don't think we have any suggestions for rules, just documentation on how to write them in general. However, you could probably make a class of users - admins, for example - that can SSH to the KDC's. Who else would be making new replica's? You need the master passwords IIRC. We already have a pre-created group admins which should contain all users with admins privileges. You can use that group to create an HBAC rule assigning these users SSH access to the IPA servers. We just miss an automatically maintained hostgroup with all IPA masters that could be used in such HBAC rule - you would have to maintain it manually for now. There is a relevant RFE ticket though if you are interested: https://fedorahosted.org/freeipa/ticket/3416 I would really love to have the ability to easily give certain classes of users SSH, and potentially only on certain servers. That, plus the ability to change and set your password without ever logging into a system will allow us to really use IPA effectively.(We have users that don't use linux, and are in IPA only for LDAP Kerberos auth against web apps.) This use-case should be already solved. Such users can login to Web UI and change their passwords in a self-service page. Since FreeIPA 3.0+, they can also reset their password via Web UI in case it is expired and cannot be thus used to log in to the self-service page. HTH, Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Password expiry when account provisioned/updated via JSON RPC
On 03/05/2013 10:28 PM, Brian Smith wrote:
I set the policy to 1 year and recreated the account.
$ ipa pwpolicy-show --user=it-rc-test-faculty
Group: global_policy
Max lifetime (days): 365
Min lifetime (hours): 1
History size: 0
Character classes: 0
Min length: 8
Max failures: 10
Failure reset interval: 60
Lockout duration: 600
Looks like a bug was filed for this about 9 months
ago: https://fedorahosted.org/freeipa/ticket/2795
I can also confirm the same behavior when the policy is set to 0 days,
less than 90 days, or if I create a separate password policy for users
in the ipausers group. The result is always 90 days.
If the user updates the password themselves (after initial login) then
the password policy works and sets the expiry accordingly.
The user that is adding the users with userpasswd set appears in the
passsyncmanagersdns list:
passsyncmanagersdns:
uid=rc-user-svcacct,cn=users,cn=accounts,dc=rc,dc=usf,dc=edu
Can you work around this issue?
While it was filed 9 months ago it was found to not be that critical so
we deferred it till later time.
Patches are always welcome too :-)
On Mon, Mar 4, 2013 at 2:40 PM, Rob Crittenden rcrit...@redhat.com
mailto:rcrit...@redhat.com wrote:
Brian Smith wrote:
Thanks for your response, and sorry for my late response. I'm
on RHEL6,
using the packages from the distribution
repository, ipa-server-2.2.0-17.el6_3.1.x86_64
My pwpolicy is set as such (in testing):
$ ipa pwpolicy-show --all
dn: cn=global_policy,cn=rc.usf.edu http://rc.usf.edu
http://rc.usf.edu,cn=kerberos,dc=rc,dc=usf,dc=edu
Group: global_policy
Max lifetime (days): 365
Min lifetime (hours): 1
History size: 0
Character classes: 0
Min length: 8
Max failures: 10
Failure reset interval: 60
Lockout duration: 600
objectclass: top, nsContainer, krbPwdPolicy
If I create an account and set the password using the
following JSON
string, against $server/ipa/json, say today,
{
method:user_add,
params:[ [],
{
uid:it-rc-test-faculty,
homedirectory:/home/i/it-rc-test-faculty,
userpassword:MyPasswordInTheClear,
givenname:RC TEST - Faculty,
sn:Service_Account
}]
}
I get a password expiry time like so:
$ ipa user-show --all it-rc-test-faculty | grep
krbpasswordexpiration
krbpasswordexpiration: 20130602163523Z
That's clearly not one year into the future, but more like 90
days.
Is there something else I'm missing or are we looking at a bug?
I still can't reproduce this. I tried from our 3.x branch and the
2.2 bits on 6.3.
Can you do: ipa pwpolicy-show --user=it-rc-test-faculty
This will show the policy applied to that user.
Might also check /var/log/dirsrv/slapd-REALM/errors for anything
suspicious.
rob
Many thanks,
-Brian
On Tue, Feb 26, 2013 at 3:22 AM, Martin Kosek
mko...@redhat.com mailto:mko...@redhat.com
mailto:mko...@redhat.com mailto:mko...@redhat.com wrote:
On 02/25/2013 04:38 PM, Brian Smith wrote:
It seems that regardless of the global password expiry
setting,
that setting a
password via the methods
user-add
passwd
i will always have a password that expires in 90 days. I
followed the
instructions here
http://freeipa.org/page/PasswordSynchronization
to avoid the immediate expiry, but I need at least 180
days for my
configuration to work.
Any help would be appreciated!
--
Brian Smith
Assistant Director
Research Computing, University of South Florida
4202 E. Fowler Ave. SVC4010
Office Phone: +1 813 974-1467
tel:%2B1%20813%20974-1467 tel:%2B1%20813%20974-1467
Organization URL: http://rc.usf.edu
Hello Brian,
Updating maximum password expiration time with ipa
pwpolicy-mod
affects only
new passwords, i.e. password that you already changed will
have the
old lifetime.
When I tested this on Fedora 18, password change worked
for me:
# ipa pwpolicy-mod --maxlife 180
Group: global_policy
Max lifetime (days): 180
Min lifetime (hours): 1
History size: 0
Re: [Freeipa-users] Errors when trying IPA,Dovecot GSSAPI.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2013 02:46 PM, M.R Niranjan wrote: On 03/06/2013 08:03 PM, Johan Petersson wrote: Hi, I hope someone here can shed some light on what is wrong in my test environment. The error seem to be that Dovecot on mail server wants to access mail folder in my home directory on the NFS Server but can't get credentials for it. rpc.gssd on Mail Server try either to open a cachefile in /tmp that is corrupt or expired or if no cache file exists it just do error downcall. No try to update the key or create a new one. Should not forwardable tickets update the cache or generate a new one? The permission denied error in maillog i believe is because of no valid kerberos credentials. IPAserver NFS Server for Home Directory through autofs, IPA Client with nfs/share.test.net Mail server IPA Client with imap/mail.test.net,smtp/mail.test.net Clients pc's that are also IPA clients Everything is Red Hat 6.4 server and Client with default settings for IPA server and client. When trying to get mail i get ticket not accepted but i do get a imap ticket that i can see with klist. Ticket cache: FILE:/tmp/krb5cc_164483_UsqtSh Default principal: jo...@test.net Valid starting Expires Service principal 03/06/13 14:34:28 03/07/13 14:34:28 krbtgt/test@test.net 03/06/13 14:40:41 03/07/13 14:34:28 imap/mail.test@test.net 03/06/13 14:44:43 03/07/13 14:34:28 host/share.test@test.net Hopefully relevant logs: Mail Server /var/log/messages with rpc.gssapi -vvv: Mar 6 14:43:21 mail rpc.gssd[1143]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt12) Mar 6 14:43:21 mail rpc.gssd[1143]: handle_gssd_upcall: 'mech=krb5 uid=164483 enctypes=18,17,16,23,3,1,2 ' Mar 6 14:43:21 mail rpc.gssd[1143]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt12) Mar 6 14:43:21 mail rpc.gssd[1143]: process_krb5_upcall: service is 'null' Mar 6 14:43:21 mail rpc.gssd[1143]: getting credentials for client with uid 164483 for server share.test.net Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_machine_TEST.NET' being considered, with preferred realm 'TEST.NET' Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_machine_TEST.NET' owned by 0, not 164483 Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_164481_MOFHds' being considered, with preferred realm 'TEST.NET' Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_164481_MOFHds' owned by 0, not 164483 Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_0' being considered, with preferred realm 'TEST.NET' Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_0' owned by 0, not 164483 Mar 6 14:43:21 mail rpc.gssd[1143]: WARNING: Failed to create krb5 context for user with uid 164483 for server share.test.net Mar 6 14:43:21 mail rpc.gssd[1143]: doing error downcall Mail Server /var/log/maillog: Mar 06 14:43:11 master: Info: Dovecot v2.0.9 starting up (core dumps disabled) Mar 06 14:43:21 auth: Debug: Loading modules from directory: /usr/lib64/dovecot/auth Mar 06 14:43:21 auth: Debug: Module loaded: /usr/lib64/dovecot/auth/libauthdb_ldap.so Mar 06 14:43:21 auth: Debug: Module loaded: /usr/lib64/dovecot/auth/libdriver_sqlite.so Mar 06 14:43:21 auth: Debug: Module loaded: /usr/lib64/dovecot/auth/libmech_gssapi.so Mar 06 14:43:21 auth: Debug: auth client connected (pid=2183) Mar 06 14:43:21 auth: Debug: client in: AUTH 1 GSSAPI service=imap secured lip=192.168.0.33 rip=192.168.0.202 lport=143 rport=36424 Mar 06 14:43:21 auth: Debug: gssapi(?,192.168.0.202): Using all keytab entries Mar 06 14:43:21 auth: Debug: client out: CONT 1 Mar 06 14:43:21 auth: Debug: client in: CONThidden Mar 06 14:43:21 auth: Debug: gssapi(jo...@test.net,192.168.0.202): security context state completed. Mar 06 14:43:21 auth: Debug: client out: CONT 1 YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRv1MwL+M8NJprfWznLmhNSKz2ONwOwvw+2nJkIlLZiRLgIfQECmsAnkj6v54ukCkFNkcl0eCKTuHX9/8CTSpBQZL0RpeHHqfqMDDVRtKuiVaK7DzFOf/RC2ZTKmRD4l54p4PF5KA39L3VTNbkKhsIN Mar 06 14:43:21 auth: Debug: client in: CONThidden Mar 06 14:43:21 auth: Debug: gssapi(jo...@test.net,192.168.0.202): Negotiated security layer Mar 06 14:43:21 auth: Debug: client out: CONT 1 BQQF/wAMN4/a0gH///+o8Mw0PdRlusfHcCo= Mar 06 14:43:21 auth: Debug: client in: CONThidden Mar 06 14:43:21 auth: Debug: client out: OK 1 user=johan Mar 06 14:43:21 auth: Debug: master in: REQUEST 1818361857 2183 1 2f9e416bebaaac9a0a3f266165753c1b Mar 06 14:43:21 auth: Debug: passwd(johan,192.168.0.202): lookup Mar 06 14:43:21 auth: Debug: master out: USER 1818361857 johan system_groups_user=johan uid=164483 gid=164483 home=/nethome/johan Mar 06 14:43:21 imap-login: Info: Login: user=johan, method=GSSAPI, rip=192.168.0.202, lip=192.168.0.33, mpid=2186, TLS Mar
Re: [Freeipa-users] Errors when trying IPA,Dovecot GSSAPI.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2013 08:30 PM, Dale Macartney wrote: On 03/06/2013 02:46 PM, M.R Niranjan wrote: On 03/06/2013 08:03 PM, Johan Petersson wrote: Hi, I hope someone here can shed some light on what is wrong in my test environment. The error seem to be that Dovecot on mail server wants to access mail folder in my home directory on the NFS Server but can't get credentials for it. rpc.gssd on Mail Server try either to open a cachefile in /tmp that is corrupt or expired or if no cache file exists it just do error downcall. No try to update the key or create a new one. Should not forwardable tickets update the cache or generate a new one? The permission denied error in maillog i believe is because of no valid kerberos credentials. IPAserver NFS Server for Home Directory through autofs, IPA Client with nfs/share.test.net Mail server IPA Client with imap/mail.test.net,smtp/mail.test.net Clients pc's that are also IPA clients Everything is Red Hat 6.4 server and Client with default settings for IPA server and client. When trying to get mail i get ticket not accepted but i do get a imap ticket that i can see with klist. Ticket cache: FILE:/tmp/krb5cc_164483_UsqtSh Default principal: jo...@test.net Valid starting Expires Service principal 03/06/13 14:34:28 03/07/13 14:34:28 krbtgt/test@test.net 03/06/13 14:40:41 03/07/13 14:34:28 imap/mail.test@test.net 03/06/13 14:44:43 03/07/13 14:34:28 host/share.test@test.net Hopefully relevant logs: Mail Server /var/log/messages with rpc.gssapi -vvv: Mar 6 14:43:21 mail rpc.gssd[1143]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt12) Mar 6 14:43:21 mail rpc.gssd[1143]: handle_gssd_upcall: 'mech=krb5 uid=164483 enctypes=18,17,16,23,3,1,2 ' Mar 6 14:43:21 mail rpc.gssd[1143]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt12) Mar 6 14:43:21 mail rpc.gssd[1143]: process_krb5_upcall: service is 'null' Mar 6 14:43:21 mail rpc.gssd[1143]: getting credentials for client with uid 164483 for server share.test.net Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_machine_TEST.NET' being considered, with preferred realm 'TEST.NET' Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_machine_TEST.NET' owned by 0, not 164483 Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_164481_MOFHds' being considered, with preferred realm 'TEST.NET' Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_164481_MOFHds' owned by 0, not 164483 Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_0' being considered, with preferred realm 'TEST.NET' Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_0' owned by 0, not 164483 Mar 6 14:43:21 mail rpc.gssd[1143]: WARNING: Failed to create krb5 context for user with uid 164483 for server share.test.net Mar 6 14:43:21 mail rpc.gssd[1143]: doing error downcall Mail Server /var/log/maillog: Mar 06 14:43:11 master: Info: Dovecot v2.0.9 starting up (core dumps disabled) Mar 06 14:43:21 auth: Debug: Loading modules from directory: /usr/lib64/dovecot/auth Mar 06 14:43:21 auth: Debug: Module loaded: /usr/lib64/dovecot/auth/libauthdb_ldap.so Mar 06 14:43:21 auth: Debug: Module loaded: /usr/lib64/dovecot/auth/libdriver_sqlite.so Mar 06 14:43:21 auth: Debug: Module loaded: /usr/lib64/dovecot/auth/libmech_gssapi.so Mar 06 14:43:21 auth: Debug: auth client connected (pid=2183) Mar 06 14:43:21 auth: Debug: client in: AUTH 1 GSSAPI service=imap secured lip=192.168.0.33 rip=192.168.0.202 lport=143 rport=36424 Mar 06 14:43:21 auth: Debug: gssapi(?,192.168.0.202): Using all keytab entries Mar 06 14:43:21 auth: Debug: client out: CONT 1 Mar 06 14:43:21 auth: Debug: client in: CONThidden Mar 06 14:43:21 auth: Debug: gssapi(jo...@test.net,192.168.0.202): security context state completed. Mar 06 14:43:21 auth: Debug: client out: CONT 1 YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRv1MwL+M8NJprfWznLmhNSKz2ONwOwvw+2nJkIlLZiRLgIfQECmsAnkj6v54ukCkFNkcl0eCKTuHX9/8CTSpBQZL0RpeHHqfqMDDVRtKuiVaK7DzFOf/RC2ZTKmRD4l54p4PF5KA39L3VTNbkKhsIN Mar 06 14:43:21 auth: Debug: client in: CONThidden Mar 06 14:43:21 auth: Debug: gssapi(jo...@test.net,192.168.0.202): Negotiated security layer Mar 06 14:43:21 auth: Debug: client out: CONT 1 BQQF/wAMN4/a0gH///+o8Mw0PdRlusfHcCo= Mar 06 14:43:21 auth: Debug: client in: CONThidden Mar 06 14:43:21 auth: Debug: client out: OK 1 user=johan Mar 06 14:43:21 auth: Debug: master in: REQUEST 1818361857 2183 1 2f9e416bebaaac9a0a3f266165753c1b Mar 06 14:43:21 auth: Debug: passwd(johan,192.168.0.202): lookup Mar 06 14:43:21 auth: Debug: master out: USER 1818361857 johan system_groups_user=johan uid=164483 gid=164483 home=/nethome/johan Mar 06 14:43:21 imap-login: Info: Login: user=johan, method=GSSAPI,
Re: [Freeipa-users] Errors when trying IPA,Dovecot GSSAPI.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2013 08:30 PM, Dale Macartney wrote: On 03/06/2013 02:46 PM, M.R Niranjan wrote: On 03/06/2013 08:03 PM, Johan Petersson wrote: Hi, I hope someone here can shed some light on what is wrong in my test environment. The error seem to be that Dovecot on mail server wants to access mail folder in my home directory on the NFS Server but can't get credentials for it. rpc.gssd on Mail Server try either to open a cachefile in /tmp that is corrupt or expired or if no cache file exists it just do error downcall. No try to update the key or create a new one. Should not forwardable tickets update the cache or generate a new one? The permission denied error in maillog i believe is because of no valid kerberos credentials. IPAserver NFS Server for Home Directory through autofs, IPA Client with nfs/share.test.net Mail server IPA Client with imap/mail.test.net,smtp/mail.test.net Clients pc's that are also IPA clients Everything is Red Hat 6.4 server and Client with default settings for IPA server and client. When trying to get mail i get ticket not accepted but i do get a imap ticket that i can see with klist. Ticket cache: FILE:/tmp/krb5cc_164483_UsqtSh Default principal: jo...@test.net Valid starting Expires Service principal 03/06/13 14:34:28 03/07/13 14:34:28 krbtgt/test@test.net 03/06/13 14:40:41 03/07/13 14:34:28 imap/mail.test@test.net 03/06/13 14:44:43 03/07/13 14:34:28 host/share.test@test.net Hopefully relevant logs: Mail Server /var/log/messages with rpc.gssapi -vvv: Mar 6 14:43:21 mail rpc.gssd[1143]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt12) Mar 6 14:43:21 mail rpc.gssd[1143]: handle_gssd_upcall: 'mech=krb5 uid=164483 enctypes=18,17,16,23,3,1,2 ' Mar 6 14:43:21 mail rpc.gssd[1143]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt12) Mar 6 14:43:21 mail rpc.gssd[1143]: process_krb5_upcall: service is 'null' Mar 6 14:43:21 mail rpc.gssd[1143]: getting credentials for client with uid 164483 for server share.test.net Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_machine_TEST.NET' being considered, with preferred realm 'TEST.NET' Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_machine_TEST.NET' owned by 0, not 164483 Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_164481_MOFHds' being considered, with preferred realm 'TEST.NET' Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_164481_MOFHds' owned by 0, not 164483 Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_0' being considered, with preferred realm 'TEST.NET' Mar 6 14:43:21 mail rpc.gssd[1143]: CC file '/tmp/krb5cc_0' owned by 0, not 164483 Mar 6 14:43:21 mail rpc.gssd[1143]: WARNING: Failed to create krb5 context for user with uid 164483 for server share.test.net Mar 6 14:43:21 mail rpc.gssd[1143]: doing error downcall Mail Server /var/log/maillog: Mar 06 14:43:11 master: Info: Dovecot v2.0.9 starting up (core dumps disabled) Mar 06 14:43:21 auth: Debug: Loading modules from directory: /usr/lib64/dovecot/auth Mar 06 14:43:21 auth: Debug: Module loaded: /usr/lib64/dovecot/auth/libauthdb_ldap.so Mar 06 14:43:21 auth: Debug: Module loaded: /usr/lib64/dovecot/auth/libdriver_sqlite.so Mar 06 14:43:21 auth: Debug: Module loaded: /usr/lib64/dovecot/auth/libmech_gssapi.so Mar 06 14:43:21 auth: Debug: auth client connected (pid=2183) Mar 06 14:43:21 auth: Debug: client in: AUTH 1 GSSAPI service=imap secured lip=192.168.0.33 rip=192.168.0.202 lport=143 rport=36424 Mar 06 14:43:21 auth: Debug: gssapi(?,192.168.0.202): Using all keytab entries Mar 06 14:43:21 auth: Debug: client out: CONT 1 Mar 06 14:43:21 auth: Debug: client in: CONThidden Mar 06 14:43:21 auth: Debug: gssapi(jo...@test.net,192.168.0.202): security context state completed. Mar 06 14:43:21 auth: Debug: client out: CONT 1 YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRv1MwL+M8NJprfWznLmhNSKz2ONwOwvw+2nJkIlLZiRLgIfQECmsAnkj6v54ukCkFNkcl0eCKTuHX9/8CTSpBQZL0RpeHHqfqMDDVRtKuiVaK7DzFOf/RC2ZTKmRD4l54p4PF5KA39L3VTNbkKhsIN Mar 06 14:43:21 auth: Debug: client in: CONThidden Mar 06 14:43:21 auth: Debug: gssapi(jo...@test.net,192.168.0.202): Negotiated security layer Mar 06 14:43:21 auth: Debug: client out: CONT 1 BQQF/wAMN4/a0gH///+o8Mw0PdRlusfHcCo= Mar 06 14:43:21 auth: Debug: client in: CONThidden Mar 06 14:43:21 auth: Debug: client out: OK 1 user=johan Mar 06 14:43:21 auth: Debug: master in: REQUEST 1818361857 2183 1 2f9e416bebaaac9a0a3f266165753c1b Mar 06 14:43:21 auth: Debug: passwd(johan,192.168.0.202): lookup Mar 06 14:43:21 auth: Debug: master out: USER 1818361857 johan system_groups_user=johan uid=164483 gid=164483 home=/nethome/johan Mar 06 14:43:21 imap-login: Info: Login: user=johan, method=GSSAPI,
Re: [Freeipa-users] Password expiry when account provisioned/updated via JSON RPC
I'm going to dig into it further, hopefully produce a patch in the next few
days. My work-around for right now is ldapmodifying
the krbPasswordExpiration attribute on the account after creation and
subsequent password updates.
On Wed, Mar 6, 2013 at 8:40 AM, Dmitri Pal d...@redhat.com wrote:
On 03/05/2013 10:28 PM, Brian Smith wrote:
I set the policy to 1 year and recreated the account.
$ ipa pwpolicy-show --user=it-rc-test-faculty
Group: global_policy
Max lifetime (days): 365
Min lifetime (hours): 1
History size: 0
Character classes: 0
Min length: 8
Max failures: 10
Failure reset interval: 60
Lockout duration: 600
Looks like a bug was filed for this about 9 months ago:
https://fedorahosted.org/freeipa/ticket/2795
I can also confirm the same behavior when the policy is set to 0 days,
less than 90 days, or if I create a separate password policy for users in
the ipausers group. The result is always 90 days.
If the user updates the password themselves (after initial login) then
the password policy works and sets the expiry accordingly.
The user that is adding the users with userpasswd set appears in the
passsyncmanagersdns list:
passsyncmanagersdns:
uid=rc-user-svcacct,cn=users,cn=accounts,dc=rc,dc=usf,dc=edu
Can you work around this issue?
While it was filed 9 months ago it was found to not be that critical so we
deferred it till later time.
Patches are always welcome too :-)
On Mon, Mar 4, 2013 at 2:40 PM, Rob Crittenden rcrit...@redhat.comwrote:
Brian Smith wrote:
Thanks for your response, and sorry for my late response. I'm on RHEL6,
using the packages from the distribution
repository, ipa-server-2.2.0-17.el6_3.1.x86_64
My pwpolicy is set as such (in testing):
$ ipa pwpolicy-show --all
dn: cn=global_policy,cn=rc.usf.edu
http://rc.usf.edu,cn=kerberos,dc=rc,dc=usf,dc=edu
Group: global_policy
Max lifetime (days): 365
Min lifetime (hours): 1
History size: 0
Character classes: 0
Min length: 8
Max failures: 10
Failure reset interval: 60
Lockout duration: 600
objectclass: top, nsContainer, krbPwdPolicy
If I create an account and set the password using the following JSON
string, against $server/ipa/json, say today,
{
method:user_add,
params:[ [],
{
uid:it-rc-test-faculty,
homedirectory:/home/i/it-rc-test-faculty,
userpassword:MyPasswordInTheClear,
givenname:RC TEST - Faculty,
sn:Service_Account
}]
}
I get a password expiry time like so:
$ ipa user-show --all it-rc-test-faculty | grep krbpasswordexpiration
krbpasswordexpiration: 20130602163523Z
That's clearly not one year into the future, but more like 90 days.
Is there something else I'm missing or are we looking at a bug?
I still can't reproduce this. I tried from our 3.x branch and the 2.2
bits on 6.3.
Can you do: ipa pwpolicy-show --user=it-rc-test-faculty
This will show the policy applied to that user.
Might also check /var/log/dirsrv/slapd-REALM/errors for anything
suspicious.
rob
Many thanks,
-Brian
On Tue, Feb 26, 2013 at 3:22 AM, Martin Kosek mko...@redhat.com
mailto:mko...@redhat.com wrote:
On 02/25/2013 04:38 PM, Brian Smith wrote:
It seems that regardless of the global password expiry setting,
that setting a
password via the methods
user-add
passwd
i will always have a password that expires in 90 days. I
followed the
instructions here http://freeipa.org/page/PasswordSynchronization
to avoid the immediate expiry, but I need at least 180 days for my
configuration to work.
Any help would be appreciated!
--
Brian Smith
Assistant Director
Research Computing, University of South Florida
4202 E. Fowler Ave. SVC4010
Office Phone: +1 813 974-1467 tel:%2B1%20813%20974-1467
Organization URL: http://rc.usf.edu
Hello Brian,
Updating maximum password expiration time with ipa pwpolicy-mod
affects only
new passwords, i.e. password that you already changed will have the
old lifetime.
When I tested this on Fedora 18, password change worked for me:
# ipa pwpolicy-mod --maxlife 180
Group: global_policy
Max lifetime (days): 180
Min lifetime (hours): 1
History size: 0
Character classes: 0
Min length: 8
Max failures: 6
Failure reset interval: 60
Lockout duration: 600
# ipa user-add --first=Foo --last=Bar fbar
-
Added user fbar
-
User login: fbar
First name: Foo
Last name: Bar
Full name: Foo Bar
Display name: Foo Bar
Initials: FB
Home directory: /home/fbar
GECOS field: Foo Bar
Login shell: /bin/sh
Kerberos principal: f...@example.com
[Freeipa-users] Can I change an IPA client's IPA without re-enrolling it?
Hi Everyone, The subject says it all. I'm using IPA in CentOS 6. I know for a hostname change on a client, I'd have to uninstall the IPA client, change the hostname, and then reinstall it. But, I don't know if that holds true for IPs. Would a simple IP change require the uninstall/change/install steps? Regards, Ranbir -- Kanwar Ranbir Sandhu Linux 3.7.9-101.fc17.x86_64 x86_64 GNU/Linux 16:38:17 up 1 day, 22:46, 5 users, load average: 0.67, 0.42, 0.34 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Can I change an IPA client's IPA without re-enrolling it?
Kanwar Ranbir Sandhu wrote: Hi Everyone, The subject says it all. I'm using IPA in CentOS 6. I know for a hostname change on a client, I'd have to uninstall the IPA client, change the hostname, and then reinstall it. But, I don't know if that holds true for IPs. Would a simple IP change require the uninstall/change/install steps? Regards, Ranbir A re-install should not be necessary. Just be sure that forward and reverse name resolution works after making the change (something we test for during install). rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Can I change an IPA client's IPA without re-enrolling it?
On 03/06/2013 11:08 PM, Kanwar Ranbir Sandhu wrote: On Wed, 2013-03-06 at 16:50 -0500, Rob Crittenden wrote: A re-install should not be necessary. Just be sure that forward and reverse name resolution works after making the change (something we test for during install). Thanks. I'll give it a go. I just saw the typo in my subject. Fail. :P Ranbir Ranbir, you may also want to check --enable-dns-updates flag of ipa-client-install. It will configure SSSD to automatically run nsupdate when host IP changes. This would let you avoid manual DNS record changes. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
