[Freeipa-users] Re: http Certificate expired
Den 01/05/2019 kl. 21.48 skrev Rob Crittenden via FreeIPA-users: > Klaus Vink Slott via FreeIPA-users wrote: >> Have had a small FreeIPA setup running for some time, but today I was unable >> to login at the web-gui on the master. It was possible to login at the >> replica but if try to delete a host I get: >> >> cannot connect to >> 'https://ipa.int.vink-slott.dk:443/ca/rest/certs/search?size=2147483647': >> [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:877) >> >> Indeed if I run a getcert list -c IPA on the master, one certificate is >> expired. >> Request ID '20190302094604': >> status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN >> stuck: yes >> key pair storage: type=FILE,location='/var/lib/ipa/private/httpd.key' >> certificate: type=FILE,location='/var/lib/ipa/certs/httpd.crt' >> CA: IPA >> issuer: CN=Certificate Authority,O=INT.VINK-SLOTT.DK >> subject: CN=ipa.int.vink-slott.dk,O=INT.VINK-SLOTT.DK >> expires: 2019-04-22 15:33:08 CEST >> dns: ipa.int.vink-slott.dk >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/libexec/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes >> >> All other certificates is valid and status: MONITORING >> >> I tried different measures based on google searches and old entries on this >> list. But all I have accomplished is to change the state to: >> Request ID '20190302094604': >> status: NEED_KEYINFO_READ_PIN >> stuck: yes >> key pair storage: >> type=FILE,location='/var/lib/ipa/private/httpd.key',pin set >> >> At this state I am not sure that I added the correct pin. - And why this is >> suddenly a problem. > > It depends very much on what version of IPA you are running, perhaps the > distro, and what you did to get the tracking into this state. > It is freeipa-server-4.7.2-1.1.fc28.x86_64 on a fully patched Fedora 28 What I tried so far (rebuild from memory and bash-history): # ipa-getcert resubmit -i 20190302094604 - result: status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN -> NEED_KEYINFO_READ_PIN Then I followed https://access.redhat.com/solutions/3939431 - no change Then I located pin in /etc/pki/pki-tomcat/password.conf and /etc/httpd/conf/password.conf and tried to add these like this: # getcert start-tracking -i 20190302094604 -P \ # [long-number from internal=] # ipa-getcert resubmit -i 20190302094604 - result: key pair storage now have " ,pin set" # getcert start-tracking -i 20190302094604 -P \ # [hexstring from internal:] - result: key pair storage now have " ,pin set" -- Klaus ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Password expiration oddness
Yuri Krysko via FreeIPA-users wrote: > Hello All, > > > > I have a user in our FreeIPA domain, whose password according to the > applied policy (displayed in the user properties UI ) should have > expired ~ 2 months ago, but it never did, nor did it force the user to > reset it. The below LDAP user attributes show old data and all in > accordance with the password policy. The user is still able to > authenticate to the applications using LDAP connection against the > FreeIPA servers. The krblastsuccessfulauth gets updated every time the > user logs in. I assume if I force-reset the user’s password, it will go > back to normal. However, I’d like to understand how to explain such a > bizarre behavior and avoid it in the future. > > > > User password expiration: 20190305034410Z > > krblastpwdchange: 20190104034410Z > > krblastsuccessfulauth: 20190501213547Z See https://pagure.io/freeipa/issue/1539 rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Password expiration oddness
Hello All, I have a user in our FreeIPA domain, whose password according to the applied policy (displayed in the user properties UI ) should have expired ~ 2 months ago, but it never did, nor did it force the user to reset it. The below LDAP user attributes show old data and all in accordance with the password policy. The user is still able to authenticate to the applications using LDAP connection against the FreeIPA servers. The krblastsuccessfulauth gets updated every time the user logs in. I assume if I force-reset the user’s password, it will go back to normal. However, I’d like to understand how to explain such a bizarre behavior and avoid it in the future. User password expiration: 20190305034410Z krblastpwdchange: 20190104034410Z krblastsuccessfulauth: 20190501213547Z Thanks, Yuri LEGAL DISCLAIMER: M.C. Dean, Inc. and its subsidiaries considers this e-mail and any files transmitted with it to be protected, proprietary or privileged information intended solely for the use of the named recipient(s). Any disclosure of this material or the information contained herein, in whole or in part, to anyone outside of the intended recipient or affiliates is strictly prohibited. M. C. Dean, Inc. accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of the information contained in it, unless that information is subsequently confirmed in writing. Employees of M.C. Dean, Inc. are instructed not to infringe on any rights of the recipient; any such communication violates company policy. If you are not the intended recipient, any disclosure, copying, distribution, or action taken or omitted in reliance on this information is strictly prohibited by M.C. Dean, Inc.; please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: http Certificate expired
Klaus Vink Slott via FreeIPA-users wrote: > Have had a small FreeIPA setup running for some time, but today I was unable > to login at the web-gui on the master. It was possible to login at the > replica but if try to delete a host I get: > > cannot connect to > 'https://ipa.int.vink-slott.dk:443/ca/rest/certs/search?size=2147483647': > [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:877) > > Indeed if I run a getcert list -c IPA on the master, one certificate is > expired. > Request ID '20190302094604': > status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN > stuck: yes > key pair storage: type=FILE,location='/var/lib/ipa/private/httpd.key' > certificate: type=FILE,location='/var/lib/ipa/certs/httpd.crt' > CA: IPA > issuer: CN=Certificate Authority,O=INT.VINK-SLOTT.DK > subject: CN=ipa.int.vink-slott.dk,O=INT.VINK-SLOTT.DK > expires: 2019-04-22 15:33:08 CEST > dns: ipa.int.vink-slott.dk > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > > All other certificates is valid and status: MONITORING > > I tried different measures based on google searches and old entries on this > list. But all I have accomplished is to change the state to: > Request ID '20190302094604': > status: NEED_KEYINFO_READ_PIN > stuck: yes > key pair storage: > type=FILE,location='/var/lib/ipa/private/httpd.key',pin set > > At this state I am not sure that I added the correct pin. - And why this is > suddenly a problem. It depends very much on what version of IPA you are running, perhaps the distro, and what you did to get the tracking into this state. rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] http Certificate expired
Have had a small FreeIPA setup running for some time, but today I was unable to login at the web-gui on the master. It was possible to login at the replica but if try to delete a host I get: cannot connect to 'https://ipa.int.vink-slott.dk:443/ca/rest/certs/search?size=2147483647': [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:877) Indeed if I run a getcert list -c IPA on the master, one certificate is expired. Request ID '20190302094604': status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN stuck: yes key pair storage: type=FILE,location='/var/lib/ipa/private/httpd.key' certificate: type=FILE,location='/var/lib/ipa/certs/httpd.crt' CA: IPA issuer: CN=Certificate Authority,O=INT.VINK-SLOTT.DK subject: CN=ipa.int.vink-slott.dk,O=INT.VINK-SLOTT.DK expires: 2019-04-22 15:33:08 CEST dns: ipa.int.vink-slott.dk key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_httpd track: yes auto-renew: yes All other certificates is valid and status: MONITORING I tried different measures based on google searches and old entries on this list. But all I have accomplished is to change the state to: Request ID '20190302094604': status: NEED_KEYINFO_READ_PIN stuck: yes key pair storage: type=FILE,location='/var/lib/ipa/private/httpd.key',pin set At this state I am not sure that I added the correct pin. - And why this is suddenly a problem. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Strange ipa group-add gid behavior
Orion Poplawski via FreeIPA-users wrote: > On 4/30/19 2:51 PM, Alexander Bokovoy wrote: >> On ti, 30 huhti 2019, Orion Poplawski wrote: >>> On 4/30/19 2:14 PM, Rob Crittenden wrote: Orion Poplawski via FreeIPA-users wrote: > On 4/30/19 2:00 PM, Alexander Bokovoy wrote: >> On ti, 30 huhti 2019, Orion Poplawski via FreeIPA-users wrote: >>> We're seeing some strange gid assignment behavior. When I run ipa >>> group-add >>> on one ipa client I get gids in the expected range for my domain >>> (8000-1). >>> But when it is run on one of our IPA servers we get numbers like 108500 >>> or >>> 58500. >>> >>> ipa idrange-find reports what I would expect everywhere: >>> >>> # ipa idrange-find >>> >>> 3 ranges matched >>> >>> Range name: AD.NWRA.COM_id_range >>> First Posix ID of the range: 2 >>> Number of IDs in the range: 2 >>> First RID of the corresponding RID range: 0 >>> Domain SID of the trusted domain: S-1-5-21- >>> Range type: Active Directory domain range >>> >>> Range name: legacy >>> First Posix ID of the range: 1000 >>> Number of IDs in the range: 100 >>> First RID of the corresponding RID range: 1 >>> First RID of the secondary RID range: 10001 >>> Range type: local domain range >>> >>> Range name: NWRA.COM_id_range >>> First Posix ID of the range: 8000 >>> Number of IDs in the range: 2000 >>> First RID of the corresponding RID range: 1000 >>> First RID of the secondary RID range: 1 >>> Range type: local domain range >>> >>> Number of entries returned 3 >>> >>> >>> ipa-client-4.6.4-10.el7.centos.3.x86_64 >>> >>> >>> No idea what else to look at. >> What about >> ipa-replica-manage dnarange-show >> ipa-replica-manage dnanextrange-show >> >> ? >> >> 'ipa idrange-*' commands are mostly for trusted AD domains' ranges and >> local ranges there are simply to allow SSSD to protect the space for IPA >> users/groups. When DNA plugin in IPA LDAP generates new IDs, it uses the >> data you can see with 'ipa-replica-manage dna*' commands. > > Ah, thanks. Yeah, that is different: > > #1.nwra.com: 8043-58499 > #2.nwra.com: 58501-108499 > #3.nwra.com: 108502-207999 > #4.nwra.com: No range set > #5.nwra.com: No range set > > So I guess I need to read up on that. Interesting that it is different > everywhere. I'm assuming that it should match the NWRA.COM_id_range above. > > We seem to be seeing issues with group membership for AD trust users in > HBAC > groups via external group membership not propagating out to clients, and I > guessed that the issue might have been the gid range of the group. I > still > think it is an issue. The IPA domain range by default is 200k IIRC and is (should be) immutable post-install. Did you really set only 2k entries when you initially installed IPA? >>> >>> Yes - this was a *LONG* time ago. >>> Note that 207999 - 8000 = 19 (not inclusive), so this actually looks ok. It also isn't a major problem that masters 4 and 5 don't have a range, is just means that users and groups haven't been added there for them to require a range. It would only make a difference if masters 1-3 died sudden deaths. >>> >>> Okay - I think I follow this logic better. >>> >>> But I'm still seeing problems with group membership. I have: >>> >>> adu...@ad.nwra.com member of aduser_exter...@nwra.com which belongs to >>> aduser_h...@nwra.com. gid of 108501 >>> >>> id adu...@ad.nwra.com on the IPA servers correctly reports membership in >>> aduser_hbac. >>> >>> but id aduser on the IPA clients do not. We are also making use of: >>> >>> full_name_format = %1$s >>> default_domain_suffix = ad.nwra.com >>> >>> >>> An error I see on the client: >>> >>> (Tue Apr 30 14:23:26 2019) [sssd[be[nwra.com]]] [ipa_s2n_get_list_next] >>> (0x0400): Received [aduser_h...@nwra.com] attributes from IPA server. >>> (Tue Apr 30 14:23:26 2019) [sssd[be[nwra.com]]] [ipa_s2n_get_list_next] >>> (0x0020): Object [aduser_h...@nwra.com] has no SID, please check the >>> ipaNTSecurityIdentifier attribute on the server-side >>> (Tue Apr 30 14:23:26 2019) [sssd[be[nwra.com]]] [ipa_s2n_get_list_done] >>> (0x0040): s2n get_fqlist request failed. >>> >>> And indeed no ipaNTSecurityIdentifier attribute was created for that group. >>> Probably because again I have a very restrictive range for that and the >>> assigned GID did not fit. >> It is not a GID but rather RID (relative identifier) which is identified >> by available ID ranges for the local range (now that is where 'ipa >> idrange-*' is playing a role). Most likely you had not enough range >> space to
[Freeipa-users] Re: Looking for guidance with FreeIPA integration with Foreman/Puppet/Katello
Hello, We execute a script after any server creation that uses the FreeIPA API for adding the sever to the proper Hostgroup. As we already have the HBAC rules created with the hostgroups, the teams that should access to the servers are allowed automatically. Regards. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
