Re: [Freeipa-users] AD trust deployment without IPA authority over reverse lookup zone
On Tue, 2015-08-25 at 15:19 +0200, Petr Spacek wrote: On 1.8.2015 21:19, John Stein wrote: Hi, Thanks for the reply. Any Idea when will the GSSAPI-updating bug fix get to RHEL 7? You can watch the progress here: https://bugzilla.redhat.com/show_bug.cgi?id=1214827 Unfortunately fixing this bug will not be sufficient for your particular scenario. FreeIPA does not allow ordinary host/ principals used by client machines (not to be confused with FreeIPA servers) to get tickets for AD Kerberos realms. It effectively means that nsupdate will properly detect the AD realm and generate correct request but the request will be refused because the client will not be able to get ticket. I.e. you will have to resort to manual PTR record update OR convince Alexander/Simo that allowing host/ principals from FreeIPA realm to get tickets for AD realm is not a security issue :-) There is no security issue per se, host/ principals can get tickets just fine but we do not attach a PAC here, and AD may refuse to operate w/o a MS-PAC. Please open a RFE if this is breaking operations. We'll need to decide how to assign a SID to hosts but that's the only security issue that needs to be solved. Simo. Petr^2 Spacek Thanks again, John On Mon, Jul 27, 2015 at 5:30 PM Alexander Bokovoy aboko...@redhat.com wrote: On Mon, 27 Jul 2015, John Stein wrote: Hi, I consider deploying IPA in my organization.The environment is disconnected from the internet.I have some concerns I'm not sure how to resolve. The environment consists mostly of windows servers (thousands) and workstations (ten thousand) managed by AD (CORP.COM). There is also a small linux environment (up to a thousand servers) that are currently not centerally managed (user-wise). I want to utilize IPA and the AD trust feature to implement SSO. I'd like to have a sub-domain ran by IPA (LINUX.CORP.COM). Because the environment is windows dominated, the AD is used as the authoritative DNS server for all forward and reverse lookup zones. The AD trust requires that both the IPA and AD will be authoritative over their respective forward and reverse lookup zones. However, the linux and No. We require that *some entity* is responsible for the zones. If you put everything in AD DNS, fine, but then you are responsible for manual update of the zone records and that all specific records are there. windows servers are spread across multiple subnets without any big-scale logic, therefore it is not practical to create a reverse lookup zone for each subnet in the IPA server as those subnets contain both linux and windows machines. You cannot have machines from IPA and AD domains in the same DNS zone at the same time. A/ records of those IPA and AD machines must belong to different DNS zones. This is basic requirement of Active Directory deployment -- each AD domain is responsible for at least one DNS zone and you cannot have machines from two different AD domains in the same DNS zone. I came up with some solutions: 1) Have only the AD as a DNS server and give up on ipa-client-install and automatic client registration. Totally unrelated to how you handle DNS zones. ipa-client-install does not require you to allow creation of DNS records. It can sufficiently work with a configuration where a DNS record for the host is pre-created. 2) DNS synchronization between IPA and AD. Unrelated and is not recommended. In DNS lexicon only a single entity is responsible for the single DNS zone. IPA cannot be authoritative at the same time as AD. (Neither we support IPA being a slave for other DNS server). 3) Have the IPA manage the forward zone (linux.corp.com), and have the clients update its own A record automatically upon ipa-client-install, while having the AD manage the reverse zones (A or B class subnets) with me creating the PTR records manually. The IPA will be configured as a conditional forwarder for linux.corp.com, while the AD will be configured as a global forwarder in the IPA server. That would work. There is a bug in nsupdate tool that prevents you from GSSAPI-updating PTR records (over AD trust) so going with manual PTR records would work. You need to make sure AD has no policy to periodically remove PTR records for Linux machines. -- / Alexander Bokovoy -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] firefox add-on corrupt
Hello I got ipa server and replica working for over a year. But now when I try to acces the web ui I have to login with user/password intead of kerberos ticket. If I go to http://ipaserver.bla.bla.bla/ipa/config/browserconfig.html and click on Install Kerberos Configuration Firefox extension it gives me the following error: The add-on downloaded from ipaserver.bla.bla.bla could not be installed because it appears to be corrupt It happens the same at replica web ui Both servers are latest and updated rhel7 Clients are ubuntu and fedora with firefox 40 -- Gustavo Berman Sysadmin - Gerencia de Física - Centro Atómico Bariloche - CNEA -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] bind-dynamicdb TKEY update
On 29.7.2015 06:30, Jorgen Lundman wrote: Hola! So with todays advisory: https://kb.isc.org/article/AA-01272 we finally get to test the procedure to patch and update here :) Are there any plans for the dynamic_db github to pull in the fix, or should I proceed with that step? For the record, dynamic_db repo is kind of obsolete because the API is being merged to upstream BIND (hopefully) and we are changing the API at the same time. I.e. not merging fixes to dynamic_db repo should make you nervous :-) See https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Patches#Futuredevelopment for further details. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] AD trust deployment without IPA authority over reverse lookup zone
On Tue, 25 Aug 2015, Simo Sorce wrote: On Tue, 2015-08-25 at 15:19 +0200, Petr Spacek wrote: On 1.8.2015 21:19, John Stein wrote: Hi, Thanks for the reply. Any Idea when will the GSSAPI-updating bug fix get to RHEL 7? You can watch the progress here: https://bugzilla.redhat.com/show_bug.cgi?id=1214827 Unfortunately fixing this bug will not be sufficient for your particular scenario. FreeIPA does not allow ordinary host/ principals used by client machines (not to be confused with FreeIPA servers) to get tickets for AD Kerberos realms. It effectively means that nsupdate will properly detect the AD realm and generate correct request but the request will be refused because the client will not be able to get ticket. I.e. you will have to resort to manual PTR record update OR convince Alexander/Simo that allowing host/ principals from FreeIPA realm to get tickets for AD realm is not a security issue :-) There is no security issue per se, host/ principals can get tickets just fine but we do not attach a PAC here, and AD may refuse to operate w/o a MS-PAC. Please open a RFE if this is breaking operations. We'll need to decide how to assign a SID to hosts but that's the only security issue that needs to be solved. For one-way trust you'll be unable to get the ticket at all as there is no cross-forest TGT on our side to issue. And this is a default configuration in FreeIPA 4.2. You will have to have bi-directional trust to get GSSAPI authentication in nsupdate working at all against a trusted forest. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] AD trust deployment without IPA authority over reverse lookup zone
On 25.8.2015 16:08, Alexander Bokovoy wrote: On Tue, 25 Aug 2015, Simo Sorce wrote: On Tue, 2015-08-25 at 15:19 +0200, Petr Spacek wrote: On 1.8.2015 21:19, John Stein wrote: Hi, Thanks for the reply. Any Idea when will the GSSAPI-updating bug fix get to RHEL 7? You can watch the progress here: https://bugzilla.redhat.com/show_bug.cgi?id=1214827 Unfortunately fixing this bug will not be sufficient for your particular scenario. FreeIPA does not allow ordinary host/ principals used by client machines (not to be confused with FreeIPA servers) to get tickets for AD Kerberos realms. It effectively means that nsupdate will properly detect the AD realm and generate correct request but the request will be refused because the client will not be able to get ticket. I.e. you will have to resort to manual PTR record update OR convince Alexander/Simo that allowing host/ principals from FreeIPA realm to get tickets for AD realm is not a security issue :-) There is no security issue per se, host/ principals can get tickets just fine but we do not attach a PAC here, and AD may refuse to operate w/o a MS-PAC. Please open a RFE if this is breaking operations. We'll need to decide how to assign a SID to hosts but that's the only security issue that needs to be solved. Here it is: https://fedorahosted.org/freeipa/ticket/5260 For one-way trust you'll be unable to get the ticket at all as there is no cross-forest TGT on our side to issue. And this is a default configuration in FreeIPA 4.2. You will have to have bi-directional trust to get GSSAPI authentication in nsupdate working at all against a trusted forest. Understood, that is the price users have to pay for using one-way trust. Still, I think that we should support this use case if user is willing to use bi-directional trust. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA user Home Directory Permission Issue
Hi Simo, We are usingsession optional *pam_oddjob_mkhomedir*.so umask=0077 *Best Regards,* *__* *Yogesh Sharma* *Email: yks0...@gmail.com yks0...@gmail.com | Web: www.initd.in http://www.initd.in/ * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* https://www.fb.com/yks http://in.linkedin.com/in/yks https://twitter.com/checkwithyogesh http://google.com/+YogeshSharmaOnGooglePlus On Mon, Aug 24, 2015 at 12:21 AM, Simo Sorce s...@redhat.com wrote: On Sun, 2015-08-23 at 12:06 +0530, Yogesh Sharma wrote: Typo: Umask set is 0077, then the permission should be 700, though we are getting 755. Where are you setting this mask ? And what pam helper do you use to create the home dirs ? pam_mkhomedir ? ot pam_oddjob_mkhomedir ? Simo. *Best Regards,* *__* *Yogesh Sharma* *Email: yks0...@gmail.com yks0...@gmail.com | Web: www.initd.in http://www.initd.in/ * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* https://www.fb.com/yks http://in.linkedin.com/in/yks https://twitter.com/checkwithyogesh http://google.com/+YogeshSharmaOnGooglePlus On Sun, Aug 23, 2015 at 12:00 PM, Yogesh Sharma yks0...@gmail.com wrote: Hi, FreeIPA users are getting their home directory with default permission of 755 instead of 700. I have checked the pam.d configuration and the umask set there for mkhomedir.so is 0700, however home dir permission are not according to this. Is there somewhere else we need to add the umask to make it 700. Please suggest. *Best Regards,* *__* *Yogesh Sharma* *Email: yks0...@gmail.com yks0...@gmail.com | Web: www.initd.in http://www.initd.in/ * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* https://www.fb.com/yks http://in.linkedin.com/in/yks https://twitter.com/checkwithyogesh http://google.com/+YogeshSharmaOnGooglePlus -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA user Home Directory Permission Issue
Hi Simo, We are usingsession optional *pam_oddjob_mkhomedir*.so umask=0077 and included in password-auth-ac and password-auth *Best Regards,* *__* *Yogesh Sharma* *Email: yks0...@gmail.com yks0...@gmail.com | Web: www.initd.in http://www.initd.in/ * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* https://www.fb.com/yks http://in.linkedin.com/in/yks https://twitter.com/checkwithyogesh http://google.com/+YogeshSharmaOnGooglePlus On Tue, Aug 25, 2015 at 3:29 PM, Yogesh Sharma yks0...@gmail.com wrote: Hi Simo, We are usingsession optional *pam_oddjob_mkhomedir*.so umask=0077 *Best Regards,* *__* *Yogesh Sharma* *Email: yks0...@gmail.com yks0...@gmail.com | Web: www.initd.in http://www.initd.in/ * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* https://www.fb.com/yks http://in.linkedin.com/in/yks https://twitter.com/checkwithyogesh http://google.com/+YogeshSharmaOnGooglePlus On Mon, Aug 24, 2015 at 12:21 AM, Simo Sorce s...@redhat.com wrote: On Sun, 2015-08-23 at 12:06 +0530, Yogesh Sharma wrote: Typo: Umask set is 0077, then the permission should be 700, though we are getting 755. Where are you setting this mask ? And what pam helper do you use to create the home dirs ? pam_mkhomedir ? ot pam_oddjob_mkhomedir ? Simo. *Best Regards,* *__* *Yogesh Sharma* *Email: yks0...@gmail.com yks0...@gmail.com | Web: www.initd.in http://www.initd.in/ * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* https://www.fb.com/yks http://in.linkedin.com/in/yks https://twitter.com/checkwithyogesh http://google.com/+YogeshSharmaOnGooglePlus On Sun, Aug 23, 2015 at 12:00 PM, Yogesh Sharma yks0...@gmail.com wrote: Hi, FreeIPA users are getting their home directory with default permission of 755 instead of 700. I have checked the pam.d configuration and the umask set there for mkhomedir.so is 0700, however home dir permission are not according to this. Is there somewhere else we need to add the umask to make it 700. Please suggest. *Best Regards,* *__* *Yogesh Sharma* *Email: yks0...@gmail.com yks0...@gmail.com | Web: www.initd.in http://www.initd.in/ * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* https://www.fb.com/yks http://in.linkedin.com/in/yks https://twitter.com/checkwithyogesh http://google.com/+YogeshSharmaOnGooglePlus -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] AD trust deployment without IPA authority over reverse lookup zone
On 1.8.2015 21:19, John Stein wrote: Hi, Thanks for the reply. Any Idea when will the GSSAPI-updating bug fix get to RHEL 7? You can watch the progress here: https://bugzilla.redhat.com/show_bug.cgi?id=1214827 Unfortunately fixing this bug will not be sufficient for your particular scenario. FreeIPA does not allow ordinary host/ principals used by client machines (not to be confused with FreeIPA servers) to get tickets for AD Kerberos realms. It effectively means that nsupdate will properly detect the AD realm and generate correct request but the request will be refused because the client will not be able to get ticket. I.e. you will have to resort to manual PTR record update OR convince Alexander/Simo that allowing host/ principals from FreeIPA realm to get tickets for AD realm is not a security issue :-) Petr^2 Spacek Thanks again, John On Mon, Jul 27, 2015 at 5:30 PM Alexander Bokovoy aboko...@redhat.com wrote: On Mon, 27 Jul 2015, John Stein wrote: Hi, I consider deploying IPA in my organization.The environment is disconnected from the internet.I have some concerns I'm not sure how to resolve. The environment consists mostly of windows servers (thousands) and workstations (ten thousand) managed by AD (CORP.COM). There is also a small linux environment (up to a thousand servers) that are currently not centerally managed (user-wise). I want to utilize IPA and the AD trust feature to implement SSO. I'd like to have a sub-domain ran by IPA (LINUX.CORP.COM). Because the environment is windows dominated, the AD is used as the authoritative DNS server for all forward and reverse lookup zones. The AD trust requires that both the IPA and AD will be authoritative over their respective forward and reverse lookup zones. However, the linux and No. We require that *some entity* is responsible for the zones. If you put everything in AD DNS, fine, but then you are responsible for manual update of the zone records and that all specific records are there. windows servers are spread across multiple subnets without any big-scale logic, therefore it is not practical to create a reverse lookup zone for each subnet in the IPA server as those subnets contain both linux and windows machines. You cannot have machines from IPA and AD domains in the same DNS zone at the same time. A/ records of those IPA and AD machines must belong to different DNS zones. This is basic requirement of Active Directory deployment -- each AD domain is responsible for at least one DNS zone and you cannot have machines from two different AD domains in the same DNS zone. I came up with some solutions: 1) Have only the AD as a DNS server and give up on ipa-client-install and automatic client registration. Totally unrelated to how you handle DNS zones. ipa-client-install does not require you to allow creation of DNS records. It can sufficiently work with a configuration where a DNS record for the host is pre-created. 2) DNS synchronization between IPA and AD. Unrelated and is not recommended. In DNS lexicon only a single entity is responsible for the single DNS zone. IPA cannot be authoritative at the same time as AD. (Neither we support IPA being a slave for other DNS server). 3) Have the IPA manage the forward zone (linux.corp.com), and have the clients update its own A record automatically upon ipa-client-install, while having the AD manage the reverse zones (A or B class subnets) with me creating the PTR records manually. The IPA will be configured as a conditional forwarder for linux.corp.com, while the AD will be configured as a global forwarder in the IPA server. That would work. There is a bug in nsupdate tool that prevents you from GSSAPI-updating PTR records (over AD trust) so going with manual PTR records would work. You need to make sure AD has no policy to periodically remove PTR records for Linux machines. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Trying to enroll clients on CentOS7 with '--' in the host name failing
We have a rather strange need to have '--' in some standard host names and when I use the CentOS7 ipa-client 4.1 I get the following error message. [root@pan-smk-pdev lib]# ipa-join -h craigs--ipa--client--test.pearsondev.com RPC failed at server. invalid 'hostname': invalid domain-name: only letters, numbers, '-' are allowed. DNS label may not start or end with '-' If I use a single quote it will work but, our automation environment creates hosts that have '--' in the name. Any idea how to get around this or is there some other hard requirement for not using '-' in DNS/Krb principal names? Thanks ! Craig -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Trying to enroll clients on CentOS7 with '--' in the host name failing
McNiel, Craig wrote: We have a rather strange need to have '--' in some standard host names and when I use the CentOS7 ipa-client 4.1 I get the following error message. [root@pan-smk-pdev lib]# ipa-join -h craigs--ipa--client--test.pearsondev.com http://craigs--ipa--client--test.pearsondev.com RPC failed at server. invalid 'hostname': invalid domain-name: only letters, numbers, '-' are allowed. DNS label may not start or end with '-' If I use a single quote it will work but, our automation environment creates hosts that have '--' in the name. Any idea how to get around this or is there some other hard requirement for not using '-' in DNS/Krb principal names? It's a known issue, https://fedorahosted.org/freeipa/ticket/4710, no workaround that I see other than manually changing the regex on the IPA server (which is a dangerous path to take). rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA user Home Directory Permission Issue
On Tue, 2015-08-25 at 15:30 +0530, Yogesh Sharma wrote: Hi Simo, We are usingsession optional *pam_oddjob_mkhomedir*.so umask=0077 and included in password-auth-ac and password-auth I guess you should read the pam_oddjob_mkhomedir manpage which will tell you that the way you are specifying the umask is incorrect :-) Hint: see oddjob-mkhomedir.conf HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
