November 2017 - FreeIPA-users - Fedora mailing-lists

PWM and FreeIPA integration
by Aaron Hicks 16 Nov '17

16 Nov '17

Hello the FreeIPA List, So as using the FreeIPA API and using LDAP directly to set existing users passwords (because they don't yet have one) didn't work, we've set up PWM by mostly following this gist: https://gist.github.com/PowerWagon/d794a1233d7943f1614d2ae5223e678a This has worked, and users with existing passwords can log in an manage their passwords. We are not using it to create user accounts. However we have some users who do not have passwords, so they can't provide a current password to do a password change. We have a page on our customer management system that allows users with no password to enter a password and this is sent to the PWM REST interface to set the user's password in FreeIPA. The user is not new, they just have no password set. There's a couple of thousand of them, so we're really keen on self service. However when we send a password reset request to the PWM REST with the setpassword command (using the pwmproxy user credentials) we get the following response: {"error":true,"errorCode":5027,"errorMessage":"You do not have permission to perform the requested action."} We've tried making the pwmproxy user a admin, and have giving them permission to change users passwords with the System: Change User password permission, however this gives the same response. I'd prefer not to give the pwmproxy account admin, but we need this to work. We've also tried using the admin account with the same results, we'd prefer to use an API key but have not yet managed to authenticate with one. I'm asking here as PWM is recommended by FreeIPA as a suitable 3rd Party project https://www.freeipa.org/page/Self-Service_Password_Reset I feel we're one step away from making this work. Is there a specific permission, aci, or other hoop to jump through to allow PWM to set a user's password? Regards, Aaron Hicks

2 2

pointing SSSD/IPA at named AD domain controllers now with recent updates?
by Chris Dagdigian 16 Nov '17

16 Nov '17

The most fragile and user-angering aspect of our complex IPA setup in AWS is when user AD password checks mysteriously fail and deny login. All of the troubleshooting stuff works fine - user is recognized as valid, ipa hbactest all work fine but the user gets permission denied when logging in. Right now my only fix is converting users over to SSH keybased logins with the IPA server holding the public key -- that works great. Restarting sssd a few times and waiting 10 minutes also usually resolves the issue. We *suspect* the password check failure is because this large organization has 100+ domain controllers scattered in networks and datacenters all over the place and we think that maybe SSSD is DNS resolving via _SVR_ records a domain controller that is unreachable or unknown to our cloud nACLs and security controls -- or maybe a domain controller that just flat out refuses to talk to us. I've seen on this list mentions of really cool AD integration improvements like being able to have more than one AD domain vs the existing "Default domain" that requires our users to login with fully qualified <username>@<DOMAIN>.COMPANY.ORG as well as mentions that future versions of SSSD would allow us to pin our communication to known/named AD controllers? I think the basic advice from the IPA community was that this stuff was showing up in modern sssd releases and that we just had to wait a bit for the updated sssd code to show up in distro repos. Did I understand things correctly? Are we at the point now with IPA and SSD upgrades where we could possibly pin our AD traffic to named controllers? And maybe also address the AD domain search issue as well? Thanks! Chris

2 1

Can't sync a new replica, large db file,
by Mike Johnson 16 Nov '17

16 Nov '17

Hi I've got a small environment which had until recently 2 IPA servers. Both CentOS 7.4.1708 Version info: id1: Name : ipa-server Version : 4.5.0 Release : 21.el7.centos.2.2 Kernel: 3.10.0-693.5.2.el7.x86_64 389-ds-base is at version 1.3.6.1 id5: Name : ipa-server Version : 4.5.0 Release : 21.el7.centos.2.2 Kernel: 3.10.0-693.5.2.el7.x86_64 389-ds-base is at version 1.3.6.1 I recently had an issue with high IO/load, and noted that the following file: /var/lib/dirsrv/slapd-PROD-MYDOMAIN-COM/cldb/<long-filename>.db was huge (5GB-ish) in a very small 2-master environment. This is on the master. My understanding is that the entries in this file, which have timestamps from months ago, exist because of failed replication. I don't understand how to clear this without breaking things. Second issue; not sure if related: I've since lost the replica (id2) but I've prepared a new machine (id5) to be a new replica of id1. I've cleaned the RUVs and deleted the replication agreements but when I join the new machine to the existing one using `ipa-replica-install` then I get the following on the replica: ################ Starting replication, please wait until this has completed. Update in progress, 10 seconds elapsed [ldap://id1.prod.mydomain.com:389] reports: Update failed! Status: [-11 connection error: Unknown connection error (-11) - Total update aborted] [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR Failed to start replication ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information [root@id5 ~]# ipa-replica-manage re-initialize --from id1.prod.mydomain.com Re-run /usr/sbin/ipa-replica-manage with --verbose option to get more information Unexpected error: cannot connect to 'ldaps://id5.prod.mydomain.com:636': ################ and the following on the master: ################ [14/Nov/2017:10:05:28.671905981 +0000] - INFO - NSMMReplicationPlugin - repl5_tot_run - Beginning total update of replica "agmt="cn=meToid5.prod.mydomain.com" (id5:389)". [14/Nov/2017:10:05:38.031033860 +0000] - ERR - NSMMReplicationPlugin - repl5_tot_log_operation_failure - agmt="cn=meToid5.prod.mydomain.com" (id5:389): Received error -1 (Can't contact LDAP server): for total update operation [14/Nov/2017:10:05:38.032272148 +0000] - ERR - NSMMReplicationPlugin - release_replica - agmt="cn=meToid5.prod.mydomain.com" (id5:389): Unable to send endReplication extended operation (Can't contact LDAP server) [14/Nov/2017:10:05:38.095893236 +0000] - ERR - NSMMReplicationPlugin - repl5_tot_run - Total update failed for replica "agmt="cn=meToid5.prod.mydomain.com" (id5:389)", error (-11) [14/Nov/2017:10:05:38.113388624 +0000] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToid5.prod.mydomain.com" (id5:389): Replication bind with GSSAPI auth resumed [14/Nov/2017:10:05:38.425682940 +0000] - WARN - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=meToid5.prod.mydomain.com" (id5:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. ################ I've checked the firewalls on both machines, and gone as far as to flush all the iptables rules to get it to work. No luck. I'm also getting hundreds of the last line "different database generation ID" but my understanding is that this is only logged because the replica is yet to be set up. Would anyone please be able to provide some guidance? I've been at this for a few days now! Thanks! MIke

2 8

IPA & AD Domain Layout
by Justin Smith 16 Nov '17

16 Nov '17

I was tasked with setting up FreeIPA & Active Directory and connecting them with a trust relationship. On FreeIPA 4.5, I created ipa.companydomain.com, set up an internal DNS zone for companydomain.com (which my company has used for both internal and external DNS - a bad practice, I know), and then tried to establish a trust relationship with Active Directory 2016. No dice. Alexander B. on here told me that AD does not expect that a forest can have a TLN which is superior to AD forest's root domain. A Microsoft article on AD best practices recommends registering a public domain and then using a subdomain of that for internal purposes. That sounds sensible. Here's what I envision: companyname.com (external sites + external DNS) -> corp.companyname.com (FreeIPA + intranet DNS) -> ad.corp.companyname.com (Active Directory domain) Does that sound sensible? Just wanted to run it by someone else so I don't end up surprised again. --- Justin Smith IT Analyst MIM Software, Inc. [ https://www.mimsoftware.com/ | https://www.mimsoftware.com ]

2 1

adding services to freeipa
by Andrew Meyer 16 Nov '17

16 Nov '17

When I try to add puppet i am getting the following error: [andrew.meyer@asm-automation01 ~]$ ipa service-add puppetmaster/asm-automation01.mgt.asm.borg.localipa: ERROR: Host 'asm-automation01.mgt.asm.borg.local' does not have corresponding DNS A/AAAA record[andrew.meyer@asm-automation01 ~]$ I joined the server to the FreeIPA domain and there is an A record. Didn't check fro quad-A. Not sure why it's throwing this error.

2 3

FreeIPA server: Replication issues
by James Harrison 15 Nov '17

15 Nov '17

Hello,I am using Centos to host our FreeIPA servers. We have a CA-less setup. I have upgraded to Centos 7.4 and FreeIPA version : VERSION: 4.5.0, API_VERSION: 2.228 The upgrade of both went off without any seen errors. However, now I am getting the following messages on each server (12 in total): "ERR - attrlist_replace - attr_replace (nsslapd-referral" messages Firstly, are these messages real problems I need to deal with?Secondly, if they are problems, how do I fix them? I have searched the internet and found lots of confusing mail threads, but no howto style document. Thanks for any help. Regards,James Harrison

2 1

Re: ERROR: did not receive Kerberos credentials
by Carl Gola 15 Nov '17

15 Nov '17

Looks like it was finding kinit as part of java I used the full path below but my personal ipa id generates an error but the admin id works ok [root@test-nfs-prod-1 ~]# rpm --info -qf $(which kinit) file /opt/ibm/ibm-java-x86_64-8.0-1.10/jre/bin/kinit is not owned by any package [root@test-nfs-prod-1 ~]# find / -name kinit /usr/bin/kinit /usr/lib/jvm/java-1.8.0-ibm-1.8.0.4.10-1jpp.3.el7.x86_64/jre/bin/kinit /opt/ibm/ibm-java-x86_64-8.0-1.10/jre/bin/kinit [root@test-nfs-prod-1 ~]# rpm --info -qf /usr/bin/kinit Name : krb5-workstation Version : 1.15.1 Release : 8.el7 Architecture: x86_64 Install Date: Fri 27 Oct 2017 07:55:03 PM UTC Group : System Environment/Base Size : 2606453 License : MIT Signature : RSA/SHA256, Wed 03 May 2017 09:39:47 AM UTC, Key ID 199e2f91fd431d51 Source RPM : krb5-1.15.1-8.el7.src.rpm Build Date : Fri 28 Apr 2017 08:01:32 PM UTC Build Host : x86-034.build.eng.bos.redhat.com Relocations : (not relocatable) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> Vendor : Red Hat, Inc. URL : http://web.mit.edu/kerberos/www/ Summary : Kerberos 5 programs for use on workstations Description : Kerberos is a network authentication system. The krb5-workstation package contains the basic Kerberos programs (kinit, klist, kdestroy, kpasswd). If your network uses Kerberos, this package should be installed on every workstation. [gola-us@test-nfs-prod-1 ~]$ /usr/bin/kinit gola-us kinit: Client's entry in database has expired while getting initial credentials kinit with the admin id works ok [root@test-nfs-prod-1 ~]# /usr/bin/kinit admin Password for admin(a)test.LOCAL: [root@test-nfs-prod-1 ~]# ipa user-find ---------------- 70 users matched ---------------- User login: admin Last name: Administrator Home directory: /home/admin etc.. Thanks, Carl Gola From: Robbie Harwood via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org> To: Carl Gola <gola(a)us.ibm.com>, FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> Cc: Robbie Harwood <rharwood(a)redhat.com> Date: 11/15/2017 09:47 AM Subject: [Freeipa-users] Re: ERROR: did not receive Kerberos credentials "Carl Gola" <gola(a)us.ibm.com> writes: > I'm not sure what's printing Done! either > > Here is a fresh kinit and klist afterwards > > [gola-us@test-nfs-prod-1 ~]$ kinit gola-us > Password for gola-us(a)test.LOCAL: > > Done! > New ticket is stored in cache file /home/rusers/gola-us/krb5cc_gola-us > [gola-us@test-nfs-prod-1 ~]$ klist > > Credentials cache: /home/rusers/gola-us/krb5cc_gola-us > Default principal: gola-us(a)test.LOCAL > Number of entries: 1 > > [1] Service principal: krbtgt/test.LOCAL(a)test.LOCAL > Valid starting: Wednesday, November 15, 2017 at 4:03:26 PM > Expires: Thursday, November 16, 2017 at 4:03:26 PM Hmm, this doesn't look like MIT krb5; what is it? ( `rpm --info -qf $(which kinit)` or `apt show $(dpkg -S $(which kinit) | awk -F: '{print $1}')` depending on what OS you're on.) Does Kerberos issue a service ticket as part of the user-find command, or does it not get that far? (klist, and server logs will tell this.) Thanks, --Robbie (See attached file: signature.asc) _______________________________________________ FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org

1 0

Re: ERROR: did not receive Kerberos credentials
by Carl Gola 15 Nov '17

15 Nov '17

I'm not sure what's printing Done! either Here is a fresh kinit and klist afterwards [gola-us@test-nfs-prod-1 ~]$ kinit gola-us Password for gola-us(a)test.LOCAL: Done! New ticket is stored in cache file /home/rusers/gola-us/krb5cc_gola-us [gola-us@test-nfs-prod-1 ~]$ klist Credentials cache: /home/rusers/gola-us/krb5cc_gola-us Default principal: gola-us(a)test.LOCAL Number of entries: 1 [1] Service principal: krbtgt/test.LOCAL(a)test.LOCAL Valid starting: Wednesday, November 15, 2017 at 4:03:26 PM Expires: Thursday, November 16, 2017 at 4:03:26 PM Thanks, Carl Gola From: Robbie Harwood via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org> To: Carl Gola via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>, FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> Cc: Carl Gola <gola(a)us.ibm.com>, Robbie Harwood <rharwood(a)redhat.com> Date: 11/15/2017 08:58 AM Subject: [Freeipa-users] Re: ERROR: did not receive Kerberos credentials Carl Gola via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org> writes: > Receiving the following error when trying to run ipa commands > > [gola-us@test-nfs-prod-1 ~]$ kinit gola-us > Password for gola-us(a)test.LOCAL: > > Done! What's printing "Done!" here? kinit doesn't do that that I'm aware. > New ticket is stored in cache file /home/rusers/gola-us/krb5cc_gola-us What happens if you klist this file after kinit? Thanks, --Robbie (See attached file: signature.asc) _______________________________________________ FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org

2 1

ERROR: did not receive Kerberos credentials
by Carl Gola 15 Nov '17

15 Nov '17

Receiving the following error when trying to run ipa commands [gola-us@test-nfs-prod-1 ~]$ kinit gola-us Password for gola-us(a)test.LOCAL: Done! New ticket is stored in cache file /home/rusers/gola-us/krb5cc_gola-us [gola-us@test-nfs-prod-1 ~]$ ipa user-find ipa: ERROR: did not receive Kerberos credentials [gola-us@test-nfs-prod-1 ~]$ Linux version - Red Hat Enterprise Linux Server release 7.3 (Maipo) client ipa-client-4.5.0-21.el7_4.2.2.x86_64 server ipa-server-dns-4.5.0-21.el7_4.2.2.noarch ipa-client-4.5.0-21.el7_4.2.2.x86_64 ipa-server-common-4.5.0-21.el7_4.2.2.noarch ipa-server-4.5.0-21.el7_4.2.2.x86_64 ipa-server-trust-ad-4.5.0-21.el7_4.2.2.x86_64 ipa-common-4.5.0-21.el7_4.2.2.noarch ipa-client-common-4.5.0-21.el7_4.2.2.noarch If I change the location of the cache file - export KRB5CCNAME=/tmp/.krb5cc-gola I do a kinit gola-us and an ipa command returns this [gola-us@test-nfs-prod-1 ~]$ kinit gola-us Password for gola-us(a)test.LOCAL: Done! New ticket is stored in cache file /tmp/.krb5cc-gola [gola-us@test-nfs-prod-1 ~]$ ipa user-find ipa: ERROR: cannot connect to 'any of the configured servers': https://test-ipa-prod-1.test.local/ipa/json, https://test-ipa-prod-2.test.local/ipa/json reviewing the krb5 logs shows normal communication between the client and the ipa server. kerberos tickets are generated normally Thanks, Carl Gola

2 1

easy way to check ipa-client status
by email＠ml.jacobdevans.com 15 Nov '17

15 Nov '17

So....rarely, a second server is built with the same fqdn, causing an issue with the original server kerberos realm membership...thing. Is there an easy way to check/confirm this similar to how you'd check the computer accounts for M$ AD? Thanks in advance! -Jake

2 1

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users November 2017