[Freeipa-users] Re: How to make ipa root certificate available system wide
On to, 10 loka 2019, Kevin Vasko wrote: So I went back and read, reread, studied what you wrote and I think I’m following you. I’m really unfamiliar with certs and the tools around it so forgive the ignorance. So what I ended up doing is spinning up a CentOS7 VM and installing everything on it, adding it to the FreeIPA realm etc. and followed your instructions/email. I ran the modutil -dbdir sql:./mozilla/firefox/9zd63dro.default/ -list It returns the list of the PKCS #11 Modules like I listed in my previous email. However, it only showed a single item “NSS Internal PKCS #11 Module”. To look at what keys it had I ran certutil -d sql:./mozilla/firefox/9zd63dro.default/ -h “NSS Internal PKCS #11” -L This seemed like it returned all of the system wide certs. Including my self signed internal lan cert from freeipa. Should it have? That’s where I’m getting confused with your comment in your email when you mentioned the p11-kit-proxy and where it’s coming from, how it was added (if needed) as you said it was providing all of the system wide certs? At this point this is where things took a detour and I think it’s part of my confusion, which I think is unrelated, but I was using Firefox, all of the certs are there in the system based on the commands you showed. However, every time i would visit my http server Firefox would throw a SEC_ERROR_REVOKED_CERTIFICATE I pulled my hair out for 2 hours, deleting the .mozilla folder, recreating it, looking at certs, trying to manually copy certs into the cert db etc. Until I got fed up and tried Chrome...i downloaded chrome installed it ran it, checked the certs db looked at the certs and verified my internal cert was listed just like firefox. I visited the http server in chrome and it worked perfectly. No changes, which I believe is what you would expect. I then went and tried the same thing on Ubuntu. I know you mentioned that I have to add the certs manually as Ubuntu doesn’t have the same functionality. So I just manually added my ipa.crt to firefox and then got a SEC_ERROR_REVOKED_CERTIFICATE installed chrome on ubuntu machine and manually imported the ipa.crt into chrome, went to the http and chrome worked fine. So now I have no idea where I’m getting this SEC_ERROR_REVOKED_CERTIFICATE So now on a freeipa realm joined host. It seems that CentOS7 - Firefox gets a - SEC_ERROR_REVOKED_CERTIFICATE Chrome - Works out of the box Ubuntu 18.04 - Firefox gets after manually adding cert- SEC_ERROR_REVOKED_CERTIFICATE Chrome - works after manually adding the ipa.ca cert through GUI. Is there some obvious reason why firefox would throw that error message but Chrome wouldn’t? This stuff is making my head spin. For that host certificate Firefox thinks it is revoked by its issuer. Did you fiddle with the certificates? Perhaps, it would be easier to find out what certificate is that and check its status in IPA or whoever issued it? -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ 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://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.fedorahosted.org
[Freeipa-users] Re: How to make ipa root certificate available system wide
So I went back and read, reread, studied what you wrote and I think I’m following you. I’m really unfamiliar with certs and the tools around it so forgive the ignorance. So what I ended up doing is spinning up a CentOS7 VM and installing everything on it, adding it to the FreeIPA realm etc. and followed your instructions/email. I ran the modutil -dbdir sql:./mozilla/firefox/9zd63dro.default/ -list It returns the list of the PKCS #11 Modules like I listed in my previous email. However, it only showed a single item “NSS Internal PKCS #11 Module”. To look at what keys it had I ran certutil -d sql:./mozilla/firefox/9zd63dro.default/ -h “NSS Internal PKCS #11” -L This seemed like it returned all of the system wide certs. Including my self signed internal lan cert from freeipa. Should it have? That’s where I’m getting confused with your comment in your email when you mentioned the p11-kit-proxy and where it’s coming from, how it was added (if needed) as you said it was providing all of the system wide certs? At this point this is where things took a detour and I think it’s part of my confusion, which I think is unrelated, but I was using Firefox, all of the certs are there in the system based on the commands you showed. However, every time i would visit my http server Firefox would throw a SEC_ERROR_REVOKED_CERTIFICATE I pulled my hair out for 2 hours, deleting the .mozilla folder, recreating it, looking at certs, trying to manually copy certs into the cert db etc. Until I got fed up and tried Chrome...i downloaded chrome installed it ran it, checked the certs db looked at the certs and verified my internal cert was listed just like firefox. I visited the http server in chrome and it worked perfectly. No changes, which I believe is what you would expect. I then went and tried the same thing on Ubuntu. I know you mentioned that I have to add the certs manually as Ubuntu doesn’t have the same functionality. So I just manually added my ipa.crt to firefox and then got a SEC_ERROR_REVOKED_CERTIFICATE installed chrome on ubuntu machine and manually imported the ipa.crt into chrome, went to the http and chrome worked fine. So now I have no idea where I’m getting this SEC_ERROR_REVOKED_CERTIFICATE So now on a freeipa realm joined host. It seems that CentOS7 - Firefox gets a - SEC_ERROR_REVOKED_CERTIFICATE Chrome - Works out of the box Ubuntu 18.04 - Firefox gets after manually adding cert- SEC_ERROR_REVOKED_CERTIFICATE Chrome - works after manually adding the ipa.ca cert through GUI. Is there some obvious reason why firefox would throw that error message but Chrome wouldn’t? This stuff is making my head spin. > On Thu, Oct 10, 2019 at 2:45 PM Kevin Vasko wrote: > > So you are saying that if the p11-kit-trust module is available it > should be automatically adding the system wide trust store into the > internal Firefox cert store? > > This is the out of my commands. I have the cert store thats create in > my home directory. > > But there is no p11-kit-proxy do I have to add that myself? If so how > do I do that? > > modutil -dbdir sql:/home//.mozilla/firefox/9zd63dro.default-release/ > -list > > Listing of PKCS #11 Modules > --- > 1. NSS Internal PKCS #11 Module > uri: > pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.35 > slots: 2 slots attached >status: loaded > > slot: NSS Internal Cryptographic Services >token: NSS Generic Crypto Services > uri: > pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=;model=NSS%203 > > slot: NSS User Private Key and Certificate Services >token: NSS Certificate DB > uri: > pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=;model=NSS%203 > --- > > I have the p11-kit-trust module. > > $ p11-kit list-modules > p11-kit-trust: p11-kit-trust.so >library-description: PKCS#11 Kit Trust Module >library-manufacturer: PKCS#11 Kit >library-version: 0.23 >token: System Trust >manufacturer: PKCS#11 Kit >model: p11-kit-trust >serial-number: 1 >hardware-version: 0.23 >flags: > write-protected > token-initialized > >> On Thu, Oct 10, 2019 at 11:09 AM Alexander Bokovoy >> wrote: >> On to, 10 loka 2019, Kevin Vasko wrote: >>> Alexander, >>> Unless I'm misunderstanding the information I don't think it will >>> matter though because Firefox and Chrome use their own certificates >>> stores. I found that information after I posted this question. >>> Speaking specifically for firefox (and Chrome looks to be >>> similar)...I'm concluding that why I'm not seeing it work is because >>> of this... >>> "Since
[Freeipa-users] Re: IPA's Certs - country, state, organization ?
On Thu, Oct 10, 2019 at 12:09:48PM +0100, lejeczek via FreeIPA-users wrote: > On 01/10/2019 02:21, Fraser Tweedale wrote: > > On Mon, Sep 30, 2019 at 02:04:15PM +0100, lejeczek via FreeIPA-users wrote: > >> On 09/09/2019 01:07, Fraser Tweedale wrote: > >>> On Fri, Sep 06, 2019 at 12:01:23PM +0100, lejeczek via FreeIPA-users > >>> wrote: > hi guys, > > how to manage those? > > Why are these missing in "standard" IPA installations and how to get > them in? > > many thanks, L. > > >>> Do you mean in the IPA CA certificate, or in the end-entity > >>> certificates? > >>> > >>> If the CA certificate, use the --ca-subject option to specify the > >>> full subject DN you desire. Note that you can only do this upon > >>> installation; there is no way to change the subject of the CA after > >>> installation. > >>> > >>> For end-entity certificates, upon installation you can use the > >>> --subject-base option to specify the desired "subject base DN", to > >>> which the Common Name (CN) will be appended. For existing > >>> installations you can use the 'ipa certprofile-*' commands to import > >>> or modify profile configurations. You will want to tweak the > >>> configuration of the 'subjectNameDefaultImpl' component to put > >>> include the desired attributes. > >>> > >>> Cheers, > >>> Fraser > >> Does the exactness of the 'subject' matter and if so then to whom? > >> > > It does matter. It is *critical* when renewing a CA certificate > > that the subject not change. On first installation it is not so > > critical, but receiving a certificate with different subject DN from > > the CSR usually indicates a mistake or a likelihood of problems down > > the track, when you need to renew it. So we reject it. > > > >> I got a request signed by an external authority but renewal fails with: > >> > >> $ IPA CA certificate with subject 'C=GB,..' was not found in ./file.crt > >> > >> $ The ipa-cacert-manage command failed. > >> > >> and when I glanced at request and the cert I can see that their subjects > >> differ in such way that order (what do you call it?) is reversed: > >> > >> request - Subject: CN=CCN O=University, L=Some, ST=Something, C=GB > >> > >> cert - C=GB, ST=Something, L=Some, O=University, CN=CCN > >> > >> If this is the problem indeed then how to resolve such problem? Else, > >> what is the problem? > >> > > You have to put in the CSR what you expect to get back. If the > > issuer is reversing the Subject DN attributes... you will never get > > back what you want**. So you should work out what is going on in the > > program that is issuing the certificate; work with your CA admins or > > the CA software configuration to resolve this. > > > > ** unless the Subject DN is a palindrome :D > > > > If you give details about the program used to issue the IPA CA > > certificate, we may be able to assist more. > > > > Cheers, > > Fraser > > And it's not possible to skip those checks, for cert's 'subject' ? > It would be possible by editing the code. If Subject DN does not match expectations, but we accept the certificate anyway, things may break. (Or maybe not; I am not sure but this is definitely in the Danger Zone). > p.s. Is it possible to get/extract, from the cert itself, info on which > program generated a cert? > In general it is not possible. In some cases it is possible to infer by presense of particular extensions (e.g. Microsoft Certificate Template extension suggests it was issued by AD-CS) or other characteristics of the certificate. The Issuer DN and OCSP / CRL information may provide clues. But somehow, the certificate is being signed. Someone in your organisation must know what program is being used and should be able to assist, or at least tell you what program it is. Cheers, Fraser ___ 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://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.fedorahosted.org
[Freeipa-users] Re: How to make ipa root certificate available system wide
So you are saying that if the p11-kit-trust module is available it should be automatically adding the system wide trust store into the internal Firefox cert store? This is the out of my commands. I have the cert store thats create in my home directory. But there is no p11-kit-proxy do I have to add that myself? If so how do I do that? modutil -dbdir sql:/home//.mozilla/firefox/9zd63dro.default-release/ -list Listing of PKCS #11 Modules --- 1. NSS Internal PKCS #11 Module uri: pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.35 slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services uri: pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=;model=NSS%203 slot: NSS User Private Key and Certificate Services token: NSS Certificate DB uri: pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=;model=NSS%203 --- I have the p11-kit-trust module. $ p11-kit list-modules p11-kit-trust: p11-kit-trust.so library-description: PKCS#11 Kit Trust Module library-manufacturer: PKCS#11 Kit library-version: 0.23 token: System Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.23 flags: write-protected token-initialized On Thu, Oct 10, 2019 at 11:09 AM Alexander Bokovoy wrote: > > On to, 10 loka 2019, Kevin Vasko wrote: > >Alexander, > > > >Unless I'm misunderstanding the information I don't think it will > >matter though because Firefox and Chrome use their own certificates > >stores. I found that information after I posted this question. > >Speaking specifically for firefox (and Chrome looks to be > >similar)...I'm concluding that why I'm not seeing it work is because > >of this... > > > >"Since Firefox does not use the operating system's certificate store > >by default, these CA certificates must be added in to Firefox using > >one of the following methods. " taken from here > >https://wiki.mozilla.org/CA/AddRootToFirefox > > On RHEL/Fedora we do have some magic: > https://fedoraproject.org/wiki/Changes/NSSLoadP11KitModules > > On my Fedora 30 system I have this for my Firefox profile: > > $ modutil -dbdir sql:/home/abokovoy/.mozilla/firefox/$profile/ -list > > Listing of PKCS #11 Modules > --- > 1. NSS Internal PKCS #11 Module >uri: > pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.46 > slots: 2 slots attached > status: loaded > > slot: NSS Internal Cryptographic Services > token: NSS Generic Crypto Services > uri: > pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=;model=NSS%203 > > slot: NSS User Private Key and Certificate Services > token: NSS Certificate DB > uri: > pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=;model=NSS%203 > > 2. mPollux > library name: /usr/lib64/libcryptoki.so >uri: > pkcs11:library-manufacturer=Fujitsu%20Finland%20Oy;library-description=mPollux%20DigiSign%20Client;library-version=0.1 > slots: There are no slots attached to this module > status: loaded > > 3. p11-kit-proxy > library name: p11-kit-proxy.so >uri: > pkcs11:library-manufacturer=PKCS%2311%20Kit;library-description=PKCS%2311%20Kit%20Proxy%20Module;library-version=1.1 > slots: There are no slots attached to this module > status: loaded > --- > > As you can see, there are three tokens attached. Number 1 is the NSS > internal 'token', that's how NSS database looks like typically. Number 2 > is a crypto token inserted by the Fujitsu Finland Oy which is used for > my governmental ID operations through Firefox. Number three is the proxy > for system-wide crypto tokens in Fedora. > > If I query that token separately, I can see a lot of certificates inside > Firefox NSS database. If I omit -h option, certificates from all tokens > get listed. > > $ certutil -d sql:/home/abokovoy/.mozilla/firefox/$profile/ -h p11-kit-proxy > -L |wc -l > 249 > > > Exactly same story is with Chrome/Chromium, only that they use different > store than Firefox: > > $ modutil -dbdir sql:/home/abokovoy/.pki/nssdb -list > > Listing of PKCS #11 Modules > --- > 1. NSS Internal PKCS #11 Module >uri: >
[Freeipa-users] Re: Where does the "admin" user get its privileges from?
Ah I see now. Adding --raw to the end of the privilege-show CLI command shows me that the admins group is a member of that privilege. Thank you! On Thu, Oct 10, 2019 at 10:36 AM Rob Crittenden wrote: > Russell Jones via FreeIPA-users wrote: > > Hi all, > > > > I am still exploring my default setup, and have noticed that while the > > "admin" user is a part of the admins and trust admins group, neither the > > user nor those groups have any roles defined on them that I can see. > > > > Where is this special username getting its permissions from? > > > > > > Thanks for the help! > > The group is a direct member of a couple of privileges: > > Host Enrollment > Replication Administrators > > Most of the powers are granted by separate ACIs for the admins group, > notably: > > Admin can manage any entry > Admins can write passwords > Admins can write password policies > ... > and a bunch more. > > 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://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.fedorahosted.org > > > > ___ 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://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.fedorahosted.org
[Freeipa-users] Re: How to make ipa root certificate available system wide
On to, 10 loka 2019, Kevin Vasko wrote: Alexander, Unless I'm misunderstanding the information I don't think it will matter though because Firefox and Chrome use their own certificates stores. I found that information after I posted this question. Speaking specifically for firefox (and Chrome looks to be similar)...I'm concluding that why I'm not seeing it work is because of this... "Since Firefox does not use the operating system's certificate store by default, these CA certificates must be added in to Firefox using one of the following methods. " taken from here https://wiki.mozilla.org/CA/AddRootToFirefox On RHEL/Fedora we do have some magic: https://fedoraproject.org/wiki/Changes/NSSLoadP11KitModules On my Fedora 30 system I have this for my Firefox profile: $ modutil -dbdir sql:/home/abokovoy/.mozilla/firefox/$profile/ -list Listing of PKCS #11 Modules --- 1. NSS Internal PKCS #11 Module uri: pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.46 slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services uri: pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=;model=NSS%203 slot: NSS User Private Key and Certificate Services token: NSS Certificate DB uri: pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=;model=NSS%203 2. mPollux library name: /usr/lib64/libcryptoki.so uri: pkcs11:library-manufacturer=Fujitsu%20Finland%20Oy;library-description=mPollux%20DigiSign%20Client;library-version=0.1 slots: There are no slots attached to this module status: loaded 3. p11-kit-proxy library name: p11-kit-proxy.so uri: pkcs11:library-manufacturer=PKCS%2311%20Kit;library-description=PKCS%2311%20Kit%20Proxy%20Module;library-version=1.1 slots: There are no slots attached to this module status: loaded --- As you can see, there are three tokens attached. Number 1 is the NSS internal 'token', that's how NSS database looks like typically. Number 2 is a crypto token inserted by the Fujitsu Finland Oy which is used for my governmental ID operations through Firefox. Number three is the proxy for system-wide crypto tokens in Fedora. If I query that token separately, I can see a lot of certificates inside Firefox NSS database. If I omit -h option, certificates from all tokens get listed. $ certutil -d sql:/home/abokovoy/.mozilla/firefox/$profile/ -h p11-kit-proxy -L |wc -l 249 Exactly same story is with Chrome/Chromium, only that they use different store than Firefox: $ modutil -dbdir sql:/home/abokovoy/.pki/nssdb -list Listing of PKCS #11 Modules --- 1. NSS Internal PKCS #11 Module uri: pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.46 slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services uri: pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=;model=NSS%203 slot: NSS User Private Key and Certificate Services token: NSS Certificate DB uri: pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=;model=NSS%203 2. DigiSign PKCS#11 Module library name: /usr/lib64/libcryptoki.so uri: pkcs11:library-manufacturer=Fujitsu%20Finland%20Oy;library-description=mPollux%20DigiSign%20Client;library-version=0.1 slots: There are no slots attached to this module status: loaded 3. p11-kit-proxy library name: p11-kit-proxy.so uri: pkcs11:library-manufacturer=PKCS%2311%20Kit;library-description=PKCS%2311%20Kit%20Proxy%20Module;library-version=1.1 slots: There are no slots attached to this module status: loaded --- In past, people did manual work to pick up all the certs like https://blog.xelnor.net/firefox-systemcerts/ but it is not really needed anymore if you have p11-kit-proxy on your system. By default p11-kit-proxy has two modules: $ p11-kit list-modules p11-kit-trust: p11-kit-trust.so library-description: PKCS#11 Kit Trust Module library-manufacturer: PKCS#11 Kit library-version: 0.23 token: System Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.23 flags: write-protected token-initialized token: Default Trust
[Freeipa-users] Re: Can't resolve external users on clients, but I can on servers
On Thu, Oct 10, 2019 at 10:21:12AM -, S Toulmonde via FreeIPA-users wrote: > Hi, I setup an IPA realm (under rhel7) with an trust relationship to a > Windows domain. All users in AD have an idoverride to override uid and gid. > Originally, everything was working like expected: servers could resolve IPA > and external (trusted) users, I could create kerberos tickets, log-in via > ssh... Same for IPA clients. > But recently (two weeks ago?), I tried login to an IPA client using an > external user and got denied... Debugging, I saw that id and getent wasn't > returning any external users, but could return IPA users. > Digging a bit more: the ipa servers themselves could resolve both IPA and > external users like before. > I tried fumbling around in the sssd, but to no avail... I bumped the debug > level of the sssd to 9 on the client and the server and this is what I can > observe: > > 0) configure sssd on client to only point to a single IPA server (easier to > debug), on that specific IPA server, only point to a single AD server, clear > cache and logs, restart sssd on server and client > 1) on client, issue 'id myuser' (no domain name, I configured > use_fully_qualified_names to False for the domain) -> user unknown Hi, are you using 'use_fully_qualified_names = False' on the IPA servers as well? If yes, please remove it and try again. bye, Sumit > 2) client logs: > [sssd[be[ipa.domain]]] [dp_get_account_info_handler] (0x0200): Got request > for [0x1][BE_REQ_USER][name=myuser@ipa.domain] > -> it then saw it's an external user: > [sssd[be[ipa.domain]]] [dp_get_account_info_handler] (0x0200): Got request > for [0x1][BE_REQ_USER][name=myuser@ad.domain] > -> so it sent the request to IPA: > [sssd[be[ipa.domain]]] [ipa_s2n_get_acct_info_send] (0x0400): Sending > request_type: [REQ_FULL_WITH_MEMBERS] for trust user [myuser@ad.domain] to > IPA server > Spoiler-alert: it fails with: > [sssd[be[ipa.domain]]] [sysdb_search_user_by_upn] (0x0400): No entry with upn > [myuser@ad.domain] found. > > On the server-side, I receive the request: > [sssd[be[ipa.domain]]] [dp_get_account_info_handler] (0x0200): Got request > for [0x1][BE_REQ_USER][name=myuser@ad.domain] > It resolves the user - fetch all its groups in Windows and seems to process > everything correctly (sid resolve...) but I can't find what's the > return/status of the request. Seems like this: > > (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [sdap_id_op_connect_step] > (0x4000): reusing cached connection > (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] > [get_ldap_conn_from_sdom_pvt] (0x4000): Returning LDAP connection for user > lookup. > (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [sdap_id_op_connect_step] > (0x4000): beginning to connect > (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [fo_resolve_service_send] > (0x0100): Trying to resolve service 'sd_ad.domain.root' > (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [get_server_status] > (0x1000): Status of server 'a08238.ad.domain.root' is 'name resolved' > (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] > [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 > seconds > (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [resolve_srv_send] > (0x0200): The status of SRV lookup is resolved > (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [get_server_status] > (0x1000): Status of server 'a08238.ad.domain.root' is 'name resolved' > (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [be_resolve_server_process] > (0x1000): Saving the first resolved server > (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [be_resolve_server_process] > (0x0200): Found address for server a08238.ad.domain.root: [10.121.129.9] TTL > 1236 > (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] > [sssd_async_socket_init_send] (0x4000): Using file descriptor [29] for the > connection. > (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] > [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for > connecting > (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [sdap_process_result] > (0x2000): Trace: sh[0x558da736b2f0], connected[1], ops[(nil)], > ldap[0x558da7367cb0] > (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [sdap_process_result] > (0x2000): Trace: end of ldap_result list > > Could you please help me on this? Thanks in advance! > ___ > 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://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.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email
[Freeipa-users] Re: Where does the "admin" user get its privileges from?
Russell Jones via FreeIPA-users wrote: > Hi all, > > I am still exploring my default setup, and have noticed that while the > "admin" user is a part of the admins and trust admins group, neither the > user nor those groups have any roles defined on them that I can see. > > Where is this special username getting its permissions from? > > > Thanks for the help! The group is a direct member of a couple of privileges: Host Enrollment Replication Administrators Most of the powers are granted by separate ACIs for the admins group, notably: Admin can manage any entry Admins can write passwords Admins can write password policies ... and a bunch more. 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://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.fedorahosted.org > ___ 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://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.fedorahosted.org
[Freeipa-users] Where does the "admin" user get its privileges from?
Hi all, I am still exploring my default setup, and have noticed that while the "admin" user is a part of the admins and trust admins group, neither the user nor those groups have any roles defined on them that I can see. Where is this special username getting its permissions from? Thanks for the help! ___ 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://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.fedorahosted.org
[Freeipa-users] Re: How to make ipa root certificate available system wide
Alexander, Unless I'm misunderstanding the information I don't think it will matter though because Firefox and Chrome use their own certificates stores. I found that information after I posted this question. Speaking specifically for firefox (and Chrome looks to be similar)...I'm concluding that why I'm not seeing it work is because of this... "Since Firefox does not use the operating system's certificate store by default, these CA certificates must be added in to Firefox using one of the following methods. " taken from here https://wiki.mozilla.org/CA/AddRootToFirefox So I at this point I don't think anything is wrong with ipa-install-client and it is performing correctly at this point adding it to the cert store. Given that the exception that you mentioned, that there is a difference in ipa-install-client adding it to the the NSS database on RHEL/Fedora/CentOS and not on the Ubuntu/Debian variants. However, I still don't think that will matter since Firefox/Chrome aren't reading either the NSS database or the crt bundle from what I understand. I'm going to keep digging to see if I find a solution for getting FF/Chrome to look at my certs and will post back on what I find. -Kevin On Thu, Oct 10, 2019 at 9:17 AM Alexander Bokovoy wrote: > > On to, 10 loka 2019, Kevin Vasko via FreeIPA-users wrote: > >I actually manually checked the system wide crt files on each > >distribution I'm using, Ubuntu, CentOS and RHEL6/7. In all cases my > >/etc/ipa/ca.crt did appear to be in the each of their respective *.crt > >files. That indicates to me that there isn't any problem with the > >ipa-install-client on any of the distributions like I originally > >thought. Rob it does look like Ubuntu is adding it to the > >/etc/ssl/certs/ca-certificates.crt with the ipa-install-client as I > >didn't do it manually on any of my systems, so it does appear they are > >doing it somehow. > > > >These are the locations I checked. > > > >"/etc/ssl/certs/ca-certificates.crt",// > >Debian/Ubuntu/Gentoo etc. > >"/etc/pki/tls/certs/ca-bundle.crt", // Fedora/RHEL 6 > >"/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7 > > > >What appears to be the problem is (unless I'm mistaken) Firefox nor > >Chrome are using the system wide cert locations apparently and only > >using their own cert store. At least according to this article: > >https://thomas-leister.de/en/how-to-import-ca-root-certificate/ > On RHEL/Fedora/CentOS we import system wide cert store automatically to > NSS databases through p11-kit. > > On Ubuntu/Debian/Gentoo you need to do that manually. > > > > >It kind of is backed up by this article on the Mozilla page. > >https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox > > > >So based off of this information I'm going to have to manually add the > >root certificates to each Chrome and Firefox cert store on the client > >machines, which is a bummer. > > > >Sorry for the noise. > > > >On Thu, Oct 10, 2019 at 8:40 AM Rob Crittenden wrote: > >> > >> Kevin Vasko via FreeIPA-users wrote: > >> > Kees Bakker, > >> > > >> > If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu > >> > 18.04 and based on Rob's comment it might not be done if I'm > >> > understanding him correctly. > >> > >> Assuming I'm reading the code right it is not being executed on > >> Debian/Ubuntu. At least not in the source. It's possible it is patched > >> into the package in the distribution. > >> > >> rob > >> > >> > > >> > -Kevin > >> > > >> > On Thu, Oct 10, 2019 at 8:19 AM Kees Bakker via FreeIPA-users > >> > wrote: > >> >> > >> >> On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote > >> >>> > >> >>> Kevin Vasko via FreeIPA-users wrote: > >> How would I validate that certs are getting added properly on a > >> CentOS machine system wide store? > >> > >> I’m going to test it today to find out if this is a problem unique > >> to Ubuntu/CentOS. > >> >>> On Fedora the chain is put into > >> >>> /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is > >> >>> executed. > >> >>> > >> >>> There is no Debian/Ubuntu equivalent in the upstream source (it's > >> >>> possible it is done in packaging). You could try something like: > >> >>> > >> >>> cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt > >> >>> update-ca-certificates > >> >> This is already done by ipa-client-install > >> >> ___ > >> >> 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://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.fedorahosted.org > >> >
[Freeipa-users] Re: How to make ipa root certificate available system wide
On to, 10 loka 2019, Kevin Vasko via FreeIPA-users wrote: I actually manually checked the system wide crt files on each distribution I'm using, Ubuntu, CentOS and RHEL6/7. In all cases my /etc/ipa/ca.crt did appear to be in the each of their respective *.crt files. That indicates to me that there isn't any problem with the ipa-install-client on any of the distributions like I originally thought. Rob it does look like Ubuntu is adding it to the /etc/ssl/certs/ca-certificates.crt with the ipa-install-client as I didn't do it manually on any of my systems, so it does appear they are doing it somehow. These are the locations I checked. "/etc/ssl/certs/ca-certificates.crt",// Debian/Ubuntu/Gentoo etc. "/etc/pki/tls/certs/ca-bundle.crt", // Fedora/RHEL 6 "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7 What appears to be the problem is (unless I'm mistaken) Firefox nor Chrome are using the system wide cert locations apparently and only using their own cert store. At least according to this article: https://thomas-leister.de/en/how-to-import-ca-root-certificate/ On RHEL/Fedora/CentOS we import system wide cert store automatically to NSS databases through p11-kit. On Ubuntu/Debian/Gentoo you need to do that manually. It kind of is backed up by this article on the Mozilla page. https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox So based off of this information I'm going to have to manually add the root certificates to each Chrome and Firefox cert store on the client machines, which is a bummer. Sorry for the noise. On Thu, Oct 10, 2019 at 8:40 AM Rob Crittenden wrote: Kevin Vasko via FreeIPA-users wrote: > Kees Bakker, > > If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu > 18.04 and based on Rob's comment it might not be done if I'm > understanding him correctly. Assuming I'm reading the code right it is not being executed on Debian/Ubuntu. At least not in the source. It's possible it is patched into the package in the distribution. rob > > -Kevin > > On Thu, Oct 10, 2019 at 8:19 AM Kees Bakker via FreeIPA-users > wrote: >> >> On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote >>> >>> Kevin Vasko via FreeIPA-users wrote: How would I validate that certs are getting added properly on a CentOS machine system wide store? I’m going to test it today to find out if this is a problem unique to Ubuntu/CentOS. >>> On Fedora the chain is put into >>> /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is executed. >>> >>> There is no Debian/Ubuntu equivalent in the upstream source (it's >>> possible it is done in packaging). You could try something like: >>> >>> cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt >>> update-ca-certificates >> This is already done by ipa-client-install >> ___ >> 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://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.fedorahosted.org > ___ > 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://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.fedorahosted.org > ___ 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://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.fedorahosted.org -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ 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://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.fedorahosted.org
[Freeipa-users] Re: How to make ipa root certificate available system wide
I actually manually checked the system wide crt files on each distribution I'm using, Ubuntu, CentOS and RHEL6/7. In all cases my /etc/ipa/ca.crt did appear to be in the each of their respective *.crt files. That indicates to me that there isn't any problem with the ipa-install-client on any of the distributions like I originally thought. Rob it does look like Ubuntu is adding it to the /etc/ssl/certs/ca-certificates.crt with the ipa-install-client as I didn't do it manually on any of my systems, so it does appear they are doing it somehow. These are the locations I checked. "/etc/ssl/certs/ca-certificates.crt",// Debian/Ubuntu/Gentoo etc. "/etc/pki/tls/certs/ca-bundle.crt", // Fedora/RHEL 6 "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7 What appears to be the problem is (unless I'm mistaken) Firefox nor Chrome are using the system wide cert locations apparently and only using their own cert store. At least according to this article: https://thomas-leister.de/en/how-to-import-ca-root-certificate/ It kind of is backed up by this article on the Mozilla page. https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox So based off of this information I'm going to have to manually add the root certificates to each Chrome and Firefox cert store on the client machines, which is a bummer. Sorry for the noise. On Thu, Oct 10, 2019 at 8:40 AM Rob Crittenden wrote: > > Kevin Vasko via FreeIPA-users wrote: > > Kees Bakker, > > > > If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu > > 18.04 and based on Rob's comment it might not be done if I'm > > understanding him correctly. > > Assuming I'm reading the code right it is not being executed on > Debian/Ubuntu. At least not in the source. It's possible it is patched > into the package in the distribution. > > rob > > > > > -Kevin > > > > On Thu, Oct 10, 2019 at 8:19 AM Kees Bakker via FreeIPA-users > > wrote: > >> > >> On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote > >>> > >>> Kevin Vasko via FreeIPA-users wrote: > How would I validate that certs are getting added properly on a CentOS > machine system wide store? > > I’m going to test it today to find out if this is a problem unique to > Ubuntu/CentOS. > >>> On Fedora the chain is put into > >>> /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is > >>> executed. > >>> > >>> There is no Debian/Ubuntu equivalent in the upstream source (it's > >>> possible it is done in packaging). You could try something like: > >>> > >>> cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt > >>> update-ca-certificates > >> This is already done by ipa-client-install > >> ___ > >> 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://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.fedorahosted.org > > ___ > > 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://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.fedorahosted.org > > > ___ 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://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.fedorahosted.org
[Freeipa-users] Re: DNS - classless/subnet reverse zones ?
Hello, IPA utilizes BIND in the backend, so have you tried to create the subzone with the way BIND expects? 0-31.0.168.192.in-addr.arpa. This one is for /27 for instance. Modify it for your needs and see if it works. Never tried this myself but I worth checking. Sent from my iPhone On 10 Oct 2019, at 07:13, lejeczek via FreeIPA-users wrote: hi guys, when I try to add a zone: $ ipa dnszone-add --name-from-ip=10.5.4.128/25 Zone name [4.5.10.in-addr.arpa.]: I see the above. Is what IPA does there correct? Or... what is the recipe for a classless/subnet reverse zone creation? many thanks, L. ___ 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://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.fedorahosted.org ___ 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://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.fedorahosted.org
[Freeipa-users] Re: How to make ipa root certificate available system wide
Kevin Vasko via FreeIPA-users wrote: > Kees Bakker, > > If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu > 18.04 and based on Rob's comment it might not be done if I'm > understanding him correctly. Assuming I'm reading the code right it is not being executed on Debian/Ubuntu. At least not in the source. It's possible it is patched into the package in the distribution. rob > > -Kevin > > On Thu, Oct 10, 2019 at 8:19 AM Kees Bakker via FreeIPA-users > wrote: >> >> On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote >>> >>> Kevin Vasko via FreeIPA-users wrote: How would I validate that certs are getting added properly on a CentOS machine system wide store? I’m going to test it today to find out if this is a problem unique to Ubuntu/CentOS. >>> On Fedora the chain is put into >>> /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is executed. >>> >>> There is no Debian/Ubuntu equivalent in the upstream source (it's >>> possible it is done in packaging). You could try something like: >>> >>> cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt >>> update-ca-certificates >> This is already done by ipa-client-install >> ___ >> 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://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.fedorahosted.org > ___ > 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://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.fedorahosted.org > ___ 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://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.fedorahosted.org
[Freeipa-users] Re: How to make ipa root certificate available system wide
Kees Bakker, If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu 18.04 and based on Rob's comment it might not be done if I'm understanding him correctly. -Kevin On Thu, Oct 10, 2019 at 8:19 AM Kees Bakker via FreeIPA-users wrote: > > On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote > > > > Kevin Vasko via FreeIPA-users wrote: > >> How would I validate that certs are getting added properly on a CentOS > >> machine system wide store? > >> > >> I’m going to test it today to find out if this is a problem unique to > >> Ubuntu/CentOS. > > On Fedora the chain is put into > > /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is executed. > > > > There is no Debian/Ubuntu equivalent in the upstream source (it's > > possible it is done in packaging). You could try something like: > > > > cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt > > update-ca-certificates > This is already done by ipa-client-install > ___ > 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://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.fedorahosted.org ___ 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://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.fedorahosted.org
[Freeipa-users] Re: How to make ipa root certificate available system wide
On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote Kevin Vasko via FreeIPA-users wrote: How would I validate that certs are getting added properly on a CentOS machine system wide store? I’m going to test it today to find out if this is a problem unique to Ubuntu/CentOS. On Fedora the chain is put into /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is executed. There is no Debian/Ubuntu equivalent in the upstream source (it's possible it is done in packaging). You could try something like: cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt update-ca-certificates This is already done by ipa-client-install ___ 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://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.fedorahosted.org
[Freeipa-users] Re: How to make ipa root certificate available system wide
Kevin Vasko via FreeIPA-users wrote: > How would I validate that certs are getting added properly on a CentOS > machine system wide store? > > I’m going to test it today to find out if this is a problem unique to > Ubuntu/CentOS. On Fedora the chain is put into /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is executed. There is no Debian/Ubuntu equivalent in the upstream source (it's possible it is done in packaging). You could try something like: cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt update-ca-certificates rob > > -Kevin > >> On Oct 9, 2019, at 10:44 PM, Fraser Tweedale wrote: >> >> On Wed, Oct 09, 2019 at 08:58:14PM -0500, Kevin Vasko wrote: >>> Seems to happen on both Ubuntu 16.04 and 18.04. >>> >>> $ lsb_release -a >>> No LSB modules are available. >>> Distributor ID: Ubuntu >>> Description:Ubuntu 16.04.6 LTS >>> Release:16.04 >>> Codename: xenial >>> >>> $ firefox --version >>> Mozilla Firefox 67.0.4 >>> >>> freeipa-client/xenial,now 4.3.1-0ubuntu1 amd64 [installed] >>> freeipa-common/xenial,xenial,now 4.3.1-0ubuntu1 all [installed,automatic] >>> firefox/now 67.0.4+build1-0ubuntu0.16.04.1 amd64 >>> >>> >>> >>> Ubuntu 18.04 machine: >>> >>> $ lsb_release -a >>> No LSB modules are available. >>> Distributor ID: Ubuntu >>> Description:Ubuntu 18.04.3 LTS >>> Release:18.04 >>> Codename: bionic >>> >>> freeipa-client/bionic,now 4.7.0~pre1+git20180411-2ubuntu2 amd64 [installed] >>> freeipa-common/bionic,bionic,now 4.7.0~pre1+git20180411-2ubuntu2 all >>> [installed,automatic] >>> firefox/bionic-updates,bionic-security,now >>> 69.0.2+build1-0ubuntu0.18.04.1 amd64 [installed] >>> >>> Where is the system trust store located? I was going to validate that >>> the freeipa ca.crt is added to the system trust store. If its not >>> there how do you add the ca.crt to the system trust store? >>> >>> Should the ipa-install-client command add the system wide trust store? >>> >> Thanks for the details. I do not know about system trust on Ubuntu. >> It could be that ipa-client on Ubuntu does add the IPA CA to system >> trust, but the Firefox/Chrome packages ignore the system trust >> store. >> >> Hopefully someone more familiar with Ubuntu can clarify. >> >> Cheers, >> Fraser >> >>> I'll try this on CentOS tomorrow to see if its just an Ubuntu issue. >>> On Wed, Oct 9, 2019 at 8:25 PM Fraser Tweedale wrote: On Wed, Oct 09, 2019 at 06:28:11PM -0500, Kevin Vasko via FreeIPA-users wrote: > Hello, > > I’m wanting to make our https servers use a trusted certificate within > our LAN only. So for example if I have websrv1.ny.example.com when a user > uses a machine that’s enrolled into our realm and they visit > https://websrv1.ny.example.com they shouldn’t be prompted to accept the > self signed certificate. > > I think I’m pretty close but I’m missing a small part. > > The ipa server is all setup and working. Hosts are enrolled to ipa and > have the /etc/ipa/ca.crt. > > I have created a service for the http server in IPA. I have obtained a > .key file and .crt file for my web server. Those keys for the web server > are in the appropriate location and the web server is pointing at the > certs correctly. > > On my clients when I go to the web servers URl I am no longer getting a > “self signed cert” error message in the browser. > > That message has now changed to “unverified certificate authority”. Which > basically indicates to me that the browser doesn’t know if this > certificate authority should/can be trusted. > > If i go in the browser (firefox or chrome) in the certificate authority > section and import the /etc/ipa/ca.crt i get no errors in the browser > about it being unverified. > > So my question is, what am I missing to make the /etc/ipa/ca.crt file > globally available for browsers to pick up the certificate automatically? > > when we enroll a host we simply do > > freeipa-install-client —domain=example.com —realm=EXAMPLE.COM —mkhomedir > > Accept the defaults, put in the password to enroll and that’s it. Is > there something I’m missing? > > -Kevin > Looks like the browser is not using the system trust store. Please provide full details of operating system and package versions for both freeipa and browser packages. Cheers, Fraser > ___ > 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://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.fedorahosted.org >
[Freeipa-users] Re: How to make ipa root certificate available system wide
How would I validate that certs are getting added properly on a CentOS machine system wide store? I’m going to test it today to find out if this is a problem unique to Ubuntu/CentOS. -Kevin > On Oct 9, 2019, at 10:44 PM, Fraser Tweedale wrote: > > On Wed, Oct 09, 2019 at 08:58:14PM -0500, Kevin Vasko wrote: >> Seems to happen on both Ubuntu 16.04 and 18.04. >> >> $ lsb_release -a >> No LSB modules are available. >> Distributor ID: Ubuntu >> Description:Ubuntu 16.04.6 LTS >> Release:16.04 >> Codename: xenial >> >> $ firefox --version >> Mozilla Firefox 67.0.4 >> >> freeipa-client/xenial,now 4.3.1-0ubuntu1 amd64 [installed] >> freeipa-common/xenial,xenial,now 4.3.1-0ubuntu1 all [installed,automatic] >> firefox/now 67.0.4+build1-0ubuntu0.16.04.1 amd64 >> >> >> >> Ubuntu 18.04 machine: >> >> $ lsb_release -a >> No LSB modules are available. >> Distributor ID: Ubuntu >> Description:Ubuntu 18.04.3 LTS >> Release:18.04 >> Codename: bionic >> >> freeipa-client/bionic,now 4.7.0~pre1+git20180411-2ubuntu2 amd64 [installed] >> freeipa-common/bionic,bionic,now 4.7.0~pre1+git20180411-2ubuntu2 all >> [installed,automatic] >> firefox/bionic-updates,bionic-security,now >> 69.0.2+build1-0ubuntu0.18.04.1 amd64 [installed] >> >> Where is the system trust store located? I was going to validate that >> the freeipa ca.crt is added to the system trust store. If its not >> there how do you add the ca.crt to the system trust store? >> >> Should the ipa-install-client command add the system wide trust store? >> > Thanks for the details. I do not know about system trust on Ubuntu. > It could be that ipa-client on Ubuntu does add the IPA CA to system > trust, but the Firefox/Chrome packages ignore the system trust > store. > > Hopefully someone more familiar with Ubuntu can clarify. > > Cheers, > Fraser > >> I'll try this on CentOS tomorrow to see if its just an Ubuntu issue. >> >>> On Wed, Oct 9, 2019 at 8:25 PM Fraser Tweedale wrote: >>> >>> On Wed, Oct 09, 2019 at 06:28:11PM -0500, Kevin Vasko via FreeIPA-users >>> wrote: Hello, I’m wanting to make our https servers use a trusted certificate within our LAN only. So for example if I have websrv1.ny.example.com when a user uses a machine that’s enrolled into our realm and they visit https://websrv1.ny.example.com they shouldn’t be prompted to accept the self signed certificate. I think I’m pretty close but I’m missing a small part. The ipa server is all setup and working. Hosts are enrolled to ipa and have the /etc/ipa/ca.crt. I have created a service for the http server in IPA. I have obtained a .key file and .crt file for my web server. Those keys for the web server are in the appropriate location and the web server is pointing at the certs correctly. On my clients when I go to the web servers URl I am no longer getting a “self signed cert” error message in the browser. That message has now changed to “unverified certificate authority”. Which basically indicates to me that the browser doesn’t know if this certificate authority should/can be trusted. If i go in the browser (firefox or chrome) in the certificate authority section and import the /etc/ipa/ca.crt i get no errors in the browser about it being unverified. So my question is, what am I missing to make the /etc/ipa/ca.crt file globally available for browsers to pick up the certificate automatically? when we enroll a host we simply do freeipa-install-client —domain=example.com —realm=EXAMPLE.COM —mkhomedir Accept the defaults, put in the password to enroll and that’s it. Is there something I’m missing? -Kevin >>> Looks like the browser is not using the system trust store. Please >>> provide full details of operating system and package versions for >>> both freeipa and browser packages. >>> >>> Cheers, >>> Fraser ___ 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://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.fedorahosted.org
[Freeipa-users] Re: IPA's Certs - country, state, organization ?
On 01/10/2019 02:21, Fraser Tweedale wrote: > On Mon, Sep 30, 2019 at 02:04:15PM +0100, lejeczek via FreeIPA-users wrote: >> On 09/09/2019 01:07, Fraser Tweedale wrote: >>> On Fri, Sep 06, 2019 at 12:01:23PM +0100, lejeczek via FreeIPA-users wrote: hi guys, how to manage those? Why are these missing in "standard" IPA installations and how to get them in? many thanks, L. >>> Do you mean in the IPA CA certificate, or in the end-entity >>> certificates? >>> >>> If the CA certificate, use the --ca-subject option to specify the >>> full subject DN you desire. Note that you can only do this upon >>> installation; there is no way to change the subject of the CA after >>> installation. >>> >>> For end-entity certificates, upon installation you can use the >>> --subject-base option to specify the desired "subject base DN", to >>> which the Common Name (CN) will be appended. For existing >>> installations you can use the 'ipa certprofile-*' commands to import >>> or modify profile configurations. You will want to tweak the >>> configuration of the 'subjectNameDefaultImpl' component to put >>> include the desired attributes. >>> >>> Cheers, >>> Fraser >> Does the exactness of the 'subject' matter and if so then to whom? >> > It does matter. It is *critical* when renewing a CA certificate > that the subject not change. On first installation it is not so > critical, but receiving a certificate with different subject DN from > the CSR usually indicates a mistake or a likelihood of problems down > the track, when you need to renew it. So we reject it. > >> I got a request signed by an external authority but renewal fails with: >> >> $ IPA CA certificate with subject 'C=GB,..' was not found in ./file.crt >> >> $ The ipa-cacert-manage command failed. >> >> and when I glanced at request and the cert I can see that their subjects >> differ in such way that order (what do you call it?) is reversed: >> >> request - Subject: CN=CCN O=University, L=Some, ST=Something, C=GB >> >> cert - C=GB, ST=Something, L=Some, O=University, CN=CCN >> >> If this is the problem indeed then how to resolve such problem? Else, >> what is the problem? >> > You have to put in the CSR what you expect to get back. If the > issuer is reversing the Subject DN attributes... you will never get > back what you want**. So you should work out what is going on in the > program that is issuing the certificate; work with your CA admins or > the CA software configuration to resolve this. > > ** unless the Subject DN is a palindrome :D > > If you give details about the program used to issue the IPA CA > certificate, we may be able to assist more. > > Cheers, > Fraser And it's not possible to skip those checks, for cert's 'subject' ? p.s. Is it possible to get/extract, from the cert itself, info on which program generated a cert? many thanks, L. pEpkey.asc Description: application/pgp-keys ___ 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://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.fedorahosted.org
[Freeipa-users] How to change the timeout of 60 seconds on the login with AD users
Hi, Thanks for the tip. I try to login executing: ssh -l USER@AD.DOMAIN HOSTNAME Unfortunately I have tested with: LOGIN_TIMEOUT 90 And also changing on sshd_conf: LogLevel DEBUG3 ClientAliveInterval 600 LoginGraceTime 600 ClientAliveCountMax 3 And on sssd.conf: ldap_enumeration_search_timeout = 600 But still have a timeout when login process is longer than 60 seconds. I have enabled nscd and then authentication takes less than 60 s and then works, but it will be great if I can know how that timeout can be configured. Thanks & 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://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.fedorahosted.org
[Freeipa-users] sebastien.toulmo...@proximus.com
sebastien.toulmo...@proximus.com This e-mail cannot be used for other purposes than Proximus business use. See more on https://www.proximus.be/maildisclaimer ___ 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://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.fedorahosted.org
[Freeipa-users] Can't resolve external users on clients, but I can on servers
Hi, I setup an IPA realm (under rhel7) with an trust relationship to a Windows domain. All users in AD have an idoverride to override uid and gid. Originally, everything was working like expected: servers could resolve IPA and external (trusted) users, I could create kerberos tickets, log-in via ssh... Same for IPA clients. But recently (two weeks ago?), I tried login to an IPA client using an external user and got denied... Debugging, I saw that id and getent wasn't returning any external users, but could return IPA users. Digging a bit more: the ipa servers themselves could resolve both IPA and external users like before. I tried fumbling around in the sssd, but to no avail... I bumped the debug level of the sssd to 9 on the client and the server and this is what I can observe: 0) configure sssd on client to only point to a single IPA server (easier to debug), on that specific IPA server, only point to a single AD server, clear cache and logs, restart sssd on server and client 1) on client, issue 'id myuser' (no domain name, I configured use_fully_qualified_names to False for the domain) -> user unknown 2) client logs: [sssd[be[ipa.domain]]] [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][name=myuser@ipa.domain] -> it then saw it's an external user: [sssd[be[ipa.domain]]] [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][name=myuser@ad.domain] -> so it sent the request to IPA: [sssd[be[ipa.domain]]] [ipa_s2n_get_acct_info_send] (0x0400): Sending request_type: [REQ_FULL_WITH_MEMBERS] for trust user [myuser@ad.domain] to IPA server Spoiler-alert: it fails with: [sssd[be[ipa.domain]]] [sysdb_search_user_by_upn] (0x0400): No entry with upn [myuser@ad.domain] found. On the server-side, I receive the request: [sssd[be[ipa.domain]]] [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][name=myuser@ad.domain] It resolves the user - fetch all its groups in Windows and seems to process everything correctly (sid resolve...) but I can't find what's the return/status of the request. Seems like this: (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [get_ldap_conn_from_sdom_pvt] (0x4000): Returning LDAP connection for user lookup. (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'sd_ad.domain.root' (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [get_server_status] (0x1000): Status of server 'a08238.ad.domain.root' is 'name resolved' (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [get_server_status] (0x1000): Status of server 'a08238.ad.domain.root' is 'name resolved' (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [be_resolve_server_process] (0x0200): Found address for server a08238.ad.domain.root: [10.121.129.9] TTL 1236 (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [sssd_async_socket_init_send] (0x4000): Using file descriptor [29] for the connection. (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for connecting (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [sdap_process_result] (0x2000): Trace: sh[0x558da736b2f0], connected[1], ops[(nil)], ldap[0x558da7367cb0] (Thu Oct 10 11:27:32 2019) [sssd[be[ipa.domain]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list Could you please help me on this? Thanks in advance! ___ 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://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.fedorahosted.org
[Freeipa-users] DNS - classless/subnet reverse zones ?
hi guys, when I try to add a zone: $ ipa dnszone-add --name-from-ip=10.5.4.128/25 Zone name [4.5.10.in-addr.arpa.]: I see the above. Is what IPA does there correct? Or... what is the recipe for a classless/subnet reverse zone creation? many thanks, L. pEpkey.asc Description: application/pgp-keys ___ 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://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.fedorahosted.org
