[Freeipa-users] OTP and Laptops
Hello, I'm wondering where/how I could get some more information about the underpinnings of the OTP token mechanisms? Ultimately, I'd like to understand the reason why OTP in FreeIPA doesn't work at the moment with laptops, specifically. -- 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] OTP and Laptops
Depending on the laptop -- assuming you are trying to kinit from a terminal window, check the version of Kerberos. It needs to be at least 1.6. ~J On 7/27/15 7:48 AM, John Johnson wrote: Hello, I'm wondering where/how I could get some more information about the underpinnings of the OTP token mechanisms? Ultimately, I'd like to understand the reason why OTP in FreeIPA doesn't work at the moment with laptops, specifically. -- 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] AD trust deployment without IPA authority over reverse lookup zone
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 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. 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. 2) DNS synchronization between IPA and AD. 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. I strongly dislike the first two solutions and I would like your opinion on the feasibility of the third. I'm also open for any other ideas. If there aren't any, is this solution feasible? Thanks, John -- 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 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
Re: [Freeipa-users] OTP and Laptops
Kerberos version is 1.12.2 on RHEL7.1. I guess I'm wondering if the issue is hardware-related, somehow specific to laptops; or if it's related to the way laptops are assumed to be used, i.e. portable, etc. On Mon, Jul 27, 2015 at 10:14 AM, Janelle janellenicol...@gmail.com wrote: Depending on the laptop -- assuming you are trying to kinit from a terminal window, check the version of Kerberos. It needs to be at least 1.6. ~J On 7/27/15 7:48 AM, John Johnson wrote: Hello, I'm wondering where/how I could get some more information about the underpinnings of the OTP token mechanisms? Ultimately, I'd like to understand the reason why OTP in FreeIPA doesn't work at the moment with laptops, specifically. -- 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 -- 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] OTP and Laptops
John Johnson wrote: Kerberos version is 1.12.2 on RHEL7.1. I guess I'm wondering if the issue is hardware-related, somehow specific to laptops; or if it's related to the way laptops are assumed to be used, i.e. portable, etc. It would be helpful if you described what isn't working. rob On Mon, Jul 27, 2015 at 10:14 AM, Janelle janellenicol...@gmail.com mailto:janellenicol...@gmail.com wrote: Depending on the laptop -- assuming you are trying to kinit from a terminal window, check the version of Kerberos. It needs to be at least 1.6. ~J On 7/27/15 7:48 AM, John Johnson wrote: Hello, I'm wondering where/how I could get some more information about the underpinnings of the OTP token mechanisms? Ultimately, I'd like to understand the reason why OTP in FreeIPA doesn't work at the moment with laptops, specifically. -- 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 -- 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] OTP and Laptops
I'm not saying that something isn't working for me; I'm going off the information available on https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/authconfig-addl-auth.html#otp-laptop-users and a thread in this mailing list referencing it. I'm simply trying to understand the particular issue related to the laptop-specific implementation and obstacles as it relates to OTP On Mon, Jul 27, 2015 at 10:13 PM, Rob Crittenden rcrit...@redhat.com wrote: John Johnson wrote: Kerberos version is 1.12.2 on RHEL7.1. I guess I'm wondering if the issue is hardware-related, somehow specific to laptops; or if it's related to the way laptops are assumed to be used, i.e. portable, etc. It would be helpful if you described what isn't working. rob On Mon, Jul 27, 2015 at 10:14 AM, Janelle janellenicol...@gmail.com mailto:janellenicol...@gmail.com wrote: Depending on the laptop -- assuming you are trying to kinit from a terminal window, check the version of Kerberos. It needs to be at least 1.6. ~J On 7/27/15 7:48 AM, John Johnson wrote: Hello, I'm wondering where/how I could get some more information about the underpinnings of the OTP token mechanisms? Ultimately, I'd like to understand the reason why OTP in FreeIPA doesn't work at the moment with laptops, specifically. -- 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 -- 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] Failed to start pki-tomcatd Service
On Sun, 26 Jul 2015, Alexandre Ellert wrote: 2015-07-23 8:41 GMT+02:00 Alexander Bokovoy aboko...@redhat.com: On Thu, 23 Jul 2015, Ludwig Krispenz wrote: - Directory server starts just fine but serves only port 389 - krb5kdc starts just fine and works fine with LDAP server - Dogtag tries to use LDAP server via port 636 and fails We need to see why port 636 is disabled. why do you think so ? There is: [22/Jul/2015:18:14:54 +0200] - slapd started. Listening on All Interfaces port 389 for LDAP requests [22/Jul/2015:18:14:54 +0200] - Listening on All Interfaces port 636 for LDAPS requests [22/Jul/2015:18:14:54 +0200] - Listening on /var/run/slapd-NUMEEZY-FR.socket for LDAPI requests Missed that part. However, dogtag was failing in accessing LDAP over port 636. but what is failing is: agmt=cn=cloneAgreement1-inf-ipa-2.numeezy.fr-pki-tomcat (inf-ipa:7389): Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) () Is dogtag on a different instance ? why do we use port 7389 ? Because it was migration from RHEL6 to RHEL7. In RHEL6 dogtag was living in a separate instance. If the problem is too hard to solve, maybe I should try to deploy another replica ? You may try that. Sorry for not responding, I have some other tasks that occupy my time right now. If you have Red Hat subscription, it would be good to open a support case and put the details of the migration and logs there. -- / 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] OTP and Laptops
On Mon, 27 Jul 2015, John Johnson wrote: I'm not saying that something isn't working for me; I'm going off the information available on https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/authconfig-addl-auth.html#otp-laptop-users and a thread in this mailing list referencing it. I'm simply trying to understand the particular issue related to the laptop-specific implementation and obstacles as it relates to OTP No, there is no hardware-specific limitations. What the documentation tries to explain (rather poorly, I agree!) is that a roaming clients like laptops would have some issues when OTP is the only scheme enabled for the user. This is solved in SSSD 1.13 and both solution and the problem are described in detail in https://fedorahosted.org/sssd/wiki/DesignDocs/PAMConversationForOTP -- / 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
