[Freeipa-users] RHEL 5.11 as IPA client
Hello. We cannot login to our IPA enrolled RHEL 5.11 host using any IPA (4.1) native or AD trusted users. Seems like it fails on connection to server. SSSD logs attached. Additionally, is it ever possible now to use AD trusted users to ssh RHEL 5 servers? Logs and sssd config attached. WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 ?? ? ? ? ? ??? ?? ???, ??? ??? ??. ? ? ? ??? ??, ??? ?? ? ??? ???-, ? ?. ?? ?? ??? ? ?, ?? ?, ?, ??? ??? ??? ?? ? ??? ??? ? ? ? ?. ?? ??? ? , ??, ??? ??? ?? ? ??? ?? ?? ? ? ? ? ??? ? ? ??. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 sssd.conf Description: sssd.conf sssd_default.log Description: sssd_default.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] RHEL 5.11 as IPA client
On Wed, 10 Jun 2015, Alexander Frolushkin wrote: Hello. We cannot login to our IPA enrolled RHEL 5.11 host using any IPA (4.1) native or AD trusted users. Seems like it fails on connection to server. SSSD logs attached. Additionally, is it ever possible now to use AD trusted users to ssh RHEL 5 servers? Logs and sssd config attached. RHEL5 uses OpenSSL crypto library which doesn't support TLS 1.1+ which is required by default by IPA 4.1. Your potential fix would be to allow tls1.0 use at the server side but you need to know what this leads to: https://access.redhat.com/articles/1294573 You seem to have issues on RHEL5 with TLS1.0+ configuration which is in use by the LDAP server: (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [sdap_process_result] (8): Trace: sh[0x15b01590], connected[1], ops[0x15b01e40], ldap[0x15b019d0] (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [sdap_connect_done] (3): START TLS result: Success(0), Start TLS request accepted.Server willing to negotiate SSL. (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [sdap_connect_done] (3): ldap_install_tls failed: [Connect error] [Start TLS request accepted.Server willing to negotiate SSL.] (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [sdap_handle_release] (8): Trace: sh[0x15b01590], connected[1], ops[(nil)], ldap[0x15b019d0], destructor_lock[0], release_memory[0] (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [remove_connection_callback] (9): Successfully removed connection callback. (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [fo_set_port_status] (4): Marking port 389 of server 'sib-rhidm01.unix.megafon.ru' as 'not working' (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [be_pam_handler_callback] (4): Backend returned: (3, 4, NULL) [Internal Error (System error)] (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [be_pam_handler_callback] (4): Sending result [4][default] (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [be_pam_handler_callback] (4): Sent result [4][default] (Wed Jun 10 17:05:22 2015) [sssd[be[default]]] [sbus_dispatch] (9): dbus conn: 15AF0830 (Wed Jun 10 17:05:22 2015) [sssd[be[default]]] [sbus_dispatch] (9): Dispatching. -- / 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] RHEL 5.11 as IPA client
Okay, the situation now become completely cleared, thank you! WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 -Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Wednesday, June 10, 2015 4:46 PM To: Alexander Frolushkin (SIB) Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] RHEL 5.11 as IPA client On Wed, 10 Jun 2015, Alexander Frolushkin wrote: This is not good at all... Firstly old sssd, now crypto issues... Can you also say, will HBAC and SUDO in IPA work for trusted AD users on RHEL 5 servers if we will enable vulnerable tls? SSSD on RHEL 5 does not support SUDO natively, look at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Configuring_Identity_Management/configuring-rhel5.html SSSD on RHEL 5 does not support HBAC rules when configured against compat tree. https://www.redhat.com/archives/freeipa-users/2015-April/msg00523.html -- / Alexander Bokovoy Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- 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] LDAP authentication for JIRA using FreeIPA
Cool, I am glad you made this working. BTW, would any of you mind volunteering and helping the FreeIPA community with contributing a HOWTO article on how to configure FreeIPA and Jira? It is still missing in FreeIPA.org wiki. All we have right now is the link to this discussion, that Petr Spacek added to http://www.freeipa.org/page/HowTos#Web_Services It would be really nice to also have a real page that others can follow and use. Thank you! Martin On 06/10/2015 11:29 AM, Brian Topping wrote: FYI, that mirrors my configuration. Not sure if this was covered previously, but for my setup, only JIRA connects to IPA. All the other atleasian products contact JIRA for their information. Cheers, Brian On Jun 10, 2015, at 12:47 AM, Sandor Juhasz sjuh...@chemaxon.com wrote: Hi, here are our working configurations. Might be useful. We use compat tree for auth. We use user in group matching. We use group filter for login authorization. We use FedoraDS as ldap connector on JIRA's side. We don't use pw change or user create in IPA from JIRA side. Watch out not to have matching local users/groups or you will suffer bigtime. Initially it was setup not to use ldap groups, but was changed afterwards by creating all new groups in ldap for this purpose and readding the users. We use ldap service user for binding - https://www.freeipa.org/page/Zimbra_Collaboration_Server_7.2_Authentication_and_GAL_lookups_against_FreeIPA. Attributes: autoAddGroups: com.atlassian.crowd.directory.sync.currentstartsynctime: null com.atlassian.crowd.directory.sync.issynchronising: false com.atlassian.crowd.directory.sync.lastdurationms: 373 com.atlassian.crowd.directory.sync.laststartsynctime: 1433920165776 crowd.sync.incremental.enabled: false directory.cache.synchronise.interval: 3600 ldap.basedn: dc=OURDOMAIN ldap.connection.timeout: 0 ldap.external.id: ldap.group.description: description ldap.group.dn: cn=groups,cn=compat ldap.group.filter: ((objectClass=posixgroup)(|(cn=COMPANYGROUP)(cn=TEAMGROUPS)(cn=JIRAGROUP))) ldap.group.name: cn ldap.group.objectclass: groupOfUniqueNames ldap.group.usernames: memberUid ldap.local.groups: false ldap.nestedgroups.disabled: true ldap.pagedresults: false ldap.pagedresults.size: 1000 ldap.password: ldap.pool.initsize: null ldap.pool.maxsize: null ldap.pool.prefsize: null ldap.pool.timeout: 0 ldap.propogate.changes: false ldap.read.timeout: 12 ldap.referral: false ldap.relaxed.dn.standardisation: true ldap.roles.disabled: true ldap.search.timelimit: 6 ldap.secure: false ldap.url: ldap://IPAURL ldap.user.displayname: cn ldap.user.dn: cn=users,cn=accounts ldap.user.email: mail ldap.user.encryption: sha ldap.user.filter: ((objectclass=posixAccount)(memberOf=cn=JIRAGROUP,cn=groups,cn=accounts,dc=OURDOMAIN)) ldap.user.firstname: givenName ldap.user.group: memberOf ldap.user.lastname: sn ldap.user.objectclass: person ldap.user.password: userPassword ldap.user.username: uid ldap.user.username.rdn: ldap.userdn: uid=OURSERVICEUSER,cn=sysaccounts,cn=etc,dc=OURDOMAIN ldap.usermembership.use: false ldap.usermembership.use.for.groups: false localUserStatusEnabled: false Sándor Juhász System Administrator ChemAxon Ltd. Building Hx, GraphiSoft Park, Záhony utca 7, Budapest, Hungary, H-1031 Cell: +36704258964 From: Martin Kosek mko...@redhat.com To: Christopher Lamb christopher.l...@ch.ibm.com, freeipa-users@redhat.com Sent: Wednesday, June 10, 2015 9:22:03 AM Subject: Re: [Freeipa-users] LDAP authentication for JIRA using FreeIPA On 06/08/2015 06:44 PM, Christopher Lamb wrote: Hi All we are interested to know if anybody has succeeded (or for that matter failed) in using FreeIPA to provide user authentication for Atlassian products such as JIRA or Confluence? Somewhere in an Atlassian ticket I saw that FreeIPA is not officially supported, so I guess that should set our expectations . If anyone has succeeded, then of course any tips on how best to do so would be fantastic! I saw reply in the threads, so it should be covered. BTW, please add +1s to respective Jira tickets to add proper FreeIPA support. It would be really cool if Jira would know FreeIPA out of the box and could connect to it natively! -- 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
[Freeipa-users] ssh known hosts gets recreated on client
Hello, If I uninstall the ipa client with ipa-client-install --uninstall then reinstall it to the same ipa master then most functions work fine. However, if I attempt to ssh from the client to the master then I get. @@@ @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 86:c1:d7:96:8d:a3:b6:54:69:7c:cf:79:55:b3:14:c1. Please contact your system administrator. Add correct host key in /home/gbob/.ssh/known_hosts to get rid of this message. Offending key in /var/lib/sss/pubconf/known_hosts:1 RSA host key for ipa004.jackland.co.uk has changed and you have requested strict checking. Host key verification failed. I've tried stopping the sssd service on the client, removing /var/lib/sss/pubconf/known_hosts and /var/lib/sss/db/* then restarting sssd, but /var/lib/sss/pubconf just gets recreated with the old contents and I get the same error (it seems odd that it's reporting that the host key of the master has changed when it's the client that has been reinstalled). How do I clear-out the client's knowledge of the old host keys? In this case I'm using ipa-client v3.0.0 on RHEL6.6 Thanks Bob -- 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] RHEL 5.11 as IPA client
This is not good at all... Firstly old sssd, now crypto issues... Can you also say, will HBAC and SUDO in IPA work for trusted AD users on RHEL 5 servers if we will enable vulnerable tls? WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 -Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Wednesday, June 10, 2015 4:30 PM To: Alexander Frolushkin (SIB) Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] RHEL 5.11 as IPA client On Wed, 10 Jun 2015, Alexander Frolushkin wrote: Hello. We cannot login to our IPA enrolled RHEL 5.11 host using any IPA (4.1) native or AD trusted users. Seems like it fails on connection to server. SSSD logs attached. Additionally, is it ever possible now to use AD trusted users to ssh RHEL 5 servers? Logs and sssd config attached. RHEL5 uses OpenSSL crypto library which doesn't support TLS 1.1+ which is required by default by IPA 4.1. Your potential fix would be to allow tls1.0 use at the server side but you need to know what this leads to: https://access.redhat.com/articles/1294573 You seem to have issues on RHEL5 with TLS1.0+ configuration which is in use by the LDAP server: (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [sdap_process_result] (8): Trace: sh[0x15b01590], connected[1], ops[0x15b01e40], ldap[0x15b019d0] (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [sdap_connect_done] (3): START TLS result: Success(0), Start TLS request accepted.Server willing to negotiate SSL. (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [sdap_connect_done] (3): ldap_install_tls failed: [Connect error] [Start TLS request accepted.Server willing to negotiate SSL.] (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [sdap_handle_release] (8): Trace: sh[0x15b01590], connected[1], ops[(nil)], ldap[0x15b019d0], destructor_lock[0], release_memory[0] (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [remove_connection_callback] (9): Successfully removed connection callback. (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [fo_set_port_status] (4): Marking port 389 of server 'sib-rhidm01.unix.megafon.ru' as 'not working' (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [be_pam_handler_callback] (4): Backend returned: (3, 4, NULL) [Internal Error (System error)] (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [be_pam_handler_callback] (4): Sending result [4][default] (Wed Jun 10 17:05:16 2015) [sssd[be[default]]] [be_pam_handler_callback] (4): Sent result [4][default] (Wed Jun 10 17:05:22 2015) [sssd[be[default]]] [sbus_dispatch] (9): dbus conn: 15AF0830 (Wed Jun 10 17:05:22 2015) [sssd[be[default]]] [sbus_dispatch] (9): Dispatching. -- / Alexander Bokovoy Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- 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] RHEL 5.11 as IPA client
On Wed, 10 Jun 2015, Alexander Frolushkin wrote: This is not good at all... Firstly old sssd, now crypto issues... Can you also say, will HBAC and SUDO in IPA work for trusted AD users on RHEL 5 servers if we will enable vulnerable tls? SSSD on RHEL 5 does not support SUDO natively, look at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Configuring_Identity_Management/configuring-rhel5.html SSSD on RHEL 5 does not support HBAC rules when configured against compat tree. https://www.redhat.com/archives/freeipa-users/2015-April/msg00523.html -- / 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] LDAP authentication for JIRA using FreeIPA
Hi All Thanks to Brian and Sandor for their input so far - this gives me another approach to try. From my side this is a work-in-progress report: we have got something working, but are not quite happy with it. Stepping back a bit: I suspect there are a number of integration approaches that may (or may not) work. Atlassian offer several default ldap configurations inc. the FedoraDS mentioned by Sando. Probably several of these can be massaged / bullied to work with FreeIPA with varying degrees of effort / pain. There seem also to be several possible integration use-cases, ranging from full bidirectional replication of ldap users and groups down to simple read-only* authentication only. In our case we want to take a simple approach: in fact we have tried 2 methods so far. 1) We first tried a one-way replication of FreeIPA users and groups to JIRA, as described here: https://confluence.atlassian.com/display/JIRA/Connecting+to+an+LDAP +Directory We used the A generic LDAP directory server standard config with some values changed for the FreeIPA equivalents. While we were successfully able to connect from JIRA to FreeIPA, and users replicated across, groups did not - it failed at the point of group membership. Also the users could not login (but that is maybe because - from a JIRA point of view - the users had no groups). We did not spend long on this approach, so it is possible that with a little more tweaking we could get it to work. 2) We next tried an even simpler approach - using LDAP only for authentication. https://confluence.atlassian.com/display/JIRA/Connecting+to+an+Internal +Directory+with+LDAP+Authentication Under this approach, when a user first tries to logon to JIRA the user is authenticated and replicated to JIRA. Groups remain local the JIRA directory (although a default group e.g. jira-users can be setup.) This approach is suitable when only a subset of LDAP users need JIRA access. Being one-way there should be no danger of JIRA screwing the LDAP. While we can successfully authenticate FreeIPA users (and thus login and work in JIRA) with this approach, so far we have not been able to get the email address to replicate from FreeIPA to JIRA (and without working email notifications JIRA is rendered as useful as a chocolate teapot) We will continue experimenting (we now have a suggested config from Sandor below as a further variant). Once we get something satisfactory working I would be pleased to contribute to a wiki-page on the topic. Cheers Chris From: Martin Kosek mko...@redhat.com To: Brian Topping brian.topp...@gmail.com, Sandor Juhasz sjuh...@chemaxon.com Cc: freeipa-users@redhat.com Date: 10.06.2015 12:13 Subject:Re: [Freeipa-users] LDAP authentication for JIRA using FreeIPA Sent by:freeipa-users-boun...@redhat.com Cool, I am glad you made this working. BTW, would any of you mind volunteering and helping the FreeIPA community with contributing a HOWTO article on how to configure FreeIPA and Jira? It is still missing in FreeIPA.org wiki. All we have right now is the link to this discussion, that Petr Spacek added to http://www.freeipa.org/page/HowTos#Web_Services It would be really nice to also have a real page that others can follow and use. Thank you! Martin On 06/10/2015 11:29 AM, Brian Topping wrote: FYI, that mirrors my configuration. Not sure if this was covered previously, but for my setup, only JIRA connects to IPA. All the other atleasian products contact JIRA for their information. Cheers, Brian On Jun 10, 2015, at 12:47 AM, Sandor Juhasz sjuh...@chemaxon.com wrote: Hi, here are our working configurations. Might be useful. We use compat tree for auth. We use user in group matching. We use group filter for login authorization. We use FedoraDS as ldap connector on JIRA's side. We don't use pw change or user create in IPA from JIRA side. Watch out not to have matching local users/groups or you will suffer bigtime. Initially it was setup not to use ldap groups, but was changed afterwards by creating all new groups in ldap for this purpose and readding the users. We use ldap service user for binding - https://www.freeipa.org/page/Zimbra_Collaboration_Server_7.2_Authentication_and_GAL_lookups_against_FreeIPA . Attributes: autoAddGroups: com.atlassian.crowd.directory.sync.currentstartsynctime: null com.atlassian.crowd.directory.sync.issynchronising: false com.atlassian.crowd.directory.sync.lastdurationms: 373 com.atlassian.crowd.directory.sync.laststartsynctime: 1433920165776 crowd.sync.incremental.enabled: false directory.cache.synchronise.interval: 3600 ldap.basedn: dc=OURDOMAIN ldap.connection.timeout: 0 ldap.external.id: ldap.group.description: description ldap.group.dn: cn=groups,cn=compat ldap.group.filter: ((objectClass=posixgroup)(| (cn=COMPANYGROUP)(cn=TEAMGROUPS)(cn=JIRAGROUP))) ldap.group.name: cn ldap.group.objectclass: groupOfUniqueNames ldap.group.usernames:
Re: [Freeipa-users] ssh known hosts gets recreated on client
The /home/USER/.ssh/known_hosts file doesn't exist. It's /var/lib/sss/pubconf/known_hosts that's the problem. If the offending line is deleted from this file or this file is deleted completely then it's automatically replaced and the same error occurs. On 10/06/2015 13:55, Cory Carlton wrote: I feel this is a User ssh file issue not a sssd when sshing. the client is seeing its a different key exchange with the same IP it once knew about, the known_hosts file on the client machine (and user) in the .ssh folder need to be updated or wiped clean. If you edit on the client machine /home/USER/.ssh/known_hosts delete the IP line. On Wed, Jun 10, 2015 at 5:33 AM, Bob Hinton b...@jackland.demon.co.uk mailto:b...@jackland.demon.co.uk wrote: Hello, If I uninstall the ipa client with ipa-client-install --uninstall then reinstall it to the same ipa master then most functions work fine. However, if I attempt to ssh from the client to the master then I get. @@@ @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 86:c1:d7:96:8d:a3:b6:54:69:7c:cf:79:55:b3:14:c1. Please contact your system administrator. Add correct host key in /home/gbob/.ssh/known_hosts to get rid of this message. Offending key in /var/lib/sss/pubconf/known_hosts:1 RSA host key for ipa004.jackland.co.uk http://ipa004.jackland.co.uk has changed and you have requested strict checking. Host key verification failed. I've tried stopping the sssd service on the client, removing /var/lib/sss/pubconf/known_hosts and /var/lib/sss/db/* then restarting sssd, but /var/lib/sss/pubconf just gets recreated with the old contents and I get the same error (it seems odd that it's reporting that the host key of the master has changed when it's the client that has been reinstalled). How do I clear-out the client's knowledge of the old host keys? In this case I'm using ipa-client v3.0.0 on RHEL6.6 Thanks Bob -- 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] ssh known hosts gets recreated on client
I feel this is a User ssh file issue not a sssd when sshing. the client is seeing its a different key exchange with the same IP it once knew about, the known_hosts file on the client machine (and user) in the .ssh folder need to be updated or wiped clean. If you edit on the client machine /home/USER/.ssh/known_hosts delete the IP line. On Wed, Jun 10, 2015 at 5:33 AM, Bob Hinton b...@jackland.demon.co.uk wrote: Hello, If I uninstall the ipa client with ipa-client-install --uninstall then reinstall it to the same ipa master then most functions work fine. However, if I attempt to ssh from the client to the master then I get. @@@ @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 86:c1:d7:96:8d:a3:b6:54:69:7c:cf:79:55:b3:14:c1. Please contact your system administrator. Add correct host key in /home/gbob/.ssh/known_hosts to get rid of this message. Offending key in /var/lib/sss/pubconf/known_hosts:1 RSA host key for ipa004.jackland.co.uk has changed and you have requested strict checking. Host key verification failed. I've tried stopping the sssd service on the client, removing /var/lib/sss/pubconf/known_hosts and /var/lib/sss/db/* then restarting sssd, but /var/lib/sss/pubconf just gets recreated with the old contents and I get the same error (it seems odd that it's reporting that the host key of the master has changed when it's the client that has been reinstalled). How do I clear-out the client's knowledge of the old host keys? In this case I'm using ipa-client v3.0.0 on RHEL6.6 Thanks Bob -- 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] LDAP authentication for JIRA using FreeIPA
Hi, i tried many linear combinations of setup options when i tied our JIRA to ldap. First it was tied to openldap with user auth only. Once we started to use IPA, i changed. Using the base config of FedoraDS was chosen becuase IPA is based on it as well. We don't want any of our service actively modifying ldap, so read-only posix schema was the choice. As for group matching. Accounts tree will not work, don't know why, it just did not work for us. Use compat tree, it is there for these occasions. On the membership schem settings: Group member attribute: memberUid User membership attribute: memberOf Use the user membership attribute: no tick For this setup you need a service user, because memberUid attributes of users are not visible for a single user in the ldap schema - don't remember why. We needed that for user filter as well, so we have chosen to use it this way. Sándor Juhász System Administrator ChemAxon Ltd . Building Hx, GraphiSoft Park, Záhony utca 7, Budapest, Hungary, H-1031 Cell: +36704258964 From: Christopher Lamb christopher.l...@ch.ibm.com To: Martin Kosek mko...@redhat.com, Brian Topping brian.topp...@gmail.com, Sandor Juhasz sjuh...@chemaxon.com Cc: freeipa-users@redhat.com Sent: Wednesday, June 10, 2015 1:55:15 PM Subject: Re: [Freeipa-users] LDAP authentication for JIRA using FreeIPA Hi All Thanks to Brian and Sandor for their input so far - this gives me another approach to try. From my side this is a work-in-progress report: we have got something working, but are not quite happy with it. Stepping back a bit: I suspect there are a number of integration approaches that may (or may not) work. Atlassian offer several default ldap configurations inc. the FedoraDS mentioned by Sando. Probably several of these can be massaged / bullied to work with FreeIPA with varying degrees of effort / pain. There seem also to be several possible integration use-cases, ranging from full bidirectional replication of ldap users and groups down to simple read-only* authentication only. In our case we want to take a simple approach: in fact we have tried 2 methods so far. 1) We first tried a one-way replication of FreeIPA users and groups to JIRA, as described here: https://confluence.atlassian.com/display/JIRA/Connecting+to+an+LDAP +Directory We used the A generic LDAP directory server standard config with some values changed for the FreeIPA equivalents. While we were successfully able to connect from JIRA to FreeIPA, and users replicated across, groups did not - it failed at the point of group membership. Also the users could not login (but that is maybe because - from a JIRA point of view - the users had no groups). We did not spend long on this approach, so it is possible that with a little more tweaking we could get it to work. 2) We next tried an even simpler approach - using LDAP only for authentication. https://confluence.atlassian.com/display/JIRA/Connecting+to+an+Internal +Directory+with+LDAP+Authentication Under this approach, when a user first tries to logon to JIRA the user is authenticated and replicated to JIRA. Groups remain local the JIRA directory (although a default group e.g. jira-users can be setup.) This approach is suitable when only a subset of LDAP users need JIRA access. Being one-way there should be no danger of JIRA screwing the LDAP. While we can successfully authenticate FreeIPA users (and thus login and work in JIRA) with this approach, so far we have not been able to get the email address to replicate from FreeIPA to JIRA (and without working email notifications JIRA is rendered as useful as a chocolate teapot) We will continue experimenting (we now have a suggested config from Sandor below as a further variant). Once we get something satisfactory working I would be pleased to contribute to a wiki-page on the topic. Cheers Chris From: Martin Kosek mko...@redhat.com To: Brian Topping brian.topp...@gmail.com, Sandor Juhasz sjuh...@chemaxon.com Cc: freeipa-users@redhat.com Date: 10.06.2015 12:13 Subject: Re: [Freeipa-users] LDAP authentication for JIRA using FreeIPA Sent by: freeipa-users-boun...@redhat.com Cool, I am glad you made this working. BTW, would any of you mind volunteering and helping the FreeIPA community with contributing a HOWTO article on how to configure FreeIPA and Jira? It is still missing in FreeIPA.org wiki. All we have right now is the link to this discussion, that Petr Spacek added to http://www.freeipa.org/page/HowTos#Web_Services It would be really nice to also have a real page that others can follow and use. Thank you! Martin On 06/10/2015 11:29 AM, Brian Topping wrote: FYI, that mirrors my configuration. Not sure if this was covered previously, but for my setup, only JIRA connects to IPA. All the other atleasian products contact JIRA for their information. Cheers, Brian On Jun 10, 2015, at 12:47 AM, Sandor Juhasz
[Freeipa-users] migrating 3.0 - 4.1: passwords not migrated?
hi, Currently there are CentOS 6.5 servers and IPA 3.0. The goal is migrating users to CentOS 7.1 and IPA 4.1. This is the command I use: $ ipa migrate-ds ldap://ipa11 --user-container=cn=users,cn=accounts,dc=foo --group-container=cn=groups,cn=accounts,dc=foo --base-dn=dc=foo --with-compat ~/.pw.manager Users are migrated successfully but password must be reset, otherwise they cannot logon. Any idea, what's going on? I also have a bonus question. How can I migrate the cn=sysaccounts,cn=etc,dc=cxn tree? Do I need to export/import it as ldif and that's all? Thanks, tamas -- 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] LDAP authentication for JIRA using FreeIPA
Hi, here are our working configurations. Might be useful. We use compat tree for auth. We use user in group matching. We use group filter for login authorization. We use FedoraDS as ldap connector on JIRA's side. We don't use pw change or user create in IPA from JIRA side. Watch out not to have matching local users/groups or you will suffer bigtime. Initially it was setup not to use ldap groups, but was changed afterwards by creating all new groups in ldap for this purpose and readding the users. We use ldap service user for binding - https://www.freeipa.org/page/Zimbra_Collaboration_Server_7.2_Authentication_and_GAL_lookups_against_FreeIPA. Attributes: autoAddGroups: com.atlassian.crowd.directory.sync.currentstartsynctime: null com.atlassian.crowd.directory.sync.issynchronising: false com.atlassian.crowd.directory.sync.lastdurationms: 373 com.atlassian.crowd.directory.sync.laststartsynctime: 1433920165776 crowd.sync.incremental.enabled: false directory.cache.synchronise.interval: 3600 ldap.basedn: dc=OURDOMAIN ldap.connection.timeout: 0 ldap.external.id: ldap.group.description: description ldap.group.dn: cn=groups,cn=compat ldap.group.filter: ((objectClass=posixgroup)(|(cn=COMPANYGROUP)(cn=TEAMGROUPS)(cn=JIRAGROUP))) ldap.group.name: cn ldap.group.objectclass: groupOfUniqueNames ldap.group.usernames: memberUid ldap.local.groups: false ldap.nestedgroups.disabled: true ldap.pagedresults: false ldap.pagedresults.size: 1000 ldap.password: ldap.pool.initsize: null ldap.pool.maxsize: null ldap.pool.prefsize: null ldap.pool.timeout: 0 ldap.propogate.changes: false ldap.read.timeout: 12 ldap.referral: false ldap.relaxed.dn.standardisation: true ldap.roles.disabled: true ldap.search.timelimit: 6 ldap.secure: false ldap.url: ldap://IPAURL ldap.user.displayname: cn ldap.user.dn: cn=users,cn=accounts ldap.user.email: mail ldap.user.encryption: sha ldap.user.filter: ((objectclass=posixAccount)(memberOf=cn=JIRAGROUP,cn=groups,cn=accounts,dc=OURDOMAIN)) ldap.user.firstname: givenName ldap.user.group: memberOf ldap.user.lastname: sn ldap.user.objectclass: person ldap.user.password: userPassword ldap.user.username: uid ldap.user.username.rdn: ldap.userdn: uid=OURSERVICEUSER,cn=sysaccounts,cn=etc,dc=OURDOMAIN ldap.usermembership.use: false ldap.usermembership.use.for.groups: false localUserStatusEnabled: false Sándor Juhász System Administrator ChemAxon Ltd . Building Hx, GraphiSoft Park, Záhony utca 7, Budapest, Hungary, H-1031 Cell: +36704258964 From: Martin Kosek mko...@redhat.com To: Christopher Lamb christopher.l...@ch.ibm.com, freeipa-users@redhat.com Sent: Wednesday, June 10, 2015 9:22:03 AM Subject: Re: [Freeipa-users] LDAP authentication for JIRA using FreeIPA On 06/08/2015 06:44 PM, Christopher Lamb wrote: Hi All we are interested to know if anybody has succeeded (or for that matter failed) in using FreeIPA to provide user authentication for Atlassian products such as JIRA or Confluence? Somewhere in an Atlassian ticket I saw that FreeIPA is not officially supported, so I guess that should set our expectations . If anyone has succeeded, then of course any tips on how best to do so would be fantastic! I saw reply in the threads, so it should be covered. BTW, please add +1s to respective Jira tickets to add proper FreeIPA support. It would be really cool if Jira would know FreeIPA out of the box and could connect to it natively! -- 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] LDAP authentication for JIRA using FreeIPA
FYI, that mirrors my configuration. Not sure if this was covered previously, but for my setup, only JIRA connects to IPA. All the other atleasian products contact JIRA for their information. Cheers, Brian On Jun 10, 2015, at 12:47 AM, Sandor Juhasz sjuh...@chemaxon.com wrote: Hi, here are our working configurations. Might be useful. We use compat tree for auth. We use user in group matching. We use group filter for login authorization. We use FedoraDS as ldap connector on JIRA's side. We don't use pw change or user create in IPA from JIRA side. Watch out not to have matching local users/groups or you will suffer bigtime. Initially it was setup not to use ldap groups, but was changed afterwards by creating all new groups in ldap for this purpose and readding the users. We use ldap service user for binding - https://www.freeipa.org/page/Zimbra_Collaboration_Server_7.2_Authentication_and_GAL_lookups_against_FreeIPA. Attributes: autoAddGroups: com.atlassian.crowd.directory.sync.currentstartsynctime: null com.atlassian.crowd.directory.sync.issynchronising: false com.atlassian.crowd.directory.sync.lastdurationms: 373 com.atlassian.crowd.directory.sync.laststartsynctime: 1433920165776 crowd.sync.incremental.enabled: false directory.cache.synchronise.interval: 3600 ldap.basedn: dc=OURDOMAIN ldap.connection.timeout: 0 ldap.external.id: ldap.group.description: description ldap.group.dn: cn=groups,cn=compat ldap.group.filter: ((objectClass=posixgroup)(|(cn=COMPANYGROUP)(cn=TEAMGROUPS)(cn=JIRAGROUP))) ldap.group.name: cn ldap.group.objectclass: groupOfUniqueNames ldap.group.usernames: memberUid ldap.local.groups: false ldap.nestedgroups.disabled: true ldap.pagedresults: false ldap.pagedresults.size: 1000 ldap.password: ldap.pool.initsize: null ldap.pool.maxsize: null ldap.pool.prefsize: null ldap.pool.timeout: 0 ldap.propogate.changes: false ldap.read.timeout: 12 ldap.referral: false ldap.relaxed.dn.standardisation: true ldap.roles.disabled: true ldap.search.timelimit: 6 ldap.secure: false ldap.url: ldap://IPAURL ldap.user.displayname: cn ldap.user.dn: cn=users,cn=accounts ldap.user.email: mail ldap.user.encryption: sha ldap.user.filter: ((objectclass=posixAccount)(memberOf=cn=JIRAGROUP,cn=groups,cn=accounts,dc=OURDOMAIN)) ldap.user.firstname: givenName ldap.user.group: memberOf ldap.user.lastname: sn ldap.user.objectclass: person ldap.user.password: userPassword ldap.user.username: uid ldap.user.username.rdn: ldap.userdn: uid=OURSERVICEUSER,cn=sysaccounts,cn=etc,dc=OURDOMAIN ldap.usermembership.use: false ldap.usermembership.use.for.groups: false localUserStatusEnabled: false Sándor Juhász System Administrator ChemAxon Ltd. Building Hx, GraphiSoft Park, Záhony utca 7, Budapest, Hungary, H-1031 Cell: +36704258964 From: Martin Kosek mko...@redhat.com To: Christopher Lamb christopher.l...@ch.ibm.com, freeipa-users@redhat.com Sent: Wednesday, June 10, 2015 9:22:03 AM Subject: Re: [Freeipa-users] LDAP authentication for JIRA using FreeIPA On 06/08/2015 06:44 PM, Christopher Lamb wrote: Hi All we are interested to know if anybody has succeeded (or for that matter failed) in using FreeIPA to provide user authentication for Atlassian products such as JIRA or Confluence? Somewhere in an Atlassian ticket I saw that FreeIPA is not officially supported, so I guess that should set our expectations . If anyone has succeeded, then of course any tips on how best to do so would be fantastic! I saw reply in the threads, so it should be covered. BTW, please add +1s to respective Jira tickets to add proper FreeIPA support. It would be really cool if Jira would know FreeIPA out of the box and could connect to it natively! -- 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] migrating 3.0 - 4.1: passwords not migrated?
On 06/10/2015 03:18 PM, Tamas Papp wrote: hi, Currently there are CentOS 6.5 servers and IPA 3.0. The goal is migrating users to CentOS 7.1 and IPA 4.1. This is the command I use: $ ipa migrate-ds ldap://ipa11 --user-container=cn=users,cn=accounts,dc=foo --group-container=cn=groups,cn=accounts,dc=foo --base-dn=dc=foo --with-compat ~/.pw.manager Users are migrated successfully but password must be reset, otherwise they cannot logon. Any idea, what's going on? My guess is that their Kerberos key is also migrated. The key is not valid on the new installation as also Kerberos master key is different. So I would suggest stripping the users from their Kerberos attributes first. Some advise here: https://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA I also have a bonus question. How can I migrate the cn=sysaccounts,cn=etc,dc=cxn tree? Do I need to export/import it as ldif and that's all? Hmm, this should be all. Except if the users were members of for examples roles or privileges, you would need to migrate that membership too as mere presence of memberOf attribute in the sys account will not be enough. -- 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] migrating 3.0 - 4.1: passwords not migrated?
Hi Tamas I think the general advice is to replicate rather than to migrate. I am sure Martin K will jump in on this. However some weeks ago, when doing a very similar move to yours, we chose to migrate (we were misled by some very old FreeIPA docus that have since been archived). In our case passwords were successfully migrated, so the users were able to use the same user / password combo as before. I will see if I can dig out the migrate command we used at the time. Chris From: Tamas Papp tom...@martos.bme.hu To: freeipa-users@redhat.com Date: 10.06.2015 15:19 Subject:[Freeipa-users] migrating 3.0 - 4.1: passwords not migrated? Sent by:freeipa-users-boun...@redhat.com hi, Currently there are CentOS 6.5 servers and IPA 3.0. The goal is migrating users to CentOS 7.1 and IPA 4.1. This is the command I use: $ ipa migrate-ds ldap://ipa11 --user-container=cn=users,cn=accounts,dc=foo --group-container=cn=groups,cn=accounts,dc=foo --base-dn=dc=foo --with-compat ~/.pw.manager Users are migrated successfully but password must be reset, otherwise they cannot logon. Any idea, what's going on? I also have a bonus question. How can I migrate the cn=sysaccounts,cn=etc,dc=cxn tree? Do I need to export/import it as ldif and that's all? Thanks, tamas -- 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] ssh known hosts gets recreated on client
On (10/06/15 11:33), Bob Hinton wrote: Hello, If I uninstall the ipa client with ipa-client-install --uninstall then reinstall it to the same ipa master then most functions work fine. However, if I attempt to ssh from the client to the master then I get. @@@ @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 86:c1:d7:96:8d:a3:b6:54:69:7c:cf:79:55:b3:14:c1. Please contact your system administrator. Add correct host key in /home/gbob/.ssh/known_hosts to get rid of this message. Offending key in /var/lib/sss/pubconf/known_hosts:1 RSA host key for ipa004.jackland.co.uk has changed and you have requested strict checking. Host key verification failed. I've tried stopping the sssd service on the client, removing /var/lib/sss/pubconf/known_hosts and /var/lib/sss/db/* then restarting sssd, but /var/lib/sss/pubconf just gets recreated with the old contents and I get the same error (it seems odd that it's reporting that the host key of the master has changed when it's the client that has been reinstalled). How do I clear-out the client's knowledge of the old host keys? In this case I'm using ipa-client v3.0.0 on RHEL6.6 You removed /var/lib/sss/pubconf/known_hosts and also sssd cache, but you still have problem after restarting sssd. So the only explanation is that wrong host public key is stored in FreeIPA. Could you try to check host public key with ldapsearch in FreeIPA. I think you wold need to do it as an admin. LS -- 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] migrating 3.0 - 4.1: passwords not migrated?
On 06/10/2015 03:32 PM, Christopher Lamb wrote: Hi Tamas I think the general advice is to replicate rather than to migrate. I am sure Martin K will jump in on this. Yes :-) However some weeks ago, when doing a very similar move to yours, we chose to migrate (we were misled by some very old FreeIPA docus that have since been archived). In our case passwords were successfully migrated, so the users were able to use the same user / password combo as before. I will see if I can dig out the migrate command we used at the time. Did you use the migration command advised in https://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA ? Chris From: Tamas Papp tom...@martos.bme.hu To: freeipa-users@redhat.com Date: 10.06.2015 15:19 Subject: [Freeipa-users] migrating 3.0 - 4.1: passwords not migrated? Sent by: freeipa-users-boun...@redhat.com hi, Currently there are CentOS 6.5 servers and IPA 3.0. The goal is migrating users to CentOS 7.1 and IPA 4.1. This is the command I use: $ ipa migrate-ds ldap://ipa11 --user-container=cn=users,cn=accounts,dc=foo --group-container=cn=groups,cn=accounts,dc=foo --base-dn=dc=foo --with-compat ~/.pw.manager Users are migrated successfully but password must be reset, otherwise they cannot logon. Any idea, what's going on? I also have a bonus question. How can I migrate the cn=sysaccounts,cn=etc,dc=cxn tree? Do I need to export/import it as ldif and that's all? Thanks, tamas -- 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] migrating 3.0 - 4.1: passwords not migrated?
Hi Martin and Tamas My source was a different one, i found a hint in a ipa python file! Luckily I documented what we did in our internal wiki. I have found the following section: Migration from FreeIPA 3.0.0 to FreeIPA 4.1.0 kinit admin ipa config-mod --enable-migration=TRUE ipa-compat-manage disable ipactl restart The migration function uses the script /usr/lib/python2.7/site-packages/ipalib/plugins/migration.py. This contains some useful comments, including the parameters for an IPA to IPA migration! ipa migrate-ds --group-overwrite-gid --user-container='cn=users,cn=accounts' --group-container='cn=groups,cn=accounts' ldap://url of old FreeIPA server:389 ipa-compat-manage enable ipactl restart This copies all the users, and the groups - other than admin. This means that users that were members of the admins group on the old instance will not be added to admins group on the new instance. They must be readded, either via the Web UI, or CLI: su - admin, ipa group-add-member admins --users=bilbo Note that at the time we makng things up as we went along, so very possibly this was not the best way 8-) but it worked for us. Chris From: Martin Kosek mko...@redhat.com To: Christopher Lamb/Switzerland/IBM@IBMCH, Tamas Papp tom...@martos.bme.hu Cc: freeipa-users@redhat.com Date: 10.06.2015 15:35 Subject:Re: [Freeipa-users] migrating 3.0 - 4.1: passwords not migrated? On 06/10/2015 03:32 PM, Christopher Lamb wrote: Hi Tamas I think the general advice is to replicate rather than to migrate. I am sure Martin K will jump in on this. Yes :-) However some weeks ago, when doing a very similar move to yours, we chose to migrate (we were misled by some very old FreeIPA docus that have since been archived). In our case passwords were successfully migrated, so the users were able to use the same user / password combo as before. I will see if I can dig out the migrate command we used at the time. Did you use the migration command advised in https://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA ? Chris From: Tamas Papp tom...@martos.bme.hu To:freeipa-users@redhat.com Date: 10.06.2015 15:19 Subject: [Freeipa-users] migrating 3.0 - 4.1: passwords not migrated? Sent by: freeipa-users-boun...@redhat.com hi, Currently there are CentOS 6.5 servers and IPA 3.0. The goal is migrating users to CentOS 7.1 and IPA 4.1. This is the command I use: $ ipa migrate-ds ldap://ipa11 --user-container=cn=users,cn=accounts,dc=foo --group-container=cn=groups,cn=accounts,dc=foo --base-dn=dc=foo --with-compat ~/.pw.manager Users are migrated successfully but password must be reset, otherwise they cannot logon. Any idea, what's going on? I also have a bonus question. How can I migrate the cn=sysaccounts,cn=etc,dc=cxn tree? Do I need to export/import it as ldif and that's all? Thanks, tamas -- 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] migrating 3.0 - 4.1: passwords not migrated?
On Wed, 10 Jun 2015, Christopher Lamb wrote: Hi Martin and Tamas My source was a different one, i found a hint in a ipa python file! Luckily I documented what we did in our internal wiki. I have found the following section: Migration from FreeIPA 3.0.0 to FreeIPA 4.1.0 kinit admin ipa config-mod --enable-migration=TRUE ipa-compat-manage disable ipactl restart The migration function uses the script /usr/lib/python2.7/site-packages/ipalib/plugins/migration.py. This contains some useful comments, including the parameters for an IPA to IPA migration! Yes, and you'll get the same information if you just run 'ipa migration'. In general, all IPA commands grouped in topics and we have extensive documentation for them. Do 'ipa help topics' to see all topics Do 'ipa help topic' to see specific topic's documentation. -- / 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] ssh known hosts gets recreated on client
On 10/06/2015 14:37, Lukas Slebodnik wrote: On (10/06/15 11:33), Bob Hinton wrote: Hello, If I uninstall the ipa client with ipa-client-install --uninstall then reinstall it to the same ipa master then most functions work fine. However, if I attempt to ssh from the client to the master then I get. @@@ @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 86:c1:d7:96:8d:a3:b6:54:69:7c:cf:79:55:b3:14:c1. Please contact your system administrator. Add correct host key in /home/gbob/.ssh/known_hosts to get rid of this message. Offending key in /var/lib/sss/pubconf/known_hosts:1 RSA host key for ipa004.jackland.co.uk has changed and you have requested strict checking. Host key verification failed. I've tried stopping the sssd service on the client, removing /var/lib/sss/pubconf/known_hosts and /var/lib/sss/db/* then restarting sssd, but /var/lib/sss/pubconf just gets recreated with the old contents and I get the same error (it seems odd that it's reporting that the host key of the master has changed when it's the client that has been reinstalled). How do I clear-out the client's knowledge of the old host keys? In this case I'm using ipa-client v3.0.0 on RHEL6.6 You removed /var/lib/sss/pubconf/known_hosts and also sssd cache, but you still have problem after restarting sssd. So the only explanation is that wrong host public key is stored in FreeIPA. Could you try to check host public key with ldapsearch in FreeIPA. I think you wold need to do it as an admin. LS . The two rsa keys look like they're the same (see below) though the finger-prints are evidently different. I copied and pasted the two keys into files and ran diff over these to prove that they match. I can actually fix the problem by copying the ipa master host keys to a file, removing them with ipa host-mod ipa004.jackland.co.uk --sshpubkey='' then I can ssh from the client to the master without the error. I can finally restore the keys from the file using the ipa host-mod command again and all is well. So this looks like a long-winded way of clearing some sort of cache of the key finger-print on the client. It would just be nice to know if there's a more direct way of doing this. Also I know this works for one client, but it would be a pain to have to go through this procedure for lots of them. Thanks Bob -sh-4.2$ ipa host-show ipa004.jackland.co.uk --all dn: fqdn=ipa004.jackland.co.uk,cn=computers,cn=accounts,dc=jackland,dc=co,dc=uk Host name: ipa004.jackland.co.uk Principal name: host/ipa004.jackland.co...@jackland.co.uk SSH public key: ssh-rsa B3NzaC1yc2EDAQABAAABAQClPcH8nnghnG3+knwkdg70I106jxO/zIeKggF71C4OHLCu0MJ/loEOcySZ2WH5YPWzRhX1LVN9FyDUKiOc3SNKnjpxjPsJXxk7r77X99jPmk+1QBgYGpn4yrYw/ebEAQLSjHGK86KfNvIbG2RSbNn6uQzC/mciXLEO+7lQ6Vq+DE3Du7+2iuyC2qKeNA9VVzc1NLm0phHT5nOKHpUZ3208GK1vn6r/5YiPmPy5zh8cGmedRft2Fc/J0rOlw5zvwW6kKYZldLvBK7xD2Pm3i2fs38nkH1JA3t83/FXXR/S/F7cY9aI1J/s/UuzawYmeBFXhrbexsUJicY7sS4LqtfBl, ssh-ed25519 C3NzaC1lZDI1NTE5ILt/SPXhj9izWvjQv5ChWozlOgqRzmSFMZkVj4amRGh/, ecdsa-sha2-nistp256 E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBM4R+8D6KCGntBbpGhwDzgH7YJt0xw1Ze21NH+rlsfnoLFStuM7T46/T1L2b2II8hwCmu6dt7F+NSd4YXUpk0/M= Requires pre-authentication: True Trusted for delegation: False Password: False Keytab: True Managed by: ipa004.jackland.co.uk Managing: ipa004.jackland.co.uk SSH public key fingerprint: DA:92:FD:52:AE:C2:65:00:9A:F6:0B:AA:20:51:8E:04 (ssh-rsa), 53:79:39:CE:D8:13:23:D2:3C:2C:8E:E4:56:7E:41:76 (ssh-ed25519), 56:28:C4:62:3F:64:18:5D:EC:B9:E0:1F:8B:48:EA:0B (ecdsa-sha2-nistp256) cn: ipa004.jackland.co.uk ipauniqueid: 0ffd1566-fd61-11e4-b868-000c29f1a817 krblastpwdchange: 20150518132324Z objectclass: ipaSshGroupOfPubKeys, ipaobject, krbprincipal, nshost, top, ipaservice, pkiuser, ipahost, krbticketpolicyaux, krbprincipalaux, ipasshhost serverhostname: ipa004 -sh-4.2$ -sh-4.1$ ssh ipa004.jackland.co.uk @@@ @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 86:c1:d7:96:8d:a3:b6:54:69:7c:cf:79:55:b3:14:c1. Please contact your system administrator. Add correct
Re: [Freeipa-users] Installing a replica with alternate 'admin' username
Brian Mathis wrote: I have renamed the default 'admin' account to something else to avoid possible conflicts with other application accounts. However, when I try to install a replica with ipa-replica-install, it uses 'admin' as the username and I don't see a way to supply an alternate account name to use. I have been able to work-around this by using the --skip-conncheck option, but I would still like to have the script go through that process if possible to get the added verification that things are working. Is there any way to use a different account name than 'admin' with ipa-replica-install? I'm on CentOS 7 using ipa-server-4.1.0-18.el7. There isn't currently. I opened https://fedorahosted.org/freeipa/ticket/5060 The conn checker, ipa-replica-conncheck, actually takes the principal as an argument but this is hardcoded as admin in ipa-replica-install. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] add suse 11 sp3 to ipa
hido you know where is the path of certification file and certification key file for clients? From: Rob Crittenden rcrit...@redhat.com To: mohammad sereshki mohammadseres...@yahoo.com; Freeipa-users freeipa-users@redhat.com Sent: Tuesday, June 9, 2015 10:29 PM Subject: Re: [Freeipa-users] add suse 11 sp3 to ipa mohammad sereshki wrote: hi Would you please let me know is it possible to add suse 11 sp3 to IPA? and how it is possible? Regards I'm not sure if any version of SUSE has ipa-client or freeipa-client, but I know that 12+ has sssd. If 11 also has sssd then you can configure that part using this: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/linux-manual.html Note that a bunch of the steps don't really apply to you, like getting a host cert. Oddly enough, the docs don't include setting up krb5.conf, but you can get the jist of that from an ipa-cleint enrolled client. If you don't have sssd then you'll need to go the nss_ldap route. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Installing a replica with alternate 'admin' username
I have renamed the default 'admin' account to something else to avoid possible conflicts with other application accounts. However, when I try to install a replica with ipa-replica-install, it uses 'admin' as the username and I don't see a way to supply an alternate account name to use. I have been able to work-around this by using the --skip-conncheck option, but I would still like to have the script go through that process if possible to get the added verification that things are working. Is there any way to use a different account name than 'admin' with ipa-replica-install? I'm on CentOS 7 using ipa-server-4.1.0-18.el7. ❧ Brian Mathis @orev -- 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] ssh known hosts gets recreated on client
OK. I think the original problem wasn't what I thought it was. The keys in /etc/ssh/*.pub on the ipamaster didn't match the ones stored in IPA. I'm not sure how this happened, however the master is a test VM that's been used to test ipa-backup and ipa-restore (it's a V4.1.0 master even though the client is V3.0) Anyway, I repaired this by setting the keys in IPA to the ones in the files by doing the following on the ipa master :- echo ipa host-mod ipa004.jackland.co.uk --sshpubkey=' keyfix.sh sudo cat /etc/ssh/ssh_host_rsa_key.pub keyfix.sh echo -n ',' keyfix.sh sudo cat /etc/ssh/ssh_host_ecdsa_key.pub keyfix.sh echo -n ',' keyfix.sh sudo cat /etc/ssh/ssh_host_ed25519_key.pub keyfix.sh echo ' keyfix.sh vi keyfix.sh (keep pressing J to join everything into one long line) sh keyfix.sh On 10/06/2015 17:09, Bob Hinton wrote: On 10/06/2015 14:37, Lukas Slebodnik wrote: On (10/06/15 11:33), Bob Hinton wrote: Hello, If I uninstall the ipa client with ipa-client-install --uninstall then reinstall it to the same ipa master then most functions work fine. However, if I attempt to ssh from the client to the master then I get. @@@ @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 86:c1:d7:96:8d:a3:b6:54:69:7c:cf:79:55:b3:14:c1. Please contact your system administrator. Add correct host key in /home/gbob/.ssh/known_hosts to get rid of this message. Offending key in /var/lib/sss/pubconf/known_hosts:1 RSA host key for ipa004.jackland.co.uk has changed and you have requested strict checking. Host key verification failed. I've tried stopping the sssd service on the client, removing /var/lib/sss/pubconf/known_hosts and /var/lib/sss/db/* then restarting sssd, but /var/lib/sss/pubconf just gets recreated with the old contents and I get the same error (it seems odd that it's reporting that the host key of the master has changed when it's the client that has been reinstalled). How do I clear-out the client's knowledge of the old host keys? In this case I'm using ipa-client v3.0.0 on RHEL6.6 You removed /var/lib/sss/pubconf/known_hosts and also sssd cache, but you still have problem after restarting sssd. So the only explanation is that wrong host public key is stored in FreeIPA. Could you try to check host public key with ldapsearch in FreeIPA. I think you wold need to do it as an admin. LS . The two rsa keys look like they're the same (see below) though the finger-prints are evidently different. I copied and pasted the two keys into files and ran diff over these to prove that they match. I can actually fix the problem by copying the ipa master host keys to a file, removing them with ipa host-mod ipa004.jackland.co.uk --sshpubkey='' then I can ssh from the client to the master without the error. I can finally restore the keys from the file using the ipa host-mod command again and all is well. So this looks like a long-winded way of clearing some sort of cache of the key finger-print on the client. It would just be nice to know if there's a more direct way of doing this. Also I know this works for one client, but it would be a pain to have to go through this procedure for lots of them. Thanks Bob -sh-4.2$ ipa host-show ipa004.jackland.co.uk --all dn: fqdn=ipa004.jackland.co.uk,cn=computers,cn=accounts,dc=jackland,dc=co,dc=uk Host name: ipa004.jackland.co.uk Principal name: host/ipa004.jackland.co...@jackland.co.uk SSH public key: ssh-rsa B3NzaC1yc2EDAQABAAABAQClPcH8nnghnG3+knwkdg70I106jxO/zIeKggF71C4OHLCu0MJ/loEOcySZ2WH5YPWzRhX1LVN9FyDUKiOc3SNKnjpxjPsJXxk7r77X99jPmk+1QBgYGpn4yrYw/ebEAQLSjHGK86KfNvIbG2RSbNn6uQzC/mciXLEO+7lQ6Vq+DE3Du7+2iuyC2qKeNA9VVzc1NLm0phHT5nOKHpUZ3208GK1vn6r/5YiPmPy5zh8cGmedRft2Fc/J0rOlw5zvwW6kKYZldLvBK7xD2Pm3i2fs38nkH1JA3t83/FXXR/S/F7cY9aI1J/s/UuzawYmeBFXhrbexsUJicY7sS4LqtfBl, ssh-ed25519 C3NzaC1lZDI1NTE5ILt/SPXhj9izWvjQv5ChWozlOgqRzmSFMZkVj4amRGh/, ecdsa-sha2-nistp256 E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBM4R+8D6KCGntBbpGhwDzgH7YJt0xw1Ze21NH+rlsfnoLFStuM7T46/T1L2b2II8hwCmu6dt7F+NSd4YXUpk0/M= Requires pre-authentication: True Trusted for delegation: False Password: False Keytab: True Managed by: ipa004.jackland.co.uk Managing: ipa004.jackland.co.uk SSH public key fingerprint: DA:92:FD:52:AE:C2:65:00:9A:F6:0B:AA:20:51:8E:04 (ssh-rsa), 53:79:39:CE:D8:13:23:D2:3C:2C:8E:E4:56:7E:41:76 (ssh-ed25519), 56:28:C4:62:3F:64:18:5D:EC:B9:E0:1F:8B:48:EA:0B (ecdsa-sha2-nistp256)
Re: [Freeipa-users] add suse 11 sp3 to ipa
Hi, On Tue, 9 Jun 2015, Rob Crittenden wrote: mohammad sereshki wrote: Would you please let me know is it possible to add suse 11 sp3 to IPA? and how it is possible? I'm not sure if any version of SUSE has ipa-client or freeipa-client, but I know that 12+ has sssd. If 11 also has sssd then you can configure that part using this: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/linux-manual.html Note that a bunch of the steps don't really apply to you, like getting a host cert. Oddly enough, the docs don't include setting up krb5.conf, but you can get the jist of that from an ipa-cleint enrolled client. If you don't have sssd then you'll need to go the nss_ldap route. I have a bunch of openSUSE 13.2 machines which work fine with sssd from standard repos (after manual installation as described in the above document - you can, however, make a powerful autoyast recipe that includes configuration files, certs and Kerberos host keys to automate the complete installation process). I recall that i had to use an extra repository for sssd and earlier versions of openSUSE Linux: http://download.opensuse.org/repositories/network:/ldap/ There seems to be indeed no sssd for SLE11 SP3, only nss_ldap. Mit freundlichen Gruessen/With best regards, --Daniel. -- 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
