[Freeipa-users] Re: Ongoing CA access issues
Bret Wortman via FreeIPA-users wrote: > Still trying to get my CA working. > > In the IPA web UI, under Authentication -> Certificates, I can see a > number of certs listed as VALID, EXPIRED, or REVOKED_EXPIRED. But I can > also see many more that are greyed out, and whose "Issuing CA" and > "Status" columns are empty. Does this begin to point toward a solvable > problem? I think these are probably red herrings. As I mentioned cert-find uses a different API than the rest of the CA commands. It is interesting that the CA is at least partially up I guess. The authenticated requests IPA is making to dogtag are returning 503 Service Unavailable which suggests that the CA isn't fully running, or there is some issue with the AJP connector. I'm frankly surprised that the REST API works at all as I though the CA was an all-or-nothing affair. /var/log/pki/pki-tomcat/ca/debug may hold clues on what is going on. You might also try creating /etc/ipa/server.conf containing: [global] debug=True This will increase the server-level debugging but I doubt you'll get much useful out of it in this case given it is the CA that is the problem, but who knows. rob > > > On 05/18/2017 08:58 AM, Bret Wortman wrote: >> >> Oops, the slapd messages are arriving every 60s, not 5m. >> >> >> On 05/18/2017 08:56 AM, Bret Wortman wrote: >>> >>> httpd_error seems to give the most information. When i try to use ipa >>> cert-show: >>> >>> ipa: INFO: [jsonserver_kerb] ad...@damascusgrp.com: ping(): SUCCESS >>> (111)Connection refused: AH00957: AJP: attempt to connect to >>> 127.0.0.1:8009 (localhost) failed >>> AH00959: ap_proxy_connect_backend disabling worker for (locahost) for 60s >>> [client 192.168.208.54:52714] AH00896: failed to make connection to >>> backend: localhost >>> ipa: ERROR: ra.get_certificate(): Unable to communicate with CMS (503) >>> ipa: INFO: [jsonserver_kerb] ad...@damascusgrp.com: >>> cert_show/1(u'895', version=u'2.213'): CertificateOperationError >>> >>> /var/log/pki/pki-tomcat/ca/debug just loops through the same set of >>> messages every 5 minutes or so but doesn't seem to error. >>> >>> /var/log/pki/localhost_access_log.2017-05-18.txt is basically empty >>> except for a single entry (for a POST to /ca/admin/ca/getStatus) >>> >>> Nothing shows up in dirsrv/slapd-DAMASCUSGRP-COM/errors or access >>> when I issue the request, but periodic messages do appear about every >>> 5 minutes or so. >>> >>> >>> On 05/18/2017 08:43 AM, Bret Wortman wrote: On 04/26/2017 06:02 PM, Rob Crittenden wrote: > Bret Wortman wrote: >> So I can see my certs using cert-find, but can't get details using >> cert-show or add new ones using cert-request. >> >> # ipa cert-find >> : >> -- >> Number of entries returned 385 >> -- >> # ipa cert-show 895 >> ipa: ERROR: Certificate operation cannot be completed: Unable to >> communicate with CMS (503) >> # ipa cert-show 1 (which does not exist) >> ipa: ERROR: Certificate operation cannot be completed: Unable to >> communicate with CMS (503) >> # ipa cert-status 895 >> ipa: ERROR: Certificate operation cannot be completed: Unable to >> communicate with CMS (503) >> # >> >> Is this an IPV6 thing? Because ipactl shows everything green and >> certmonger is running. > Doubtful. > > cert-find and cert-show use different APIs in dogtag. cert-find > uses the > newer RESTful API and cert-show uses the older XML-based API (and is > authenticated). I'm guessing that is where the issue lies. > > What I'd recommend doing is noting the time, restarting the CA, and > then > plow through the debug log looking for failures. It could be that > the CA > is only partially up (and I'd check your CA subsystem certs as well). Which debug log, specifically, do you think will help? I'm also not sure what you mean by, "check your CA subsystem certs." We still have pending CSRs that we can't grant until I get this working again. > rob > >> Bret >> >> >> On 04/26/2017 09:03 AM, Bret Wortman wrote: >>> Digging still deeper: >>> >>> # ipa cert-request f.f >>> --principal=HTTP/`hostname`@DAMASCUSGRP.COM >>> ipa: ERROR: Certificate operation cannot be completed: >>> Unable to >>> communicate with CMS (503) >>> >>> Looks like this is an HTTP error; so is it possible that my IPA >>> thinks >>> it has a CA but there's no CMS available? >>> >>> >>> On 04/26/2017 08:41 AM, Bret Wortman wrote: Using the firefox debugger, I get these errors when trying to pop up the New Certificate dialog: Empty string passed to getElementById(). (5) jquery.js:4:1060 TypeError: u
[Freeipa-users] Re: ipa command breaks by setting "NSSVerifyClient require"
On 05/29/2017 07:15 PM, Fraser Tweedale via FreeIPA-users wrote: On Mon, May 29, 2017 at 06:26:31PM +0530, Ivars Strazdiņš wrote: I am not saying “instead of”. We are using standard authetication provided by FreeIPA, but I want to protect Web UI interface from unwanted attention as it is, unfortunately, exposed to entire internet. I’d be much happier if Apache could reject (or redirect) any client which is not presenting required certificate even before any authentication attempt is started. That is not to say that the whole server is exposed, but 443 port is. Thanks for explaining. Maybe I'm missing something in this thread, but couldn't the OP simply put a reverse proxy in front of the Internet-exposed port? -- Ian Pilcher arequip...@gmail.com "I grew up before Mark Zuckerberg invented friendship" ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Establish Kerberos trust to non AD server running MIT Kerberos
Team, What will be correct procedure to establish kerberos trust to non Active Directory server running MIT Kerberos. Regards, Andrey ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Stale/ghost RUVs that cannot be removed
Thanks German, I can confirm this worked and the ghost replicas were removed.
Much appreciated for the assistance.
Thanks,
Goran
> On May 29, 2017, at 11:40 AM, German Parente wrote:
>
> Hi,
>
> you could try this operation manually but please, be sure that all the
> replicas are up and running:
>
> ldapmodify -a -D "cn=directory manager" -W << EOF
> dn: cn=clean 3, cn=cleanallruv, cn=tasks, cn=config
> objectclass: extensibleObject
> replica-base-dn:
> replica-id: 3
> replica-force-cleaning: yes
> cn: clean 3
> EOF
>
> should be something like dc=ecobee,dc=com ?
>
> that's the way to add a cleanallruv task manually. You should repeat this
> with replica id "4"
>
> regards,
>
> German.
>
>
>
> On Mon, May 29, 2017 at 5:07 PM, Goran Marik via FreeIPA-users
> wrote:
> Hi,
>
> We are troubleshooting an sync issue that started after a freeipa upgrade
> (yum update) to the latest Centos 7.3 mid-April. One of the problems that
> happen is that we see stale RUVs that cannot be deleted. Here is the output
> of list-ruv and clean-run:
>
> “””
> ipa-replica-manage list-ruv
> Directory Manager password:
> unable to decode: {replica 3} 57020ed900060003 57020ed900060003
> unable to decode: {replica 4} 5702fe5b00050004 5702fe5b00050004
> Replica Update Vectors:
> inf01.prod.ecobee.com:389: 6
> inf02.dev.ecobee.com:389: 8
> inf01.dev.ecobee.com:389: 7
> inf02.prod.ecobee.com:389: 5
> Certificate Server Replica Update Vectors:
> inf02.prod.ecobee.com:389: 1095
> inf01.dev.ecobee.com:389: 1295
> inf02.dev.ecobee.com:389: 1190
> inf01.prod.ecobee.com:389: 1195
> “””
>
> “””
> ipa-replica-manage clean-ruv 3
> Directory Manager password:
>
> unable to decode: {replica 3} 57020ed900060003 57020ed900060003
> unable to decode: {replica 4} 5702fe5b00050004 5702fe5b00050004
> Replica ID 3 not found
> “””
>
> The ipa_consistecy_script reports this issue as two ghost replicas ("Ghost
> Replicas 2222FAIL”). The
> clean-dangling-ruv reports that that are no dangling RUVs.
>
> Our version is VERSION: 4.4.0, API_VERSION: 2.213, on Centos 7.3.1611
>
> In the list archives, I found one case from 2015 that sound similar and was
> possible fixed, but not confirmed, with a script cleanallruv.pl, but I
> haven’t been able to find more info on that. Any further help would be
> appreciated.
>
>
> Thanks,
> Goran
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Replica cannot be reinitialized after upgrade
Thanks Ludwig. I’ve open the issue #6990 with the logs and files requested. In the past few days I’ve managed to remove the stale replicas running the cleanruv task via ldif, and tried to resync again few times, but the error logs still keep happening. You mentioned that there is the nsds5ReplicaIgnoreMissingChange option, but can you specify the steps on how to set/enable that option? Thanks, Goran > On May 19, 2017, at 3:49 AM, Ludwig Krispenz wrote: > > > On 05/18/2017 10:13 PM, Goran Marik wrote: >> Thanks Ludwig for the suggestion and thanks to Maciej for the confirmation >> from his end. This issue is happening for us for several weeks, so I don’t >> think this is a transient problem. >> >> What is the best way to sanitize the logs without removing useful info >> before sending them your way? Will the files mentioned on >> "https://www.freeipa.org/page/Files_to_be_attached_to_bug_report -> >> Directory server failed" be sufficient? > yes, but we need soem additional info on the replication config and state, > you could add /etc/dirsrv/slapd-*/dse.ldif > and the result of these query > > ldapsearch -o ldif-wrap=no -D "cn=directory manager" ... > -b "cn=config" "objectclass=nsds5replica" \* nsds50ruv > > But looking again at the csn reorted missing it is from June, 2016. So I > wonder if this is for an stale/removed replica and cleaning the ruvs would > help >> >> I’ve also run the ipa_consistency_check script, and the output shows that >> something is indeed wrong with the sync: >> “”” >> FreeIPA servers:inf01inf01inf02inf02STATE >> = >> Active Users15 15 15 15 OK >> Stage Users 0000OK >> Preserved Users 3333OK >> User Groups 9999OK >> Hosts 45 45 45 46 FAIL >> Host Groups 7777OK >> HBAC Rules 6666OK >> SUDO Rules 7777OK >> DNS Zones 33 33 33 33 OK >> LDAP Conflicts NO NO NO NO OK >> Ghost Replicas 2222FAIL >> Anonymous BIND YES YES YES YES OK >> Replication Status inf01.prod 0inf01.dev 0inf01.dev 0inf01.dev 0 >> inf02.dev 0inf02.dev 0inf01.prod 0inf01.prod 0 >> inf02.prod 0inf02.prod 0inf02.prod 0inf02.dev 0 >> = >> “”” >> >> Thanks, >> Goran >> >>> On May 15, 2017, at 6:35 AM, Ludwig Krispenz wrote: >>> >>> The messages you see could be transient messages, and if replication is >>> working than this seems to be the case. If not we would need more data to >>> investigate: deployment info, relicaIDs of all servers, ruvs, logs,. >>> >>> Here is some background info: there are some scenarios where a csn could >>> not be found in the changelog, eg if updates were aplied on the supplier >>> during a total init, they could be part of the data and database ruv, but >>> not in the changelog of the initialized replica. >>> ds did try to use an alternative csn in cases where it could not be found, >>> but this had the risk of missing updates, so we decided to change it and >>> make this misssing csn a non fatal error, backoff and retry, if another >>> supplier would have updated the replica in between, the starting csn could >>> have changed and be found. so if the reported missing csns change and >>> replication continues everything is ok, although I think the messages >>> should stop at some point. >>> >>> There is a configuration parameter for a replciation agreement to trigger >>> the previous behaviour of picking an alternative csn: >>> nsds5ReplicaIgnoreMissingChange >>> with potential values "once", "always". >>> >>> where "once" just tries to kickstart replication by using another csn and >>> "always" changes the default behaviour >>> >>> >>> On 05/11/2017 06:53 PM, Goran Marik wrote: Hi, After an upgrade to Centos 7.3.1611 with “yum update", we started seeing the following messages in the logs: “”” May 9 21:58:28 inf01 ns-slapd[4323]: [09/May/2017:21:58:28.519724479 +] NSMMReplicationPlugin - changelog program - agmt="cn=cloneAgreement1-inf02.dev.ecobee.com-pki-tomcat" (inf02:389): CSN 576b34e8000a050f not found, we aren't as up to date, or we purged May 9 21:58:28 inf01 ns-slapd[4323]: [09/May/2017:21:58:28.550459233 +] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-inf02.dev.ecobee.com-pki-tomcat" (inf02:389): Data required to update replica has been purged from the changelog. The replica must be reinitialized. May 9 21:58:32
[Freeipa-users] Compat tree question
Red Hat Enterprise Linux Server release 7.3 ipa-server-4.4.0-14.el7_3.4.x86_64 389-ds-base-1.3.5.10-15.el7_3.x86_64 sssd-1.14.0-43.el7_3.11.x86_64 When looking at entries in the "cn=groups,cn=compat" tree, I noticed that the entries for windows groups have the realm portion of the group name in all caps. This is true for the comment, the dn and the cn. example: # domain us...@win.mydomain.com, groups, compat, ipa.mydomain.com dn: cn=domain us...@win.mydomain.com ,cn=groups,cn=compat,dc=ipa,dc=mydomain,dc=com memberUid: 123...@win.mydomain.com cn: domain us...@win.mydomain.com When I look at the entries in the "cn=users,cn=compat" tree, the realm portion of the user name is all lower case. Incidentally, these same user names are also all lowercase in the "memberUid" option on the groups above. example: # 123...@win.mydomain.com, users, compat, ipa.mydomain.com dn: uid=123...@win.mydomain.com,cn=users,cn=compat,dc=ipa,dc=mydomain,dc=com homeDirectory: /home/win.mydomain.com/123456 uid: 123...@win.mydomain.com Was this by design ? The reason I ask, is that when I try to use the "kinit" feature on our Solaris 10 systems (which is joined to the IPA domain) for this windows user, I get an error. [~]$ kinit Password for 123...@win.mydomain.com: kinit(v5): KDC reply did not match expectations while getting initial credentials If I run it like this: [~]$ kinit 123...@win.mydomain.com Password for 123...@win.mydomain.com: [~]$ klist Ticket cache: FILE:/tmp/krb5cc_1683378846 Default principal: 123...@win.mydomain.com Valid startingExpiresService principal 05/30/17 11:44:35 05/30/17 21:44:40 krbtgt/ win.mydomain@win.mydomain.com renew until 06/06/17 11:44:35 I believe this is due to the fact that the Solaris 10 system is using the lowercase entry in the compat tree above. Here is the result of the ID command on this user: [~]$ id uid=1683378846(123...@win.mydomain.com) gid=1683378846( 123...@win.mydomain.com) I know this is a work around but I would prefer to make this easier on the end users. Any suggestions ? Robert Johnson ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Establish Kerberos trust to non AD server running MIT Kerberos
On ti, 30 touko 2017, Andrey Ptashnik via FreeIPA-users wrote: Team, What will be correct procedure to establish kerberos trust to non Active Directory server running MIT Kerberos. This is something we do not officially support, but see https://bugzilla.redhat.com/show_bug.cgi?id=1035494#c16 and comment 14. -- / Alexander Bokovoy ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Compat tree question
On ti, 30 touko 2017, Robert Johnson via FreeIPA-users wrote: Red Hat Enterprise Linux Server release 7.3 ipa-server-4.4.0-14.el7_3.4.x86_64 389-ds-base-1.3.5.10-15.el7_3.x86_64 sssd-1.14.0-43.el7_3.11.x86_64 When looking at entries in the "cn=groups,cn=compat" tree, I noticed that the entries for windows groups have the realm portion of the group name in all caps. This is true for the comment, the dn and the cn. example: # domain us...@win.mydomain.com, groups, compat, ipa.mydomain.com dn: cn=domain us...@win.mydomain.com ,cn=groups,cn=compat,dc=ipa,dc=mydomain,dc=com memberUid: 123...@win.mydomain.com cn: domain us...@win.mydomain.com When I look at the entries in the "cn=users,cn=compat" tree, the realm portion of the user name is all lower case. Incidentally, these same user names are also all lowercase in the "memberUid" option on the groups above. example: # 123...@win.mydomain.com, users, compat, ipa.mydomain.com dn: uid=123...@win.mydomain.com,cn=users,cn=compat,dc=ipa,dc=mydomain,dc=com homeDirectory: /home/win.mydomain.com/123456 uid: 123...@win.mydomain.com Was this by design ? Users and groups for AD users are inserted into the compat tree on demand, when a request comes mentioning them via LDAP query. The name is taken from the LDAP query. So it is your application(s) that are asking fully qualified user/group names with domain part capitalized. The reason I ask, is that when I try to use the "kinit" feature on our Solaris 10 systems (which is joined to the IPA domain) for this windows user, I get an error. [~]$ kinit Password for 123...@win.mydomain.com: kinit(v5): KDC reply did not match expectations while getting initial credentials If I run it like this: [~]$ kinit 123...@win.mydomain.com Password for 123...@win.mydomain.com: [~]$ klist Ticket cache: FILE:/tmp/krb5cc_1683378846 Default principal: 123...@win.mydomain.com Valid startingExpiresService principal 05/30/17 11:44:35 05/30/17 21:44:40 krbtgt/ win.mydomain@win.mydomain.com renew until 06/06/17 11:44:35 I believe this is due to the fact that the Solaris 10 system is using the lowercase entry in the compat tree above. Here is the result of the ID command on this user: [~]$ id uid=1683378846(123...@win.mydomain.com) gid=1683378846( 123...@win.mydomain.com) I know this is a work around but I would prefer to make this easier on the end users. Any suggestions ? You mix up Kerberos principals and user identities. They are different. In Kerberos protocol realm is case-sensitive. WIN.MYDOMAIN.COM is not the same realm as win.mydomain.com. On Active Directory side this is hidden behind the Windows UI facade but on UNIX systems Kerberos libraries aren't hiding this fact. That's why you get "KDC reply did not match expectations .." error message -- a realm name is used as part of Kerberos exchange and it is expected to be all upper cases. On identity front you have probably configured your Solaris systems to look up identities with upper cased fqdn and compat tree plugin inserts those as it is. I certainly don't see this behavior with other systems. -- / Alexander Bokovoy ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] SSH Key replication time/issues
Hey again, I'm trying to track down how to ensure ssh keys are added AND removed quickly. Right now it seems I must restart ipa services or sss_cache -E to force them to update, and there doesn't seem to be a determinate amount of time to allow replication. Note, SSH keys are stored in the "Default View" for external users (external one-way trust with AD). Thanks, -Jake ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Establish Kerberos trust to non AD server running MIT Kerberos
Alexander, Thank you for the hint! We are testing component integration in the non-production environment in the lab. Can you advice if that is potentially working solution and we can get working, or someone tried without much success and Red Hat won’t be investing time into that development even in the future at all. Regards, Andrey On 5/30/17, 12:00 PM, "Alexander Bokovoy" wrote: >On ti, 30 touko 2017, Andrey Ptashnik via FreeIPA-users wrote: >>Team, >> >>What will be correct procedure to establish kerberos trust to non >>Active Directory server running MIT Kerberos. >This is something we do not officially support, but see >https://bugzilla.redhat.com/show_bug.cgi?id=1035494#c16 and comment 14. > >-- >/ Alexander Bokovoy ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Establish Kerberos trust to non AD server running MIT Kerberos
On ti, 30 touko 2017, Andrey Ptashnik via FreeIPA-users wrote: Alexander, Thank you for the hint! We are testing component integration in the non-production environment in the lab. Can you advice if that is potentially working solution and we can get working, or someone tried without much success and Red Hat won’t be investing time into that development even in the future at all. I have no idea on how Red Hat plans to productize FreeIPA features that aren't developed yet, so no comment on that side. Upstream-wise, when we get IPA-IPA trust working, we'll get to the point where this would be required to handle and have it properly working. In IPA-AD trust this is handled automatically by the code in ipasam module but IPA-AD trust is more than just a Kerberos realm trust. A problem with a generic Kerberos realm trust is that it doesn't really have an answer to an identity part of the question. You would have Kerberos principals from a trusted realm but you don't know to which identities they need to be mapped on POSIX systems enrolled into IPA, for POSIX applications. This goes further -- if we have no identities, how we can apply RBAC, HBAC, SUDO, and other rules. One possible answer to those questions is when you have identical user names on both sides and you are effectively ask to impersonate IPA users by a trusted realm Kerberos principals. This still needs manual setup on your side to allow mapping of the principals but at least solves identity problem. It is, however, a hardly most interesting case. So what use case you have in mind for such a trust? -- / Alexander Bokovoy ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Compat tree question
So I took a brand new user that I have never used in the system before (I checked that the entry was not in the compat tree) and just ran an "id" command on Solaris system. I then looked in the /var/log/dirsrv/slapd-/access log file on the ipa server, for the query and from the log file, the query came in as all caps. example: [~]$: id 831...@win.mydomin.com [~]$: cat /var/log/dirsrv/slapd-/access |grep 831413 [30/May/2017:13:34:38.637498942 -0400] conn=94124 op=622 SRCH base="cn=users,cn=compat,dc=ipa,dc=mydomain,dc=com" scope=1 filter="(&(objectClass=posixAccount)(uid=831...@win.mydomin.com))" attrs="cn uid uidNumber gidNumber gecos description homeDirectory loginShell" [30/May/2017:13:34:38.651811322 -0400] conn=94124 op=622 RESULT err=0 tag=101 nentries=1 etime=0 However, the entry in the compat tree is all lowercase just like I reported. I can reproduce this easily. Robert Johnson On Tue, May 30, 2017 at 1:10 PM, Alexander Bokovoy wrote: > On ti, 30 touko 2017, Robert Johnson via FreeIPA-users wrote: > >> Red Hat Enterprise Linux Server release 7.3 >> ipa-server-4.4.0-14.el7_3.4.x86_64 >> 389-ds-base-1.3.5.10-15.el7_3.x86_64 >> sssd-1.14.0-43.el7_3.11.x86_64 >> >> When looking at entries in the "cn=groups,cn=compat" tree, I noticed that >> the entries for windows groups have the realm portion of the group name in >> all caps. This is true for the comment, the dn and the cn. >> example: >> # domain us...@win.mydomain.com, groups, compat, ipa.mydomain.com >> dn: cn=domain us...@win.mydomain.com >> ,cn=groups,cn=compat,dc=ipa,dc=mydomain,dc=com >> memberUid: 123...@win.mydomain.com >> cn: domain us...@win.mydomain.com >> >> When I look at the entries in the "cn=users,cn=compat" tree, the realm >> portion of the user name is all lower case. Incidentally, these same user >> names are also all lowercase in the "memberUid" option on the groups >> above. >> example: >> # 123...@win.mydomain.com, users, compat, ipa.mydomain.com >> dn: uid=123...@win.mydomain.com,cn=users,cn=compat,dc=ipa,dc=myd >> omain,dc=com >> homeDirectory: /home/win.mydomain.com/123456 >> uid: 123...@win.mydomain.com >> >> Was this by design ? >> > Users and groups for AD users are inserted into the compat tree on > demand, when a request comes mentioning them via LDAP query. The name is > taken from the LDAP query. > > So it is your application(s) that are asking fully qualified user/group > names with domain part capitalized. > > > The reason I ask, is that when I try to use the "kinit" feature on our >> Solaris 10 systems (which is joined to the IPA domain) for this windows >> user, I get an error. >> >> [~]$ kinit >> Password for 123...@win.mydomain.com: >> kinit(v5): KDC reply did not match expectations while getting initial >> credentials >> >> If I run it like this: >> [~]$ kinit 123...@win.mydomain.com >> Password for 123...@win.mydomain.com: >> [~]$ klist >> Ticket cache: FILE:/tmp/krb5cc_1683378846 >> Default principal: 123...@win.mydomain.com >> >> Valid startingExpiresService principal >> 05/30/17 11:44:35 05/30/17 21:44:40 krbtgt/ >> win.mydomain@win.mydomain.com >>renew until 06/06/17 11:44:35 >> >> I believe this is due to the fact that the Solaris 10 system is using the >> lowercase entry in the compat tree above. Here is the result of the ID >> command on this user: >> [~]$ id >> uid=1683378846(123...@win.mydomain.com) gid=1683378846( >> 123...@win.mydomain.com) >> >> I know this is a work around but I would prefer to make this easier on the >> end users. Any suggestions ? >> > You mix up Kerberos principals and user identities. They are different. > In Kerberos protocol realm is case-sensitive. WIN.MYDOMAIN.COM is not > the same realm as win.mydomain.com. On Active Directory side this is > hidden behind the Windows UI facade but on UNIX systems Kerberos > libraries aren't hiding this fact. > > That's why you get "KDC reply did not match expectations .." error > message -- a realm name is used as part of Kerberos exchange and it is > expected to be all upper cases. > > On identity front you have probably configured your Solaris systems to > look up identities with upper cased fqdn and compat tree plugin inserts > those as it is. I certainly don't see this behavior with other systems. > > -- > / Alexander Bokovoy > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: [Freeipa-users]SSH Key replication time/issues
Looks like this is applied immediately, but required a service sssd restart; sss_cache -E Do these attributes have a TTL set? I know these are all SSSD Specific questions, and not directly related to FreeIPA. Thanks, Jake From: "freeipa-users" To: "freeipa-users" Cc: "Jake" Sent: Tuesday, May 30, 2017 1:15:32 PM Subject: [Freeipa-users]SSH Key replication time/issues Hey again, I'm trying to track down how to ensure ssh keys are added AND removed quickly. Right now it seems I must restart ipa services or sss_cache -E to force them to update, and there doesn't seem to be a determinate amount of time to allow replication. Note, SSH keys are stored in the "Default View" for external users (external one-way trust with AD). Thanks, -Jake ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Compat tree question
On ti, 30 touko 2017, Robert Johnson via FreeIPA-users wrote: So I took a brand new user that I have never used in the system before (I checked that the entry was not in the compat tree) and just ran an "id" command on Solaris system. I then looked in the /var/log/dirsrv/slapd-/access log file on the ipa server, for the query and from the log file, the query came in as all caps. example: [~]$: id 831...@win.mydomin.com [~]$: cat /var/log/dirsrv/slapd-/access |grep 831413 [30/May/2017:13:34:38.637498942 -0400] conn=94124 op=622 SRCH base="cn=users,cn=compat,dc=ipa,dc=mydomain,dc=com" scope=1 filter="(&(objectClass=posixAccount)(uid=831...@win.mydomin.com))" attrs="cn uid uidNumber gidNumber gecos description homeDirectory loginShell" [30/May/2017:13:34:38.651811322 -0400] conn=94124 op=622 RESULT err=0 tag=101 nentries=1 etime=0 However, the entry in the compat tree is all lowercase just like I reported. I can reproduce this easily. memberUid value comes from SSSD look up. SSSD normalizes all names to low case. For group names, I'm not sure they are normalized, though. Robert Johnson On Tue, May 30, 2017 at 1:10 PM, Alexander Bokovoy wrote: On ti, 30 touko 2017, Robert Johnson via FreeIPA-users wrote: Red Hat Enterprise Linux Server release 7.3 ipa-server-4.4.0-14.el7_3.4.x86_64 389-ds-base-1.3.5.10-15.el7_3.x86_64 sssd-1.14.0-43.el7_3.11.x86_64 When looking at entries in the "cn=groups,cn=compat" tree, I noticed that the entries for windows groups have the realm portion of the group name in all caps. This is true for the comment, the dn and the cn. example: # domain us...@win.mydomain.com, groups, compat, ipa.mydomain.com dn: cn=domain us...@win.mydomain.com ,cn=groups,cn=compat,dc=ipa,dc=mydomain,dc=com memberUid: 123...@win.mydomain.com cn: domain us...@win.mydomain.com When I look at the entries in the "cn=users,cn=compat" tree, the realm portion of the user name is all lower case. Incidentally, these same user names are also all lowercase in the "memberUid" option on the groups above. example: # 123...@win.mydomain.com, users, compat, ipa.mydomain.com dn: uid=123...@win.mydomain.com,cn=users,cn=compat,dc=ipa,dc=myd omain,dc=com homeDirectory: /home/win.mydomain.com/123456 uid: 123...@win.mydomain.com Was this by design ? Users and groups for AD users are inserted into the compat tree on demand, when a request comes mentioning them via LDAP query. The name is taken from the LDAP query. So it is your application(s) that are asking fully qualified user/group names with domain part capitalized. The reason I ask, is that when I try to use the "kinit" feature on our Solaris 10 systems (which is joined to the IPA domain) for this windows user, I get an error. [~]$ kinit Password for 123...@win.mydomain.com: kinit(v5): KDC reply did not match expectations while getting initial credentials If I run it like this: [~]$ kinit 123...@win.mydomain.com Password for 123...@win.mydomain.com: [~]$ klist Ticket cache: FILE:/tmp/krb5cc_1683378846 Default principal: 123...@win.mydomain.com Valid startingExpiresService principal 05/30/17 11:44:35 05/30/17 21:44:40 krbtgt/ win.mydomain@win.mydomain.com renew until 06/06/17 11:44:35 I believe this is due to the fact that the Solaris 10 system is using the lowercase entry in the compat tree above. Here is the result of the ID command on this user: [~]$ id uid=1683378846(123...@win.mydomain.com) gid=1683378846( 123...@win.mydomain.com) I know this is a work around but I would prefer to make this easier on the end users. Any suggestions ? You mix up Kerberos principals and user identities. They are different. In Kerberos protocol realm is case-sensitive. WIN.MYDOMAIN.COM is not the same realm as win.mydomain.com. On Active Directory side this is hidden behind the Windows UI facade but on UNIX systems Kerberos libraries aren't hiding this fact. That's why you get "KDC reply did not match expectations .." error message -- a realm name is used as part of Kerberos exchange and it is expected to be all upper cases. On identity front you have probably configured your Solaris systems to look up identities with upper cased fqdn and compat tree plugin inserts those as it is. I certainly don't see this behavior with other systems. -- / Alexander Bokovoy ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org -- / Alexander Bokovoy ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Compat tree question
Is there a option in SSSD or the plugin to turn off the normalization ? On Tue, May 30, 2017 at 2:27 PM, Alexander Bokovoy wrote: > On ti, 30 touko 2017, Robert Johnson via FreeIPA-users wrote: > >> So I took a brand new user that I have never used in the system before (I >> checked that the entry was not in the compat tree) and just ran an "id" >> command on Solaris system. I then looked in the >> /var/log/dirsrv/slapd-> domain>/access log file on the ipa server, for the query and from the log >> file, the query came in as all caps. >> >> example: >> [~]$: id 831...@win.mydomin.com >> >> [~]$: cat /var/log/dirsrv/slapd-/access |grep 831413 >> [30/May/2017:13:34:38.637498942 -0400] conn=94124 op=622 SRCH >> base="cn=users,cn=compat,dc=ipa,dc=mydomain,dc=com" scope=1 >> filter="(&(objectClass=posixAccount)(uid=831...@win.mydomin.com))" >> attrs="cn uid uidNumber gidNumber gecos description homeDirectory >> loginShell" >> [30/May/2017:13:34:38.651811322 -0400] conn=94124 op=622 RESULT err=0 >> tag=101 nentries=1 etime=0 >> >> However, the entry in the compat tree is all lowercase just like I >> reported. I can reproduce this easily. >> > memberUid value comes from SSSD look up. SSSD normalizes all names to > low case. > > For group names, I'm not sure they are normalized, though. > > > > >> Robert Johnson >> >> On Tue, May 30, 2017 at 1:10 PM, Alexander Bokovoy >> wrote: >> >> On ti, 30 touko 2017, Robert Johnson via FreeIPA-users wrote: >>> >>> Red Hat Enterprise Linux Server release 7.3 ipa-server-4.4.0-14.el7_3.4.x86_64 389-ds-base-1.3.5.10-15.el7_3.x86_64 sssd-1.14.0-43.el7_3.11.x86_64 When looking at entries in the "cn=groups,cn=compat" tree, I noticed that the entries for windows groups have the realm portion of the group name in all caps. This is true for the comment, the dn and the cn. example: # domain us...@win.mydomain.com, groups, compat, ipa.mydomain.com dn: cn=domain us...@win.mydomain.com ,cn=groups,cn=compat,dc=ipa,dc=mydomain,dc=com memberUid: 123...@win.mydomain.com cn: domain us...@win.mydomain.com When I look at the entries in the "cn=users,cn=compat" tree, the realm portion of the user name is all lower case. Incidentally, these same user names are also all lowercase in the "memberUid" option on the groups above. example: # 123...@win.mydomain.com, users, compat, ipa.mydomain.com dn: uid=123...@win.mydomain.com,cn=users,cn=compat,dc=ipa,dc=myd omain,dc=com homeDirectory: /home/win.mydomain.com/123456 uid: 123...@win.mydomain.com Was this by design ? Users and groups for AD users are inserted into the compat tree on >>> demand, when a request comes mentioning them via LDAP query. The name is >>> taken from the LDAP query. >>> >>> So it is your application(s) that are asking fully qualified user/group >>> names with domain part capitalized. >>> >>> >>> The reason I ask, is that when I try to use the "kinit" feature on our >>> Solaris 10 systems (which is joined to the IPA domain) for this windows user, I get an error. [~]$ kinit Password for 123...@win.mydomain.com: kinit(v5): KDC reply did not match expectations while getting initial credentials If I run it like this: [~]$ kinit 123...@win.mydomain.com Password for 123...@win.mydomain.com: [~]$ klist Ticket cache: FILE:/tmp/krb5cc_1683378846 Default principal: 123...@win.mydomain.com Valid startingExpiresService principal 05/30/17 11:44:35 05/30/17 21:44:40 krbtgt/ win.mydomain@win.mydomain.com renew until 06/06/17 11:44:35 I believe this is due to the fact that the Solaris 10 system is using the lowercase entry in the compat tree above. Here is the result of the ID command on this user: [~]$ id uid=1683378846(123...@win.mydomain.com) gid=1683378846( 123...@win.mydomain.com) I know this is a work around but I would prefer to make this easier on the end users. Any suggestions ? You mix up Kerberos principals and user identities. They are different. >>> In Kerberos protocol realm is case-sensitive. WIN.MYDOMAIN.COM is not >>> the same realm as win.mydomain.com. On Active Directory side this is >>> hidden behind the Windows UI facade but on UNIX systems Kerberos >>> libraries aren't hiding this fact. >>> >>> That's why you get "KDC reply did not match expectations .." error >>> message -- a realm name is used as part of Kerberos exchange and it is >>> expected to be all upper cases. >>> >>> On identity front you have probably configured your Solaris systems to >>> look up identities with upper cased fqdn and compat tree plugin inserts >>> those as it is. I certainly don't see this behavior with other systems. >>> >>> -- >>> / Alexander Bokovoy >>> >>> >
[Freeipa-users] Re: Compat tree question
On ti, 30 touko 2017, Robert Johnson via FreeIPA-users wrote: Is there a option in SSSD or the plugin to turn off the normalization ? No. But as I said, you are not supposed to use all capital fqdn. You need to use your user/group name as it is. id user@ad.realm kinit user@AD.REALM are two different names -- the former is user name in POSIX and it is case sensitive to the operating system but is case-insensitive in LDAP. The latter is Kerberos principal which is case sensitive to Kerberos KDC. In LDAP 'uid' attribute is compared case-sensitive, 'cn' attribute is case-insensitive. For 'uid' we add a secondary value from SSSD (normalized) if it is different from the original in request because case-normalized searches wouldn't work otherwise. For 'cn' we don't change anything because 'cn' comparison syntax in LDAP is case-insensitive. On Tue, May 30, 2017 at 2:27 PM, Alexander Bokovoy wrote: On ti, 30 touko 2017, Robert Johnson via FreeIPA-users wrote: So I took a brand new user that I have never used in the system before (I checked that the entry was not in the compat tree) and just ran an "id" command on Solaris system. I then looked in the /var/log/dirsrv/slapd-/access log file on the ipa server, for the query and from the log file, the query came in as all caps. example: [~]$: id 831...@win.mydomin.com [~]$: cat /var/log/dirsrv/slapd-/access |grep 831413 [30/May/2017:13:34:38.637498942 -0400] conn=94124 op=622 SRCH base="cn=users,cn=compat,dc=ipa,dc=mydomain,dc=com" scope=1 filter="(&(objectClass=posixAccount)(uid=831...@win.mydomin.com))" attrs="cn uid uidNumber gidNumber gecos description homeDirectory loginShell" [30/May/2017:13:34:38.651811322 -0400] conn=94124 op=622 RESULT err=0 tag=101 nentries=1 etime=0 However, the entry in the compat tree is all lowercase just like I reported. I can reproduce this easily. memberUid value comes from SSSD look up. SSSD normalizes all names to low case. For group names, I'm not sure they are normalized, though. Robert Johnson On Tue, May 30, 2017 at 1:10 PM, Alexander Bokovoy wrote: On ti, 30 touko 2017, Robert Johnson via FreeIPA-users wrote: Red Hat Enterprise Linux Server release 7.3 ipa-server-4.4.0-14.el7_3.4.x86_64 389-ds-base-1.3.5.10-15.el7_3.x86_64 sssd-1.14.0-43.el7_3.11.x86_64 When looking at entries in the "cn=groups,cn=compat" tree, I noticed that the entries for windows groups have the realm portion of the group name in all caps. This is true for the comment, the dn and the cn. example: # domain us...@win.mydomain.com, groups, compat, ipa.mydomain.com dn: cn=domain us...@win.mydomain.com ,cn=groups,cn=compat,dc=ipa,dc=mydomain,dc=com memberUid: 123...@win.mydomain.com cn: domain us...@win.mydomain.com When I look at the entries in the "cn=users,cn=compat" tree, the realm portion of the user name is all lower case. Incidentally, these same user names are also all lowercase in the "memberUid" option on the groups above. example: # 123...@win.mydomain.com, users, compat, ipa.mydomain.com dn: uid=123...@win.mydomain.com,cn=users,cn=compat,dc=ipa,dc=myd omain,dc=com homeDirectory: /home/win.mydomain.com/123456 uid: 123...@win.mydomain.com Was this by design ? Users and groups for AD users are inserted into the compat tree on demand, when a request comes mentioning them via LDAP query. The name is taken from the LDAP query. So it is your application(s) that are asking fully qualified user/group names with domain part capitalized. The reason I ask, is that when I try to use the "kinit" feature on our Solaris 10 systems (which is joined to the IPA domain) for this windows user, I get an error. [~]$ kinit Password for 123...@win.mydomain.com: kinit(v5): KDC reply did not match expectations while getting initial credentials If I run it like this: [~]$ kinit 123...@win.mydomain.com Password for 123...@win.mydomain.com: [~]$ klist Ticket cache: FILE:/tmp/krb5cc_1683378846 Default principal: 123...@win.mydomain.com Valid startingExpiresService principal 05/30/17 11:44:35 05/30/17 21:44:40 krbtgt/ win.mydomain@win.mydomain.com renew until 06/06/17 11:44:35 I believe this is due to the fact that the Solaris 10 system is using the lowercase entry in the compat tree above. Here is the result of the ID command on this user: [~]$ id uid=1683378846(123...@win.mydomain.com) gid=1683378846( 123...@win.mydomain.com) I know this is a work around but I would prefer to make this easier on the end users. Any suggestions ? You mix up Kerberos principals and user identities. They are different. In Kerberos protocol realm is case-sensitive. WIN.MYDOMAIN.COM is not the same realm as win.mydomain.com. On Active Directory side this is hidden behind the Windows UI facade but on UNIX systems Kerberos libraries aren't hiding this fact. That's why you get "KDC reply did not match expectations .." error message -- a realm name is used as part of Kerberos exchange and it is expected to be
[Freeipa-users] Kerberos and load balancing
Hi, I have a load balancer in front of three Webservers. I have read about the possible scenarios on https://ssimo.org/blog/id_019.html and I am already sucessfully using one common SPN for the loadbalancer. My question is: Will it work if the domains are not the same? (i.e. if the loadbalancer SPN is HTTP/someservice.mydomain...@mydomain.at but the servers are in a subdomain like for instance webserver1.linux.mydomain.at) Regards, Ronald ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Establish Kerberos trust to non AD server running MIT Kerberos
Alexander, Thanks again for your point of view of the problem! There are some Linux centric products on the market that require centralized AAA services (Authentication, Authorization, Accounting). One of them is Hadoop and it’s Hortonworks implementation. It has it’s own Kerberos to be able to authenticate users from centrally managed domain and we were exploring options on how to point it into user base that we currently have within IPA domain. Regards, Andrey On 5/30/17, 12:43 PM, "Alexander Bokovoy" wrote: >On ti, 30 touko 2017, Andrey Ptashnik via FreeIPA-users wrote: >>Alexander, >> >>Thank you for the hint! >>We are testing component integration in the non-production environment >>in the lab. Can you advice if that is potentially working solution and >>we can get working, or someone tried without much success and Red Hat >>won’t be investing time into that development even in the future at >>all. >I have no idea on how Red Hat plans to productize FreeIPA features that >aren't developed yet, so no comment on that side. > >Upstream-wise, when we get IPA-IPA trust working, we'll get to the point >where this would be required to handle and have it properly working. In >IPA-AD trust this is handled automatically by the code in ipasam module >but IPA-AD trust is more than just a Kerberos realm trust. > >A problem with a generic Kerberos realm trust is that it doesn't really >have an answer to an identity part of the question. You would have >Kerberos principals from a trusted realm but you don't know to which >identities they need to be mapped on POSIX systems enrolled into IPA, >for POSIX applications. > >This goes further -- if we have no identities, how we can apply RBAC, >HBAC, SUDO, and other rules. > >One possible answer to those questions is when you have identical user >names on both sides and you are effectively ask to impersonate IPA >users by a trusted realm Kerberos principals. This still needs manual >setup on your side to allow mapping of the principals but at least >solves identity problem. It is, however, a hardly most interesting case. > >So what use case you have in mind for such a trust? > >-- >/ Alexander Bokovoy ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Establish Kerberos trust to non AD server running MIT Kerberos
On ti, 30 touko 2017, Andrey Ptashnik wrote: Alexander, Thanks again for your point of view of the problem! There are some Linux centric products on the market that require centralized AAA services (Authentication, Authorization, Accounting). One of them is Hadoop and it’s Hortonworks implementation. It has it’s own Kerberos to be able to authenticate users from centrally managed domain and we were exploring options on how to point it into user base that we currently have within IPA domain. Did you check https://mapredit.blogspot.fi/2016/10/freeipa-and-hadoop-distributions-hdp-cdh.html ? Specifically, for Hortonworks' Ambari: https://community.hortonworks.com/articles/59645/ambari-24-kerberos-with-freeipa.html -- / Alexander Bokovoy ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Establish Kerberos trust to non AD server running MIT Kerberos
Alexander, Thank you for those documents! Term “experimental” little scared me away, however I’ll give it a try, since we have a journey for the best, read future proof, option. Regards, Andrey On 5/30/17, 3:09 PM, "Alexander Bokovoy" wrote: >On ti, 30 touko 2017, Andrey Ptashnik wrote: >>Alexander, >> >>Thanks again for your point of view of the problem! >>There are some Linux centric products on the market that require >>centralized AAA services (Authentication, Authorization, Accounting). >>One of them is Hadoop and it’s Hortonworks implementation. It has it’s >>own Kerberos to be able to authenticate users from centrally managed >>domain and we were exploring options on how to point it into user base >>that we currently have within IPA domain. > >Did you check >https://mapredit.blogspot.fi/2016/10/freeipa-and-hadoop-distributions-hdp-cdh.html >? > >Specifically, for Hortonworks' Ambari: >https://community.hortonworks.com/articles/59645/ambari-24-kerberos-with-freeipa.html > >-- >/ Alexander Bokovoy ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: SSSD Cache and Service Tickets
On 2017-05-29 09:45, Sumit Bose via FreeIPA-users wrote: > On Sat, May 27, 2017 at 05:46:57PM +0200, Ronald Wimmer via FreeIPA-users > wrote: >> On 2017-05-26 18:51, Sumit Bose via FreeIPA-users wrote: >>> [...] >>> Did you ‘Allow GSSAPI credential delegation’ in the putty configuration? >>> Additionally the internal Windows Kerberos handling only allows >>> delegation to host which have the ok-to-delegate flag set in the >>> Kerberos service ticket. >>> >>> Please check with 'ipa host-show hostname' if 'Trusted for delegation: >>> True', if not please try 'ipa host-mod hostname --ok-as-delegate=True'. >> Setting the flag solved the problem. Thanks a lot. >> >> Can this flag be set by default for new hosts? > As fas as I know IPA does not offer such option. Imo it would not be > a good idea to enable it by default. Since delegation means that your > full TGT is forwarded the target host should really be trusted because > otherwise someone with e.g. physical access to the host might be able to > steal the TGT and use it as long as the ticket is valid. > What other options do I have if I want users connecting from Windows to be able to use automounted home directories? ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Establish Kerberos trust to non AD server running MIT Kerberos
Another common use case is with acquisitions when you bringing on board team and their equipment that is also being managed by another IPA domain with respective products already integrated in it like OpenStack / OpenShift. You could survive with dual accounts, however not for long. Regards, Andrey On 5/30/17, 12:43 PM, "Alexander Bokovoy" wrote: > >So what use case you have in mind for such a trust? > >-- >/ Alexander Bokovoy > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] very slow remove users process
Hi folks, I have a freeipa group with 3 users to delete. The process is very very slow. For example: # time ipa -v user-del vvv - Deleted user "vvv" - real0m16.913s user0m0.814s sys 0m0.084s The hardware parameters are normal. The hard drive is SSD. Regards. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: ipa command breaks by setting "NSSVerifyClient require"
On Tue, May 30, 2017 at 10:46:59AM -0500, Ian Pilcher via FreeIPA-users wrote: > On 05/29/2017 07:15 PM, Fraser Tweedale via FreeIPA-users wrote: > > On Mon, May 29, 2017 at 06:26:31PM +0530, Ivars Strazdiņš wrote: > > > I am not saying “instead of”. We are using standard authetication > > > provided by FreeIPA, but I want to protect Web UI interface from unwanted > > > attention as it is, unfortunately, exposed to entire internet. I’d be > > > much happier if Apache could reject (or redirect) any client which is not > > > presenting required certificate even before any authentication attempt is > > > started. > > > That is not to say that the whole server is exposed, but 443 port is. > > > > > Thanks for explaining. > > Maybe I'm missing something in this thread, but couldn't the OP simply > put a reverse proxy in front of the Internet-exposed port? > What you are missing: the client tools do not support certificate authentication (yet). ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: ipa command breaks by setting "NSSVerifyClient require"
> On 2017. gada 30. maijs, at 21:16, Ian Pilcher via FreeIPA-users > wrote: > > On 05/29/2017 07:15 PM, Fraser Tweedale via FreeIPA-users wrote: >> On Mon, May 29, 2017 at 06:26:31PM +0530, Ivars Strazdiņš wrote: >>> I am not saying “instead of”. We are using standard authetication provided >>> by FreeIPA, but I want to protect Web UI interface from unwanted attention >>> as it is, unfortunately, exposed to entire internet. I’d be much happier if >>> Apache could reject (or redirect) any client which is not presenting >>> required certificate even before any authentication attempt is started. >>> That is not to say that the whole server is exposed, but 443 port is. >>> >> Thanks for explaining. > > Maybe I'm missing something in this thread, but couldn't the OP simply > put a reverse proxy in front of the Internet-exposed port? That’s a clever hint that I will explore. Thanks! Ivars ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
