Re: [Freeipa-users] FreeIPA smart card how to
Okay. I haven't been able to get around this issue. I can log using my username, my card is recognized by GDM and reads the card as expected, but I am unable to login using my smartcard. From what I can see in the logs the common name on my card doesn't match the username on my test account. Feb 2 13:00:05 cabildo gdm-smartcard]: pam_krb5[5152]: error resolving user name '' to uid/gid pair Feb 2 13:00:05 cabildo gdm-smartcard]: pam_krb5[5152]: error getting information about ' Feb 2 13:00:06 cabildo gdm-smartcard]: pam_unix(gdm-smartcard:account): could not identify user (from getpwnam()) Feb 2 13:00:06 cabildo gdm-smartcard]: pam_sss(gdm-smartcard:account): Access denied for user : 10 (User not known to the underlying authentication module) Feb 2 13:00:06 cabildo gdm-smartcard]: pam_krb5[5152]: error resolving user name '' to uid/gid pair Feb 2 13:00:13 cabildo gdm-smartcard]: pam_pkcs11(gdm-smartcard:auth): pam_get_pwd() failed: Conversation error Where do I go from here? *Michael Rainey* NRL 7320 Computer Support Group Building 1009, Room C156 Stennis Space Center, MS 39529 On 02/02/2016 09:56 AM, Martin Kosek wrote: On 02/02/2016 04:49 PM, Michael Rainey (Contractor) wrote: Greetings FreeIPA Community, I have been testing and working with the smart card login feature of the IPA server, and have had some successes with this project. However, my latest server/client setup isn't working as expected. I can where the problem is occurring, which is the Common Name on the Card is not being mapped to the proper attribute on the IPA server. So here's my question: Is there a howto which explains how an where this mapping occurs? Is this something I can configure myself, or is hard coded. At the moment, the Smart Card support present in SSSD looks up the user by searching with a blob containing the whole SC certificate. This BTW means that the certificate needs to be present at user entry in FreeIPA to make sure it matches, no other mapping mechanism is available yet. We have some plans though: http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping If you are interested in HOWTOs, Nathan Kinder put together pretty neat blog posts how to make Smart Card authentication working: http://www.freeipa.org/page/V4/User_Certificates#References HTH, Martin -- 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] FreeIPA for securing Hadoop clusters
Greetings FreeIPA Community, For the past few months, we have been working on securing our Hadoop clusters at eBay using FreeIpa. We have been using Microsoft AD and we are replacing it with FreeIpa. Hadoop uses Kerberos, Ldap, certificates and secret keys for security. FreeIPA is a good fit. We are developing automation scripts and some services for integrating Hadoop with FreeIpa, which we plan to opensource once it is ready. We like to share our experience and lessons learned in the upcoming Hadoop Summit. Please support us by voting for our topic at https://hadoopsummit.uservoice.com/forums/344958-governance-and-security/suggestions/11664876-freeipa-for-securing-hadoop-fish cheers, Benoy Antony -- 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] FreeIPA Consistency Checker
Hi, I just wanted to share a little script that I've created to check consistency across FreeIPA servers. https://github.com/peterpakos/ipa_check_consistency I hope you will like it. Please note, it's been tested only with FreeIPA 4.2 (Centos 7.2) so I'm not sure if it works with other versions. Please feel free to try it and if you have any improvement ideas then log them via GitHub. Thanks. -- Kind regards, Peter Pakos -- 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] "Installing the client"
In the docs, there is a section called "Installing the client". https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#setting-up-clients The very first step contains language that is not explained. "For a regular user system" has one install method, and "An administrator machine" has another. There is no indication what an administrator machine might be used for - is this a replica? Is it a system that can run ipa commands on behalf of the ipa-server? What is the difference between a regular user system and an administrator machine? Cheers L. This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. -- 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] PKINIT support in FreeIPA 4.2.0
Hello, I installed ipa-server on Centos 7.1 and later did and upgrade of the whole system to Centos 7.2. I think the FreeIPA version changed from 4.1.0 to 4.2.0 between these Centos/RHEL minor releases. We'd now like to try integrating with a 2FA provider via a radius proxy and want to use anonymous PKINIT to secure the initial communications between the client and the KDC. We've tried following the MIT Kerberos PKINIT configuration documentation http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html generating our own certs manually with openssl but haven't had any luck. We're seeing this in the kdc log: preauth pkinit failed to initialize: No realms configured correctly for pkinit support I've noticed there are many new pkinit-related options that have been added to the ipa-server-install script in 4.2.0, so it looks like PKINIT is available in this version of FreeIPA. Is that the case? And if it is, what is the recommended way to enable it given that it seems to have been disabled in the original install that I did? Or would it just be easier to start from scratch with a 4.2.0 ipa-server-install? (It's a test instance that doesn't have too much in it - it will take a several hours to rebuild from scratch.) Regards, Nik -- 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] Obtaining certificate private keys for Apache/etc.
I've been doing some reading and perhaps I'm confusing myself, but I couldn't find any definitive guide on how to go about doing what I think it a pretty simple thing. My ipa-client installs appear to generate a new TLS/SSL/PKI cert for each host when they are registered. I'd like to utilize that certificate with Apache/tomcat/etc.. I'm aware of how to obtain the certificate itself, however I'm not clear on how to obtain the private key (in a format that I can use as well) that was used to generate the certificate. Would someone kindly point me in the right direction or ideally just educate me on the command/options needed to do this. In particular, I'm looking to create pem files for both the key and cert for use with Apache, but it would be useful to understand how to do it for other stores as well. (Hint: this would be great to just have in a document that makes it clear). :) Thanks again to the freeipa team. I love this product. -- Chris -- 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] "Installing the client"
On Tue, 02 Feb 2016, Simpson Lachlan wrote: In the docs, there is a section called "Installing the client". https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#setting-up-clients The very first step contains language that is not explained. "For a regular user system" has one install method, and "An administrator machine" has another. There is no indication what an administrator machine might be used for - is this a replica? Is it a system that can run ipa commands on behalf of the ipa-server? What is the difference between a regular user system and an administrator machine? If you want to administer IPA from the command line, you need to install IPA command line tools. This is what it calls as 'administrator machine'. For a regular client system you wouldn't be running 'ipa' command, thus installing ipa-admintools is not needed. I agree it is a bit terse there so it might be a good idea to file a documentation bug against 'ipa' component of RHEL 7. -- / 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] Joining a host
Hola, Presuming a regular machine, I've started the join as per instructions: yum install ipa-client [root@vmts-linux1 ~]# ipa-client-install Error checking LDAP: Operations error: 04DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1 Discovery was successful! Client hostname: vmts-linux1.unix.example.org Realm: UNIX.EXAMPLE.ORG DNS Domain: unix.example.org IPA Server: dc1.example.org BaseDN: dc=unix,dc=example,dc=org There are two things here that I'd like to understand. 1. There was an error, but the process seems to have been successful? Should I be investigating that error or is it to be expected? 2. The IPA server is wrong - the machine it has found the PDC server (with a one way trust IPA->AD), but not the IPA server. I can only presume this is in error and that I should run the command again explicitly stating the IPA server? Cheers L. This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. -- 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] Obtaining certificate private keys for Apache/etc.
I wrote the following guide for sysadmins at my university in an attempt to coalesce in one place what I consider to be the good practices for X.509 certificate management using OpenSSL. I've included examples on how to load private keys, end-entity certificates and intermediate certificates into alternate trust stores (PKCS for IIS and JKS for Java). https://confluence.id.ubc.ca:8443/display/ITSecurity/how+to+obtain%2C+deploy+and+verify+an+X.509+certificate Let me know if you have suggestions for improvement. -- Luca Filipozzi, UBC IT Enterprise Architecture On Feb 2, 2016, at 15:43, Christopher Young> wrote: I've been doing some reading and perhaps I'm confusing myself, but I couldn't find any definitive guide on how to go about doing what I think it a pretty simple thing. My ipa-client installs appear to generate a new TLS/SSL/PKI cert for each host when they are registered. I'd like to utilize that certificate with Apache/tomcat/etc.. I'm aware of how to obtain the certificate itself, however I'm not clear on how to obtain the private key (in a format that I can use as well) that was used to generate the certificate. Would someone kindly point me in the right direction or ideally just educate me on the command/options needed to do this. In particular, I'm looking to create pem files for both the key and cert for use with Apache, but it would be useful to understand how to do it for other stores as well. (Hint: this would be great to just have in a document that makes it clear). :) Thanks again to the freeipa team. I love this product. -- Chris -- 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
[Freeipa-users] DNS Dynamic Update Failing
Hi All, I've run into a frustrating issue regarding DNS Dynamic Updating. In a nutshell: If I enroll a new client when the forward policy on a dns zone is set to "disabled" I don't have a problem enrolling the client and updating the dns record. However if the policy of the zone is set to "only" or "first", nsupdate fails during the client install. Install logs says nsupdate: Specified Zone 'example.com' does not exist (NXDOMAIN). I'm seeing this in multiple zones, and all I need to change to fix it is to change the forwarding policy. However it's problematic as we start the rollout, since we will need to rely on external dns until we have all servers enrolled. Client Install Log Snippet: 2016-02-02T22:53:17Z DEBUG args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt 2016-02-02T22:53:17Z DEBUG stdout= 2016-02-02T22:53:17Z DEBUG stderr=specified zone 'dev.example.net' does not exist (NXDOMAIN) specified zone 'dev.example.net' does not exist (NXDOMAIN) Zone Configuration: [admin@ipa01 ~]$ ipa dnszone-show --all Zone name: dev.example.net dn: idnsname=dev.example.net,cn=dns,dc=example,dc=com Zone name: dev.example.net Authoritative nameserver: ipa01 Administrator e-mail address: hostmaster.dev.example.net. SOA serial: 1454447236 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant EXAMPLE.COM krb5-self * A; grant EXAMPLE.COM krb5-self * ; grant EXAMPLE.COM krb5-self * SSHFP; Active zone: TRUE Dynamic update: TRUE Allow query: any; Allow transfer: none; Zone forwarders: 8.8.8.8 Forward policy: only nsrecord: ipa01, ipa02 objectclass: top, idnsrecord, idnszone Any ideas on how to remedy this? I'd like to avoid updating records by hand if it can be avoided. Thanks! Josh -- 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] User mapping between domains
> -Original Message- > From: Simpson Lachlan > > and that via the ID Views Default Trust View the IPA server would: > - see that jsmith is "Smith Jane" in AD > - authenticate against "Smith Jane"'s AD password > - see that jsmith's uid now needs to be 1500 instead of 17890983 > - see that jsmith's home should be /home/jsmith, creating this dir if it > doesn't exist > - see that jsmith's shell is /bin/bash I should add: - how do I clear the SSSD cache on client hosts when details change upstream? - the documentation mentioned - http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust#How_to_Test - indicates that after applying an override via command line like: ipa idoverrideuser-add 'Default Trust View' testu...@tbad.idm.lab.eng.brq.redhat.com --uid we need to follow this up with a restart of SSSD. I've not known this to be sufficient. I cannot give a "sufficient" way to make this override stick - "magic hand waving" that has worked for me includes: restarting SSSD twice, rebooting the IPA server, and sometimes it seems that after a . Am I missing something? Cheers L. Details: Centos 7.2 sssd-common-1.13.0-40.el7_2.1.x86_64 sssd-ad-1.13.0-40.el7_2.1.x86_64 sssd-1.13.0-40.el7_2.1.x86_64 python-sssdconfig-1.13.0-40.el7_2.1.noarch sssd-krb5-common-1.13.0-40.el7_2.1.x86_64 sssd-ipa-1.13.0-40.el7_2.1.x86_64 sssd-ldap-1.13.0-40.el7_2.1.x86_64 sssd-proxy-1.13.0-40.el7_2.1.x86_64 sssd-client-1.13.0-40.el7_2.1.x86_64 sssd-common-pac-1.13.0-40.el7_2.1.x86_64 sssd-krb5-1.13.0-40.el7_2.1.x86_64 cheers L. This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. -- 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] User mapping between domains
IPA is successfully installed, a one way trust created, and we have been able to login using AD credentials. For future googler's, there is some bare bones documentation on how to allow AD users to login to your system, under the heading "Allow access for users from AD domain to protected resources" http://www.freeipa.org/page/Active_Directory_trust_setup#Configure_IPA_server_for_cross-realm_trusts I can confirm this works for a one directional trust (IPA trusts AD), since that is what we have. Question/Issue: Currently I have two logins, one in the AD domain and one on each server in the IPA domain. The desire is to close that gap. We were under the impression that, utilising idoverrideuser, that we could map AD's "Smith Jane"@example.org (or EXAMPLE\Jane Smith; yes I know our AD logins have spaces in them, it's a technical debt that has no solution roadmap within the org) to jsm...@unix.example.org (which we would set up in IPA), and be able to override certain aspects, like: - instead of using the clumsy ssh "Smith Jane"@example@host1.unix.example.org to login to a system, we could use: ssh jsm...@host1.unix.example.org and that via the ID Views Default Trust View the IPA server would: - see that jsmith is "Smith Jane" in AD - authenticate against "Smith Jane"'s AD password - see that jsmith's uid now needs to be 1500 instead of 17890983 - see that jsmith's home should be /home/jsmith, creating this dir if it doesn't exist - see that jsmith's shell is /bin/bash Am I merely imagining that this is possible? My information came from various blog posts on the RH blog that suggested such a thing was possible, and this post on the FreeIPA site: http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust#ID_Views Given the above use case, can I please get advice on: - is there a preferred order in which IPA user (jsm...@unix.example.org) is created and AD user (EXAMPLE\Smith Jane) has their ID Views Default Trust View entry created? - for the creation of homedir on login, does this need to be done per host, via ipa-client-install's --mkhomedir option rather than per user? Have I missed something? Cheers L. This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. -- 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] [Centos7.2 Freeipa 4.2] browser : your session has expired
On Tue, 02 Feb 2016, Christopher Lamb wrote: Hi Petr I get exactly the same behaviour ever so often. We are running IPA server 4.2.0 15.0.1.el7_2.3, (though we got the same problem with earlier releases too). In my case the laptop running Firefox / FreeIPA WebUI, and the OEL Server running the IPA server have time within seconds / milliseconds of one another. The server uses NTPD (and has full missile lock on the NTP pool servers), and the laptop uses whatever OSX uses to keep time accurate. As I only need to use the FreeIPA WebUI rarely (every few months or so) the exact behaviour is difficult to pin down. It seems to work like this: a) I will sometimes have access without the "your session has expired" error. Typically this is when I have not used FreeIPA for a long time (months). b) then some days later, when I revisit the WebUI, the "your session has expired" error will crop up. c) as I have access to several workstations, each with several browsers installed (IE, FF, Chrome, Safari etc.), I may get luck and find one that does not give the error (while the others do). Just like the OP, the workstations are not FreeIPA hosts (or servers), and we use login /pw for the WebUI. Can you hit ctrl+shift+I in Firefox (open development console), select 'Network' tab there, hit reload, and explore the requests/responses there when the error is manifested. Unfortunately, there is no way to copy out the whole traffic but you can at least make screenshots. This approach allows you to see what's happening inside the communication without need to decode SSL traffic in Wireshark. -- / 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] [Centos7.2 Freeipa 4.2] browser : your session has expired
From: Alexander BokovoyTo: Christopher Lamb/Switzerland/IBM@IBMCH Cc: Petr Vobornik , freeipa-users@redhat.com, wodel youchi Date: 02.02.2016 09:32 Subject:Re: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your session has expired On Tue, 02 Feb 2016, Christopher Lamb wrote: > >Hi Petr > >I get exactly the same behaviour ever so often. We are running IPA server >4.2.0 15.0.1.el7_2.3, (though we got the same problem with earlier releases >too). > >In my case the laptop running Firefox / FreeIPA WebUI, and the OEL Server >running the IPA server have time within seconds / milliseconds of one >another. The server uses NTPD (and has full missile lock on the NTP pool >servers), and the laptop uses whatever OSX uses to keep time accurate. > >As I only need to use the FreeIPA WebUI rarely (every few months or so) the >exact behaviour is difficult to pin down. It seems to work like this: > >a) I will sometimes have access without the "your session has expired" >error. Typically this is when I have not used FreeIPA for a long time >(months). > >b) then some days later, when I revisit the WebUI, the "your session has >expired" error will crop up. > >c) as I have access to several workstations, each with several browsers >installed (IE, FF, Chrome, Safari etc.), I may get luck and find one that >does not give the error (while the others do). > >Just like the OP, the workstations are not FreeIPA hosts (or servers), and >we use login /pw for the WebUI. Can you hit ctrl+shift+I in Firefox (open development console), select 'Network' tab there, hit reload, and explore the requests/responses there when the error is manifested. Unfortunately, there is no way to copy out the whole traffic but you can at least make screenshots. This approach allows you to see what's happening inside the communication without need to decode SSL traffic in Wireshark. -- / 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] ca install fails upgrading to 4.2.0
On 02/02/2016 02:18 AM, Robert van Veelen wrote: > Hi, > I'm trying to create an ipa replica from > ipa-server-3.0.0-47/pki-ca-9.0.3-45 to ipa-server-4.2.0-15/pki-ca-10.2.5-6 > and cannot get the install to complete. The CS is configured as a sub to an > external CA. I keep getting the same error when running the > replica-install. Digging into pki-ca's debug log, I find the following > errors: > > java.lang.Exception: SystemCertsVerification: system certs verification > failure > & > CertUtils: verifySystemCertByNickname() failed: caSigningCert cert-pki-ca > > I've tried regenerating the source cacert.p12, upgrading pki-ca to latest, > etc. It just seems like the new replica is unable to verify the certs while > running selftests. any good tips for a next step to work out whats going on? > > Thanks, > > -rob Can this be the same problem as answered by Endi here: https://www.redhat.com/archives/freeipa-users/2016-January/msg00564.html ? -- 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] [Centos7.2 Freeipa 4.2] browser : your session has expired
The 401 after successful 200 is an issue with session which to browser looks as expired session. Please examine cookie headers of both the 'login_password' and the subsequent 'json' request (as written in the other mail). On 02/02/2016 09:40 AM, Christopher Lamb wrote: From: Alexander BokovoyTo: Christopher Lamb/Switzerland/IBM@IBMCH Cc: Petr Vobornik , freeipa-users@redhat.com, wodel youchi Date: 02.02.2016 09:32 Subject:Re: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your session has expired On Tue, 02 Feb 2016, Christopher Lamb wrote: Hi Petr I get exactly the same behaviour ever so often. We are running IPA server 4.2.0 15.0.1.el7_2.3, (though we got the same problem with earlier releases too). In my case the laptop running Firefox / FreeIPA WebUI, and the OEL Server running the IPA server have time within seconds / milliseconds of one another. The server uses NTPD (and has full missile lock on the NTP pool servers), and the laptop uses whatever OSX uses to keep time accurate. As I only need to use the FreeIPA WebUI rarely (every few months or so) the exact behaviour is difficult to pin down. It seems to work like this: a) I will sometimes have access without the "your session has expired" error. Typically this is when I have not used FreeIPA for a long time (months). b) then some days later, when I revisit the WebUI, the "your session has expired" error will crop up. c) as I have access to several workstations, each with several browsers installed (IE, FF, Chrome, Safari etc.), I may get luck and find one that does not give the error (while the others do). Just like the OP, the workstations are not FreeIPA hosts (or servers), and we use login /pw for the WebUI. Can you hit ctrl+shift+I in Firefox (open development console), select 'Network' tab there, hit reload, and explore the requests/responses there when the error is manifested. Unfortunately, there is no way to copy out the whole traffic but you can at least make screenshots. This approach allows you to see what's happening inside the communication without need to decode SSL traffic in Wireshark. -- / Alexander Bokovoy -- Petr Vobornik -- 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] Fw: [Centos7.2 Freeipa 4.2] browser : your session has expired
On 02/02/2016 09:49 AM, Christopher Lamb wrote: > > > Sorry, Notes is playing up, and sent the last before I could type any text! > > The POST /ipa/session/login_password is successful. > > but the POST /ipa/session/json and GET /ipa/session/login_kerberos both > give 401 unathorized > > Chris Just to make sure we have covered all possible pit holes we have already gathered on our Troubleshooting page, did check all the advise in this list http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI ? -- 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] [Centos7.2 Freeipa 4.2] browser : your session has expired
Hi Petr I get exactly the same behaviour ever so often. We are running IPA server 4.2.0 15.0.1.el7_2.3, (though we got the same problem with earlier releases too). In my case the laptop running Firefox / FreeIPA WebUI, and the OEL Server running the IPA server have time within seconds / milliseconds of one another. The server uses NTPD (and has full missile lock on the NTP pool servers), and the laptop uses whatever OSX uses to keep time accurate. As I only need to use the FreeIPA WebUI rarely (every few months or so) the exact behaviour is difficult to pin down. It seems to work like this: a) I will sometimes have access without the "your session has expired" error. Typically this is when I have not used FreeIPA for a long time (months). b) then some days later, when I revisit the WebUI, the "your session has expired" error will crop up. c) as I have access to several workstations, each with several browsers installed (IE, FF, Chrome, Safari etc.), I may get luck and find one that does not give the error (while the others do). Just like the OP, the workstations are not FreeIPA hosts (or servers), and we use login /pw for the WebUI. Chris From: Petr VobornikTo: wodel youchi , Alexander Bokovoy Cc: freeipa-users@redhat.com Date: 02.02.2016 08:48 Subject:Re: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your session has expired Sent by:freeipa-users-boun...@redhat.com On 01/31/2016 09:49 AM, wodel youchi wrote: > Hi, > > I miss explained myself apparently, here it is: > > I open a session with login/password, I do some work, I left it for a > while, the session disconnects which is normal. > I come back, I try to authenticate with login/password it keeps telling me > : your session has expired. > > Regards. Is there a time difference between a machine with browser and an IPA server? > > 2016-01-30 17:54 GMT+01:00 Alexander Bokovoy : > >> >> >> - Original Message - >>> Hi, >>> >>> When accessing the webui of Freeipa from the browser using login >> password, I >>> get your session has expired. >>> >>> >>> As a workaround I have to either : >>> - Delete the https certificate of the ipa server from the browser and >> delete >>> history then relogin again. >>> - Restart ipa services : ipactl restart >> - delete cookies in the browser corresponding to IPA server. >> >>> PS: The machine I am using to connect to the webui of freeipa is not >> enrolled >>> in it, I am using login/pass to connect not kerberos. >> Web UI session is set to 30 minutes or so. >> >> -- >> / Alexander Bokovoy >> > > > -- Petr Vobornik -- 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] [Centos7.2 Freeipa 4.2] browser : your session has expired
On 02/02/2016 09:14 AM, Christopher Lamb wrote: Hi Petr I get exactly the same behaviour ever so often. We are running IPA server 4.2.0 15.0.1.el7_2.3, (though we got the same problem with earlier releases too). In my case the laptop running Firefox / FreeIPA WebUI, and the OEL Server running the IPA server have time within seconds / milliseconds of one another. The server uses NTPD (and has full missile lock on the NTP pool servers), and the laptop uses whatever OSX uses to keep time accurate. As I only need to use the FreeIPA WebUI rarely (every few months or so) the exact behaviour is difficult to pin down. It seems to work like this: a) I will sometimes have access without the "your session has expired" error. Typically this is when I have not used FreeIPA for a long time (months). b) then some days later, when I revisit the WebUI, the "your session has expired" error will crop up. c) as I have access to several workstations, each with several browsers installed (IE, FF, Chrome, Safari etc.), I may get luck and find one that does not give the error (while the others do). Just like the OP, the workstations are not FreeIPA hosts (or servers), and we use login /pw for the WebUI. It does not matter if the workastation is FreeIPA host when login /pw is used. When it happens, could you examine Set-Cookie response header of login_password request and its response in browser developer tools. It would be good to find out if the response is successful(200) and what is the cookie expiration date. If it's not successful, then what is in response and in X-IPA-Rejection-Reason response header. https://pvoborni.fedorapeople.org/images/ff-dev-tools-xhr.png Chris From: Petr VobornikTo: wodel youchi , Alexander Bokovoy Cc: freeipa-users@redhat.com Date: 02.02.2016 08:48 Subject:Re: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your session has expired Sent by:freeipa-users-boun...@redhat.com On 01/31/2016 09:49 AM, wodel youchi wrote: Hi, I miss explained myself apparently, here it is: I open a session with login/password, I do some work, I left it for a while, the session disconnects which is normal. I come back, I try to authenticate with login/password it keeps telling me : your session has expired. Regards. Is there a time difference between a machine with browser and an IPA server? 2016-01-30 17:54 GMT+01:00 Alexander Bokovoy : - Original Message - Hi, When accessing the webui of Freeipa from the browser using login password, I get your session has expired. As a workaround I have to either : - Delete the https certificate of the ipa server from the browser and delete history then relogin again. - Restart ipa services : ipactl restart - delete cookies in the browser corresponding to IPA server. PS: The machine I am using to connect to the webui of freeipa is not enrolled in it, I am using login/pass to connect not kerberos. Web UI session is set to 30 minutes or so. -- / Alexander Bokovoy -- Petr Vobornik -- 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 -- Petr Vobornik -- 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-users] Problem managing Autofs with FreeIPA
On Mon, Feb 01, 2016 at 04:11:32PM -0600, Jon wrote: > Hello, > > I am attempting to configure autofs to automount home directories from an > NFS server. > > I'm following these instructions as this was the only contiguous "here's > what you need to do" instructions as the FreeIPA and Fedora documentation > seems to contradict itself, and there's no clear cut a. then b. then c. > (Admittedly, this is my first foray into managing home dirs this way, so > I'm learning all around :) but I need a bit of direction...) > > First things first, can anyone confirm these directions are correct please? > > > http://blog.delouw.ch/2015/03/14/using-ipa-to-provide-automount-maps-for-nfsv4-home-directories/ > > I'm going to assume they are for the purposes of the rest of the post. > > I'm currently working with three servers: > freeipa01 - The FreeIPA server > home-dir01 - The Home directory NFS server > ipa-test01 - My test server where I'm making changes/trying to mount the > home directory. > > ipa-test01 is the only CentOS 6.5 machine (no choice, it's the "production > blessed" image), freeipa01 and home-dir01 are both CentOS7. > > Following those above linked instructions, I have created the following > autmount configurations: > > Automount Configuration: > >> [root@ipa-test01 ~]# ipa automountlocation-find > >> > >> 1 automount location matched > >> > >> Location: default > >> > >> Number of entries returned 1 > >> > >> > >> [root@ipa-test01 ~]# ipa automountmap-find > >> Location: default > >> > >> 3 automount maps matched > >> > >> Map: auto.direct > >> > >> Map: auto.home > >> > >> Map: auto.master > >> > >> Number of entries returned 3 > >> > >> > >> [root@ipa-test01 ~]# ipa automountkey-find default auto.home > >> --- > >> 1 automount key matched > >> --- > >> Key: * > >> Mount information: -fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192 > home-dir01.sub.domain.mydomain.com:/exports/home/& > >> > >> Number of entries returned 1 > >> > > Exports configuration: > > >> [root@home-dir01 home]# cat /etc/exports > >> /exports/home *(rw,no_root_squash,sec=sys:krb5:krb5i:krb5p) > > > > At some point I generated this error. I have been unable to reproduce > it... Included for completeness of my reporting but I don't think it's > currently an issue. > > >> Feb 1 15:43:19 ipa-test01 rpc.gssd[1371]: ERROR: No credentials found > for connection to server home-dir01.sub.domain.mydomain.com > > > Without an entry in /etc/hosts I receive the following error when > attempting to login as my domain user: > > >> Feb 1 16:22:13 ipa-test01 kernel: type=1105 audit(1454361733.209:125): > user pid=1777 uid=0 auid=0 ses=1 msg='op=PAM:session_open acct=" > j...@mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? > terminal=/dev/pts/0 res=success' > >> Feb 1 16:22:22 ipa-test01 rpc.gssd[1371]: ERROR: unable to resolve > 2605:1c00:50f2:300a::56ff::442a to hostname: Temporary failure in > name resolution > >> Feb 1 16:22:22 ipa-test01 rpc.gssd[1371]: ERROR: failed to read service > info > >> Feb 1 16:22:22 ipa-test01 rpc.gssd[1371]: ERROR: unable to resolve > 192.168.10.250 to hostname: Name or service not known > >> Feb 1 16:22:22 ipa-test01 rpc.gssd[1371]: ERROR: failed to read service > info > > > So I added the entry in /etc/hosts for my nfs server (will fix in DNS, but > we use 3rd party DNS service that is not integrated with AD...), I get the > following error (repeated attempts to sudo), note the "res=success" > > >> ipa-test01:/var/log/messages > >> Feb 1 16:16:38 ipa-test01 kernel: __ratelimit: 90 callbacks suppressed > >> Feb 1 16:16:38 ipa-test01 kernel: type=1123 audit(1454361398.936:92): > user pid=1632 uid=0 auid=0 ses=1 msg='cwd="/root" cmd="-sh" terminal=pts/0 > res=success' > >> Feb 1 16:16:38 ipa-test01 kernel: type=1103 audit(1454361398.936:93): > user pid=1632 uid=0 auid=0 ses=1 msg='op=PAM:setcred acct="j...@mydomain.com" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' > >> Feb 1 16:16:38 ipa-test01 kernel: type=1105 audit(1454361398.943:94): > user pid=1632 uid=0 auid=0 ses=1 msg='op=PAM:session_open acct=" > j...@mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? > terminal=/dev/pts/0 res=success' > >> Feb 1 16:16:38 ipa-test01 kernel: type=1106 audit(1454361398.944:95): > user pid=1632 uid=0 auid=0 ses=1 msg='op=PAM:session_close acct=" > j...@mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? > terminal=/dev/pts/0 res=success' > >> Feb 1 16:16:38 ipa-test01 kernel: type=1104 audit(1454361398.944:96): > user pid=1632 uid=0 auid=0 ses=1 msg='op=PAM:setcred acct="j...@mydomain.com" > exe="/usr/bin/sudo"
Re: [Freeipa-users] Sudo privilege inheritance in FreeIPA (3.0.x branch)
On Wed, Jan 27, 2016 at 09:36:13AM -0700, sysadmin ofdoom wrote: > I am trying to implement FreeIPA in a larger environment. Due to the > complexity of the environment I've been constructing a user group structure > such that i have groups at the following levels: > > project --> project_at_site --> project_site_vendor I'm not sure the order of the hierarchy is correct, can you show an example with ipa group-show? > > HBAC rules are defined at the lowest level (vendor at site) and associated > with a host group at the same level. > > Each of the above user group levels will have a corresponding sudo group. > (Used to provide a vendor access to servers the vendor supports at a > specific site at a moments notice) > > HBAC rules are propagating up the chain correctly. > > When a user is added to a top level group (e.g. project or project-sudo) > the indirect membership shows up for both Sudo and HBAC rules. > > The problem is that I can't get the sudo privileges to work when the user > shows indirect membership for the sudo rule. If i make the user a direct > member of the sudo rule, i can use sudo. > > As I've looked at debug logs, i was able to see that the query used when i > was identical when i was successful at using sudo and when i i got denied. > The difference is the failure would have a message like > [sudosrv_get_sudorules_from_cache] (0x0400): Returning 1 rules for [ > u...@example.com] The successes returned 2 rules. > > The only change made between the success and failure was making the user a > direct member of the sudo rule where the failure was an indirect member. > > Thanks for any help! sudo uses the list of groups as returned by initgroups()/getgrouplist(), so if the user is a member of that group (as reported by id $user), then the sudo rule should match. -- 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] Fw: [Centos7.2 Freeipa 4.2] browser : your session has expired
Sorry, Notes is playing up, and sent the last before I could type any text! The POST /ipa/session/login_password is successful. but the POST /ipa/session/json and GET /ipa/session/login_kerberos both give 401 unathorized Chris - Forwarded by Christopher Lamb/Switzerland/IBM on 02.02.2016 09:46 - From: Christopher Lamb/Switzerland/IBM@IBMCH To: Alexander BokovoyCc: freeipa-users@redhat.com Date: 02.02.2016 09:42 Subject:Re: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your session has expired Sent by:freeipa-users-boun...@redhat.com Inactive hide details for Alexander Bokovoy ---02.02.2016 09:32:00---On Tue, 02 Feb 2016, Christopher Lamb wrote: >Alexander Bokovoy ---02.02.2016 09:32:00---On Tue, 02 Feb 2016, Christopher Lamb wrote: > From: Alexander Bokovoy To: Christopher Lamb/Switzerland/IBM@IBMCH Cc: Petr Vobornik , freeipa-users@redhat.com, wodel youchi Date: 02.02.2016 09:32 Subject: Re: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your session has expired On Tue, 02 Feb 2016, Christopher Lamb wrote: > >Hi Petr > >I get exactly the same behaviour ever so often. We are running IPA server >4.2.0 15.0.1.el7_2.3, (though we got the same problem with earlier releases >too). > >In my case the laptop running Firefox / FreeIPA WebUI, and the OEL Server >running the IPA server have time within seconds / milliseconds of one >another. The server uses NTPD (and has full missile lock on the NTP pool >servers), and the laptop uses whatever OSX uses to keep time accurate. > >As I only need to use the FreeIPA WebUI rarely (every few months or so) the >exact behaviour is difficult to pin down. It seems to work like this: > >a) I will sometimes have access without the "your session has expired" >error. Typically this is when I have not used FreeIPA for a long time >(months). > >b) then some days later, when I revisit the WebUI, the "your session has >expired" error will crop up. > >c) as I have access to several workstations, each with several browsers >installed (IE, FF, Chrome, Safari etc.), I may get luck and find one that >does not give the error (while the others do). > >Just like the OP, the workstations are not FreeIPA hosts (or servers), and >we use login /pw for the WebUI. Can you hit ctrl+shift+I in Firefox (open development console), select 'Network' tab there, hit reload, and explore the requests/responses there when the error is manifested. Unfortunately, there is no way to copy out the whole traffic but you can at least make screenshots. This approach allows you to see what's happening inside the communication without need to decode SSL traffic in Wireshark. -- / 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 -- 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 client in DMZ
On Tue, Feb 02, 2016 at 02:12:58PM +, Baird, Josh wrote: > I believe the sssd clients will need to communicate directly with your AD > domain controllers, unfortunately. I wish there was a clean way around this, > since we have a ton of DC's in our HUB site, and I don't really want to poke > holes in the firewall(s) for all of them. > > Would someone from sssd/IPA mind chiming in here? What exactly needs to be > open? What DNS record can we query to get the exact list of DC's that need > to be available? Is there a way to restrict the list of domain controllers > that certain sssd clients need to communicate with (for scenarios like this)? The clients only need to communicate with AD during authentication and only for password authentication. Since the authentication is Kerberos based port 88 should be open and although typically it is sufficient for Kerberos to use UDP in the AD case we need TCP as well because AD Kerberos tickets are too large for UDP due to the PAC data in the ticket. If you want to allow password changes you have to open port 749 as well. For the trusted domain SSSD delegates everything including finding a suitable KDC to libkrb5. If 'dns_lookup_kdc = true' and no realm definition is available for the AD domain in /etc/krb5.conf libkrb5 will do a SRV query for _kerberos._tcp.ad.domain (no sites or other AD specific options). If you want to restrict the AD servers the clients want to talk and keep the holes in the firewall small I would suggest to add the AD realms to /etc/krb5.conf which only contains the KDC the clients should talk to. HTH bye, Sumit > > Thanks, > > Josh > > > -Original Message- > > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- > > boun...@redhat.com] On Behalf Of Andy Thompson > > Sent: Tuesday, February 02, 2016 9:04 AM > > To: freeipa-users@redhat.com > > Subject: [Freeipa-users] freeipa client in DMZ > > > > Are ports required to be open for a freeipa client in a DMZ to the AD DCs > > for > > trusted users to login? I've got everything open to the IPA servers > > required > > and can lookup users and sudo rules and such but trusted users are not able > > to login. > > > > Thanks > > > > -andy > > > > > > > > *** This communication may contain privileged and/or confidential > > information. It is intended solely for the use of the addressee. If you are > > not > > the intended recipient, you are strictly prohibited from disclosing, > > copying, > > distributing or using any of this information. If you received this > > communication in error, please contact the sender immediately and destroy > > the material in its entirety, whether electronic or hard copy. *** > > > > > > -- > > 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 -- 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 client in DMZ
> -Original Message- > From: Baird, Josh [mailto:jba...@follett.com] > Sent: Tuesday, February 2, 2016 9:13 AM > To: Andy Thompson; freeipa- > us...@redhat.com > Subject: RE: freeipa client in DMZ > > I believe the sssd clients will need to communicate directly with your AD > domain controllers, unfortunately. I wish there was a clean way around this, > since we have a ton of DC's in our HUB site, and I don't really want to poke > holes in the firewall(s) for all of them. > > Would someone from sssd/IPA mind chiming in here? What exactly needs to > be open? What DNS record can we query to get the exact list of DC's that > need to be available? Is there a way to restrict the list of domain > controllers > that certain sssd clients need to communicate with (for scenarios like this)? > > Thanks, > > Josh > > > -Original Message- > > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- > > boun...@redhat.com] On Behalf Of Andy Thompson > > Sent: Tuesday, February 02, 2016 9:04 AM > > To: freeipa-users@redhat.com > > Subject: [Freeipa-users] freeipa client in DMZ > > > > Are ports required to be open for a freeipa client in a DMZ to the AD > > DCs for trusted users to login? I've got everything open to the IPA > > servers required and can lookup users and sudo rules and such but > > trusted users are not able to login. > > > > Thanks > > > > -andy > > > > Going through my firewall logs it appears kerberos needs opened to the DCs at a minimum although I dropped 464 in there as well. Once I opened that up I was able to authenticate I'm not much of an AD guy so I don't know if there is a way to limit the servers accessed within AD. In my environment I had to setup separate DNS servers for the AD domain due to the environment setup so I could control it that way by removing DC records from that DNS environment. My thought is that it relies on the _kerberos._tcp srv records -andy -- 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 client in DMZ
On Tue, 02 Feb 2016, Baird, Josh wrote: I believe the sssd clients will need to communicate directly with your AD domain controllers, unfortunately. I wish there was a clean way around this, since we have a ton of DC's in our HUB site, and I don't really want to poke holes in the firewall(s) for all of them. There is a way with FreeIPA 4.2+, but you need to have MIT Kerberos 1.13 on the client side. This way all clients will talk to IPA masters and IPA master would serve as Kerberos proxy using MS-KKDCP protocol. Would someone from sssd/IPA mind chiming in here? What exactly needs to be open? What DNS record can we query to get the exact list of DC's that need to be available? Is there a way to restrict the list of domain controllers that certain sssd clients need to communicate with (for scenarios like this)? For normal IPA-AD trust following is needed from IPA clients: - access from IPA client to AD DCs for Kerberos (port 88 TCP/UDP, 464 TCP/UDP) - access from IPA client to IPA master for LDAP (389 TCP), Kerberos (port 88 TCP/UDP, port 464 TCP/UDP) - access from IPA client to your DNS server (53 UDP), whatever that could be There might be other ports too, I don't remember off-hand. If you want to block certain domain controllers from being accessible by IPA clients, make sure you are doing it with rejection so that SSSD and Kerberos library would properly jump to the next discovered AD DC. DNS SRV records often contain all AD DCs and there is no support for sites in Kerberos library to pick up only the local ones, it takes what is given from DNS SRV records (if use of DNS-based discovery is enabled) and tries them one by one. -- / 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] Fw: [Centos7.2 Freeipa 4.2] browser : your session has expired
Hi Martin, Good points Web UI Cannot authenticate to Web UI Make sure that the user can authenticate in CLI, e.g. with kinit $USER --> yes the user can ssh to FreeIPA hosts, and can call kinit without error. Make sure that httpd, dirsrv and ipa_memcached services on the affected FreeIPA server are running. --> httpd, slapd and memcached all running (proved by pgrep -l) Make sure there are no related SELinux AVCs -- SELinux is disabled Make sure that cookies are enabled on the client browser --> enabled Make sure that the time on the FreeIPA server is up to date and there is no (significant) clock skew (freeipa-users thread) --> no clock skew Search for any related errors in /var/log/httpd/error_log --> no errors today Chris From: Martin KosekTo: Christopher Lamb/Switzerland/IBM@IBMCH, freeipa-users@redhat.com Cc: Alexander Bokovoy Date: 02.02.2016 09:53 Subject:Re: [Freeipa-users] Fw: [Centos7.2 Freeipa 4.2] browser : your session has expired On 02/02/2016 09:49 AM, Christopher Lamb wrote: > > > Sorry, Notes is playing up, and sent the last before I could type any text! > > The POST /ipa/session/login_password is successful. > > but the POST /ipa/session/json and GET /ipa/session/login_kerberos both > give 401 unathorized > > Chris Just to make sure we have covered all possible pit holes we have already gathered on our Troubleshooting page, did check all the advise in this list http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI ? -- 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] OTP
Hi all, I' m trying to enable OTP: - Enabled "Two factor authentication (password + OTP)" for a particular user. - Added a OTP token, FreeOTP on an Android that is, for the user which all went fine. Trying to login will fail. After several attempts, systemctl --failed will tell: UNIT LOAD ACTIVE SUB DESCRIPTION * ipa-otpd@0-1642-0.service loaded failed failed ipa-otpd service (PID 1642/UID 0) * ipa-otpd@1-1642-0.service loaded failed failed ipa-otpd service (PID 1642/UID 0) * ipa-otpd@10-1642-0.service loaded failed failed ipa-otpd service (PID 1642/UID 0) * ipa-otpd@11-1642-0.service loaded failed failed ipa-otpd service (PID 1642/UID 0) * ipa-otpd@12-1642-0.service loaded failed failed ipa-otpd service (PID 1642/UID 0) * ipa-otpd@13-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) * ipa-otpd@14-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) * ipa-otpd@15-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) * ipa-otpd@16-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) * ipa-otpd@2-1642-0.service loaded failed failed ipa-otpd service (PID 1642/UID 0) * ipa-otpd@3-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) * ipa-otpd@4-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) * ipa-otpd@5-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) * ipa-otpd@6-1642-0.service loaded failed failed ipa-otpd service (PID 1642/UID 0) * ipa-otpd@7-1642-0.service loaded failed failed ipa-otpd service (PID 1642/UID 0) * ipa-otpd@8-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) * ipa-otpd@9-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 17 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'. Journalctl will tell some more: root@ipa log]# journalctl -f -u ipa-otpd@9-1643-0.service -- Logs begin at Fri 2016-01-29 10:14:55 CET. -- Feb 02 11:03:19 ipa.blabla.bla systemd[1]: ipa-otpd@9-1643-0.service: Main process exited, code=exited, status=1/FAILURE Feb 02 11:03:19 ipa.blabla.bla systemd[1]: ipa-otpd@9-1643-0.service: Unit entered failed state. Feb 02 11:03:19 ipa.blabla.bla systemd[1]: ipa-otpd@9-1643-0.service: Failed with result 'exit-code'. Feb 02 11:04:31 ipa.blabla.bla systemd[1]: Started ipa-otpd service (PID 1643/UID 0). Feb 02 11:04:31 ipa.blabla.bla systemd[1]: Starting ipa-otpd service (PID 1643/UID 0)... Feb 02 11:04:31 ipa.blabla.bla ipa-otpd[2924]: LDAP: ldapi://%2fvar%2frun%2fslapd-BLABLA-BLA.socket Feb 02 11:05:23 ipa.blabla.bla ipa-otpd[2924]: stdio.c:073: Invalid argument: Error receiving packet Feb 02 11:05:23 ipa.blabla.bla systemd[1]: ipa-otpd@9-1643-0.service: Main process exited, code=exited, status=1/FAILURE Feb 02 11:05:23 ipa.blabla.bla systemd[1]: ipa-otpd@9-1643-0.service: Unit entered failed state. Feb 02 11:05:23 ipa.blabla.bla systemd[1]: ipa-otpd@9-1643-0.service: Failed with result 'exit-code'. What' s going wrong here? Winny -- 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] ca install fails upgrading to 4.2.0
Unfortunately not. I saw that thread and grabbed the patch and updated spec to give it a try. Same issue. cheers, -rob On Tue, 2 Feb 2016 at 08:46 Martin Kosekwrote: > On 02/02/2016 02:18 AM, Robert van Veelen wrote: > > Hi, > > I'm trying to create an ipa replica from > > ipa-server-3.0.0-47/pki-ca-9.0.3-45 to > ipa-server-4.2.0-15/pki-ca-10.2.5-6 > > and cannot get the install to complete. The CS is configured as a sub to > an > > external CA. I keep getting the same error when running the > > replica-install. Digging into pki-ca's debug log, I find the following > > errors: > > > > java.lang.Exception: SystemCertsVerification: system certs verification > > failure > > & > > CertUtils: verifySystemCertByNickname() failed: caSigningCert > cert-pki-ca > > > > I've tried regenerating the source cacert.p12, upgrading pki-ca to > latest, > > etc. It just seems like the new replica is unable to verify the certs > while > > running selftests. any good tips for a next step to work out whats going > on? > > > > Thanks, > > > > -rob > > Can this be the same problem as answered by Endi here: > https://www.redhat.com/archives/freeipa-users/2016-January/msg00564.html > ? > > -- 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 smart card how to
On 02/02/2016 04:49 PM, Michael Rainey (Contractor) wrote: > Greetings FreeIPA Community, > > I have been testing and working with the smart card login feature of the IPA > server, and have had some successes with this project. However, my latest > server/client setup isn't working as expected. I can where the problem is > occurring, which is the Common Name on the Card is not being mapped to the > proper attribute on the IPA server. So here's my question: Is there a howto > which explains how an where this mapping occurs? Is this something I can > configure myself, or is hard coded. At the moment, the Smart Card support present in SSSD looks up the user by searching with a blob containing the whole SC certificate. This BTW means that the certificate needs to be present at user entry in FreeIPA to make sure it matches, no other mapping mechanism is available yet. We have some plans though: http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping If you are interested in HOWTOs, Nathan Kinder put together pretty neat blog posts how to make Smart Card authentication working: http://www.freeipa.org/page/V4/User_Certificates#References HTH, Martin -- 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] Fw: [Centos7.2 Freeipa 4.2] browser : your session has expired
On 02/02/2016 10:33 AM, Christopher Lamb wrote: > > Hi Martin, > > Good points > > Web UI > Cannot authenticate to Web UI >Make sure that the user can authenticate in CLI, e.g. with kinit $USER >--> yes the user can ssh to FreeIPA hosts, and can call kinit without >error. >Make sure that httpd, dirsrv and ipa_memcached services on the affected >FreeIPA server are running. --> httpd, slapd and memcached all running >(proved by pgrep -l) >Make sure there are no related SELinux AVCs -- SELinux is disabled That made me sad a little, I can only say: http://stopdisablingselinux.com/ :-) >Make sure that cookies are enabled on the client browser --> enabled >Make sure that the time on the FreeIPA server is up to date and there is >no (significant) clock skew (freeipa-users thread) --> no clock skew >Search for any related errors in /var/log/httpd/error_log --> no errors >today Ok, thanks for ruling out the basic issues, I will let Petr and Alexander dive in the others. When we discover the culprit, it would be nice to add it to this list too. > From: Martin Kosek> To: Christopher Lamb/Switzerland/IBM@IBMCH, > freeipa-users@redhat.com > Cc: Alexander Bokovoy > Date: 02.02.2016 09:53 > Subject: Re: [Freeipa-users] Fw: [Centos7.2 Freeipa 4.2] browser : your > session has expired > > > > On 02/02/2016 09:49 AM, Christopher Lamb wrote: >> >> >> Sorry, Notes is playing up, and sent the last before I could type any > text! >> >> The POST /ipa/session/login_password is successful. >> >> but the POST /ipa/session/json and GET /ipa/session/login_kerberos both >> give 401 unathorized >> >> Chris > > Just to make sure we have covered all possible pit holes we have already > gathered on our Troubleshooting page, did check all the advise in this list > > http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI > > ? > > > > -- 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] ca install fails upgrading to 4.2.0
On 02/02/2016 11:51 AM, Robert van Veelen wrote: > Unfortunately not. I saw that thread and grabbed the patch and updated spec > to give it a try. Same issue. > cheers, Ah, pity. Let me CC Endi in this thread then. I suspect he will be interested in the same log files as in the referred thread. > On Tue, 2 Feb 2016 at 08:46 Martin Kosekwrote: > >> On 02/02/2016 02:18 AM, Robert van Veelen wrote: >>> Hi, >>> I'm trying to create an ipa replica from >>> ipa-server-3.0.0-47/pki-ca-9.0.3-45 to >> ipa-server-4.2.0-15/pki-ca-10.2.5-6 >>> and cannot get the install to complete. The CS is configured as a sub to >> an >>> external CA. I keep getting the same error when running the >>> replica-install. Digging into pki-ca's debug log, I find the following >>> errors: >>> >>> java.lang.Exception: SystemCertsVerification: system certs verification >>> failure >>> & >>> CertUtils: verifySystemCertByNickname() failed: caSigningCert >> cert-pki-ca >>> >>> I've tried regenerating the source cacert.p12, upgrading pki-ca to >> latest, >>> etc. It just seems like the new replica is unable to verify the certs >> while >>> running selftests. any good tips for a next step to work out whats going >> on? >>> >>> Thanks, >>> >>> -rob >> >> Can this be the same problem as answered by Endi here: >> https://www.redhat.com/archives/freeipa-users/2016-January/msg00564.html >> ? >> >> > -- 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] Joining realm failed with "SSL certificate problem: self signed certificate in certificate chain"
Found it. The error message on the ipa server (in /var/log/httpd/error_log) was less misleading: SSL Library Error: -12195 Peer does not recognize and trust the CA that issued your certificate After installing the ca-certificates package and adding the root certificate to it the problem was gone. Thanx to everybody Harri -- 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] FreeIPA smart card how to
Greetings FreeIPA Community, I have been testing and working with the smart card login feature of the IPA server, and have had some successes with this project. However, my latest server/client setup isn't working as expected. I can where the problem is occurring, which is the Common Name on the Card is not being mapped to the proper attribute on the IPA server. So here's my question: Is there a howto which explains how an where this mapping occurs? Is this something I can configure myself, or is hard coded. Sincerely, -- *Michael Rainey* -- 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 initialize credentials using keytab [default]" errors on functioning clients
On Tue, Feb 02, 2016 at 04:59:37PM -0800, Terence Kent wrote: > Hello, > > We’ve been using SSSD with FreeIPA very successfully for a while now - we > love it. Recently, we’ve noticed that all our linux hosts (All Ubuntu 14.04) > log the following message pretty regularly (several dozen times per day): > > "Failed to initialize credentials using keytab [default]: Generic error (see > e-text). Unable to create GSSAPI-encrypted LDAP connection.” > > Now, outside of this message, we have no symptoms that things aren’t > functioning properly. SSSD is properly recognizing changes whenever we update > our FreeIPA server. > > Can anyone point us in the right direction on how to fix this issue? So far, > we’ve done the following: > > 1. Verified the /etc/krb5.keytab seems to be fine (and it does). with kinit -k, right? > 2. Verified that changes to our FreeIPA servers properly get replicated to > the clients. strange, I would have thought that this would cause the client to go offline. Can you send the complete logs? Ideally ldap_child.log and sssd_$domain.log -- 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] User mapping between domains
On Wed, Feb 03, 2016 at 03:59:55AM +, Simpson Lachlan wrote: > IPA is successfully installed, a one way trust created, and we have been able > to > login using AD credentials. > > For future googler's, there is some bare bones documentation on how to allow > AD > users to login to your system, under the heading "Allow access for users from > AD > domain to protected resources" > > http://www.freeipa.org/page/Active_Directory_trust_setup#Configure_IPA_server_for_cross-realm_trusts > > I can confirm this works for a one directional trust (IPA trusts AD), since > that > is what we have. > > Question/Issue: > > Currently I have two logins, one in the AD domain and one on each server in > the IPA domain. The desire is to close that gap. > > We were under the impression that, utilising idoverrideuser, that we could > map > AD's > > "Smith Jane"@example.org (or EXAMPLE\Jane Smith; yes I know our AD logins > have spaces in them, it's a technical debt that has no solution roadmap > within > the org) to > > jsm...@unix.example.org (which we would set up in IPA), > > and be able to override certain aspects, like: > > - instead of using the clumsy > > ssh "Smith Jane"@example@host1.unix.example.org btw normally you can login with samAccountName or UPN. I find it a bit odd that samAccountName would contain "Smith Jane", I would expect that to be in the gecos attribute.. Maybe in this case using UPN would be at least a bit easier , because you wouldn't have to quote it? > > to login to a system, we could use: > > ssh jsm...@host1.unix.example.org No, this cannot be done, at least not this way. While you can "remap" the AD usernames to a different one with id overrides functionality (so that "Smith Jane" might have a different name, you would still need to use the fully qualified name, not a shortname. This is because the trusted AD domain is a subdomain in SSSD lingo and all subdomains are implicitly fully qualified. If you want to use shortnames for your AD logins, you can use the default_domain_suffix option. But then only the domain that you put into this option's value can use short names and all other domains (including the IPA domain) must be fully qualified. > > and that via the ID Views Default Trust View the IPA server would: > - see that jsmith is "Smith Jane" in AD > - authenticate against "Smith Jane"'s AD password > - see that jsmith's uid now needs to be 1500 instead of 17890983 > - see that jsmith's home should be /home/jsmith, creating this dir if it > doesn't exist > - see that jsmith's shell is /bin/bash > > Am I merely imagining that this is possible? > > My information came from various blog posts on the RH blog that suggested > such a > thing was possible, and this post on the FreeIPA site: > > http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust#ID_Views > > Given the above use case, can I please get advice on: > > - is there a preferred order in which IPA user (jsm...@unix.example.org) is > created and AD user (EXAMPLE\Smith Jane) has their ID Views Default Trust > View entry created? > - for the creation of homedir on login, does this need to be done per host, > via > ipa-client-install's --mkhomedir option rather than per user? > > > Have I missed something? > > Cheers > L. > > > This email (including any attachments or links) may contain > confidential and/or legally privileged information and is > intended only to be read or used by the addressee. If you > are not the intended addressee, any use, distribution, > disclosure or copying of this email is strictly > prohibited. > Confidentiality and legal privilege attached to this email > (including any attachments) are not waived or lost by > reason of its mistaken delivery to you. > If you have received this email in error, please delete it > and notify us immediately by telephone or email. Peter > MacCallum Cancer Centre provides no guarantee that this > transmission is free of virus or that it has not been > intercepted or altered and will not be liable for any delay > in its receipt. > > > -- > 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
[Freeipa-users] FW: Joining a host
> -Original Message- > From: Simpson Lachlan > Sent: Wednesday, 3 February 2016 9:50 AM > To: Simpson Lachlan > Subject: RE: Joining a host > > > -Original Message- > > From: Simpson Lachlan > > > > [root@vmts-linux1 ~]# ipa-client-install Error checking LDAP: Operations > > error: > > 04DC: LdapErr: DSID-0C0906E8, comment: In order to perform this > > operation a successful bind must be completed on the connection., data > > 0, v1db1 Discovery was successful! > > Client hostname: vmts-linux1.unix.example.org > > Realm: UNIX.EXAMPLE.ORG > > DNS Domain: unix.example.org > > IPA Server: dc1.example.org > > BaseDN: dc=unix,dc=example,dc=org > > > > Interestingly, if I choose to explicitly put the IPA server name, I get dire > warnings > of no DNS autodiscover. > > The man page states: > > "Client machine can also be configured without a DNS autodiscovery at all. > When > both --server and --domain options are used, client installer will use the > specified > server and domain directly." > > > [root@vmts-linux1 ~]# ipa-client-install > --server=vmts-linuxidm.unix.example.org > Usage: ipa-client-install [options] > > ipa-client-install: error: --server cannot be used without providing --domain > > [root@vmts-linux1 ~]# ipa-client-install > --server=vmts-linuxidm.unix.example.org - > -domain=unix.example.org Autodiscovery of servers for failover cannot work > with > this configuration. > If you proceed with the installation, services will be configured to always > access > the discovered server for all operations and will not fail over to other > servers in > case of failure. > Proceed with fixed values and no DNS discovery? [no]: > > > I think we now have two solid conclusions: > > - there are DNS issues in my domain that I need to fix up (why isn't > _ldap._tcp.unix.example.org resolving to the IPA server?) > - the man page should clearly state that --server can't be run without the > --domain > option, unless it can, and the error message is wrong. > > Cheers > L. This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. -- 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] Joining a host
> > -Original Message- > > From: Simpson Lachlan > > Sent: Wednesday, 3 February 2016 9:50 AM > > > > [root@vmts-linux1 ~]# ipa-client-install > > --server=vmts-linuxidm.unix.example.org - -domain=unix.example.org > > Autodiscovery of servers for failover cannot work with this configuration. > > If you proceed with the installation, services will be configured to > > always access the discovered server for all operations and will not > > fail over to other servers in case of failure. > > Proceed with fixed values and no DNS discovery? [no]: > > > > > > I think we now have two solid conclusions: > > > > - there are DNS issues in my domain that I need to fix up (why isn't > > _ldap._tcp.unix.example.org resolving to the IPA server?) > > - the man page should clearly state that --server can't be run > > without the --domain option, unless it can, and the error message is wrong. Sure enough, #1 was true, and when the DNS entries for _ldap._tcp and _kerberos._tcp within that domain were fixed, running ipa-client-install worked exactly as expected. Cheers L. This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. -- 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] "Failed to initialize credentials using keytab [default]" errors on functioning clients
Hello, We’ve been using SSSD with FreeIPA very successfully for a while now - we love it. Recently, we’ve noticed that all our linux hosts (All Ubuntu 14.04) log the following message pretty regularly (several dozen times per day): "Failed to initialize credentials using keytab [default]: Generic error (see e-text). Unable to create GSSAPI-encrypted LDAP connection.” Now, outside of this message, we have no symptoms that things aren’t functioning properly. SSSD is properly recognizing changes whenever we update our FreeIPA server. Can anyone point us in the right direction on how to fix this issue? So far, we’ve done the following: 1. Verified the /etc/krb5.keytab seems to be fine (and it does). 2. Verified that changes to our FreeIPA servers properly get replicated to the clients. Thanks! Terence-- 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] Obtaining certificate private keys for Apache/etc.
That looks more like a regular SSL/TLS guide. I was asking about interacting with FreeIPA (likely via certmonger, I think) specifically. If anyone has details on obtaining the default system cert (and especially the private key) and exporting/converting to PEMs, I'd greatly appreciate. I will try and look over your guide regardless soon and provide some feedback. At the moment, I'm confused about where the private keys used to generate the default host PKI certs are stored and how to extract them. On Tue, Feb 2, 2016 at 6:50 PM, Filipozzi, Lucawrote: > I wrote the following guide for sysadmins at my university in an attempt to > coalesce in one place what I consider to be the good practices for X.509 > certificate management using OpenSSL. I've included examples on how to load > private keys, end-entity certificates and intermediate certificates into > alternate trust stores (PKCS for IIS and JKS for Java). > > https://confluence.id.ubc.ca:8443/display/ITSecurity/how+to+obtain%2C+deploy+and+verify+an+X.509+certificate > > Let me know if you have suggestions for improvement. > > -- > Luca Filipozzi, UBC IT Enterprise Architecture > > On Feb 2, 2016, at 15:43, Christopher Young wrote: > > I've been doing some reading and perhaps I'm confusing myself, but I > couldn't find any definitive guide on how to go about doing what I > think it a pretty simple thing. > > My ipa-client installs appear to generate a new TLS/SSL/PKI cert for > each host when they are registered. I'd like to utilize that > certificate with Apache/tomcat/etc.. I'm aware of how to obtain the > certificate itself, however I'm not clear on how to obtain the private > key (in a format that I can use as well) that was used to generate the > certificate. > > Would someone kindly point me in the right direction or ideally just > educate me on the command/options needed to do this. In particular, > I'm looking to create pem files for both the key and cert for use with > Apache, but it would be useful to understand how to do it for other > stores as well. (Hint: this would be great to just have in a document > that makes it clear). :) > > Thanks again to the freeipa team. I love this product. > > -- Chris > > -- > 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
[Freeipa-users] freeipa client in DMZ
Are ports required to be open for a freeipa client in a DMZ to the AD DCs for trusted users to login? I've got everything open to the IPA servers required and can lookup users and sudo rules and such but trusted users are not able to login. Thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- 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 client in DMZ
I believe the sssd clients will need to communicate directly with your AD domain controllers, unfortunately. I wish there was a clean way around this, since we have a ton of DC's in our HUB site, and I don't really want to poke holes in the firewall(s) for all of them. Would someone from sssd/IPA mind chiming in here? What exactly needs to be open? What DNS record can we query to get the exact list of DC's that need to be available? Is there a way to restrict the list of domain controllers that certain sssd clients need to communicate with (for scenarios like this)? Thanks, Josh > -Original Message- > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- > boun...@redhat.com] On Behalf Of Andy Thompson > Sent: Tuesday, February 02, 2016 9:04 AM > To: freeipa-users@redhat.com > Subject: [Freeipa-users] freeipa client in DMZ > > Are ports required to be open for a freeipa client in a DMZ to the AD DCs for > trusted users to login? I've got everything open to the IPA servers required > and can lookup users and sudo rules and such but trusted users are not able > to login. > > Thanks > > -andy > > > > *** This communication may contain privileged and/or confidential > information. It is intended solely for the use of the addressee. If you are > not > the intended recipient, you are strictly prohibited from disclosing, copying, > distributing or using any of this information. If you received this > communication in error, please contact the sender immediately and destroy > the material in its entirety, whether electronic or hard copy. *** > > > -- > 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