Re: [Freeipa-users] Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute
Ivan Ferreira wrote: Hi everybody. I’m testing ipa-server 2.1.3. I’m trying to create a Certificate for vsftpd. I can successfully create the certificate with the following command: # ipa cert-request --add --principal=FTP/ftp.linux.com.py ftp.csr But I want to create certificates with subjectAltName DNS extensions, and it seems that is not possible through an openSSL CRS and dogtag. So I deleted the service entry, then I created again using: # ipa service-add FTP/ftp.linux.com.py Then, I try to create the certificate using the following command: # ipa-getcert request -k /etc/vsftpd/private/ftp.key -f /etc/vsftpd/certs/ftp.crt -N cn=ftp.linux.com.py -D cn=le-303.linux.com.py -D cn=ftp -D cn=le-303 -K FTP/ftp.linux.com.py But I have the following error: Request ID '20120108062420': status: CA_REJECTED ca-error: Server denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute of entry 'krbprincipalname=ftp/ftp.linux.com...@linux.com.py,cn=services,cn=accounts,dc=linux,dc=com,dc=py'.). stuck: yes key pair storage: type=FILE,location='/etc/vsftpd/private/ftp.key' certificate: type=FILE,location='/etc/vsftpd/certs/ftp.crt' CA: IPA issuer: subject: expires: unknown track: yes auto-renew: yes It looks like there is a problem with an ACI, or admin principal is not having enough privileges. ¿Anyone gime me some hints? ipa-getcert executes using the host principal of the machine it is running on. If you really want this machine to do the request you can add it as a manager to the service: # ipa service-add-host --hosts=host_you_are_on FTP/ftp.linux.com.py # ipa resubmit -i 20120108062420 If you don't want certmonger tracking this forever you can tell it to stop once the cert is generated with: # ipa-getcert stop-tracking -i 20120108062420 rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Expired SSL certificate issue with IPA
nasir nasir wrote: Hi, Would the below error cause any issues during replica and upgrade? # ipa user-show admin ipa: ERROR: cert validation failed for CN=xx.xx.com,O=xx.COM ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) ipa: ERROR: cert validation failed for CN=xx.xx.com,O=xx.COM ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) ipa: ERROR: cannot connect to 'any of the configured servers': https://xx.xx.com/ipa/xml, https://xx.xx.com/ipa/xml I don't think so but the problem will exist until addressed. In other words upgrading and/or creating a replica won't change things for this server. rob Nidal. --- On *Fri, 1/6/12, nasir nasir /kollath...@yahoo.com/* wrote: From: nasir nasir kollath...@yahoo.com Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA To: Rob Crittenden rcrit...@redhat.com Cc: freeipa-users@redhat.com, fasilk...@gmail.com Date: Friday, January 6, 2012, 9:12 AM Thanks for the input Rob, We have already did it with your previous input and everything got normal. But the ipa user-show admin command gave the following errors. # ipa user-show admin ipa: ERROR: cert validation failed for CN=xx.xx.com,O=xx.COM ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) ipa: ERROR: cert validation failed for CN=xx.xx.com,O=xx.COM ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) ipa: ERROR: cannot connect to 'any of the configured servers': https://xx.xx.com/ipa/xml, https://xx.xx.com/ipa/xml Regardless of the above error, everything seems to be working fine. Now we need to have the replica of the server before going for an upgrade of IPA. Thank you all for the wonderful support during our hard times. Nidal. --- On *Fri, 1/6/12, Rob Crittenden /rcrit...@redhat.com/* wrote: From: Rob Crittenden rcrit...@redhat.com Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA To: nasir nasir kollath...@yahoo.com Cc: freeipa-users@redhat.com, fasilk...@gmail.com Date: Friday, January 6, 2012, 7:21 AM nasir nasir wrote: Rob, # ipa user-show admin ipa: ERROR: cert validation failed for CN=openipa.hugayet.com,O=HUGAYET.COM ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.) ipa: ERROR: cert validation failed for CN=openipa.hugayet.com,O=HUGAYET.COM ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.) ipa: ERROR: cannot connect to 'any of the configured servers': https://openipa.hugayet.com/ipa/xml, https://openipa.hugayet.com/ipa/xml From what Nalin said, certmonger users /etc/ipa/ca.crt. This needs to match the CA that issued your Apache cert. How can we proceed further? I think you're going to need to set the system time back to when the certificate is valid to do the renewal. rob Nidal. --- On *Thu, 1/5/12, Rob Crittenden /rcrit...@redhat.com/*wrote: From: Rob Crittenden rcrit...@redhat.com Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA To: nasir nasir kollath...@yahoo.com Cc: freeipa-users@redhat.com, fasilk...@gmail.com Date: Thursday, January 5, 2012, 2:21 PM nasir nasir wrote: Hi Rob, Added the directive NSSEnforceValidCerts off in /etc/httpd/conf.d/nss.conf and restarted httpd. Please find the /var/log/httpd/error_log [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: KeyError(-1215723696,) in module 'threading' from '/usr/lib/python2.6/threading.pyc' ignored [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: KeyError(-1215723696,) in module 'threading' from '/usr/lib/python2.6/threading.pyc' ignored [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: KeyError(-1215723696,) in module 'threading' from '/usr/lib/python2.6/threading.pyc' ignored [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: KeyError(-1215723696,) in module 'threading' from '/usr/lib/python2.6/threading.pyc' ignored [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: KeyError(-1215723696,) in module 'threading' from '/usr/lib/python2.6/threading.pyc' ignored [Fri Jan 06 01:06:29 2012]
Re: [Freeipa-users] Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute
Thank you very much Rob for your time. The problem is solved. -Mensaje original- De: Rob Crittenden [mailto:rcrit...@redhat.com] Enviado el: lunes, 09 de enero de 2012 11:52 a.m. Para: Ivan Ferreira CC: freeipa-users@redhat.com Asunto: Re: [Freeipa-users] Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute Ivan Ferreira wrote: Hi everybody. I'm testing ipa-server 2.1.3. I'm trying to create a Certificate for vsftpd. I can successfully create the certificate with the following command: # ipa cert-request --add --principal=FTP/ftp.linux.com.py ftp.csr But I want to create certificates with subjectAltName DNS extensions, and it seems that is not possible through an openSSL CRS and dogtag. So I deleted the service entry, then I created again using: # ipa service-add FTP/ftp.linux.com.py Then, I try to create the certificate using the following command: # ipa-getcert request -k /etc/vsftpd/private/ftp.key -f /etc/vsftpd/certs/ftp.crt -N cn=ftp.linux.com.py -D cn=le-303.linux.com.py -D cn=ftp -D cn=le-303 -K FTP/ftp.linux.com.py But I have the following error: Request ID '20120108062420': status: CA_REJECTED ca-error: Server denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute of entry 'krbprincipalname=ftp/ftp.linux.com...@linux.com.py,cn=services,cn=accounts,dc=linux,dc=com,dc=py'.). stuck: yes key pair storage: type=FILE,location='/etc/vsftpd/private/ftp.key' certificate: type=FILE,location='/etc/vsftpd/certs/ftp.crt' CA: IPA issuer: subject: expires: unknown track: yes auto-renew: yes It looks like there is a problem with an ACI, or admin principal is not having enough privileges. ¿Anyone gime me some hints? ipa-getcert executes using the host principal of the machine it is running on. If you really want this machine to do the request you can add it as a manager to the service: # ipa service-add-host --hosts=host_you_are_on FTP/ftp.linux.com.py # ipa resubmit -i 20120108062420 If you don't want certmonger tracking this forever you can tell it to stop once the cert is generated with: # ipa-getcert stop-tracking -i 20120108062420 rob AVISO LEGAL: Esta información es privada y confidencial y está dirigida únicamente a su destinatario. Si usted no es el destinatario original de este mensaje y por este medio pudo acceder a dicha información por favor elimine el mensaje. La distribución o copia de este mensaje está estrictamente prohibida. Esta comunicación es sólo para propósitos de información y no debe ser considerada como propuesta, aceptación ni como una declaración de voluntad oficial de NUCLEO S.A. La transmisión de e-mails no garantiza que el correo electrónico sea seguro o libre de error. Por consiguiente, no manifestamos que esta información sea completa o precisa. Toda información está sujeta a alterarse sin previo aviso. This information is private and confidential and intended for the recipient only. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and shall not be regarded neither as a proposal, acceptance nor as a statement of will or official statement from NUCLEO S.A. . Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Initial login on RHEL 6 fails
For a users very first, (as in never logged in before and will have to
set new password), login attempt via GDM, the password change will fail
and the user will be unable to log in.
Now if the user has already set a password the login works fine. I
haven't tested after the password expires but I suspect it will be the
same as above.
The salient errors (I believe) in the logs are the following:
Jan 9 18:33:34 host.name pam: gdm-password[5056]:
pam_unix(gdm-password:auth): authe
ntication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=
user=user_name
Jan 9 18:33:34 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:auth): system
info: [Password has expired]
Jan 9 18:33:34 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:auth): authen
tication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=user_name
Jan 9 18:33:34 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:auth): receiv
ed for user user_name: 12 (Authentication token is no longer valid; new
one r
equired)
Jan 9 18:33:35 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:account): Use
r info message: Password expired. Change your password now.
Jan 9 18:33:35 host.name pam: gdm-password[5056]:
pam_unix(gdm-password:chauthtok): user user_name does not exist in
/etc/passwd
Jan 9 18:33:51 host.name pam: gdm-password[5056]:
pam_unix(gdm-password:chauthtok): user user_name does not exist in
/etc/passwd
Jan 9 18:33:52 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:chauthtok): system info: [Generic error (see e-text)]
Jan 9 18:33:52 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:chauthtok): User info message: Password change
failed. Server message: Failed to decrypt password
Jan 9 18:33:52 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:chauthtok): Password change failed for user
user_name: 20 (Authentication token manipulation error)
The KDC logs, don't shed a huge amount of light:
Jan 09 18:33:34 ipa.server krb5kdc[2379](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: CLIENT KEY EXPIRED: user_n...@realm.com for
krbtgt/realm@realm.com, Password has expired
Jan 09 18:33:34 ipa.server krb5kdc[2377](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: NEEDED_PREAUTH: user_n...@realm.com for kadmin/changepw@
REALM.COM, Additional pre-authentication required
Jan 09 18:33:34 ipa.server krb5kdc[2375](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: ISSUE: authtime 1326134014, etypes {rep=18 tkt=18
ses=18}, user_n...@realm.com for kadmin/chang...@realm.com
Jan 09 18:33:39 ipa.server krb5kdc[2375](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: NEEDED_PREAUTH: user_n...@realm.com for kadmin/changepw@
REALM.COM, Additional pre-authentication required
Jan 09 18:33:39 ipa.server krb5kdc[2382](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: ISSUE: authtime 1326134019, etypes {rep=18 tkt=18
ses=18}, user_n...@realm.com for kadmin/chang...@realm.com
Jan 09 18:33:51 ipa.server krb5kdc[2382](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: NEEDED_PREAUTH: user_n...@realm.com for kadmin/changepw@
REALM.COM, Additional pre-authentication required
After doing some testing while writing this message it appears that
kpasswd and even the sshd login fail as well in the same way.
A copy of /etc/pam.d/system-auth for completeness:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
authrequired pam_env.so
authsufficientpam_fprintd.so
authsufficientpam_unix.so nullok try_first_pass
authrequisite pam_succeed_if.so uid = 500 quiet
authsufficientpam_sss.so use_first_pass
authrequired pam_deny.so
account required pam_unix.so
account sufficientpam_localuser.so
account sufficientpam_succeed_if.so uid 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
passwordrequisite pam_cracklib.so try_first_pass retry=3 type=
minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=0
passwordsufficientpam_unix.so sha512 shadow nullok
try_first_pass use_authtok remember=12
passwordsufficientpam_sss.so use_authtok
passwordrequired pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session optional pam_oddjob_mkhomedir.so
session [success=1 default=ignore] pam_succeed_if.so service in
crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
session optionalpam_motd.so motd=/etc/motd
Let me know any thoughts on the matter,
-Erinn
signature.asc
Description: OpenPGP digital signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] consulting?
Just wondering if there was anyone listening on the list that might be available for little work integrating FreeIPA with Active Directory (preferrably in the south east US.) I hope this isn't against the list rules, I just thought one of you guys could help or point me in the right direction. Thanks. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Initial login on RHEL 6 fails
On 01/09/2012 02:16 PM, Erinn Looney-Triggs wrote:
For a users very first, (as in never logged in before and will have to
set new password), login attempt via GDM, the password change will fail
and the user will be unable to log in.
Now if the user has already set a password the login works fine. I
haven't tested after the password expires but I suspect it will be the
same as above.
The salient errors (I believe) in the logs are the following:
Jan 9 18:33:34 host.name pam: gdm-password[5056]:
pam_unix(gdm-password:auth): authe
ntication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=
user=user_name
Jan 9 18:33:34 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:auth): system
info: [Password has expired]
Jan 9 18:33:34 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:auth): authen
tication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=user_name
Jan 9 18:33:34 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:auth): receiv
ed for user user_name: 12 (Authentication token is no longer valid; new
one r
equired)
Jan 9 18:33:35 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:account): Use
r info message: Password expired. Change your password now.
Jan 9 18:33:35 host.name pam: gdm-password[5056]:
pam_unix(gdm-password:chauthtok): user user_name does not exist in
/etc/passwd
Jan 9 18:33:51 host.name pam: gdm-password[5056]:
pam_unix(gdm-password:chauthtok): user user_name does not exist in
/etc/passwd
Jan 9 18:33:52 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:chauthtok): system info: [Generic error (see e-text)]
Jan 9 18:33:52 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:chauthtok): User info message: Password change
failed. Server message: Failed to decrypt password
Jan 9 18:33:52 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:chauthtok): Password change failed for user
user_name: 20 (Authentication token manipulation error)
The KDC logs, don't shed a huge amount of light:
Jan 09 18:33:34 ipa.server krb5kdc[2379](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: CLIENT KEY EXPIRED: user_n...@realm.com for
krbtgt/realm@realm.com, Password has expired
Jan 09 18:33:34 ipa.server krb5kdc[2377](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: NEEDED_PREAUTH: user_n...@realm.com for kadmin/changepw@
REALM.COM, Additional pre-authentication required
Jan 09 18:33:34 ipa.server krb5kdc[2375](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: ISSUE: authtime 1326134014, etypes {rep=18 tkt=18
ses=18}, user_n...@realm.com for kadmin/chang...@realm.com
Jan 09 18:33:39 ipa.server krb5kdc[2375](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: NEEDED_PREAUTH: user_n...@realm.com for kadmin/changepw@
REALM.COM, Additional pre-authentication required
Jan 09 18:33:39 ipa.server krb5kdc[2382](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: ISSUE: authtime 1326134019, etypes {rep=18 tkt=18
ses=18}, user_n...@realm.com for kadmin/chang...@realm.com
Jan 09 18:33:51 ipa.server krb5kdc[2382](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: NEEDED_PREAUTH: user_n...@realm.com for kadmin/changepw@
REALM.COM, Additional pre-authentication required
After doing some testing while writing this message it appears that
kpasswd and even the sshd login fail as well in the same way.
A copy of /etc/pam.d/system-auth for completeness:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
authrequired pam_env.so
authsufficientpam_fprintd.so
authsufficientpam_unix.so nullok try_first_pass
authrequisite pam_succeed_if.so uid = 500 quiet
authsufficientpam_sss.so use_first_pass
authrequired pam_deny.so
account required pam_unix.so
account sufficientpam_localuser.so
account sufficientpam_succeed_if.so uid 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
passwordrequisite pam_cracklib.so try_first_pass retry=3 type=
minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=0
passwordsufficientpam_unix.so sha512 shadow nullok
try_first_pass use_authtok remember=12
passwordsufficientpam_sss.so use_authtok
passwordrequired pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session optional pam_oddjob_mkhomedir.so
session [success=1 default=ignore] pam_succeed_if.so service in
crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
session optionalpam_motd.so motd=/etc/motd
Let me know any thoughts on the matter,
-Erinn
Did you create a user and added a password for him?
ipa user-add ...
ipa passwd ...
Can you please provide the output of the:
ipa user-show user
Re: [Freeipa-users] Initial login on RHEL 6 fails
On 01/09/2012 11:33 AM, Dmitri Pal wrote:
On 01/09/2012 02:16 PM, Erinn Looney-Triggs wrote:
For a users very first, (as in never logged in before and will have to
set new password), login attempt via GDM, the password change will fail
and the user will be unable to log in.
Now if the user has already set a password the login works fine. I
haven't tested after the password expires but I suspect it will be the
same as above.
The salient errors (I believe) in the logs are the following:
Jan 9 18:33:34 host.name pam: gdm-password[5056]:
pam_unix(gdm-password:auth): authe
ntication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=
user=user_name
Jan 9 18:33:34 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:auth): system
info: [Password has expired]
Jan 9 18:33:34 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:auth): authen
tication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=user_name
Jan 9 18:33:34 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:auth): receiv
ed for user user_name: 12 (Authentication token is no longer valid; new
one r
equired)
Jan 9 18:33:35 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:account): Use
r info message: Password expired. Change your password now.
Jan 9 18:33:35 host.name pam: gdm-password[5056]:
pam_unix(gdm-password:chauthtok): user user_name does not exist in
/etc/passwd
Jan 9 18:33:51 host.name pam: gdm-password[5056]:
pam_unix(gdm-password:chauthtok): user user_name does not exist in
/etc/passwd
Jan 9 18:33:52 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:chauthtok): system info: [Generic error (see e-text)]
Jan 9 18:33:52 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:chauthtok): User info message: Password change
failed. Server message: Failed to decrypt password
Jan 9 18:33:52 host.name pam: gdm-password[5056]:
pam_sss(gdm-password:chauthtok): Password change failed for user
user_name: 20 (Authentication token manipulation error)
The KDC logs, don't shed a huge amount of light:
Jan 09 18:33:34 ipa.server krb5kdc[2379](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: CLIENT KEY EXPIRED: user_n...@realm.com
mailto:user_n...@realm.com for
krbtgt/realm@realm.com mailto:krbtgt/realm@realm.com, Password has
expired
Jan 09 18:33:34 ipa.server krb5kdc[2377](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: NEEDED_PREAUTH: user_n...@realm.com
mailto:user_n...@realm.com for kadmin/changepw@
REALM.COM, Additional pre-authentication required
Jan 09 18:33:34 ipa.server krb5kdc[2375](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: ISSUE: authtime 1326134014, etypes {rep=18 tkt=18
ses=18}, user_n...@realm.com mailto:user_n...@realm.com for
kadmin/chang...@realm.com mailto:kadmin/chang...@realm.com
Jan 09 18:33:39 ipa.server krb5kdc[2375](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: NEEDED_PREAUTH: user_n...@realm.com
mailto:user_n...@realm.com for kadmin/changepw@
REALM.COM, Additional pre-authentication required
Jan 09 18:33:39 ipa.server krb5kdc[2382](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: ISSUE: authtime 1326134019, etypes {rep=18 tkt=18
ses=18}, user_n...@realm.com mailto:user_n...@realm.com for
kadmin/chang...@realm.com mailto:kadmin/chang...@realm.com
Jan 09 18:33:51 ipa.server krb5kdc[2382](info): AS_REQ (4 etypes {18 17 16
23}) 74.93.225.129: NEEDED_PREAUTH: user_n...@realm.com
mailto:user_n...@realm.com for kadmin/changepw@
REALM.COM, Additional pre-authentication required
After doing some testing while writing this message it appears that
kpasswd and even the sshd login fail as well in the same way.
A copy of /etc/pam.d/system-auth for completeness:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
authrequired pam_env.so
authsufficientpam_fprintd.so
authsufficientpam_unix.so nullok try_first_pass
authrequisite pam_succeed_if.so uid = 500 quiet
authsufficientpam_sss.so use_first_pass
authrequired pam_deny.so
account required pam_unix.so
account sufficientpam_localuser.so
account sufficientpam_succeed_if.so uid 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
passwordrequisite pam_cracklib.so try_first_pass retry=3 type=
minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=0
passwordsufficientpam_unix.so sha512 shadow nullok
try_first_pass use_authtok remember=12
passwordsufficientpam_sss.so use_authtok
passwordrequired pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session optional pam_oddjob_mkhomedir.so
session [success=1 default=ignore] pam_succeed_if.so service in
crond quiet use_uid
session
Re: [Freeipa-users] migration plan from local accounts
Let me know if there is anything unclear about AIX clients in the documentation on freeipa.org. May I ask why there is a krb5 server as a requirement on a client? Thanks Le 5 janv. 2012 19:50, Simo Sorce s...@redhat.com a écrit : On Thu, 2012-01-05 at 18:27 -0500, Sylvain Angers wrote: Hi again, by moving away from local account, to freeipa do we affect any of these numbers?: -group name length limits -group membership limits or they remain the same / as the under limit of the local os? On linux, I believe there will still be a limitation of 16 id per group, right? Linux has a limitation of 65K groups per user, and this has been true for many years now. If you use NFS with sys auth instead of krb5 auth then you have a lim On Thu, 2012-01-05 at 18:27 -0500, Sylvain Angers wrote: Hi again, by moving away from local account, to freeipa do we affect any of these numbers?: -group name length limits -group membership limits or they remain the same / as the under limit of the local os? On linux, I believe there will still be a limitation of 16 id per group, right? Linux has a limitation of 65K groups per user, and this has been true for many years now. If you use NFS with sys auth instead of krb5 auth then you have a limitation of 16 groups per user, but this is a protocol limitation valid for all OSs, it is not a limitation of Linux. And using krb5 auth there is no such limitation. If anyone has some past experience with AIX, feel free to share with me We did some qualification/documentation testing on AIX a while back. All I can say is that AIX can work agains FreeIPA just fine, but I am in no way an AIX expert and the docs we have on freeipa.org are all I can tell you to use as I already forgot all the details we dicovered at the time we tested AIX :) I am really interested to ear about it Let me know if there is anything unclear about AIX clients in the documentation on freeipa.org. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Initial login on RHEL 6 fails
On Mon, 2012-01-09 at 12:28 -0900, Erinn Looney-Triggs wrote: [snip] Looks like the expiration is not updated, I suspect the password change actually failed. A couple of additional notes that may be important. The system to which I am attempting to authenticate lives in private IP space whereas the IPA server is on a public IP. Does it mean the client system is NATed wrt IPA ? I think that could make kpasswd fail. I need to check if this has been addressed in MIT libraries but IIRC it is a known limitation so far. The kpasswd binary I think specifies the IP address in mk_priv and fails verification from behind a NAT. Second HBAC is in effect on the host so the user must be a member of the desktop group in order to authenticate. HBAC is not involved in any way with password changes, so I am confident you can exclude any correlation. These may not have any bearing, or they may who knows. Yes the NAT part may be your issue. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Initial login on RHEL 6 fails
On 01/09/2012 01:31 PM, Simo Sorce wrote: On Mon, 2012-01-09 at 12:28 -0900, Erinn Looney-Triggs wrote: [snip] Looks like the expiration is not updated, I suspect the password change actually failed. A couple of additional notes that may be important. The system to which I am attempting to authenticate lives in private IP space whereas the IPA server is on a public IP. Does it mean the client system is NATed wrt IPA ? That is correct. I think that could make kpasswd fail. I need to check if this has been addressed in MIT libraries but IIRC it is a known limitation so far. The kpasswd binary I think specifies the IP address in mk_priv and fails verification from behind a NAT. Second HBAC is in effect on the host so the user must be a member of the desktop group in order to authenticate. HBAC is not involved in any way with password changes, so I am confident you can exclude any correlation. These may not have any bearing, or they may who knows. Yes the NAT part may be your issue. Yeah my kerb foo is a little rusty but the whole NAT/kerb thing causing issues does ring a bell with me too. I will continue to research. Thanks for the info, -Erinn signature.asc Description: OpenPGP digital signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] migration plan from local accounts
On 01/09/2012 04:59 PM, Sylvain Angers wrote: Let me know if there is anything unclear about AIX clients in the documentation on freeipa.org http://freeipa.org/. May I ask why there is a krb5 server as a requirement on a client? Thanks Server is not a requirement on the client. And kerberos client is optional too. It is not a requirement but rather recommended for the best security and SSO purposes this is why we recommend and use by default configuration. But you can configure client to use LDAP only for authentication and identity lookups. It would work too. Le 5 janv. 2012 19:50, Simo Sorce s...@redhat.com mailto:s...@redhat.com a écrit : On Thu, 2012-01-05 at 18:27 -0500, Sylvain Angers wrote: Hi again, by moving away from local account, to freeipa do we affect any of these numbers?: -group name length limits -group membership limits or they remain the same / as the under limit of the local os? On linux, I believe there will still be a limitation of 16 id per group, right? Linux has a limitation of 65K groups per user, and this has been true for many years now. If you use NFS with sys auth instead of krb5 auth then you have a lim On Thu, 2012-01-05 at 18:27 -0500, Sylvain Angers wrote: Hi again, by moving away from local account, to freeipa do we affect any of these numbers?: -group name length limits -group membership limits or they remain the same / as the under limit of the local os? On linux, I believe there will still be a limitation of 16 id per group, right? Linux has a limitation of 65K groups per user, and this has been true for many years now. If you use NFS with sys auth instead of krb5 auth then you have a limitation of 16 groups per user, but this is a protocol limitation valid for all OSs, it is not a limitation of Linux. And using krb5 auth there is no such limitation. If anyone has some past experience with AIX, feel free to share with me We did some qualification/documentation testing on AIX a while back. All I can say is that AIX can work agains FreeIPA just fine, but I am in no way an AIX expert and the docs we have on freeipa.org http://freeipa.org are all I can tell you to use as I already forgot all the details we dicovered at the time we tested AIX :) I am really interested to ear about it Let me know if there is anything unclear about AIX clients in the documentation on freeipa.org http://freeipa.org. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
