From sbose at redhat.com Tue Apr 1 07:19:10 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 1 Apr 2014 09:19:10 +0200 Subject: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate In-Reply-To: <95da496c517c455281c0833c200367f0@BY2PR03MB176.namprd03.prod.outlook.com> References: <5339EF9B.3070606@redhat.com> <94b3969cbcd3400d804b4c3dc4332fd7@BY2PR03MB176.namprd03.prod.outlook.com> <5339F1B0.8030209@redhat.com> <95da496c517c455281c0833c200367f0@BY2PR03MB176.namprd03.prod.outlook.com> Message-ID: <20140401071910.GD11404@localhost.localdomain> On Mon, Mar 31, 2014 at 11:05:18PM +0000, Todd Maugh wrote: > > [root at black-62 sssd]# tail -f sssd_ops.boingo.com.log > (Mon Mar 31 22:58:01 2014) [sssd[be[ops.boingo.com]]] [be_resolve_server_done] (4): Found address for server idm-master-els.ops.boingo.com: [172.22.170.46] TTL 7200 > (Mon Mar 31 22:58:01 2014) [sssd[be[ops.boingo.com]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: host/black-62.qa.boingo.com > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [child_sig_handler] (4): child [13134] finished successfully. > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [fo_set_port_status] (4): Marking port 0 of server 'idm-master-els.ops.boingo.com' as 'working' > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [set_server_common_status] (4): Marking server 'idm-master-els.ops.boingo.com' as 'working' > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [be_run_online_cb] (3): Going online. Running callbacks. > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [delayed_online_authentication_callback] (5): Backend is online, starting delayed online authentication. > (Mon Mar 31 22:59:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] > (Mon Mar 31 22:59:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success > (Mon Mar 31 23:00:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] > (Mon Mar 31 23:00:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success > (Mon Mar 31 23:01:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] > (Mon Mar 31 23:01:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success > (Mon Mar 31 23:02:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] > (Mon Mar 31 23:02:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success > (Mon Mar 31 23:03:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] > (Mon Mar 31 23:03:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success The log does not show any authentication or PAM related activities. Please increase the debug_level and check for PAM related messages like e.g. "[pam_print_data] (0x0100): command: PAM_AUTHENTICATE". If there are no such messages, please check your PAM configuration as Dmitri suggested. HTH bye, Sumit > > I see this in the sssd Logs but still not authenticating > > will check out AVC and SELinux very frustrating > > > ________________________________________ > From: Rob Crittenden > Sent: Monday, March 31, 2014 3:52 PM > To: Todd Maugh; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate > > Todd Maugh wrote: > > HBAC rules are set to allow_all enabled > > Ok. I'd start with increasing the sssd log level and see what it says. > > I gather that basic nss works since you can kinit as other users. > > You may want to check for SELinux AVCs as well. > > rob > > > > > -----Original Message----- > > From: Rob Crittenden [mailto:rcritten at redhat.com] > > Sent: Monday, March 31, 2014 3:44 PM > > To: Todd Maugh; freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate > > > > Todd Maugh wrote: > >> Hi, > >> > >> I have a rhel5 client I had problems with my IPA environment and had > >> to rebuild > >> > >> I'm on the latest version of IPA with a red hat 6 server > >> > >> I successfully enrolled the client to the new server (same domain, > >> same > >> realm) I had removed all old certs, sysrestores, and ipa/default.conf > >> > >> I can ssh to the box as root, and then either su or kinit to any IPA > >> user with out issue > >> > >> But when I try to ssh as the ipauser to the box it gives me permission > >> denied, please try again > >> > >> I cleared out the sssd cache and restarted sssd > >> > >> Is there something I'm missing or a log to check? > >> > >> I need to worked this out before I move forward enrolling other > >> previously enrolled clients. > > > > Check your HBAC rules. > > > > rob > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From sanchez.nevada at gmail.com Tue Apr 1 09:46:19 2014 From: sanchez.nevada at gmail.com (Nevada Sanchez) Date: Tue, 1 Apr 2014 05:46:19 -0400 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) Message-ID: I've had a replica working with FreeIPA 3.2.1 for awhile. After upgrading to 3.3.4, the replica wouldn't recognize my admin login anymore. After much troubleshooting, I decided to try to redo the replica since it was quite straightforward when I first set it up (what could go wrong, right?) Unfortunately, I've spent most of my day trying to get the replica to work this time. I've tried turning off all firewalls on both machines, rebooting both machines, upgrading all packages on both machines (both are running Fedora 19), reinstalling FreeIPA packages, and several other things, but I keep getting stuck at the same step (see output below). ================================================================= [root at ipa2 ipaserver]# ipa-replica-install --setup-dns --no-forwarders /var/lib/ipa/replica-info-ipa2.example.com.gpg WARNING: conflicting time&date synchronization service 'chronyd' will be disabled in favor of ntpd Run connection check to master Check connection from replica to remote master 'ipa.example.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'ipa2.example.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/34]: creating directory server user [2/34]: creating directory server instance [3/34]: adding default schema [4/34]: enabling memberof plugin [5/34]: enabling winsync plugin [6/34]: configuring replication version plugin [7/34]: enabling IPA enrollment plugin [8/34]: enabling ldapi [9/34]: configuring uniqueness plugin [10/34]: configuring uuid plugin [11/34]: configuring modrdn plugin [12/34]: configuring DNS plugin [13/34]: enabling entryUSN plugin [14/34]: configuring lockout plugin [15/34]: creating indices [16/34]: enabling referential integrity plugin [17/34]: configuring ssl for ds instance [18/34]: configuring certmap.conf [19/34]: configure autobind for root [20/34]: configure new location for managed entries [21/34]: configure dirsrv ccache [22/34]: enable SASL mapping fallback [23/34]: restarting directory server [24/34]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 5 seconds elapsed [ipa.example.com] reports: Update failed! Status: [-1 Total update abortedLDAP error: Can't contact LDAP server] Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Failed to start replication ================================================================= I've confirmed that I can do ldapsearch from each machine to the other one for the replica status records (through ldap and ldaps), so I know that they can communicate. Trouble is, something behind the scenes is throwing the status error (as seen in the nsds5ReplicaLastInitStatus attribute). ================================================================= [root at ipa2 ipaserver]# ldapsearch ldaps://ipa.example.com:636 -D 'cn=Directory Manager' -w ##### -b 'cn=meToipa2.example.com,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config' '(objectClass=*)' -s base nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5ReplicaLastInitEnd # extended LDIF # # LDAPv3 # base with scope baseObject # filter: (objectclass=*) # requesting: ldaps://ipa.example.com:636 (objectClass=*) nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5ReplicaLastInitEnd # # meToipa2.example.com, replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config dn: cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cd c\3Dcom,cn=mapping tree,cn=config nsds5ReplicaLastInitStart: 20140401092800Z nsds5replicaUpdateInProgress: FALSE nsds5ReplicaLastInitStatus: -1 Total update abortedLDAP error: Can't contact L DAP server cn: meToipa2.example.com nsds5ReplicaLastInitEnd: 20140401092804Z # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ================================================================= I'd really love for someone to help out with this, as I can't afford another entire night trying to figure this out. Thanks in advance! -Nevada -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Apr 1 12:46:13 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Apr 2014 08:46:13 -0400 Subject: [Freeipa-users] Issue on import official cert of godaddy. In-Reply-To: References: <533976BF.2050602@redhat.com> <53397DB9.9020709@redhat.com> Message-ID: <533AB515.50201@redhat.com> barrykfl at gmail.com wrote: > I found the cause and remove the error. ...i used the bundle cert to > make the p12 file by official guide ...bnudle cert can use only even i > download another root ca cert of godday it fail says somelike local > chain error, > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > Anyway it really enter 3 entries A root CA , A sign CA , A server cert > ... BUT actaully the singer CA not present it is actually intermediate CERT. > I add it again by certutil then it error gone ...but still keeping the > 3 entries row ...no idea is the cert issue or not, > BTW i have another issue on web ui, when browsing service tag. i tried > to add all back of orginal IPA CA cert but doesnt help even remove..any > idea > ..??? > > Go Daddy Class 2 Certification Authority - The Go Daddy Group, Inc. ,, > Go Daddy Secure Certification Authority - The Go Daddy Group, Inc. CT,C,C > Server-Cert ,, > *.abc.com - GoDaddy.com, > Inc. u,u,u > ABC.COM IPA > CA CT,C,C > ipaCert ,, It is a different error, unrelated to trust. It looks like you don't have the private keys for Server-Cert and ipaCert. For Server-Cert it doesn't really matter since you're using your own, but ipaCert is required. I don't know if this is the cause of the error or something else. Hopefully you have a backup of the Apache database somewhere. You can use pk12util to export ipaCert out of that and import it into the current database. rob > Rgards > > 2014-03-31 22:39 GMT+08:00 >: > > There are already godaddy class and class 2 cert in it i wonder why > the error still comess > > 2014/3/31 ??10:37 ? "Rob Crittenden" > ??? > > barrykfl at gmail.com wrote: > > I follow the mAnual.using ipa cert install > > > > It will auto remove ipa cert after u insert godaddy . Should > i add them > > back? No.conflict? > > You only need to add in the CA. There will be no conflict. > > > 2)do.umeant ca root cert of godaddy ? Ialread try added any > ca root cert > > of godaddy the error still comes out > > You need to add the CA that issued the wildcard cert they gave you. > Typically there are one or more subordinate CAs that actually > issue the > certificates. > > rob > > > > > 2014/3/31 ??10:08 ? "Rob Crittenden" > > >> ??? > > > > barrykfl at gmail.com > > wrote: > > > > Dear all: > > I have succesfful impont certs to http and ldap but > some inssue > > arise. > > 1) when i click in service in the UI it still using > OLD entries > > of seld > > sign cert and given out error ...pls see attachment,. > > How to reflect the godaddy cert there and it cannot > be deleted .?? > > > > > > You're misreading this. The IPA CA is still installed and > has issued > > some certificates to some service (and probably hosts). > I'm guessing > > you removed the IPA CA certificate from /etc/httpd/alias. > You need > > to add it back to let IPA talk to its CA again. > > > > 2) when start up dirsrv it casue some warning out say: > > Starting dirsrv: > > ABS-COM...[31/Mar/2014:10:25:__59 +0800] - SSL > alert: > > CERT_VerifyCertificateNow: verify certificate > failed for cert > > *.wisers.com > > - > > GoDaddy.com, Inc. of family > > cn=RSA,c n=encryption,cn=config (Netscape > Portable Runtime error > > -8172 - Peer's certificate iss uer has been > marked as not > > trusted by > > the user.) > > any where i should import again to skip the error and > realize > > the change > > no prompt out errors? > > > > > > You need to add the GoDaddy CA cert chain to the 389-ds cert > > database in /etc/dirsrv/slapd-ABS-COM/ > > > > rob > > > > From tmaugh at boingo.com Tue Apr 1 14:17:43 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 1 Apr 2014 14:17:43 +0000 Subject: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate In-Reply-To: <20140401071910.GD11404@localhost.localdomain> References: <5339EF9B.3070606@redhat.com> <94b3969cbcd3400d804b4c3dc4332fd7@BY2PR03MB176.namprd03.prod.outlook.com> <5339F1B0.8030209@redhat.com> <95da496c517c455281c0833c200367f0@BY2PR03MB176.namprd03.prod.outlook.com> <20140401071910.GD11404@localhost.localdomain> Message-ID: I set my debug level to 5 and these were the messages I got. I checked the sshd_config and it seems to be using gsapi what lines should be uncommented or entered or set to true or yes for Pam. I tried the one pam line I saw to true. But it made no difference -----Original Message----- From: Sumit Bose [mailto:sbose at redhat.com] Sent: Tuesday, April 01, 2014 12:19 AM To: Todd Maugh Cc: Rob Crittenden; freeipa-users at redhat.com Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate On Mon, Mar 31, 2014 at 11:05:18PM +0000, Todd Maugh wrote: > > [root at black-62 sssd]# tail -f sssd_ops.boingo.com.log (Mon Mar 31 > 22:58:01 2014) [sssd[be[ops.boingo.com]]] [be_resolve_server_done] > (4): Found address for server idm-master-els.ops.boingo.com: > [172.22.170.46] TTL 7200 (Mon Mar 31 22:58:01 2014) [sssd[be[ops.boingo.com]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: host/black-62.qa.boingo.com (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [child_sig_handler] (4): child [13134] finished successfully. > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [fo_set_port_status] (4): Marking port 0 of server 'idm-master-els.ops.boingo.com' as 'working' > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [set_server_common_status] (4): Marking server 'idm-master-els.ops.boingo.com' as 'working' > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [be_run_online_cb] (3): Going online. Running callbacks. > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] > [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [delayed_online_authentication_callback] (5): Backend is online, starting delayed online authentication. > (Mon Mar 31 22:59:01 2014) [sssd[be[ops.boingo.com]]] > [be_get_account_info] (4): Got request for > [4097][1][name=tmp.XXXXUiK3X6] (Mon Mar 31 22:59:01 2014) > [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. > Returned 0,0,Success (Mon Mar 31 23:00:01 2014) > [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for > [4097][1][name=tmp.XXXXUiK3X6] (Mon Mar 31 23:00:01 2014) > [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. > Returned 0,0,Success (Mon Mar 31 23:01:01 2014) > [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for > [4097][1][name=tmp.XXXXUiK3X6] (Mon Mar 31 23:01:01 2014) > [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. > Returned 0,0,Success (Mon Mar 31 23:02:01 2014) > [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for > [4097][1][name=tmp.XXXXUiK3X6] (Mon Mar 31 23:02:01 2014) > [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. > Returned 0,0,Success (Mon Mar 31 23:03:01 2014) > [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for > [4097][1][name=tmp.XXXXUiK3X6] (Mon Mar 31 23:03:01 2014) > [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. > Returned 0,0,Success The log does not show any authentication or PAM related activities. Please increase the debug_level and check for PAM related messages like e.g. "[pam_print_data] (0x0100): command: PAM_AUTHENTICATE". If there are no such messages, please check your PAM configuration as Dmitri suggested. HTH bye, Sumit > > I see this in the sssd Logs but still not authenticating > > will check out AVC and SELinux very frustrating > > > ________________________________________ > From: Rob Crittenden > Sent: Monday, March 31, 2014 3:52 PM > To: Todd Maugh; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled > and enrolled to new server cant authenticate > > Todd Maugh wrote: > > HBAC rules are set to allow_all enabled > > Ok. I'd start with increasing the sssd log level and see what it says. > > I gather that basic nss works since you can kinit as other users. > > You may want to check for SELinux AVCs as well. > > rob > > > > > -----Original Message----- > > From: Rob Crittenden [mailto:rcritten at redhat.com] > > Sent: Monday, March 31, 2014 3:44 PM > > To: Todd Maugh; freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled > > and enrolled to new server cant authenticate > > > > Todd Maugh wrote: > >> Hi, > >> > >> I have a rhel5 client I had problems with my IPA environment and > >> had to rebuild > >> > >> I'm on the latest version of IPA with a red hat 6 server > >> > >> I successfully enrolled the client to the new server (same domain, > >> same > >> realm) I had removed all old certs, sysrestores, and > >> ipa/default.conf > >> > >> I can ssh to the box as root, and then either su or kinit to any > >> IPA user with out issue > >> > >> But when I try to ssh as the ipauser to the box it gives me > >> permission denied, please try again > >> > >> I cleared out the sssd cache and restarted sssd > >> > >> Is there something I'm missing or a log to check? > >> > >> I need to worked this out before I move forward enrolling other > >> previously enrolled clients. > > > > Check your HBAC rules. > > > > rob > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From bpk678 at gmail.com Tue Apr 1 14:17:57 2014 From: bpk678 at gmail.com (Brendan Kearney) Date: Tue, 01 Apr 2014 10:17:57 -0400 Subject: [Freeipa-users] using keytabs for auth to ldap Message-ID: <1396361877.21555.18.camel@desktop.bpk2.com> What distribution you use? Fedora Which distribution version you use? Fedora 20, with latest updates Which architecture you use? x86_64 on a qemu VM What plugin version you use? bind-dyndb-ldap-4.1-1.fc20.x86_64 Do you use bind-dyndb-ldap as part of ?FreeIPA installation? no, using openldap-servers-2.4.39-2.fc20.x86_64 Which version of ?BIND you use? bind-9.9.4-12.P2.fc20.x86_64 Please provide dynamic-db section from configuration file /etc/named.conf dynamic-db "bpk2.com" { library "ldap.so"; arg "uri ldap://127.0.0.1/"; arg "base cn=dns,dc=bpk2,dc=com"; arg "auth_method simple"; arg "bind_dn cn=Manager,dc=bpk2,dc=com"; arg "password ***REMOVED***"; arg "sync_ptr yes"; arg "dyn_update yes"; arg "connections 2"; arg "verbose_checks yes"; }; Do you have some other text based or ?DLZ zones configured? no Do you have some global forwarders configured in BIND configuration file? no Do you have some settings in global configuration object in LDAP? dn: cn=dns,dc=my-domain,dc=com cn: dns idnspersistentsearch: FALSE idnszonerefresh: 30 objectclass: top objectclass: nsContainer objectclass: idnsConfigObject i want to use bind-dyndb-ldap with keytabs against my directory. i have created the principal DNS/test.bpk2.com at BPK2.COM, and can have created the keytab file. what i want to know is: what ldap object should i create to match up against the kerberos principal? i have to grant access to the ldap tree, so what ID will be presented to ldap when using the keytab? am i able to use the sasl_username without the sasl_password to establish that? being that i want to use a keytab, the username would be in there, correct? when i list the keys in the keytab, there is a PRIMARY, an INSTANCE and a REALM (DNS/test.bpk2.com at BPK2.COM). is the PRIMARY (DNS) or the INSTANCE (test.bpk2.com) what has to be linked in ldap to the kerberos identity? do i need a specific olcAuthzRegexp to massage the kerberos ID into a proper ldap DN, like i am doing already for my ID? example: {0}uid=([^,]*),cn=bpk2.com,cn=gssapi,cn=auth uid= $1,ou=Users,dc=bpk2,dc=com i am running n-way multi master ldap. does the uri directive support more than one value (ldap://ldap1.bpk2.com ldap://ldap2.bpk2.com)? can the SRV records be used to point the uri directive at the ldap servers by querying for them? ha, thats a-chicken-and-the-egg topic, but an interesting one... i am assuming my named.conf will change to include: arg "uri ldap://ldap1.bpk2.com/ ldap://ldap2.bpk2.com"; arg "auth_method sasl"; arg "sasl_mech GSSAPI"; arg "krb5_keytab FILE:/etc/named.keytab"; is there anything else obvious that i am missing? thank you, brendan From rmeggins at redhat.com Tue Apr 1 17:13:54 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 01 Apr 2014 11:13:54 -0600 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: References: Message-ID: <533AF3D2.5050308@redhat.com> On 04/01/2014 03:46 AM, Nevada Sanchez wrote: > I've had a replica working with FreeIPA 3.2.1 for awhile. After > upgrading to 3.3.4, the replica wouldn't recognize my admin login > anymore. After much troubleshooting, I decided to try to redo the > replica since it was quite straightforward when I first set it up > (what could go wrong, right?) What is your version of 389-ds-base? rpm -q 389-ds-base What is in your dirsrv errors log? /var/log/dirsrv/slapd-DOMAIN-TLD/errors > > Unfortunately, I've spent most of my day trying to get the replica to > work this time. I've tried turning off all firewalls on both machines, > rebooting both machines, upgrading all packages on both machines (both > are running Fedora 19), reinstalling FreeIPA packages, and several > other things, but I keep getting stuck at the same step (see output > below). > > ================================================================= > [root at ipa2 ipaserver]# ipa-replica-install --setup-dns --no-forwarders > /var/lib/ipa/replica-info-ipa2.example.com.gpg > WARNING: conflicting time&date synchronization service 'chronyd' will > be disabled in favor of ntpd > > Run connection check to master > Check connection from replica to remote master 'ipa.example.com > ': > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): OK > Kerberos KDC: TCP (88): OK > Kerberos Kpasswd: TCP (464): OK > HTTP Server: Unsecure port (80): OK > HTTP Server: Secure port (443): OK > > The following list of ports use UDP protocol and would need to be > checked manually: > Kerberos KDC: UDP (88): SKIPPED > Kerberos Kpasswd: UDP (464): SKIPPED > > Connection from replica to master is OK. > Start listening on required ports for remote master check > Get credentials to log in to remote master > Check SSH connection to remote master > Execute check on remote master > Check connection from master to remote replica 'ipa2.example.com > ': > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): OK > Kerberos KDC: TCP (88): OK > Kerberos KDC: UDP (88): OK > Kerberos Kpasswd: TCP (464): OK > Kerberos Kpasswd: UDP (464): OK > HTTP Server: Unsecure port (80): OK > HTTP Server: Secure port (443): OK > > Connection from master to replica is OK. > > Connection check OK > Configuring NTP daemon (ntpd) > [1/4]: stopping ntpd > [2/4]: writing configuration > [3/4]: configuring ntpd to start on boot > [4/4]: starting ntpd > Done configuring NTP daemon (ntpd). > Configuring directory server (dirsrv): Estimated time 1 minute > [1/34]: creating directory server user > [2/34]: creating directory server instance > [3/34]: adding default schema > [4/34]: enabling memberof plugin > [5/34]: enabling winsync plugin > [6/34]: configuring replication version plugin > [7/34]: enabling IPA enrollment plugin > [8/34]: enabling ldapi > [9/34]: configuring uniqueness plugin > [10/34]: configuring uuid plugin > [11/34]: configuring modrdn plugin > [12/34]: configuring DNS plugin > [13/34]: enabling entryUSN plugin > [14/34]: configuring lockout plugin > [15/34]: creating indices > [16/34]: enabling referential integrity plugin > [17/34]: configuring ssl for ds instance > [18/34]: configuring certmap.conf > [19/34]: configure autobind for root > [20/34]: configure new location for managed entries > [21/34]: configure dirsrv ccache > [22/34]: enable SASL mapping fallback > [23/34]: restarting directory server > [24/34]: setting up initial replication > Starting replication, please wait until this has completed. > Update in progress, 5 seconds elapsed > [ipa.example.com ] reports: Update failed! > Status: [-1 Total update abortedLDAP error: Can't contact LDAP server] > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Failed to start replication > ================================================================= > > I've confirmed that I can do ldapsearch from each machine to the other > one for the replica status records (through ldap and ldaps), so I know > that they can communicate. Trouble is, something behind the scenes is > throwing the status error (as seen in the nsds5ReplicaLastInitStatus > attribute). > > ================================================================= > [root at ipa2 ipaserver]# ldapsearch ldaps://ipa.example.com:636 > -D 'cn=Directory Manager' -w ##### -b > 'cn=meToipa2.example.com > ,cn=replica,cn=dc\=example\,dc\=com,cn=mapping > tree,cn=config' '(objectClass=*)' -s base nsds5ReplicaLastInitStart > nsds5replicaUpdateInProgress nsds5ReplicaLastInitStatus cn > nsds5BeginReplicaRefresh nsds5ReplicaLastInitEnd > # extended LDIF > # > # LDAPv3 > # base ,cn=replica,cn=dc\=example\,dc\=com,cn=mapping > tree,cn=config> with scope baseObject > # filter: (objectclass=*) > # requesting: ldaps://ipa.example.com:636 > (objectClass=*) nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress > nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh > nsds5ReplicaLastInitEnd > # > > # meToipa2.example.com , replica, > dc\3Dexample\2Cdc\3Dcom, > mapping tree, config > dn: cn=meToipa2.example.com > ,cn=replica,cn=dc\3Dexample\2Cd > c\3Dcom,cn=mapping tree,cn=config > nsds5ReplicaLastInitStart: 20140401092800Z > nsds5replicaUpdateInProgress: FALSE > nsds5ReplicaLastInitStatus: -1 Total update abortedLDAP error: Can't > contact L > DAP server > cn: meToipa2.example.com > nsds5ReplicaLastInitEnd: 20140401092804Z > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > ================================================================= > > I'd really love for someone to help out with this, as I can't afford > another entire night trying to figure this out. Thanks in advance! > > -Nevada > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Tue Apr 1 17:58:00 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 1 Apr 2014 17:58:00 +0000 Subject: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate In-Reply-To: References: <5339EF9B.3070606@redhat.com> <94b3969cbcd3400d804b4c3dc4332fd7@BY2PR03MB176.namprd03.prod.outlook.com> <5339F1B0.8030209@redhat.com> <95da496c517c455281c0833c200367f0@BY2PR03MB176.namprd03.prod.outlook.com> <20140401071910.GD11404@localhost.localdomain>, Message-ID: I am seeing this error in /var/log/secure [root at black-64.qa ~]# tail /var/log/secure Apr 1 17:54:05 black-64 sshd[3649]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.194.1.250 user=tmaugh Apr 1 17:54:05 black-64 sshd[3649]: pam_sss(sshd:auth): received for user tmaugh: 4 (System error) Apr 1 17:54:07 black-64 sshd[3649]: Failed password for tmaugh from 10.194.1.250 port 44697 ssh2 Apr 1 17:54:12 black-64 sshd[3649]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.194.1.250 user=tmaugh Apr 1 17:54:12 black-64 sshd[3649]: pam_sss(sshd:auth): received for user tmaugh: 4 (System error) Apr 1 17:54:14 black-64 sshd[3649]: Failed password for tmaugh from 10.194.1.250 port 44697 ssh2 Apr 1 17:54:15 black-64 sshd[3650]: Connection closed by 10.194.1.250 Apr 1 17:54:15 black-64 sshd[3649]: PAM 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.194.1.250 user=tmaugh Apr 1 17:56:49 black-64 sshd[3713]: Accepted publickey for root from 10.194.1.250 port 38249 ssh2 Apr 1 17:56:49 black-64 sshd[3713]: pam_unix(sshd:session): session opened for user root by (uid=0) ________________________________________ From: freeipa-users-bounces at redhat.com on behalf of Todd Maugh Sent: Tuesday, April 01, 2014 7:17 AM To: Sumit Bose Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate I set my debug level to 5 and these were the messages I got. I checked the sshd_config and it seems to be using gsapi what lines should be uncommented or entered or set to true or yes for Pam. I tried the one pam line I saw to true. But it made no difference -----Original Message----- From: Sumit Bose [mailto:sbose at redhat.com] Sent: Tuesday, April 01, 2014 12:19 AM To: Todd Maugh Cc: Rob Crittenden; freeipa-users at redhat.com Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate On Mon, Mar 31, 2014 at 11:05:18PM +0000, Todd Maugh wrote: > > [root at black-62 sssd]# tail -f sssd_ops.boingo.com.log (Mon Mar 31 > 22:58:01 2014) [sssd[be[ops.boingo.com]]] [be_resolve_server_done] > (4): Found address for server idm-master-els.ops.boingo.com: > [172.22.170.46] TTL 7200 (Mon Mar 31 22:58:01 2014) [sssd[be[ops.boingo.com]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: host/black-62.qa.boingo.com (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [child_sig_handler] (4): child [13134] finished successfully. > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [fo_set_port_status] (4): Marking port 0 of server 'idm-master-els.ops.boingo.com' as 'working' > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [set_server_common_status] (4): Marking server 'idm-master-els.ops.boingo.com' as 'working' > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [be_run_online_cb] (3): Going online. Running callbacks. > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] > [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [delayed_online_authentication_callback] (5): Backend is online, starting delayed online authentication. > (Mon Mar 31 22:59:01 2014) [sssd[be[ops.boingo.com]]] > [be_get_account_info] (4): Got request for > [4097][1][name=tmp.XXXXUiK3X6] (Mon Mar 31 22:59:01 2014) > [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. > Returned 0,0,Success (Mon Mar 31 23:00:01 2014) > [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for > [4097][1][name=tmp.XXXXUiK3X6] (Mon Mar 31 23:00:01 2014) > [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. > Returned 0,0,Success (Mon Mar 31 23:01:01 2014) > [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for > [4097][1][name=tmp.XXXXUiK3X6] (Mon Mar 31 23:01:01 2014) > [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. > Returned 0,0,Success (Mon Mar 31 23:02:01 2014) > [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for > [4097][1][name=tmp.XXXXUiK3X6] (Mon Mar 31 23:02:01 2014) > [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. > Returned 0,0,Success (Mon Mar 31 23:03:01 2014) > [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for > [4097][1][name=tmp.XXXXUiK3X6] (Mon Mar 31 23:03:01 2014) > [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. > Returned 0,0,Success The log does not show any authentication or PAM related activities. Please increase the debug_level and check for PAM related messages like e.g. "[pam_print_data] (0x0100): command: PAM_AUTHENTICATE". If there are no such messages, please check your PAM configuration as Dmitri suggested. HTH bye, Sumit > > I see this in the sssd Logs but still not authenticating > > will check out AVC and SELinux very frustrating > > > ________________________________________ > From: Rob Crittenden > Sent: Monday, March 31, 2014 3:52 PM > To: Todd Maugh; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled > and enrolled to new server cant authenticate > > Todd Maugh wrote: > > HBAC rules are set to allow_all enabled > > Ok. I'd start with increasing the sssd log level and see what it says. > > I gather that basic nss works since you can kinit as other users. > > You may want to check for SELinux AVCs as well. > > rob > > > > > -----Original Message----- > > From: Rob Crittenden [mailto:rcritten at redhat.com] > > Sent: Monday, March 31, 2014 3:44 PM > > To: Todd Maugh; freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled > > and enrolled to new server cant authenticate > > > > Todd Maugh wrote: > >> Hi, > >> > >> I have a rhel5 client I had problems with my IPA environment and > >> had to rebuild > >> > >> I'm on the latest version of IPA with a red hat 6 server > >> > >> I successfully enrolled the client to the new server (same domain, > >> same > >> realm) I had removed all old certs, sysrestores, and > >> ipa/default.conf > >> > >> I can ssh to the box as root, and then either su or kinit to any > >> IPA user with out issue > >> > >> But when I try to ssh as the ipauser to the box it gives me > >> permission denied, please try again > >> > >> I cleared out the sssd cache and restarted sssd > >> > >> Is there something I'm missing or a log to check? > >> > >> I need to worked this out before I move forward enrolling other > >> previously enrolled clients. > > > > Check your HBAC rules. > > > > rob > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From tmaugh at boingo.com Tue Apr 1 18:00:28 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 1 Apr 2014 18:00:28 +0000 Subject: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate In-Reply-To: References: <5339EF9B.3070606@redhat.com> <94b3969cbcd3400d804b4c3dc4332fd7@BY2PR03MB176.namprd03.prod.outlook.com> <5339F1B0.8030209@redhat.com> <95da496c517c455281c0833c200367f0@BY2PR03MB176.namprd03.prod.outlook.com> <20140401071910.GD11404@localhost.localdomain>, , Message-ID: <11390e861eae4805be996bf8642157ed@BY2PR03MB176.namprd03.prod.outlook.com> here is my sssd.conf [root at black-64.qa ~]# cat /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = nss, pam # SSSD will not start if you do not configure any domains. # Add new domain configurations as [domain/] sections, and # then add the list of domains (in the order you want them to be # queried) to the "domains" attribute below and uncomment it. # domains = LDAP domains = ops.boingo.com [nss] [pam] # Example LDAP domain # [domain/LDAP] # id_provider = ldap # auth_provider = ldap # ldap_schema can be set to "rfc2307", which stores group member names in the # "memberuid" attribute, or to "rfc2307bis", which stores group member DNs in # the "member" attribute. If you do not know this value, ask your LDAP # administrator. # ldap_schema = rfc2307 # ldap_uri = ldap://ldap.mydomain.org # ldap_search_base = dc=mydomain,dc=org # Note that enabling enumeration will have a moderate performance impact. # Consequently, the default value for enumeration is FALSE. # Refer to the sssd.conf man page for full details. # enumerate = false # Allow offline logins by locally storing password hashes (default: false). # cache_credentials = true # An example Active Directory domain. Please note that this configuration # works for AD 2003R2 and AD 2008, because they use pretty much RFC2307bis # compliant attribute names. To support UNIX clients with AD 2003 or older, # you must install Microsoft Services For Unix and map LDAP attributes onto # msSFU30* attribute names. # [domain/AD] # id_provider = ldap # auth_provider = krb5 # chpass_provider = krb5 # # ldap_uri = ldap://your.ad.example.com # ldap_search_base = dc=example,dc=com # ldap_schema = rfc2307bis # ldap_sasl_mech = GSSAPI # ldap_user_object_class = user # ldap_group_object_class = group # ldap_user_home_directory = unixHomeDirectory # ldap_user_principal = userPrincipalName # ldap_account_expire_policy = ad # ldap_force_upper_case_realm = true # # krb5_server = your.ad.example.com # krb5_realm = EXAMPLE.COM [domain/ops.boingo.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ops.boingo.com id_provider = ipa auth_provider = ipa access_provider = ipa chpass_provider = ipa ipa_server = _srv_, idm-master-els.ops.boingo.com ldap_tls_cacert = /etc/ipa/ca.crt ________________________________________ From: Todd Maugh Sent: Tuesday, April 01, 2014 10:58 AM To: Sumit Bose Cc: freeipa-users at redhat.com Subject: RE: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate I am seeing this error in /var/log/secure [root at black-64.qa ~]# tail /var/log/secure Apr 1 17:54:05 black-64 sshd[3649]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.194.1.250 user=tmaugh Apr 1 17:54:05 black-64 sshd[3649]: pam_sss(sshd:auth): received for user tmaugh: 4 (System error) Apr 1 17:54:07 black-64 sshd[3649]: Failed password for tmaugh from 10.194.1.250 port 44697 ssh2 Apr 1 17:54:12 black-64 sshd[3649]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.194.1.250 user=tmaugh Apr 1 17:54:12 black-64 sshd[3649]: pam_sss(sshd:auth): received for user tmaugh: 4 (System error) Apr 1 17:54:14 black-64 sshd[3649]: Failed password for tmaugh from 10.194.1.250 port 44697 ssh2 Apr 1 17:54:15 black-64 sshd[3650]: Connection closed by 10.194.1.250 Apr 1 17:54:15 black-64 sshd[3649]: PAM 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.194.1.250 user=tmaugh Apr 1 17:56:49 black-64 sshd[3713]: Accepted publickey for root from 10.194.1.250 port 38249 ssh2 Apr 1 17:56:49 black-64 sshd[3713]: pam_unix(sshd:session): session opened for user root by (uid=0) ________________________________________ From: freeipa-users-bounces at redhat.com on behalf of Todd Maugh Sent: Tuesday, April 01, 2014 7:17 AM To: Sumit Bose Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate I set my debug level to 5 and these were the messages I got. I checked the sshd_config and it seems to be using gsapi what lines should be uncommented or entered or set to true or yes for Pam. I tried the one pam line I saw to true. But it made no difference -----Original Message----- From: Sumit Bose [mailto:sbose at redhat.com] Sent: Tuesday, April 01, 2014 12:19 AM To: Todd Maugh Cc: Rob Crittenden; freeipa-users at redhat.com Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate On Mon, Mar 31, 2014 at 11:05:18PM +0000, Todd Maugh wrote: > > [root at black-62 sssd]# tail -f sssd_ops.boingo.com.log (Mon Mar 31 > 22:58:01 2014) [sssd[be[ops.boingo.com]]] [be_resolve_server_done] > (4): Found address for server idm-master-els.ops.boingo.com: > [172.22.170.46] TTL 7200 (Mon Mar 31 22:58:01 2014) [sssd[be[ops.boingo.com]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: host/black-62.qa.boingo.com (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [child_sig_handler] (4): child [13134] finished successfully. > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [fo_set_port_status] (4): Marking port 0 of server 'idm-master-els.ops.boingo.com' as 'working' > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [set_server_common_status] (4): Marking server 'idm-master-els.ops.boingo.com' as 'working' > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [be_run_online_cb] (3): Going online. Running callbacks. > (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] > [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [delayed_online_authentication_callback] (5): Backend is online, starting delayed online authentication. > (Mon Mar 31 22:59:01 2014) [sssd[be[ops.boingo.com]]] > [be_get_account_info] (4): Got request for > [4097][1][name=tmp.XXXXUiK3X6] (Mon Mar 31 22:59:01 2014) > [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. > Returned 0,0,Success (Mon Mar 31 23:00:01 2014) > [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for > [4097][1][name=tmp.XXXXUiK3X6] (Mon Mar 31 23:00:01 2014) > [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. > Returned 0,0,Success (Mon Mar 31 23:01:01 2014) > [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for > [4097][1][name=tmp.XXXXUiK3X6] (Mon Mar 31 23:01:01 2014) > [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. > Returned 0,0,Success (Mon Mar 31 23:02:01 2014) > [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for > [4097][1][name=tmp.XXXXUiK3X6] (Mon Mar 31 23:02:01 2014) > [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. > Returned 0,0,Success (Mon Mar 31 23:03:01 2014) > [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for > [4097][1][name=tmp.XXXXUiK3X6] (Mon Mar 31 23:03:01 2014) > [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. > Returned 0,0,Success The log does not show any authentication or PAM related activities. Please increase the debug_level and check for PAM related messages like e.g. "[pam_print_data] (0x0100): command: PAM_AUTHENTICATE". If there are no such messages, please check your PAM configuration as Dmitri suggested. HTH bye, Sumit > > I see this in the sssd Logs but still not authenticating > > will check out AVC and SELinux very frustrating > > > ________________________________________ > From: Rob Crittenden > Sent: Monday, March 31, 2014 3:52 PM > To: Todd Maugh; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled > and enrolled to new server cant authenticate > > Todd Maugh wrote: > > HBAC rules are set to allow_all enabled > > Ok. I'd start with increasing the sssd log level and see what it says. > > I gather that basic nss works since you can kinit as other users. > > You may want to check for SELinux AVCs as well. > > rob > > > > > -----Original Message----- > > From: Rob Crittenden [mailto:rcritten at redhat.com] > > Sent: Monday, March 31, 2014 3:44 PM > > To: Todd Maugh; freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled > > and enrolled to new server cant authenticate > > > > Todd Maugh wrote: > >> Hi, > >> > >> I have a rhel5 client I had problems with my IPA environment and > >> had to rebuild > >> > >> I'm on the latest version of IPA with a red hat 6 server > >> > >> I successfully enrolled the client to the new server (same domain, > >> same > >> realm) I had removed all old certs, sysrestores, and > >> ipa/default.conf > >> > >> I can ssh to the box as root, and then either su or kinit to any > >> IPA user with out issue > >> > >> But when I try to ssh as the ipauser to the box it gives me > >> permission denied, please try again > >> > >> I cleared out the sssd cache and restarted sssd > >> > >> Is there something I'm missing or a log to check? > >> > >> I need to worked this out before I move forward enrolling other > >> previously enrolled clients. > > > > Check your HBAC rules. > > > > rob > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From pspacek at redhat.com Tue Apr 1 18:40:17 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 01 Apr 2014 20:40:17 +0200 Subject: [Freeipa-users] bind-dyndb-ldap: using keytabs for auth to ldap In-Reply-To: <1396361877.21555.18.camel@desktop.bpk2.com> References: <1396361877.21555.18.camel@desktop.bpk2.com> Message-ID: <533B0811.4050402@redhat.com> Hello! On 1.4.2014 16:17, Brendan Kearney wrote: > What plugin version you use? bind-dyndb-ldap-4.1-1.fc20.x86_64 Before I dive into details, please read about the following bug: https://fedorahosted.org/bind-dyndb-ldap/ticket/134 I just found it, fixed it and I'm attaching patch for you so you don't need to wait for a new release :-) > Do you use bind-dyndb-ldap as part of ?FreeIPA installation? no, using > openldap-servers-2.4.39-2.fc20.x86_64 > Please provide dynamic-db section from configuration > file /etc/named.conf > dynamic-db "bpk2.com" { > library "ldap.so"; > arg "uri ldap://127.0.0.1/"; > arg "base cn=dns,dc=bpk2,dc=com"; > arg "auth_method simple"; > arg "bind_dn cn=Manager,dc=bpk2,dc=com"; > arg "password ***REMOVED***"; > arg "sync_ptr yes"; > arg "dyn_update yes"; > arg "connections 2"; > arg "verbose_checks yes"; > }; > i want to use bind-dyndb-ldap with keytabs against my directory. i have > created the principal DNS/test.bpk2.com at BPK2.COM, and can have created > the keytab file. what i want to know is: > > what ldap object should i create to match up against the kerberos > principal? > i have to grant access to the ldap tree, so what ID will be presented to > ldap when using the keytab? This is up to your LDAP server implementation. Bind-dyndb-ldap just calls SASL and Kerberos libraries. The plugin itself is not aware of any principal<->DN mapping. > am i able to use the sasl_username without the sasl_password to > establish that? sasl_username defaults to "DNS/$(hostname)" so usually it is not necessary to specify it explicitly. (It should match your Kerberos principal.) > being that i want to use a keytab, the username would be in there, > correct? > when i list the keys in the keytab, there is a PRIMARY, an INSTANCE and > a REALM (DNS/test.bpk2.com at BPK2.COM). is the PRIMARY (DNS) or the > INSTANCE (test.bpk2.com) what has to be linked in ldap to the kerberos > identity? Your LDAP server will get the whole principal and it is up to the server how it will map it to some existing entity. > do i need a specific olcAuthzRegexp to massage the kerberos ID into a > proper ldap DN, like i am doing already for my ID? example: > {0}uid=([^,]*),cn=bpk2.com,cn=gssapi,cn=auth uid= > $1,ou=Users,dc=bpk2,dc=com I have no idea, I have never configured this in OpenLDAP. Please let us know what configuration worked for you so we have the information in mailing list archives. Thanks! > i am running n-way multi master ldap. does the uri directive support > more than one value (ldap://ldap1.bpk2.com ldap://ldap2.bpk2.com)? Unfortunately no, it is not supported. The usual recommendation is to configure one DNS server on one LDAP server for redundancy. > can the SRV records be used to point the uri directive at the ldap > servers by querying for them? ha, thats a-chicken-and-the-egg topic, > but an interesting one... That is an interesting idea but SRV lookups are not supported. > i am assuming my named.conf will change to include: BTW documentation about named.conf syntax is in README: https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/plain/README > arg "uri ldap://ldap1.bpk2.com/ ldap://ldap2.bpk2.com"; ^ This is not supported. Please pick just one LDAP server. > arg "auth_method sasl"; ^ This is correct. > arg "sasl_mech GSSAPI"; ^ This is default. > arg "krb5_keytab FILE:/etc/named.keytab"; ^ This is default. > is there anything else obvious that i am missing? It should be enough if you configure your LDAP server accordingly. Let us know if you encounter any problem. BTW did you see FreeIPA project? It integrates LDAP+Kerberos with management tools and nice user interface and solver Microsoft AD integration. Maybe it could save you some headaches ... -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0231-Fix-record-parsing-to-prevent-child-zone-corruption.patch Type: text/x-patch Size: 1674 bytes Desc: not available URL: From rmeggins at redhat.com Tue Apr 1 19:22:30 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 01 Apr 2014 13:22:30 -0600 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: References: <533AF3D2.5050308@redhat.com> Message-ID: <533B11F6.3040603@redhat.com> On 04/01/2014 01:16 PM, Nevada Sanchez wrote: > 389-ds-base-1.3.1.22-1.fc19.x86_64 > > The following, I think, summarizes the contents of the error log (I > probably uninstalled and tried reimporting 2 or 3 times in what is shown). > > . > . > . > [01/Apr/2014:03:42:46 -0400] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to > access the database > [01/Apr/2014:03:42:46 -0400] - check_and_set_import_cache: pagesize: > 4096, pages: 1970554, procpages: 53717 > [01/Apr/2014:03:42:46 -0400] - Import allocates 3152884KB import cache. > [01/Apr/2014:03:42:46 -0400] - import userRoot: Beginning import job... > [01/Apr/2014:03:42:46 -0400] - import userRoot: Index buffering > enabled with bucket size 100 > [01/Apr/2014:03:42:46 -0400] - import userRoot: Processing file > "/var/lib/dirsrv/boot.ldif" > [01/Apr/2014:03:42:46 -0400] - import userRoot: Finished scanning file > "/var/lib/dirsrv/boot.ldif" (1 entries) > [01/Apr/2014:03:42:46 -0400] - import userRoot: Workers finished; > cleaning up... > [01/Apr/2014:03:42:47 -0400] - import userRoot: Workers cleaned up. > [01/Apr/2014:03:42:47 -0400] - import userRoot: Cleaning up producer > thread... > [01/Apr/2014:03:42:47 -0400] - import userRoot: Indexing complete. > Post-processing... > [01/Apr/2014:03:42:47 -0400] - import userRoot: Generating > numSubordinates complete. > [01/Apr/2014:03:42:47 -0400] - Nothing to do to build ancestorid index > [01/Apr/2014:03:42:47 -0400] - import userRoot: Flushing caches... > [01/Apr/2014:03:42:47 -0400] - import userRoot: Closing files... > [01/Apr/2014:03:42:47 -0400] - All database threads now stopped > [01/Apr/2014:03:42:47 -0400] - import userRoot: Import complete. > Processed 1 entries in 1 seconds. (1.00 entries/sec) > [01/Apr/2014:03:42:47 -0400] - 389-Directory/1.3.1.22.a1 > B2014.073.1751 starting up > [01/Apr/2014:03:42:47 -0400] - Db home directory is not set. Possibly > nsslapd-directory (optionally nsslapd-db-home-directory) is missing in > the config file. > [01/Apr/2014:03:42:48 -0400] - 389-Directory/1.3.1.22.a1 > B2014.073.1751 starting up > [01/Apr/2014:03:42:48 -0400] - Db home directory is not set. Possibly > nsslapd-directory (optionally nsslapd-db-home-directory) is missing in > the config file. > [01/Apr/2014:03:42:48 -0400] - I'm resizing my cache now...cache was > 3228553216 and is now 8000000 > [01/Apr/2014:03:42:48 -0400] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [01/Apr/2014:03:42:48 -0400] - The change of nsslapd-ldapilisten will > not take effect until the server is restarted > [01/Apr/2014:03:43:01 -0400] - Warning: Adding configuration attribute > "nsslapd-security" > [01/Apr/2014:03:43:01 -0400] - slapd shutting down - signaling > operation threads > [01/Apr/2014:03:43:01 -0400] - slapd shutting down - waiting for 27 > threads to terminate > [01/Apr/2014:03:43:01 -0400] - slapd shutting down - closing down > internal subsystems and plugins > [01/Apr/2014:03:43:01 -0400] - Waiting for 4 database threads to stop > [01/Apr/2014:03:43:02 -0400] - All database threads now stopped > [01/Apr/2014:03:43:02 -0400] - slapd stopped. > [01/Apr/2014:03:43:03 -0400] - 389-Directory/1.3.1.22.a1 > B2014.073.1751 starting up > [01/Apr/2014:03:43:03 -0400] attrcrypt - No symmetric key found for > cipher AES in backend userRoot, attempting to create one... > [01/Apr/2014:03:43:03 -0400] attrcrypt - Key for cipher AES > successfully generated and stored > [01/Apr/2014:03:43:03 -0400] attrcrypt - No symmetric key found for > cipher 3DES in backend userRoot, attempting to create one... > [01/Apr/2014:03:43:03 -0400] attrcrypt - Key for cipher 3DES > successfully generated and stored > [01/Apr/2014:03:43:03 -0400] ipalockout_get_global_config - [file > ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) > [01/Apr/2014:03:43:04 -0400] ipaenrollment_start - [file > ipa_enrollment.c, line 393]: Failed to get default realm?! > [01/Apr/2014:03:43:04 -0400] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [01/Apr/2014:03:43:04 -0400] - Listening on All Interfaces port 636 > for LDAPS requests > [01/Apr/2014:03:43:04 -0400] - Listening on > /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests > [01/Apr/2014:03:43:04 -0400] - slapd shutting down - signaling > operation threads > [01/Apr/2014:03:43:04 -0400] - slapd shutting down - waiting for 27 > threads to terminate > [01/Apr/2014:03:43:05 -0400] - slapd shutting down - closing down > internal subsystems and plugins > [01/Apr/2014:03:43:05 -0400] - Waiting for 4 database threads to stop > [01/Apr/2014:03:43:05 -0400] - All database threads now stopped > [01/Apr/2014:03:43:05 -0400] - slapd stopped. > [01/Apr/2014:03:43:06 -0400] - 389-Directory/1.3.1.22.a1 > B2014.073.1751 starting up > [01/Apr/2014:03:43:06 -0400] ipalockout_get_global_config - [file > ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) > [01/Apr/2014:03:43:06 -0400] ipaenrollment_start - [file > ipa_enrollment.c, line 393]: Failed to get default realm?! > [01/Apr/2014:03:43:06 -0400] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [01/Apr/2014:03:43:06 -0400] - Listening on All Interfaces port 636 > for LDAPS requests > [01/Apr/2014:03:43:06 -0400] - Listening on > /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests > [01/Apr/2014:03:43:08 -0400] NSMMReplicationPlugin - > agmt="cn=meToipa.example.com " (ipa: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. > [01/Apr/2014:03:43:08 -0400] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=example,dc=com is going > offline; disabling replication > [01/Apr/2014:03:43:08 -0400] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to > access the database > [01/Apr/2014:03:43:11 -0400] - import userRoot: Workers finished; > cleaning up... > [01/Apr/2014:03:43:11 -0400] - import userRoot: Workers cleaned up. > [01/Apr/2014:03:43:11 -0400] - import userRoot: Indexing complete. > Post-processing... > [01/Apr/2014:03:43:11 -0400] - import userRoot: Generating > numSubordinates complete. > [01/Apr/2014:03:43:12 -0400] - import userRoot: Flushing caches... > [01/Apr/2014:03:43:12 -0400] - import userRoot: Closing files... > [01/Apr/2014:03:43:12 -0400] - import userRoot: Import complete. > Processed 453 entries in 4 seconds. (113.25 entries/sec) > [01/Apr/2014:03:43:12 -0400] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=example,dc=com is coming > online; enabling replication > [01/Apr/2014:03:43:12 -0400] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=example,dc=com--no CoS Templates found, which > should be added before the CoS Definition. > [01/Apr/2014:03:43:19 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:03:43:19 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:03:48:19 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:03:48:19 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:03:53:19 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:03:53:19 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:03:58:19 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:03:58:19 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:03:18 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:03:18 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:08:18 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:08:18 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:13:18 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:13:18 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:18:19 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:18:19 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:23:18 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:23:18 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:28:18 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:28:18 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:33:19 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:33:19 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:38:19 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:38:19 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:43:18 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:43:18 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:48:18 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:48:18 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:53:19 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:53:19 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:58:18 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:58:18 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:03:18 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:03:18 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:08:18 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:08:18 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:13:18 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:13:19 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:14:36 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:14:36 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:14:41 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:14:41 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:14:46 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:14:46 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:14:58 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:14:58 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:15:00 -0400] - slapd shutting down - signaling > operation threads > [01/Apr/2014:05:15:00 -0400] - slapd shutting down - waiting for 28 > threads to terminate > [01/Apr/2014:05:15:00 -0400] - slapd shutting down - closing down > internal subsystems and plugins > [01/Apr/2014:05:15:01 -0400] - Waiting for 4 database threads to stop > [01/Apr/2014:05:15:01 -0400] - All database threads now stopped > [01/Apr/2014:05:15:01 -0400] - slapd stopped. > [01/Apr/2014:05:27:38 -0400] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to > access the database > [01/Apr/2014:05:27:38 -0400] - check_and_set_import_cache: pagesize: > 4096, pages: 1970554, procpages: 53717 > [01/Apr/2014:05:27:38 -0400] - Import allocates 3152884KB import cache. > [01/Apr/2014:05:27:38 -0400] - import userRoot: Beginning import job... > [01/Apr/2014:05:27:38 -0400] - import userRoot: Index buffering > enabled with bucket size 100 > [01/Apr/2014:05:27:39 -0400] - import userRoot: Processing file > "/var/lib/dirsrv/boot.ldif" > [01/Apr/2014:05:27:39 -0400] - import userRoot: Finished scanning file > "/var/lib/dirsrv/boot.ldif" (1 entries) > [01/Apr/2014:05:27:39 -0400] - import userRoot: Workers finished; > cleaning up... > [01/Apr/2014:05:27:39 -0400] - import userRoot: Workers cleaned up. > [01/Apr/2014:05:27:39 -0400] - import userRoot: Cleaning up producer > thread... > [01/Apr/2014:05:27:39 -0400] - import userRoot: Indexing complete. > Post-processing... > [01/Apr/2014:05:27:39 -0400] - import userRoot: Generating > numSubordinates complete. > [01/Apr/2014:05:27:39 -0400] - Nothing to do to build ancestorid index > [01/Apr/2014:05:27:39 -0400] - import userRoot: Flushing caches... > [01/Apr/2014:05:27:39 -0400] - import userRoot: Closing files... > [01/Apr/2014:05:27:40 -0400] - All database threads now stopped > [01/Apr/2014:05:27:40 -0400] - import userRoot: Import complete. > Processed 1 entries in 2 seconds. (0.50 entries/sec) > [01/Apr/2014:05:27:40 -0400] - 389-Directory/1.3.1.22.a1 > B2014.073.1751 starting up > [01/Apr/2014:05:27:40 -0400] - Db home directory is not set. Possibly > nsslapd-directory (optionally nsslapd-db-home-directory) is missing in > the config file. > [01/Apr/2014:05:27:40 -0400] - 389-Directory/1.3.1.22.a1 > B2014.073.1751 starting up > [01/Apr/2014:05:27:40 -0400] - Db home directory is not set. Possibly > nsslapd-directory (optionally nsslapd-db-home-directory) is missing in > the config file. > [01/Apr/2014:05:27:40 -0400] - I'm resizing my cache now...cache was > 3228553216 and is now 8000000 > [01/Apr/2014:05:27:41 -0400] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [01/Apr/2014:05:27:41 -0400] - The change of nsslapd-ldapilisten will > not take effect until the server is restarted > [01/Apr/2014:05:27:54 -0400] - Warning: Adding configuration attribute > "nsslapd-security" > [01/Apr/2014:05:27:54 -0400] - slapd shutting down - signaling > operation threads > [01/Apr/2014:05:27:54 -0400] - slapd shutting down - waiting for 28 > threads to terminate > [01/Apr/2014:05:27:54 -0400] - slapd shutting down - closing down > internal subsystems and plugins > [01/Apr/2014:05:27:54 -0400] - Waiting for 4 database threads to stop > [01/Apr/2014:05:27:55 -0400] - All database threads now stopped > [01/Apr/2014:05:27:55 -0400] - slapd stopped. > [01/Apr/2014:05:27:56 -0400] - 389-Directory/1.3.1.22.a1 > B2014.073.1751 starting up > [01/Apr/2014:05:27:56 -0400] attrcrypt - No symmetric key found for > cipher AES in backend userRoot, attempting to create one... > [01/Apr/2014:05:27:56 -0400] attrcrypt - Key for cipher AES > successfully generated and stored > [01/Apr/2014:05:27:56 -0400] attrcrypt - No symmetric key found for > cipher 3DES in backend userRoot, attempting to create one... > [01/Apr/2014:05:27:56 -0400] attrcrypt - Key for cipher 3DES > successfully generated and stored > [01/Apr/2014:05:27:56 -0400] ipalockout_get_global_config - [file > ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) > [01/Apr/2014:05:27:56 -0400] ipaenrollment_start - [file > ipa_enrollment.c, line 393]: Failed to get default realm?! > [01/Apr/2014:05:27:56 -0400] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [01/Apr/2014:05:27:56 -0400] - Listening on All Interfaces port 636 > for LDAPS requests > [01/Apr/2014:05:27:56 -0400] - Listening on > /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests > [01/Apr/2014:05:27:56 -0400] - slapd shutting down - signaling > operation threads > [01/Apr/2014:05:27:56 -0400] - slapd shutting down - waiting for 29 > threads to terminate > [01/Apr/2014:05:27:57 -0400] - slapd shutting down - closing down > internal subsystems and plugins > [01/Apr/2014:05:27:57 -0400] - Waiting for 4 database threads to stop > [01/Apr/2014:05:27:57 -0400] - All database threads now stopped > [01/Apr/2014:05:27:57 -0400] - slapd stopped. > [01/Apr/2014:05:27:58 -0400] - 389-Directory/1.3.1.22.a1 > B2014.073.1751 starting up > [01/Apr/2014:05:27:59 -0400] ipalockout_get_global_config - [file > ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) > [01/Apr/2014:05:27:59 -0400] ipaenrollment_start - [file > ipa_enrollment.c, line 393]: Failed to get default realm?! > [01/Apr/2014:05:27:59 -0400] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [01/Apr/2014:05:27:59 -0400] - Listening on All Interfaces port 636 > for LDAPS requests > [01/Apr/2014:05:27:59 -0400] - Listening on > /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests > [01/Apr/2014:05:28:01 -0400] NSMMReplicationPlugin - > agmt="cn=meToipa.example.com " (ipa: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. > [01/Apr/2014:05:28:01 -0400] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=example,dc=com is going > offline; disabling replication > [01/Apr/2014:05:28:01 -0400] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to > access the database > [01/Apr/2014:05:28:04 -0400] - import userRoot: Workers finished; > cleaning up... > [01/Apr/2014:05:28:05 -0400] - import userRoot: Workers cleaned up. > [01/Apr/2014:05:28:05 -0400] - import userRoot: Indexing complete. > Post-processing... > [01/Apr/2014:05:28:05 -0400] - import userRoot: Generating > numSubordinates complete. > [01/Apr/2014:05:28:05 -0400] - import userRoot: Flushing caches... > [01/Apr/2014:05:28:05 -0400] - import userRoot: Closing files... > [01/Apr/2014:05:28:06 -0400] - import userRoot: Import complete. > Processed 453 entries in 5 seconds. (90.60 entries/sec) > [01/Apr/2014:05:28:06 -0400] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=example,dc=com is coming > online; enabling replication > [01/Apr/2014:05:28:06 -0400] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=example,dc=com--no CoS Templates found, which > should be added before the CoS Definition. > [01/Apr/2014:05:32:38 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:32:38 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > . > . > . > [01/Apr/2014:13:12:39 -0400] ipalockout_preop - [file ipa_lockout.c, > line 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:13:12:39 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 This seems bad, but I'm not sure if this is the root of the replication problem. > > > > On Tue, Apr 1, 2014 at 1:13 PM, Rich Megginson > wrote: > > On 04/01/2014 03:46 AM, Nevada Sanchez wrote: >> I've had a replica working with FreeIPA 3.2.1 for awhile. After >> upgrading to 3.3.4, the replica wouldn't recognize my admin login >> anymore. After much troubleshooting, I decided to try to redo the >> replica since it was quite straightforward when I first set it up >> (what could go wrong, right?) > What is your version of 389-ds-base? rpm -q 389-ds-base > > What is in your dirsrv errors log? > /var/log/dirsrv/slapd-DOMAIN-TLD/errors > >> >> Unfortunately, I've spent most of my day trying to get the >> replica to work this time. I've tried turning off all firewalls >> on both machines, rebooting both machines, upgrading all packages >> on both machines (both are running Fedora 19), reinstalling >> FreeIPA packages, and several other things, but I keep getting >> stuck at the same step (see output below). >> >> ================================================================= >> [root at ipa2 ipaserver]# ipa-replica-install --setup-dns >> --no-forwarders /var/lib/ipa/replica-info-ipa2.example.com.gpg >> WARNING: conflicting time&date synchronization service 'chronyd' will >> be disabled in favor of ntpd >> >> Run connection check to master >> Check connection from replica to remote master 'ipa.example.com >> ': >> Directory Service: Unsecure port (389): OK >> Directory Service: Secure port (636): OK >> Kerberos KDC: TCP (88): OK >> Kerberos Kpasswd: TCP (464): OK >> HTTP Server: Unsecure port (80): OK >> HTTP Server: Secure port (443): OK >> >> The following list of ports use UDP protocol and would need to be >> checked manually: >> Kerberos KDC: UDP (88): SKIPPED >> Kerberos Kpasswd: UDP (464): SKIPPED >> >> Connection from replica to master is OK. >> Start listening on required ports for remote master check >> Get credentials to log in to remote master >> Check SSH connection to remote master >> Execute check on remote master >> Check connection from master to remote replica 'ipa2.example.com >> ': >> Directory Service: Unsecure port (389): OK >> Directory Service: Secure port (636): OK >> Kerberos KDC: TCP (88): OK >> Kerberos KDC: UDP (88): OK >> Kerberos Kpasswd: TCP (464): OK >> Kerberos Kpasswd: UDP (464): OK >> HTTP Server: Unsecure port (80): OK >> HTTP Server: Secure port (443): OK >> >> Connection from master to replica is OK. >> >> Connection check OK >> Configuring NTP daemon (ntpd) >> [1/4]: stopping ntpd >> [2/4]: writing configuration >> [3/4]: configuring ntpd to start on boot >> [4/4]: starting ntpd >> Done configuring NTP daemon (ntpd). >> Configuring directory server (dirsrv): Estimated time 1 minute >> [1/34]: creating directory server user >> [2/34]: creating directory server instance >> [3/34]: adding default schema >> [4/34]: enabling memberof plugin >> [5/34]: enabling winsync plugin >> [6/34]: configuring replication version plugin >> [7/34]: enabling IPA enrollment plugin >> [8/34]: enabling ldapi >> [9/34]: configuring uniqueness plugin >> [10/34]: configuring uuid plugin >> [11/34]: configuring modrdn plugin >> [12/34]: configuring DNS plugin >> [13/34]: enabling entryUSN plugin >> [14/34]: configuring lockout plugin >> [15/34]: creating indices >> [16/34]: enabling referential integrity plugin >> [17/34]: configuring ssl for ds instance >> [18/34]: configuring certmap.conf >> [19/34]: configure autobind for root >> [20/34]: configure new location for managed entries >> [21/34]: configure dirsrv ccache >> [22/34]: enable SASL mapping fallback >> [23/34]: restarting directory server >> [24/34]: setting up initial replication >> Starting replication, please wait until this has completed. >> Update in progress, 5 seconds elapsed >> [ipa.example.com ] reports: Update >> failed! Status: [-1 Total update abortedLDAP error: Can't contact >> LDAP server] >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> Failed to start replication >> ================================================================= >> >> I've confirmed that I can do ldapsearch from each machine to the >> other one for the replica status records (through ldap and >> ldaps), so I know that they can communicate. Trouble is, >> something behind the scenes is throwing the status error (as seen >> in the nsds5ReplicaLastInitStatus attribute). >> >> ================================================================= >> [root at ipa2 ipaserver]# ldapsearch ldaps://ipa.example.com:636 >> -D 'cn=Directory Manager' -w ##### >> -b 'cn=meToipa2.example.com >> ,cn=replica,cn=dc\=example\,dc\=com,cn=mapping >> tree,cn=config' '(objectClass=*)' -s base >> nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress >> nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh >> nsds5ReplicaLastInitEnd >> # extended LDIF >> # >> # LDAPv3 >> # base > ,cn=replica,cn=dc\=example\,dc\=com,cn=mapping >> tree,cn=config> with scope baseObject >> # filter: (objectclass=*) >> # requesting: ldaps://ipa.example.com:636 >> (objectClass=*) >> nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress >> nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh >> nsds5ReplicaLastInitEnd >> # >> >> # meToipa2.example.com , replica, >> dc\3Dexample\2Cdc\3Dcom, >> mapping tree, config >> dn: cn=meToipa2.example.com >> ,cn=replica,cn=dc\3Dexample\2Cd >> c\3Dcom,cn=mapping tree,cn=config >> nsds5ReplicaLastInitStart: 20140401092800Z >> nsds5replicaUpdateInProgress: FALSE >> nsds5ReplicaLastInitStatus: -1 Total update abortedLDAP error: >> Can't contact L >> DAP server >> cn: meToipa2.example.com >> nsds5ReplicaLastInitEnd: 20140401092804Z >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> ================================================================= >> >> I'd really love for someone to help out with this, as I can't >> afford another entire night trying to figure this out. Thanks in >> advance! >> >> -Nevada >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpk678 at gmail.com Tue Apr 1 19:34:19 2014 From: bpk678 at gmail.com (Brendan Kearney) Date: Tue, 01 Apr 2014 15:34:19 -0400 Subject: [Freeipa-users] bind-dyndb-ldap: using keytabs for auth to ldap In-Reply-To: <533B0811.4050402@redhat.com> References: <1396361877.21555.18.camel@desktop.bpk2.com> <533B0811.4050402@redhat.com> Message-ID: <1396380859.21555.27.camel@desktop.bpk2.com> > Hello! > Before I dive into details, please read about the following bug: > https://fedorahosted.org/bind-dyndb-ldap/ticket/134 > > I just found it, fixed it and I'm attaching patch for you so you don't need to > wait for a new release :-) thanks, but i am not sure how to apply patches. > Your LDAP server will get the whole principal and it is up to the server how > it will map it to some existing entity. what do you do on the IPA side? did you follow some best practice? i am trying not to reinvent the wheel. > BTW documentation about named.conf syntax is in README: > https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/plain/README as well as in the package. i did consult the doc. > Let us know if you encounter any problem. certainly will. > BTW did you see FreeIPA project? It integrates LDAP+Kerberos with management > tools and nice user interface and solver Microsoft AD integration. > > Maybe it could save you some headaches ... not a big fan of 389, as it is a fork of openldap, though RH has done some nifty things with it (dogtag, IPA, etc). i am a bit of a purist, thats all. also, this is a learning exercise for me. i am trying to understand the inner workings of each of the pieces and see how they interoperate with each other. From rmeggins at redhat.com Tue Apr 1 19:47:19 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 01 Apr 2014 13:47:19 -0600 Subject: [Freeipa-users] bind-dyndb-ldap: using keytabs for auth to ldap In-Reply-To: <1396380859.21555.27.camel@desktop.bpk2.com> References: <1396361877.21555.18.camel@desktop.bpk2.com> <533B0811.4050402@redhat.com> <1396380859.21555.27.camel@desktop.bpk2.com> Message-ID: <533B17C7.9070001@redhat.com> On 04/01/2014 01:34 PM, Brendan Kearney wrote: >> Hello! >> Before I dive into details, please read about the following bug: >> https://fedorahosted.org/bind-dyndb-ldap/ticket/134 >> >> I just found it, fixed it and I'm attaching patch for you so you don't need to >> wait for a new release :-) > thanks, but i am not sure how to apply patches. > > >> Your LDAP server will get the whole principal and it is up to the server how >> it will map it to some existing entity. > what do you do on the IPA side? did you follow some best practice? i > am trying not to reinvent the wheel. > >> BTW documentation about named.conf syntax is in README: >> https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/plain/README > as well as in the package. i did consult the doc. > >> Let us know if you encounter any problem. > certainly will. > >> BTW did you see FreeIPA project? It integrates LDAP+Kerberos with management >> tools and nice user interface and solver Microsoft AD integration. >> >> Maybe it could save you some headaches ... > not a big fan of 389, as it is a fork of openldap, No, it is not. http://port389.org/wiki/History > though RH has done > some nifty things with it (dogtag, IPA, etc). i am a bit of a purist, > thats all. also, this is a learning exercise for me. i am trying to > understand the inner workings of each of the pieces and see how they > interoperate with each other. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From bpk678 at gmail.com Tue Apr 1 19:51:37 2014 From: bpk678 at gmail.com (Brendan Kearney) Date: Tue, 01 Apr 2014 15:51:37 -0400 Subject: [Freeipa-users] bind-dyndb-ldap: using keytabs for auth to ldap In-Reply-To: <533B17C7.9070001@redhat.com> References: <1396361877.21555.18.camel@desktop.bpk2.com> <533B0811.4050402@redhat.com> <1396380859.21555.27.camel@desktop.bpk2.com> <533B17C7.9070001@redhat.com> Message-ID: <1396381897.21555.29.camel@desktop.bpk2.com> > No, it is not. > http://port389.org/wiki/History ok then. still, i am trying to learn the individual pieces and get them working together. From sanchez.nevada at gmail.com Tue Apr 1 19:16:58 2014 From: sanchez.nevada at gmail.com (Nevada Sanchez) Date: Tue, 1 Apr 2014 15:16:58 -0400 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: <533AF3D2.5050308@redhat.com> References: <533AF3D2.5050308@redhat.com> Message-ID: 389-ds-base-1.3.1.22-1.fc19.x86_64 The following, I think, summarizes the contents of the error log (I probably uninstalled and tried reimporting 2 or 3 times in what is shown). . . . [01/Apr/2014:03:42:46 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [01/Apr/2014:03:42:46 -0400] - check_and_set_import_cache: pagesize: 4096, pages: 1970554, procpages: 53717 [01/Apr/2014:03:42:46 -0400] - Import allocates 3152884KB import cache. [01/Apr/2014:03:42:46 -0400] - import userRoot: Beginning import job... [01/Apr/2014:03:42:46 -0400] - import userRoot: Index buffering enabled with bucket size 100 [01/Apr/2014:03:42:46 -0400] - import userRoot: Processing file "/var/lib/dirsrv/boot.ldif" [01/Apr/2014:03:42:46 -0400] - import userRoot: Finished scanning file "/var/lib/dirsrv/boot.ldif" (1 entries) [01/Apr/2014:03:42:46 -0400] - import userRoot: Workers finished; cleaning up... [01/Apr/2014:03:42:47 -0400] - import userRoot: Workers cleaned up. [01/Apr/2014:03:42:47 -0400] - import userRoot: Cleaning up producer thread... [01/Apr/2014:03:42:47 -0400] - import userRoot: Indexing complete. Post-processing... [01/Apr/2014:03:42:47 -0400] - import userRoot: Generating numSubordinates complete. [01/Apr/2014:03:42:47 -0400] - Nothing to do to build ancestorid index [01/Apr/2014:03:42:47 -0400] - import userRoot: Flushing caches... [01/Apr/2014:03:42:47 -0400] - import userRoot: Closing files... [01/Apr/2014:03:42:47 -0400] - All database threads now stopped [01/Apr/2014:03:42:47 -0400] - import userRoot: Import complete. Processed 1 entries in 1 seconds. (1.00 entries/sec) [01/Apr/2014:03:42:47 -0400] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [01/Apr/2014:03:42:47 -0400] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. [01/Apr/2014:03:42:48 -0400] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [01/Apr/2014:03:42:48 -0400] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. [01/Apr/2014:03:42:48 -0400] - I'm resizing my cache now...cache was 3228553216 and is now 8000000 [01/Apr/2014:03:42:48 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [01/Apr/2014:03:42:48 -0400] - The change of nsslapd-ldapilisten will not take effect until the server is restarted [01/Apr/2014:03:43:01 -0400] - Warning: Adding configuration attribute "nsslapd-security" [01/Apr/2014:03:43:01 -0400] - slapd shutting down - signaling operation threads [01/Apr/2014:03:43:01 -0400] - slapd shutting down - waiting for 27 threads to terminate [01/Apr/2014:03:43:01 -0400] - slapd shutting down - closing down internal subsystems and plugins [01/Apr/2014:03:43:01 -0400] - Waiting for 4 database threads to stop [01/Apr/2014:03:43:02 -0400] - All database threads now stopped [01/Apr/2014:03:43:02 -0400] - slapd stopped. [01/Apr/2014:03:43:03 -0400] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [01/Apr/2014:03:43:03 -0400] attrcrypt - No symmetric key found for cipher AES in backend userRoot, attempting to create one... [01/Apr/2014:03:43:03 -0400] attrcrypt - Key for cipher AES successfully generated and stored [01/Apr/2014:03:43:03 -0400] attrcrypt - No symmetric key found for cipher 3DES in backend userRoot, attempting to create one... [01/Apr/2014:03:43:03 -0400] attrcrypt - Key for cipher 3DES successfully generated and stored [01/Apr/2014:03:43:03 -0400] ipalockout_get_global_config - [file ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) [01/Apr/2014:03:43:04 -0400] ipaenrollment_start - [file ipa_enrollment.c, line 393]: Failed to get default realm?! [01/Apr/2014:03:43:04 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [01/Apr/2014:03:43:04 -0400] - Listening on All Interfaces port 636 for LDAPS requests [01/Apr/2014:03:43:04 -0400] - Listening on /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests [01/Apr/2014:03:43:04 -0400] - slapd shutting down - signaling operation threads [01/Apr/2014:03:43:04 -0400] - slapd shutting down - waiting for 27 threads to terminate [01/Apr/2014:03:43:05 -0400] - slapd shutting down - closing down internal subsystems and plugins [01/Apr/2014:03:43:05 -0400] - Waiting for 4 database threads to stop [01/Apr/2014:03:43:05 -0400] - All database threads now stopped [01/Apr/2014:03:43:05 -0400] - slapd stopped. [01/Apr/2014:03:43:06 -0400] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [01/Apr/2014:03:43:06 -0400] ipalockout_get_global_config - [file ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) [01/Apr/2014:03:43:06 -0400] ipaenrollment_start - [file ipa_enrollment.c, line 393]: Failed to get default realm?! [01/Apr/2014:03:43:06 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [01/Apr/2014:03:43:06 -0400] - Listening on All Interfaces port 636 for LDAPS requests [01/Apr/2014:03:43:06 -0400] - Listening on /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests [01/Apr/2014:03:43:08 -0400] NSMMReplicationPlugin - agmt="cn= meToipa.example.com" (ipa: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. [01/Apr/2014:03:43:08 -0400] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=example,dc=com is going offline; disabling replication [01/Apr/2014:03:43:08 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [01/Apr/2014:03:43:11 -0400] - import userRoot: Workers finished; cleaning up... [01/Apr/2014:03:43:11 -0400] - import userRoot: Workers cleaned up. [01/Apr/2014:03:43:11 -0400] - import userRoot: Indexing complete. Post-processing... [01/Apr/2014:03:43:11 -0400] - import userRoot: Generating numSubordinates complete. [01/Apr/2014:03:43:12 -0400] - import userRoot: Flushing caches... [01/Apr/2014:03:43:12 -0400] - import userRoot: Closing files... [01/Apr/2014:03:43:12 -0400] - import userRoot: Import complete. Processed 453 entries in 4 seconds. (113.25 entries/sec) [01/Apr/2014:03:43:12 -0400] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=example,dc=com is coming online; enabling replication [01/Apr/2014:03:43:12 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=example,dc=com--no CoS Templates found, which should be added before the CoS Definition. [01/Apr/2014:03:43:19 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:03:43:19 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:03:48:19 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:03:48:19 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:03:53:19 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:03:53:19 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:03:58:19 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:03:58:19 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:03:18 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:03:18 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:08:18 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:08:18 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:13:18 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:13:18 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:18:19 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:18:19 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:23:18 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:23:18 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:28:18 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:28:18 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:33:19 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:33:19 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:38:19 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:38:19 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:43:18 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:43:18 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:48:18 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:48:18 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:53:19 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:53:19 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:58:18 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:04:58:18 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:05:03:18 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:05:03:18 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:05:08:18 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:05:08:18 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:05:13:18 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:05:13:19 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:05:14:36 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:05:14:36 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:05:14:41 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:05:14:41 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:05:14:46 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:05:14:46 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:05:14:58 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:05:14:58 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:05:15:00 -0400] - slapd shutting down - signaling operation threads [01/Apr/2014:05:15:00 -0400] - slapd shutting down - waiting for 28 threads to terminate [01/Apr/2014:05:15:00 -0400] - slapd shutting down - closing down internal subsystems and plugins [01/Apr/2014:05:15:01 -0400] - Waiting for 4 database threads to stop [01/Apr/2014:05:15:01 -0400] - All database threads now stopped [01/Apr/2014:05:15:01 -0400] - slapd stopped. [01/Apr/2014:05:27:38 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [01/Apr/2014:05:27:38 -0400] - check_and_set_import_cache: pagesize: 4096, pages: 1970554, procpages: 53717 [01/Apr/2014:05:27:38 -0400] - Import allocates 3152884KB import cache. [01/Apr/2014:05:27:38 -0400] - import userRoot: Beginning import job... [01/Apr/2014:05:27:38 -0400] - import userRoot: Index buffering enabled with bucket size 100 [01/Apr/2014:05:27:39 -0400] - import userRoot: Processing file "/var/lib/dirsrv/boot.ldif" [01/Apr/2014:05:27:39 -0400] - import userRoot: Finished scanning file "/var/lib/dirsrv/boot.ldif" (1 entries) [01/Apr/2014:05:27:39 -0400] - import userRoot: Workers finished; cleaning up... [01/Apr/2014:05:27:39 -0400] - import userRoot: Workers cleaned up. [01/Apr/2014:05:27:39 -0400] - import userRoot: Cleaning up producer thread... [01/Apr/2014:05:27:39 -0400] - import userRoot: Indexing complete. Post-processing... [01/Apr/2014:05:27:39 -0400] - import userRoot: Generating numSubordinates complete. [01/Apr/2014:05:27:39 -0400] - Nothing to do to build ancestorid index [01/Apr/2014:05:27:39 -0400] - import userRoot: Flushing caches... [01/Apr/2014:05:27:39 -0400] - import userRoot: Closing files... [01/Apr/2014:05:27:40 -0400] - All database threads now stopped [01/Apr/2014:05:27:40 -0400] - import userRoot: Import complete. Processed 1 entries in 2 seconds. (0.50 entries/sec) [01/Apr/2014:05:27:40 -0400] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [01/Apr/2014:05:27:40 -0400] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. [01/Apr/2014:05:27:40 -0400] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [01/Apr/2014:05:27:40 -0400] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. [01/Apr/2014:05:27:40 -0400] - I'm resizing my cache now...cache was 3228553216 and is now 8000000 [01/Apr/2014:05:27:41 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [01/Apr/2014:05:27:41 -0400] - The change of nsslapd-ldapilisten will not take effect until the server is restarted [01/Apr/2014:05:27:54 -0400] - Warning: Adding configuration attribute "nsslapd-security" [01/Apr/2014:05:27:54 -0400] - slapd shutting down - signaling operation threads [01/Apr/2014:05:27:54 -0400] - slapd shutting down - waiting for 28 threads to terminate [01/Apr/2014:05:27:54 -0400] - slapd shutting down - closing down internal subsystems and plugins [01/Apr/2014:05:27:54 -0400] - Waiting for 4 database threads to stop [01/Apr/2014:05:27:55 -0400] - All database threads now stopped [01/Apr/2014:05:27:55 -0400] - slapd stopped. [01/Apr/2014:05:27:56 -0400] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [01/Apr/2014:05:27:56 -0400] attrcrypt - No symmetric key found for cipher AES in backend userRoot, attempting to create one... [01/Apr/2014:05:27:56 -0400] attrcrypt - Key for cipher AES successfully generated and stored [01/Apr/2014:05:27:56 -0400] attrcrypt - No symmetric key found for cipher 3DES in backend userRoot, attempting to create one... [01/Apr/2014:05:27:56 -0400] attrcrypt - Key for cipher 3DES successfully generated and stored [01/Apr/2014:05:27:56 -0400] ipalockout_get_global_config - [file ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) [01/Apr/2014:05:27:56 -0400] ipaenrollment_start - [file ipa_enrollment.c, line 393]: Failed to get default realm?! [01/Apr/2014:05:27:56 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [01/Apr/2014:05:27:56 -0400] - Listening on All Interfaces port 636 for LDAPS requests [01/Apr/2014:05:27:56 -0400] - Listening on /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests [01/Apr/2014:05:27:56 -0400] - slapd shutting down - signaling operation threads [01/Apr/2014:05:27:56 -0400] - slapd shutting down - waiting for 29 threads to terminate [01/Apr/2014:05:27:57 -0400] - slapd shutting down - closing down internal subsystems and plugins [01/Apr/2014:05:27:57 -0400] - Waiting for 4 database threads to stop [01/Apr/2014:05:27:57 -0400] - All database threads now stopped [01/Apr/2014:05:27:57 -0400] - slapd stopped. [01/Apr/2014:05:27:58 -0400] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [01/Apr/2014:05:27:59 -0400] ipalockout_get_global_config - [file ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) [01/Apr/2014:05:27:59 -0400] ipaenrollment_start - [file ipa_enrollment.c, line 393]: Failed to get default realm?! [01/Apr/2014:05:27:59 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [01/Apr/2014:05:27:59 -0400] - Listening on All Interfaces port 636 for LDAPS requests [01/Apr/2014:05:27:59 -0400] - Listening on /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests [01/Apr/2014:05:28:01 -0400] NSMMReplicationPlugin - agmt="cn= meToipa.example.com" (ipa: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. [01/Apr/2014:05:28:01 -0400] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=example,dc=com is going offline; disabling replication [01/Apr/2014:05:28:01 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [01/Apr/2014:05:28:04 -0400] - import userRoot: Workers finished; cleaning up... [01/Apr/2014:05:28:05 -0400] - import userRoot: Workers cleaned up. [01/Apr/2014:05:28:05 -0400] - import userRoot: Indexing complete. Post-processing... [01/Apr/2014:05:28:05 -0400] - import userRoot: Generating numSubordinates complete. [01/Apr/2014:05:28:05 -0400] - import userRoot: Flushing caches... [01/Apr/2014:05:28:05 -0400] - import userRoot: Closing files... [01/Apr/2014:05:28:06 -0400] - import userRoot: Import complete. Processed 453 entries in 5 seconds. (90.60 entries/sec) [01/Apr/2014:05:28:06 -0400] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=example,dc=com is coming online; enabling replication [01/Apr/2014:05:28:06 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=example,dc=com--no CoS Templates found, which should be added before the CoS Definition. [01/Apr/2014:05:32:38 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:05:32:38 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 . . . [01/Apr/2014:13:12:39 -0400] ipalockout_preop - [file ipa_lockout.c, line 749]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 [01/Apr/2014:13:12:39 -0400] ipalockout_postop - [file ipa_lockout.c, line 503]: Failed to retrieve entry "cn=Replication Manager cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 On Tue, Apr 1, 2014 at 1:13 PM, Rich Megginson wrote: > On 04/01/2014 03:46 AM, Nevada Sanchez wrote: > > I've had a replica working with FreeIPA 3.2.1 for awhile. After upgrading > to 3.3.4, the replica wouldn't recognize my admin login anymore. After much > troubleshooting, I decided to try to redo the replica since it was quite > straightforward when I first set it up (what could go wrong, right?) > > What is your version of 389-ds-base? rpm -q 389-ds-base > > What is in your dirsrv errors log? /var/log/dirsrv/slapd-DOMAIN-TLD/errors > > > Unfortunately, I've spent most of my day trying to get the replica to > work this time. I've tried turning off all firewalls on both machines, > rebooting both machines, upgrading all packages on both machines (both are > running Fedora 19), reinstalling FreeIPA packages, and several other > things, but I keep getting stuck at the same step (see output below). > > ================================================================= > [root at ipa2 ipaserver]# ipa-replica-install --setup-dns --no-forwarders > /var/lib/ipa/replica-info-ipa2.example.com.gpg > WARNING: conflicting time&date synchronization service 'chronyd' will > be disabled in favor of ntpd > > Run connection check to master > Check connection from replica to remote master 'ipa.example.com': > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): OK > Kerberos KDC: TCP (88): OK > Kerberos Kpasswd: TCP (464): OK > HTTP Server: Unsecure port (80): OK > HTTP Server: Secure port (443): OK > > The following list of ports use UDP protocol and would need to be > checked manually: > Kerberos KDC: UDP (88): SKIPPED > Kerberos Kpasswd: UDP (464): SKIPPED > > Connection from replica to master is OK. > Start listening on required ports for remote master check > Get credentials to log in to remote master > Check SSH connection to remote master > Execute check on remote master > Check connection from master to remote replica 'ipa2.example.com': > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): OK > Kerberos KDC: TCP (88): OK > Kerberos KDC: UDP (88): OK > Kerberos Kpasswd: TCP (464): OK > Kerberos Kpasswd: UDP (464): OK > HTTP Server: Unsecure port (80): OK > HTTP Server: Secure port (443): OK > > Connection from master to replica is OK. > > Connection check OK > Configuring NTP daemon (ntpd) > [1/4]: stopping ntpd > [2/4]: writing configuration > [3/4]: configuring ntpd to start on boot > [4/4]: starting ntpd > Done configuring NTP daemon (ntpd). > Configuring directory server (dirsrv): Estimated time 1 minute > [1/34]: creating directory server user > [2/34]: creating directory server instance > [3/34]: adding default schema > [4/34]: enabling memberof plugin > [5/34]: enabling winsync plugin > [6/34]: configuring replication version plugin > [7/34]: enabling IPA enrollment plugin > [8/34]: enabling ldapi > [9/34]: configuring uniqueness plugin > [10/34]: configuring uuid plugin > [11/34]: configuring modrdn plugin > [12/34]: configuring DNS plugin > [13/34]: enabling entryUSN plugin > [14/34]: configuring lockout plugin > [15/34]: creating indices > [16/34]: enabling referential integrity plugin > [17/34]: configuring ssl for ds instance > [18/34]: configuring certmap.conf > [19/34]: configure autobind for root > [20/34]: configure new location for managed entries > [21/34]: configure dirsrv ccache > [22/34]: enable SASL mapping fallback > [23/34]: restarting directory server > [24/34]: setting up initial replication > Starting replication, please wait until this has completed. > Update in progress, 5 seconds elapsed > [ipa.example.com] reports: Update failed! Status: [-1 Total update > abortedLDAP error: Can't contact LDAP server] > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Failed to start replication > ================================================================= > > I've confirmed that I can do ldapsearch from each machine to the other > one for the replica status records (through ldap and ldaps), so I know that > they can communicate. Trouble is, something behind the scenes is throwing > the status error (as seen in the nsds5ReplicaLastInitStatus attribute). > > ================================================================= > [root at ipa2 ipaserver]# ldapsearch ldaps://ipa.example.com:636 -D > 'cn=Directory Manager' -w ##### -b 'cn=meToipa2.example.com,cn=replica,cn=dc\=example\,dc\=com,cn=mapping > tree,cn=config' '(objectClass=*)' -s base nsds5ReplicaLastInitStart > nsds5replicaUpdateInProgress nsds5ReplicaLastInitStatus cn > nsds5BeginReplicaRefresh nsds5ReplicaLastInitEnd > # extended LDIF > # > # LDAPv3 > # base tree,cn=config> with scope baseObject > # filter: (objectclass=*) > # requesting: ldaps://ipa.example.com:636 (objectClass=*) > nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress > nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh > nsds5ReplicaLastInitEnd > # > > # meToipa2.example.com, replica, dc\3Dexample\2Cdc\3Dcom, > mapping tree, config > dn: cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cd > c\3Dcom,cn=mapping tree,cn=config > nsds5ReplicaLastInitStart: 20140401092800Z > nsds5replicaUpdateInProgress: FALSE > nsds5ReplicaLastInitStatus: -1 Total update abortedLDAP error: Can't > contact L > DAP server > cn: meToipa2.example.com > nsds5ReplicaLastInitEnd: 20140401092804Z > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > ================================================================= > > I'd really love for someone to help out with this, as I can't afford > another entire night trying to figure this out. Thanks in advance! > > -Nevada > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Apr 1 20:19:41 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 1 Apr 2014 22:19:41 +0200 Subject: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate In-Reply-To: References: <5339EF9B.3070606@redhat.com> <94b3969cbcd3400d804b4c3dc4332fd7@BY2PR03MB176.namprd03.prod.outlook.com> <5339F1B0.8030209@redhat.com> <95da496c517c455281c0833c200367f0@BY2PR03MB176.namprd03.prod.outlook.com> <20140401071910.GD11404@localhost.localdomain> Message-ID: <20140401201941.GA8263@hendrix.redhat.com> On Tue, Apr 01, 2014 at 05:58:00PM +0000, Todd Maugh wrote: > I am seeing this error in /var/log/secure > > [root at black-64.qa ~]# tail /var/log/secure > Apr 1 17:54:05 black-64 sshd[3649]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.194.1.250 user=tmaugh > Apr 1 17:54:05 black-64 sshd[3649]: pam_sss(sshd:auth): received for user tmaugh: 4 (System error) > Apr 1 17:54:07 black-64 sshd[3649]: Failed password for tmaugh from 10.194.1.250 port 44697 ssh2 > Apr 1 17:54:12 black-64 sshd[3649]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.194.1.250 user=tmaugh > Apr 1 17:54:12 black-64 sshd[3649]: pam_sss(sshd:auth): received for user tmaugh: 4 (System error) "System Error" means something like "Unhandled exception" from pam_sss. In general, this shouldn't happen, although System Error is not always indicative of a bug in SSSD. We use System Error as the default return code if no other condition matches, so sometimes we just fail to translate the error code properly -- at one point, we used to return System Error on clock skew for instance. Could you attach or paste (to me directly if needed) the domain log file and also the krb5_child.log ? > Apr 1 17:54:14 black-64 sshd[3649]: Failed password for tmaugh from 10.194.1.250 port 44697 ssh2 > Apr 1 17:54:15 black-64 sshd[3650]: Connection closed by 10.194.1.250 > Apr 1 17:54:15 black-64 sshd[3649]: PAM 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.194.1.250 user=tmaugh > Apr 1 17:56:49 black-64 sshd[3713]: Accepted publickey for root from 10.194.1.250 port 38249 ssh2 > Apr 1 17:56:49 black-64 sshd[3713]: pam_unix(sshd:session): session opened for user root by (uid=0) From tmaugh at boingo.com Tue Apr 1 20:58:37 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 1 Apr 2014 20:58:37 +0000 Subject: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate In-Reply-To: <20140401201941.GA8263@hendrix.redhat.com> References: <5339EF9B.3070606@redhat.com> <94b3969cbcd3400d804b4c3dc4332fd7@BY2PR03MB176.namprd03.prod.outlook.com> <5339F1B0.8030209@redhat.com> <95da496c517c455281c0833c200367f0@BY2PR03MB176.namprd03.prod.outlook.com> <20140401071910.GD11404@localhost.localdomain> , <20140401201941.GA8263@hendrix.redhat.com> Message-ID: /var/log/sssd/krb5_child.log is empty here is the sssd domain log sssd_ops.boingo.com.log 97][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:28:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:29:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:29:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:30:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:30:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:31:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:31:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:32:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:32:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:33:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:33:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:34:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:34:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:35:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:35:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:36:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:36:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:37:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:37:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:38:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:38:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:39:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:39:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:40:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:40:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:40:10 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4099][1][name=tmaugh] (Tue Apr 1 19:40:10 2014) [sssd[be[ops.boingo.com]]] [sdap_initgr_nested_send] (4): User entry lacks original memberof ? (Tue Apr 1 19:40:10 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:41:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:41:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:42:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:42:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:43:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:43:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:44:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:44:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:45:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:45:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:46:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:46:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:47:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:47:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:48:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:48:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:49:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:49:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:50:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:50:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:51:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:51:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:52:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:52:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:53:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:53:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:54:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:54:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:55:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:55:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:56:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:56:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:57:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:57:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:58:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:58:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:59:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:59:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:00:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:00:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:01:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:01:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:02:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:02:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:03:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:03:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:04:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:04:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:05:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:05:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:06:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:06:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:07:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:07:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:08:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:08:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:09:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:09:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:10:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:10:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:11:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:11:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:12:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:12:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:13:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:13:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:13:50 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4099][1][name=pin] (Tue Apr 1 20:13:50 2014) [sssd[be[ops.boingo.com]]] [sdap_get_initgr_user] (2): Expected one user entry and got 0 (Tue Apr 1 20:13:50 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:14:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:14:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:15:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:15:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:16:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:16:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:17:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:17:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:18:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:18:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:19:02 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:19:02 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:20:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:20:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:21:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:21:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:22:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:22:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:23:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:23:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:24:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:24:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:25:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:25:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:26:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:26:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:27:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:27:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:28:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:28:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:29:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:29:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:30:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:30:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:31:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:31:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:32:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:32:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:33:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:33:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:34:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:34:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:35:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:35:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:36:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:36:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:37:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:37:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:38:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:38:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:39:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:39:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:40:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:40:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:40:25 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4099][1][name=tmaugh] (Tue Apr 1 20:40:25 2014) [sssd[be[ops.boingo.com]]] [sdap_initgr_nested_send] (4): User entry lacks original memberof ? (Tue Apr 1 20:40:25 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:41:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:41:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:42:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:42:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:43:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:43:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:44:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:44:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:45:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:45:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:46:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:46:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:47:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:47:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:48:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:48:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:49:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:49:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:49:20 2014) [sssd[be[ops.boingo.com]]] [sbus_dispatch] (3): Connection is not open for dispatching. (Tue Apr 1 20:49:20 2014) [sssd[be[ops.boingo.com]]] [be_client_destructor] (4): Removed PAM client (Tue Apr 1 20:49:20 2014) [sssd[be[ops.boingo.com]]] [sbus_dispatch] (3): Connection is not open for dispatching. (Tue Apr 1 20:49:20 2014) [sssd[be[ops.boingo.com]]] [be_client_destructor] (4): Removed NSS client (Tue Apr 1 20:49:20 2014) [sssd[be[ops.boingo.com]]] [remove_krb5_info_files] (5): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.OPS.BOINGO.COM], [2][No such file or directory] (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [server_setup] (3): CONFDB: /var/lib/sss/db/config.ldb (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [recreate_ares_channel] (4): Initializing new c-ares channel (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [fo_context_init] (3): Created new fail over context, retry timeout is 30 (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [confdb_get_domain_internal] (1): No enumeration for [ops.boingo.com]! (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sysdb_domain_init_internal] (5): DB File for ops.boingo.com: /var/lib/sss/db/cache_ops.boingo.com.ldb (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sbus_init_connection] (5): Adding connection 736BC0 (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [monitor_common_send_id] (4): Sending ID: (%BE_ops.boingo.com,1) (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sbus_new_server] (3): D-BUS Server listening on unix:path=/var/lib/sss/pipes/private/sbus-dp_ops.boingo.com.7919,guid=059ed610f0f84928a4a10c00533b2652 (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [fo_new_service] (3): Creating new service 'IPA' (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [fo_add_srv_server] (3): Adding new SRV server in domain 'unknown', to service 'IPA' using tcp (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [fo_add_server] (3): Adding new server 'idm-master-els.ops.boingo.com', to service 'IPA' (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_entry_usn has value entryUSN (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_rootdse_last_usn has value lastUSN (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_object_class has value posixAccount (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_name has value uid (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_pwd has value userPassword (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_uid_number has value uidNumber (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_gid_number has value gidNumber (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_gecos has value gecos (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_home_directory has value homeDirectory (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shell has value loginShell (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_principal has value krbPrincipalName (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_fullname has value cn (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_member_of has value memberOf (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_uuid has value nsUniqueId (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_modify_timestamp has value modifyTimestamp (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_entry_usn has value (null) (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_last_change has value shadowLastChange (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_min has value shadowMin (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_max has value shadowMax (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_warning has value shadowWarning (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_inactive has value shadowInactive (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_expire has value shadowExpire (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_flag has value shadowFlag (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_krb_last_pwd_change has value krbLastPwdChange (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_krb_password_expiration has value krbPasswordExpiration (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_pwd_attribute has value pwdAttribute (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_authorized_service has value authorizedService (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_ad_account_expires has value accountExpires (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_ad_user_account_control has value userAccountControl (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_ns_account_lock has value nsAccountLock (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_object_class has value posixGroup (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_name has value cn (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_pwd has value userPassword (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_gid_number has value gidNumber (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_member has value member (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_uuid has value nsUniqueId (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_modify_timestamp has value modifyTimestamp (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_entry_usn has value (null) (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_object_class has value nisNetgroup (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_name has value cn (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_member has value memberNisNetgroup (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_triple has value nisNetgroupTriple (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_uuid has value nsUniqueId (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_modify_timestamp has value modifyTimestamp (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sss_krb5_verify_keytab] (4): Principal name is: [host/black-62.qa.boingo.com at OPS.BOINGO.COM] (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [krb5_try_kdcip] (4): No KDC found in configuration, trying legacy option (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_entry_usn has value entryUSN (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_rootdse_last_usn has value lastUSN (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_object_class has value posixAccount (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_name has value uid (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_pwd has value userPassword (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_uid_number has value uidNumber (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_gid_number has value gidNumber (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_gecos has value gecos (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_home_directory has value homeDirectory (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shell has value loginShell (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_principal has value krbPrincipalName (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_fullname has value cn (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_member_of has value memberOf (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_uuid has value nsUniqueId (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_modify_timestamp has value modifyTimestamp (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_entry_usn has value (null) (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_last_change has value shadowLastChange (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_min has value shadowMin (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_max has value shadowMax (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_warning has value shadowWarning (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_inactive has value shadowInactive (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_expire has value shadowExpire (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_flag has value shadowFlag (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_krb_last_pwd_change has value krbLastPwdChange (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_krb_password_expiration has value krbPasswordExpiration (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_pwd_attribute has value pwdAttribute (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_authorized_service has value authorizedService (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_ad_account_expires has value accountExpires (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_ad_user_account_control has value userAccountControl (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_ns_account_lock has value nsAccountLock (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_object_class has value posixGroup (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_name has value cn (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_pwd has value userPassword (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_gid_number has value gidNumber (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_member has value member (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_uuid has value nsUniqueId (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_modify_timestamp has value modifyTimestamp (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_entry_usn has value (null) (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_object_class has value nisNetgroup (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_name has value cn (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_member has value memberNisNetgroup (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_triple has value nisNetgroupTriple (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_uuid has value nsUniqueId (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_modify_timestamp has value modifyTimestamp (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [check_and_export_lifetime] (5): No lifetime configured. (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [check_and_export_lifetime] (5): No lifetime configured. (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [check_and_export_options] (1): No KDC explicitly configured, using defaults. (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [check_and_export_options] (1): No kpasswd server explicitly configured, using the KDC or defaults. (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [main] (1): Backend provider (ops.boingo.com) started! (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [id_callback] (4): Got id ack and version (1) from Monitor (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sbus_server_init_new_connection] (5): Entering. (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sbus_server_init_new_connection] (5): Adding connection 0x1365d20. (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sbus_init_connection] (5): Adding connection 1365D20 (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sbus_server_init_new_connection] (5): Got a connection (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [be_client_init] (4): Set-up Backend ID timeout [0x1366820] (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [sbus_server_init_new_connection] (5): Entering. (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [sbus_server_init_new_connection] (5): Adding connection 0x13684c0. (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [sbus_init_connection] (5): Adding connection 13684C0 (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [sbus_server_init_new_connection] (5): Got a connection (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [be_client_init] (4): Set-up Backend ID timeout [0x1368ce0] (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [client_registration] (4): Cancel DP ID timeout [0x1366820] (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [client_registration] (4): Added Frontend client [PAM] (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [client_registration] (4): Cancel DP ID timeout [0x1368ce0] (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [client_registration] (4): Added Frontend client [NSS] (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=csteinke] (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [fo_resolve_service_send] (4): Trying to resolve service 'IPA' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [resolv_gethostbyname_files_send] (4): Trying to resolve A record of 'black-62.qa.boingo.com' in files (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [resolve_srv_cont] (4): Searching for servers via SRV query '_ldap._tcp.qa.boingo.com' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [resolv_getsrv_send] (4): Trying to resolve SRV record of '_ldap._tcp.qa.boingo.com' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [resolve_srv_done] (1): SRV query failed: [Domain name not found] (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [resolve_srv_cont] (4): Searching for servers via SRV query '_ldap._tcp.ops.boingo.com' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [resolv_getsrv_send] (4): Trying to resolve SRV record of '_ldap._tcp.ops.boingo.com' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [resolve_srv_done] (1): SRV query failed: [Domain name not found] (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [fo_set_port_status] (4): Marking port 0 of server '(no name)' as 'not working' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [set_srv_data_status] (4): Marking SRV lookup of service 'IPA' as 'not resolved' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [fo_resolve_service_send] (4): Trying to resolve service 'IPA' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [resolv_gethostbyname_files_send] (4): Trying to resolve A record of 'idm-master-els.ops.boingo.com' in files (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [set_server_common_status] (4): Marking server 'idm-master-els.ops.boingo.com' as 'resolving name' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [set_server_common_status] (4): Marking server 'idm-master-els.ops.boingo.com' as 'name resolved' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [be_resolve_server_done] (4): Found address for server idm-master-els.ops.boingo.com: [172.22.170.46] TTL 7200 (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [fo_resolve_service_send] (4): Trying to resolve service 'IPA' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [be_resolve_server_done] (4): Found address for server idm-master-els.ops.boingo.com: [172.22.170.46] TTL 7200 (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: host/black-62.qa.boingo.com (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [child_sig_handler] (4): child [7939] finished successfully. (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [fo_set_port_status] (4): Marking port 0 of server 'idm-master-els.ops.boingo.com' as 'working' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [set_server_common_status] (4): Marking server 'idm-master-els.ops.boingo.com' as 'working' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [be_run_online_cb] (3): Going online. Running callbacks. (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [delayed_online_authentication_callback] (5): Backend is online, starting delayed online authentication. (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4099][1][name=csteinke] (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [sdap_initgr_nested_send] (4): User entry lacks original memberof ? (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:50:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:50:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:50:38 2014) [sssd[be[ops.boingo.com]]] [sbus_dispatch] (3): Connection is not open for dispatching. (Tue Apr 1 20:50:38 2014) [sssd[be[ops.boingo.com]]] [be_client_destructor] (4): Removed PAM client (Tue Apr 1 20:50:38 2014) [sssd[be[ops.boingo.com]]] [sbus_dispatch] (3): Connection is not open for dispatching. (Tue Apr 1 20:50:38 2014) [sssd[be[ops.boingo.com]]] [be_client_destructor] (4): Removed NSS client (Tue Apr 1 20:50:38 2014) [sssd[be[ops.boingo.com]]] [remove_krb5_info_files] (5): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.OPS.BOINGO.COM], [2][No such file or directory] ________________________________________ From: freeipa-users-bounces at redhat.com on behalf of Jakub Hrozek Sent: Tuesday, April 01, 2014 1:19 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate On Tue, Apr 01, 2014 at 05:58:00PM +0000, Todd Maugh wrote: > I am seeing this error in /var/log/secure > > [root at black-64.qa ~]# tail /var/log/secure > Apr 1 17:54:05 black-64 sshd[3649]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.194.1.250 user=tmaugh > Apr 1 17:54:05 black-64 sshd[3649]: pam_sss(sshd:auth): received for user tmaugh: 4 (System error) > Apr 1 17:54:07 black-64 sshd[3649]: Failed password for tmaugh from 10.194.1.250 port 44697 ssh2 > Apr 1 17:54:12 black-64 sshd[3649]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.194.1.250 user=tmaugh > Apr 1 17:54:12 black-64 sshd[3649]: pam_sss(sshd:auth): received for user tmaugh: 4 (System error) "System Error" means something like "Unhandled exception" from pam_sss. In general, this shouldn't happen, although System Error is not always indicative of a bug in SSSD. We use System Error as the default return code if no other condition matches, so sometimes we just fail to translate the error code properly -- at one point, we used to return System Error on clock skew for instance. Could you attach or paste (to me directly if needed) the domain log file and also the krb5_child.log ? > Apr 1 17:54:14 black-64 sshd[3649]: Failed password for tmaugh from 10.194.1.250 port 44697 ssh2 > Apr 1 17:54:15 black-64 sshd[3650]: Connection closed by 10.194.1.250 > Apr 1 17:54:15 black-64 sshd[3649]: PAM 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.194.1.250 user=tmaugh > Apr 1 17:56:49 black-64 sshd[3713]: Accepted publickey for root from 10.194.1.250 port 38249 ssh2 > Apr 1 17:56:49 black-64 sshd[3713]: pam_unix(sshd:session): session opened for user root by (uid=0) _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From rmeggins at redhat.com Tue Apr 1 21:30:53 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 01 Apr 2014 15:30:53 -0600 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: References: <533AF3D2.5050308@redhat.com> <533B11F6.3040603@redhat.com> Message-ID: <533B300D.6050707@redhat.com> On 04/01/2014 03:28 PM, Nevada Sanchez wrote: > Okay, I just tried doing this on a FRESH fedora 19 image (applied all > updates, installed freeipa, made a new replica file for the new test > server, and went state to ipa-replica-insntall). Exact same errors. > Anything else I should try? I don't know. Does anyone on the IPA team know what the ipa_lockout errors are about, and if they would cause replication not to work? > > > On Tue, Apr 1, 2014 at 3:22 PM, Rich Megginson > wrote: > > On 04/01/2014 01:16 PM, Nevada Sanchez wrote: >> 389-ds-base-1.3.1.22-1.fc19.x86_64 >> >> The following, I think, summarizes the contents of the error log >> (I probably uninstalled and tried reimporting 2 or 3 times in >> what is shown). >> >> . >> . >> . >> [01/Apr/2014:03:42:46 -0400] - WARNING: Import is running with >> nsslapd-db-private-import-mem on; No other process is allowed to >> access the database >> [01/Apr/2014:03:42:46 -0400] - check_and_set_import_cache: >> pagesize: 4096, pages: 1970554, procpages: 53717 >> [01/Apr/2014:03:42:46 -0400] - Import allocates 3152884KB import >> cache. >> [01/Apr/2014:03:42:46 -0400] - import userRoot: Beginning import >> job... >> [01/Apr/2014:03:42:46 -0400] - import userRoot: Index buffering >> enabled with bucket size 100 >> [01/Apr/2014:03:42:46 -0400] - import userRoot: Processing file >> "/var/lib/dirsrv/boot.ldif" >> [01/Apr/2014:03:42:46 -0400] - import userRoot: Finished scanning >> file "/var/lib/dirsrv/boot.ldif" (1 entries) >> [01/Apr/2014:03:42:46 -0400] - import userRoot: Workers finished; >> cleaning up... >> [01/Apr/2014:03:42:47 -0400] - import userRoot: Workers cleaned up. >> [01/Apr/2014:03:42:47 -0400] - import userRoot: Cleaning up >> producer thread... >> [01/Apr/2014:03:42:47 -0400] - import userRoot: Indexing >> complete. Post-processing... >> [01/Apr/2014:03:42:47 -0400] - import userRoot: Generating >> numSubordinates complete. >> [01/Apr/2014:03:42:47 -0400] - Nothing to do to build ancestorid >> index >> [01/Apr/2014:03:42:47 -0400] - import userRoot: Flushing caches... >> [01/Apr/2014:03:42:47 -0400] - import userRoot: Closing files... >> [01/Apr/2014:03:42:47 -0400] - All database threads now stopped >> [01/Apr/2014:03:42:47 -0400] - import userRoot: Import complete. >> Processed 1 entries in 1 seconds. (1.00 entries/sec) >> [01/Apr/2014:03:42:47 -0400] - 389-Directory/1.3.1.22.a1 >> B2014.073.1751 starting up >> [01/Apr/2014:03:42:47 -0400] - Db home directory is not set. >> Possibly nsslapd-directory (optionally nsslapd-db-home-directory) >> is missing in the config file. >> [01/Apr/2014:03:42:48 -0400] - 389-Directory/1.3.1.22.a1 >> B2014.073.1751 starting up >> [01/Apr/2014:03:42:48 -0400] - Db home directory is not set. >> Possibly nsslapd-directory (optionally nsslapd-db-home-directory) >> is missing in the config file. >> [01/Apr/2014:03:42:48 -0400] - I'm resizing my cache now...cache >> was 3228553216 and is now 8000000 >> [01/Apr/2014:03:42:48 -0400] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [01/Apr/2014:03:42:48 -0400] - The change of nsslapd-ldapilisten >> will not take effect until the server is restarted >> [01/Apr/2014:03:43:01 -0400] - Warning: Adding configuration >> attribute "nsslapd-security" >> [01/Apr/2014:03:43:01 -0400] - slapd shutting down - signaling >> operation threads >> [01/Apr/2014:03:43:01 -0400] - slapd shutting down - waiting for >> 27 threads to terminate >> [01/Apr/2014:03:43:01 -0400] - slapd shutting down - closing down >> internal subsystems and plugins >> [01/Apr/2014:03:43:01 -0400] - Waiting for 4 database threads to stop >> [01/Apr/2014:03:43:02 -0400] - All database threads now stopped >> [01/Apr/2014:03:43:02 -0400] - slapd stopped. >> [01/Apr/2014:03:43:03 -0400] - 389-Directory/1.3.1.22.a1 >> B2014.073.1751 starting up >> [01/Apr/2014:03:43:03 -0400] attrcrypt - No symmetric key found >> for cipher AES in backend userRoot, attempting to create one... >> [01/Apr/2014:03:43:03 -0400] attrcrypt - Key for cipher AES >> successfully generated and stored >> [01/Apr/2014:03:43:03 -0400] attrcrypt - No symmetric key found >> for cipher 3DES in backend userRoot, attempting to create one... >> [01/Apr/2014:03:43:03 -0400] attrcrypt - Key for cipher 3DES >> successfully generated and stored >> [01/Apr/2014:03:43:03 -0400] ipalockout_get_global_config - [file >> ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) >> [01/Apr/2014:03:43:04 -0400] ipaenrollment_start - [file >> ipa_enrollment.c, line 393]: Failed to get default realm?! >> [01/Apr/2014:03:43:04 -0400] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [01/Apr/2014:03:43:04 -0400] - Listening on All Interfaces port >> 636 for LDAPS requests >> [01/Apr/2014:03:43:04 -0400] - Listening on >> /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests >> [01/Apr/2014:03:43:04 -0400] - slapd shutting down - signaling >> operation threads >> [01/Apr/2014:03:43:04 -0400] - slapd shutting down - waiting for >> 27 threads to terminate >> [01/Apr/2014:03:43:05 -0400] - slapd shutting down - closing down >> internal subsystems and plugins >> [01/Apr/2014:03:43:05 -0400] - Waiting for 4 database threads to stop >> [01/Apr/2014:03:43:05 -0400] - All database threads now stopped >> [01/Apr/2014:03:43:05 -0400] - slapd stopped. >> [01/Apr/2014:03:43:06 -0400] - 389-Directory/1.3.1.22.a1 >> B2014.073.1751 starting up >> [01/Apr/2014:03:43:06 -0400] ipalockout_get_global_config - [file >> ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) >> [01/Apr/2014:03:43:06 -0400] ipaenrollment_start - [file >> ipa_enrollment.c, line 393]: Failed to get default realm?! >> [01/Apr/2014:03:43:06 -0400] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [01/Apr/2014:03:43:06 -0400] - Listening on All Interfaces port >> 636 for LDAPS requests >> [01/Apr/2014:03:43:06 -0400] - Listening on >> /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests >> [01/Apr/2014:03:43:08 -0400] NSMMReplicationPlugin - >> agmt="cn=meToipa.example.com " >> (ipa: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. >> [01/Apr/2014:03:43:08 -0400] NSMMReplicationPlugin - >> multimaster_be_state_change: replica dc=example,dc=com is going >> offline; disabling replication >> [01/Apr/2014:03:43:08 -0400] - WARNING: Import is running with >> nsslapd-db-private-import-mem on; No other process is allowed to >> access the database >> [01/Apr/2014:03:43:11 -0400] - import userRoot: Workers finished; >> cleaning up... >> [01/Apr/2014:03:43:11 -0400] - import userRoot: Workers cleaned up. >> [01/Apr/2014:03:43:11 -0400] - import userRoot: Indexing >> complete. Post-processing... >> [01/Apr/2014:03:43:11 -0400] - import userRoot: Generating >> numSubordinates complete. >> [01/Apr/2014:03:43:12 -0400] - import userRoot: Flushing caches... >> [01/Apr/2014:03:43:12 -0400] - import userRoot: Closing files... >> [01/Apr/2014:03:43:12 -0400] - import userRoot: Import complete. >> Processed 453 entries in 4 seconds. (113.25 entries/sec) >> [01/Apr/2014:03:43:12 -0400] NSMMReplicationPlugin - >> multimaster_be_state_change: replica dc=example,dc=com is coming >> online; enabling replication >> [01/Apr/2014:03:43:12 -0400] - Skipping CoS Definition >> cn=Password Policy,cn=accounts,dc=example,dc=com--no CoS >> Templates found, which should be added before the CoS Definition. >> [01/Apr/2014:03:43:19 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:03:43:19 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:03:48:19 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:03:48:19 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:03:53:19 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:03:53:19 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:03:58:19 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:03:58:19 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:03:18 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:03:18 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:08:18 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:08:18 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:13:18 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:13:18 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:18:19 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:18:19 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:23:18 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:23:18 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:28:18 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:28:18 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:33:19 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:33:19 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:38:19 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:38:19 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:43:18 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:43:18 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:48:18 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:48:18 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:53:19 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:53:19 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:58:18 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:04:58:18 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:05:03:18 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:05:03:18 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:05:08:18 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:05:08:18 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:05:13:18 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:05:13:19 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:05:14:36 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:05:14:36 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:05:14:41 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:05:14:41 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:05:14:46 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:05:14:46 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:05:14:58 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:05:14:58 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:05:15:00 -0400] - slapd shutting down - signaling >> operation threads >> [01/Apr/2014:05:15:00 -0400] - slapd shutting down - waiting for >> 28 threads to terminate >> [01/Apr/2014:05:15:00 -0400] - slapd shutting down - closing down >> internal subsystems and plugins >> [01/Apr/2014:05:15:01 -0400] - Waiting for 4 database threads to stop >> [01/Apr/2014:05:15:01 -0400] - All database threads now stopped >> [01/Apr/2014:05:15:01 -0400] - slapd stopped. >> [01/Apr/2014:05:27:38 -0400] - WARNING: Import is running with >> nsslapd-db-private-import-mem on; No other process is allowed to >> access the database >> [01/Apr/2014:05:27:38 -0400] - check_and_set_import_cache: >> pagesize: 4096, pages: 1970554, procpages: 53717 >> [01/Apr/2014:05:27:38 -0400] - Import allocates 3152884KB import >> cache. >> [01/Apr/2014:05:27:38 -0400] - import userRoot: Beginning import >> job... >> [01/Apr/2014:05:27:38 -0400] - import userRoot: Index buffering >> enabled with bucket size 100 >> [01/Apr/2014:05:27:39 -0400] - import userRoot: Processing file >> "/var/lib/dirsrv/boot.ldif" >> [01/Apr/2014:05:27:39 -0400] - import userRoot: Finished scanning >> file "/var/lib/dirsrv/boot.ldif" (1 entries) >> [01/Apr/2014:05:27:39 -0400] - import userRoot: Workers finished; >> cleaning up... >> [01/Apr/2014:05:27:39 -0400] - import userRoot: Workers cleaned up. >> [01/Apr/2014:05:27:39 -0400] - import userRoot: Cleaning up >> producer thread... >> [01/Apr/2014:05:27:39 -0400] - import userRoot: Indexing >> complete. Post-processing... >> [01/Apr/2014:05:27:39 -0400] - import userRoot: Generating >> numSubordinates complete. >> [01/Apr/2014:05:27:39 -0400] - Nothing to do to build ancestorid >> index >> [01/Apr/2014:05:27:39 -0400] - import userRoot: Flushing caches... >> [01/Apr/2014:05:27:39 -0400] - import userRoot: Closing files... >> [01/Apr/2014:05:27:40 -0400] - All database threads now stopped >> [01/Apr/2014:05:27:40 -0400] - import userRoot: Import complete. >> Processed 1 entries in 2 seconds. (0.50 entries/sec) >> [01/Apr/2014:05:27:40 -0400] - 389-Directory/1.3.1.22.a1 >> B2014.073.1751 starting up >> [01/Apr/2014:05:27:40 -0400] - Db home directory is not set. >> Possibly nsslapd-directory (optionally nsslapd-db-home-directory) >> is missing in the config file. >> [01/Apr/2014:05:27:40 -0400] - 389-Directory/1.3.1.22.a1 >> B2014.073.1751 starting up >> [01/Apr/2014:05:27:40 -0400] - Db home directory is not set. >> Possibly nsslapd-directory (optionally nsslapd-db-home-directory) >> is missing in the config file. >> [01/Apr/2014:05:27:40 -0400] - I'm resizing my cache now...cache >> was 3228553216 and is now 8000000 >> [01/Apr/2014:05:27:41 -0400] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [01/Apr/2014:05:27:41 -0400] - The change of nsslapd-ldapilisten >> will not take effect until the server is restarted >> [01/Apr/2014:05:27:54 -0400] - Warning: Adding configuration >> attribute "nsslapd-security" >> [01/Apr/2014:05:27:54 -0400] - slapd shutting down - signaling >> operation threads >> [01/Apr/2014:05:27:54 -0400] - slapd shutting down - waiting for >> 28 threads to terminate >> [01/Apr/2014:05:27:54 -0400] - slapd shutting down - closing down >> internal subsystems and plugins >> [01/Apr/2014:05:27:54 -0400] - Waiting for 4 database threads to stop >> [01/Apr/2014:05:27:55 -0400] - All database threads now stopped >> [01/Apr/2014:05:27:55 -0400] - slapd stopped. >> [01/Apr/2014:05:27:56 -0400] - 389-Directory/1.3.1.22.a1 >> B2014.073.1751 starting up >> [01/Apr/2014:05:27:56 -0400] attrcrypt - No symmetric key found >> for cipher AES in backend userRoot, attempting to create one... >> [01/Apr/2014:05:27:56 -0400] attrcrypt - Key for cipher AES >> successfully generated and stored >> [01/Apr/2014:05:27:56 -0400] attrcrypt - No symmetric key found >> for cipher 3DES in backend userRoot, attempting to create one... >> [01/Apr/2014:05:27:56 -0400] attrcrypt - Key for cipher 3DES >> successfully generated and stored >> [01/Apr/2014:05:27:56 -0400] ipalockout_get_global_config - [file >> ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) >> [01/Apr/2014:05:27:56 -0400] ipaenrollment_start - [file >> ipa_enrollment.c, line 393]: Failed to get default realm?! >> [01/Apr/2014:05:27:56 -0400] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [01/Apr/2014:05:27:56 -0400] - Listening on All Interfaces port >> 636 for LDAPS requests >> [01/Apr/2014:05:27:56 -0400] - Listening on >> /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests >> [01/Apr/2014:05:27:56 -0400] - slapd shutting down - signaling >> operation threads >> [01/Apr/2014:05:27:56 -0400] - slapd shutting down - waiting for >> 29 threads to terminate >> [01/Apr/2014:05:27:57 -0400] - slapd shutting down - closing down >> internal subsystems and plugins >> [01/Apr/2014:05:27:57 -0400] - Waiting for 4 database threads to stop >> [01/Apr/2014:05:27:57 -0400] - All database threads now stopped >> [01/Apr/2014:05:27:57 -0400] - slapd stopped. >> [01/Apr/2014:05:27:58 -0400] - 389-Directory/1.3.1.22.a1 >> B2014.073.1751 starting up >> [01/Apr/2014:05:27:59 -0400] ipalockout_get_global_config - [file >> ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) >> [01/Apr/2014:05:27:59 -0400] ipaenrollment_start - [file >> ipa_enrollment.c, line 393]: Failed to get default realm?! >> [01/Apr/2014:05:27:59 -0400] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [01/Apr/2014:05:27:59 -0400] - Listening on All Interfaces port >> 636 for LDAPS requests >> [01/Apr/2014:05:27:59 -0400] - Listening on >> /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests >> [01/Apr/2014:05:28:01 -0400] NSMMReplicationPlugin - >> agmt="cn=meToipa.example.com " >> (ipa: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. >> [01/Apr/2014:05:28:01 -0400] NSMMReplicationPlugin - >> multimaster_be_state_change: replica dc=example,dc=com is going >> offline; disabling replication >> [01/Apr/2014:05:28:01 -0400] - WARNING: Import is running with >> nsslapd-db-private-import-mem on; No other process is allowed to >> access the database >> [01/Apr/2014:05:28:04 -0400] - import userRoot: Workers finished; >> cleaning up... >> [01/Apr/2014:05:28:05 -0400] - import userRoot: Workers cleaned up. >> [01/Apr/2014:05:28:05 -0400] - import userRoot: Indexing >> complete. Post-processing... >> [01/Apr/2014:05:28:05 -0400] - import userRoot: Generating >> numSubordinates complete. >> [01/Apr/2014:05:28:05 -0400] - import userRoot: Flushing caches... >> [01/Apr/2014:05:28:05 -0400] - import userRoot: Closing files... >> [01/Apr/2014:05:28:06 -0400] - import userRoot: Import complete. >> Processed 453 entries in 5 seconds. (90.60 entries/sec) >> [01/Apr/2014:05:28:06 -0400] NSMMReplicationPlugin - >> multimaster_be_state_change: replica dc=example,dc=com is coming >> online; enabling replication >> [01/Apr/2014:05:28:06 -0400] - Skipping CoS Definition >> cn=Password Policy,cn=accounts,dc=example,dc=com--no CoS >> Templates found, which should be added before the CoS Definition. >> [01/Apr/2014:05:32:38 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:05:32:38 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> . >> . >> . >> [01/Apr/2014:13:12:39 -0400] ipalockout_preop - [file >> ipa_lockout.c, line 749]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 >> [01/Apr/2014:13:12:39 -0400] ipalockout_postop - [file >> ipa_lockout.c, line 503]: Failed to retrieve entry >> "cn=Replication Manager >> cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > > This seems bad, but I'm not sure if this is the root of the > replication problem. > > >> >> >> >> On Tue, Apr 1, 2014 at 1:13 PM, Rich Megginson >> > wrote: >> >> On 04/01/2014 03:46 AM, Nevada Sanchez wrote: >>> I've had a replica working with FreeIPA 3.2.1 for awhile. >>> After upgrading to 3.3.4, the replica wouldn't recognize my >>> admin login anymore. After much troubleshooting, I decided >>> to try to redo the replica since it was quite >>> straightforward when I first set it up (what could go wrong, >>> right?) >> What is your version of 389-ds-base? rpm -q 389-ds-base >> >> What is in your dirsrv errors log? >> /var/log/dirsrv/slapd-DOMAIN-TLD/errors >> >>> >>> Unfortunately, I've spent most of my day trying to get the >>> replica to work this time. I've tried turning off all >>> firewalls on both machines, rebooting both machines, >>> upgrading all packages on both machines (both are running >>> Fedora 19), reinstalling FreeIPA packages, and several other >>> things, but I keep getting stuck at the same step (see >>> output below). >>> >>> ================================================================= >>> [root at ipa2 ipaserver]# ipa-replica-install --setup-dns >>> --no-forwarders /var/lib/ipa/replica-info-ipa2.example.com.gpg >>> WARNING: conflicting time&date synchronization service >>> 'chronyd' will >>> be disabled in favor of ntpd >>> >>> Run connection check to master >>> Check connection from replica to remote master >>> 'ipa.example.com ': >>> Directory Service: Unsecure port (389): OK >>> Directory Service: Secure port (636): OK >>> Kerberos KDC: TCP (88): OK >>> Kerberos Kpasswd: TCP (464): OK >>> HTTP Server: Unsecure port (80): OK >>> HTTP Server: Secure port (443): OK >>> >>> The following list of ports use UDP protocol and would need >>> to be >>> checked manually: >>> Kerberos KDC: UDP (88): SKIPPED >>> Kerberos Kpasswd: UDP (464): SKIPPED >>> >>> Connection from replica to master is OK. >>> Start listening on required ports for remote master check >>> Get credentials to log in to remote master >>> Check SSH connection to remote master >>> Execute check on remote master >>> Check connection from master to remote replica >>> 'ipa2.example.com ': >>> Directory Service: Unsecure port (389): OK >>> Directory Service: Secure port (636): OK >>> Kerberos KDC: TCP (88): OK >>> Kerberos KDC: UDP (88): OK >>> Kerberos Kpasswd: TCP (464): OK >>> Kerberos Kpasswd: UDP (464): OK >>> HTTP Server: Unsecure port (80): OK >>> HTTP Server: Secure port (443): OK >>> >>> Connection from master to replica is OK. >>> >>> Connection check OK >>> Configuring NTP daemon (ntpd) >>> [1/4]: stopping ntpd >>> [2/4]: writing configuration >>> [3/4]: configuring ntpd to start on boot >>> [4/4]: starting ntpd >>> Done configuring NTP daemon (ntpd). >>> Configuring directory server (dirsrv): Estimated time 1 minute >>> [1/34]: creating directory server user >>> [2/34]: creating directory server instance >>> [3/34]: adding default schema >>> [4/34]: enabling memberof plugin >>> [5/34]: enabling winsync plugin >>> [6/34]: configuring replication version plugin >>> [7/34]: enabling IPA enrollment plugin >>> [8/34]: enabling ldapi >>> [9/34]: configuring uniqueness plugin >>> [10/34]: configuring uuid plugin >>> [11/34]: configuring modrdn plugin >>> [12/34]: configuring DNS plugin >>> [13/34]: enabling entryUSN plugin >>> [14/34]: configuring lockout plugin >>> [15/34]: creating indices >>> [16/34]: enabling referential integrity plugin >>> [17/34]: configuring ssl for ds instance >>> [18/34]: configuring certmap.conf >>> [19/34]: configure autobind for root >>> [20/34]: configure new location for managed entries >>> [21/34]: configure dirsrv ccache >>> [22/34]: enable SASL mapping fallback >>> [23/34]: restarting directory server >>> [24/34]: setting up initial replication >>> Starting replication, please wait until this has completed. >>> Update in progress, 5 seconds elapsed >>> [ipa.example.com ] reports: Update >>> failed! Status: [-1 Total update abortedLDAP error: Can't >>> contact LDAP server] >>> >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> Failed to start replication >>> ================================================================= >>> >>> I've confirmed that I can do ldapsearch from each machine to >>> the other one for the replica status records (through ldap >>> and ldaps), so I know that they can communicate. Trouble is, >>> something behind the scenes is throwing the status error (as >>> seen in the nsds5ReplicaLastInitStatus attribute). >>> >>> ================================================================= >>> [root at ipa2 ipaserver]# ldapsearch >>> ldaps://ipa.example.com:636 -D >>> 'cn=Directory Manager' -w ##### -b 'cn=meToipa2.example.com >>> ,cn=replica,cn=dc\=example\,dc\=com,cn=mapping >>> tree,cn=config' '(objectClass=*)' -s base >>> nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress >>> nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh >>> nsds5ReplicaLastInitEnd >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base >> ,cn=replica,cn=dc\=example\,dc\=com,cn=mapping >>> tree,cn=config> with scope baseObject >>> # filter: (objectclass=*) >>> # requesting: ldaps://ipa.example.com:636 >>> (objectClass=*) >>> nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress >>> nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh >>> nsds5ReplicaLastInitEnd >>> # >>> >>> # meToipa2.example.com , >>> replica, dc\3Dexample\2Cdc\3Dcom, >>> mapping tree, config >>> dn: cn=meToipa2.example.com >>> ,cn=replica,cn=dc\3Dexample\2Cd >>> c\3Dcom,cn=mapping tree,cn=config >>> nsds5ReplicaLastInitStart: 20140401092800Z >>> nsds5replicaUpdateInProgress: FALSE >>> nsds5ReplicaLastInitStatus: -1 Total update abortedLDAP >>> error: Can't contact L >>> DAP server >>> cn: meToipa2.example.com >>> nsds5ReplicaLastInitEnd: 20140401092804Z >>> >>> # search result >>> search: 2 >>> result: 0 Success >>> >>> # numResponses: 2 >>> # numEntries: 1 >>> ================================================================= >>> >>> I'd really love for someone to help out with this, as I >>> can't afford another entire night trying to figure this out. >>> Thanks in advance! >>> >>> -Nevada >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Apr 1 21:41:42 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Apr 2014 17:41:42 -0400 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: <533B300D.6050707@redhat.com> References: <533AF3D2.5050308@redhat.com> <533B11F6.3040603@redhat.com> <533B300D.6050707@redhat.com> Message-ID: <533B3296.1020409@redhat.com> Rich Megginson wrote: > On 04/01/2014 03:28 PM, Nevada Sanchez wrote: >> Okay, I just tried doing this on a FRESH fedora 19 image (applied all >> updates, installed freeipa, made a new replica file for the new test >> server, and went state to ipa-replica-insntall). Exact same errors. >> Anything else I should try? > > I don't know. > > Does anyone on the IPA team know what the ipa_lockout errors are about, > and if they would cause replication not to work? > I suspect it is a red herring. The error is not found, so it is probably that the entry doesn't exist yet. This is replication for the CA anyway. I'd be curious what the access and error logs on the existing side looks like. It may be an SSL trust problem, for example. rob From sanchez.nevada at gmail.com Tue Apr 1 21:28:25 2014 From: sanchez.nevada at gmail.com (Nevada Sanchez) Date: Tue, 1 Apr 2014 17:28:25 -0400 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: <533B11F6.3040603@redhat.com> References: <533AF3D2.5050308@redhat.com> <533B11F6.3040603@redhat.com> Message-ID: Okay, I just tried doing this on a FRESH fedora 19 image (applied all updates, installed freeipa, made a new replica file for the new test server, and went state to ipa-replica-insntall). Exact same errors. Anything else I should try? On Tue, Apr 1, 2014 at 3:22 PM, Rich Megginson wrote: > On 04/01/2014 01:16 PM, Nevada Sanchez wrote: > > 389-ds-base-1.3.1.22-1.fc19.x86_64 > > The following, I think, summarizes the contents of the error log (I > probably uninstalled and tried reimporting 2 or 3 times in what is shown). > > . > . > . > [01/Apr/2014:03:42:46 -0400] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to access the > database > [01/Apr/2014:03:42:46 -0400] - check_and_set_import_cache: pagesize: 4096, > pages: 1970554, procpages: 53717 > [01/Apr/2014:03:42:46 -0400] - Import allocates 3152884KB import cache. > [01/Apr/2014:03:42:46 -0400] - import userRoot: Beginning import job... > [01/Apr/2014:03:42:46 -0400] - import userRoot: Index buffering enabled > with bucket size 100 > [01/Apr/2014:03:42:46 -0400] - import userRoot: Processing file > "/var/lib/dirsrv/boot.ldif" > [01/Apr/2014:03:42:46 -0400] - import userRoot: Finished scanning file > "/var/lib/dirsrv/boot.ldif" (1 entries) > [01/Apr/2014:03:42:46 -0400] - import userRoot: Workers finished; cleaning > up... > [01/Apr/2014:03:42:47 -0400] - import userRoot: Workers cleaned up. > [01/Apr/2014:03:42:47 -0400] - import userRoot: Cleaning up producer > thread... > [01/Apr/2014:03:42:47 -0400] - import userRoot: Indexing complete. > Post-processing... > [01/Apr/2014:03:42:47 -0400] - import userRoot: Generating numSubordinates > complete. > [01/Apr/2014:03:42:47 -0400] - Nothing to do to build ancestorid index > [01/Apr/2014:03:42:47 -0400] - import userRoot: Flushing caches... > [01/Apr/2014:03:42:47 -0400] - import userRoot: Closing files... > [01/Apr/2014:03:42:47 -0400] - All database threads now stopped > [01/Apr/2014:03:42:47 -0400] - import userRoot: Import complete. > Processed 1 entries in 1 seconds. (1.00 entries/sec) > [01/Apr/2014:03:42:47 -0400] - 389-Directory/1.3.1.22.a1 B2014.073.1751 > starting up > [01/Apr/2014:03:42:47 -0400] - Db home directory is not set. Possibly > nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the > config file. > [01/Apr/2014:03:42:48 -0400] - 389-Directory/1.3.1.22.a1 B2014.073.1751 > starting up > [01/Apr/2014:03:42:48 -0400] - Db home directory is not set. Possibly > nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the > config file. > [01/Apr/2014:03:42:48 -0400] - I'm resizing my cache now...cache was > 3228553216 and is now 8000000 > [01/Apr/2014:03:42:48 -0400] - slapd started. Listening on All Interfaces > port 389 for LDAP requests > [01/Apr/2014:03:42:48 -0400] - The change of nsslapd-ldapilisten will not > take effect until the server is restarted > [01/Apr/2014:03:43:01 -0400] - Warning: Adding configuration attribute > "nsslapd-security" > [01/Apr/2014:03:43:01 -0400] - slapd shutting down - signaling operation > threads > [01/Apr/2014:03:43:01 -0400] - slapd shutting down - waiting for 27 > threads to terminate > [01/Apr/2014:03:43:01 -0400] - slapd shutting down - closing down internal > subsystems and plugins > [01/Apr/2014:03:43:01 -0400] - Waiting for 4 database threads to stop > [01/Apr/2014:03:43:02 -0400] - All database threads now stopped > [01/Apr/2014:03:43:02 -0400] - slapd stopped. > [01/Apr/2014:03:43:03 -0400] - 389-Directory/1.3.1.22.a1 B2014.073.1751 > starting up > [01/Apr/2014:03:43:03 -0400] attrcrypt - No symmetric key found for cipher > AES in backend userRoot, attempting to create one... > [01/Apr/2014:03:43:03 -0400] attrcrypt - Key for cipher AES successfully > generated and stored > [01/Apr/2014:03:43:03 -0400] attrcrypt - No symmetric key found for cipher > 3DES in backend userRoot, attempting to create one... > [01/Apr/2014:03:43:03 -0400] attrcrypt - Key for cipher 3DES successfully > generated and stored > [01/Apr/2014:03:43:03 -0400] ipalockout_get_global_config - [file > ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) > [01/Apr/2014:03:43:04 -0400] ipaenrollment_start - [file ipa_enrollment.c, > line 393]: Failed to get default realm?! > [01/Apr/2014:03:43:04 -0400] - slapd started. Listening on All Interfaces > port 389 for LDAP requests > [01/Apr/2014:03:43:04 -0400] - Listening on All Interfaces port 636 for > LDAPS requests > [01/Apr/2014:03:43:04 -0400] - Listening on > /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests > [01/Apr/2014:03:43:04 -0400] - slapd shutting down - signaling operation > threads > [01/Apr/2014:03:43:04 -0400] - slapd shutting down - waiting for 27 > threads to terminate > [01/Apr/2014:03:43:05 -0400] - slapd shutting down - closing down internal > subsystems and plugins > [01/Apr/2014:03:43:05 -0400] - Waiting for 4 database threads to stop > [01/Apr/2014:03:43:05 -0400] - All database threads now stopped > [01/Apr/2014:03:43:05 -0400] - slapd stopped. > [01/Apr/2014:03:43:06 -0400] - 389-Directory/1.3.1.22.a1 B2014.073.1751 > starting up > [01/Apr/2014:03:43:06 -0400] ipalockout_get_global_config - [file > ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) > [01/Apr/2014:03:43:06 -0400] ipaenrollment_start - [file ipa_enrollment.c, > line 393]: Failed to get default realm?! > [01/Apr/2014:03:43:06 -0400] - slapd started. Listening on All Interfaces > port 389 for LDAP requests > [01/Apr/2014:03:43:06 -0400] - Listening on All Interfaces port 636 for > LDAPS requests > [01/Apr/2014:03:43:06 -0400] - Listening on > /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests > [01/Apr/2014:03:43:08 -0400] NSMMReplicationPlugin - agmt="cn= > meToipa.example.com" (ipa: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. > [01/Apr/2014:03:43:08 -0400] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=example,dc=com is going offline; > disabling replication > [01/Apr/2014:03:43:08 -0400] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to access the > database > [01/Apr/2014:03:43:11 -0400] - import userRoot: Workers finished; cleaning > up... > [01/Apr/2014:03:43:11 -0400] - import userRoot: Workers cleaned up. > [01/Apr/2014:03:43:11 -0400] - import userRoot: Indexing complete. > Post-processing... > [01/Apr/2014:03:43:11 -0400] - import userRoot: Generating numSubordinates > complete. > [01/Apr/2014:03:43:12 -0400] - import userRoot: Flushing caches... > [01/Apr/2014:03:43:12 -0400] - import userRoot: Closing files... > [01/Apr/2014:03:43:12 -0400] - import userRoot: Import complete. > Processed 453 entries in 4 seconds. (113.25 entries/sec) > [01/Apr/2014:03:43:12 -0400] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=example,dc=com is coming online; > enabling replication > [01/Apr/2014:03:43:12 -0400] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=example,dc=com--no CoS Templates found, which should > be added before the CoS Definition. > [01/Apr/2014:03:43:19 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:03:43:19 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:03:48:19 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:03:48:19 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:03:53:19 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:03:53:19 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:03:58:19 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:03:58:19 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:03:18 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:03:18 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:08:18 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:08:18 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:13:18 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:13:18 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:18:19 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:18:19 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:23:18 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:23:18 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:28:18 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:28:18 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:33:19 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:33:19 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:38:19 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:38:19 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:43:18 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:43:18 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:48:18 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:48:18 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:53:19 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:53:19 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:58:18 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:04:58:18 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:03:18 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:03:18 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:08:18 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:08:18 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:13:18 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:13:19 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:14:36 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:14:36 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:14:41 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:14:41 -0400] ipalockout_postop - [file ipa_lockout.c, > line 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:14:46 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:14:46 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:14:58 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:14:58 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:15:00 -0400] - slapd shutting down - signaling operation > threads > [01/Apr/2014:05:15:00 -0400] - slapd shutting down - waiting for 28 > threads to terminate > [01/Apr/2014:05:15:00 -0400] - slapd shutting down - closing down internal > subsystems and plugins > [01/Apr/2014:05:15:01 -0400] - Waiting for 4 database threads to stop > [01/Apr/2014:05:15:01 -0400] - All database threads now stopped > [01/Apr/2014:05:15:01 -0400] - slapd stopped. > [01/Apr/2014:05:27:38 -0400] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to access the > database > [01/Apr/2014:05:27:38 -0400] - check_and_set_import_cache: pagesize: 4096, > pages: 1970554, procpages: 53717 > [01/Apr/2014:05:27:38 -0400] - Import allocates 3152884KB import cache. > [01/Apr/2014:05:27:38 -0400] - import userRoot: Beginning import job... > [01/Apr/2014:05:27:38 -0400] - import userRoot: Index buffering enabled > with bucket size 100 > [01/Apr/2014:05:27:39 -0400] - import userRoot: Processing file > "/var/lib/dirsrv/boot.ldif" > [01/Apr/2014:05:27:39 -0400] - import userRoot: Finished scanning file > "/var/lib/dirsrv/boot.ldif" (1 entries) > [01/Apr/2014:05:27:39 -0400] - import userRoot: Workers finished; cleaning > up... > [01/Apr/2014:05:27:39 -0400] - import userRoot: Workers cleaned up. > [01/Apr/2014:05:27:39 -0400] - import userRoot: Cleaning up producer > thread... > [01/Apr/2014:05:27:39 -0400] - import userRoot: Indexing complete. > Post-processing... > [01/Apr/2014:05:27:39 -0400] - import userRoot: Generating numSubordinates > complete. > [01/Apr/2014:05:27:39 -0400] - Nothing to do to build ancestorid index > [01/Apr/2014:05:27:39 -0400] - import userRoot: Flushing caches... > [01/Apr/2014:05:27:39 -0400] - import userRoot: Closing files... > [01/Apr/2014:05:27:40 -0400] - All database threads now stopped > [01/Apr/2014:05:27:40 -0400] - import userRoot: Import complete. > Processed 1 entries in 2 seconds. (0.50 entries/sec) > [01/Apr/2014:05:27:40 -0400] - 389-Directory/1.3.1.22.a1 B2014.073.1751 > starting up > [01/Apr/2014:05:27:40 -0400] - Db home directory is not set. Possibly > nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the > config file. > [01/Apr/2014:05:27:40 -0400] - 389-Directory/1.3.1.22.a1 B2014.073.1751 > starting up > [01/Apr/2014:05:27:40 -0400] - Db home directory is not set. Possibly > nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the > config file. > [01/Apr/2014:05:27:40 -0400] - I'm resizing my cache now...cache was > 3228553216 and is now 8000000 > [01/Apr/2014:05:27:41 -0400] - slapd started. Listening on All Interfaces > port 389 for LDAP requests > [01/Apr/2014:05:27:41 -0400] - The change of nsslapd-ldapilisten will not > take effect until the server is restarted > [01/Apr/2014:05:27:54 -0400] - Warning: Adding configuration attribute > "nsslapd-security" > [01/Apr/2014:05:27:54 -0400] - slapd shutting down - signaling operation > threads > [01/Apr/2014:05:27:54 -0400] - slapd shutting down - waiting for 28 > threads to terminate > [01/Apr/2014:05:27:54 -0400] - slapd shutting down - closing down internal > subsystems and plugins > [01/Apr/2014:05:27:54 -0400] - Waiting for 4 database threads to stop > [01/Apr/2014:05:27:55 -0400] - All database threads now stopped > [01/Apr/2014:05:27:55 -0400] - slapd stopped. > [01/Apr/2014:05:27:56 -0400] - 389-Directory/1.3.1.22.a1 B2014.073.1751 > starting up > [01/Apr/2014:05:27:56 -0400] attrcrypt - No symmetric key found for cipher > AES in backend userRoot, attempting to create one... > [01/Apr/2014:05:27:56 -0400] attrcrypt - Key for cipher AES successfully > generated and stored > [01/Apr/2014:05:27:56 -0400] attrcrypt - No symmetric key found for cipher > 3DES in backend userRoot, attempting to create one... > [01/Apr/2014:05:27:56 -0400] attrcrypt - Key for cipher 3DES successfully > generated and stored > [01/Apr/2014:05:27:56 -0400] ipalockout_get_global_config - [file > ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) > [01/Apr/2014:05:27:56 -0400] ipaenrollment_start - [file ipa_enrollment.c, > line 393]: Failed to get default realm?! > [01/Apr/2014:05:27:56 -0400] - slapd started. Listening on All Interfaces > port 389 for LDAP requests > [01/Apr/2014:05:27:56 -0400] - Listening on All Interfaces port 636 for > LDAPS requests > [01/Apr/2014:05:27:56 -0400] - Listening on > /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests > [01/Apr/2014:05:27:56 -0400] - slapd shutting down - signaling operation > threads > [01/Apr/2014:05:27:56 -0400] - slapd shutting down - waiting for 29 > threads to terminate > [01/Apr/2014:05:27:57 -0400] - slapd shutting down - closing down internal > subsystems and plugins > [01/Apr/2014:05:27:57 -0400] - Waiting for 4 database threads to stop > [01/Apr/2014:05:27:57 -0400] - All database threads now stopped > [01/Apr/2014:05:27:57 -0400] - slapd stopped. > [01/Apr/2014:05:27:58 -0400] - 389-Directory/1.3.1.22.a1 B2014.073.1751 > starting up > [01/Apr/2014:05:27:59 -0400] ipalockout_get_global_config - [file > ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) > [01/Apr/2014:05:27:59 -0400] ipaenrollment_start - [file ipa_enrollment.c, > line 393]: Failed to get default realm?! > [01/Apr/2014:05:27:59 -0400] - slapd started. Listening on All Interfaces > port 389 for LDAP requests > [01/Apr/2014:05:27:59 -0400] - Listening on All Interfaces port 636 for > LDAPS requests > [01/Apr/2014:05:27:59 -0400] - Listening on > /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests > [01/Apr/2014:05:28:01 -0400] NSMMReplicationPlugin - agmt="cn= > meToipa.example.com" (ipa: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. > [01/Apr/2014:05:28:01 -0400] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=example,dc=com is going offline; > disabling replication > [01/Apr/2014:05:28:01 -0400] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to access the > database > [01/Apr/2014:05:28:04 -0400] - import userRoot: Workers finished; cleaning > up... > [01/Apr/2014:05:28:05 -0400] - import userRoot: Workers cleaned up. > [01/Apr/2014:05:28:05 -0400] - import userRoot: Indexing complete. > Post-processing... > [01/Apr/2014:05:28:05 -0400] - import userRoot: Generating numSubordinates > complete. > [01/Apr/2014:05:28:05 -0400] - import userRoot: Flushing caches... > [01/Apr/2014:05:28:05 -0400] - import userRoot: Closing files... > [01/Apr/2014:05:28:06 -0400] - import userRoot: Import complete. > Processed 453 entries in 5 seconds. (90.60 entries/sec) > [01/Apr/2014:05:28:06 -0400] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=example,dc=com is coming online; > enabling replication > [01/Apr/2014:05:28:06 -0400] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=example,dc=com--no CoS Templates found, which should > be added before the CoS Definition. > [01/Apr/2014:05:32:38 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:05:32:38 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > . > . > . > [01/Apr/2014:13:12:39 -0400] ipalockout_preop - [file ipa_lockout.c, line > 749]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > [01/Apr/2014:13:12:39 -0400] ipalockout_postop - [file ipa_lockout.c, line > 503]: Failed to retrieve entry "cn=Replication Manager > cloneAgreement1-ipa2.example.com-pki-tomcat,ou=csusers,cn=config": 32 > > > This seems bad, but I'm not sure if this is the root of the replication > problem. > > > > > > On Tue, Apr 1, 2014 at 1:13 PM, Rich Megginson wrote: > >> On 04/01/2014 03:46 AM, Nevada Sanchez wrote: >> >> I've had a replica working with FreeIPA 3.2.1 for awhile. After upgrading >> to 3.3.4, the replica wouldn't recognize my admin login anymore. After much >> troubleshooting, I decided to try to redo the replica since it was quite >> straightforward when I first set it up (what could go wrong, right?) >> >> What is your version of 389-ds-base? rpm -q 389-ds-base >> >> What is in your dirsrv errors log? >> /var/log/dirsrv/slapd-DOMAIN-TLD/errors >> >> >> Unfortunately, I've spent most of my day trying to get the replica to >> work this time. I've tried turning off all firewalls on both machines, >> rebooting both machines, upgrading all packages on both machines (both are >> running Fedora 19), reinstalling FreeIPA packages, and several other >> things, but I keep getting stuck at the same step (see output below). >> >> ================================================================= >> [root at ipa2 ipaserver]# ipa-replica-install --setup-dns --no-forwarders >> /var/lib/ipa/replica-info-ipa2.example.com.gpg >> WARNING: conflicting time&date synchronization service 'chronyd' will >> be disabled in favor of ntpd >> >> Run connection check to master >> Check connection from replica to remote master 'ipa.example.com': >> Directory Service: Unsecure port (389): OK >> Directory Service: Secure port (636): OK >> Kerberos KDC: TCP (88): OK >> Kerberos Kpasswd: TCP (464): OK >> HTTP Server: Unsecure port (80): OK >> HTTP Server: Secure port (443): OK >> >> The following list of ports use UDP protocol and would need to be >> checked manually: >> Kerberos KDC: UDP (88): SKIPPED >> Kerberos Kpasswd: UDP (464): SKIPPED >> >> Connection from replica to master is OK. >> Start listening on required ports for remote master check >> Get credentials to log in to remote master >> Check SSH connection to remote master >> Execute check on remote master >> Check connection from master to remote replica 'ipa2.example.com': >> Directory Service: Unsecure port (389): OK >> Directory Service: Secure port (636): OK >> Kerberos KDC: TCP (88): OK >> Kerberos KDC: UDP (88): OK >> Kerberos Kpasswd: TCP (464): OK >> Kerberos Kpasswd: UDP (464): OK >> HTTP Server: Unsecure port (80): OK >> HTTP Server: Secure port (443): OK >> >> Connection from master to replica is OK. >> >> Connection check OK >> Configuring NTP daemon (ntpd) >> [1/4]: stopping ntpd >> [2/4]: writing configuration >> [3/4]: configuring ntpd to start on boot >> [4/4]: starting ntpd >> Done configuring NTP daemon (ntpd). >> Configuring directory server (dirsrv): Estimated time 1 minute >> [1/34]: creating directory server user >> [2/34]: creating directory server instance >> [3/34]: adding default schema >> [4/34]: enabling memberof plugin >> [5/34]: enabling winsync plugin >> [6/34]: configuring replication version plugin >> [7/34]: enabling IPA enrollment plugin >> [8/34]: enabling ldapi >> [9/34]: configuring uniqueness plugin >> [10/34]: configuring uuid plugin >> [11/34]: configuring modrdn plugin >> [12/34]: configuring DNS plugin >> [13/34]: enabling entryUSN plugin >> [14/34]: configuring lockout plugin >> [15/34]: creating indices >> [16/34]: enabling referential integrity plugin >> [17/34]: configuring ssl for ds instance >> [18/34]: configuring certmap.conf >> [19/34]: configure autobind for root >> [20/34]: configure new location for managed entries >> [21/34]: configure dirsrv ccache >> [22/34]: enable SASL mapping fallback >> [23/34]: restarting directory server >> [24/34]: setting up initial replication >> Starting replication, please wait until this has completed. >> Update in progress, 5 seconds elapsed >> [ipa.example.com] reports: Update failed! Status: [-1 Total update >> abortedLDAP error: Can't contact LDAP server] >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> Failed to start replication >> ================================================================= >> >> I've confirmed that I can do ldapsearch from each machine to the other >> one for the replica status records (through ldap and ldaps), so I know that >> they can communicate. Trouble is, something behind the scenes is throwing >> the status error (as seen in the nsds5ReplicaLastInitStatus attribute). >> >> ================================================================= >> [root at ipa2 ipaserver]# ldapsearch ldaps://ipa.example.com:636 -D >> 'cn=Directory Manager' -w ##### -b 'cn=meToipa2.example.com,cn=replica,cn=dc\=example\,dc\=com,cn=mapping >> tree,cn=config' '(objectClass=*)' -s base nsds5ReplicaLastInitStart >> nsds5replicaUpdateInProgress nsds5ReplicaLastInitStatus cn >> nsds5BeginReplicaRefresh nsds5ReplicaLastInitEnd >> # extended LDIF >> # >> # LDAPv3 >> # base > tree,cn=config> with scope baseObject >> # filter: (objectclass=*) >> # requesting: ldaps://ipa.example.com:636 (objectClass=*) >> nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress >> nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh >> nsds5ReplicaLastInitEnd >> # >> >> # meToipa2.example.com, replica, dc\3Dexample\2Cdc\3Dcom, >> mapping tree, config >> dn: cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cd >> c\3Dcom,cn=mapping tree,cn=config >> nsds5ReplicaLastInitStart: 20140401092800Z >> nsds5replicaUpdateInProgress: FALSE >> nsds5ReplicaLastInitStatus: -1 Total update abortedLDAP error: Can't >> contact L >> DAP server >> cn: meToipa2.example.com >> nsds5ReplicaLastInitEnd: 20140401092804Z >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> ================================================================= >> >> I'd really love for someone to help out with this, as I can't afford >> another entire night trying to figure this out. Thanks in advance! >> >> -Nevada >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Tue Apr 1 22:23:57 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 1 Apr 2014 22:23:57 +0000 Subject: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate In-Reply-To: References: <5339EF9B.3070606@redhat.com> <94b3969cbcd3400d804b4c3dc4332fd7@BY2PR03MB176.namprd03.prod.outlook.com> <5339F1B0.8030209@redhat.com> <95da496c517c455281c0833c200367f0@BY2PR03MB176.namprd03.prod.outlook.com> <20140401071910.GD11404@localhost.localdomain> , <20140401201941.GA8263@hendrix.redhat.com>, Message-ID: <903097f8461d497c89f8f15881ce8181@BY2PR03MB176.namprd03.prod.outlook.com> Ok so On 2 of the servers I found that UsePAM was not even in the sshd_conf when I put that in I was fine but 3 other servers that have it in the sshd_conf are exhibiting the password not accepted error then I went and cleared the sssd cache and IM back in business thank you for the help ________________________________________ From: freeipa-users-bounces at redhat.com on behalf of Todd Maugh Sent: Tuesday, April 01, 2014 1:58 PM To: Jakub Hrozek; freeipa-users at redhat.com Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate /var/log/sssd/krb5_child.log is empty here is the sssd domain log sssd_ops.boingo.com.log 97][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:28:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:29:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:29:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:30:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:30:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:31:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:31:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:32:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:32:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:33:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:33:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:34:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:34:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:35:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:35:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:36:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:36:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:37:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:37:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:38:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:38:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:39:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:39:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:40:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:40:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:40:10 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4099][1][name=tmaugh] (Tue Apr 1 19:40:10 2014) [sssd[be[ops.boingo.com]]] [sdap_initgr_nested_send] (4): User entry lacks original memberof ? (Tue Apr 1 19:40:10 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:41:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:41:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:42:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:42:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:43:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:43:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:44:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:44:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:45:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:45:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:46:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:46:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:47:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:47:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:48:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:48:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:49:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:49:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:50:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:50:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:51:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:51:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:52:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:52:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:53:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:53:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:54:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:54:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:55:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:55:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:56:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:56:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:57:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:57:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:58:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:58:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 19:59:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 19:59:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:00:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:00:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:01:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:01:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:02:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:02:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:03:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:03:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:04:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:04:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:05:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:05:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:06:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:06:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:07:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:07:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:08:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:08:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:09:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:09:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:10:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:10:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:11:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:11:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:12:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:12:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:13:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:13:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:13:50 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4099][1][name=pin] (Tue Apr 1 20:13:50 2014) [sssd[be[ops.boingo.com]]] [sdap_get_initgr_user] (2): Expected one user entry and got 0 (Tue Apr 1 20:13:50 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:14:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:14:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:15:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:15:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:16:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:16:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:17:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:17:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:18:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:18:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:19:02 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:19:02 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:20:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:20:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:21:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:21:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:22:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:22:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:23:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:23:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:24:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:24:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:25:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:25:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:26:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:26:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:27:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:27:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:28:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:28:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:29:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:29:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:30:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:30:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:31:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:31:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:32:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:32:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:33:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:33:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:34:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:34:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:35:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:35:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:36:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:36:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:37:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:37:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:38:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:38:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:39:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:39:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:40:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:40:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:40:25 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4099][1][name=tmaugh] (Tue Apr 1 20:40:25 2014) [sssd[be[ops.boingo.com]]] [sdap_initgr_nested_send] (4): User entry lacks original memberof ? (Tue Apr 1 20:40:25 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:41:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:41:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:42:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:42:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:43:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:43:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:44:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:44:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:45:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:45:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:46:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:46:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:47:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:47:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:48:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:48:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:49:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:49:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:49:20 2014) [sssd[be[ops.boingo.com]]] [sbus_dispatch] (3): Connection is not open for dispatching. (Tue Apr 1 20:49:20 2014) [sssd[be[ops.boingo.com]]] [be_client_destructor] (4): Removed PAM client (Tue Apr 1 20:49:20 2014) [sssd[be[ops.boingo.com]]] [sbus_dispatch] (3): Connection is not open for dispatching. (Tue Apr 1 20:49:20 2014) [sssd[be[ops.boingo.com]]] [be_client_destructor] (4): Removed NSS client (Tue Apr 1 20:49:20 2014) [sssd[be[ops.boingo.com]]] [remove_krb5_info_files] (5): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.OPS.BOINGO.COM], [2][No such file or directory] (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [server_setup] (3): CONFDB: /var/lib/sss/db/config.ldb (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [recreate_ares_channel] (4): Initializing new c-ares channel (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [fo_context_init] (3): Created new fail over context, retry timeout is 30 (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [confdb_get_domain_internal] (1): No enumeration for [ops.boingo.com]! (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sysdb_domain_init_internal] (5): DB File for ops.boingo.com: /var/lib/sss/db/cache_ops.boingo.com.ldb (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sbus_init_connection] (5): Adding connection 736BC0 (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [monitor_common_send_id] (4): Sending ID: (%BE_ops.boingo.com,1) (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sbus_new_server] (3): D-BUS Server listening on unix:path=/var/lib/sss/pipes/private/sbus-dp_ops.boingo.com.7919,guid=059ed610f0f84928a4a10c00533b2652 (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [fo_new_service] (3): Creating new service 'IPA' (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [fo_add_srv_server] (3): Adding new SRV server in domain 'unknown', to service 'IPA' using tcp (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [fo_add_server] (3): Adding new server 'idm-master-els.ops.boingo.com', to service 'IPA' (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_entry_usn has value entryUSN (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_rootdse_last_usn has value lastUSN (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_object_class has value posixAccount (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_name has value uid (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_pwd has value userPassword (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_uid_number has value uidNumber (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_gid_number has value gidNumber (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_gecos has value gecos (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_home_directory has value homeDirectory (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shell has value loginShell (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_principal has value krbPrincipalName (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_fullname has value cn (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_member_of has value memberOf (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_uuid has value nsUniqueId (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_modify_timestamp has value modifyTimestamp (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_entry_usn has value (null) (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_last_change has value shadowLastChange (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_min has value shadowMin (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_max has value shadowMax (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_warning has value shadowWarning (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_inactive has value shadowInactive (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_expire has value shadowExpire (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_flag has value shadowFlag (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_krb_last_pwd_change has value krbLastPwdChange (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_krb_password_expiration has value krbPasswordExpiration (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_pwd_attribute has value pwdAttribute (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_authorized_service has value authorizedService (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_ad_account_expires has value accountExpires (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_ad_user_account_control has value userAccountControl (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_ns_account_lock has value nsAccountLock (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_object_class has value posixGroup (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_name has value cn (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_pwd has value userPassword (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_gid_number has value gidNumber (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_member has value member (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_uuid has value nsUniqueId (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_modify_timestamp has value modifyTimestamp (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_entry_usn has value (null) (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_object_class has value nisNetgroup (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_name has value cn (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_member has value memberNisNetgroup (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_triple has value nisNetgroupTriple (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_uuid has value nsUniqueId (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_modify_timestamp has value modifyTimestamp (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sss_krb5_verify_keytab] (4): Principal name is: [host/black-62.qa.boingo.com at OPS.BOINGO.COM] (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [krb5_try_kdcip] (4): No KDC found in configuration, trying legacy option (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_entry_usn has value entryUSN (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_rootdse_last_usn has value lastUSN (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_object_class has value posixAccount (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_name has value uid (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_pwd has value userPassword (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_uid_number has value uidNumber (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_gid_number has value gidNumber (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_gecos has value gecos (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_home_directory has value homeDirectory (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shell has value loginShell (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_principal has value krbPrincipalName (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_fullname has value cn (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_member_of has value memberOf (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_uuid has value nsUniqueId (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_modify_timestamp has value modifyTimestamp (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_entry_usn has value (null) (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_last_change has value shadowLastChange (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_min has value shadowMin (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_max has value shadowMax (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_warning has value shadowWarning (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_inactive has value shadowInactive (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_expire has value shadowExpire (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_shadow_flag has value shadowFlag (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_krb_last_pwd_change has value krbLastPwdChange (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_krb_password_expiration has value krbPasswordExpiration (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_pwd_attribute has value pwdAttribute (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_authorized_service has value authorizedService (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_ad_account_expires has value accountExpires (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_user_ad_user_account_control has value userAccountControl (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_ns_account_lock has value nsAccountLock (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_object_class has value posixGroup (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_name has value cn (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_pwd has value userPassword (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_gid_number has value gidNumber (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_member has value member (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_uuid has value nsUniqueId (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_modify_timestamp has value modifyTimestamp (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_group_entry_usn has value (null) (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_object_class has value nisNetgroup (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_name has value cn (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_member has value memberNisNetgroup (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_triple has value nisNetgroupTriple (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_uuid has value nsUniqueId (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sdap_get_map] (5): Option ldap_netgroup_modify_timestamp has value modifyTimestamp (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [check_and_export_lifetime] (5): No lifetime configured. (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [check_and_export_lifetime] (5): No lifetime configured. (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [check_and_export_options] (1): No KDC explicitly configured, using defaults. (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [check_and_export_options] (1): No kpasswd server explicitly configured, using the KDC or defaults. (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [main] (1): Backend provider (ops.boingo.com) started! (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [id_callback] (4): Got id ack and version (1) from Monitor (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sbus_server_init_new_connection] (5): Entering. (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sbus_server_init_new_connection] (5): Adding connection 0x1365d20. (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sbus_init_connection] (5): Adding connection 1365D20 (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [sbus_server_init_new_connection] (5): Got a connection (Tue Apr 1 20:49:22 2014) [sssd[be[ops.boingo.com]]] [be_client_init] (4): Set-up Backend ID timeout [0x1366820] (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [sbus_server_init_new_connection] (5): Entering. (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [sbus_server_init_new_connection] (5): Adding connection 0x13684c0. (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [sbus_init_connection] (5): Adding connection 13684C0 (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [sbus_server_init_new_connection] (5): Got a connection (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [be_client_init] (4): Set-up Backend ID timeout [0x1368ce0] (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [client_registration] (4): Cancel DP ID timeout [0x1366820] (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [client_registration] (4): Added Frontend client [PAM] (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [client_registration] (4): Cancel DP ID timeout [0x1368ce0] (Tue Apr 1 20:49:23 2014) [sssd[be[ops.boingo.com]]] [client_registration] (4): Added Frontend client [NSS] (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=csteinke] (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [fo_resolve_service_send] (4): Trying to resolve service 'IPA' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [resolv_gethostbyname_files_send] (4): Trying to resolve A record of 'black-62.qa.boingo.com' in files (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [resolve_srv_cont] (4): Searching for servers via SRV query '_ldap._tcp.qa.boingo.com' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [resolv_getsrv_send] (4): Trying to resolve SRV record of '_ldap._tcp.qa.boingo.com' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [resolve_srv_done] (1): SRV query failed: [Domain name not found] (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [resolve_srv_cont] (4): Searching for servers via SRV query '_ldap._tcp.ops.boingo.com' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [resolv_getsrv_send] (4): Trying to resolve SRV record of '_ldap._tcp.ops.boingo.com' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [resolve_srv_done] (1): SRV query failed: [Domain name not found] (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [fo_set_port_status] (4): Marking port 0 of server '(no name)' as 'not working' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [set_srv_data_status] (4): Marking SRV lookup of service 'IPA' as 'not resolved' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [fo_resolve_service_send] (4): Trying to resolve service 'IPA' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [resolv_gethostbyname_files_send] (4): Trying to resolve A record of 'idm-master-els.ops.boingo.com' in files (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [set_server_common_status] (4): Marking server 'idm-master-els.ops.boingo.com' as 'resolving name' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [set_server_common_status] (4): Marking server 'idm-master-els.ops.boingo.com' as 'name resolved' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [be_resolve_server_done] (4): Found address for server idm-master-els.ops.boingo.com: [172.22.170.46] TTL 7200 (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [fo_resolve_service_send] (4): Trying to resolve service 'IPA' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [be_resolve_server_done] (4): Found address for server idm-master-els.ops.boingo.com: [172.22.170.46] TTL 7200 (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: host/black-62.qa.boingo.com (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [child_sig_handler] (4): child [7939] finished successfully. (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [fo_set_port_status] (4): Marking port 0 of server 'idm-master-els.ops.boingo.com' as 'working' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [set_server_common_status] (4): Marking server 'idm-master-els.ops.boingo.com' as 'working' (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [be_run_online_cb] (3): Going online. Running callbacks. (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [delayed_online_authentication_callback] (5): Backend is online, starting delayed online authentication. (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4099][1][name=csteinke] (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [sdap_initgr_nested_send] (4): User entry lacks original memberof ? (Tue Apr 1 20:49:57 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:50:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6] (Tue Apr 1 20:50:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Tue Apr 1 20:50:38 2014) [sssd[be[ops.boingo.com]]] [sbus_dispatch] (3): Connection is not open for dispatching. (Tue Apr 1 20:50:38 2014) [sssd[be[ops.boingo.com]]] [be_client_destructor] (4): Removed PAM client (Tue Apr 1 20:50:38 2014) [sssd[be[ops.boingo.com]]] [sbus_dispatch] (3): Connection is not open for dispatching. (Tue Apr 1 20:50:38 2014) [sssd[be[ops.boingo.com]]] [be_client_destructor] (4): Removed NSS client (Tue Apr 1 20:50:38 2014) [sssd[be[ops.boingo.com]]] [remove_krb5_info_files] (5): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.OPS.BOINGO.COM], [2][No such file or directory] ________________________________________ From: freeipa-users-bounces at redhat.com on behalf of Jakub Hrozek Sent: Tuesday, April 01, 2014 1:19 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate On Tue, Apr 01, 2014 at 05:58:00PM +0000, Todd Maugh wrote: > I am seeing this error in /var/log/secure > > [root at black-64.qa ~]# tail /var/log/secure > Apr 1 17:54:05 black-64 sshd[3649]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.194.1.250 user=tmaugh > Apr 1 17:54:05 black-64 sshd[3649]: pam_sss(sshd:auth): received for user tmaugh: 4 (System error) > Apr 1 17:54:07 black-64 sshd[3649]: Failed password for tmaugh from 10.194.1.250 port 44697 ssh2 > Apr 1 17:54:12 black-64 sshd[3649]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.194.1.250 user=tmaugh > Apr 1 17:54:12 black-64 sshd[3649]: pam_sss(sshd:auth): received for user tmaugh: 4 (System error) "System Error" means something like "Unhandled exception" from pam_sss. In general, this shouldn't happen, although System Error is not always indicative of a bug in SSSD. We use System Error as the default return code if no other condition matches, so sometimes we just fail to translate the error code properly -- at one point, we used to return System Error on clock skew for instance. Could you attach or paste (to me directly if needed) the domain log file and also the krb5_child.log ? > Apr 1 17:54:14 black-64 sshd[3649]: Failed password for tmaugh from 10.194.1.250 port 44697 ssh2 > Apr 1 17:54:15 black-64 sshd[3650]: Connection closed by 10.194.1.250 > Apr 1 17:54:15 black-64 sshd[3649]: PAM 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.194.1.250 user=tmaugh > Apr 1 17:56:49 black-64 sshd[3713]: Accepted publickey for root from 10.194.1.250 port 38249 ssh2 > Apr 1 17:56:49 black-64 sshd[3713]: pam_unix(sshd:session): session opened for user root by (uid=0) _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From tmaugh at boingo.com Tue Apr 1 23:15:53 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 1 Apr 2014 23:15:53 +0000 Subject: [Freeipa-users] force uninstall from Ubunutu 12.04 Message-ID: Has any one been able to successfully uninstall a client from Ubuntu 12.04 I have the install down for these boxes. But I need to transfer an ubunutu client from our old ipa server to the new The error I get during uninstall is Failed to remove krb5/LDAP Configuration Even if I remove the /etc/ipa/default.conf When I go to renenroll client it says IPA client is already configured on this system. Run the uninstall blah blah blah Any suggestions? Does any one know the magic file to remove? Thanks again Your favorite questioner Todd Todd Maugh Sr System Engineer Boingo Wireless tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Apr 2 01:11:26 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Apr 2014 21:11:26 -0400 Subject: [Freeipa-users] force uninstall from Ubunutu 12.04 In-Reply-To: References: Message-ID: <533B63BE.6080006@redhat.com> Todd Maugh wrote: > Has any one been able to successfully uninstall a client from Ubuntu 12.04 > > I have the install down for these boxes. But I need to transfer an > ubunutu client from our old ipa server to the new > > The error I get during uninstall is > > Failed to remove krb5/LDAP Configuration > > Even if I remove the /etc/ipa/default.conf > > When I go to renenroll client it says > > IPA client is already configured on this system. > > Run the uninstall blah blah blah > > Any suggestions? Does any one know the magic file to remove? The files in /var/lib/ipa/sysrestore rob From pspacek at redhat.com Wed Apr 2 07:41:31 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 02 Apr 2014 09:41:31 +0200 Subject: [Freeipa-users] bind-dyndb-ldap: using keytabs for auth to ldap In-Reply-To: <1396381897.21555.29.camel@desktop.bpk2.com> References: <1396361877.21555.18.camel@desktop.bpk2.com> <533B0811.4050402@redhat.com> <1396380859.21555.27.camel@desktop.bpk2.com> <533B17C7.9070001@redhat.com> <1396381897.21555.29.camel@desktop.bpk2.com> Message-ID: <533BBF2B.3070203@redhat.com> On 1.4.2014 21:51, Brendan Kearney wrote: >> No, it is not. >> http://port389.org/wiki/History > > ok then. still, i am trying to learn the individual pieces and get them > working together. Okay then. I'm attaching SASL mapping configuration we use in FreeIPA. You can read all the gory details on https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/SASL.html Please let us know what configuration works for your with OpenLDAP so we can add this information to bind-dyndb-ldap docs or wiki. Have a nice day! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: sasl-config.ldif Type: text/x-ldif Size: 625 bytes Desc: not available URL: From sanchez.nevada at gmail.com Wed Apr 2 01:52:38 2014 From: sanchez.nevada at gmail.com (Nevada Sanchez) Date: Tue, 1 Apr 2014 21:52:38 -0400 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: <533B3296.1020409@redhat.com> References: <533AF3D2.5050308@redhat.com> <533B11F6.3040603@redhat.com> <533B300D.6050707@redhat.com> <533B3296.1020409@redhat.com> Message-ID: The access log is summed up below. I looked into the ipa_lockout errors. They had to do with Kerberos not being set up yet. It shouldn't be, I imagine, but I set up the Kerberos conf anyway and got that error to go away--it didn't fix anything, unfortunately. ============================================== [01/Apr/2014:21:23:29 +0000] conn=1 fd=64 slot=64 connection from ::1 to ::1 [01/Apr/2014:21:23:29 +0000] conn=1 op=-1 fd=64 closed - B1 [01/Apr/2014:21:23:29 +0000] conn=2 fd=64 slot=64 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:29 +0000] conn=2 op=0 BIND dn="cn=directory manager" method=128 version=3 [01/Apr/2014:21:23:29 +0000] conn=2 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:29 +0000] conn=3 fd=65 slot=65 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:29 +0000] conn=3 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:29 +0000] conn=3 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:29 +0000] conn=3 op=1 MOD dn="cn=MemberOf Plugin,cn=plugins,cn=config" [01/Apr/2014:21:23:29 +0000] conn=3 op=2 UNBIND [01/Apr/2014:21:23:29 +0000] conn=3 op=2 fd=65 closed - U1 [01/Apr/2014:21:23:29 +0000] conn=3 op=1 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:29 +0000] conn=4 fd=66 slot=66 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:29 +0000] conn=4 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:29 +0000] conn=4 op=1 ADD dn="cn=ipa-winsync,cn=plugins,cn=config" [01/Apr/2014:21:23:29 +0000] conn=4 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:29 +0000] conn=4 op=2 UNBIND [01/Apr/2014:21:23:29 +0000] conn=4 op=2 fd=66 closed - U1 [01/Apr/2014:21:23:29 +0000] conn=4 op=1 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:30 +0000] conn=5 fd=65 slot=65 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:30 +0000] conn=5 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:30 +0000] conn=5 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:30 +0000] conn=5 op=1 ADD dn="cn=IPA Version Replication,cn=plugins,cn=config" [01/Apr/2014:21:23:30 +0000] conn=5 op=2 UNBIND [01/Apr/2014:21:23:30 +0000] conn=5 op=2 fd=65 closed - U1 [01/Apr/2014:21:23:30 +0000] conn=5 op=1 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:30 +0000] conn=6 fd=66 slot=66 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:30 +0000] conn=6 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:30 +0000] conn=6 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:30 +0000] conn=6 op=1 ADD dn="cn=ipa_enrollment_extop,cn=plugins,cn=config" [01/Apr/2014:21:23:30 +0000] conn=6 op=2 UNBIND [01/Apr/2014:21:23:30 +0000] conn=6 op=2 fd=66 closed - U1 [01/Apr/2014:21:23:30 +0000] conn=6 op=1 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:30 +0000] conn=7 fd=65 slot=65 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:30 +0000] conn=7 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:30 +0000] conn=7 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:30 +0000] conn=7 op=1 MOD dn="cn=config" [01/Apr/2014:21:23:30 +0000] conn=7 op=2 UNBIND [01/Apr/2014:21:23:30 +0000] conn=7 op=2 fd=65 closed - U1 [01/Apr/2014:21:23:30 +0000] conn=7 op=1 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:30 +0000] conn=8 fd=66 slot=66 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:30 +0000] conn=8 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:30 +0000] conn=8 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:30 +0000] conn=8 op=1 ADD dn="cn=krbPrincipalName uniqueness,cn=plugins,cn=config" [01/Apr/2014:21:23:30 +0000] conn=8 op=2 ADD dn="cn=krbCanonicalName uniqueness,cn=plugins,cn=config" [01/Apr/2014:21:23:30 +0000] conn=8 op=1 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:30 +0000] conn=8 op=3 ADD dn="cn=netgroup uniqueness,cn=plugins,cn=config" [01/Apr/2014:21:23:30 +0000] conn=8 op=2 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:30 +0000] conn=8 op=4 ADD dn="cn=ipaUniqueID uniqueness,cn=plugins,cn=config" [01/Apr/2014:21:23:30 +0000] conn=8 op=3 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:30 +0000] conn=8 op=5 ADD dn="cn=sudorule name uniqueness,cn=plugins,cn=config" [01/Apr/2014:21:23:30 +0000] conn=8 op=4 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:30 +0000] conn=8 op=5 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:30 +0000] conn=8 op=6 UNBIND [01/Apr/2014:21:23:30 +0000] conn=8 op=6 fd=66 closed - U1 [01/Apr/2014:21:23:30 +0000] conn=9 fd=65 slot=65 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:30 +0000] conn=9 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:30 +0000] conn=9 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:30 +0000] conn=9 op=1 ADD dn="cn=IPA UUID,cn=plugins,cn=config" [01/Apr/2014:21:23:30 +0000] conn=9 op=2 UNBIND [01/Apr/2014:21:23:30 +0000] conn=9 op=2 fd=65 closed - U1 [01/Apr/2014:21:23:30 +0000] conn=9 op=1 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:30 +0000] conn=10 fd=66 slot=66 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:30 +0000] conn=10 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:30 +0000] conn=10 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:30 +0000] conn=10 op=1 ADD dn="cn=IPA Unique IDs,cn=IPA UUID,cn=plugins,cn=config" [01/Apr/2014:21:23:30 +0000] conn=10 op=2 UNBIND [01/Apr/2014:21:23:30 +0000] conn=10 op=2 fd=66 closed - U1 [01/Apr/2014:21:23:30 +0000] conn=10 op=1 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:30 +0000] conn=11 fd=65 slot=65 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:30 +0000] conn=11 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:30 +0000] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:30 +0000] conn=11 op=1 ADD dn="cn=IPA MODRDN,cn=plugins,cn=config" [01/Apr/2014:21:23:30 +0000] conn=11 op=2 UNBIND [01/Apr/2014:21:23:30 +0000] conn=11 op=2 fd=65 closed - U1 [01/Apr/2014:21:23:30 +0000] conn=11 op=1 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:30 +0000] conn=12 fd=66 slot=66 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:30 +0000] conn=12 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:30 +0000] conn=12 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:30 +0000] conn=12 op=1 ADD dn="cn=Kerberos Principal Name,cn=IPA MODRDN,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=12 op=2 UNBIND [01/Apr/2014:21:23:31 +0000] conn=12 op=2 fd=66 closed - U1 [01/Apr/2014:21:23:31 +0000] conn=12 op=1 RESULT err=0 tag=105 nentries=0 etime=1 [01/Apr/2014:21:23:31 +0000] conn=13 fd=65 slot=65 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:31 +0000] conn=13 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:31 +0000] conn=13 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:31 +0000] conn=13 op=1 ADD dn="cn=IPA DNS,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=13 op=2 UNBIND [01/Apr/2014:21:23:31 +0000] conn=13 op=2 fd=65 closed - U1 [01/Apr/2014:21:23:31 +0000] conn=13 op=1 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=14 fd=66 slot=66 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:31 +0000] conn=14 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:31 +0000] conn=14 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:31 +0000] conn=14 op=1 MOD dn="cn=config" [01/Apr/2014:21:23:31 +0000] conn=14 op=2 MOD dn="cn=config" [01/Apr/2014:21:23:31 +0000] conn=14 op=1 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=14 op=3 MOD dn="cn=USN,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=14 op=2 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=14 op=4 UNBIND [01/Apr/2014:21:23:31 +0000] conn=14 op=4 fd=66 closed - U1 [01/Apr/2014:21:23:31 +0000] conn=14 op=3 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=15 fd=65 slot=65 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:31 +0000] conn=15 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:31 +0000] conn=15 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:31 +0000] conn=15 op=1 ADD dn="cn=IPA Lockout,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=15 op=2 UNBIND [01/Apr/2014:21:23:31 +0000] conn=15 op=2 fd=65 closed - U1 [01/Apr/2014:21:23:31 +0000] conn=15 op=1 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 fd=66 slot=66 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:31 +0000] conn=16 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:31 +0000] conn=16 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:31 +0000] conn=16 op=1 ADD dn="cn=krbPrincipalName,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=2 ADD dn="cn=ou,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=1 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=3 ADD dn="cn=carLicense,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=2 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=4 ADD dn="cn=title,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=3 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=5 ADD dn="cn=manager,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=4 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=6 ADD dn="cn=secretary,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=7 ADD dn="cn=displayname,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=6 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=5 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=8 MOD dn="cn=uid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=9 ADD dn="cn=uidnumber,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=8 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=7 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=10 ADD dn="cn=gidnumber,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=9 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=11 MOD dn="cn=ntUniqueId,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=10 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=12 MOD dn="cn=ntUserDomainId,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=11 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=13 ADD dn="cn=fqdn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=12 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=14 ADD dn="cn=macAddress,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=15 ADD dn="cn=memberHost,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=14 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=13 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=16 ADD dn="cn=memberUser,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=15 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=16 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=17 ADD dn="cn=sourcehost,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=17 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=18 ADD dn="cn=memberservice,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=19 ADD dn="cn=managedby,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=18 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=20 ADD dn="cn=memberallowcmd,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=19 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=21 ADD dn="cn=memberdenycmd,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=21 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=20 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=22 ADD dn="cn=ipasudorunas,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=23 ADD dn="cn=ipasudorunasgroup,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=22 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=24 ADD dn="cn=automountkey,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=24 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=23 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=25 ADD dn="cn=ipakrbprincipalalias,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=25 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=26 ADD dn="cn=ipauniqueid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [01/Apr/2014:21:23:31 +0000] conn=16 op=26 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:31 +0000] conn=16 op=27 UNBIND [01/Apr/2014:21:23:31 +0000] conn=16 op=27 fd=66 closed - U1 [01/Apr/2014:21:23:31 +0000] conn=17 fd=65 slot=65 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:31 +0000] conn=17 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:31 +0000] conn=17 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:31 +0000] conn=17 op=1 MOD dn="cn=referential integrity postoperation,cn=plugins,cn=config" [01/Apr/2014:21:23:32 +0000] conn=17 op=2 UNBIND [01/Apr/2014:21:23:32 +0000] conn=17 op=2 fd=65 closed - U1 [01/Apr/2014:21:23:32 +0000] conn=17 op=1 RESULT err=0 tag=103 nentries=0 etime=1 [01/Apr/2014:21:23:42 +0000] conn=18 fd=65 slot=65 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:42 +0000] conn=18 op=0 BIND dn="cn=directory manager" method=128 version=3 [01/Apr/2014:21:23:42 +0000] conn=18 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:42 +0000] conn=18 op=1 MOD dn="cn=encryption,cn=config" [01/Apr/2014:21:23:42 +0000] conn=18 op=2 MOD dn="cn=config" [01/Apr/2014:21:23:42 +0000] conn=18 op=1 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:42 +0000] conn=18 op=3 SRCH base="cn=schema" scope=0 filter="(objectClass=*)" attrs="attributeTypes objectClasses" [01/Apr/2014:21:23:42 +0000] conn=18 op=2 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:42 +0000] conn=18 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [01/Apr/2014:21:23:43 +0000] conn=18 op=4 ADD dn="cn=RSA,cn=encryption,cn=config" [01/Apr/2014:21:23:43 +0000] conn=18 op=5 UNBIND [01/Apr/2014:21:23:43 +0000] conn=18 op=5 fd=65 closed - U1 [01/Apr/2014:21:23:43 +0000] conn=18 op=4 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:43 +0000] conn=19 fd=66 slot=66 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:43 +0000] conn=19 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:43 +0000] conn=19 op=1 ADD dn="cn=root-autobind,cn=config" [01/Apr/2014:21:23:43 +0000] conn=19 op=2 MOD dn="cn=config" [01/Apr/2014:21:23:43 +0000] conn=19 op=1 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:43 +0000] conn=19 op=3 MOD dn="cn=config" [01/Apr/2014:21:23:43 +0000] conn=19 op=2 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:43 +0000] conn=19 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:43 +0000] conn=19 op=4 UNBIND [01/Apr/2014:21:23:43 +0000] conn=19 op=4 fd=66 closed - U1 [01/Apr/2014:21:23:43 +0000] conn=19 op=3 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:43 +0000] conn=20 fd=65 slot=65 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:43 +0000] conn=20 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:43 +0000] conn=20 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:43 +0000] conn=20 op=1 MOD dn="cn=Managed Entries,cn=plugins,cn=config" [01/Apr/2014:21:23:43 +0000] conn=20 op=2 UNBIND [01/Apr/2014:21:23:43 +0000] conn=20 op=2 fd=65 closed - U1 [01/Apr/2014:21:23:43 +0000] conn=20 op=1 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:43 +0000] conn=21 fd=66 slot=66 connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:43 +0000] conn=21 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [01/Apr/2014:21:23:43 +0000] conn=21 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:43 +0000] conn=21 op=1 MOD dn="cn=config" [01/Apr/2014:21:23:43 +0000] conn=21 op=2 UNBIND [01/Apr/2014:21:23:43 +0000] conn=21 op=2 fd=66 closed - U1 [01/Apr/2014:21:23:43 +0000] conn=21 op=1 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:46 +0000] conn=1 fd=64 slot=64 connection from ::1 to ::1 [01/Apr/2014:21:23:46 +0000] conn=1 op=-1 fd=64 closed - B1 [01/Apr/2014:21:23:46 +0000] conn=2 fd=64 slot=64 connection from local to /var/run/slapd-EXAMPLE-COM.socket [01/Apr/2014:21:23:46 +0000] conn=2 op=0 BIND dn="cn=directory manager" method=128 version=3 [01/Apr/2014:21:23:46 +0000] conn=2 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:46 +0000] conn=2 op=1 SRCH base="cn=IPA Version Replication,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL [01/Apr/2014:21:23:46 +0000] conn=2 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [01/Apr/2014:21:23:46 +0000] conn=2 op=2 SRCH base="cn=schema" scope=0 filter="(objectClass=*)" attrs="attributeTypes objectClasses" [01/Apr/2014:21:23:46 +0000] conn=2 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [01/Apr/2014:21:23:47 +0000] conn=2 op=3 MOD dn="cn=IPA Version Replication,cn=plugins,cn=config" [01/Apr/2014:21:23:47 +0000] conn=2 op=4 UNBIND [01/Apr/2014:21:23:47 +0000] conn=2 op=4 fd=64 closed - U1 [01/Apr/2014:21:23:47 +0000] conn=2 op=3 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:51 +0000] conn=1 fd=64 slot=64 connection from ::1 to ::1 [01/Apr/2014:21:23:51 +0000] conn=2 fd=65 slot=65 SSL connection from 10.0.3.15 to 10.0.3.15 [01/Apr/2014:21:23:51 +0000] conn=1 op=-1 fd=64 closed - B1 [01/Apr/2014:21:23:51 +0000] conn=2 SSL 256-bit AES [01/Apr/2014:21:23:51 +0000] conn=2 op=0 BIND dn="cn=directory manager" method=128 version=3 [01/Apr/2014:21:23:51 +0000] conn=2 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [01/Apr/2014:21:23:51 +0000] conn=2 op=1 SRCH base="cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL [01/Apr/2014:21:23:51 +0000] conn=2 op=1 RESULT err=32 tag=101 nentries=0 etime=0 [01/Apr/2014:21:23:52 +0000] conn=2 op=2 SRCH base="cn=schema" scope=0 filter="(objectClass=*)" attrs="attributeTypes objectClasses" [01/Apr/2014:21:23:52 +0000] conn=2 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [01/Apr/2014:21:23:52 +0000] conn=2 op=3 ADD dn="cn=replication manager,cn=config" [01/Apr/2014:21:23:52 +0000] conn=2 op=4 SRCH base="cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL [01/Apr/2014:21:23:52 +0000] conn=2 op=3 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:52 +0000] conn=2 op=4 RESULT err=32 tag=101 nentries=0 etime=0 [01/Apr/2014:21:23:52 +0000] conn=2 op=5 ADD dn="cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" [01/Apr/2014:21:23:52 +0000] conn=2 op=6 SRCH base="cn=config,cn=ldbm database,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" attrs="nsslapd-directory" [01/Apr/2014:21:23:52 +0000] conn=2 op=6 RESULT err=0 tag=101 nentries=1 etime=0 [01/Apr/2014:21:23:52 +0000] conn=2 op=7 ADD dn="cn=changelog5,cn=config" [01/Apr/2014:21:23:52 +0000] conn=2 op=5 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:52 +0000] conn=2 op=7 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:52 +0000] conn=3 fd=64 slot=64 connection from 10.0.3.4 to 10.0.3.15 [01/Apr/2014:21:23:52 +0000] conn=3 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [01/Apr/2014:21:23:52 +0000] conn=3 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [01/Apr/2014:21:23:53 +0000] conn=3 SSL 256-bit AES [01/Apr/2014:21:23:53 +0000] conn=3 op=1 BIND dn="cn=replication manager,cn=config" method=128 version=3 [01/Apr/2014:21:23:53 +0000] conn=3 op=1 RESULT err=0 tag=97 nentries=0 etime=1 dn="cn=replication manager,cn=config" [01/Apr/2014:21:23:53 +0000] conn=3 op=2 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [01/Apr/2014:21:23:53 +0000] conn=3 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [01/Apr/2014:21:23:53 +0000] conn=3 op=3 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [01/Apr/2014:21:23:53 +0000] conn=3 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [01/Apr/2014:21:23:53 +0000] conn=3 op=4 EXT oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" [01/Apr/2014:21:23:53 +0000] conn=2 op=8 SRCH base="cn=meToipa.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL [01/Apr/2014:21:23:53 +0000] conn=2 op=8 RESULT err=32 tag=101 nentries=0 etime=0 [01/Apr/2014:21:23:53 +0000] conn=2 op=9 ADD dn="cn=meToipa.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" [01/Apr/2014:21:23:53 +0000] conn=3 op=4 RESULT err=0 tag=120 nentries=0 etime=0 [01/Apr/2014:21:23:53 +0000] conn=2 op=10 MOD dn="cn=meToipa.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" [01/Apr/2014:21:23:53 +0000] conn=2 op=9 RESULT err=0 tag=105 nentries=0 etime=0 [01/Apr/2014:21:23:53 +0000] conn=3 op=5 SRCH base="cn=schema" scope=0 filter="(objectClass=*)" attrs="nsSchemaCSN" [01/Apr/2014:21:23:53 +0000] conn=2 op=11 SRCH base="cn=meToipa.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL [01/Apr/2014:21:23:53 +0000] conn=2 op=11 RESULT err=0 tag=101 nentries=1 etime=0 [01/Apr/2014:21:23:53 +0000] conn=2 op=10 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:53 +0000] conn=3 op=5 RESULT err=0 tag=101 nentries=1 etime=0 [01/Apr/2014:21:23:53 +0000] conn=3 op=6 MOD dn="cn=schema" [01/Apr/2014:21:23:53 +0000] conn=3 op=6 RESULT err=0 tag=103 nentries=0 etime=0 [01/Apr/2014:21:23:53 +0000] conn=3 op=7 EXT oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End Session" [01/Apr/2014:21:23:53 +0000] conn=3 op=7 RESULT err=0 tag=120 nentries=0 etime=0 [01/Apr/2014:21:23:53 +0000] conn=3 op=8 UNBIND [01/Apr/2014:21:23:53 +0000] conn=3 op=8 fd=64 closed - U1 [01/Apr/2014:21:23:53 +0000] conn=4 fd=66 slot=66 connection from 10.0.3.4 to 10.0.3.15 [01/Apr/2014:21:23:53 +0000] conn=4 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [01/Apr/2014:21:23:53 +0000] conn=4 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [01/Apr/2014:21:23:53 +0000] conn=4 SSL 256-bit AES [01/Apr/2014:21:23:53 +0000] conn=4 op=1 BIND dn="cn=replication manager,cn=config" method=128 version=3 [01/Apr/2014:21:23:53 +0000] conn=4 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=replication manager,cn=config" [01/Apr/2014:21:23:53 +0000] conn=4 op=2 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [01/Apr/2014:21:23:53 +0000] conn=4 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [01/Apr/2014:21:23:53 +0000] conn=4 op=3 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [01/Apr/2014:21:23:53 +0000] conn=4 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [01/Apr/2014:21:23:53 +0000] conn=4 op=4 EXT oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" [01/Apr/2014:21:23:54 +0000] conn=4 op=4 RESULT err=0 tag=120 nentries=0 etime=1 [01/Apr/2014:21:23:54 +0000] conn=4 op=5 SRCH base="cn=schema" scope=0 filter="(objectClass=*)" attrs="nsSchemaCSN" [01/Apr/2014:21:23:54 +0000] conn=4 op=5 RESULT err=0 tag=101 nentries=1 etime=0 [01/Apr/2014:21:23:54 +0000] conn=4 op=6 EXT oid="2.16.840.1.113730.3.5.6" name="Netscape Replication Total Update Entry" . . . [01/Apr/2014:21:23:55 +0000] conn=4 op=458 RESULT err=0 tag=120 nentries=0 etime=0 [01/Apr/2014:21:23:57 +0000] conn=4 op=459 EXT oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End Session" [01/Apr/2014:21:23:57 +0000] conn=4 op=459 RESULT err=0 tag=120 nentries=0 etime=0 [01/Apr/2014:21:23:58 +0000] conn=4 op=460 UNBIND [01/Apr/2014:21:23:58 +0000] conn=4 op=460 fd=66 closed - U1 [01/Apr/2014:21:23:58 +0000] conn=5 fd=64 slot=64 connection from 10.0.3.4 to 10.0.3.15 [01/Apr/2014:21:23:58 +0000] conn=5 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [01/Apr/2014:21:23:58 +0000] conn=5 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [01/Apr/2014:21:23:58 +0000] conn=5 SSL 256-bit AES [01/Apr/2014:21:23:58 +0000] conn=5 op=1 BIND dn="cn=replication manager,cn=config" method=128 version=3 [01/Apr/2014:21:23:58 +0000] conn=5 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=replication manager,cn=config" [01/Apr/2014:21:23:58 +0000] conn=5 op=2 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [01/Apr/2014:21:23:58 +0000] conn=5 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [01/Apr/2014:21:23:58 +0000] conn=5 op=3 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [01/Apr/2014:21:23:58 +0000] conn=5 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [01/Apr/2014:21:23:58 +0000] conn=5 op=4 EXT oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" [01/Apr/2014:21:23:58 +0000] conn=5 op=4 RESULT err=0 tag=120 nentries=0 etime=0 [01/Apr/2014:21:23:58 +0000] conn=5 op=5 SRCH base="cn=schema" scope=0 filter="(objectClass=*)" attrs="nsSchemaCSN" [01/Apr/2014:21:23:58 +0000] conn=5 op=5 RESULT err=0 tag=101 nentries=1 etime=0 [01/Apr/2014:21:23:58 +0000] conn=5 op=6 SRCH base="cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs="nsDS5ReplicaId" [01/Apr/2014:21:23:58 +0000] conn=5 op=6 RESULT err=0 tag=101 nentries=1 etime=0 [01/Apr/2014:21:23:58 +0000] conn=5 op=7 EXT oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End Session" [01/Apr/2014:21:23:58 +0000] conn=5 op=7 RESULT err=0 tag=120 nentries=0 etime=0 [01/Apr/2014:21:23:59 +0000] conn=2 op=12 UNBIND [01/Apr/2014:21:23:59 +0000] conn=2 op=12 fd=65 closed - U1 On Tue, Apr 1, 2014 at 5:41 PM, Rob Crittenden wrote: > Rich Megginson wrote: > >> On 04/01/2014 03:28 PM, Nevada Sanchez wrote: >> >>> Okay, I just tried doing this on a FRESH fedora 19 image (applied all >>> updates, installed freeipa, made a new replica file for the new test >>> server, and went state to ipa-replica-insntall). Exact same errors. >>> Anything else I should try? >>> >> >> I don't know. >> >> Does anyone on the IPA team know what the ipa_lockout errors are about, >> and if they would cause replication not to work? >> >> > I suspect it is a red herring. The error is not found, so it is probably > that the entry doesn't exist yet. This is replication for the CA anyway. > > I'd be curious what the access and error logs on the existing side looks > like. It may be an SSL trust problem, for example. > > rob > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Apr 2 13:46:34 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 02 Apr 2014 07:46:34 -0600 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: References: <533AF3D2.5050308@redhat.com> <533B11F6.3040603@redhat.com> <533B300D.6050707@redhat.com> <533B3296.1020409@redhat.com> Message-ID: <533C14BA.1030307@redhat.com> On 04/01/2014 07:52 PM, Nevada Sanchez wrote: > The access log is summed up below. I looked into the ipa_lockout > errors. They had to do with Kerberos not being set up yet. It > shouldn't be, I imagine, but I set up the Kerberos conf anyway and got > that error to go away--it didn't fix anything, unfortunately. > > ============================================== > [01/Apr/2014:21:23:29 +0000] conn=1 fd=64 slot=64 connection from ::1 > to ::1 > [01/Apr/2014:21:23:29 +0000] conn=1 op=-1 fd=64 closed - B1 > [01/Apr/2014:21:23:29 +0000] conn=2 fd=64 slot=64 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:29 +0000] conn=2 op=0 BIND dn="cn=directory > manager" method=128 version=3 > [01/Apr/2014:21:23:29 +0000] conn=2 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:29 +0000] conn=3 fd=65 slot=65 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:29 +0000] conn=3 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:29 +0000] conn=3 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:29 +0000] conn=3 op=1 MOD dn="cn=MemberOf > Plugin,cn=plugins,cn=config" > [01/Apr/2014:21:23:29 +0000] conn=3 op=2 UNBIND > [01/Apr/2014:21:23:29 +0000] conn=3 op=2 fd=65 closed - U1 > [01/Apr/2014:21:23:29 +0000] conn=3 op=1 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:29 +0000] conn=4 fd=66 slot=66 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:29 +0000] conn=4 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:29 +0000] conn=4 op=1 ADD > dn="cn=ipa-winsync,cn=plugins,cn=config" > [01/Apr/2014:21:23:29 +0000] conn=4 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:29 +0000] conn=4 op=2 UNBIND > [01/Apr/2014:21:23:29 +0000] conn=4 op=2 fd=66 closed - U1 > [01/Apr/2014:21:23:29 +0000] conn=4 op=1 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:30 +0000] conn=5 fd=65 slot=65 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:30 +0000] conn=5 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:30 +0000] conn=5 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:30 +0000] conn=5 op=1 ADD dn="cn=IPA Version > Replication,cn=plugins,cn=config" > [01/Apr/2014:21:23:30 +0000] conn=5 op=2 UNBIND > [01/Apr/2014:21:23:30 +0000] conn=5 op=2 fd=65 closed - U1 > [01/Apr/2014:21:23:30 +0000] conn=5 op=1 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:30 +0000] conn=6 fd=66 slot=66 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:30 +0000] conn=6 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:30 +0000] conn=6 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:30 +0000] conn=6 op=1 ADD > dn="cn=ipa_enrollment_extop,cn=plugins,cn=config" > [01/Apr/2014:21:23:30 +0000] conn=6 op=2 UNBIND > [01/Apr/2014:21:23:30 +0000] conn=6 op=2 fd=66 closed - U1 > [01/Apr/2014:21:23:30 +0000] conn=6 op=1 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:30 +0000] conn=7 fd=65 slot=65 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:30 +0000] conn=7 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:30 +0000] conn=7 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:30 +0000] conn=7 op=1 MOD dn="cn=config" > [01/Apr/2014:21:23:30 +0000] conn=7 op=2 UNBIND > [01/Apr/2014:21:23:30 +0000] conn=7 op=2 fd=65 closed - U1 > [01/Apr/2014:21:23:30 +0000] conn=7 op=1 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:30 +0000] conn=8 fd=66 slot=66 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:30 +0000] conn=8 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:30 +0000] conn=8 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:30 +0000] conn=8 op=1 ADD dn="cn=krbPrincipalName > uniqueness,cn=plugins,cn=config" > [01/Apr/2014:21:23:30 +0000] conn=8 op=2 ADD dn="cn=krbCanonicalName > uniqueness,cn=plugins,cn=config" > [01/Apr/2014:21:23:30 +0000] conn=8 op=1 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:30 +0000] conn=8 op=3 ADD dn="cn=netgroup > uniqueness,cn=plugins,cn=config" > [01/Apr/2014:21:23:30 +0000] conn=8 op=2 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:30 +0000] conn=8 op=4 ADD dn="cn=ipaUniqueID > uniqueness,cn=plugins,cn=config" > [01/Apr/2014:21:23:30 +0000] conn=8 op=3 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:30 +0000] conn=8 op=5 ADD dn="cn=sudorule name > uniqueness,cn=plugins,cn=config" > [01/Apr/2014:21:23:30 +0000] conn=8 op=4 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:30 +0000] conn=8 op=5 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:30 +0000] conn=8 op=6 UNBIND > [01/Apr/2014:21:23:30 +0000] conn=8 op=6 fd=66 closed - U1 > [01/Apr/2014:21:23:30 +0000] conn=9 fd=65 slot=65 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:30 +0000] conn=9 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:30 +0000] conn=9 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:30 +0000] conn=9 op=1 ADD dn="cn=IPA > UUID,cn=plugins,cn=config" > [01/Apr/2014:21:23:30 +0000] conn=9 op=2 UNBIND > [01/Apr/2014:21:23:30 +0000] conn=9 op=2 fd=65 closed - U1 > [01/Apr/2014:21:23:30 +0000] conn=9 op=1 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:30 +0000] conn=10 fd=66 slot=66 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:30 +0000] conn=10 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:30 +0000] conn=10 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:30 +0000] conn=10 op=1 ADD dn="cn=IPA Unique > IDs,cn=IPA UUID,cn=plugins,cn=config" > [01/Apr/2014:21:23:30 +0000] conn=10 op=2 UNBIND > [01/Apr/2014:21:23:30 +0000] conn=10 op=2 fd=66 closed - U1 > [01/Apr/2014:21:23:30 +0000] conn=10 op=1 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:30 +0000] conn=11 fd=65 slot=65 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:30 +0000] conn=11 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:30 +0000] conn=11 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:30 +0000] conn=11 op=1 ADD dn="cn=IPA > MODRDN,cn=plugins,cn=config" > [01/Apr/2014:21:23:30 +0000] conn=11 op=2 UNBIND > [01/Apr/2014:21:23:30 +0000] conn=11 op=2 fd=65 closed - U1 > [01/Apr/2014:21:23:30 +0000] conn=11 op=1 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:30 +0000] conn=12 fd=66 slot=66 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:30 +0000] conn=12 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:30 +0000] conn=12 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:30 +0000] conn=12 op=1 ADD dn="cn=Kerberos > Principal Name,cn=IPA MODRDN,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=12 op=2 UNBIND > [01/Apr/2014:21:23:31 +0000] conn=12 op=2 fd=66 closed - U1 > [01/Apr/2014:21:23:31 +0000] conn=12 op=1 RESULT err=0 tag=105 > nentries=0 etime=1 > [01/Apr/2014:21:23:31 +0000] conn=13 fd=65 slot=65 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:31 +0000] conn=13 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:31 +0000] conn=13 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:31 +0000] conn=13 op=1 ADD dn="cn=IPA > DNS,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=13 op=2 UNBIND > [01/Apr/2014:21:23:31 +0000] conn=13 op=2 fd=65 closed - U1 > [01/Apr/2014:21:23:31 +0000] conn=13 op=1 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=14 fd=66 slot=66 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:31 +0000] conn=14 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:31 +0000] conn=14 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:31 +0000] conn=14 op=1 MOD dn="cn=config" > [01/Apr/2014:21:23:31 +0000] conn=14 op=2 MOD dn="cn=config" > [01/Apr/2014:21:23:31 +0000] conn=14 op=1 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=14 op=3 MOD > dn="cn=USN,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=14 op=2 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=14 op=4 UNBIND > [01/Apr/2014:21:23:31 +0000] conn=14 op=4 fd=66 closed - U1 > [01/Apr/2014:21:23:31 +0000] conn=14 op=3 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=15 fd=65 slot=65 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:31 +0000] conn=15 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:31 +0000] conn=15 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:31 +0000] conn=15 op=1 ADD dn="cn=IPA > Lockout,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=15 op=2 UNBIND > [01/Apr/2014:21:23:31 +0000] conn=15 op=2 fd=65 closed - U1 > [01/Apr/2014:21:23:31 +0000] conn=15 op=1 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 fd=66 slot=66 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:31 +0000] conn=16 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:31 +0000] conn=16 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:31 +0000] conn=16 op=1 ADD > dn="cn=krbPrincipalName,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=2 ADD > dn="cn=ou,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=1 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=3 ADD > dn="cn=carLicense,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=2 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=4 ADD > dn="cn=title,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=3 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=5 ADD > dn="cn=manager,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=4 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=6 ADD > dn="cn=secretary,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=7 ADD > dn="cn=displayname,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=6 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=5 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=8 MOD > dn="cn=uid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=9 ADD > dn="cn=uidnumber,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=8 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=7 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=10 ADD > dn="cn=gidnumber,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=9 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=11 MOD > dn="cn=ntUniqueId,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=10 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=12 MOD > dn="cn=ntUserDomainId,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=11 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=13 ADD > dn="cn=fqdn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=12 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=14 ADD > dn="cn=macAddress,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=15 ADD > dn="cn=memberHost,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=14 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=13 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=16 ADD > dn="cn=memberUser,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=15 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=16 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=17 ADD > dn="cn=sourcehost,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=17 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=18 ADD > dn="cn=memberservice,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=19 ADD > dn="cn=managedby,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=18 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=20 ADD > dn="cn=memberallowcmd,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=19 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=21 ADD > dn="cn=memberdenycmd,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=21 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=20 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=22 ADD > dn="cn=ipasudorunas,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=23 ADD > dn="cn=ipasudorunasgroup,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=22 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=24 ADD > dn="cn=automountkey,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=24 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=23 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=25 ADD > dn="cn=ipakrbprincipalalias,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=25 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=26 ADD > dn="cn=ipauniqueid,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > [01/Apr/2014:21:23:31 +0000] conn=16 op=26 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:31 +0000] conn=16 op=27 UNBIND > [01/Apr/2014:21:23:31 +0000] conn=16 op=27 fd=66 closed - U1 > [01/Apr/2014:21:23:31 +0000] conn=17 fd=65 slot=65 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:31 +0000] conn=17 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:31 +0000] conn=17 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:31 +0000] conn=17 op=1 MOD dn="cn=referential > integrity postoperation,cn=plugins,cn=config" > [01/Apr/2014:21:23:32 +0000] conn=17 op=2 UNBIND > [01/Apr/2014:21:23:32 +0000] conn=17 op=2 fd=65 closed - U1 > [01/Apr/2014:21:23:32 +0000] conn=17 op=1 RESULT err=0 tag=103 > nentries=0 etime=1 > [01/Apr/2014:21:23:42 +0000] conn=18 fd=65 slot=65 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:42 +0000] conn=18 op=0 BIND dn="cn=directory > manager" method=128 version=3 > [01/Apr/2014:21:23:42 +0000] conn=18 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:42 +0000] conn=18 op=1 MOD dn="cn=encryption,cn=config" > [01/Apr/2014:21:23:42 +0000] conn=18 op=2 MOD dn="cn=config" > [01/Apr/2014:21:23:42 +0000] conn=18 op=1 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:42 +0000] conn=18 op=3 SRCH base="cn=schema" > scope=0 filter="(objectClass=*)" attrs="attributeTypes objectClasses" > [01/Apr/2014:21:23:42 +0000] conn=18 op=2 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:42 +0000] conn=18 op=3 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Apr/2014:21:23:43 +0000] conn=18 op=4 ADD > dn="cn=RSA,cn=encryption,cn=config" > [01/Apr/2014:21:23:43 +0000] conn=18 op=5 UNBIND > [01/Apr/2014:21:23:43 +0000] conn=18 op=5 fd=65 closed - U1 > [01/Apr/2014:21:23:43 +0000] conn=18 op=4 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:43 +0000] conn=19 fd=66 slot=66 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:43 +0000] conn=19 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:43 +0000] conn=19 op=1 ADD > dn="cn=root-autobind,cn=config" > [01/Apr/2014:21:23:43 +0000] conn=19 op=2 MOD dn="cn=config" > [01/Apr/2014:21:23:43 +0000] conn=19 op=1 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:43 +0000] conn=19 op=3 MOD dn="cn=config" > [01/Apr/2014:21:23:43 +0000] conn=19 op=2 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:43 +0000] conn=19 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:43 +0000] conn=19 op=4 UNBIND > [01/Apr/2014:21:23:43 +0000] conn=19 op=4 fd=66 closed - U1 > [01/Apr/2014:21:23:43 +0000] conn=19 op=3 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:43 +0000] conn=20 fd=65 slot=65 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:43 +0000] conn=20 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:43 +0000] conn=20 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:43 +0000] conn=20 op=1 MOD dn="cn=Managed > Entries,cn=plugins,cn=config" > [01/Apr/2014:21:23:43 +0000] conn=20 op=2 UNBIND > [01/Apr/2014:21:23:43 +0000] conn=20 op=2 fd=65 closed - U1 > [01/Apr/2014:21:23:43 +0000] conn=20 op=1 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:43 +0000] conn=21 fd=66 slot=66 connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:43 +0000] conn=21 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [01/Apr/2014:21:23:43 +0000] conn=21 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:43 +0000] conn=21 op=1 MOD dn="cn=config" > [01/Apr/2014:21:23:43 +0000] conn=21 op=2 UNBIND > [01/Apr/2014:21:23:43 +0000] conn=21 op=2 fd=66 closed - U1 > [01/Apr/2014:21:23:43 +0000] conn=21 op=1 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:46 +0000] conn=1 fd=64 slot=64 connection from ::1 > to ::1 > [01/Apr/2014:21:23:46 +0000] conn=1 op=-1 fd=64 closed - B1 > [01/Apr/2014:21:23:46 +0000] conn=2 fd=64 slot=64 connection from > local to /var/run/slapd-EXAMPLE-COM.socket > [01/Apr/2014:21:23:46 +0000] conn=2 op=0 BIND dn="cn=directory > manager" method=128 version=3 > [01/Apr/2014:21:23:46 +0000] conn=2 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:46 +0000] conn=2 op=1 SRCH base="cn=IPA Version > Replication,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" > attrs=ALL > [01/Apr/2014:21:23:46 +0000] conn=2 op=1 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Apr/2014:21:23:46 +0000] conn=2 op=2 SRCH base="cn=schema" scope=0 > filter="(objectClass=*)" attrs="attributeTypes objectClasses" > [01/Apr/2014:21:23:46 +0000] conn=2 op=2 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Apr/2014:21:23:47 +0000] conn=2 op=3 MOD dn="cn=IPA Version > Replication,cn=plugins,cn=config" > [01/Apr/2014:21:23:47 +0000] conn=2 op=4 UNBIND > [01/Apr/2014:21:23:47 +0000] conn=2 op=4 fd=64 closed - U1 > [01/Apr/2014:21:23:47 +0000] conn=2 op=3 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:51 +0000] conn=1 fd=64 slot=64 connection from ::1 > to ::1 > [01/Apr/2014:21:23:51 +0000] conn=2 fd=65 slot=65 SSL connection from > 10.0.3.15 to 10.0.3.15 > [01/Apr/2014:21:23:51 +0000] conn=1 op=-1 fd=64 closed - B1 > [01/Apr/2014:21:23:51 +0000] conn=2 SSL 256-bit AES > [01/Apr/2014:21:23:51 +0000] conn=2 op=0 BIND dn="cn=directory > manager" method=128 version=3 > [01/Apr/2014:21:23:51 +0000] conn=2 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [01/Apr/2014:21:23:51 +0000] conn=2 op=1 SRCH > base="cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" > scope=0 filter="(objectClass=*)" attrs=ALL > [01/Apr/2014:21:23:51 +0000] conn=2 op=1 RESULT err=32 tag=101 > nentries=0 etime=0 > [01/Apr/2014:21:23:52 +0000] conn=2 op=2 SRCH base="cn=schema" scope=0 > filter="(objectClass=*)" attrs="attributeTypes objectClasses" > [01/Apr/2014:21:23:52 +0000] conn=2 op=2 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Apr/2014:21:23:52 +0000] conn=2 op=3 ADD dn="cn=replication > manager,cn=config" > [01/Apr/2014:21:23:52 +0000] conn=2 op=4 SRCH > base="cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" > scope=0 filter="(objectClass=*)" attrs=ALL > [01/Apr/2014:21:23:52 +0000] conn=2 op=3 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:52 +0000] conn=2 op=4 RESULT err=32 tag=101 > nentries=0 etime=0 > [01/Apr/2014:21:23:52 +0000] conn=2 op=5 ADD > dn="cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" > [01/Apr/2014:21:23:52 +0000] conn=2 op=6 SRCH base="cn=config,cn=ldbm > database,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" > attrs="nsslapd-directory" > [01/Apr/2014:21:23:52 +0000] conn=2 op=6 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Apr/2014:21:23:52 +0000] conn=2 op=7 ADD dn="cn=changelog5,cn=config" > [01/Apr/2014:21:23:52 +0000] conn=2 op=5 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:52 +0000] conn=2 op=7 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:52 +0000] conn=3 fd=64 slot=64 connection from > 10.0.3.4 to 10.0.3.15 > [01/Apr/2014:21:23:52 +0000] conn=3 op=0 EXT > oid="1.3.6.1.4.1.1466.20037" name="startTLS" > [01/Apr/2014:21:23:52 +0000] conn=3 op=0 RESULT err=0 tag=120 > nentries=0 etime=0 > [01/Apr/2014:21:23:53 +0000] conn=3 SSL 256-bit AES > [01/Apr/2014:21:23:53 +0000] conn=3 op=1 BIND dn="cn=replication > manager,cn=config" method=128 version=3 > [01/Apr/2014:21:23:53 +0000] conn=3 op=1 RESULT err=0 tag=97 > nentries=0 etime=1 dn="cn=replication manager,cn=config" > [01/Apr/2014:21:23:53 +0000] conn=3 op=2 SRCH base="" scope=0 > filter="(objectClass=*)" attrs="supportedControl supportedExtension" > [01/Apr/2014:21:23:53 +0000] conn=3 op=2 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Apr/2014:21:23:53 +0000] conn=3 op=3 SRCH base="" scope=0 > filter="(objectClass=*)" attrs="supportedControl supportedExtension" > [01/Apr/2014:21:23:53 +0000] conn=3 op=3 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Apr/2014:21:23:53 +0000] conn=3 op=4 EXT > oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" > [01/Apr/2014:21:23:53 +0000] conn=2 op=8 SRCH > base="cn=meToipa.example.com > ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL > [01/Apr/2014:21:23:53 +0000] conn=2 op=8 RESULT err=32 tag=101 > nentries=0 etime=0 > [01/Apr/2014:21:23:53 +0000] conn=2 op=9 ADD > dn="cn=meToipa.example.com > ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config" > [01/Apr/2014:21:23:53 +0000] conn=3 op=4 RESULT err=0 tag=120 > nentries=0 etime=0 > [01/Apr/2014:21:23:53 +0000] conn=2 op=10 MOD > dn="cn=meToipa.example.com > ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config" > [01/Apr/2014:21:23:53 +0000] conn=2 op=9 RESULT err=0 tag=105 > nentries=0 etime=0 > [01/Apr/2014:21:23:53 +0000] conn=3 op=5 SRCH base="cn=schema" scope=0 > filter="(objectClass=*)" attrs="nsSchemaCSN" > [01/Apr/2014:21:23:53 +0000] conn=2 op=11 SRCH > base="cn=meToipa.example.com > ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL > [01/Apr/2014:21:23:53 +0000] conn=2 op=11 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Apr/2014:21:23:53 +0000] conn=2 op=10 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:53 +0000] conn=3 op=5 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Apr/2014:21:23:53 +0000] conn=3 op=6 MOD dn="cn=schema" > [01/Apr/2014:21:23:53 +0000] conn=3 op=6 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Apr/2014:21:23:53 +0000] conn=3 op=7 EXT > oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End Session" > [01/Apr/2014:21:23:53 +0000] conn=3 op=7 RESULT err=0 tag=120 > nentries=0 etime=0 > [01/Apr/2014:21:23:53 +0000] conn=3 op=8 UNBIND > [01/Apr/2014:21:23:53 +0000] conn=3 op=8 fd=64 closed - U1 > [01/Apr/2014:21:23:53 +0000] conn=4 fd=66 slot=66 connection from > 10.0.3.4 to 10.0.3.15 > [01/Apr/2014:21:23:53 +0000] conn=4 op=0 EXT > oid="1.3.6.1.4.1.1466.20037" name="startTLS" > [01/Apr/2014:21:23:53 +0000] conn=4 op=0 RESULT err=0 tag=120 > nentries=0 etime=0 > [01/Apr/2014:21:23:53 +0000] conn=4 SSL 256-bit AES > [01/Apr/2014:21:23:53 +0000] conn=4 op=1 BIND dn="cn=replication > manager,cn=config" method=128 version=3 > [01/Apr/2014:21:23:53 +0000] conn=4 op=1 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=replication manager,cn=config" > [01/Apr/2014:21:23:53 +0000] conn=4 op=2 SRCH base="" scope=0 > filter="(objectClass=*)" attrs="supportedControl supportedExtension" > [01/Apr/2014:21:23:53 +0000] conn=4 op=2 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Apr/2014:21:23:53 +0000] conn=4 op=3 SRCH base="" scope=0 > filter="(objectClass=*)" attrs="supportedControl supportedExtension" > [01/Apr/2014:21:23:53 +0000] conn=4 op=3 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Apr/2014:21:23:53 +0000] conn=4 op=4 EXT > oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" > [01/Apr/2014:21:23:54 +0000] conn=4 op=4 RESULT err=0 tag=120 > nentries=0 etime=1 > [01/Apr/2014:21:23:54 +0000] conn=4 op=5 SRCH base="cn=schema" scope=0 > filter="(objectClass=*)" attrs="nsSchemaCSN" > [01/Apr/2014:21:23:54 +0000] conn=4 op=5 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Apr/2014:21:23:54 +0000] conn=4 op=6 EXT > oid="2.16.840.1.113730.3.5.6" name="Netscape Replication Total Update > Entry" > . > . > . > [01/Apr/2014:21:23:55 +0000] conn=4 op=458 RESULT err=0 tag=120 > nentries=0 etime=0 > [01/Apr/2014:21:23:57 +0000] conn=4 op=459 EXT > oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End Session" > [01/Apr/2014:21:23:57 +0000] conn=4 op=459 RESULT err=0 tag=120 > nentries=0 etime=0 > [01/Apr/2014:21:23:58 +0000] conn=4 op=460 UNBIND > [01/Apr/2014:21:23:58 +0000] conn=4 op=460 fd=66 closed - U1 > [01/Apr/2014:21:23:58 +0000] conn=5 fd=64 slot=64 connection from > 10.0.3.4 to 10.0.3.15 > [01/Apr/2014:21:23:58 +0000] conn=5 op=0 EXT > oid="1.3.6.1.4.1.1466.20037" name="startTLS" > [01/Apr/2014:21:23:58 +0000] conn=5 op=0 RESULT err=0 tag=120 > nentries=0 etime=0 > [01/Apr/2014:21:23:58 +0000] conn=5 SSL 256-bit AES > [01/Apr/2014:21:23:58 +0000] conn=5 op=1 BIND dn="cn=replication > manager,cn=config" method=128 version=3 > [01/Apr/2014:21:23:58 +0000] conn=5 op=1 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=replication manager,cn=config" > [01/Apr/2014:21:23:58 +0000] conn=5 op=2 SRCH base="" scope=0 > filter="(objectClass=*)" attrs="supportedControl supportedExtension" > [01/Apr/2014:21:23:58 +0000] conn=5 op=2 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Apr/2014:21:23:58 +0000] conn=5 op=3 SRCH base="" scope=0 > filter="(objectClass=*)" attrs="supportedControl supportedExtension" > [01/Apr/2014:21:23:58 +0000] conn=5 op=3 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Apr/2014:21:23:58 +0000] conn=5 op=4 EXT > oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" > [01/Apr/2014:21:23:58 +0000] conn=5 op=4 RESULT err=0 tag=120 > nentries=0 etime=0 > [01/Apr/2014:21:23:58 +0000] conn=5 op=5 SRCH base="cn=schema" scope=0 > filter="(objectClass=*)" attrs="nsSchemaCSN" > [01/Apr/2014:21:23:58 +0000] conn=5 op=5 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Apr/2014:21:23:58 +0000] conn=5 op=6 SRCH > base="cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" > scope=0 filter="(objectClass=*)" attrs="nsDS5ReplicaId" > [01/Apr/2014:21:23:58 +0000] conn=5 op=6 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Apr/2014:21:23:58 +0000] conn=5 op=7 EXT > oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End Session" > [01/Apr/2014:21:23:58 +0000] conn=5 op=7 RESULT err=0 tag=120 > nentries=0 etime=0 > [01/Apr/2014:21:23:59 +0000] conn=2 op=12 UNBIND > [01/Apr/2014:21:23:59 +0000] conn=2 op=12 fd=65 closed - U1 This shows replication is working - that is, this server is able to act as a consumer for replication from 10.0.3.4 > > > > On Tue, Apr 1, 2014 at 5:41 PM, Rob Crittenden > wrote: > > Rich Megginson wrote: > > On 04/01/2014 03:28 PM, Nevada Sanchez wrote: > > Okay, I just tried doing this on a FRESH fedora 19 image > (applied all > updates, installed freeipa, made a new replica file for > the new test > server, and went state to ipa-replica-insntall). Exact > same errors. > Anything else I should try? > > > I don't know. > > Does anyone on the IPA team know what the ipa_lockout errors > are about, > and if they would cause replication not to work? > > > I suspect it is a red herring. The error is not found, so it is > probably that the entry doesn't exist yet. This is replication for > the CA anyway. > > I'd be curious what the access and error logs on the existing side > looks like. It may be an SSL trust problem, for example. > > rob > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Apr 2 15:03:53 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 02 Apr 2014 09:03:53 -0600 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: References: <533AF3D2.5050308@redhat.com> <533B11F6.3040603@redhat.com> <533B300D.6050707@redhat.com> <533B3296.1020409@redhat.com> <533C14BA.1030307@redhat.com> Message-ID: <533C26D9.7060409@redhat.com> On 04/02/2014 08:59 AM, Nevada Sanchez wrote: > That's what it looks like. However, because the installer says it > failed at that step, it doesn't do the rest, so I end up with a > partially configured server (doesn't do any of the IPA things that it > should). Maybe I could get by with a patch that would force it to > continue beyond that step even when it thinks it fails, so I could end > up with a usable server. > > Also, how would I go about checking if there were an SSL problem? I > know, for example, that ldapsearch on using ldaps from each direction > works. From hostA: # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ -h fqdn.of.hostb -s base -b "" 'objectclass=*' vendorVersion > > Thanks! > > > On Wed, Apr 2, 2014 at 9:46 AM, Rich Megginson > wrote: > > On 04/01/2014 07:52 PM, Nevada Sanchez wrote: >> The access log is summed up below. I looked into the ipa_lockout >> errors. They had to do with Kerberos not being set up yet. It >> shouldn't be, I imagine, but I set up the Kerberos conf anyway >> and got that error to go away--it didn't fix anything, >> unfortunately. >> >> ============================================== >> [01/Apr/2014:21:23:29 +0000] conn=1 fd=64 slot=64 connection from >> ::1 to ::1 >> [01/Apr/2014:21:23:29 +0000] conn=1 op=-1 fd=64 closed - B1 >> [01/Apr/2014:21:23:29 +0000] conn=2 fd=64 slot=64 connection from >> 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:29 +0000] conn=2 op=0 BIND dn="cn=directory >> manager" method=128 version=3 >> [01/Apr/2014:21:23:29 +0000] conn=2 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:29 +0000] conn=3 fd=65 slot=65 connection from >> 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:29 +0000] conn=3 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:29 +0000] conn=3 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:29 +0000] conn=3 op=1 MOD dn="cn=MemberOf >> Plugin,cn=plugins,cn=config" >> [01/Apr/2014:21:23:29 +0000] conn=3 op=2 UNBIND >> [01/Apr/2014:21:23:29 +0000] conn=3 op=2 fd=65 closed - U1 >> [01/Apr/2014:21:23:29 +0000] conn=3 op=1 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:29 +0000] conn=4 fd=66 slot=66 connection from >> 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:29 +0000] conn=4 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:29 +0000] conn=4 op=1 ADD >> dn="cn=ipa-winsync,cn=plugins,cn=config" >> [01/Apr/2014:21:23:29 +0000] conn=4 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:29 +0000] conn=4 op=2 UNBIND >> [01/Apr/2014:21:23:29 +0000] conn=4 op=2 fd=66 closed - U1 >> [01/Apr/2014:21:23:29 +0000] conn=4 op=1 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:30 +0000] conn=5 fd=65 slot=65 connection from >> 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:30 +0000] conn=5 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:30 +0000] conn=5 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:30 +0000] conn=5 op=1 ADD dn="cn=IPA Version >> Replication,cn=plugins,cn=config" >> [01/Apr/2014:21:23:30 +0000] conn=5 op=2 UNBIND >> [01/Apr/2014:21:23:30 +0000] conn=5 op=2 fd=65 closed - U1 >> [01/Apr/2014:21:23:30 +0000] conn=5 op=1 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:30 +0000] conn=6 fd=66 slot=66 connection from >> 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:30 +0000] conn=6 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:30 +0000] conn=6 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:30 +0000] conn=6 op=1 ADD >> dn="cn=ipa_enrollment_extop,cn=plugins,cn=config" >> [01/Apr/2014:21:23:30 +0000] conn=6 op=2 UNBIND >> [01/Apr/2014:21:23:30 +0000] conn=6 op=2 fd=66 closed - U1 >> [01/Apr/2014:21:23:30 +0000] conn=6 op=1 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:30 +0000] conn=7 fd=65 slot=65 connection from >> 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:30 +0000] conn=7 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:30 +0000] conn=7 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:30 +0000] conn=7 op=1 MOD dn="cn=config" >> [01/Apr/2014:21:23:30 +0000] conn=7 op=2 UNBIND >> [01/Apr/2014:21:23:30 +0000] conn=7 op=2 fd=65 closed - U1 >> [01/Apr/2014:21:23:30 +0000] conn=7 op=1 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:30 +0000] conn=8 fd=66 slot=66 connection from >> 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:30 +0000] conn=8 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:30 +0000] conn=8 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:30 +0000] conn=8 op=1 ADD >> dn="cn=krbPrincipalName uniqueness,cn=plugins,cn=config" >> [01/Apr/2014:21:23:30 +0000] conn=8 op=2 ADD >> dn="cn=krbCanonicalName uniqueness,cn=plugins,cn=config" >> [01/Apr/2014:21:23:30 +0000] conn=8 op=1 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:30 +0000] conn=8 op=3 ADD dn="cn=netgroup >> uniqueness,cn=plugins,cn=config" >> [01/Apr/2014:21:23:30 +0000] conn=8 op=2 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:30 +0000] conn=8 op=4 ADD dn="cn=ipaUniqueID >> uniqueness,cn=plugins,cn=config" >> [01/Apr/2014:21:23:30 +0000] conn=8 op=3 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:30 +0000] conn=8 op=5 ADD dn="cn=sudorule name >> uniqueness,cn=plugins,cn=config" >> [01/Apr/2014:21:23:30 +0000] conn=8 op=4 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:30 +0000] conn=8 op=5 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:30 +0000] conn=8 op=6 UNBIND >> [01/Apr/2014:21:23:30 +0000] conn=8 op=6 fd=66 closed - U1 >> [01/Apr/2014:21:23:30 +0000] conn=9 fd=65 slot=65 connection from >> 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:30 +0000] conn=9 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:30 +0000] conn=9 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:30 +0000] conn=9 op=1 ADD dn="cn=IPA >> UUID,cn=plugins,cn=config" >> [01/Apr/2014:21:23:30 +0000] conn=9 op=2 UNBIND >> [01/Apr/2014:21:23:30 +0000] conn=9 op=2 fd=65 closed - U1 >> [01/Apr/2014:21:23:30 +0000] conn=9 op=1 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:30 +0000] conn=10 fd=66 slot=66 connection >> from 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:30 +0000] conn=10 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:30 +0000] conn=10 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:30 +0000] conn=10 op=1 ADD dn="cn=IPA Unique >> IDs,cn=IPA UUID,cn=plugins,cn=config" >> [01/Apr/2014:21:23:30 +0000] conn=10 op=2 UNBIND >> [01/Apr/2014:21:23:30 +0000] conn=10 op=2 fd=66 closed - U1 >> [01/Apr/2014:21:23:30 +0000] conn=10 op=1 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:30 +0000] conn=11 fd=65 slot=65 connection >> from 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:30 +0000] conn=11 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:30 +0000] conn=11 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:30 +0000] conn=11 op=1 ADD dn="cn=IPA >> MODRDN,cn=plugins,cn=config" >> [01/Apr/2014:21:23:30 +0000] conn=11 op=2 UNBIND >> [01/Apr/2014:21:23:30 +0000] conn=11 op=2 fd=65 closed - U1 >> [01/Apr/2014:21:23:30 +0000] conn=11 op=1 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:30 +0000] conn=12 fd=66 slot=66 connection >> from 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:30 +0000] conn=12 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:30 +0000] conn=12 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:30 +0000] conn=12 op=1 ADD dn="cn=Kerberos >> Principal Name,cn=IPA MODRDN,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=12 op=2 UNBIND >> [01/Apr/2014:21:23:31 +0000] conn=12 op=2 fd=66 closed - U1 >> [01/Apr/2014:21:23:31 +0000] conn=12 op=1 RESULT err=0 tag=105 >> nentries=0 etime=1 >> [01/Apr/2014:21:23:31 +0000] conn=13 fd=65 slot=65 connection >> from 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:31 +0000] conn=13 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:31 +0000] conn=13 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:31 +0000] conn=13 op=1 ADD dn="cn=IPA >> DNS,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=13 op=2 UNBIND >> [01/Apr/2014:21:23:31 +0000] conn=13 op=2 fd=65 closed - U1 >> [01/Apr/2014:21:23:31 +0000] conn=13 op=1 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=14 fd=66 slot=66 connection >> from 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:31 +0000] conn=14 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:31 +0000] conn=14 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:31 +0000] conn=14 op=1 MOD dn="cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=14 op=2 MOD dn="cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=14 op=1 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=14 op=3 MOD >> dn="cn=USN,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=14 op=2 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=14 op=4 UNBIND >> [01/Apr/2014:21:23:31 +0000] conn=14 op=4 fd=66 closed - U1 >> [01/Apr/2014:21:23:31 +0000] conn=14 op=3 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=15 fd=65 slot=65 connection >> from 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:31 +0000] conn=15 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:31 +0000] conn=15 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:31 +0000] conn=15 op=1 ADD dn="cn=IPA >> Lockout,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=15 op=2 UNBIND >> [01/Apr/2014:21:23:31 +0000] conn=15 op=2 fd=65 closed - U1 >> [01/Apr/2014:21:23:31 +0000] conn=15 op=1 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 fd=66 slot=66 connection >> from 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=1 ADD >> dn="cn=krbPrincipalName,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=2 ADD >> dn="cn=ou,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=1 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=3 ADD >> dn="cn=carLicense,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=2 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=4 ADD >> dn="cn=title,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=3 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=5 ADD >> dn="cn=manager,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=4 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=6 ADD >> dn="cn=secretary,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=7 ADD >> dn="cn=displayname,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=6 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=5 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=8 MOD >> dn="cn=uid,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=9 ADD >> dn="cn=uidnumber,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=8 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=7 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=10 ADD >> dn="cn=gidnumber,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=9 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=11 MOD >> dn="cn=ntUniqueId,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=10 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=12 MOD >> dn="cn=ntUserDomainId,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=11 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=13 ADD >> dn="cn=fqdn,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=12 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=14 ADD >> dn="cn=macAddress,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=15 ADD >> dn="cn=memberHost,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=14 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=13 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=16 ADD >> dn="cn=memberUser,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=15 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=16 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=17 ADD >> dn="cn=sourcehost,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=17 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=18 ADD >> dn="cn=memberservice,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=19 ADD >> dn="cn=managedby,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=18 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=20 ADD >> dn="cn=memberallowcmd,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=19 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=21 ADD >> dn="cn=memberdenycmd,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=21 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=20 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=22 ADD >> dn="cn=ipasudorunas,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=23 ADD >> dn="cn=ipasudorunasgroup,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=22 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=24 ADD >> dn="cn=automountkey,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=24 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=23 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=25 ADD >> dn="cn=ipakrbprincipalalias,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=25 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=26 ADD >> dn="cn=ipauniqueid,cn=index,cn=userRoot,cn=ldbm >> database,cn=plugins,cn=config" >> [01/Apr/2014:21:23:31 +0000] conn=16 op=26 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:31 +0000] conn=16 op=27 UNBIND >> [01/Apr/2014:21:23:31 +0000] conn=16 op=27 fd=66 closed - U1 >> [01/Apr/2014:21:23:31 +0000] conn=17 fd=65 slot=65 connection >> from 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:31 +0000] conn=17 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:31 +0000] conn=17 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:31 +0000] conn=17 op=1 MOD dn="cn=referential >> integrity postoperation,cn=plugins,cn=config" >> [01/Apr/2014:21:23:32 +0000] conn=17 op=2 UNBIND >> [01/Apr/2014:21:23:32 +0000] conn=17 op=2 fd=65 closed - U1 >> [01/Apr/2014:21:23:32 +0000] conn=17 op=1 RESULT err=0 tag=103 >> nentries=0 etime=1 >> [01/Apr/2014:21:23:42 +0000] conn=18 fd=65 slot=65 connection >> from 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:42 +0000] conn=18 op=0 BIND dn="cn=directory >> manager" method=128 version=3 >> [01/Apr/2014:21:23:42 +0000] conn=18 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:42 +0000] conn=18 op=1 MOD >> dn="cn=encryption,cn=config" >> [01/Apr/2014:21:23:42 +0000] conn=18 op=2 MOD dn="cn=config" >> [01/Apr/2014:21:23:42 +0000] conn=18 op=1 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:42 +0000] conn=18 op=3 SRCH base="cn=schema" >> scope=0 filter="(objectClass=*)" attrs="attributeTypes objectClasses" >> [01/Apr/2014:21:23:42 +0000] conn=18 op=2 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:42 +0000] conn=18 op=3 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [01/Apr/2014:21:23:43 +0000] conn=18 op=4 ADD >> dn="cn=RSA,cn=encryption,cn=config" >> [01/Apr/2014:21:23:43 +0000] conn=18 op=5 UNBIND >> [01/Apr/2014:21:23:43 +0000] conn=18 op=5 fd=65 closed - U1 >> [01/Apr/2014:21:23:43 +0000] conn=18 op=4 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:43 +0000] conn=19 fd=66 slot=66 connection >> from 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:43 +0000] conn=19 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:43 +0000] conn=19 op=1 ADD >> dn="cn=root-autobind,cn=config" >> [01/Apr/2014:21:23:43 +0000] conn=19 op=2 MOD dn="cn=config" >> [01/Apr/2014:21:23:43 +0000] conn=19 op=1 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:43 +0000] conn=19 op=3 MOD dn="cn=config" >> [01/Apr/2014:21:23:43 +0000] conn=19 op=2 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:43 +0000] conn=19 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:43 +0000] conn=19 op=4 UNBIND >> [01/Apr/2014:21:23:43 +0000] conn=19 op=4 fd=66 closed - U1 >> [01/Apr/2014:21:23:43 +0000] conn=19 op=3 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:43 +0000] conn=20 fd=65 slot=65 connection >> from 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:43 +0000] conn=20 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:43 +0000] conn=20 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:43 +0000] conn=20 op=1 MOD dn="cn=Managed >> Entries,cn=plugins,cn=config" >> [01/Apr/2014:21:23:43 +0000] conn=20 op=2 UNBIND >> [01/Apr/2014:21:23:43 +0000] conn=20 op=2 fd=65 closed - U1 >> [01/Apr/2014:21:23:43 +0000] conn=20 op=1 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:43 +0000] conn=21 fd=66 slot=66 connection >> from 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:43 +0000] conn=21 op=0 BIND dn="cn=Directory >> Manager" method=128 version=3 >> [01/Apr/2014:21:23:43 +0000] conn=21 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:43 +0000] conn=21 op=1 MOD dn="cn=config" >> [01/Apr/2014:21:23:43 +0000] conn=21 op=2 UNBIND >> [01/Apr/2014:21:23:43 +0000] conn=21 op=2 fd=66 closed - U1 >> [01/Apr/2014:21:23:43 +0000] conn=21 op=1 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:46 +0000] conn=1 fd=64 slot=64 connection from >> ::1 to ::1 >> [01/Apr/2014:21:23:46 +0000] conn=1 op=-1 fd=64 closed - B1 >> [01/Apr/2014:21:23:46 +0000] conn=2 fd=64 slot=64 connection from >> local to /var/run/slapd-EXAMPLE-COM.socket >> [01/Apr/2014:21:23:46 +0000] conn=2 op=0 BIND dn="cn=directory >> manager" method=128 version=3 >> [01/Apr/2014:21:23:46 +0000] conn=2 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:46 +0000] conn=2 op=1 SRCH base="cn=IPA >> Version Replication,cn=plugins,cn=config" scope=0 >> filter="(objectClass=*)" attrs=ALL >> [01/Apr/2014:21:23:46 +0000] conn=2 op=1 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [01/Apr/2014:21:23:46 +0000] conn=2 op=2 SRCH base="cn=schema" >> scope=0 filter="(objectClass=*)" attrs="attributeTypes objectClasses" >> [01/Apr/2014:21:23:46 +0000] conn=2 op=2 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [01/Apr/2014:21:23:47 +0000] conn=2 op=3 MOD dn="cn=IPA Version >> Replication,cn=plugins,cn=config" >> [01/Apr/2014:21:23:47 +0000] conn=2 op=4 UNBIND >> [01/Apr/2014:21:23:47 +0000] conn=2 op=4 fd=64 closed - U1 >> [01/Apr/2014:21:23:47 +0000] conn=2 op=3 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:51 +0000] conn=1 fd=64 slot=64 connection from >> ::1 to ::1 >> [01/Apr/2014:21:23:51 +0000] conn=2 fd=65 slot=65 SSL connection >> from 10.0.3.15 to 10.0.3.15 >> [01/Apr/2014:21:23:51 +0000] conn=1 op=-1 fd=64 closed - B1 >> [01/Apr/2014:21:23:51 +0000] conn=2 SSL 256-bit AES >> [01/Apr/2014:21:23:51 +0000] conn=2 op=0 BIND dn="cn=directory >> manager" method=128 version=3 >> [01/Apr/2014:21:23:51 +0000] conn=2 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [01/Apr/2014:21:23:51 +0000] conn=2 op=1 SRCH >> base="cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL >> [01/Apr/2014:21:23:51 +0000] conn=2 op=1 RESULT err=32 tag=101 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:52 +0000] conn=2 op=2 SRCH base="cn=schema" >> scope=0 filter="(objectClass=*)" attrs="attributeTypes objectClasses" >> [01/Apr/2014:21:23:52 +0000] conn=2 op=2 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [01/Apr/2014:21:23:52 +0000] conn=2 op=3 ADD dn="cn=replication >> manager,cn=config" >> [01/Apr/2014:21:23:52 +0000] conn=2 op=4 SRCH >> base="cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL >> [01/Apr/2014:21:23:52 +0000] conn=2 op=3 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:52 +0000] conn=2 op=4 RESULT err=32 tag=101 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:52 +0000] conn=2 op=5 ADD >> dn="cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" >> [01/Apr/2014:21:23:52 +0000] conn=2 op=6 SRCH >> base="cn=config,cn=ldbm database,cn=plugins,cn=config" scope=0 >> filter="(objectClass=*)" attrs="nsslapd-directory" >> [01/Apr/2014:21:23:52 +0000] conn=2 op=6 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [01/Apr/2014:21:23:52 +0000] conn=2 op=7 ADD >> dn="cn=changelog5,cn=config" >> [01/Apr/2014:21:23:52 +0000] conn=2 op=5 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:52 +0000] conn=2 op=7 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:52 +0000] conn=3 fd=64 slot=64 connection from >> 10.0.3.4 to 10.0.3.15 >> [01/Apr/2014:21:23:52 +0000] conn=3 op=0 EXT >> oid="1.3.6.1.4.1.1466.20037" name="startTLS" >> [01/Apr/2014:21:23:52 +0000] conn=3 op=0 RESULT err=0 tag=120 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:53 +0000] conn=3 SSL 256-bit AES >> [01/Apr/2014:21:23:53 +0000] conn=3 op=1 BIND dn="cn=replication >> manager,cn=config" method=128 version=3 >> [01/Apr/2014:21:23:53 +0000] conn=3 op=1 RESULT err=0 tag=97 >> nentries=0 etime=1 dn="cn=replication manager,cn=config" >> [01/Apr/2014:21:23:53 +0000] conn=3 op=2 SRCH base="" scope=0 >> filter="(objectClass=*)" attrs="supportedControl supportedExtension" >> [01/Apr/2014:21:23:53 +0000] conn=3 op=2 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [01/Apr/2014:21:23:53 +0000] conn=3 op=3 SRCH base="" scope=0 >> filter="(objectClass=*)" attrs="supportedControl supportedExtension" >> [01/Apr/2014:21:23:53 +0000] conn=3 op=3 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [01/Apr/2014:21:23:53 +0000] conn=3 op=4 EXT >> oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" >> [01/Apr/2014:21:23:53 +0000] conn=2 op=8 SRCH >> base="cn=meToipa.example.com >> ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL >> [01/Apr/2014:21:23:53 +0000] conn=2 op=8 RESULT err=32 tag=101 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:53 +0000] conn=2 op=9 ADD >> dn="cn=meToipa.example.com >> ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" >> [01/Apr/2014:21:23:53 +0000] conn=3 op=4 RESULT err=0 tag=120 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:53 +0000] conn=2 op=10 MOD >> dn="cn=meToipa.example.com >> ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" >> [01/Apr/2014:21:23:53 +0000] conn=2 op=9 RESULT err=0 tag=105 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:53 +0000] conn=3 op=5 SRCH base="cn=schema" >> scope=0 filter="(objectClass=*)" attrs="nsSchemaCSN" >> [01/Apr/2014:21:23:53 +0000] conn=2 op=11 SRCH >> base="cn=meToipa.example.com >> ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL >> [01/Apr/2014:21:23:53 +0000] conn=2 op=11 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [01/Apr/2014:21:23:53 +0000] conn=2 op=10 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:53 +0000] conn=3 op=5 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [01/Apr/2014:21:23:53 +0000] conn=3 op=6 MOD dn="cn=schema" >> [01/Apr/2014:21:23:53 +0000] conn=3 op=6 RESULT err=0 tag=103 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:53 +0000] conn=3 op=7 EXT >> oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End Session" >> [01/Apr/2014:21:23:53 +0000] conn=3 op=7 RESULT err=0 tag=120 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:53 +0000] conn=3 op=8 UNBIND >> [01/Apr/2014:21:23:53 +0000] conn=3 op=8 fd=64 closed - U1 >> [01/Apr/2014:21:23:53 +0000] conn=4 fd=66 slot=66 connection from >> 10.0.3.4 to 10.0.3.15 >> [01/Apr/2014:21:23:53 +0000] conn=4 op=0 EXT >> oid="1.3.6.1.4.1.1466.20037" name="startTLS" >> [01/Apr/2014:21:23:53 +0000] conn=4 op=0 RESULT err=0 tag=120 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:53 +0000] conn=4 SSL 256-bit AES >> [01/Apr/2014:21:23:53 +0000] conn=4 op=1 BIND dn="cn=replication >> manager,cn=config" method=128 version=3 >> [01/Apr/2014:21:23:53 +0000] conn=4 op=1 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=replication manager,cn=config" >> [01/Apr/2014:21:23:53 +0000] conn=4 op=2 SRCH base="" scope=0 >> filter="(objectClass=*)" attrs="supportedControl supportedExtension" >> [01/Apr/2014:21:23:53 +0000] conn=4 op=2 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [01/Apr/2014:21:23:53 +0000] conn=4 op=3 SRCH base="" scope=0 >> filter="(objectClass=*)" attrs="supportedControl supportedExtension" >> [01/Apr/2014:21:23:53 +0000] conn=4 op=3 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [01/Apr/2014:21:23:53 +0000] conn=4 op=4 EXT >> oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" >> [01/Apr/2014:21:23:54 +0000] conn=4 op=4 RESULT err=0 tag=120 >> nentries=0 etime=1 >> [01/Apr/2014:21:23:54 +0000] conn=4 op=5 SRCH base="cn=schema" >> scope=0 filter="(objectClass=*)" attrs="nsSchemaCSN" >> [01/Apr/2014:21:23:54 +0000] conn=4 op=5 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [01/Apr/2014:21:23:54 +0000] conn=4 op=6 EXT >> oid="2.16.840.1.113730.3.5.6" name="Netscape Replication Total >> Update Entry" >> . >> . >> . >> [01/Apr/2014:21:23:55 +0000] conn=4 op=458 RESULT err=0 tag=120 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:57 +0000] conn=4 op=459 EXT >> oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End Session" >> [01/Apr/2014:21:23:57 +0000] conn=4 op=459 RESULT err=0 tag=120 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:58 +0000] conn=4 op=460 UNBIND >> [01/Apr/2014:21:23:58 +0000] conn=4 op=460 fd=66 closed - U1 >> [01/Apr/2014:21:23:58 +0000] conn=5 fd=64 slot=64 connection from >> 10.0.3.4 to 10.0.3.15 >> [01/Apr/2014:21:23:58 +0000] conn=5 op=0 EXT >> oid="1.3.6.1.4.1.1466.20037" name="startTLS" >> [01/Apr/2014:21:23:58 +0000] conn=5 op=0 RESULT err=0 tag=120 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:58 +0000] conn=5 SSL 256-bit AES >> [01/Apr/2014:21:23:58 +0000] conn=5 op=1 BIND dn="cn=replication >> manager,cn=config" method=128 version=3 >> [01/Apr/2014:21:23:58 +0000] conn=5 op=1 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=replication manager,cn=config" >> [01/Apr/2014:21:23:58 +0000] conn=5 op=2 SRCH base="" scope=0 >> filter="(objectClass=*)" attrs="supportedControl supportedExtension" >> [01/Apr/2014:21:23:58 +0000] conn=5 op=2 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [01/Apr/2014:21:23:58 +0000] conn=5 op=3 SRCH base="" scope=0 >> filter="(objectClass=*)" attrs="supportedControl supportedExtension" >> [01/Apr/2014:21:23:58 +0000] conn=5 op=3 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [01/Apr/2014:21:23:58 +0000] conn=5 op=4 EXT >> oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" >> [01/Apr/2014:21:23:58 +0000] conn=5 op=4 RESULT err=0 tag=120 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:58 +0000] conn=5 op=5 SRCH base="cn=schema" >> scope=0 filter="(objectClass=*)" attrs="nsSchemaCSN" >> [01/Apr/2014:21:23:58 +0000] conn=5 op=5 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [01/Apr/2014:21:23:58 +0000] conn=5 op=6 SRCH >> base="cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" scope=0 filter="(objectClass=*)" >> attrs="nsDS5ReplicaId" >> [01/Apr/2014:21:23:58 +0000] conn=5 op=6 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [01/Apr/2014:21:23:58 +0000] conn=5 op=7 EXT >> oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End Session" >> [01/Apr/2014:21:23:58 +0000] conn=5 op=7 RESULT err=0 tag=120 >> nentries=0 etime=0 >> [01/Apr/2014:21:23:59 +0000] conn=2 op=12 UNBIND >> [01/Apr/2014:21:23:59 +0000] conn=2 op=12 fd=65 closed - U1 > > This shows replication is working - that is, this server is able > to act as a consumer for replication from 10.0.3.4 > > >> >> >> >> On Tue, Apr 1, 2014 at 5:41 PM, Rob Crittenden >> > wrote: >> >> Rich Megginson wrote: >> >> On 04/01/2014 03:28 PM, Nevada Sanchez wrote: >> >> Okay, I just tried doing this on a FRESH fedora 19 >> image (applied all >> updates, installed freeipa, made a new replica file >> for the new test >> server, and went state to ipa-replica-insntall). >> Exact same errors. >> Anything else I should try? >> >> >> I don't know. >> >> Does anyone on the IPA team know what the ipa_lockout >> errors are about, >> and if they would cause replication not to work? >> >> >> I suspect it is a red herring. The error is not found, so it >> is probably that the entry doesn't exist yet. This is >> replication for the CA anyway. >> >> I'd be curious what the access and error logs on the existing >> side looks like. It may be an SSL trust problem, for example. >> >> rob >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Apr 2 15:41:47 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 02 Apr 2014 09:41:47 -0600 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: References: <533AF3D2.5050308@redhat.com> <533B11F6.3040603@redhat.com> <533B300D.6050707@redhat.com> <533B3296.1020409@redhat.com> <533C14BA.1030307@redhat.com> <533C26D9.7060409@redhat.com> Message-ID: <533C2FBB.1020601@redhat.com> On 04/02/2014 09:20 AM, Nevada Sanchez wrote: > Okay, we might be on to something: > > ipa -> ipa2 > ================================ > $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ > -h ipa2.example.com -s base -b "" > 'objectclass=*' vendorVersion > dn: > vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 > ================================ > > ipa2 -> ipa > ================================ > $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ > -h ipa.example.com -s base -b "" > 'objectclass=*' vendorVersion > ldap_start_tls: Connect error (-11) > additional info: TLS error -8172:Peer's certificate issuer has been > marked as not trusted by the user. > ================================ > > The original IPA trusts the replica (since it signed the cert, I > assume), but the replica doesn't trust the main IPA server. I guess > the ZZ option would have shown me the failure that I missed in my > initial ldapsearch tests. -Z[Z] Issue StartTLS (Transport Layer Security) extended operation. If you use -ZZ, the command will require the operation to be suc- cessful. i.e. use SSL, and force a successful handshake > > Anyway, what's the best way to remedy this in a way that makes IPA > happy? (I've found that LDAP can have different requirements on which > certs go where). I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install is supposed to take care of installing the CA cert properly for you. If you try to hack it and install the CA cert manually, you will probably miss something else that ipa install did not do. I think the only way to ensure that you have a properly configured ipa server + replicas is to get all of the ipa commands completing successfully. Which means going back to the drawing board and starting over from scratch. > > > On Wed, Apr 2, 2014 at 11:03 AM, Rich Megginson > wrote: > > On 04/02/2014 08:59 AM, Nevada Sanchez wrote: >> That's what it looks like. However, because the installer says it >> failed at that step, it doesn't do the rest, so I end up with a >> partially configured server (doesn't do any of the IPA things >> that it should). Maybe I could get by with a patch that would >> force it to continue beyond that step even when it thinks it >> fails, so I could end up with a usable server. >> >> Also, how would I go about checking if there were an SSL problem? >> I know, for example, that ldapsearch on using ldaps from each >> direction works. > > From hostA: > > # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch > -xLLLZZ -h fqdn.of.hostb -s base -b "" 'objectclass=*' vendorVersion > > > > >> >> Thanks! >> >> >> On Wed, Apr 2, 2014 at 9:46 AM, Rich Megginson >> > wrote: >> >> On 04/01/2014 07:52 PM, Nevada Sanchez wrote: >>> The access log is summed up below. I looked into the >>> ipa_lockout errors. They had to do with Kerberos not being >>> set up yet. It shouldn't be, I imagine, but I set up the >>> Kerberos conf anyway and got that error to go away--it >>> didn't fix anything, unfortunately. >>> >>> ============================================== >>> [01/Apr/2014:21:23:29 +0000] conn=1 fd=64 slot=64 connection >>> from ::1 to ::1 >>> [01/Apr/2014:21:23:29 +0000] conn=1 op=-1 fd=64 closed - B1 >>> [01/Apr/2014:21:23:29 +0000] conn=2 fd=64 slot=64 connection >>> from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:29 +0000] conn=2 op=0 BIND >>> dn="cn=directory manager" method=128 version=3 >>> [01/Apr/2014:21:23:29 +0000] conn=2 op=0 RESULT err=0 tag=97 >>> nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:29 +0000] conn=3 fd=65 slot=65 connection >>> from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:29 +0000] conn=3 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:29 +0000] conn=3 op=0 RESULT err=0 tag=97 >>> nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:29 +0000] conn=3 op=1 MOD dn="cn=MemberOf >>> Plugin,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:29 +0000] conn=3 op=2 UNBIND >>> [01/Apr/2014:21:23:29 +0000] conn=3 op=2 fd=65 closed - U1 >>> [01/Apr/2014:21:23:29 +0000] conn=3 op=1 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:29 +0000] conn=4 fd=66 slot=66 connection >>> from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:29 +0000] conn=4 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:29 +0000] conn=4 op=1 ADD >>> dn="cn=ipa-winsync,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:29 +0000] conn=4 op=0 RESULT err=0 tag=97 >>> nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:29 +0000] conn=4 op=2 UNBIND >>> [01/Apr/2014:21:23:29 +0000] conn=4 op=2 fd=66 closed - U1 >>> [01/Apr/2014:21:23:29 +0000] conn=4 op=1 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:30 +0000] conn=5 fd=65 slot=65 connection >>> from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:30 +0000] conn=5 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:30 +0000] conn=5 op=0 RESULT err=0 tag=97 >>> nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:30 +0000] conn=5 op=1 ADD dn="cn=IPA >>> Version Replication,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:30 +0000] conn=5 op=2 UNBIND >>> [01/Apr/2014:21:23:30 +0000] conn=5 op=2 fd=65 closed - U1 >>> [01/Apr/2014:21:23:30 +0000] conn=5 op=1 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:30 +0000] conn=6 fd=66 slot=66 connection >>> from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:30 +0000] conn=6 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:30 +0000] conn=6 op=0 RESULT err=0 tag=97 >>> nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:30 +0000] conn=6 op=1 ADD >>> dn="cn=ipa_enrollment_extop,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:30 +0000] conn=6 op=2 UNBIND >>> [01/Apr/2014:21:23:30 +0000] conn=6 op=2 fd=66 closed - U1 >>> [01/Apr/2014:21:23:30 +0000] conn=6 op=1 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:30 +0000] conn=7 fd=65 slot=65 connection >>> from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:30 +0000] conn=7 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:30 +0000] conn=7 op=0 RESULT err=0 tag=97 >>> nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:30 +0000] conn=7 op=1 MOD dn="cn=config" >>> [01/Apr/2014:21:23:30 +0000] conn=7 op=2 UNBIND >>> [01/Apr/2014:21:23:30 +0000] conn=7 op=2 fd=65 closed - U1 >>> [01/Apr/2014:21:23:30 +0000] conn=7 op=1 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:30 +0000] conn=8 fd=66 slot=66 connection >>> from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:30 +0000] conn=8 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:30 +0000] conn=8 op=0 RESULT err=0 tag=97 >>> nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:30 +0000] conn=8 op=1 ADD >>> dn="cn=krbPrincipalName uniqueness,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:30 +0000] conn=8 op=2 ADD >>> dn="cn=krbCanonicalName uniqueness,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:30 +0000] conn=8 op=1 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:30 +0000] conn=8 op=3 ADD dn="cn=netgroup >>> uniqueness,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:30 +0000] conn=8 op=2 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:30 +0000] conn=8 op=4 ADD >>> dn="cn=ipaUniqueID uniqueness,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:30 +0000] conn=8 op=3 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:30 +0000] conn=8 op=5 ADD dn="cn=sudorule >>> name uniqueness,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:30 +0000] conn=8 op=4 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:30 +0000] conn=8 op=5 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:30 +0000] conn=8 op=6 UNBIND >>> [01/Apr/2014:21:23:30 +0000] conn=8 op=6 fd=66 closed - U1 >>> [01/Apr/2014:21:23:30 +0000] conn=9 fd=65 slot=65 connection >>> from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:30 +0000] conn=9 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:30 +0000] conn=9 op=0 RESULT err=0 tag=97 >>> nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:30 +0000] conn=9 op=1 ADD dn="cn=IPA >>> UUID,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:30 +0000] conn=9 op=2 UNBIND >>> [01/Apr/2014:21:23:30 +0000] conn=9 op=2 fd=65 closed - U1 >>> [01/Apr/2014:21:23:30 +0000] conn=9 op=1 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:30 +0000] conn=10 fd=66 slot=66 >>> connection from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:30 +0000] conn=10 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:30 +0000] conn=10 op=0 RESULT err=0 >>> tag=97 nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:30 +0000] conn=10 op=1 ADD dn="cn=IPA >>> Unique IDs,cn=IPA UUID,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:30 +0000] conn=10 op=2 UNBIND >>> [01/Apr/2014:21:23:30 +0000] conn=10 op=2 fd=66 closed - U1 >>> [01/Apr/2014:21:23:30 +0000] conn=10 op=1 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:30 +0000] conn=11 fd=65 slot=65 >>> connection from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:30 +0000] conn=11 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:30 +0000] conn=11 op=0 RESULT err=0 >>> tag=97 nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:30 +0000] conn=11 op=1 ADD dn="cn=IPA >>> MODRDN,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:30 +0000] conn=11 op=2 UNBIND >>> [01/Apr/2014:21:23:30 +0000] conn=11 op=2 fd=65 closed - U1 >>> [01/Apr/2014:21:23:30 +0000] conn=11 op=1 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:30 +0000] conn=12 fd=66 slot=66 >>> connection from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:30 +0000] conn=12 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:30 +0000] conn=12 op=0 RESULT err=0 >>> tag=97 nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:30 +0000] conn=12 op=1 ADD >>> dn="cn=Kerberos Principal Name,cn=IPA >>> MODRDN,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=12 op=2 UNBIND >>> [01/Apr/2014:21:23:31 +0000] conn=12 op=2 fd=66 closed - U1 >>> [01/Apr/2014:21:23:31 +0000] conn=12 op=1 RESULT err=0 >>> tag=105 nentries=0 etime=1 >>> [01/Apr/2014:21:23:31 +0000] conn=13 fd=65 slot=65 >>> connection from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:31 +0000] conn=13 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:31 +0000] conn=13 op=0 RESULT err=0 >>> tag=97 nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:31 +0000] conn=13 op=1 ADD dn="cn=IPA >>> DNS,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=13 op=2 UNBIND >>> [01/Apr/2014:21:23:31 +0000] conn=13 op=2 fd=65 closed - U1 >>> [01/Apr/2014:21:23:31 +0000] conn=13 op=1 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=14 fd=66 slot=66 >>> connection from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:31 +0000] conn=14 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:31 +0000] conn=14 op=0 RESULT err=0 >>> tag=97 nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:31 +0000] conn=14 op=1 MOD dn="cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=14 op=2 MOD dn="cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=14 op=1 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=14 op=3 MOD >>> dn="cn=USN,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=14 op=2 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=14 op=4 UNBIND >>> [01/Apr/2014:21:23:31 +0000] conn=14 op=4 fd=66 closed - U1 >>> [01/Apr/2014:21:23:31 +0000] conn=14 op=3 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=15 fd=65 slot=65 >>> connection from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:31 +0000] conn=15 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:31 +0000] conn=15 op=0 RESULT err=0 >>> tag=97 nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:31 +0000] conn=15 op=1 ADD dn="cn=IPA >>> Lockout,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=15 op=2 UNBIND >>> [01/Apr/2014:21:23:31 +0000] conn=15 op=2 fd=65 closed - U1 >>> [01/Apr/2014:21:23:31 +0000] conn=15 op=1 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 fd=66 slot=66 >>> connection from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=0 RESULT err=0 >>> tag=97 nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=1 ADD >>> dn="cn=krbPrincipalName,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=2 ADD >>> dn="cn=ou,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=1 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=3 ADD >>> dn="cn=carLicense,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=2 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=4 ADD >>> dn="cn=title,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=3 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=5 ADD >>> dn="cn=manager,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=4 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=6 ADD >>> dn="cn=secretary,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=7 ADD >>> dn="cn=displayname,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=6 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=5 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=8 MOD >>> dn="cn=uid,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=9 ADD >>> dn="cn=uidnumber,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=8 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=7 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=10 ADD >>> dn="cn=gidnumber,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=9 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=11 MOD >>> dn="cn=ntUniqueId,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=10 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=12 MOD >>> dn="cn=ntUserDomainId,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=11 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=13 ADD >>> dn="cn=fqdn,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=12 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=14 ADD >>> dn="cn=macAddress,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=15 ADD >>> dn="cn=memberHost,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=14 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=13 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=16 ADD >>> dn="cn=memberUser,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=15 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=16 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=17 ADD >>> dn="cn=sourcehost,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=17 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=18 ADD >>> dn="cn=memberservice,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=19 ADD >>> dn="cn=managedby,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=18 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=20 ADD >>> dn="cn=memberallowcmd,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=19 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=21 ADD >>> dn="cn=memberdenycmd,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=21 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=20 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=22 ADD >>> dn="cn=ipasudorunas,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=23 ADD >>> dn="cn=ipasudorunasgroup,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=22 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=24 ADD >>> dn="cn=automountkey,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=24 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=23 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=25 ADD >>> dn="cn=ipakrbprincipalalias,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=25 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=26 ADD >>> dn="cn=ipauniqueid,cn=index,cn=userRoot,cn=ldbm >>> database,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=26 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=27 UNBIND >>> [01/Apr/2014:21:23:31 +0000] conn=16 op=27 fd=66 closed - U1 >>> [01/Apr/2014:21:23:31 +0000] conn=17 fd=65 slot=65 >>> connection from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:31 +0000] conn=17 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:31 +0000] conn=17 op=0 RESULT err=0 >>> tag=97 nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:31 +0000] conn=17 op=1 MOD >>> dn="cn=referential integrity postoperation,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:32 +0000] conn=17 op=2 UNBIND >>> [01/Apr/2014:21:23:32 +0000] conn=17 op=2 fd=65 closed - U1 >>> [01/Apr/2014:21:23:32 +0000] conn=17 op=1 RESULT err=0 >>> tag=103 nentries=0 etime=1 >>> [01/Apr/2014:21:23:42 +0000] conn=18 fd=65 slot=65 >>> connection from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:42 +0000] conn=18 op=0 BIND >>> dn="cn=directory manager" method=128 version=3 >>> [01/Apr/2014:21:23:42 +0000] conn=18 op=0 RESULT err=0 >>> tag=97 nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:42 +0000] conn=18 op=1 MOD >>> dn="cn=encryption,cn=config" >>> [01/Apr/2014:21:23:42 +0000] conn=18 op=2 MOD dn="cn=config" >>> [01/Apr/2014:21:23:42 +0000] conn=18 op=1 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:42 +0000] conn=18 op=3 SRCH >>> base="cn=schema" scope=0 filter="(objectClass=*)" >>> attrs="attributeTypes objectClasses" >>> [01/Apr/2014:21:23:42 +0000] conn=18 op=2 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:42 +0000] conn=18 op=3 RESULT err=0 >>> tag=101 nentries=1 etime=0 >>> [01/Apr/2014:21:23:43 +0000] conn=18 op=4 ADD >>> dn="cn=RSA,cn=encryption,cn=config" >>> [01/Apr/2014:21:23:43 +0000] conn=18 op=5 UNBIND >>> [01/Apr/2014:21:23:43 +0000] conn=18 op=5 fd=65 closed - U1 >>> [01/Apr/2014:21:23:43 +0000] conn=18 op=4 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:43 +0000] conn=19 fd=66 slot=66 >>> connection from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:43 +0000] conn=19 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:43 +0000] conn=19 op=1 ADD >>> dn="cn=root-autobind,cn=config" >>> [01/Apr/2014:21:23:43 +0000] conn=19 op=2 MOD dn="cn=config" >>> [01/Apr/2014:21:23:43 +0000] conn=19 op=1 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:43 +0000] conn=19 op=3 MOD dn="cn=config" >>> [01/Apr/2014:21:23:43 +0000] conn=19 op=2 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:43 +0000] conn=19 op=0 RESULT err=0 >>> tag=97 nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:43 +0000] conn=19 op=4 UNBIND >>> [01/Apr/2014:21:23:43 +0000] conn=19 op=4 fd=66 closed - U1 >>> [01/Apr/2014:21:23:43 +0000] conn=19 op=3 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:43 +0000] conn=20 fd=65 slot=65 >>> connection from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:43 +0000] conn=20 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:43 +0000] conn=20 op=0 RESULT err=0 >>> tag=97 nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:43 +0000] conn=20 op=1 MOD dn="cn=Managed >>> Entries,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:43 +0000] conn=20 op=2 UNBIND >>> [01/Apr/2014:21:23:43 +0000] conn=20 op=2 fd=65 closed - U1 >>> [01/Apr/2014:21:23:43 +0000] conn=20 op=1 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:43 +0000] conn=21 fd=66 slot=66 >>> connection from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:43 +0000] conn=21 op=0 BIND >>> dn="cn=Directory Manager" method=128 version=3 >>> [01/Apr/2014:21:23:43 +0000] conn=21 op=0 RESULT err=0 >>> tag=97 nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:43 +0000] conn=21 op=1 MOD dn="cn=config" >>> [01/Apr/2014:21:23:43 +0000] conn=21 op=2 UNBIND >>> [01/Apr/2014:21:23:43 +0000] conn=21 op=2 fd=66 closed - U1 >>> [01/Apr/2014:21:23:43 +0000] conn=21 op=1 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:46 +0000] conn=1 fd=64 slot=64 connection >>> from ::1 to ::1 >>> [01/Apr/2014:21:23:46 +0000] conn=1 op=-1 fd=64 closed - B1 >>> [01/Apr/2014:21:23:46 +0000] conn=2 fd=64 slot=64 connection >>> from local to /var/run/slapd-EXAMPLE-COM.socket >>> [01/Apr/2014:21:23:46 +0000] conn=2 op=0 BIND >>> dn="cn=directory manager" method=128 version=3 >>> [01/Apr/2014:21:23:46 +0000] conn=2 op=0 RESULT err=0 tag=97 >>> nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:46 +0000] conn=2 op=1 SRCH base="cn=IPA >>> Version Replication,cn=plugins,cn=config" scope=0 >>> filter="(objectClass=*)" attrs=ALL >>> [01/Apr/2014:21:23:46 +0000] conn=2 op=1 RESULT err=0 >>> tag=101 nentries=1 etime=0 >>> [01/Apr/2014:21:23:46 +0000] conn=2 op=2 SRCH >>> base="cn=schema" scope=0 filter="(objectClass=*)" >>> attrs="attributeTypes objectClasses" >>> [01/Apr/2014:21:23:46 +0000] conn=2 op=2 RESULT err=0 >>> tag=101 nentries=1 etime=0 >>> [01/Apr/2014:21:23:47 +0000] conn=2 op=3 MOD dn="cn=IPA >>> Version Replication,cn=plugins,cn=config" >>> [01/Apr/2014:21:23:47 +0000] conn=2 op=4 UNBIND >>> [01/Apr/2014:21:23:47 +0000] conn=2 op=4 fd=64 closed - U1 >>> [01/Apr/2014:21:23:47 +0000] conn=2 op=3 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:51 +0000] conn=1 fd=64 slot=64 connection >>> from ::1 to ::1 >>> [01/Apr/2014:21:23:51 +0000] conn=2 fd=65 slot=65 SSL >>> connection from 10.0.3.15 to 10.0.3.15 >>> [01/Apr/2014:21:23:51 +0000] conn=1 op=-1 fd=64 closed - B1 >>> [01/Apr/2014:21:23:51 +0000] conn=2 SSL 256-bit AES >>> [01/Apr/2014:21:23:51 +0000] conn=2 op=0 BIND >>> dn="cn=directory manager" method=128 version=3 >>> [01/Apr/2014:21:23:51 +0000] conn=2 op=0 RESULT err=0 tag=97 >>> nentries=0 etime=0 dn="cn=directory manager" >>> [01/Apr/2014:21:23:51 +0000] conn=2 op=1 SRCH >>> base="cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >>> tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL >>> [01/Apr/2014:21:23:51 +0000] conn=2 op=1 RESULT err=32 >>> tag=101 nentries=0 etime=0 >>> [01/Apr/2014:21:23:52 +0000] conn=2 op=2 SRCH >>> base="cn=schema" scope=0 filter="(objectClass=*)" >>> attrs="attributeTypes objectClasses" >>> [01/Apr/2014:21:23:52 +0000] conn=2 op=2 RESULT err=0 >>> tag=101 nentries=1 etime=0 >>> [01/Apr/2014:21:23:52 +0000] conn=2 op=3 ADD >>> dn="cn=replication manager,cn=config" >>> [01/Apr/2014:21:23:52 +0000] conn=2 op=4 SRCH >>> base="cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >>> tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL >>> [01/Apr/2014:21:23:52 +0000] conn=2 op=3 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:52 +0000] conn=2 op=4 RESULT err=32 >>> tag=101 nentries=0 etime=0 >>> [01/Apr/2014:21:23:52 +0000] conn=2 op=5 ADD >>> dn="cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >>> tree,cn=config" >>> [01/Apr/2014:21:23:52 +0000] conn=2 op=6 SRCH >>> base="cn=config,cn=ldbm database,cn=plugins,cn=config" >>> scope=0 filter="(objectClass=*)" attrs="nsslapd-directory" >>> [01/Apr/2014:21:23:52 +0000] conn=2 op=6 RESULT err=0 >>> tag=101 nentries=1 etime=0 >>> [01/Apr/2014:21:23:52 +0000] conn=2 op=7 ADD >>> dn="cn=changelog5,cn=config" >>> [01/Apr/2014:21:23:52 +0000] conn=2 op=5 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:52 +0000] conn=2 op=7 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:52 +0000] conn=3 fd=64 slot=64 connection >>> from 10.0.3.4 to 10.0.3.15 >>> [01/Apr/2014:21:23:52 +0000] conn=3 op=0 EXT >>> oid="1.3.6.1.4.1.1466.20037" name="startTLS" >>> [01/Apr/2014:21:23:52 +0000] conn=3 op=0 RESULT err=0 >>> tag=120 nentries=0 etime=0 >>> [01/Apr/2014:21:23:53 +0000] conn=3 SSL 256-bit AES >>> [01/Apr/2014:21:23:53 +0000] conn=3 op=1 BIND >>> dn="cn=replication manager,cn=config" method=128 version=3 >>> [01/Apr/2014:21:23:53 +0000] conn=3 op=1 RESULT err=0 tag=97 >>> nentries=0 etime=1 dn="cn=replication manager,cn=config" >>> [01/Apr/2014:21:23:53 +0000] conn=3 op=2 SRCH base="" >>> scope=0 filter="(objectClass=*)" attrs="supportedControl >>> supportedExtension" >>> [01/Apr/2014:21:23:53 +0000] conn=3 op=2 RESULT err=0 >>> tag=101 nentries=1 etime=0 >>> [01/Apr/2014:21:23:53 +0000] conn=3 op=3 SRCH base="" >>> scope=0 filter="(objectClass=*)" attrs="supportedControl >>> supportedExtension" >>> [01/Apr/2014:21:23:53 +0000] conn=3 op=3 RESULT err=0 >>> tag=101 nentries=1 etime=0 >>> [01/Apr/2014:21:23:53 +0000] conn=3 op=4 EXT >>> oid="2.16.840.1.113730.3.5.12" >>> name="replication-multimaster-extop" >>> [01/Apr/2014:21:23:53 +0000] conn=2 op=8 SRCH >>> base="cn=meToipa.example.com >>> ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >>> tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL >>> [01/Apr/2014:21:23:53 +0000] conn=2 op=8 RESULT err=32 >>> tag=101 nentries=0 etime=0 >>> [01/Apr/2014:21:23:53 +0000] conn=2 op=9 ADD >>> dn="cn=meToipa.example.com >>> ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >>> tree,cn=config" >>> [01/Apr/2014:21:23:53 +0000] conn=3 op=4 RESULT err=0 >>> tag=120 nentries=0 etime=0 >>> [01/Apr/2014:21:23:53 +0000] conn=2 op=10 MOD >>> dn="cn=meToipa.example.com >>> ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >>> tree,cn=config" >>> [01/Apr/2014:21:23:53 +0000] conn=2 op=9 RESULT err=0 >>> tag=105 nentries=0 etime=0 >>> [01/Apr/2014:21:23:53 +0000] conn=3 op=5 SRCH >>> base="cn=schema" scope=0 filter="(objectClass=*)" >>> attrs="nsSchemaCSN" >>> [01/Apr/2014:21:23:53 +0000] conn=2 op=11 SRCH >>> base="cn=meToipa.example.com >>> ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >>> tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL >>> [01/Apr/2014:21:23:53 +0000] conn=2 op=11 RESULT err=0 >>> tag=101 nentries=1 etime=0 >>> [01/Apr/2014:21:23:53 +0000] conn=2 op=10 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:53 +0000] conn=3 op=5 RESULT err=0 >>> tag=101 nentries=1 etime=0 >>> [01/Apr/2014:21:23:53 +0000] conn=3 op=6 MOD dn="cn=schema" >>> [01/Apr/2014:21:23:53 +0000] conn=3 op=6 RESULT err=0 >>> tag=103 nentries=0 etime=0 >>> [01/Apr/2014:21:23:53 +0000] conn=3 op=7 EXT >>> oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End >>> Session" >>> [01/Apr/2014:21:23:53 +0000] conn=3 op=7 RESULT err=0 >>> tag=120 nentries=0 etime=0 >>> [01/Apr/2014:21:23:53 +0000] conn=3 op=8 UNBIND >>> [01/Apr/2014:21:23:53 +0000] conn=3 op=8 fd=64 closed - U1 >>> [01/Apr/2014:21:23:53 +0000] conn=4 fd=66 slot=66 connection >>> from 10.0.3.4 to 10.0.3.15 >>> [01/Apr/2014:21:23:53 +0000] conn=4 op=0 EXT >>> oid="1.3.6.1.4.1.1466.20037" name="startTLS" >>> [01/Apr/2014:21:23:53 +0000] conn=4 op=0 RESULT err=0 >>> tag=120 nentries=0 etime=0 >>> [01/Apr/2014:21:23:53 +0000] conn=4 SSL 256-bit AES >>> [01/Apr/2014:21:23:53 +0000] conn=4 op=1 BIND >>> dn="cn=replication manager,cn=config" method=128 version=3 >>> [01/Apr/2014:21:23:53 +0000] conn=4 op=1 RESULT err=0 tag=97 >>> nentries=0 etime=0 dn="cn=replication manager,cn=config" >>> [01/Apr/2014:21:23:53 +0000] conn=4 op=2 SRCH base="" >>> scope=0 filter="(objectClass=*)" attrs="supportedControl >>> supportedExtension" >>> [01/Apr/2014:21:23:53 +0000] conn=4 op=2 RESULT err=0 >>> tag=101 nentries=1 etime=0 >>> [01/Apr/2014:21:23:53 +0000] conn=4 op=3 SRCH base="" >>> scope=0 filter="(objectClass=*)" attrs="supportedControl >>> supportedExtension" >>> [01/Apr/2014:21:23:53 +0000] conn=4 op=3 RESULT err=0 >>> tag=101 nentries=1 etime=0 >>> [01/Apr/2014:21:23:53 +0000] conn=4 op=4 EXT >>> oid="2.16.840.1.113730.3.5.12" >>> name="replication-multimaster-extop" >>> [01/Apr/2014:21:23:54 +0000] conn=4 op=4 RESULT err=0 >>> tag=120 nentries=0 etime=1 >>> [01/Apr/2014:21:23:54 +0000] conn=4 op=5 SRCH >>> base="cn=schema" scope=0 filter="(objectClass=*)" >>> attrs="nsSchemaCSN" >>> [01/Apr/2014:21:23:54 +0000] conn=4 op=5 RESULT err=0 >>> tag=101 nentries=1 etime=0 >>> [01/Apr/2014:21:23:54 +0000] conn=4 op=6 EXT >>> oid="2.16.840.1.113730.3.5.6" name="Netscape Replication >>> Total Update Entry" >>> . >>> . >>> . >>> [01/Apr/2014:21:23:55 +0000] conn=4 op=458 RESULT err=0 >>> tag=120 nentries=0 etime=0 >>> [01/Apr/2014:21:23:57 +0000] conn=4 op=459 EXT >>> oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End >>> Session" >>> [01/Apr/2014:21:23:57 +0000] conn=4 op=459 RESULT err=0 >>> tag=120 nentries=0 etime=0 >>> [01/Apr/2014:21:23:58 +0000] conn=4 op=460 UNBIND >>> [01/Apr/2014:21:23:58 +0000] conn=4 op=460 fd=66 closed - U1 >>> [01/Apr/2014:21:23:58 +0000] conn=5 fd=64 slot=64 connection >>> from 10.0.3.4 to 10.0.3.15 >>> [01/Apr/2014:21:23:58 +0000] conn=5 op=0 EXT >>> oid="1.3.6.1.4.1.1466.20037" name="startTLS" >>> [01/Apr/2014:21:23:58 +0000] conn=5 op=0 RESULT err=0 >>> tag=120 nentries=0 etime=0 >>> [01/Apr/2014:21:23:58 +0000] conn=5 SSL 256-bit AES >>> [01/Apr/2014:21:23:58 +0000] conn=5 op=1 BIND >>> dn="cn=replication manager,cn=config" method=128 version=3 >>> [01/Apr/2014:21:23:58 +0000] conn=5 op=1 RESULT err=0 tag=97 >>> nentries=0 etime=0 dn="cn=replication manager,cn=config" >>> [01/Apr/2014:21:23:58 +0000] conn=5 op=2 SRCH base="" >>> scope=0 filter="(objectClass=*)" attrs="supportedControl >>> supportedExtension" >>> [01/Apr/2014:21:23:58 +0000] conn=5 op=2 RESULT err=0 >>> tag=101 nentries=1 etime=0 >>> [01/Apr/2014:21:23:58 +0000] conn=5 op=3 SRCH base="" >>> scope=0 filter="(objectClass=*)" attrs="supportedControl >>> supportedExtension" >>> [01/Apr/2014:21:23:58 +0000] conn=5 op=3 RESULT err=0 >>> tag=101 nentries=1 etime=0 >>> [01/Apr/2014:21:23:58 +0000] conn=5 op=4 EXT >>> oid="2.16.840.1.113730.3.5.12" >>> name="replication-multimaster-extop" >>> [01/Apr/2014:21:23:58 +0000] conn=5 op=4 RESULT err=0 >>> tag=120 nentries=0 etime=0 >>> [01/Apr/2014:21:23:58 +0000] conn=5 op=5 SRCH >>> base="cn=schema" scope=0 filter="(objectClass=*)" >>> attrs="nsSchemaCSN" >>> [01/Apr/2014:21:23:58 +0000] conn=5 op=5 RESULT err=0 >>> tag=101 nentries=1 etime=0 >>> [01/Apr/2014:21:23:58 +0000] conn=5 op=6 SRCH >>> base="cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >>> tree,cn=config" scope=0 filter="(objectClass=*)" >>> attrs="nsDS5ReplicaId" >>> [01/Apr/2014:21:23:58 +0000] conn=5 op=6 RESULT err=0 >>> tag=101 nentries=1 etime=0 >>> [01/Apr/2014:21:23:58 +0000] conn=5 op=7 EXT >>> oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End >>> Session" >>> [01/Apr/2014:21:23:58 +0000] conn=5 op=7 RESULT err=0 >>> tag=120 nentries=0 etime=0 >>> [01/Apr/2014:21:23:59 +0000] conn=2 op=12 UNBIND >>> [01/Apr/2014:21:23:59 +0000] conn=2 op=12 fd=65 closed - U1 >> >> This shows replication is working - that is, this server is >> able to act as a consumer for replication from 10.0.3.4 >> >> >>> >>> >>> >>> On Tue, Apr 1, 2014 at 5:41 PM, Rob Crittenden >>> > wrote: >>> >>> Rich Megginson wrote: >>> >>> On 04/01/2014 03:28 PM, Nevada Sanchez wrote: >>> >>> Okay, I just tried doing this on a FRESH fedora >>> 19 image (applied all >>> updates, installed freeipa, made a new replica >>> file for the new test >>> server, and went state to ipa-replica-insntall). >>> Exact same errors. >>> Anything else I should try? >>> >>> >>> I don't know. >>> >>> Does anyone on the IPA team know what the >>> ipa_lockout errors are about, >>> and if they would cause replication not to work? >>> >>> >>> I suspect it is a red herring. The error is not found, >>> so it is probably that the entry doesn't exist yet. This >>> is replication for the CA anyway. >>> >>> I'd be curious what the access and error logs on the >>> existing side looks like. It may be an SSL trust >>> problem, for example. >>> >>> rob >>> >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Apr 2 15:45:18 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Apr 2014 11:45:18 -0400 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: <533C2FBB.1020601@redhat.com> References: <533AF3D2.5050308@redhat.com> <533B11F6.3040603@redhat.com> <533B300D.6050707@redhat.com> <533B3296.1020409@redhat.com> <533C14BA.1030307@redhat.com> <533C26D9.7060409@redhat.com> <533C2FBB.1020601@redhat.com> Message-ID: <533C308E.8000303@redhat.com> Rich Megginson wrote: > On 04/02/2014 09:20 AM, Nevada Sanchez wrote: >> Okay, we might be on to something: >> >> ipa -> ipa2 >> ================================ >> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ >> -h ipa2.example.com -s base -b "" >> 'objectclass=*' vendorVersion >> dn: >> vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 >> ================================ >> >> ipa2 -> ipa >> ================================ >> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ >> -h ipa.example.com -s base -b "" >> 'objectclass=*' vendorVersion >> ldap_start_tls: Connect error (-11) >> additional info: TLS error -8172:Peer's certificate issuer has been >> marked as not trusted by the user. >> ================================ >> >> The original IPA trusts the replica (since it signed the cert, I >> assume), but the replica doesn't trust the main IPA server. I guess >> the ZZ option would have shown me the failure that I missed in my >> initial ldapsearch tests. > -Z[Z] Issue StartTLS (Transport Layer Security) extended > operation. If > you use -ZZ, the command will require the operation to > be suc- > cessful. > > i.e. use SSL, and force a successful handshake > >> >> Anyway, what's the best way to remedy this in a way that makes IPA >> happy? (I've found that LDAP can have different requirements on which >> certs go where). > > I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install > is supposed to take care of installing the CA cert properly for you. If > you try to hack it and install the CA cert manually, you will probably > miss something else that ipa install did not do. > > I think the only way to ensure that you have a properly configured ipa > server + replicas is to get all of the ipa commands completing successfully. > > Which means going back to the drawing board and starting over from scratch. You can compare the certs that each side is using with: # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM Did you by chance replace the SSL server certs that IPA uses on your working master? rob From tmaugh at boingo.com Wed Apr 2 16:01:59 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Wed, 2 Apr 2014 16:01:59 +0000 Subject: [Freeipa-users] force uninstall from Ubunutu 12.04 In-Reply-To: <533B63BE.6080006@redhat.com> References: <533B63BE.6080006@redhat.com> Message-ID: <39020f2194c94bdd89b2297a572c718b@BY2PR03MB176.namprd03.prod.outlook.com> Thank you that was it!!! -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, April 01, 2014 6:11 PM To: Todd Maugh; freeipa-users at redhat.com Subject: Re: [Freeipa-users] force uninstall from Ubunutu 12.04 Todd Maugh wrote: > Has any one been able to successfully uninstall a client from Ubuntu > 12.04 > > I have the install down for these boxes. But I need to transfer an > ubunutu client from our old ipa server to the new > > The error I get during uninstall is > > Failed to remove krb5/LDAP Configuration > > Even if I remove the /etc/ipa/default.conf > > When I go to renenroll client it says > > IPA client is already configured on this system. > > Run the uninstall blah blah blah > > Any suggestions? Does any one know the magic file to remove? The files in /var/lib/ipa/sysrestore rob From rmeggins at redhat.com Wed Apr 2 17:49:19 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 02 Apr 2014 11:49:19 -0600 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: References: <533AF3D2.5050308@redhat.com> <533B11F6.3040603@redhat.com> <533B300D.6050707@redhat.com> <533B3296.1020409@redhat.com> <533C14BA.1030307@redhat.com> <533C26D9.7060409@redhat.com> <533C2FBB.1020601@redhat.com> <533C308E.8000303@redhat.com> Message-ID: <533C4D9F.4050807@redhat.com> On 04/02/2014 11:45 AM, Nevada Sanchez wrote: > My apologies. I mistakenly ran the failing ldapsearch from an > unpriviliged user (couldn't read slapd-EXAMPLE-COM directory). Running > as root, it now works just fine (same result as the one that worked). > SSL seems to not be the issue. Also, I haven't change the SSL certs > since I first set up the master. > > I have been doing the replica side things from scratch (even so far as > starting with a new machine). For the master side, I have just been > re-preparing the replica. I hope I don't have to start from scratch > with the master replica. I guess the next step would be to do the ipa-replica-install using -ddd and review the extra debug information that comes out. > > > On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden > wrote: > > Rich Megginson wrote: > > On 04/02/2014 09:20 AM, Nevada Sanchez wrote: > > Okay, we might be on to something: > > ipa -> ipa2 > ================================ > $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM > ldapsearch -xLLLZZ > -h ipa2.example.com > -s base -b "" > > 'objectclass=*' vendorVersion > dn: > vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 > ================================ > > ipa2 -> ipa > ================================ > $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM > ldapsearch -xLLLZZ > -h ipa.example.com > -s base -b "" > > 'objectclass=*' vendorVersion > ldap_start_tls: Connect error (-11) > additional info: TLS error -8172:Peer's certificate issuer > has been > marked as not trusted by the user. > ================================ > > The original IPA trusts the replica (since it signed the > cert, I > assume), but the replica doesn't trust the main IPA > server. I guess > the ZZ option would have shown me the failure that I > missed in my > initial ldapsearch tests. > > -Z[Z] Issue StartTLS (Transport Layer Security) extended > operation. If > you use -ZZ, the command will require the > operation to > be suc- > cessful. > > i.e. use SSL, and force a successful handshake > > > Anyway, what's the best way to remedy this in a way that > makes IPA > happy? (I've found that LDAP can have different > requirements on which > certs go where). > > > I'm not sure. > ipa-server-install/ipa-replica-prepare/ipa-replica-install > is supposed to take care of installing the CA cert properly > for you. If > you try to hack it and install the CA cert manually, you will > probably > miss something else that ipa install did not do. > > I think the only way to ensure that you have a properly > configured ipa > server + replicas is to get all of the ipa commands completing > successfully. > > Which means going back to the drawing board and starting over > from scratch. > > > You can compare the certs that each side is using with: > > # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM > > Did you by chance replace the SSL server certs that IPA uses on > your working master? > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanchez.nevada at gmail.com Wed Apr 2 17:45:57 2014 From: sanchez.nevada at gmail.com (Nevada Sanchez) Date: Wed, 2 Apr 2014 13:45:57 -0400 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: <533C308E.8000303@redhat.com> References: <533AF3D2.5050308@redhat.com> <533B11F6.3040603@redhat.com> <533B300D.6050707@redhat.com> <533B3296.1020409@redhat.com> <533C14BA.1030307@redhat.com> <533C26D9.7060409@redhat.com> <533C2FBB.1020601@redhat.com> <533C308E.8000303@redhat.com> Message-ID: My apologies. I mistakenly ran the failing ldapsearch from an unpriviliged user (couldn't read slapd-EXAMPLE-COM directory). Running as root, it now works just fine (same result as the one that worked). SSL seems to not be the issue. Also, I haven't change the SSL certs since I first set up the master. I have been doing the replica side things from scratch (even so far as starting with a new machine). For the master side, I have just been re-preparing the replica. I hope I don't have to start from scratch with the master replica. On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden wrote: > Rich Megginson wrote: > >> On 04/02/2014 09:20 AM, Nevada Sanchez wrote: >> >>> Okay, we might be on to something: >>> >>> ipa -> ipa2 >>> ================================ >>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ >>> -h ipa2.example.com -s base -b "" >>> >>> 'objectclass=*' vendorVersion >>> dn: >>> vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 >>> ================================ >>> >>> ipa2 -> ipa >>> ================================ >>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ >>> -h ipa.example.com -s base -b "" >>> >>> 'objectclass=*' vendorVersion >>> ldap_start_tls: Connect error (-11) >>> additional info: TLS error -8172:Peer's certificate issuer has been >>> marked as not trusted by the user. >>> ================================ >>> >>> The original IPA trusts the replica (since it signed the cert, I >>> assume), but the replica doesn't trust the main IPA server. I guess >>> the ZZ option would have shown me the failure that I missed in my >>> initial ldapsearch tests. >>> >> -Z[Z] Issue StartTLS (Transport Layer Security) extended >> operation. If >> you use -ZZ, the command will require the operation to >> be suc- >> cessful. >> >> i.e. use SSL, and force a successful handshake >> >> >>> Anyway, what's the best way to remedy this in a way that makes IPA >>> happy? (I've found that LDAP can have different requirements on which >>> certs go where). >>> >> >> I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install >> is supposed to take care of installing the CA cert properly for you. If >> you try to hack it and install the CA cert manually, you will probably >> miss something else that ipa install did not do. >> >> I think the only way to ensure that you have a properly configured ipa >> server + replicas is to get all of the ipa commands completing >> successfully. >> >> Which means going back to the drawing board and starting over from >> scratch. >> > > You can compare the certs that each side is using with: > > # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM > > Did you by chance replace the SSL server certs that IPA uses on your > working master? > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Apr 3 01:38:50 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 02 Apr 2014 19:38:50 -0600 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: References: <533AF3D2.5050308@redhat.com> <533B11F6.3040603@redhat.com> <533B300D.6050707@redhat.com> <533B3296.1020409@redhat.com> <533C14BA.1030307@redhat.com> <533C26D9.7060409@redhat.com> <533C2FBB.1020601@redhat.com> <533C308E.8000303@redhat.com> <533C4D9F.4050807@redhat.com> Message-ID: <533CBBAA.9040905@redhat.com> On 04/02/2014 03:01 PM, Nevada Sanchez wrote: > Okay, I ran it with debug on. The output is quite large. I'm not sure > what the etiquette is for posting large logs, so I threw it on gist > here: > https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt > > > > Let me know if I should copy it into the thread instead. Ok. Now can you post excerpts from the dirsrv errors log from both the master replica and the replica from around the time of the failure? > > > On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson > wrote: > > On 04/02/2014 11:45 AM, Nevada Sanchez wrote: >> My apologies. I mistakenly ran the failing ldapsearch from an >> unpriviliged user (couldn't read slapd-EXAMPLE-COM directory). >> Running as root, it now works just fine (same result as the one >> that worked). SSL seems to not be the issue. Also, I haven't >> change the SSL certs since I first set up the master. >> >> I have been doing the replica side things from scratch (even so >> far as starting with a new machine). For the master side, I have >> just been re-preparing the replica. I hope I don't have to start >> from scratch with the master replica. > > I guess the next step would be to do the ipa-replica-install using > -ddd and review the extra debug information that comes out. > > >> >> >> On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden >> > wrote: >> >> Rich Megginson wrote: >> >> On 04/02/2014 09:20 AM, Nevada Sanchez wrote: >> >> Okay, we might be on to something: >> >> ipa -> ipa2 >> ================================ >> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM >> ldapsearch -xLLLZZ >> -h ipa2.example.com >> -s base -b "" >> >> 'objectclass=*' vendorVersion >> dn: >> vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 >> ================================ >> >> ipa2 -> ipa >> ================================ >> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM >> ldapsearch -xLLLZZ >> -h ipa.example.com >> -s base -b "" >> >> 'objectclass=*' vendorVersion >> ldap_start_tls: Connect error (-11) >> additional info: TLS error -8172:Peer's certificate >> issuer has been >> marked as not trusted by the user. >> ================================ >> >> The original IPA trusts the replica (since it signed >> the cert, I >> assume), but the replica doesn't trust the main IPA >> server. I guess >> the ZZ option would have shown me the failure that I >> missed in my >> initial ldapsearch tests. >> >> -Z[Z] Issue StartTLS (Transport Layer Security) >> extended >> operation. If >> you use -ZZ, the command will require >> the operation to >> be suc- >> cessful. >> >> i.e. use SSL, and force a successful handshake >> >> >> Anyway, what's the best way to remedy this in a way >> that makes IPA >> happy? (I've found that LDAP can have different >> requirements on which >> certs go where). >> >> >> I'm not sure. >> ipa-server-install/ipa-replica-prepare/ipa-replica-install >> is supposed to take care of installing the CA cert >> properly for you. If >> you try to hack it and install the CA cert manually, you >> will probably >> miss something else that ipa install did not do. >> >> I think the only way to ensure that you have a properly >> configured ipa >> server + replicas is to get all of the ipa commands >> completing successfully. >> >> Which means going back to the drawing board and starting >> over from scratch. >> >> >> You can compare the certs that each side is using with: >> >> # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM >> >> Did you by chance replace the SSL server certs that IPA uses >> on your working master? >> >> rob >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.taylor at speedcast.com Thu Apr 3 01:49:29 2014 From: david.taylor at speedcast.com (David Taylor) Date: Thu, 3 Apr 2014 01:49:29 +0000 Subject: [Freeipa-users] Problem using IPA for Apache LDAP Auth Message-ID: <087A7F28B635FF4BB10D496CF170969405632082@SC-EXCHANGE.speedcast.com> Hi All, I'm having some issues with setting up ldap auth for an apache webserver. In short I have an IPA server that seems to be working correctly, it is currently acting and a central authentication server for our Linux server environment. What I'm trying to do is get LDAP Auth up for our web based services. The test environment is all CentOS 6.5 with the following config IPA server with an LDAP bind user set up as per http://www.freeipa.org/page/Apache_Group_Based_Authorization without the kerberos component. There is a single web directory /var/www/html/webtest with a single index.htlm file and a .htaccess file with the following contents. # Make sure you're using HTTPS, or anyone can read your LDAP password. # SSLRequireSSL Order deny,allow Deny from All AuthName "Example Authorisation" AuthType Basic AuthBasicProvider ldap AuthzLDAPAuthoritative on AuthLDAPUrl "ldaps://ipa.example.com:636/dc=example,dc=com?uid" AuthLDAPBindDN "uid=webapps,cn=sysaccounts,cn=etc, dc=example,dc=com" AuthLDAPBindPassword "" Require valid-user Satisfy any --------------------------------------------------------------------------------------- When I try to access the web page I get a basic auth prompt and in the ipa server logs I get the following [03/Apr/2014:12:26:22 +1100] conn=1689 fd=83 slot=83 SSL connection from 10.0.0.11 to 10.0.0.3 [03/Apr/2014:12:26:22 +1100] conn=1689 SSL 256-bit AES [03/Apr/2014:12:26:22 +1100] conn=1689 op=0 BIND dn="uid=webapps,cn=sysaccounts,cn=etc,dc=example,dc=com" method=128 version=3 [03/Apr/2014:12:26:22 +1100] conn=1689 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=webapps,cn=sysaccounts,cn=etc, dc=example,dc=com" [03/Apr/2014:12:26:22 +1100] conn=1689 op=1 SRCH base=" dc=example,dc=com" scope=2 filter="(&(objectClass=*)(uid=dtaylor))" attrs="uid" [03/Apr/2014:12:26:22 +1100] conn=1689 op=1 RESULT err=0 tag=101 nentries=1 etime=0 notes=U --------------------------------------------------------------------------------------- Any help is greatly appreciated. Best regards David Taylor -------------- next part -------------- An HTML attachment was scrubbed... URL: From justin.brown at fandingo.org Thu Apr 3 05:55:10 2014 From: justin.brown at fandingo.org (Justin Brown) Date: Thu, 3 Apr 2014 00:55:10 -0500 Subject: [Freeipa-users] Server Ports Message-ID: I'm having some trouble determining which ports my servers need open to communicate and what ports client servers and users will need. The last documentation that I was able to find was included in Fedora 15 (http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html). I opened those ports with firewalld, but I encountered errors when joining my replica server. (I retried the replica install with firewalld, and it succeeded, so it's clearly a problem with the firewall settings.) I'm joining the wave of the future, so please excuse the firewalld XML, but it should be pretty obvsious. All of the services are built into firewalld, except "dogtag", which I made myself and is defined at the end. Services dns, kerberos, and kpasswd are TCP+UDP. Service ntp is UDP only. The others are TCP only. ========= services/dogtag.xml: ========= On a side note, it would be nice if the firewalld packagers included a freeipa-server service (nudge nudge). Thanks, Justin From pspacek at redhat.com Thu Apr 3 07:25:49 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Apr 2014 09:25:49 +0200 Subject: [Freeipa-users] Server Ports In-Reply-To: References: Message-ID: <533D0CFD.9000706@redhat.com> On 3.4.2014 07:55, Justin Brown wrote: > I'm having some trouble determining which ports my servers need open > to communicate and what ports client servers and users will need. The > last documentation that I was able to find was included in Fedora 15 > (http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html). http://www.freeipa.org/page/Documentation is the ultimate source of documentation. Latest documentation build is on http://www.freeipa.org/docs/master/html-desktop/index.html > I opened those ports with firewalld, but I encountered errors when > joining my replica server. (I retried the replica install with > firewalld, and it succeeded, so it's clearly a problem with the > firewall settings.) > > I'm joining the wave of the future, so please excuse the firewalld > XML, but it should be pretty obvsious. All of the services are built > into firewalld, except "dogtag", which I made myself and is defined at > the end. ipa-replica-conncheck utility should tell you what is missing. > On a side note, it would be nice if the firewalld packagers included a > freeipa-server service (nudge nudge). Patches are welcome :-) -- Petr^2 Spacek From justin.brown at fandingo.org Thu Apr 3 07:46:32 2014 From: justin.brown at fandingo.org (Justin Brown) Date: Thu, 3 Apr 2014 02:46:32 -0500 Subject: [Freeipa-users] Server Ports In-Reply-To: <533D0CFD.9000706@redhat.com> References: <533D0CFD.9000706@redhat.com> Message-ID: Petr, I'll try another replica for testing tomorrow, and unfortunately the logs were purged when I reinstalled. The error message was not helpful and said something along the lines of CA installation failed, but did not list any reason. I'll get you the exact message tomorrow. I'll also try some more network tests as I have all of the ports that you listed plus some additional Dogtag ports, which I've come to understand are now proxied through 7389. > Patches are welcome :-) Yes, you've got me. ;) I'll review the Firewalld packaging in more detail and try to come up with a workable solution. It's not currently possible to do meta-services in firewalld, and I'm sure the FreeIPA developers don't want a hard dependency on firewalld via a hypothetical freeipa-server-firewalld dependency. I'm sure some solution is possible -- maybe even just in the documentation. Thanks, Justin On Thu, Apr 3, 2014 at 2:25 AM, Petr Spacek wrote: > On 3.4.2014 07:55, Justin Brown wrote: >> >> I'm having some trouble determining which ports my servers need open >> to communicate and what ports client servers and users will need. The >> last documentation that I was able to find was included in Fedora 15 >> >> (http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html). > > http://www.freeipa.org/page/Documentation > is the ultimate source of documentation. > > Latest documentation build is on > http://www.freeipa.org/docs/master/html-desktop/index.html > > >> I opened those ports with firewalld, but I encountered errors when >> joining my replica server. (I retried the replica install with >> firewalld, and it succeeded, so it's clearly a problem with the >> firewall settings.) >> >> I'm joining the wave of the future, so please excuse the firewalld >> XML, but it should be pretty obvsious. All of the services are built >> into firewalld, except "dogtag", which I made myself and is defined at >> the end. > > > ipa-replica-conncheck utility should tell you what is missing. > > >> On a side note, it would be nice if the firewalld packagers included a >> freeipa-server service (nudge nudge). > > > Patches are welcome :-) > > -- > Petr^2 Spacek From mkosek at redhat.com Thu Apr 3 10:43:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 03 Apr 2014 12:43:44 +0200 Subject: [Freeipa-users] Server Ports In-Reply-To: References: <533D0CFD.9000706@redhat.com> Message-ID: <533D3B60.7040209@redhat.com> On 04/03/2014 09:46 AM, Justin Brown wrote: > Petr, > > I'll try another replica for testing tomorrow, and unfortunately the > logs were purged when I reinstalled. The error message was not helpful > and said something along the lines of CA installation failed, but did > not list any reason. I'll get you the exact message tomorrow. I'll > also try some more network tests as I have all of the ports that you > listed plus some additional Dogtag ports, which I've come to > understand are now proxied through 7389. > >> Patches are welcome :-) > > Yes, you've got me. ;) I'll review the Firewalld packaging in more > detail and try to come up with a workable solution. It's not currently > possible to do meta-services in firewalld, and I'm sure the FreeIPA > developers don't want a hard dependency on firewalld via a > hypothetical freeipa-server-firewalld dependency. I'm sure some > solution is possible -- maybe even just in the documentation. > > Thanks, > Justin Hi Justin, Petr is right, patches and contributions are extremely welcome :-) Let me just pass the initial information in case you'd want to accept this challenge: How to contribute: http://www.freeipa.org/page/Contribute/Code Trac ticket with related information and links to Bugzillas: https://fedorahosted.org/freeipa/ticket/2110 Actually I do not think that freeipa-server-firewalld or similar is that bad idea. We already thought of shipping our own firewalld file(s) and such subpackage may be a way to go. This is something that can be discussed on freeipa-devel list. Martin From sanchez.nevada at gmail.com Wed Apr 2 21:01:33 2014 From: sanchez.nevada at gmail.com (Nevada Sanchez) Date: Wed, 2 Apr 2014 17:01:33 -0400 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: <533C4D9F.4050807@redhat.com> References: <533AF3D2.5050308@redhat.com> <533B11F6.3040603@redhat.com> <533B300D.6050707@redhat.com> <533B3296.1020409@redhat.com> <533C14BA.1030307@redhat.com> <533C26D9.7060409@redhat.com> <533C2FBB.1020601@redhat.com> <533C308E.8000303@redhat.com> <533C4D9F.4050807@redhat.com> Message-ID: Okay, I ran it with debug on. The output is quite large. I'm not sure what the etiquette is for posting large logs, so I threw it on gist here: https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt Let me know if I should copy it into the thread instead. On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson wrote: > On 04/02/2014 11:45 AM, Nevada Sanchez wrote: > > My apologies. I mistakenly ran the failing ldapsearch from an unpriviliged > user (couldn't read slapd-EXAMPLE-COM directory). Running as root, it now > works just fine (same result as the one that worked). SSL seems to not be > the issue. Also, I haven't change the SSL certs since I first set up the > master. > > I have been doing the replica side things from scratch (even so far as > starting with a new machine). For the master side, I have just been > re-preparing the replica. I hope I don't have to start from scratch with > the master replica. > > > I guess the next step would be to do the ipa-replica-install using -ddd > and review the extra debug information that comes out. > > > > > On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden wrote: > >> Rich Megginson wrote: >> >>> On 04/02/2014 09:20 AM, Nevada Sanchez wrote: >>> >>>> Okay, we might be on to something: >>>> >>>> ipa -> ipa2 >>>> ================================ >>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ >>>> -h ipa2.example.com -s base -b "" >>>> >>>> 'objectclass=*' vendorVersion >>>> dn: >>>> vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 >>>> ================================ >>>> >>>> ipa2 -> ipa >>>> ================================ >>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ >>>> -h ipa.example.com -s base -b "" >>>> >>>> 'objectclass=*' vendorVersion >>>> ldap_start_tls: Connect error (-11) >>>> additional info: TLS error -8172:Peer's certificate issuer has been >>>> marked as not trusted by the user. >>>> ================================ >>>> >>>> The original IPA trusts the replica (since it signed the cert, I >>>> assume), but the replica doesn't trust the main IPA server. I guess >>>> the ZZ option would have shown me the failure that I missed in my >>>> initial ldapsearch tests. >>>> >>> -Z[Z] Issue StartTLS (Transport Layer Security) extended >>> operation. If >>> you use -ZZ, the command will require the operation to >>> be suc- >>> cessful. >>> >>> i.e. use SSL, and force a successful handshake >>> >>> >>>> Anyway, what's the best way to remedy this in a way that makes IPA >>>> happy? (I've found that LDAP can have different requirements on which >>>> certs go where). >>>> >>> >>> I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install >>> is supposed to take care of installing the CA cert properly for you. If >>> you try to hack it and install the CA cert manually, you will probably >>> miss something else that ipa install did not do. >>> >>> I think the only way to ensure that you have a properly configured ipa >>> server + replicas is to get all of the ipa commands completing >>> successfully. >>> >>> Which means going back to the drawing board and starting over from >>> scratch. >>> >> >> You can compare the certs that each side is using with: >> >> # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM >> >> Did you by chance replace the SSL server certs that IPA uses on your >> working master? >> >> rob >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanchez.nevada at gmail.com Thu Apr 3 03:22:10 2014 From: sanchez.nevada at gmail.com (Nevada Sanchez) Date: Wed, 2 Apr 2014 23:22:10 -0400 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: <533CBBAA.9040905@redhat.com> References: <533AF3D2.5050308@redhat.com> <533B11F6.3040603@redhat.com> <533B300D.6050707@redhat.com> <533B3296.1020409@redhat.com> <533C14BA.1030307@redhat.com> <533C26D9.7060409@redhat.com> <533C2FBB.1020601@redhat.com> <533C308E.8000303@redhat.com> <533C4D9F.4050807@redhat.com> <533CBBAA.9040905@redhat.com> Message-ID: Okay. Updated the gist with the additional logs: https://gist.github.com/nevsan/8b6f78d7396963dc5f70 On Wed, Apr 2, 2014 at 9:38 PM, Rich Megginson wrote: > On 04/02/2014 03:01 PM, Nevada Sanchez wrote: > > Okay, I ran it with debug on. The output is quite large. I'm not sure what > the etiquette is for posting large logs, so I threw it on gist here: > https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt > > Let me know if I should copy it into the thread instead. > > > Ok. Now can you post excerpts from the dirsrv errors log from both the > master replica and the replica from around the time of the failure? > > > > > On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson wrote: > >> On 04/02/2014 11:45 AM, Nevada Sanchez wrote: >> >> My apologies. I mistakenly ran the failing ldapsearch from an >> unpriviliged user (couldn't read slapd-EXAMPLE-COM directory). Running as >> root, it now works just fine (same result as the one that worked). SSL >> seems to not be the issue. Also, I haven't change the SSL certs since I >> first set up the master. >> >> I have been doing the replica side things from scratch (even so far as >> starting with a new machine). For the master side, I have just been >> re-preparing the replica. I hope I don't have to start from scratch with >> the master replica. >> >> >> I guess the next step would be to do the ipa-replica-install using -ddd >> and review the extra debug information that comes out. >> >> >> >> >> On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden wrote: >> >>> Rich Megginson wrote: >>> >>>> On 04/02/2014 09:20 AM, Nevada Sanchez wrote: >>>> >>>>> Okay, we might be on to something: >>>>> >>>>> ipa -> ipa2 >>>>> ================================ >>>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ >>>>> -h ipa2.example.com -s base -b "" >>>>> >>>>> 'objectclass=*' vendorVersion >>>>> dn: >>>>> vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 >>>>> ================================ >>>>> >>>>> ipa2 -> ipa >>>>> ================================ >>>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ >>>>> -h ipa.example.com -s base -b "" >>>>> >>>>> 'objectclass=*' vendorVersion >>>>> ldap_start_tls: Connect error (-11) >>>>> additional info: TLS error -8172:Peer's certificate issuer has been >>>>> marked as not trusted by the user. >>>>> ================================ >>>>> >>>>> The original IPA trusts the replica (since it signed the cert, I >>>>> assume), but the replica doesn't trust the main IPA server. I guess >>>>> the ZZ option would have shown me the failure that I missed in my >>>>> initial ldapsearch tests. >>>>> >>>> -Z[Z] Issue StartTLS (Transport Layer Security) extended >>>> operation. If >>>> you use -ZZ, the command will require the operation to >>>> be suc- >>>> cessful. >>>> >>>> i.e. use SSL, and force a successful handshake >>>> >>>> >>>>> Anyway, what's the best way to remedy this in a way that makes IPA >>>>> happy? (I've found that LDAP can have different requirements on which >>>>> certs go where). >>>>> >>>> >>>> I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install >>>> is supposed to take care of installing the CA cert properly for you. If >>>> you try to hack it and install the CA cert manually, you will probably >>>> miss something else that ipa install did not do. >>>> >>>> I think the only way to ensure that you have a properly configured ipa >>>> server + replicas is to get all of the ipa commands completing >>>> successfully. >>>> >>>> Which means going back to the drawing board and starting over from >>>> scratch. >>>> >>> >>> You can compare the certs that each side is using with: >>> >>> # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM >>> >>> Did you by chance replace the SSL server certs that IPA uses on your >>> working master? >>> >>> rob >>> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwhanley at syr.edu Thu Apr 3 14:31:55 2014 From: mwhanley at syr.edu (Matthew W Hanley) Date: Thu, 3 Apr 2014 14:31:55 +0000 Subject: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory Message-ID: I'm in the midst of setting up a trust with FreeIPA and Active Directory and am receiving the following error: # ipa trust-add --type=ad ad.example.com --admin 'mwhanley' --password Active directory domain administrator's password: ipa: ERROR: Cannot find specified domain or server name The FreeIPA server is running Fedora release 20, version 3.3.3-4 of FreeIPA and I have turned on debugging and get the following: ps [Wed Apr 02 10:20:53.766064 2014] [:error] [pid 32522] ipa: INFO: admin at ipaexample.com: trust_add(u'ad.example.com', trust_type=u'ad', realm_admin=u'mwhanley', realm_passwd=u'********', all=False, raw=False, version=u'2.65'): NotFound [Wed Apr 02 10:21:29.635077 2014] [:error] [pid 32521] ipa: INFO: admin at ipaexample.com: idrange_find(None, all=False, raw=False, version=u'2.65', pkey_only=False): SUCCESS INFO: Current debug levels: all: 11 tdb: 11 printdrivers: 11 lanman: 11 smb: 11 rpc_parse: 11 rpc_srv: 11 rpc_cli: 11 passdb: 11 sam: 11 auth: 11 winbind: 11 vfs: 11 idmap: 11 quota: 11 acls: 11 locking: 11 msdfs: 11 dmapi: 11 registry: 11 scavenger: 11 dns: 11 ldb: 11 pm_process() returned Yes Using binding ncacn_np:host.ipaexample.com[,] Mapped to DCERPC endpoint \pipe\lsarpc added interface eth0 ip=xxx.xxx.xxx.xxx bcast=xxx.xxx.xxx.xxx netmask=255.255.255.0 added interface eth0 ip=xxx.xxx.xxx.xxx bcast=xxx.xxx.xxx.xxx netmask=255.255.255.0 Socket options: SO_KEEPALIVE = 0 SO_REUSEADDR = 0 SO_BROADCAST = 0 TCP_NODELAY = 1 TCP_KEEPCNT = 9 TCP_KEEPIDLE = 7200 TCP_KEEPINTVL = 75 IPTOS_LOWDELAY = 0 IPTOS_THROUGHPUT = 0 SO_REUSEPORT = 0 SO_SNDBUF = 663750 SO_RCVBUF = 265452 SO_SNDLOWAT = 1 SO_RCVLOWAT = 1 SO_SNDTIMEO = 0 SO_RCVTIMEO = 0 TCP_QUICKACK = 1 TCP_DEFER_ACCEPT = 0 Starting GENSEC mechanism spnego Starting GENSEC submechanism gssapi_krb5 Ticket in credentials cache for admin at ipaexample.com will expire in 84015 secs gensec_gssapi: NO credentials were delegated GSSAPI Connection will be cryptographically sealed I've also done an "ipactl restart" to no avail. Any help would be appreciated. -Matt Matthew Hanley IT Analyst Syracuse University mwhanley at syr.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Apr 3 14:38:37 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 03 Apr 2014 08:38:37 -0600 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: References: <533AF3D2.5050308@redhat.com> <533B11F6.3040603@redhat.com> <533B300D.6050707@redhat.com> <533B3296.1020409@redhat.com> <533C14BA.1030307@redhat.com> <533C26D9.7060409@redhat.com> <533C2FBB.1020601@redhat.com> <533C308E.8000303@redhat.com> <533C4D9F.4050807@redhat.com> <533CBBAA.9040905@redhat.com> Message-ID: <533D726D.4080909@redhat.com> On 04/02/2014 09:22 PM, Nevada Sanchez wrote: > Okay. Updated the gist with the additional logs: > https://gist.github.com/nevsan/8b6f78d7396963dc5f70 > > 1) Dirsrv is crashing: [02/Apr/2014:20:49:53 +0000] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [02/Apr/2014:20:49:54 +0000] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. [02/Apr/2014:20:49:54 +0000] - I'm resizing my cache now...cache was 710029312 and is now 8000000 [02/Apr/2014:20:49:54 +0000] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [02/Apr/2014:20:49:54 +0000] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [02/Apr/2014:20:49:55 +0000] - slapd started. Listening on All Interfaces port 389 for LDAP requests Please use the instructions at http://port389.org/wiki/FAQ#Debugging_Crashes to get a core dump and stack trace. 2) The first occurrence of the connection error is at [02/Apr/2014:20:52:38 +0000] but there isn't anything in the consumer error log after [02/Apr/2014:20:50:21 +0000] and in the consumer access log after [02/Apr/2014:20:50:22 +0000] > On Wed, Apr 2, 2014 at 9:38 PM, Rich Megginson > wrote: > > On 04/02/2014 03:01 PM, Nevada Sanchez wrote: >> Okay, I ran it with debug on. The output is quite large. I'm not >> sure what the etiquette is for posting large logs, so I threw it >> on gist here: >> https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt >> >> >> >> Let me know if I should copy it into the thread instead. > > Ok. Now can you post excerpts from the dirsrv errors log from > both the master replica and the replica from around the time of > the failure? > > >> >> >> On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson >> > wrote: >> >> On 04/02/2014 11:45 AM, Nevada Sanchez wrote: >>> My apologies. I mistakenly ran the failing ldapsearch from >>> an unpriviliged user (couldn't read slapd-EXAMPLE-COM >>> directory). Running as root, it now works just fine (same >>> result as the one that worked). SSL seems to not be the >>> issue. Also, I haven't change the SSL certs since I first >>> set up the master. >>> >>> I have been doing the replica side things from scratch (even >>> so far as starting with a new machine). For the master side, >>> I have just been re-preparing the replica. I hope I don't >>> have to start from scratch with the master replica. >> >> I guess the next step would be to do the ipa-replica-install >> using -ddd and review the extra debug information that comes >> out. >> >> >>> >>> >>> On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden >>> > wrote: >>> >>> Rich Megginson wrote: >>> >>> On 04/02/2014 09:20 AM, Nevada Sanchez wrote: >>> >>> Okay, we might be on to something: >>> >>> ipa -> ipa2 >>> ================================ >>> $ >>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM >>> ldapsearch -xLLLZZ >>> -h ipa2.example.com >>> -s base -b "" >>> >>> 'objectclass=*' vendorVersion >>> dn: >>> vendorVersion: 389-Directory/1.3.1.22.a1 >>> B2014.073.1751 >>> ================================ >>> >>> ipa2 -> ipa >>> ================================ >>> $ >>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM >>> ldapsearch -xLLLZZ >>> -h ipa.example.com >>> -s base -b "" >>> >>> 'objectclass=*' vendorVersion >>> ldap_start_tls: Connect error (-11) >>> additional info: TLS error -8172:Peer's >>> certificate issuer has been >>> marked as not trusted by the user. >>> ================================ >>> >>> The original IPA trusts the replica (since it >>> signed the cert, I >>> assume), but the replica doesn't trust the main >>> IPA server. I guess >>> the ZZ option would have shown me the failure >>> that I missed in my >>> initial ldapsearch tests. >>> >>> -Z[Z] Issue StartTLS (Transport Layer >>> Security) extended >>> operation. If >>> you use -ZZ, the command will >>> require the operation to >>> be suc- >>> cessful. >>> >>> i.e. use SSL, and force a successful handshake >>> >>> >>> Anyway, what's the best way to remedy this in a >>> way that makes IPA >>> happy? (I've found that LDAP can have different >>> requirements on which >>> certs go where). >>> >>> >>> I'm not sure. >>> ipa-server-install/ipa-replica-prepare/ipa-replica-install >>> is supposed to take care of installing the CA cert >>> properly for you. If >>> you try to hack it and install the CA cert manually, >>> you will probably >>> miss something else that ipa install did not do. >>> >>> I think the only way to ensure that you have a >>> properly configured ipa >>> server + replicas is to get all of the ipa commands >>> completing successfully. >>> >>> Which means going back to the drawing board and >>> starting over from scratch. >>> >>> >>> You can compare the certs that each side is using with: >>> >>> # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM >>> >>> Did you by chance replace the SSL server certs that IPA >>> uses on your working master? >>> >>> rob >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Apr 3 14:53:31 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 3 Apr 2014 16:53:31 +0200 Subject: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory In-Reply-To: References: Message-ID: <20140403145331.GN11404@localhost.localdomain> On Thu, Apr 03, 2014 at 02:31:55PM +0000, Matthew W Hanley wrote: > I'm in the midst of setting up a trust with FreeIPA and Active Directory and am receiving the following error: > > # ipa trust-add --type=ad ad.example.com --admin 'mwhanley' --password > Active directory domain administrator's password: > > ipa: ERROR: Cannot find specified domain or server name looks like a DNS issue. Can you check if dig SRV _ldap._tcp.ad.example.com returns a list of IP addresses for your AD DCs? If not you might want to have a look at www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#DNS_configuration . HTH bye, Sumit > > The FreeIPA server is running Fedora release 20, version 3.3.3-4 of FreeIPA and I have turned on debugging and get the following: > > ps [Wed Apr 02 10:20:53.766064 2014] [:error] [pid 32522] ipa: INFO: admin at ipaexample.com: trust_add(u'ad.example.com', trust_type=u'ad', realm_admin=u'mwhanley', realm_passwd=u'********', all=False, raw=False, version=u'2.65'): NotFound > [Wed Apr 02 10:21:29.635077 2014] [:error] [pid 32521] ipa: INFO: admin at ipaexample.com: idrange_find(None, all=False, raw=False, version=u'2.65', pkey_only=False): SUCCESS > INFO: Current debug levels: > all: 11 > tdb: 11 > printdrivers: 11 > lanman: 11 > smb: 11 > rpc_parse: 11 > rpc_srv: 11 > rpc_cli: 11 > passdb: 11 > sam: 11 > auth: 11 > winbind: 11 > vfs: 11 > idmap: 11 > quota: 11 > acls: 11 > locking: 11 > msdfs: 11 > dmapi: 11 > registry: 11 > scavenger: 11 > dns: 11 > ldb: 11 > pm_process() returned Yes > Using binding ncacn_np:host.ipaexample.com[,] > Mapped to DCERPC endpoint \pipe\lsarpc > added interface eth0 ip=xxx.xxx.xxx.xxx bcast=xxx.xxx.xxx.xxx netmask=255.255.255.0 > added interface eth0 ip=xxx.xxx.xxx.xxx bcast=xxx.xxx.xxx.xxx netmask=255.255.255.0 > Socket options: > SO_KEEPALIVE = 0 > SO_REUSEADDR = 0 > SO_BROADCAST = 0 > TCP_NODELAY = 1 > TCP_KEEPCNT = 9 > TCP_KEEPIDLE = 7200 > TCP_KEEPINTVL = 75 > IPTOS_LOWDELAY = 0 > IPTOS_THROUGHPUT = 0 > SO_REUSEPORT = 0 > SO_SNDBUF = 663750 > SO_RCVBUF = 265452 > SO_SNDLOWAT = 1 > SO_RCVLOWAT = 1 > SO_SNDTIMEO = 0 > SO_RCVTIMEO = 0 > TCP_QUICKACK = 1 > TCP_DEFER_ACCEPT = 0 > Starting GENSEC mechanism spnego > Starting GENSEC submechanism gssapi_krb5 > Ticket in credentials cache for admin at ipaexample.com will expire in 84015 secs > gensec_gssapi: NO credentials were delegated > GSSAPI Connection will be cryptographically sealed > > I've also done an "ipactl restart" to no avail. Any help would be appreciated. > > -Matt > > > Matthew Hanley > IT Analyst > Syracuse University > mwhanley at syr.edu > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From atomlin at engineer.com Thu Apr 3 17:38:56 2014 From: atomlin at engineer.com (Andy Tomlin) Date: Thu, 3 Apr 2014 10:38:56 -0700 Subject: [Freeipa-users] DDNS with DHCPD and IPA Message-ID: <006101cf4f63$97eaae50$c7c00af0$@engineer.com> I posted this on the DHCP mailing list, but think it may belong here instead. I am running Centos 6.5 and have installed ipa to allow all our linux machines to authenticate. We have windows machines that get their ip address from server and since installing ipa the ddns no longer works. Googling around does not show much help. The key files match. My named.conf is as follows: [root at alfred ~]# cat /etc/named.conf options { // turns on IPv6 for port 53, IPv4 is on by default for all ifaces listen-on-v6 {any;}; listen-on port 53 { 127.0.0.1; 10.0.1.2; }; // Put files that named is allowed to write in the data/ directory: directory "/var/named"; // the default dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; memstatistics-file "data/named_mem_stats.txt"; //forward first; //forwarders { // 192.168.1.254; // 8.8.8.8; //}; // Any host is permitted to issue recursive queries allow-recursion { any; }; tkey-gssapi-credential "DNS/alfred.xxxxxxx.com"; tkey-domain "xxxxxxx.COM"; }; include "/etc/named/ddns.key"; /* If you want to enable debugging, eg. using the 'rndc trace' command, * By default, SELinux policy does not allow named to modify the /var/named directory, * so put the default debug log file in data/ : */ logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; dynamic-db "ipa" { library "ldap.so"; arg "uri ldapi://%2fvar%2frun%2fslapd-xxxxxxx-COM.socket"; arg "base cn=dns, dc=xxxxxxx,dc=com"; arg "fake_mname alfred.xxxxxxx.com."; arg "auth_method sasl"; arg "sasl_mech GSSAPI"; arg "sasl_user DNS/alfred.xxxxxxx.com"; arg "zone_refresh 0"; arg "psearch yes"; arg "serial_autoincrement yes"; }; My dhcpd.conf is as follows: [root at alfred ~]# cat /etc/dhcp/dhcpd.conf # dhcpd.conf # # Sample configuration file for ISC dhcpd # # option definitions common to all supported networks... option domain-name "xxxxxxx.com"; option domain-name-servers 10.0.1.2, 8.8.8.8, 8.8.4.4; ddns-updates on; ddns-update-style interim; ignore client-updates; update-static-leases on; default-lease-time 600; max-lease-time 7200; # Use this to enble / disable dynamic dns updates globally. #ddns-update-style none; # If this DHCP server is the official DHCP server for the local # network, the authoritative directive should be uncommented. authoritative; # Use this to send dhcp log messages to a different log file (you also # have to hack syslog.conf to complete the redirection). log-facility local7; # No service will be given on this subnet, but declaring it helps the # DHCP server to understand the network topology. #subnet 10.152.187.0 netmask 255.255.255.0 { #} include "/etc/dhcp/ddns.key"; zone xxxxxxx.com. { primary 127.0.0.1; key DDNS_UPDATE; } zone 2.0.10.in-addr.arpa. { primary 127.0.0.1; key DDNS_UPDATE; } # This is a very basic subnet declaration. subnet 10.0.0.0 netmask 255.255.0.0 { range 10.0.2.50 10.0.2.250; option routers 10.0.1.2; } [root at alfred ~]# When windows client gets a dhcp address, the following is in the log [root at alfred ~]# tail -n50 /var/log/messages Apr 2 19:40:50 alfred named[8491]: client 127.0.0.1#59786: updating zone 'xxxxxxx.com/IN': update failed: rejected by secure update (REFUSED) Apr 2 19:40:50 alfred dhcpd: Unable to add forward map from atomlin.xxxxxxx.com to 10.0.2.51: timed out Apr 2 19:40:50 alfred dhcpd: DHCPREQUEST for 10.0.2.51 from 0c:54:a5:08:5f:cc (atomlin) via eth0 Apr 2 19:40:50 alfred dhcpd: DHCPACK on 10.0.2.51 to 0c:54:a5:08:5f:cc (atomlin) via eth0 [root at alfred ~]# -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Apr 3 17:51:30 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 03 Apr 2014 13:51:30 -0400 Subject: [Freeipa-users] DDNS with DHCPD and IPA In-Reply-To: <006101cf4f63$97eaae50$c7c00af0$@engineer.com> References: <006101cf4f63$97eaae50$c7c00af0$@engineer.com> Message-ID: <1396547490.18479.42.camel@willson.li.ssimo.org> On Thu, 2014-04-03 at 10:38 -0700, Andy Tomlin wrote: > I posted this on the DHCP mailing list, but think it may belong here > instead. > > > > I am running Centos 6.5 and have installed ipa to allow all our linux > machines to authenticate. We have windows machines that get their ip address > from server and since installing ipa the ddns no longer works. Googling > around does not show much help. The key files match. There is a bug in kerberos libraries that prevent Windows clients from successfully performing DDNS against BIND servers that we fixed only recently. This is the fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1066000 Not sure if this has been backported to RHEL/CentOS tbh. This is for Windows clients directly performing DDNS updates using GSS-TSIG. -- Now reading the following lines it seem you are mixing GSS-TSIG and plain TSIG, well you can't do that. ATM I think we accept only GSS-TSIG updates in IPA, while BIND DHCP seem to be capable only of TSIG updates. CCing Petr as he may have some ideas on whether this is something we can work around. Simo. > > > My named.conf is as follows: > > > > [root at alfred ~]# cat /etc/named.conf > > options { > > // turns on IPv6 for port 53, IPv4 is on by default for all ifaces > > listen-on-v6 {any;}; > > listen-on port 53 { 127.0.0.1; 10.0.1.2; }; > > > > // Put files that named is allowed to write in the data/ directory: > > directory "/var/named"; // the default > > dump-file "data/cache_dump.db"; > > statistics-file "data/named_stats.txt"; > > memstatistics-file "data/named_mem_stats.txt"; > > > > //forward first; > > //forwarders { > > // 192.168.1.254; > > // 8.8.8.8; > > //}; > > > > // Any host is permitted to issue recursive queries > > allow-recursion { any; }; > > > > tkey-gssapi-credential "DNS/alfred.xxxxxxx.com"; > > tkey-domain "xxxxxxx.COM"; > > }; > > > > include "/etc/named/ddns.key"; > > > > /* If you want to enable debugging, eg. using the 'rndc trace' command, > > * By default, SELinux policy does not allow named to modify the /var/named > directory, > > * so put the default debug log file in data/ : > > */ > > logging { > > channel default_debug { > > file "data/named.run"; > > severity dynamic; > > }; > > }; > > > > zone "." IN { > > type hint; > > file "named.ca"; > > }; > > > > include "/etc/named.rfc1912.zones"; > > > > dynamic-db "ipa" { > > library "ldap.so"; > > arg "uri ldapi://%2fvar%2frun%2fslapd-xxxxxxx-COM.socket"; > > arg "base cn=dns, dc=xxxxxxx,dc=com"; > > arg "fake_mname alfred.xxxxxxx.com."; > > arg "auth_method sasl"; > > arg "sasl_mech GSSAPI"; > > arg "sasl_user DNS/alfred.xxxxxxx.com"; > > arg "zone_refresh 0"; > > arg "psearch yes"; > > arg "serial_autoincrement yes"; > > }; > > > > My dhcpd.conf is as follows: > > [root at alfred ~]# cat /etc/dhcp/dhcpd.conf > > # dhcpd.conf > > # > > # Sample configuration file for ISC dhcpd > > # > > > > # option definitions common to all supported networks... > > option domain-name "xxxxxxx.com"; > > option domain-name-servers 10.0.1.2, 8.8.8.8, 8.8.4.4; > > > > ddns-updates on; > > ddns-update-style interim; > > ignore client-updates; > > update-static-leases on; > > > > default-lease-time 600; > > max-lease-time 7200; > > > > # Use this to enble / disable dynamic dns updates globally. > > #ddns-update-style none; > > > > # If this DHCP server is the official DHCP server for the local > > # network, the authoritative directive should be uncommented. > > authoritative; > > > > # Use this to send dhcp log messages to a different log file (you also > > # have to hack syslog.conf to complete the redirection). > > log-facility local7; > > > > # No service will be given on this subnet, but declaring it helps the > > # DHCP server to understand the network topology. > > > > #subnet 10.152.187.0 netmask 255.255.255.0 { > > #} > > > > include "/etc/dhcp/ddns.key"; > > > > zone xxxxxxx.com. { > > primary 127.0.0.1; > > key DDNS_UPDATE; > > } > > > > zone 2.0.10.in-addr.arpa. { > > primary 127.0.0.1; > > key DDNS_UPDATE; > > } > > > > # This is a very basic subnet declaration. > > > > subnet 10.0.0.0 netmask 255.255.0.0 { > > range 10.0.2.50 10.0.2.250; > > option routers 10.0.1.2; > > } > > > > [root at alfred ~]# > > > > When windows client gets a dhcp address, the following is in the log > > > > [root at alfred ~]# tail -n50 /var/log/messages > > Apr 2 19:40:50 alfred named[8491]: client 127.0.0.1#59786: updating zone > 'xxxxxxx.com/IN': update failed: rejected by secure update (REFUSED) > > Apr 2 19:40:50 alfred dhcpd: Unable to add forward map from > atomlin.xxxxxxx.com to 10.0.2.51: timed out > > Apr 2 19:40:50 alfred dhcpd: DHCPREQUEST for 10.0.2.51 from > 0c:54:a5:08:5f:cc (atomlin) via eth0 > > Apr 2 19:40:50 alfred dhcpd: DHCPACK on 10.0.2.51 to 0c:54:a5:08:5f:cc > (atomlin) via eth0 > > [root at alfred ~]# > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York From bpk678 at gmail.com Thu Apr 3 17:59:05 2014 From: bpk678 at gmail.com (brendan kearney) Date: Thu, 3 Apr 2014 13:59:05 -0400 Subject: [Freeipa-users] DDNS with DHCPD and IPA Message-ID: Dont allow clients to ddns update. Force the update to occur from dhcpd to named On Apr 3, 2014 1:53 PM, "Simo Sorce" wrote: On Thu, 2014-04-03 at 10:38 -0700, Andy Tomlin wrote: > I posted this on the DHCP mailing list, but think it may belong here > instead. > > > > I am running Centos 6.5 and have installed ipa to allow all our linux > machines to authenticate. We have windows machines that get their ip address > from server and since installing ipa the ddns no longer works. Googling > around does not show much help. The key files match. There is a bug in kerberos libraries that prevent Windows clients from successfully performing DDNS against BIND servers that we fixed only recently. This is the fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1066000 Not sure if this has been backported to RHEL/CentOS tbh. This is for Windows clients directly performing DDNS updates using GSS-TSIG. -- Now reading the following lines it seem you are mixing GSS-TSIG and plain TSIG, well you can't do that. ATM I think we accept only GSS-TSIG updates in IPA, while BIND DHCP seem to be capable only of TSIG updates. CCing Petr as he may have some ideas on whether this is something we can work around. Simo. > > > My named.conf is as follows: > > > > [root at alfred ~]# cat /etc/named.conf > > options { > > // turns on IPv6 for port 53, IPv4 is on by default for all ifaces > > listen-on-v6 {any;}; > > listen-on port 53 { 127.0.0.1; 10.0.1.2; }; > > > > // Put files that named is allowed to write in the data/ directory: > > directory "/var/named"; // the default > > dump-file "data/cache_dump.db"; > > statistics-file "data/named_stats.txt"; > > memstatistics-file "data/named_mem_stats.txt"; > > > > //forward first; > > //forwarders { > > // 192.168.1.254; > > // 8.8.8.8; > > //}; > > > > // Any host is permitted to issue recursive queries > > allow-recursion { any; }; > > > > tkey-gssapi-credential "DNS/alfred.xxxxxxx.com"; > > tkey-domain "xxxxxxx.COM"; > > }; > > > > include "/etc/named/ddns.key"; > > > > /* If you want to enable debugging, eg. using the 'rndc trace' command, > > * By default, SELinux policy does not allow named to modify the /var/named > directory, > > * so put the default debug log file in data/ : > > */ > > logging { > > channel default_debug { > > file "data/named.run"; > > severity dynamic; > > }; > > }; > > > > zone "." IN { > > type hint; > > file "named.ca"; > > }; > > > > include "/etc/named.rfc1912.zones"; > > > > dynamic-db "ipa" { > > library "ldap.so"; > > arg "uri ldapi://%2fvar%2frun%2fslapd-xxxxxxx-COM.socket"; > > arg "base cn=dns, dc=xxxxxxx,dc=com"; > > arg "fake_mname alfred.xxxxxxx.com."; > > arg "auth_method sasl"; > > arg "sasl_mech GSSAPI"; > > arg "sasl_user DNS/alfred.xxxxxxx.com"; > > arg "zone_refresh 0"; > > arg "psearch yes"; > > arg "serial_autoincrement yes"; > > }; > > > > My dhcpd.conf is as follows: > > [root at alfred ~]# cat /etc/dhcp/dhcpd.conf > > # dhcpd.conf > > # > > # Sample configuration file for ISC dhcpd > > # > > > > # option definitions common to all supported networks... > > option domain-name "xxxxxxx.com"; > > option domain-name-servers 10.0.1.2, 8.8.8.8, 8.8.4.4; > > > > ddns-updates on; > > ddns-update-style interim; > > ignore client-updates; > > update-static-leases on; > > > > default-lease-time 600; > > max-lease-time 7200; > > > > # Use this to enble / disable dynamic dns updates globally. > > #ddns-update-style none; > > > > # If this DHCP server is the official DHCP server for the local > > # network, the authoritative directive should be uncommented. > > authoritative; > > > > # Use this to send dhcp log messages to a different log file (you also > > # have to hack syslog.conf to complete the redirection). > > log-facility local7; > > > > # No service will be given on this subnet, but declaring it helps the > > # DHCP server to understand the network topology. > > > > #subnet 10.152.187.0 netmask 255.255.255.0 { > > #} > > > > include "/etc/dhcp/ddns.key"; > > > > zone xxxxxxx.com. { > > primary 127.0.0.1; > > key DDNS_UPDATE; > > } > > > > zone 2.0.10.in-addr.arpa. { > > primary 127.0.0.1; > > key DDNS_UPDATE; > > } > > > > # This is a very basic subnet declaration. > > > > subnet 10.0.0.0 netmask 255.255.0.0 { > > range 10.0.2.50 10.0.2.250; > > option routers 10.0.1.2; > > } > > > > [root at alfred ~]# > > > > When windows client gets a dhcp address, the following is in the log > > > > [root at alfred ~]# tail -n50 /var/log/messages > > Apr 2 19:40:50 alfred named[8491]: client 127.0.0.1#59786: updating zone > 'xxxxxxx.com/IN': update failed: rejected by secure update (REFUSED) > > Apr 2 19:40:50 alfred dhcpd: Unable to add forward map from > atomlin.xxxxxxx.com to 10.0.2.51: timed out > > Apr 2 19:40:50 alfred dhcpd: DHCPREQUEST for 10.0.2.51 from > 0c:54:a5:08:5f:cc (atomlin) via eth0 > > Apr 2 19:40:50 alfred dhcpd: DHCPACK on 10.0.2.51 to 0c:54:a5:08:5f:cc > (atomlin) via eth0 > > [root at alfred ~]# > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From atomlin at engineer.com Thu Apr 3 18:02:13 2014 From: atomlin at engineer.com (Andy Tomlin) Date: Thu, 3 Apr 2014 11:02:13 -0700 Subject: [Freeipa-users] DDNS with DHCPD and IPA In-Reply-To: References: Message-ID: <006c01cf4f66$d8ad5390$8a07fab0$@engineer.com> That would be my preference, would then work same as bind/dhcpd before switching to ipa. I just dont know how to do it correctly. From: brendan kearney [mailto:bpk678 at gmail.com] Sent: Thursday, April 3, 2014 10:59 AM To: Simo Sorce Cc: freeipa-users at redhat.com; atomlin at engineer.com Subject: Re: [Freeipa-users] DDNS with DHCPD and IPA Dont allow clients to ddns update. Force the update to occur from dhcpd to named On Apr 3, 2014 1:53 PM, "Simo Sorce" > wrote: On Thu, 2014-04-03 at 10:38 -0700, Andy Tomlin wrote: > I posted this on the DHCP mailing list, but think it may belong here > instead. > > > > I am running Centos 6.5 and have installed ipa to allow all our linux > machines to authenticate. We have windows machines that get their ip address > from server and since installing ipa the ddns no longer works. Googling > around does not show much help. The key files match. There is a bug in kerberos libraries that prevent Windows clients from successfully performing DDNS against BIND servers that we fixed only recently. This is the fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1066000 Not sure if this has been backported to RHEL/CentOS tbh. This is for Windows clients directly performing DDNS updates using GSS-TSIG. -- Now reading the following lines it seem you are mixing GSS-TSIG and plain TSIG, well you can't do that. ATM I think we accept only GSS-TSIG updates in IPA, while BIND DHCP seem to be capable only of TSIG updates. CCing Petr as he may have some ideas on whether this is something we can work around. Simo. > > > My named.conf is as follows: > > > > [root at alfred ~]# cat /etc/named.conf > > options { > > // turns on IPv6 for port 53, IPv4 is on by default for all ifaces > > listen-on-v6 {any;}; > > listen-on port 53 { 127.0.0.1; 10.0.1.2; }; > > > > // Put files that named is allowed to write in the data/ directory: > > directory "/var/named"; // the default > > dump-file "data/cache_dump.db"; > > statistics-file "data/named_stats.txt"; > > memstatistics-file "data/named_mem_stats.txt"; > > > > //forward first; > > //forwarders { > > // 192.168.1.254; > > // 8.8.8.8; > > //}; > > > > // Any host is permitted to issue recursive queries > > allow-recursion { any; }; > > > > tkey-gssapi-credential "DNS/alfred.xxxxxxx.com "; > > tkey-domain "xxxxxxx.COM"; > > }; > > > > include "/etc/named/ddns.key"; > > > > /* If you want to enable debugging, eg. using the 'rndc trace' command, > > * By default, SELinux policy does not allow named to modify the /var/named > directory, > > * so put the default debug log file in data/ : > > */ > > logging { > > channel default_debug { > > file "data/named.run"; > > severity dynamic; > > }; > > }; > > > > zone "." IN { > > type hint; > > file "named.ca "; > > }; > > > > include "/etc/named.rfc1912.zones"; > > > > dynamic-db "ipa" { > > library "ldap.so"; > > arg "uri ldapi://%2fvar%2frun%2fslapd-xxxxxxx-COM.socket"; > > arg "base cn=dns, dc=xxxxxxx,dc=com"; > > arg "fake_mname alfred.xxxxxxx.com ."; > > arg "auth_method sasl"; > > arg "sasl_mech GSSAPI"; > > arg "sasl_user DNS/alfred.xxxxxxx.com "; > > arg "zone_refresh 0"; > > arg "psearch yes"; > > arg "serial_autoincrement yes"; > > }; > > > > My dhcpd.conf is as follows: > > [root at alfred ~]# cat /etc/dhcp/dhcpd.conf > > # dhcpd.conf > > # > > # Sample configuration file for ISC dhcpd > > # > > > > # option definitions common to all supported networks... > > option domain-name "xxxxxxx.com "; > > option domain-name-servers 10.0.1.2, 8.8.8.8, 8.8.4.4; > > > > ddns-updates on; > > ddns-update-style interim; > > ignore client-updates; > > update-static-leases on; > > > > default-lease-time 600; > > max-lease-time 7200; > > > > # Use this to enble / disable dynamic dns updates globally. > > #ddns-update-style none; > > > > # If this DHCP server is the official DHCP server for the local > > # network, the authoritative directive should be uncommented. > > authoritative; > > > > # Use this to send dhcp log messages to a different log file (you also > > # have to hack syslog.conf to complete the redirection). > > log-facility local7; > > > > # No service will be given on this subnet, but declaring it helps the > > # DHCP server to understand the network topology. > > > > #subnet 10.152.187.0 netmask 255.255.255.0 { > > #} > > > > include "/etc/dhcp/ddns.key"; > > > > zone xxxxxxx.com . { > > primary 127.0.0.1; > > key DDNS_UPDATE; > > } > > > > zone 2.0.10.in-addr.arpa. { > > primary 127.0.0.1; > > key DDNS_UPDATE; > > } > > > > # This is a very basic subnet declaration. > > > > subnet 10.0.0.0 netmask 255.255.0.0 { > > range 10.0.2.50 10.0.2.250; > > option routers 10.0.1.2; > > } > > > > [root at alfred ~]# > > > > When windows client gets a dhcp address, the following is in the log > > > > [root at alfred ~]# tail -n50 /var/log/messages > > Apr 2 19:40:50 alfred named[8491]: client 127.0.0.1#59786: updating zone > 'xxxxxxx.com/IN ': update failed: rejected by secure update (REFUSED) > > Apr 2 19:40:50 alfred dhcpd: Unable to add forward map from > atomlin.xxxxxxx.com to 10.0.2.51 : timed out > > Apr 2 19:40:50 alfred dhcpd: DHCPREQUEST for 10.0.2.51 from > 0c:54:a5:08:5f:cc (atomlin) via eth0 > > Apr 2 19:40:50 alfred dhcpd: DHCPACK on 10.0.2.51 to 0c:54:a5:08:5f:cc > (atomlin) via eth0 > > [root at alfred ~]# > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From stacy.redmond at blueshieldca.com Thu Apr 3 18:05:08 2014 From: stacy.redmond at blueshieldca.com (Redmond, Stacy) Date: Thu, 3 Apr 2014 11:05:08 -0700 Subject: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory In-Reply-To: References: Message-ID: <77D4DA314ADF354BBE2686CBBAB9DD790D404E00@EDHC01WEX02.bsc.bscal.com> I have this same exact issue. I have not only verified that DNS is functioning properly, I have also added the AD server to the local hosts file as is the reported fix for this issue and it still persists. [root at linuxtest1 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) [root at linuxtest1 ~]# uname -a Linux linuxtest1.sbx.local 2.6.32-431.11.2.el6.x86_64 #1 SMP Mon Mar 3 13:32:45 EST 2014 x86_64 x86_64 x86_64 GNU/Linux [root at linuxtest1 ~]# nslookup wdir901sbx.sbx.local Server: 10.130.82.20 Address: 10.130.82.20#53 Name: wdir901sbx.sbx.local Address: 10.130.82.20 [root at linuxtest1 ~]# nslookup 10.130.82.20 Server: 10.130.82.20 Address: 10.130.82.20#53 20.82.130.10.in-addr.arpa name = wdir901sbx.sbx.local. [root at linuxtest1 ~]# dig SRV _ldap._tcp.ad.sbx.local ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> SRV _ldap._tcp.ad.sbx.local ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50435 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;_ldap._tcp.ad.sbx.local. IN SRV ;; AUTHORITY SECTION: sbx.local. 3600 IN SOA wdir901sbx.sbx.local. hostmaster. 4715 900 600 86400 3600 ;; Query time: 0 msec ;; SERVER: 10.130.82.20#53(10.130.82.20) ;; WHEN: Thu Apr 3 10:34:02 2014 ;; MSG SIZE rcvd: 107 [root at linuxtest1 ~]# ipa trust-add --type=ad ad.sbx.local --admin 'admsredmo01' --password Active directory domain administrator's password: ipa: ERROR: Cannot find specified domain or server name [root at linuxtest1 ~]# [root at linuxtest1 ~]# ipa trust-add --type=ad sbx.local --admin 'admsredmo01' --password Active directory domain administrator's password: ipa: ERROR: Cannot find specified domain or server name [root at linuxtest1 ~]# Any and all help would be appreciated. -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of freeipa-users-request at redhat.com Sent: Thursday, April 03, 2014 9:00 AM To: freeipa-users at redhat.com Subject: Freeipa-users Digest, Vol 69, Issue 20 Send Freeipa-users mailing list submissions to freeipa-users at redhat.com To subscribe or unsubscribe via the World Wide Web, visit https://www.redhat.com/mailman/listinfo/freeipa-users or, via email, send a message with subject or body 'help' to freeipa-users-request at redhat.com You can reach the person managing the list at freeipa-users-owner at redhat.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Freeipa-users digest..." Today's Topics: 1. Re: Unable to establish trust with FreeIPA and Active Directory (Sumit Bose) ---------------------------------------------------------------------- Message: 1 Date: Thu, 3 Apr 2014 16:53:31 +0200 From: Sumit Bose To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory Message-ID: <20140403145331.GN11404 at localhost.localdomain> Content-Type: text/plain; charset=us-ascii On Thu, Apr 03, 2014 at 02:31:55PM +0000, Matthew W Hanley wrote: > I'm in the midst of setting up a trust with FreeIPA and Active Directory and am receiving the following error: > > # ipa trust-add --type=ad ad.example.com --admin 'mwhanley' --password > Active directory domain administrator's password: > > ipa: ERROR: Cannot find specified domain or server name looks like a DNS issue. Can you check if dig SRV _ldap._tcp.ad.example.com returns a list of IP addresses for your AD DCs? If not you might want to have a look at www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#DNS_configuration . HTH bye, Sumit > > The FreeIPA server is running Fedora release 20, version 3.3.3-4 of FreeIPA and I have turned on debugging and get the following: > > ps [Wed Apr 02 10:20:53.766064 2014] [:error] [pid 32522] ipa: INFO: > admin at ipaexample.com: trust_add(u'ad.example.com', trust_type=u'ad', > realm_admin=u'mwhanley', realm_passwd=u'********', all=False, > raw=False, version=u'2.65'): NotFound [Wed Apr 02 10:21:29.635077 > 2014] [:error] [pid 32521] ipa: INFO: admin at ipaexample.com: > idrange_find(None, all=False, raw=False, version=u'2.65', > pkey_only=False): SUCCESS > INFO: Current debug levels: > all: 11 > tdb: 11 > printdrivers: 11 > lanman: 11 > smb: 11 > rpc_parse: 11 > rpc_srv: 11 > rpc_cli: 11 > passdb: 11 > sam: 11 > auth: 11 > winbind: 11 > vfs: 11 > idmap: 11 > quota: 11 > acls: 11 > locking: 11 > msdfs: 11 > dmapi: 11 > registry: 11 > scavenger: 11 > dns: 11 > ldb: 11 > pm_process() returned Yes > Using binding ncacn_np:host.ipaexample.com[,] Mapped to DCERPC > endpoint \pipe\lsarpc added interface eth0 ip=xxx.xxx.xxx.xxx > bcast=xxx.xxx.xxx.xxx netmask=255.255.255.0 added interface eth0 > ip=xxx.xxx.xxx.xxx bcast=xxx.xxx.xxx.xxx netmask=255.255.255.0 Socket > options: > SO_KEEPALIVE = 0 > SO_REUSEADDR = 0 > SO_BROADCAST = 0 > TCP_NODELAY = 1 > TCP_KEEPCNT = 9 > TCP_KEEPIDLE = 7200 > TCP_KEEPINTVL = 75 > IPTOS_LOWDELAY = 0 > IPTOS_THROUGHPUT = 0 > SO_REUSEPORT = 0 > SO_SNDBUF = 663750 > SO_RCVBUF = 265452 > SO_SNDLOWAT = 1 > SO_RCVLOWAT = 1 > SO_SNDTIMEO = 0 > SO_RCVTIMEO = 0 > TCP_QUICKACK = 1 > TCP_DEFER_ACCEPT = 0 > Starting GENSEC mechanism spnego > Starting GENSEC submechanism gssapi_krb5 Ticket in credentials cache > for admin at ipaexample.com will expire in 84015 secs > gensec_gssapi: NO credentials were delegated GSSAPI Connection will be > cryptographically sealed > > I've also done an "ipactl restart" to no avail. Any help would be appreciated. > > -Matt > > > Matthew Hanley > IT Analyst > Syracuse University > mwhanley at syr.edu > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users ------------------------------ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users End of Freeipa-users Digest, Vol 69, Issue 20 ********************************************* From abokovoy at redhat.com Thu Apr 3 19:12:02 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 3 Apr 2014 22:12:02 +0300 Subject: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory In-Reply-To: <77D4DA314ADF354BBE2686CBBAB9DD790D404E00@EDHC01WEX02.bsc.bscal.com> References: <77D4DA314ADF354BBE2686CBBAB9DD790D404E00@EDHC01WEX02.bsc.bscal.com> Message-ID: <20140403191202.GA4947@redhat.com> On Thu, 03 Apr 2014, Redmond, Stacy wrote: >I have this same exact issue. I have not only verified that DNS is >functioning properly, I have also added the AD server to the local hosts >file as is the reported fix for this issue and it still persists. add log level = 100 to [global] section in /usr/share/ipa/smb.conf.empty and try 'ipa trust-add' again. You'll get debug output in httpd's error_log. I'd like to see level 100 logs, they give a bit more details in case of SMB Python bindings. -- / Alexander Bokovoy From stacy.redmond at blueshieldca.com Thu Apr 3 20:22:51 2014 From: stacy.redmond at blueshieldca.com (Redmond, Stacy) Date: Thu, 3 Apr 2014 13:22:51 -0700 Subject: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory In-Reply-To: <20140403191202.GA4947@redhat.com> References: <77D4DA314ADF354BBE2686CBBAB9DD790D404E00@EDHC01WEX02.bsc.bscal.com> <20140403191202.GA4947@redhat.com> Message-ID: <77D4DA314ADF354BBE2686CBBAB9DD790D404F68@EDHC01WEX02.bsc.bscal.com> Yes, I did that, here is the log [Thu Apr 03 13:21:52 2014] [error] [client 10.130.82.68] Credentials for HTTP/linuxtest1.sbx.local at UNIX have expired or will soon expire - now 1396556512 endtime 1396551629, referer: https://linuxtest1.sbx.local/ipa/xml [Thu Apr 03 13:21:52 2014] [error] [client 10.130.82.68] Credentials for HTTP/linuxtest1.sbx.local at UNIX have expired or will soon expire - now 1396556512 endtime 1396551629, referer: https://linuxtest1.sbx.local/ipa/xml [Thu Apr 03 13:21:52 2014] [error] ipa: INFO: admin at UNIX: ping(): SUCCESS [Thu Apr 03 13:21:55 2014] [error] ipa: INFO: admin at UNIX: trust_add(u'sbx.local', trust_type=u'ad', realm_admin=u'admsredmo01', realm_passwd=u'********', range_size=200000, all=False, raw=False, version=u'2.49'): NotFound -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Thursday, April 03, 2014 12:12 PM To: Redmond, Stacy Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory On Thu, 03 Apr 2014, Redmond, Stacy wrote: >I have this same exact issue. I have not only verified that DNS is >functioning properly, I have also added the AD server to the local >hosts file as is the reported fix for this issue and it still persists. add log level = 100 to [global] section in /usr/share/ipa/smb.conf.empty and try 'ipa trust-add' again. You'll get debug output in httpd's error_log. I'd like to see level 100 logs, they give a bit more details in case of SMB Python bindings. -- / Alexander Bokovoy From william at firstyear.id.au Thu Apr 3 22:29:12 2014 From: william at firstyear.id.au (William Brown) Date: Fri, 04 Apr 2014 08:59:12 +1030 Subject: [Freeipa-users] DDNS with DHCPD and IPA In-Reply-To: <006c01cf4f66$d8ad5390$8a07fab0$@engineer.com> References: <006c01cf4f66$d8ad5390$8a07fab0$@engineer.com> Message-ID: <1396564152.4265.20.camel@strawberry.ad.adelaide.edu.au> On Thu, 2014-04-03 at 11:02 -0700, Andy Tomlin wrote: > That would be my preference, would then work same as bind/dhcpd before > switching to ipa. I just dont know how to do it correctly. > > This assumes dhcp and named are on the same system. For an unrelated project I wrote some docs here: http://tollgate.readthedocs.org/en/3.0.1/fedora-deploy.html#core-network And the example config files referenced are: https://github.com/micolous/tollgate/tree/master/docs/example/fedora The important parts are: rndc-confgen -a -r keyboard -b 256 chown named:named /etc/rndc.key In named.conf add after the options section: include "/etc/rndc.key"; In the zone (In ipa you will need to add this permission) grant rndc-key wildcard * ANY; Then in dhcpd: include "/etc/rndc.key"; And to the dhcpd range: zone dhcp.example.lan. { primary 127.0.0.1; key "rndc-key"; } zone 0.4.10.in-addr.arpa. { primary 127.0.0.1; key "rndc-key"; } This should coexist peacefully with freeipa, but try to make sure your DDNS updated zone is say dhcp.example.com rather than a zone you care about. Consider you have a domain controller called x.example.com, and you allow DDNS to example.com. If someone set their hostname to x, they could take over the DNS records for your DC. Better to have a second zone to prevent this. -- William Brown From rmeggins at redhat.com Thu Apr 3 22:32:37 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 03 Apr 2014 16:32:37 -0600 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: References: <533B11F6.3040603@redhat.com> <533B300D.6050707@redhat.com> <533B3296.1020409@redhat.com> <533C14BA.1030307@redhat.com> <533C26D9.7060409@redhat.com> <533C2FBB.1020601@redhat.com> <533C308E.8000303@redhat.com> <533C4D9F.4050807@redhat.com> <533CBBAA.9040905@redhat.com> <533D726D.4080909@redhat.com> Message-ID: <533DE185.7040502@redhat.com> On 04/03/2014 03:46 PM, Nevada Sanchez wrote: > Okay, I updated the gist and extended some of the logs (ipa2-errors > does stop at 20:50:21). I'll follow up when I have the debug stuff in > place. > > https://gist.github.com/nevsan/8b6f78d7396963dc5f70 Another strange thing - it looks as if the initial replica init completes successfully. [02/Apr/2014:20:50:18 +0000] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=meToipa2.example.com" (ipa2:389)". On the replica: [02/Apr/2014:20:50:18 +0000] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=example,dc=com is going offline; disabling replication [02/Apr/2014:20:50:18 +0000] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [02/Apr/2014:20:50:21 +0000] - import userRoot: Workers finished; cleaning up... [02/Apr/2014:20:50:21 +0000] - import userRoot: Workers cleaned up. [02/Apr/2014:20:50:21 +0000] - import userRoot: Indexing complete. Post-processing... [02/Apr/2014:20:50:21 +0000] - import userRoot: Generating numSubordinates complete. [02/Apr/2014:20:50:21 +0000] - import userRoot: Flushing caches... [02/Apr/2014:20:50:21 +0000] - import userRoot: Closing files... [02/Apr/2014:20:50:21 +0000] - import userRoot: Import complete. Processed 453 entries in 3 seconds. (151.00 entries/sec) [02/Apr/2014:20:50:21 +0000] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=example,dc=com is coming online; enabling replication On the master, access log: [02/Apr/2014:20:50:17 +0000] conn=1365 op=15 MOD dn="cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" This is the operation that triggers the replica init. Then ipa-replica-install polls for agreement status: [02/Apr/2014:20:50:19 +0000] conn=1365 op=16 SRCH base="cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5replicaLastInitEnd" [02/Apr/2014:20:50:19 +0000] conn=1365 op=16 RESULT err=0 tag=101 nentries=1 etime=0 [02/Apr/2014:20:50:20 +0000] conn=1365 op=17 SRCH base="cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5replicaLastInitEnd" [02/Apr/2014:20:50:20 +0000] conn=1365 op=17 RESULT err=0 tag=101 nentries=1 etime=0 [02/Apr/2014:20:50:21 +0000] conn=1365 op=18 SRCH base="cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5replicaLastInitEnd" [02/Apr/2014:20:50:21 +0000] conn=1365 op=18 RESULT err=0 tag=101 nentries=1 etime=0 [02/Apr/2014:20:50:22 +0000] conn=1365 op=19 SRCH base="cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5replicaLastInitEnd" [02/Apr/2014:20:50:22 +0000] conn=1365 op=19 RESULT err=0 tag=101 nentries=1 etime=1 Something happens here. The replica init is done, according to the replica error log. We don't have the replica access log from around this time to see exactly when the connection was closed, but looking at the ipa code, it would appear that ipa did not see a status of "Total update succeeded". Not sure why the master would not have reported that, unless there was some problem getting back the status from the replica. [02/Apr/2014:20:50:22 +0000] conn=1365 op=20 UNBIND [02/Apr/2014:20:50:22 +0000] conn=1365 op=20 fd=114 closed - U1 Then ipa-replica-install closes the connection and reports the error. > > > On Thu, Apr 3, 2014 at 10:38 AM, Rich Megginson > wrote: > > On 04/02/2014 09:22 PM, Nevada Sanchez wrote: >> Okay. Updated the gist with the additional logs: >> https://gist.github.com/nevsan/8b6f78d7396963dc5f70 >> >> > > 1) Dirsrv is crashing: > [02/Apr/2014:20:49:53 +0000] - 389-Directory/1.3.1.22.a1 > B2014.073.1751 starting up > [02/Apr/2014:20:49:54 +0000] - Db home directory is not set. > Possibly nsslapd-directory (optionally nsslapd-db-home-directory) > is missing in the config file. > [02/Apr/2014:20:49:54 +0000] - I'm resizing my cache now...cache > was 710029312 and is now 8000000 > [02/Apr/2014:20:49:54 +0000] - 389-Directory/1.3.1.22.a1 > B2014.073.1751 starting up > [02/Apr/2014:20:49:54 +0000] - Detected Disorderly Shutdown last > time Directory Server was running, recovering database. > [02/Apr/2014:20:49:55 +0000] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > > Please use the instructions at > http://port389.org/wiki/FAQ#Debugging_Crashes to get a core dump > and stack trace. > > 2) The first occurrence of the connection error is at > [02/Apr/2014:20:52:38 +0000] but there isn't anything in the > consumer error log after [02/Apr/2014:20:50:21 +0000] and in the > consumer access log after [02/Apr/2014:20:50:22 +0000] > > >> On Wed, Apr 2, 2014 at 9:38 PM, Rich Megginson >> > wrote: >> >> On 04/02/2014 03:01 PM, Nevada Sanchez wrote: >>> Okay, I ran it with debug on. The output is quite large. I'm >>> not sure what the etiquette is for posting large logs, so I >>> threw it on gist here: >>> https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt >>> >>> >>> >>> Let me know if I should copy it into the thread instead. >> >> Ok. Now can you post excerpts from the dirsrv errors log >> from both the master replica and the replica from around the >> time of the failure? >> >> >>> >>> >>> On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson >>> > wrote: >>> >>> On 04/02/2014 11:45 AM, Nevada Sanchez wrote: >>>> My apologies. I mistakenly ran the failing ldapsearch >>>> from an unpriviliged user (couldn't read >>>> slapd-EXAMPLE-COM directory). Running as root, it now >>>> works just fine (same result as the one that worked). >>>> SSL seems to not be the issue. Also, I haven't change >>>> the SSL certs since I first set up the master. >>>> >>>> I have been doing the replica side things from scratch >>>> (even so far as starting with a new machine). For the >>>> master side, I have just been re-preparing the replica. >>>> I hope I don't have to start from scratch with the >>>> master replica. >>> >>> I guess the next step would be to do the >>> ipa-replica-install using -ddd and review the extra >>> debug information that comes out. >>> >>> >>>> >>>> >>>> On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden >>>> > wrote: >>>> >>>> Rich Megginson wrote: >>>> >>>> On 04/02/2014 09:20 AM, Nevada Sanchez wrote: >>>> >>>> Okay, we might be on to something: >>>> >>>> ipa -> ipa2 >>>> ================================ >>>> $ >>>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM >>>> ldapsearch -xLLLZZ >>>> -h ipa2.example.com >>>> >>>> -s base -b "" >>>> >>>> 'objectclass=*' vendorVersion >>>> dn: >>>> vendorVersion: 389-Directory/1.3.1.22.a1 >>>> B2014.073.1751 >>>> ================================ >>>> >>>> ipa2 -> ipa >>>> ================================ >>>> $ >>>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM >>>> ldapsearch -xLLLZZ >>>> -h ipa.example.com >>>> -s base -b "" >>>> >>>> 'objectclass=*' vendorVersion >>>> ldap_start_tls: Connect error (-11) >>>> additional info: TLS error -8172:Peer's >>>> certificate issuer has been >>>> marked as not trusted by the user. >>>> ================================ >>>> >>>> The original IPA trusts the replica (since >>>> it signed the cert, I >>>> assume), but the replica doesn't trust the >>>> main IPA server. I guess >>>> the ZZ option would have shown me the >>>> failure that I missed in my >>>> initial ldapsearch tests. >>>> >>>> -Z[Z] Issue StartTLS (Transport Layer >>>> Security) extended >>>> operation. If >>>> you use -ZZ, the command will require the >>>> operation to >>>> be suc- >>>> cessful. >>>> >>>> i.e. use SSL, and force a successful handshake >>>> >>>> >>>> Anyway, what's the best way to remedy this >>>> in a way that makes IPA >>>> happy? (I've found that LDAP can have >>>> different requirements on which >>>> certs go where). >>>> >>>> >>>> I'm not sure. >>>> ipa-server-install/ipa-replica-prepare/ipa-replica-install >>>> is supposed to take care of installing the CA >>>> cert properly for you. If >>>> you try to hack it and install the CA cert >>>> manually, you will probably >>>> miss something else that ipa install did not do. >>>> >>>> I think the only way to ensure that you have a >>>> properly configured ipa >>>> server + replicas is to get all of the ipa >>>> commands completing successfully. >>>> >>>> Which means going back to the drawing board and >>>> starting over from scratch. >>>> >>>> >>>> You can compare the certs that each side is using with: >>>> >>>> # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM >>>> >>>> Did you by chance replace the SSL server certs that >>>> IPA uses on your working master? >>>> >>>> rob >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From atomlin at engineer.com Thu Apr 3 23:50:02 2014 From: atomlin at engineer.com (Andy Tomlin) Date: Thu, 3 Apr 2014 16:50:02 -0700 Subject: [Freeipa-users] DDNS with DHCPD and IPA In-Reply-To: <1396564152.4265.20.camel@strawberry.ad.adelaide.edu.au> References: <006c01cf4f66$d8ad5390$8a07fab0$@engineer.com> <1396564152.4265.20.camel@strawberry.ad.adelaide.edu.au> Message-ID: <008701cf4f97$6f7e06e0$4e7a14a0$@engineer.com> Awesome, adding the grant line with my key (DDNS_UPDATE) did the trick. This makes it perform exactly like old config. Thanks for the help. Someone should put this example in the docs. -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of William Brown Sent: Thursday, April 3, 2014 3:29 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] DDNS with DHCPD and IPA On Thu, 2014-04-03 at 11:02 -0700, Andy Tomlin wrote: > That would be my preference, would then work same as bind/dhcpd before > switching to ipa. I just dont know how to do it correctly. > > This assumes dhcp and named are on the same system. For an unrelated project I wrote some docs here: http://tollgate.readthedocs.org/en/3.0.1/fedora-deploy.html#core-network And the example config files referenced are: https://github.com/micolous/tollgate/tree/master/docs/example/fedora The important parts are: rndc-confgen -a -r keyboard -b 256 chown named:named /etc/rndc.key In named.conf add after the options section: include "/etc/rndc.key"; In the zone (In ipa you will need to add this permission) grant rndc-key wildcard * ANY; Then in dhcpd: include "/etc/rndc.key"; And to the dhcpd range: zone dhcp.example.lan. { primary 127.0.0.1; key "rndc-key"; } zone 0.4.10.in-addr.arpa. { primary 127.0.0.1; key "rndc-key"; } This should coexist peacefully with freeipa, but try to make sure your DDNS updated zone is say dhcp.example.com rather than a zone you care about. Consider you have a domain controller called x.example.com, and you allow DDNS to example.com. If someone set their hostname to x, they could take over the DNS records for your DC. Better to have a second zone to prevent this. -- William Brown _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From sanchez.nevada at gmail.com Thu Apr 3 21:46:41 2014 From: sanchez.nevada at gmail.com (Nevada Sanchez) Date: Thu, 3 Apr 2014 17:46:41 -0400 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: <533D726D.4080909@redhat.com> References: <533AF3D2.5050308@redhat.com> <533B11F6.3040603@redhat.com> <533B300D.6050707@redhat.com> <533B3296.1020409@redhat.com> <533C14BA.1030307@redhat.com> <533C26D9.7060409@redhat.com> <533C2FBB.1020601@redhat.com> <533C308E.8000303@redhat.com> <533C4D9F.4050807@redhat.com> <533CBBAA.9040905@redhat.com> <533D726D.4080909@redhat.com> Message-ID: Okay, I updated the gist and extended some of the logs (ipa2-errors does stop at 20:50:21). I'll follow up when I have the debug stuff in place. https://gist.github.com/nevsan/8b6f78d7396963dc5f70 On Thu, Apr 3, 2014 at 10:38 AM, Rich Megginson wrote: > On 04/02/2014 09:22 PM, Nevada Sanchez wrote: > > Okay. Updated the gist with the additional logs: > https://gist.github.com/nevsan/8b6f78d7396963dc5f70 > > > > 1) Dirsrv is crashing: > [02/Apr/2014:20:49:53 +0000] - 389-Directory/1.3.1.22.a1 B2014.073.1751 > starting up > [02/Apr/2014:20:49:54 +0000] - Db home directory is not set. Possibly > nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the > config file. > [02/Apr/2014:20:49:54 +0000] - I'm resizing my cache now...cache was > 710029312 and is now 8000000 > [02/Apr/2014:20:49:54 +0000] - 389-Directory/1.3.1.22.a1 B2014.073.1751 > starting up > [02/Apr/2014:20:49:54 +0000] - Detected Disorderly Shutdown last time > Directory Server was running, recovering database. > [02/Apr/2014:20:49:55 +0000] - slapd started. Listening on All Interfaces > port 389 for LDAP requests > > Please use the instructions at > http://port389.org/wiki/FAQ#Debugging_Crashes to get a core dump and > stack trace. > > 2) The first occurrence of the connection error is at > [02/Apr/2014:20:52:38 +0000] but there isn't anything in the consumer error > log after [02/Apr/2014:20:50:21 +0000] and in the consumer access log after > [02/Apr/2014:20:50:22 +0000] > > > On Wed, Apr 2, 2014 at 9:38 PM, Rich Megginson wrote: > >> On 04/02/2014 03:01 PM, Nevada Sanchez wrote: >> >> Okay, I ran it with debug on. The output is quite large. I'm not sure >> what the etiquette is for posting large logs, so I threw it on gist here: >> https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt >> >> Let me know if I should copy it into the thread instead. >> >> >> Ok. Now can you post excerpts from the dirsrv errors log from both the >> master replica and the replica from around the time of the failure? >> >> >> >> >> On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson wrote: >> >>> On 04/02/2014 11:45 AM, Nevada Sanchez wrote: >>> >>> My apologies. I mistakenly ran the failing ldapsearch from an >>> unpriviliged user (couldn't read slapd-EXAMPLE-COM directory). Running as >>> root, it now works just fine (same result as the one that worked). SSL >>> seems to not be the issue. Also, I haven't change the SSL certs since I >>> first set up the master. >>> >>> I have been doing the replica side things from scratch (even so far as >>> starting with a new machine). For the master side, I have just been >>> re-preparing the replica. I hope I don't have to start from scratch with >>> the master replica. >>> >>> >>> I guess the next step would be to do the ipa-replica-install using -ddd >>> and review the extra debug information that comes out. >>> >>> >>> >>> >>> On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden wrote: >>> >>>> Rich Megginson wrote: >>>> >>>>> On 04/02/2014 09:20 AM, Nevada Sanchez wrote: >>>>> >>>>>> Okay, we might be on to something: >>>>>> >>>>>> ipa -> ipa2 >>>>>> ================================ >>>>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ >>>>>> -h ipa2.example.com -s base -b "" >>>>>> >>>>>> 'objectclass=*' vendorVersion >>>>>> dn: >>>>>> vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 >>>>>> ================================ >>>>>> >>>>>> ipa2 -> ipa >>>>>> ================================ >>>>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ >>>>>> -h ipa.example.com -s base -b "" >>>>>> >>>>>> 'objectclass=*' vendorVersion >>>>>> ldap_start_tls: Connect error (-11) >>>>>> additional info: TLS error -8172:Peer's certificate issuer has been >>>>>> marked as not trusted by the user. >>>>>> ================================ >>>>>> >>>>>> The original IPA trusts the replica (since it signed the cert, I >>>>>> assume), but the replica doesn't trust the main IPA server. I guess >>>>>> the ZZ option would have shown me the failure that I missed in my >>>>>> initial ldapsearch tests. >>>>>> >>>>> -Z[Z] Issue StartTLS (Transport Layer Security) extended >>>>> operation. If >>>>> you use -ZZ, the command will require the operation to >>>>> be suc- >>>>> cessful. >>>>> >>>>> i.e. use SSL, and force a successful handshake >>>>> >>>>> >>>>>> Anyway, what's the best way to remedy this in a way that makes IPA >>>>>> happy? (I've found that LDAP can have different requirements on which >>>>>> certs go where). >>>>>> >>>>> >>>>> I'm not sure. >>>>> ipa-server-install/ipa-replica-prepare/ipa-replica-install >>>>> is supposed to take care of installing the CA cert properly for you. If >>>>> you try to hack it and install the CA cert manually, you will probably >>>>> miss something else that ipa install did not do. >>>>> >>>>> I think the only way to ensure that you have a properly configured ipa >>>>> server + replicas is to get all of the ipa commands completing >>>>> successfully. >>>>> >>>>> Which means going back to the drawing board and starting over from >>>>> scratch. >>>>> >>>> >>>> You can compare the certs that each side is using with: >>>> >>>> # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM >>>> >>>> Did you by chance replace the SSL server certs that IPA uses on your >>>> working master? >>>> >>>> rob >>>> >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Apr 4 04:34:06 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 4 Apr 2014 07:34:06 +0300 Subject: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory In-Reply-To: <77D4DA314ADF354BBE2686CBBAB9DD790D404F68@EDHC01WEX02.bsc.bscal.com> References: <77D4DA314ADF354BBE2686CBBAB9DD790D404E00@EDHC01WEX02.bsc.bscal.com> <20140403191202.GA4947@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D404F68@EDHC01WEX02.bsc.bscal.com> Message-ID: <20140404043406.GV3094@redhat.com> On Thu, 03 Apr 2014, Redmond, Stacy wrote: >Yes, I did that, here is the log > >[Thu Apr 03 13:21:52 2014] [error] [client 10.130.82.68] Credentials for >HTTP/linuxtest1.sbx.local at UNIX have expired or will soon expire - now >1396556512 endtime 1396551629, referer: >https://linuxtest1.sbx.local/ipa/xml >[Thu Apr 03 13:21:52 2014] [error] [client 10.130.82.68] Credentials for >HTTP/linuxtest1.sbx.local at UNIX have expired or will soon expire - now >1396556512 endtime 1396551629, referer: >https://linuxtest1.sbx.local/ipa/xml >[Thu Apr 03 13:21:52 2014] [error] ipa: INFO: admin at UNIX: ping(): >SUCCESS >[Thu Apr 03 13:21:55 2014] [error] ipa: INFO: admin at UNIX: >trust_add(u'sbx.local', trust_type=u'ad', realm_admin=u'admsredmo01', >realm_passwd=u'********', range_size=200000, all=False, raw=False, >version=u'2.49'): NotFound No, you haven't. This is not the log entries I'd expect. Between ping() and trust_add() line there should be a lot of debug output from Samba Python code. > >-----Original Message----- >From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >Sent: Thursday, April 03, 2014 12:12 PM >To: Redmond, Stacy >Cc: freeipa-users at redhat.com >Subject: Re: [Freeipa-users] Unable to establish trust with FreeIPA and >Active Directory > >On Thu, 03 Apr 2014, Redmond, Stacy wrote: >>I have this same exact issue. I have not only verified that DNS is >>functioning properly, I have also added the AD server to the local >>hosts file as is the reported fix for this issue and it still persists. >add > >log level = 100 > >to [global] section in /usr/share/ipa/smb.conf.empty > >and try 'ipa trust-add' again. > >You'll get debug output in httpd's error_log. > >I'd like to see level 100 logs, they give a bit more details in case of >SMB Python bindings. > >-- >/ Alexander Bokovoy -- / Alexander Bokovoy From sanchez.nevada at gmail.com Fri Apr 4 04:25:19 2014 From: sanchez.nevada at gmail.com (Nevada Sanchez) Date: Fri, 4 Apr 2014 00:25:19 -0400 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: <533DE185.7040502@redhat.com> References: <533B11F6.3040603@redhat.com> <533B300D.6050707@redhat.com> <533B3296.1020409@redhat.com> <533C14BA.1030307@redhat.com> <533C26D9.7060409@redhat.com> <533C2FBB.1020601@redhat.com> <533C308E.8000303@redhat.com> <533C4D9F.4050807@redhat.com> <533CBBAA.9040905@redhat.com> <533D726D.4080909@redhat.com> <533DE185.7040502@redhat.com> Message-ID: I followed the instructions that would give me a core dump, and for some reason, I don't see one in /var/log/dirsrv/slapd-EXAMPLE-COM/, even though I still see the Disorderly shutdown still shows up in the logs. I know that when I explicitly request those attributes, I get "-1 Total update abortedLDAP error: Can't contact LDAP server" for nds5ReplicaLastInitStatus (see below). Access logs stop completely on the replica after the time that you mentioned. ====================================================== [root at ipa2 ipaserver]# ldapsearch ldaps://ipa.example.com:636 -D 'cn=Directory Manager' -w ##### -b 'cn=meToipa2.example.com,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config' '(objectClass=*)' -s base nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5ReplicaLastInitEnd # extended LDIF # # LDAPv3 # base ,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config> with scope baseObject # filter: (objectclass=*) # requesting: ldaps://ipa.example.com:636 (objectClass=*) nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5ReplicaLastInitEnd # # meToipa2.example.com , replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config dn: cn=meToipa2.example.com ,cn=replica,cn=dc\3Dexample\2Cd c\3Dcom,cn=mapping tree,cn=config nsds5ReplicaLastInitStart: 20140401092800Z nsds5replicaUpdateInProgress: FALSE nsds5ReplicaLastInitStatus: -1 Total update abortedLDAP error: Can't contact L DAP server cn: meToipa2.example.com nsds5ReplicaLastInitEnd: 20140401092804Z # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 On Thu, Apr 3, 2014 at 6:32 PM, Rich Megginson wrote: > On 04/03/2014 03:46 PM, Nevada Sanchez wrote: > > Okay, I updated the gist and extended some of the logs (ipa2-errors does > stop at 20:50:21). I'll follow up when I have the debug stuff in place. > > https://gist.github.com/nevsan/8b6f78d7396963dc5f70 > > > Another strange thing - it looks as if the initial replica init completes > successfully. > > [02/Apr/2014:20:50:18 +0000] NSMMReplicationPlugin - Beginning total > update of replica "agmt="cn=meToipa2.example.com" (ipa2:389)". > > On the replica: > > [02/Apr/2014:20:50:18 +0000] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=example,dc=com is going offline; > disabling replication > [02/Apr/2014:20:50:18 +0000] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to access the > database > [02/Apr/2014:20:50:21 +0000] - import userRoot: Workers finished; cleaning > up... > [02/Apr/2014:20:50:21 +0000] - import userRoot: Workers cleaned up. > [02/Apr/2014:20:50:21 +0000] - import userRoot: Indexing complete. > Post-processing... > [02/Apr/2014:20:50:21 +0000] - import userRoot: Generating numSubordinates > complete. > [02/Apr/2014:20:50:21 +0000] - import userRoot: Flushing caches... > [02/Apr/2014:20:50:21 +0000] - import userRoot: Closing files... > [02/Apr/2014:20:50:21 +0000] - import userRoot: Import complete. Processed > 453 entries in 3 seconds. (151.00 entries/sec) > [02/Apr/2014:20:50:21 +0000] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=example,dc=com is coming online; > enabling replication > > On the master, access log: > > [02/Apr/2014:20:50:17 +0000] conn=1365 op=15 MOD dn="cn= > meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config" > > This is the operation that triggers the replica init. Then > ipa-replica-install polls for agreement status: > [02/Apr/2014:20:50:19 +0000] conn=1365 op=16 SRCH base="cn= > meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config" scope=0 filter="(objectClass=*)" > attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress > nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh > nsds5replicaLastInitEnd" > [02/Apr/2014:20:50:19 +0000] conn=1365 op=16 RESULT err=0 tag=101 > nentries=1 etime=0 > [02/Apr/2014:20:50:20 +0000] conn=1365 op=17 SRCH base="cn= > meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config" scope=0 filter="(objectClass=*)" > attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress > nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh > nsds5replicaLastInitEnd" > [02/Apr/2014:20:50:20 +0000] conn=1365 op=17 RESULT err=0 tag=101 > nentries=1 etime=0 > [02/Apr/2014:20:50:21 +0000] conn=1365 op=18 SRCH base="cn= > meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config" scope=0 filter="(objectClass=*)" > attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress > nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh > nsds5replicaLastInitEnd" > [02/Apr/2014:20:50:21 +0000] conn=1365 op=18 RESULT err=0 tag=101 > nentries=1 etime=0 > [02/Apr/2014:20:50:22 +0000] conn=1365 op=19 SRCH base="cn= > meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config" scope=0 filter="(objectClass=*)" > attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress > nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh > nsds5replicaLastInitEnd" > [02/Apr/2014:20:50:22 +0000] conn=1365 op=19 RESULT err=0 tag=101 > nentries=1 etime=1 > > Something happens here. The replica init is done, according to the > replica error log. We don't have the replica access log from around this > time to see exactly when the connection was closed, but looking at the ipa > code, it would appear that ipa did not see a status of "Total update > succeeded". Not sure why the master would not have reported that, unless > there was some problem getting back the status from the replica. > > [02/Apr/2014:20:50:22 +0000] conn=1365 op=20 UNBIND > [02/Apr/2014:20:50:22 +0000] conn=1365 op=20 fd=114 closed - U1 > > Then ipa-replica-install closes the connection and reports the error. > > > > > On Thu, Apr 3, 2014 at 10:38 AM, Rich Megginson wrote: > >> On 04/02/2014 09:22 PM, Nevada Sanchez wrote: >> >> Okay. Updated the gist with the additional logs: >> https://gist.github.com/nevsan/8b6f78d7396963dc5f70 >> >> >> >> 1) Dirsrv is crashing: >> [02/Apr/2014:20:49:53 +0000] - 389-Directory/1.3.1.22.a1 B2014.073.1751 >> starting up >> [02/Apr/2014:20:49:54 +0000] - Db home directory is not set. Possibly >> nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the >> config file. >> [02/Apr/2014:20:49:54 +0000] - I'm resizing my cache now...cache was >> 710029312 and is now 8000000 >> [02/Apr/2014:20:49:54 +0000] - 389-Directory/1.3.1.22.a1 B2014.073.1751 >> starting up >> [02/Apr/2014:20:49:54 +0000] - Detected Disorderly Shutdown last time >> Directory Server was running, recovering database. >> [02/Apr/2014:20:49:55 +0000] - slapd started. Listening on All Interfaces >> port 389 for LDAP requests >> >> Please use the instructions at >> http://port389.org/wiki/FAQ#Debugging_Crashes to get a core dump and >> stack trace. >> >> 2) The first occurrence of the connection error is at >> [02/Apr/2014:20:52:38 +0000] but there isn't anything in the consumer error >> log after [02/Apr/2014:20:50:21 +0000] and in the consumer access log after >> [02/Apr/2014:20:50:22 +0000] >> >> >> On Wed, Apr 2, 2014 at 9:38 PM, Rich Megginson wrote: >> >>> On 04/02/2014 03:01 PM, Nevada Sanchez wrote: >>> >>> Okay, I ran it with debug on. The output is quite large. I'm not sure >>> what the etiquette is for posting large logs, so I threw it on gist here: >>> https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt >>> >>> Let me know if I should copy it into the thread instead. >>> >>> >>> Ok. Now can you post excerpts from the dirsrv errors log from both the >>> master replica and the replica from around the time of the failure? >>> >>> >>> >>> >>> On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson wrote: >>> >>>> On 04/02/2014 11:45 AM, Nevada Sanchez wrote: >>>> >>>> My apologies. I mistakenly ran the failing ldapsearch from an >>>> unpriviliged user (couldn't read slapd-EXAMPLE-COM directory). Running as >>>> root, it now works just fine (same result as the one that worked). SSL >>>> seems to not be the issue. Also, I haven't change the SSL certs since I >>>> first set up the master. >>>> >>>> I have been doing the replica side things from scratch (even so far >>>> as starting with a new machine). For the master side, I have just been >>>> re-preparing the replica. I hope I don't have to start from scratch with >>>> the master replica. >>>> >>>> >>>> I guess the next step would be to do the ipa-replica-install using >>>> -ddd and review the extra debug information that comes out. >>>> >>>> >>>> >>>> >>>> On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden wrote: >>>> >>>>> Rich Megginson wrote: >>>>> >>>>>> On 04/02/2014 09:20 AM, Nevada Sanchez wrote: >>>>>> >>>>>>> Okay, we might be on to something: >>>>>>> >>>>>>> ipa -> ipa2 >>>>>>> ================================ >>>>>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ >>>>>>> -h ipa2.example.com -s base -b "" >>>>>>> >>>>>>> 'objectclass=*' vendorVersion >>>>>>> dn: >>>>>>> vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 >>>>>>> ================================ >>>>>>> >>>>>>> ipa2 -> ipa >>>>>>> ================================ >>>>>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ >>>>>>> -h ipa.example.com -s base -b "" >>>>>>> >>>>>>> 'objectclass=*' vendorVersion >>>>>>> ldap_start_tls: Connect error (-11) >>>>>>> additional info: TLS error -8172:Peer's certificate issuer has been >>>>>>> marked as not trusted by the user. >>>>>>> ================================ >>>>>>> >>>>>>> The original IPA trusts the replica (since it signed the cert, I >>>>>>> assume), but the replica doesn't trust the main IPA server. I guess >>>>>>> the ZZ option would have shown me the failure that I missed in my >>>>>>> initial ldapsearch tests. >>>>>>> >>>>>> -Z[Z] Issue StartTLS (Transport Layer Security) extended >>>>>> operation. If >>>>>> you use -ZZ, the command will require the operation >>>>>> to >>>>>> be suc- >>>>>> cessful. >>>>>> >>>>>> i.e. use SSL, and force a successful handshake >>>>>> >>>>>> >>>>>>> Anyway, what's the best way to remedy this in a way that makes IPA >>>>>>> happy? (I've found that LDAP can have different requirements on which >>>>>>> certs go where). >>>>>>> >>>>>> >>>>>> I'm not sure. >>>>>> ipa-server-install/ipa-replica-prepare/ipa-replica-install >>>>>> is supposed to take care of installing the CA cert properly for you. >>>>>> If >>>>>> you try to hack it and install the CA cert manually, you will probably >>>>>> miss something else that ipa install did not do. >>>>>> >>>>>> I think the only way to ensure that you have a properly configured ipa >>>>>> server + replicas is to get all of the ipa commands completing >>>>>> successfully. >>>>>> >>>>>> Which means going back to the drawing board and starting over from >>>>>> scratch. >>>>>> >>>>> >>>>> You can compare the certs that each side is using with: >>>>> >>>>> # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM >>>>> >>>>> Did you by chance replace the SSL server certs that IPA uses on your >>>>> working master? >>>>> >>>>> rob >>>>> >>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stacy.redmond at blueshieldca.com Fri Apr 4 14:01:42 2014 From: stacy.redmond at blueshieldca.com (Redmond, Stacy) Date: Fri, 4 Apr 2014 07:01:42 -0700 Subject: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory In-Reply-To: <20140404043406.GV3094@redhat.com> References: <77D4DA314ADF354BBE2686CBBAB9DD790D404E00@EDHC01WEX02.bsc.bscal.com> <20140403191202.GA4947@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D404F68@EDHC01WEX02.bsc.bscal.com> <20140404043406.GV3094@redhat.com> Message-ID: <77D4DA314ADF354BBE2686CBBAB9DD790D4051BE@EDHC01WEX02.bsc.bscal.com> You are absolutlely right, I had rebuilt the server, and had forgotten to put the log level back in, here it is. [root at linuxtest1 ~]# cat /var/log/httpd/error_log /dev/null lpcfg_load: refreshing parameters from /usr/share/ipa/smb.conf.empty params.c:pm_process() - Processing configuration file "/usr/share/ipa/smb.conf.empty" Processing section "[global]" INFO: Current debug levels: all: 100 tdb: 100 printdrivers: 100 lanman: 100 smb: 100 rpc_parse: 100 rpc_srv: 100 rpc_cli: 100 passdb: 100 sam: 100 auth: 100 winbind: 100 vfs: 100 idmap: 100 quota: 100 acls: 100 locking: 100 msdfs: 100 dmapi: 100 registry: 100 pm_process() returned Yes Using binding ncacn_np:linuxtest1.unix.sbx.local[,] tevent: Added timed event "dcerpc_connect_timeout_handler": 0x7facb82d32b0 tevent: Added timed event "composite_trigger": 0x7facb8091400 tevent: Added timed event "composite_trigger": 0x7facb8091d30 tevent: Running timer event 0x7facb8091400 "composite_trigger" tevent: Destroying timer event 0x7facb8091d30 "composite_trigger" Mapped to DCERPC endpoint \pipe\lsarpc added interface eth0 ip=10.130.82.68 bcast=10.130.82.255 netmask=255.255.255.0 added interface eth0 ip=10.130.82.68 bcast=10.130.82.255 netmask=255.255.255.0 tevent: Ending timer event 0x7facb8091400 "composite_trigger" tevent: Added timed event "connect_multi_timer": 0x7facb80a1e70 tevent: Schedule immediate event "tevent_req_trigger": 0x7facb813fe80 tevent: Run immediate event "tevent_req_trigger": 0x7facb813fe80 tevent: Destroying timer event 0x7facb80a1e70 "connect_multi_timer" Socket options: SO_KEEPALIVE = 0 SO_REUSEADDR = 0 SO_BROADCAST = 0 TCP_NODELAY = 1 TCP_KEEPCNT = 9 TCP_KEEPIDLE = 7200 TCP_KEEPINTVL = 75 IPTOS_LOWDELAY = 0 IPTOS_THROUGHPUT = 0 SO_REUSEPORT = 0 SO_SNDBUF = 169160 SO_RCVBUF = 87380 SO_SNDLOWAT = 1 SO_RCVLOWAT = 1 SO_SNDTIMEO = 0 SO_RCVTIMEO = 0 TCP_QUICKACK = 1 TCP_DEFER_ACCEPT = 0 tevent: Added timed event "tevent_req_timedout": 0x7facb815c6c0 tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7facb832cd60 tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7facb832cd60 tevent: Destroying timer event 0x7facb815c6c0 "tevent_req_timedout" Starting GENSEC mechanism spnego Starting GENSEC submechanism gssapi_krb5 Ticket in credentials cache for admin at UNIX will expire in 36642 secs tevent: Added timed event "tevent_req_timedout": 0x7facb815ddc0 tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7facb832cd60 tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7facb832cd60 tevent: Destroying timer event 0x7facb815ddc0 "tevent_req_timedout" gensec_gssapi: NO credentials were delegated GSSAPI Connection will be cryptographically sealed tevent: Added timed event "tevent_req_timedout": 0x7facb815d5a0 tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7facb832cd60 tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7facb832cd60 tevent: Destroying timer event 0x7facb815d5a0 "tevent_req_timedout" tevent: Added timed event "tevent_req_timedout": 0x7facb8292850 tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7facb832cd60 tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7facb832cd60 tevent: Destroying timer event 0x7facb8292850 "tevent_req_timedout" tevent: Destroying timer event 0x7facb82d32b0 "dcerpc_connect_timeout_handler" [Fri Apr 04 06:59:43 2014] [error] ipa: INFO: admin at UNIX: trust_add(u'unix.sbx.local', trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', range_size=200000, all=False, raw=False, version=u'2.49'): NotFound [root at linuxtest1 ~]# -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Thursday, April 03, 2014 9:34 PM To: Redmond, Stacy Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory On Thu, 03 Apr 2014, Redmond, Stacy wrote: >Yes, I did that, here is the log > >[Thu Apr 03 13:21:52 2014] [error] [client 10.130.82.68] Credentials >for HTTP/linuxtest1.sbx.local at UNIX have expired or will soon expire - >now >1396556512 endtime 1396551629, referer: >https://linuxtest1.sbx.local/ipa/xml >[Thu Apr 03 13:21:52 2014] [error] [client 10.130.82.68] Credentials >for HTTP/linuxtest1.sbx.local at UNIX have expired or will soon expire - >now >1396556512 endtime 1396551629, referer: >https://linuxtest1.sbx.local/ipa/xml >[Thu Apr 03 13:21:52 2014] [error] ipa: INFO: admin at UNIX: ping(): >SUCCESS >[Thu Apr 03 13:21:55 2014] [error] ipa: INFO: admin at UNIX: >trust_add(u'sbx.local', trust_type=u'ad', realm_admin=u'admsredmo01', >realm_passwd=u'********', range_size=200000, all=False, raw=False, >version=u'2.49'): NotFound No, you haven't. This is not the log entries I'd expect. Between ping() and trust_add() line there should be a lot of debug output from Samba Python code. > >-----Original Message----- >From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >Sent: Thursday, April 03, 2014 12:12 PM >To: Redmond, Stacy >Cc: freeipa-users at redhat.com >Subject: Re: [Freeipa-users] Unable to establish trust with FreeIPA and >Active Directory > >On Thu, 03 Apr 2014, Redmond, Stacy wrote: >>I have this same exact issue. I have not only verified that DNS is >>functioning properly, I have also added the AD server to the local >>hosts file as is the reported fix for this issue and it still persists. >add > >log level = 100 > >to [global] section in /usr/share/ipa/smb.conf.empty > >and try 'ipa trust-add' again. > >You'll get debug output in httpd's error_log. > >I'd like to see level 100 logs, they give a bit more details in case of >SMB Python bindings. > >-- >/ Alexander Bokovoy -- / Alexander Bokovoy From abokovoy at redhat.com Fri Apr 4 15:25:22 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 4 Apr 2014 18:25:22 +0300 Subject: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory In-Reply-To: <77D4DA314ADF354BBE2686CBBAB9DD790D4051BE@EDHC01WEX02.bsc.bscal.com> References: <77D4DA314ADF354BBE2686CBBAB9DD790D404E00@EDHC01WEX02.bsc.bscal.com> <20140403191202.GA4947@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D404F68@EDHC01WEX02.bsc.bscal.com> <20140404043406.GV3094@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D4051BE@EDHC01WEX02.bsc.bscal.com> Message-ID: <20140404152522.GY3094@redhat.com> On Fri, 04 Apr 2014, Redmond, Stacy wrote: >You are absolutlely right, I had rebuilt the server, and had forgotten >to put the log level back in, here it is. > >[root at linuxtest1 ~]# cat /var/log/httpd/error_log >/dev/null >lpcfg_load: refreshing parameters from /usr/share/ipa/smb.conf.empty >params.c:pm_process() - Processing configuration file >"/usr/share/ipa/smb.conf.empty" >Processing section "[global]" >INFO: Current debug levels: > all: 100 > tdb: 100 > printdrivers: 100 > lanman: 100 > smb: 100 > rpc_parse: 100 > rpc_srv: 100 > rpc_cli: 100 > passdb: 100 > sam: 100 > auth: 100 > winbind: 100 > vfs: 100 > idmap: 100 > quota: 100 > acls: 100 > locking: 100 > msdfs: 100 > dmapi: 100 > registry: 100 >pm_process() returned Yes >Using binding ncacn_np:linuxtest1.unix.sbx.local[,] ^^ we first try to talk to local smbd process. >tevent: Destroying timer event 0x7facb8292850 "tevent_req_timedout" >tevent: Destroying timer event 0x7facb82d32b0 >"dcerpc_connect_timeout_handler" >[Fri Apr 04 06:59:43 2014] [error] ipa: INFO: admin at UNIX: >trust_add(u'unix.sbx.local', trust_type=u'ad', what is 'unix.sbx.local'? Is this an Active Directory domain? From your log I gather that it is FreeIPA domain, not AD. 'ipa trust-add' requires Active Directory domain as an argument. -- / Alexander Bokovoy From stacy.redmond at blueshieldca.com Fri Apr 4 15:31:54 2014 From: stacy.redmond at blueshieldca.com (Redmond, Stacy) Date: Fri, 4 Apr 2014 08:31:54 -0700 Subject: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory In-Reply-To: <20140404152522.GY3094@redhat.com> References: <77D4DA314ADF354BBE2686CBBAB9DD790D404E00@EDHC01WEX02.bsc.bscal.com> <20140403191202.GA4947@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D404F68@EDHC01WEX02.bsc.bscal.com> <20140404043406.GV3094@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D4051BE@EDHC01WEX02.bsc.bscal.com> <20140404152522.GY3094@redhat.com> Message-ID: <77D4DA314ADF354BBE2686CBBAB9DD790D40522C@EDHC01WEX02.bsc.bscal.com> We will be using unix as the Kerberos realm and unix.sbx.local as the domain so we can use srv records for the unix hosts to point at ipa. The AD domain is sbx.local, here is the output using the AD domain [root at linuxtest1 ~]# ipa trust-add --type=ad sbx.local --admin Administrator --password Active directory domain administrator's password: ipa: ERROR: Cannot find specified domain or server name [root at linuxtest1 ~]# cat /var/log/httpd/error_log lpcfg_load: refreshing parameters from /usr/share/ipa/smb.conf.empty params.c:pm_process() - Processing configuration file "/usr/share/ipa/smb.conf.empty" Processing section "[global]" INFO: Current debug levels: all: 100 tdb: 100 printdrivers: 100 lanman: 100 smb: 100 rpc_parse: 100 rpc_srv: 100 rpc_cli: 100 passdb: 100 sam: 100 auth: 100 winbind: 100 vfs: 100 idmap: 100 quota: 100 acls: 100 locking: 100 msdfs: 100 dmapi: 100 registry: 100 pm_process() returned Yes Using binding ncacn_np:linuxtest1.unix.sbx.local[,] tevent: Added timed event "dcerpc_connect_timeout_handler": 0x7facb82e9d30 tevent: Added timed event "composite_trigger": 0x7facb80a8de0 tevent: Added timed event "composite_trigger": 0x7facb80a9710 tevent: Running timer event 0x7facb80a8de0 "composite_trigger" tevent: Destroying timer event 0x7facb80a9710 "composite_trigger" Mapped to DCERPC endpoint \pipe\lsarpc added interface eth0 ip=10.130.82.68 bcast=10.130.82.255 netmask=255.255.255.0 added interface eth0 ip=10.130.82.68 bcast=10.130.82.255 netmask=255.255.255.0 tevent: Ending timer event 0x7facb80a8de0 "composite_trigger" tevent: Added timed event "connect_multi_timer": 0x7facb81bf0e0 tevent: Schedule immediate event "tevent_req_trigger": 0x7facb81bfa10 tevent: Run immediate event "tevent_req_trigger": 0x7facb81bfa10 tevent: Destroying timer event 0x7facb81bf0e0 "connect_multi_timer" Socket options: SO_KEEPALIVE = 0 SO_REUSEADDR = 0 SO_BROADCAST = 0 TCP_NODELAY = 1 TCP_KEEPCNT = 9 TCP_KEEPIDLE = 7200 TCP_KEEPINTVL = 75 IPTOS_LOWDELAY = 0 IPTOS_THROUGHPUT = 0 SO_REUSEPORT = 0 SO_SNDBUF = 169160 SO_RCVBUF = 87380 SO_SNDLOWAT = 1 SO_RCVLOWAT = 1 SO_SNDTIMEO = 0 SO_RCVTIMEO = 0 TCP_QUICKACK = 1 TCP_DEFER_ACCEPT = 0 tevent: Added timed event "tevent_req_timedout": 0x7facb814b930 tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7facb8156ab0 tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7facb8156ab0 tevent: Destroying timer event 0x7facb814b930 "tevent_req_timedout" Starting GENSEC mechanism spnego Starting GENSEC submechanism gssapi_krb5 Ticket in credentials cache for admin at UNIX will expire in 31325 secs tevent: Added timed event "tevent_req_timedout": 0x7facb82715b0 tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7facb8156ab0 tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7facb8156ab0 tevent: Destroying timer event 0x7facb82715b0 "tevent_req_timedout" gensec_gssapi: NO credentials were delegated GSSAPI Connection will be cryptographically sealed tevent: Added timed event "tevent_req_timedout": 0x7facb814c340 tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7facb8156ab0 tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7facb8156ab0 tevent: Destroying timer event 0x7facb814c340 "tevent_req_timedout" tevent: Added timed event "tevent_req_timedout": 0x7facb814c340 tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7facb8156ab0 tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7facb8156ab0 tevent: Destroying timer event 0x7facb814c340 "tevent_req_timedout" tevent: Destroying timer event 0x7facb82e9d30 "dcerpc_connect_timeout_handler" [Fri Apr 04 08:28:21 2014] [error] ipa: INFO: admin at UNIX: trust_add(u'sbx.local', trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', range_size=200000, all=False, raw=False, version=u'2.49'): NotFound [root at linuxtest1 ~]# -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Friday, April 04, 2014 8:25 AM To: Redmond, Stacy Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory On Fri, 04 Apr 2014, Redmond, Stacy wrote: >You are absolutlely right, I had rebuilt the server, and had forgotten >to put the log level back in, here it is. > >[root at linuxtest1 ~]# cat /var/log/httpd/error_log /dev/null >lpcfg_load: refreshing parameters from /usr/share/ipa/smb.conf.empty >params.c:pm_process() - Processing configuration file >"/usr/share/ipa/smb.conf.empty" >Processing section "[global]" >INFO: Current debug levels: > all: 100 > tdb: 100 > printdrivers: 100 > lanman: 100 > smb: 100 > rpc_parse: 100 > rpc_srv: 100 > rpc_cli: 100 > passdb: 100 > sam: 100 > auth: 100 > winbind: 100 > vfs: 100 > idmap: 100 > quota: 100 > acls: 100 > locking: 100 > msdfs: 100 > dmapi: 100 > registry: 100 >pm_process() returned Yes >Using binding ncacn_np:linuxtest1.unix.sbx.local[,] ^^ we first try to talk to local smbd process. >tevent: Destroying timer event 0x7facb8292850 "tevent_req_timedout" >tevent: Destroying timer event 0x7facb82d32b0 >"dcerpc_connect_timeout_handler" >[Fri Apr 04 06:59:43 2014] [error] ipa: INFO: admin at UNIX: >trust_add(u'unix.sbx.local', trust_type=u'ad', what is 'unix.sbx.local'? Is this an Active Directory domain? From your log I gather that it is FreeIPA domain, not AD. 'ipa trust-add' requires Active Directory domain as an argument. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Apr 4 15:42:07 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 4 Apr 2014 18:42:07 +0300 Subject: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory In-Reply-To: <77D4DA314ADF354BBE2686CBBAB9DD790D40522C@EDHC01WEX02.bsc.bscal.com> References: <77D4DA314ADF354BBE2686CBBAB9DD790D404E00@EDHC01WEX02.bsc.bscal.com> <20140403191202.GA4947@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D404F68@EDHC01WEX02.bsc.bscal.com> <20140404043406.GV3094@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D4051BE@EDHC01WEX02.bsc.bscal.com> <20140404152522.GY3094@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D40522C@EDHC01WEX02.bsc.bscal.com> Message-ID: <20140404154207.GZ3094@redhat.com> On Fri, 04 Apr 2014, Redmond, Stacy wrote: >We will be using unix as the Kerberos realm and unix.sbx.local as the >domain so we can use srv records for the unix hosts to point at ipa. >The AD domain is sbx.local, here is the output using the AD domain > >[root at linuxtest1 ~]# ipa trust-add --type=ad sbx.local --admin >Administrator --password >Active directory domain administrator's password: >ipa: ERROR: Cannot find specified domain or server name >[root at linuxtest1 ~]# cat /var/log/httpd/error_log >lpcfg_load: refreshing parameters from /usr/share/ipa/smb.conf.empty >params.c:pm_process() - Processing configuration file >"/usr/share/ipa/smb.conf.empty" >Processing section "[global]" >INFO: Current debug levels: > all: 100 > tdb: 100 > printdrivers: 100 > lanman: 100 > smb: 100 > rpc_parse: 100 > rpc_srv: 100 > rpc_cli: 100 > passdb: 100 > sam: 100 > auth: 100 > winbind: 100 > vfs: 100 > idmap: 100 > quota: 100 > acls: 100 > locking: 100 > msdfs: 100 > dmapi: 100 > registry: 100 >pm_process() returned Yes >Using binding ncacn_np:linuxtest1.unix.sbx.local[,] ^^ talking to IPA host's smbd process. >tevent: Added timed event "dcerpc_connect_timeout_handler": >0x7facb82e9d30 >tevent: Added timed event "composite_trigger": 0x7facb80a8de0 >tevent: Added timed event "composite_trigger": 0x7facb80a9710 >tevent: Running timer event 0x7facb80a8de0 "composite_trigger" >tevent: Destroying timer event 0x7facb80a9710 "composite_trigger" >Mapped to DCERPC endpoint \pipe\lsarpc >added interface eth0 ip=10.130.82.68 bcast=10.130.82.255 >netmask=255.255.255.0 >added interface eth0 ip=10.130.82.68 bcast=10.130.82.255 >netmask=255.255.255.0 >tevent: Ending timer event 0x7facb80a8de0 "composite_trigger" >tevent: Added timed event "connect_multi_timer": 0x7facb81bf0e0 >tevent: Schedule immediate event "tevent_req_trigger": 0x7facb81bfa10 >tevent: Run immediate event "tevent_req_trigger": 0x7facb81bfa10 >tevent: Destroying timer event 0x7facb81bf0e0 "connect_multi_timer" >Socket options: > SO_KEEPALIVE = 0 > SO_REUSEADDR = 0 > SO_BROADCAST = 0 > TCP_NODELAY = 1 > TCP_KEEPCNT = 9 > TCP_KEEPIDLE = 7200 > TCP_KEEPINTVL = 75 > IPTOS_LOWDELAY = 0 > IPTOS_THROUGHPUT = 0 > SO_REUSEPORT = 0 > SO_SNDBUF = 169160 > SO_RCVBUF = 87380 > SO_SNDLOWAT = 1 > SO_RCVLOWAT = 1 > SO_SNDTIMEO = 0 > SO_RCVTIMEO = 0 > TCP_QUICKACK = 1 > TCP_DEFER_ACCEPT = 0 >tevent: Added timed event "tevent_req_timedout": 0x7facb814b930 >tevent: Schedule immediate event "tevent_queue_immediate_trigger": >0x7facb8156ab0 >tevent: Run immediate event "tevent_queue_immediate_trigger": >0x7facb8156ab0 >tevent: Destroying timer event 0x7facb814b930 "tevent_req_timedout" >Starting GENSEC mechanism spnego >Starting GENSEC submechanism gssapi_krb5 >Ticket in credentials cache for admin at UNIX will expire in 31325 secs >tevent: Added timed event "tevent_req_timedout": 0x7facb82715b0 >tevent: Schedule immediate event "tevent_queue_immediate_trigger": >0x7facb8156ab0 >tevent: Run immediate event "tevent_queue_immediate_trigger": >0x7facb8156ab0 >tevent: Destroying timer event 0x7facb82715b0 "tevent_req_timedout" >gensec_gssapi: NO credentials were delegated >GSSAPI Connection will be cryptographically sealed >tevent: Added timed event "tevent_req_timedout": 0x7facb814c340 >tevent: Schedule immediate event "tevent_queue_immediate_trigger": >0x7facb8156ab0 >tevent: Run immediate event "tevent_queue_immediate_trigger": >0x7facb8156ab0 >tevent: Destroying timer event 0x7facb814c340 "tevent_req_timedout" >tevent: Added timed event "tevent_req_timedout": 0x7facb814c340 >tevent: Schedule immediate event "tevent_queue_immediate_trigger": >0x7facb8156ab0 >tevent: Run immediate event "tevent_queue_immediate_trigger": >0x7facb8156ab0 >tevent: Destroying timer event 0x7facb814c340 "tevent_req_timedout" >tevent: Destroying timer event 0x7facb82e9d30 >"dcerpc_connect_timeout_handler" ^^ stopped just short of authenticating to smbd prior to ask it for informational policy about the domain. This means there is some problem in what smbd thinks about your admin at UNIX account. Can you do following: # for i in /var/log/samba/log.* ; do echo > $i ; done # smbcontrol all debug 100 # kinit admin at UNIX # ipa trust-add sbx.local .... # smbcontrol all debug 1 now archive logs in /var/log/samba/log.* and send them to me privately. -- / Alexander Bokovoy From dpal at redhat.com Fri Apr 4 23:45:05 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 04 Apr 2014 19:45:05 -0400 Subject: [Freeipa-users] DDNS with DHCPD and IPA In-Reply-To: <008701cf4f97$6f7e06e0$4e7a14a0$@engineer.com> References: <006c01cf4f66$d8ad5390$8a07fab0$@engineer.com> <1396564152.4265.20.camel@strawberry.ad.adelaide.edu.au> <008701cf4f97$6f7e06e0$4e7a14a0$@engineer.com> Message-ID: <533F4401.6060202@redhat.com> On 04/03/2014 07:50 PM, Andy Tomlin wrote: > Awesome, adding the grant line with my key (DDNS_UPDATE) did the trick. This > makes it perform exactly like old config. > > Thanks for the help. Someone should put this example in the docs. Would you mind writing a HowTo on our wiki? > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of William Brown > Sent: Thursday, April 3, 2014 3:29 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] DDNS with DHCPD and IPA > > On Thu, 2014-04-03 at 11:02 -0700, Andy Tomlin wrote: >> That would be my preference, would then work same as bind/dhcpd before >> switching to ipa. I just dont know how to do it correctly. >> >> > This assumes dhcp and named are on the same system. > > For an unrelated project I wrote some docs here: > > http://tollgate.readthedocs.org/en/3.0.1/fedora-deploy.html#core-network > > And the example config files referenced are: > > https://github.com/micolous/tollgate/tree/master/docs/example/fedora > > The important parts are: > > rndc-confgen -a -r keyboard -b 256 > chown named:named /etc/rndc.key > > In named.conf add after the options section: > > include "/etc/rndc.key"; > > In the zone (In ipa you will need to add this permission) > > grant rndc-key wildcard * ANY; > > Then in dhcpd: > > > include "/etc/rndc.key"; > > And to the dhcpd range: > > > zone dhcp.example.lan. { > primary 127.0.0.1; > key "rndc-key"; > } > > > zone 0.4.10.in-addr.arpa. { > primary 127.0.0.1; > key "rndc-key"; > } > > > This should coexist peacefully with freeipa, but try to make sure your DDNS > updated zone is say dhcp.example.com rather than a zone you care about. > Consider you have a domain controller called x.example.com, and you allow > DDNS to example.com. If someone set their hostname to x, they could take > over the DNS records for your DC. Better to have a second zone to prevent > this. > > -- > William Brown > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From atomlin at engineer.com Sat Apr 5 00:51:17 2014 From: atomlin at engineer.com (Andy Tomlin) Date: Fri, 4 Apr 2014 17:51:17 -0700 Subject: [Freeipa-users] DDNS with DHCPD and IPA In-Reply-To: <533F4401.6060202@redhat.com> References: <006c01cf4f66$d8ad5390$8a07fab0$@engineer.com> <1396564152.4265.20.camel@strawberry.ad.adelaide.edu.au> <008701cf4f97$6f7e06e0$4e7a14a0$@engineer.com> <533F4401.6060202@redhat.com> Message-ID: <003101cf5069$2832f4d0$7898de70$@engineer.com> Remove foot from mouth... sure. -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Friday, April 4, 2014 4:45 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] DDNS with DHCPD and IPA On 04/03/2014 07:50 PM, Andy Tomlin wrote: > Awesome, adding the grant line with my key (DDNS_UPDATE) did the > trick. This makes it perform exactly like old config. > > Thanks for the help. Someone should put this example in the docs. Would you mind writing a HowTo on our wiki? > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of William Brown > Sent: Thursday, April 3, 2014 3:29 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] DDNS with DHCPD and IPA > > On Thu, 2014-04-03 at 11:02 -0700, Andy Tomlin wrote: >> That would be my preference, would then work same as bind/dhcpd >> before switching to ipa. I just dont know how to do it correctly. >> >> > This assumes dhcp and named are on the same system. > > For an unrelated project I wrote some docs here: > > http://tollgate.readthedocs.org/en/3.0.1/fedora-deploy.html#core-netwo > rk > > And the example config files referenced are: > > https://github.com/micolous/tollgate/tree/master/docs/example/fedora > > The important parts are: > > rndc-confgen -a -r keyboard -b 256 > chown named:named /etc/rndc.key > > In named.conf add after the options section: > > include "/etc/rndc.key"; > > In the zone (In ipa you will need to add this permission) > > grant rndc-key wildcard * ANY; > > Then in dhcpd: > > > include "/etc/rndc.key"; > > And to the dhcpd range: > > > zone dhcp.example.lan. { > primary 127.0.0.1; > key "rndc-key"; > } > > > zone 0.4.10.in-addr.arpa. { > primary 127.0.0.1; > key "rndc-key"; > } > > > This should coexist peacefully with freeipa, but try to make sure your > DDNS updated zone is say dhcp.example.com rather than a zone you care about. > Consider you have a domain controller called x.example.com, and you > allow DDNS to example.com. If someone set their hostname to x, they > could take over the DNS records for your DC. Better to have a second > zone to prevent this. > > -- > William Brown > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From rmeggins at redhat.com Sat Apr 5 01:16:28 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 04 Apr 2014 19:16:28 -0600 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: References: <533B300D.6050707@redhat.com> <533B3296.1020409@redhat.com> <533C14BA.1030307@redhat.com> <533C26D9.7060409@redhat.com> <533C2FBB.1020601@redhat.com> <533C308E.8000303@redhat.com> <533C4D9F.4050807@redhat.com> <533CBBAA.9040905@redhat.com> <533D726D.4080909@redhat.com> <533DE185.7040502@redhat.com> Message-ID: <533F596C.7030105@redhat.com> On 04/03/2014 10:25 PM, Nevada Sanchez wrote: > I followed the instructions that would give me a core dump, and for > some reason, I don't see one in /var/log/dirsrv/slapd-EXAMPLE-COM/, > even though I still see the Disorderly shutdown still shows up in the > logs. Hmm - check again - it should produce a core file grep -i segfault /var/log/messages > I know that when I explicitly request those attributes, I get "-1 > Total update abortedLDAP error: Can't contact LDAP server" for > nds5ReplicaLastInitStatus (see below). Access logs stop completely on > the replica after the time that you mentioned. Hmm - looks like a bug. Please open a ticket. > > ====================================================== > [root at ipa2 ipaserver]# ldapsearch ldaps://ipa.example.com:636 > -D 'cn=Directory Manager' -w ##### -b > 'cn=meToipa2.example.com > ,cn=replica,cn=dc\=example\,dc\=com,cn=mapping > tree,cn=config' '(objectClass=*)' -s base nsds5ReplicaLastInitStart > nsds5replicaUpdateInProgress nsds5ReplicaLastInitStatus cn > nsds5BeginReplicaRefresh nsds5ReplicaLastInitEnd > # extended LDIF > # > # LDAPv3 > # base ,cn=replica,cn=dc\=example\,dc\=com,cn=mapping > tree,cn=config> with scope baseObject > # filter: (objectclass=*) > # requesting: ldaps://ipa.example.com:636 > (objectClass=*) > nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress > nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh > nsds5ReplicaLastInitEnd > # > > # meToipa2.example.com , replica, > dc\3Dexample\2Cdc\3Dcom, > mapping tree, config > dn: cn=meToipa2.example.com > ,cn=replica,cn=dc\3Dexample\2Cd > c\3Dcom,cn=mapping tree,cn=config > nsds5ReplicaLastInitStart: 20140401092800Z > nsds5replicaUpdateInProgress: FALSE > nsds5ReplicaLastInitStatus: -1 Total update abortedLDAP error: Can't > contact L > DAP server > cn: meToipa2.example.com > nsds5ReplicaLastInitEnd: 20140401092804Z > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > > On Thu, Apr 3, 2014 at 6:32 PM, Rich Megginson > wrote: > > On 04/03/2014 03:46 PM, Nevada Sanchez wrote: >> Okay, I updated the gist and extended some of the logs >> (ipa2-errors does stop at 20:50:21). I'll follow up when I have >> the debug stuff in place. >> >> https://gist.github.com/nevsan/8b6f78d7396963dc5f70 > > Another strange thing - it looks as if the initial replica init > completes successfully. > > [02/Apr/2014:20:50:18 +0000] NSMMReplicationPlugin - Beginning > total update of replica "agmt="cn=meToipa2.example.com > " (ipa2:389)". > > On the replica: > > [02/Apr/2014:20:50:18 +0000] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=example,dc=com is going > offline; disabling replication > [02/Apr/2014:20:50:18 +0000] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to > access the database > [02/Apr/2014:20:50:21 +0000] - import userRoot: Workers finished; > cleaning up... > [02/Apr/2014:20:50:21 +0000] - import userRoot: Workers cleaned up. > [02/Apr/2014:20:50:21 +0000] - import userRoot: Indexing complete. > Post-processing... > [02/Apr/2014:20:50:21 +0000] - import userRoot: Generating > numSubordinates complete. > [02/Apr/2014:20:50:21 +0000] - import userRoot: Flushing caches... > [02/Apr/2014:20:50:21 +0000] - import userRoot: Closing files... > [02/Apr/2014:20:50:21 +0000] - import userRoot: Import complete. > Processed 453 entries in 3 seconds. (151.00 entries/sec) > [02/Apr/2014:20:50:21 +0000] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=example,dc=com is coming > online; enabling replication > > On the master, access log: > > [02/Apr/2014:20:50:17 +0000] conn=1365 op=15 MOD > dn="cn=meToipa2.example.com > ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config" > > This is the operation that triggers the replica init. Then > ipa-replica-install polls for agreement status: > [02/Apr/2014:20:50:19 +0000] conn=1365 op=16 SRCH > base="cn=meToipa2.example.com > ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config" scope=0 filter="(objectClass=*)" > attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress > nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh > nsds5replicaLastInitEnd" > [02/Apr/2014:20:50:19 +0000] conn=1365 op=16 RESULT err=0 tag=101 > nentries=1 etime=0 > [02/Apr/2014:20:50:20 +0000] conn=1365 op=17 SRCH > base="cn=meToipa2.example.com > ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config" scope=0 filter="(objectClass=*)" > attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress > nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh > nsds5replicaLastInitEnd" > [02/Apr/2014:20:50:20 +0000] conn=1365 op=17 RESULT err=0 tag=101 > nentries=1 etime=0 > [02/Apr/2014:20:50:21 +0000] conn=1365 op=18 SRCH > base="cn=meToipa2.example.com > ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config" scope=0 filter="(objectClass=*)" > attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress > nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh > nsds5replicaLastInitEnd" > [02/Apr/2014:20:50:21 +0000] conn=1365 op=18 RESULT err=0 tag=101 > nentries=1 etime=0 > [02/Apr/2014:20:50:22 +0000] conn=1365 op=19 SRCH > base="cn=meToipa2.example.com > ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config" scope=0 filter="(objectClass=*)" > attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress > nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh > nsds5replicaLastInitEnd" > [02/Apr/2014:20:50:22 +0000] conn=1365 op=19 RESULT err=0 tag=101 > nentries=1 etime=1 > > Something happens here. The replica init is done, according to > the replica error log. We don't have the replica access log from > around this time to see exactly when the connection was closed, > but looking at the ipa code, it would appear that ipa did not see > a status of "Total update succeeded". Not sure why the master > would not have reported that, unless there was some problem > getting back the status from the replica. > > [02/Apr/2014:20:50:22 +0000] conn=1365 op=20 UNBIND > [02/Apr/2014:20:50:22 +0000] conn=1365 op=20 fd=114 closed - U1 > > Then ipa-replica-install closes the connection and reports the error. > > >> >> >> On Thu, Apr 3, 2014 at 10:38 AM, Rich Megginson >> > wrote: >> >> On 04/02/2014 09:22 PM, Nevada Sanchez wrote: >>> Okay. Updated the gist with the additional logs: >>> https://gist.github.com/nevsan/8b6f78d7396963dc5f70 >>> >>> >> >> 1) Dirsrv is crashing: >> [02/Apr/2014:20:49:53 +0000] - 389-Directory/1.3.1.22.a1 >> B2014.073.1751 starting up >> [02/Apr/2014:20:49:54 +0000] - Db home directory is not set. >> Possibly nsslapd-directory (optionally >> nsslapd-db-home-directory) is missing in the config file. >> [02/Apr/2014:20:49:54 +0000] - I'm resizing my cache >> now...cache was 710029312 and is now 8000000 >> [02/Apr/2014:20:49:54 +0000] - 389-Directory/1.3.1.22.a1 >> B2014.073.1751 starting up >> [02/Apr/2014:20:49:54 +0000] - Detected Disorderly Shutdown >> last time Directory Server was running, recovering database. >> [02/Apr/2014:20:49:55 +0000] - slapd started. Listening on >> All Interfaces port 389 for LDAP requests >> >> Please use the instructions at >> http://port389.org/wiki/FAQ#Debugging_Crashes to get a core >> dump and stack trace. >> >> 2) The first occurrence of the connection error is at >> [02/Apr/2014:20:52:38 +0000] but there isn't anything in the >> consumer error log after [02/Apr/2014:20:50:21 +0000] and in >> the consumer access log after [02/Apr/2014:20:50:22 +0000] >> >> >>> On Wed, Apr 2, 2014 at 9:38 PM, Rich Megginson >>> > wrote: >>> >>> On 04/02/2014 03:01 PM, Nevada Sanchez wrote: >>>> Okay, I ran it with debug on. The output is quite >>>> large. I'm not sure what the etiquette is for posting >>>> large logs, so I threw it on gist here: >>>> https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt >>>> >>>> >>>> >>>> Let me know if I should copy it into the thread instead. >>> >>> Ok. Now can you post excerpts from the dirsrv errors >>> log from both the master replica and the replica from >>> around the time of the failure? >>> >>> >>>> >>>> >>>> On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson >>>> > wrote: >>>> >>>> On 04/02/2014 11:45 AM, Nevada Sanchez wrote: >>>>> My apologies. I mistakenly ran the failing >>>>> ldapsearch from an unpriviliged user (couldn't >>>>> read slapd-EXAMPLE-COM directory). Running as >>>>> root, it now works just fine (same result as the >>>>> one that worked). SSL seems to not be the issue. >>>>> Also, I haven't change the SSL certs since I first >>>>> set up the master. >>>>> >>>>> I have been doing the replica side things from >>>>> scratch (even so far as starting with a new >>>>> machine). For the master side, I have just been >>>>> re-preparing the replica. I hope I don't have to >>>>> start from scratch with the master replica. >>>> >>>> I guess the next step would be to do the >>>> ipa-replica-install using -ddd and review the extra >>>> debug information that comes out. >>>> >>>> >>>>> >>>>> >>>>> On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden >>>>> > >>>>> wrote: >>>>> >>>>> Rich Megginson wrote: >>>>> >>>>> On 04/02/2014 09:20 AM, Nevada Sanchez wrote: >>>>> >>>>> Okay, we might be on to something: >>>>> >>>>> ipa -> ipa2 >>>>> ================================ >>>>> $ >>>>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM >>>>> ldapsearch -xLLLZZ >>>>> -h ipa2.example.com >>>>> >>>>> -s base -b "" >>>>> >>>>> 'objectclass=*' vendorVersion >>>>> dn: >>>>> vendorVersion: >>>>> 389-Directory/1.3.1.22.a1 B2014.073.1751 >>>>> ================================ >>>>> >>>>> ipa2 -> ipa >>>>> ================================ >>>>> $ >>>>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM >>>>> ldapsearch -xLLLZZ >>>>> -h ipa.example.com >>>>> >>>>> -s base -b "" >>>>> >>>>> 'objectclass=*' vendorVersion >>>>> ldap_start_tls: Connect error (-11) >>>>> additional info: TLS error >>>>> -8172:Peer's certificate issuer has been >>>>> marked as not trusted by the user. >>>>> ================================ >>>>> >>>>> The original IPA trusts the replica >>>>> (since it signed the cert, I >>>>> assume), but the replica doesn't trust >>>>> the main IPA server. I guess >>>>> the ZZ option would have shown me the >>>>> failure that I missed in my >>>>> initial ldapsearch tests. >>>>> >>>>> -Z[Z] Issue StartTLS (Transport Layer >>>>> Security) extended >>>>> operation. If >>>>> you use -ZZ, the command will require >>>>> the operation to >>>>> be suc- >>>>> cessful. >>>>> >>>>> i.e. use SSL, and force a successful handshake >>>>> >>>>> >>>>> Anyway, what's the best way to remedy >>>>> this in a way that makes IPA >>>>> happy? (I've found that LDAP can have >>>>> different requirements on which >>>>> certs go where). >>>>> >>>>> >>>>> I'm not sure. >>>>> ipa-server-install/ipa-replica-prepare/ipa-replica-install >>>>> is supposed to take care of installing the >>>>> CA cert properly for you. If >>>>> you try to hack it and install the CA cert >>>>> manually, you will probably >>>>> miss something else that ipa install did >>>>> not do. >>>>> >>>>> I think the only way to ensure that you >>>>> have a properly configured ipa >>>>> server + replicas is to get all of the ipa >>>>> commands completing successfully. >>>>> >>>>> Which means going back to the drawing >>>>> board and starting over from scratch. >>>>> >>>>> >>>>> You can compare the certs that each side is >>>>> using with: >>>>> >>>>> # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM >>>>> >>>>> Did you by chance replace the SSL server certs >>>>> that IPA uses on your working master? >>>>> >>>>> rob >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanchez.nevada at gmail.com Sat Apr 5 15:35:21 2014 From: sanchez.nevada at gmail.com (Nevada Sanchez) Date: Sat, 5 Apr 2014 11:35:21 -0400 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: <533F596C.7030105@redhat.com> References: <533B300D.6050707@redhat.com> <533B3296.1020409@redhat.com> <533C14BA.1030307@redhat.com> <533C26D9.7060409@redhat.com> <533C2FBB.1020601@redhat.com> <533C308E.8000303@redhat.com> <533C4D9F.4050807@redhat.com> <533CBBAA.9040905@redhat.com> <533D726D.4080909@redhat.com> <533DE185.7040502@redhat.com> <533F596C.7030105@redhat.com> Message-ID: Thanks. I added /var/log/messages to the gist ( https://gist.github.com/nevsan/8b6f78d7396963dc5f70)--no segfaults it seems. Any other kind of disorderly shutdowns that might happen? I'll look into creating a ticket for this. On Fri, Apr 4, 2014 at 9:16 PM, Rich Megginson wrote: > On 04/03/2014 10:25 PM, Nevada Sanchez wrote: > > I followed the instructions that would give me a core dump, and for some > reason, I don't see one in /var/log/dirsrv/slapd-EXAMPLE-COM/, even though > I still see the Disorderly shutdown still shows up in the logs. > > > Hmm - check again - it should produce a core file > > grep -i segfault /var/log/messages > > > I know that when I explicitly request those attributes, I get "-1 Total > update abortedLDAP error: Can't contact LDAP server" for > nds5ReplicaLastInitStatus (see below). Access logs stop completely on the > replica after the time that you mentioned. > > > Hmm - looks like a bug. Please open a ticket. > > > > ====================================================== > [root at ipa2 ipaserver]# ldapsearch ldaps://ipa.example.com:636 -D > 'cn=Directory Manager' -w ##### -b 'cn=meToipa2.example.com,cn=replica,cn=dc\=example\,dc\=com,cn=mapping > tree,cn=config' '(objectClass=*)' -s base nsds5ReplicaLastInitStart > nsds5replicaUpdateInProgress nsds5ReplicaLastInitStatus cn > nsds5BeginReplicaRefresh nsds5ReplicaLastInitEnd > # extended LDIF > # > # LDAPv3 > # base ,cn=replica,cn=dc\=example\,dc\=com,cn=mapping > tree,cn=config> with scope baseObject > # filter: (objectclass=*) > # requesting: ldaps://ipa.example.com:636 (objectClass=*) > nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress > nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh > nsds5ReplicaLastInitEnd > # > > # meToipa2.example.com , replica, > dc\3Dexample\2Cdc\3Dcom, > mapping tree, config > dn: cn=meToipa2.example.com > ,cn=replica,cn=dc\3Dexample\2Cd > c\3Dcom,cn=mapping tree,cn=config > nsds5ReplicaLastInitStart: 20140401092800Z > nsds5replicaUpdateInProgress: FALSE > nsds5ReplicaLastInitStatus: -1 Total update abortedLDAP error: Can't > contact L > DAP server > cn: meToipa2.example.com > nsds5ReplicaLastInitEnd: 20140401092804Z > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > > On Thu, Apr 3, 2014 at 6:32 PM, Rich Megginson wrote: > >> On 04/03/2014 03:46 PM, Nevada Sanchez wrote: >> >> Okay, I updated the gist and extended some of the logs (ipa2-errors does >> stop at 20:50:21). I'll follow up when I have the debug stuff in place. >> >> https://gist.github.com/nevsan/8b6f78d7396963dc5f70 >> >> >> Another strange thing - it looks as if the initial replica init >> completes successfully. >> >> [02/Apr/2014:20:50:18 +0000] NSMMReplicationPlugin - Beginning total >> update of replica "agmt="cn=meToipa2.example.com" (ipa2:389)". >> >> On the replica: >> >> [02/Apr/2014:20:50:18 +0000] NSMMReplicationPlugin - >> multimaster_be_state_change: replica dc=example,dc=com is going offline; >> disabling replication >> [02/Apr/2014:20:50:18 +0000] - WARNING: Import is running with >> nsslapd-db-private-import-mem on; No other process is allowed to access the >> database >> [02/Apr/2014:20:50:21 +0000] - import userRoot: Workers finished; >> cleaning up... >> [02/Apr/2014:20:50:21 +0000] - import userRoot: Workers cleaned up. >> [02/Apr/2014:20:50:21 +0000] - import userRoot: Indexing complete. >> Post-processing... >> [02/Apr/2014:20:50:21 +0000] - import userRoot: Generating >> numSubordinates complete. >> [02/Apr/2014:20:50:21 +0000] - import userRoot: Flushing caches... >> [02/Apr/2014:20:50:21 +0000] - import userRoot: Closing files... >> [02/Apr/2014:20:50:21 +0000] - import userRoot: Import complete. >> Processed 453 entries in 3 seconds. (151.00 entries/sec) >> [02/Apr/2014:20:50:21 +0000] NSMMReplicationPlugin - >> multimaster_be_state_change: replica dc=example,dc=com is coming online; >> enabling replication >> >> On the master, access log: >> >> [02/Apr/2014:20:50:17 +0000] conn=1365 op=15 MOD dn="cn= >> meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" >> >> This is the operation that triggers the replica init. Then >> ipa-replica-install polls for agreement status: >> [02/Apr/2014:20:50:19 +0000] conn=1365 op=16 SRCH base="cn= >> meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" scope=0 filter="(objectClass=*)" >> attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress >> nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh >> nsds5replicaLastInitEnd" >> [02/Apr/2014:20:50:19 +0000] conn=1365 op=16 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [02/Apr/2014:20:50:20 +0000] conn=1365 op=17 SRCH base="cn= >> meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" scope=0 filter="(objectClass=*)" >> attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress >> nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh >> nsds5replicaLastInitEnd" >> [02/Apr/2014:20:50:20 +0000] conn=1365 op=17 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [02/Apr/2014:20:50:21 +0000] conn=1365 op=18 SRCH base="cn= >> meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" scope=0 filter="(objectClass=*)" >> attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress >> nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh >> nsds5replicaLastInitEnd" >> [02/Apr/2014:20:50:21 +0000] conn=1365 op=18 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [02/Apr/2014:20:50:22 +0000] conn=1365 op=19 SRCH base="cn= >> meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" scope=0 filter="(objectClass=*)" >> attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress >> nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh >> nsds5replicaLastInitEnd" >> [02/Apr/2014:20:50:22 +0000] conn=1365 op=19 RESULT err=0 tag=101 >> nentries=1 etime=1 >> >> Something happens here. The replica init is done, according to the >> replica error log. We don't have the replica access log from around this >> time to see exactly when the connection was closed, but looking at the ipa >> code, it would appear that ipa did not see a status of "Total update >> succeeded". Not sure why the master would not have reported that, unless >> there was some problem getting back the status from the replica. >> >> [02/Apr/2014:20:50:22 +0000] conn=1365 op=20 UNBIND >> [02/Apr/2014:20:50:22 +0000] conn=1365 op=20 fd=114 closed - U1 >> >> Then ipa-replica-install closes the connection and reports the error. >> >> >> >> >> On Thu, Apr 3, 2014 at 10:38 AM, Rich Megginson wrote: >> >>> On 04/02/2014 09:22 PM, Nevada Sanchez wrote: >>> >>> Okay. Updated the gist with the additional logs: >>> https://gist.github.com/nevsan/8b6f78d7396963dc5f70 >>> >>> >>> >>> 1) Dirsrv is crashing: >>> [02/Apr/2014:20:49:53 +0000] - 389-Directory/1.3.1.22.a1 B2014.073.1751 >>> starting up >>> [02/Apr/2014:20:49:54 +0000] - Db home directory is not set. Possibly >>> nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the >>> config file. >>> [02/Apr/2014:20:49:54 +0000] - I'm resizing my cache now...cache was >>> 710029312 and is now 8000000 >>> [02/Apr/2014:20:49:54 +0000] - 389-Directory/1.3.1.22.a1 B2014.073.1751 >>> starting up >>> [02/Apr/2014:20:49:54 +0000] - Detected Disorderly Shutdown last time >>> Directory Server was running, recovering database. >>> [02/Apr/2014:20:49:55 +0000] - slapd started. Listening on All >>> Interfaces port 389 for LDAP requests >>> >>> Please use the instructions at >>> http://port389.org/wiki/FAQ#Debugging_Crashes to get a core dump and >>> stack trace. >>> >>> 2) The first occurrence of the connection error is at >>> [02/Apr/2014:20:52:38 +0000] but there isn't anything in the consumer error >>> log after [02/Apr/2014:20:50:21 +0000] and in the consumer access log after >>> [02/Apr/2014:20:50:22 +0000] >>> >>> >>> On Wed, Apr 2, 2014 at 9:38 PM, Rich Megginson wrote: >>> >>>> On 04/02/2014 03:01 PM, Nevada Sanchez wrote: >>>> >>>> Okay, I ran it with debug on. The output is quite large. I'm not sure >>>> what the etiquette is for posting large logs, so I threw it on gist here: >>>> https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt >>>> >>>> Let me know if I should copy it into the thread instead. >>>> >>>> >>>> Ok. Now can you post excerpts from the dirsrv errors log from both >>>> the master replica and the replica from around the time of the failure? >>>> >>>> >>>> >>>> >>>> On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson wrote: >>>> >>>>> On 04/02/2014 11:45 AM, Nevada Sanchez wrote: >>>>> >>>>> My apologies. I mistakenly ran the failing ldapsearch from an >>>>> unpriviliged user (couldn't read slapd-EXAMPLE-COM directory). Running as >>>>> root, it now works just fine (same result as the one that worked). SSL >>>>> seems to not be the issue. Also, I haven't change the SSL certs since I >>>>> first set up the master. >>>>> >>>>> I have been doing the replica side things from scratch (even so far >>>>> as starting with a new machine). For the master side, I have just been >>>>> re-preparing the replica. I hope I don't have to start from scratch with >>>>> the master replica. >>>>> >>>>> >>>>> I guess the next step would be to do the ipa-replica-install using >>>>> -ddd and review the extra debug information that comes out. >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden wrote: >>>>> >>>>>> Rich Megginson wrote: >>>>>> >>>>>>> On 04/02/2014 09:20 AM, Nevada Sanchez wrote: >>>>>>> >>>>>>>> Okay, we might be on to something: >>>>>>>> >>>>>>>> ipa -> ipa2 >>>>>>>> ================================ >>>>>>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ >>>>>>>> -h ipa2.example.com -s base -b "" >>>>>>>> >>>>>>>> 'objectclass=*' vendorVersion >>>>>>>> dn: >>>>>>>> vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 >>>>>>>> ================================ >>>>>>>> >>>>>>>> ipa2 -> ipa >>>>>>>> ================================ >>>>>>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ >>>>>>>> -h ipa.example.com -s base -b "" >>>>>>>> >>>>>>>> 'objectclass=*' vendorVersion >>>>>>>> ldap_start_tls: Connect error (-11) >>>>>>>> additional info: TLS error -8172:Peer's certificate issuer has been >>>>>>>> marked as not trusted by the user. >>>>>>>> ================================ >>>>>>>> >>>>>>>> The original IPA trusts the replica (since it signed the cert, I >>>>>>>> assume), but the replica doesn't trust the main IPA server. I guess >>>>>>>> the ZZ option would have shown me the failure that I missed in my >>>>>>>> initial ldapsearch tests. >>>>>>>> >>>>>>> -Z[Z] Issue StartTLS (Transport Layer Security) extended >>>>>>> operation. If >>>>>>> you use -ZZ, the command will require the operation >>>>>>> to >>>>>>> be suc- >>>>>>> cessful. >>>>>>> >>>>>>> i.e. use SSL, and force a successful handshake >>>>>>> >>>>>>> >>>>>>>> Anyway, what's the best way to remedy this in a way that makes IPA >>>>>>>> happy? (I've found that LDAP can have different requirements on >>>>>>>> which >>>>>>>> certs go where). >>>>>>>> >>>>>>> >>>>>>> I'm not sure. >>>>>>> ipa-server-install/ipa-replica-prepare/ipa-replica-install >>>>>>> is supposed to take care of installing the CA cert properly for you. >>>>>>> If >>>>>>> you try to hack it and install the CA cert manually, you will >>>>>>> probably >>>>>>> miss something else that ipa install did not do. >>>>>>> >>>>>>> I think the only way to ensure that you have a properly configured >>>>>>> ipa >>>>>>> server + replicas is to get all of the ipa commands completing >>>>>>> successfully. >>>>>>> >>>>>>> Which means going back to the drawing board and starting over from >>>>>>> scratch. >>>>>>> >>>>>> >>>>>> You can compare the certs that each side is using with: >>>>>> >>>>>> # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM >>>>>> >>>>>> Did you by chance replace the SSL server certs that IPA uses on your >>>>>> working master? >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhu_junca at yahoo.ca Sat Apr 5 16:24:50 2014 From: zhu_junca at yahoo.ca (Carl E. Ma) Date: Sat, 5 Apr 2014 09:24:50 -0700 (PDT) Subject: [Freeipa-users] experience using IPA in a mixed environment Message-ID: <1396715090.39565.YahooMailNeo@web140903.mail.bf1.yahoo.com> Hi, My environment has Redhat5, 6, Centos 6.x and Ubuntu 12.04. Following Redhat identity management manual, I am able to configure user authentication, kerberos NFS, SSSD and autofs on most of my systems. The only trouble is integrating ubuntu 12.04 with autofs. 1. automount in /etc/nsswitch.conf doesn't recognize sss as the name service, you need to put ldap instead. 2. automount on ubuntu 12.04 doesn't recognize the auto.master map from IPA server. On our IPA server: ipaserver# ipa automountlocation-tofiles default /etc/auto.master: /-????? /etc/auto.direct /home?? /etc/auto.home --------------------------- /etc/auto.direct: --------------------------- /etc/auto.home: *?????? -fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192 nfs:/opt/shares/home/& >From ubuntu 12.04 IPA client: #automount -f -d ??? <=shows it can't find the auto.master map, in /etc/default/autofs, I tried both ways to specify the auto.master map. == #cat /etc/default/autofs? | grep MASTER #MASTER_MAP_NAME="automountmapname=auto.master,cn=default,cn=automount,dc=x,dc=x,dc=x,dc=com" MASTER_MAP_NAME="auto.master" == >From the error messages, it seems automount on ubuntu doesn't lookup LDAP for auto.master information. Apr? 4 17:25:26 ecs-94a55510 automount[1032]: lookup(file): file map /etc/automountmapname=auto.master,cn=default,cn=automount,dc=x,dc=x,dc=x,dc=com missing or not readable Although I am using pam to automount user home directory, i am curious? whether anyone else experienced the same problem, or maybe I missed something. Thanks, carl From nathan.f77 at gmail.com Mon Apr 7 02:20:07 2014 From: nathan.f77 at gmail.com (Nathan Broadbent) Date: Sun, 6 Apr 2014 19:20:07 -0700 Subject: [Freeipa-users] How can I set up OTP for user authentication? Message-ID: Hello, I'm running FreeIPA version 3.3.4. I've done a little research, and it seems like this version is missing support for OTP, but I could have sworn that I found a page that said that OTP was finished and ready to use. And in the server installation logs, I found some references to 'ipa-otpd'. I also remember reading about an otp plugin for FreeIPA, but it doesn't seem to be installed on my server. Our case is that we want to require OTP codes for SSH authentication. Even for public key authentication, we would like to add a ForceCommand directive to ssh config that would require the OTP code. It would be awesome if that could be configured on a per-server basis in FreeIPA. Is OTP production ready? I found the 'Red Hat Test Day' page where people were testing OTP. If 3.3.4 doesn't support OTP, I'm happy to compile from source. Where can I find the source / branch with the most current OTP features? Will it be included in 4.0.0? Or should I checkout the 'otpui' [1] branch on GitHub? Very keen to start using the feature, and I'd be happy to help report and fix any bugs. But at the same time, I don't want to compromise our security if this feature hasn't been properly audited, so advice would be appreciated. Thanks, Nathan [1] https://github.com/npmccallum/freeipa/commits/otpui -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Apr 7 04:48:45 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 7 Apr 2014 07:48:45 +0300 Subject: [Freeipa-users] How can I set up OTP for user authentication? In-Reply-To: References: Message-ID: <20140407044845.GE20958@redhat.com> On Sun, 06 Apr 2014, Nathan Broadbent wrote: >Hello, > >I'm running FreeIPA version 3.3.4. I've done a little research, and it >seems like this version is missing support for OTP, but I could have sworn >that I found a page that said that OTP was finished and ready to use. And >in the server installation logs, I found some references to 'ipa-otpd'. OTP support is part of FreeIPA 4.0 release plan. What was released prior to that represents different components of the solution but not the full solution (yet). Full OTP functionality requires changes on both server and client side. For example, password changes and token synchronization are two elements which are tightly coupled client/server-side, though we have few more specific examples. >I also remember reading about an otp plugin for FreeIPA, but it doesn't >seem to be installed on my server. > >Our case is that we want to require OTP codes for SSH authentication. Even >for public key authentication, we would like to add a ForceCommand >directive to ssh config that would require the OTP code. It would be >awesome if that could be configured on a per-server basis in FreeIPA. > >Is OTP production ready? I found the 'Red Hat Test Day' page where people >were testing OTP. If 3.3.4 doesn't support OTP, I'm happy to compile from >source. Where can I find the source / branch with the most current OTP >features? Will it be included in 4.0.0? Or should I checkout the 'otpui' >[1] branch on GitHub? OTP support is not yet production ready, at least not labeled so in any released FreeIPA version, we plan it for 4.0. Following URL gives you an overview of what is still needs to be finished: https://fedorahosted.org/freeipa/query?component=OTP&status=!closed You can try experimenting with the COPR repo I've made for testing OTP functionality: http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ It requires Fedora 20 with all updates (including updates-testing repo) installed prior to use. We are also still tuning SELinux policy so for some cases there might be an occasional AVC even with fully updated system. These need to be reported to bugzilla.redhat.com. At this moment Fedora 20 is the only platform one can target as an experimental FreeIPA server with OTP functionality enabled. >Very keen to start using the feature, and I'd be happy to help report and >fix any bugs. But at the same time, I don't want to compromise our security >if this feature hasn't been properly audited, so advice would be >appreciated. As I said, this feature is under development. Some bugs may still lurk in the code but wider testing should help in clearing them up, so any effort in testing is definitely welcome! -- / Alexander Bokovoy From john.obaterspok at gmail.com Mon Apr 7 09:41:00 2014 From: john.obaterspok at gmail.com (John Obaterspok) Date: Mon, 7 Apr 2014 11:41:00 +0200 Subject: [Freeipa-users] DogTag memory usage. Alternatives? Message-ID: Hello, I'm using FreeIPA for my home network and it works really great. FreeIPA is running on NAS server where hw isn't latest & greatest. I've noticed the dogtag java/tomcat process is using up to 1 gig of RAM and the java process is usually in the top spot for powertop wakeups. Is it normal that it uses this much memory? Are there any alternatives? -- john From mkosek at redhat.com Mon Apr 7 11:48:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 07 Apr 2014 13:48:18 +0200 Subject: [Freeipa-users] DogTag memory usage. Alternatives? In-Reply-To: References: Message-ID: <53429082.1010201@redhat.com> On 04/07/2014 11:41 AM, John Obaterspok wrote: > Hello, > > I'm using FreeIPA for my home network and it works really great. > FreeIPA is running on NAS server where hw isn't latest & greatest. > I've noticed the dogtag java/tomcat process is using up to 1 gig of > RAM and the java process is usually in the top spot for powertop > wakeups. > > Is it normal that it uses this much memory? Are there any alternatives? > > -- john CCing Ade to answer the Dogtag part. As for the alternatives, in FreeIPA you either use PKI/Dogtag or you don't (CA-less installation). We do not support other PKI but Dogtag. If you do not really use certificates in your home network, CA-less installation may be the solution for your use case. Martin From jpazdziora at redhat.com Mon Apr 7 11:51:18 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 7 Apr 2014 13:51:18 +0200 Subject: [Freeipa-users] Enrolling client to second IPA server In-Reply-To: <20140107061112.GD12003@redhat.com> References: <20140107040241.GA3901@redhat.com> <20140107061112.GD12003@redhat.com> Message-ID: <20140407115118.GG8339@redhat.com> On Tue, Jan 07, 2014 at 08:11:12AM +0200, Alexander Bokovoy wrote: > > The problem here is that you would have the same host name assigned to > two different realms which means there would be a single principal but > two different keys associated with it from different realms. A single > keytab could contain only principals from the single realm. > > Thus, you need to use different keytabs and make sure that access to > a non-default KDC is always using non-default keytab. Understood. > You'd also need to fetch IPA2's CA certificate and trust it. Here might > be a problem since it will have the same nickname, 'IPA CA' and thus > cannot be placed in the same /etc/pki/nssdb database. You can, however, > put the cert file in a separate file somewhere, for example, > /etc/ipa/ipa2-ca.crt. Understood. > Now, suppose you have a non-default keytab set at /etc/krb5.keytab.IPA2. > > # kinit admin at IPA2 > # ipa-getkeytab -s ipaserver.example.com -p host/foo.example.com -k /etc/krb5.keytab.IPA2 > > would fetch the host keytab there. > > Then SSSD would need to be configured to use a different location for > the keytab for this realm and a different TLS cert. > > [domain/example.com] > ... > krb5_keytab = /etc/krb5.keytab.IPA2 > ldap_tls_cacert = /etc/ipa/ipa2-ca.crt > ... > > So, off my head (not tested): > 1. Set up krb5.conf to have realm and domain_realm mappings for the > second realm. You can only have one of the realms as default one. > 2. Set up sssd.conf to have a second domain which points krb5_keytab to > a different keytab, /etc/krb5.keytab.IPA2, and a different TLS CA > certificate. > 3. kinit as a principal from the second realm > 4. Use ipa-getkeytab to fetch the keytab to /etc/krb5.keytab.IPA2 I have this set up and Kerberos works -- I can do kinit user123 at REALM1.NET and kinit user678 at REALM2.NET and they pass and klist will show respective prinsipals. > Finally, for LDAP operations you can't have profiles in ldap.conf, so > defaults will only point to the original one. You can create another one > in /etc/openldap and then use LDAPCONF environmental variable to point > to the second config file for the defaults. Here is where I got stuck -- when I run getent passwd user123 at REALM1.NET I can see the record but getent passwd user678 at REALM2.NET will not return anything. Is that because of the LDAP operations still using whatever is in /etc/openldap/ldap.conf? When I put IPA2's data to /etc/openldap/ldap.conf.IPA2 and run LDAPCONF=/etc/openldap/ldap.conf.IPA2 getent passwd user678 at REALM2.NET I still don't get anything. I assume that it's because it's actually sssd which does the calls ... but how would I set LDAPCONF for sssd? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From rcritten at redhat.com Mon Apr 7 12:28:38 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Apr 2014 08:28:38 -0400 Subject: [Freeipa-users] experience using IPA in a mixed environment In-Reply-To: <1396715090.39565.YahooMailNeo@web140903.mail.bf1.yahoo.com> References: <1396715090.39565.YahooMailNeo@web140903.mail.bf1.yahoo.com> Message-ID: <534299F6.8090200@redhat.com> Carl E. Ma wrote: > Hi, > > My environment has Redhat5, 6, Centos 6.x and Ubuntu 12.04. Following Redhat identity management manual, I am able to configure user authentication, kerberos NFS, SSSD and autofs on most of my systems. > > The only trouble is integrating ubuntu 12.04 with autofs. > > 1. automount in /etc/nsswitch.conf doesn't recognize sss as the name service, you need to put ldap instead. > 2. automount on ubuntu 12.04 doesn't recognize the auto.master map from IPA server. > > On our IPA server: > ipaserver# ipa automountlocation-tofiles default > /etc/auto.master: > /- /etc/auto.direct > /home /etc/auto.home > --------------------------- > /etc/auto.direct: > --------------------------- > /etc/auto.home: > * -fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192 nfs:/opt/shares/home/& > > >>From ubuntu 12.04 IPA client: > #automount -f -d <=shows it can't find the auto.master map, in /etc/default/autofs, I tried both ways to specify the auto.master map. > == > #cat /etc/default/autofs | grep MASTER > #MASTER_MAP_NAME="automountmapname=auto.master,cn=default,cn=automount,dc=x,dc=x,dc=x,dc=com" > MASTER_MAP_NAME="auto.master" > == > >>From the error messages, it seems automount on ubuntu doesn't lookup LDAP for auto.master information. > > Apr 4 17:25:26 ecs-94a55510 automount[1032]: lookup(file): file map /etc/automountmapname=auto.master,cn=default,cn=automount,dc=x,dc=x,dc=x,dc=com missing or not readable > > Although I am using pam to automount user home directory, i am curious whether anyone else experienced the same problem, or maybe I missed something. Can you provide more information on how you configured automount (e.g. can we see the config files)? Did you use the ipa-client-automount command or configure things by hand? rob From rmeggins at redhat.com Mon Apr 7 13:56:14 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 07 Apr 2014 07:56:14 -0600 Subject: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server) In-Reply-To: References: <533C14BA.1030307@redhat.com> <533C26D9.7060409@redhat.com> <533C2FBB.1020601@redhat.com> <533C308E.8000303@redhat.com> <533C4D9F.4050807@redhat.com> <533CBBAA.9040905@redhat.com> <533D726D.4080909@redhat.com> <533DE185.7040502@redhat.com> <533F596C.7030105@redhat.com> Message-ID: <5342AE7E.70006@redhat.com> On 04/05/2014 09:35 AM, Nevada Sanchez wrote: > Thanks. I added /var/log/messages to the gist > (https://gist.github.com/nevsan/8b6f78d7396963dc5f70)--no > segfaults > it seems. Any other kind of disorderly shutdowns that might happen? > I'll look into creating a ticket for this. Only if there is some sort of build issue that causes an undefined symbol reference at runtime - that would cause the process to exit without a core. > > > On Fri, Apr 4, 2014 at 9:16 PM, Rich Megginson > wrote: > > On 04/03/2014 10:25 PM, Nevada Sanchez wrote: >> I followed the instructions that would give me a core dump, and >> for some reason, I don't see one in >> /var/log/dirsrv/slapd-EXAMPLE-COM/, even though I still see the >> Disorderly shutdown still shows up in the logs. > > Hmm - check again - it should produce a core file > > grep -i segfault /var/log/messages > > >> I know that when I explicitly request those attributes, I get "-1 >> Total update abortedLDAP error: Can't contact LDAP server" for >> nds5ReplicaLastInitStatus (see below). Access logs stop >> completely on the replica after the time that you mentioned. > > Hmm - looks like a bug. Please open a ticket. > > >> >> ====================================================== >> [root at ipa2 ipaserver]# ldapsearch ldaps://ipa.example.com:636 >> -D 'cn=Directory Manager' -w ##### >> -b 'cn=meToipa2.example.com >> ,cn=replica,cn=dc\=example\,dc\=com,cn=mapping >> tree,cn=config' '(objectClass=*)' -s base >> nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress >> nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh >> nsds5ReplicaLastInitEnd >> # extended LDIF >> # >> # LDAPv3 >> # base > ,cn=replica,cn=dc\=example\,dc\=com,cn=mapping >> tree,cn=config> with scope baseObject >> # filter: (objectclass=*) >> # requesting: ldaps://ipa.example.com:636 >> (objectClass=*) >> nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress >> nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh >> nsds5ReplicaLastInitEnd >> # >> >> # meToipa2.example.com , replica, >> dc\3Dexample\2Cdc\3Dcom, >> mapping tree, config >> dn: cn=meToipa2.example.com >> ,cn=replica,cn=dc\3Dexample\2Cd >> c\3Dcom,cn=mapping tree,cn=config >> nsds5ReplicaLastInitStart: 20140401092800Z >> nsds5replicaUpdateInProgress: FALSE >> nsds5ReplicaLastInitStatus: -1 Total update abortedLDAP error: >> Can't contact L >> DAP server >> cn: meToipa2.example.com >> nsds5ReplicaLastInitEnd: 20140401092804Z >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> >> >> On Thu, Apr 3, 2014 at 6:32 PM, Rich Megginson >> > wrote: >> >> On 04/03/2014 03:46 PM, Nevada Sanchez wrote: >>> Okay, I updated the gist and extended some of the logs >>> (ipa2-errors does stop at 20:50:21). I'll follow up when I >>> have the debug stuff in place. >>> >>> https://gist.github.com/nevsan/8b6f78d7396963dc5f70 >> >> Another strange thing - it looks as if the initial replica >> init completes successfully. >> >> [02/Apr/2014:20:50:18 +0000] NSMMReplicationPlugin - >> Beginning total update of replica >> "agmt="cn=meToipa2.example.com " >> (ipa2:389)". >> >> On the replica: >> >> [02/Apr/2014:20:50:18 +0000] NSMMReplicationPlugin - >> multimaster_be_state_change: replica dc=example,dc=com is >> going offline; disabling replication >> [02/Apr/2014:20:50:18 +0000] - WARNING: Import is running >> with nsslapd-db-private-import-mem on; No other process is >> allowed to access the database >> [02/Apr/2014:20:50:21 +0000] - import userRoot: Workers >> finished; cleaning up... >> [02/Apr/2014:20:50:21 +0000] - import userRoot: Workers >> cleaned up. >> [02/Apr/2014:20:50:21 +0000] - import userRoot: Indexing >> complete. Post-processing... >> [02/Apr/2014:20:50:21 +0000] - import userRoot: Generating >> numSubordinates complete. >> [02/Apr/2014:20:50:21 +0000] - import userRoot: Flushing >> caches... >> [02/Apr/2014:20:50:21 +0000] - import userRoot: Closing files... >> [02/Apr/2014:20:50:21 +0000] - import userRoot: Import >> complete. Processed 453 entries in 3 seconds. (151.00 >> entries/sec) >> [02/Apr/2014:20:50:21 +0000] NSMMReplicationPlugin - >> multimaster_be_state_change: replica dc=example,dc=com is >> coming online; enabling replication >> >> On the master, access log: >> >> [02/Apr/2014:20:50:17 +0000] conn=1365 op=15 MOD >> dn="cn=meToipa2.example.com >> ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" >> >> This is the operation that triggers the replica init. Then >> ipa-replica-install polls for agreement status: >> [02/Apr/2014:20:50:19 +0000] conn=1365 op=16 SRCH >> base="cn=meToipa2.example.com >> ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" scope=0 filter="(objectClass=*)" >> attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress >> nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh >> nsds5replicaLastInitEnd" >> [02/Apr/2014:20:50:19 +0000] conn=1365 op=16 RESULT err=0 >> tag=101 nentries=1 etime=0 >> [02/Apr/2014:20:50:20 +0000] conn=1365 op=17 SRCH >> base="cn=meToipa2.example.com >> ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" scope=0 filter="(objectClass=*)" >> attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress >> nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh >> nsds5replicaLastInitEnd" >> [02/Apr/2014:20:50:20 +0000] conn=1365 op=17 RESULT err=0 >> tag=101 nentries=1 etime=0 >> [02/Apr/2014:20:50:21 +0000] conn=1365 op=18 SRCH >> base="cn=meToipa2.example.com >> ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" scope=0 filter="(objectClass=*)" >> attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress >> nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh >> nsds5replicaLastInitEnd" >> [02/Apr/2014:20:50:21 +0000] conn=1365 op=18 RESULT err=0 >> tag=101 nentries=1 etime=0 >> [02/Apr/2014:20:50:22 +0000] conn=1365 op=19 SRCH >> base="cn=meToipa2.example.com >> ,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >> tree,cn=config" scope=0 filter="(objectClass=*)" >> attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress >> nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh >> nsds5replicaLastInitEnd" >> [02/Apr/2014:20:50:22 +0000] conn=1365 op=19 RESULT err=0 >> tag=101 nentries=1 etime=1 >> >> Something happens here. The replica init is done, according >> to the replica error log. We don't have the replica access >> log from around this time to see exactly when the connection >> was closed, but looking at the ipa code, it would appear that >> ipa did not see a status of "Total update succeeded". Not >> sure why the master would not have reported that, unless >> there was some problem getting back the status from the replica. >> >> [02/Apr/2014:20:50:22 +0000] conn=1365 op=20 UNBIND >> [02/Apr/2014:20:50:22 +0000] conn=1365 op=20 fd=114 closed - U1 >> >> Then ipa-replica-install closes the connection and reports >> the error. >> >> >>> >>> >>> On Thu, Apr 3, 2014 at 10:38 AM, Rich Megginson >>> > wrote: >>> >>> On 04/02/2014 09:22 PM, Nevada Sanchez wrote: >>>> Okay. Updated the gist with the additional logs: >>>> https://gist.github.com/nevsan/8b6f78d7396963dc5f70 >>>> >>>> >>> >>> 1) Dirsrv is crashing: >>> [02/Apr/2014:20:49:53 +0000] - 389-Directory/1.3.1.22.a1 >>> B2014.073.1751 starting up >>> [02/Apr/2014:20:49:54 +0000] - Db home directory is not >>> set. Possibly nsslapd-directory (optionally >>> nsslapd-db-home-directory) is missing in the config file. >>> [02/Apr/2014:20:49:54 +0000] - I'm resizing my cache >>> now...cache was 710029312 and is now 8000000 >>> [02/Apr/2014:20:49:54 +0000] - 389-Directory/1.3.1.22.a1 >>> B2014.073.1751 starting up >>> [02/Apr/2014:20:49:54 +0000] - Detected Disorderly >>> Shutdown last time Directory Server was running, >>> recovering database. >>> [02/Apr/2014:20:49:55 +0000] - slapd started. Listening >>> on All Interfaces port 389 for LDAP requests >>> >>> Please use the instructions at >>> http://port389.org/wiki/FAQ#Debugging_Crashes to get a >>> core dump and stack trace. >>> >>> 2) The first occurrence of the connection error is at >>> [02/Apr/2014:20:52:38 +0000] but there isn't anything in >>> the consumer error log after [02/Apr/2014:20:50:21 >>> +0000] and in the consumer access log after >>> [02/Apr/2014:20:50:22 +0000] >>> >>> >>>> On Wed, Apr 2, 2014 at 9:38 PM, Rich Megginson >>>> > wrote: >>>> >>>> On 04/02/2014 03:01 PM, Nevada Sanchez wrote: >>>>> Okay, I ran it with debug on. The output is quite >>>>> large. I'm not sure what the etiquette is for >>>>> posting large logs, so I threw it on gist here: >>>>> https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt >>>>> >>>>> >>>>> >>>>> Let me know if I should copy it into the thread >>>>> instead. >>>> >>>> Ok. Now can you post excerpts from the dirsrv >>>> errors log from both the master replica and the >>>> replica from around the time of the failure? >>>> >>>> >>>>> >>>>> >>>>> On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson >>>>> > >>>>> wrote: >>>>> >>>>> On 04/02/2014 11:45 AM, Nevada Sanchez wrote: >>>>>> My apologies. I mistakenly ran the failing >>>>>> ldapsearch from an unpriviliged user >>>>>> (couldn't read slapd-EXAMPLE-COM directory). >>>>>> Running as root, it now works just fine (same >>>>>> result as the one that worked). SSL seems to >>>>>> not be the issue. Also, I haven't change the >>>>>> SSL certs since I first set up the master. >>>>>> >>>>>> I have been doing the replica side things >>>>>> from scratch (even so far as starting with a >>>>>> new machine). For the master side, I have >>>>>> just been re-preparing the replica. I hope I >>>>>> don't have to start from scratch with the >>>>>> master replica. >>>>> >>>>> I guess the next step would be to do the >>>>> ipa-replica-install using -ddd and review the >>>>> extra debug information that comes out. >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Wed, Apr 2, 2014 at 11:45 AM, Rob >>>>>> Crittenden >>>>> > wrote: >>>>>> >>>>>> Rich Megginson wrote: >>>>>> >>>>>> On 04/02/2014 09:20 AM, Nevada >>>>>> Sanchez wrote: >>>>>> >>>>>> Okay, we might be on to something: >>>>>> >>>>>> ipa -> ipa2 >>>>>> ================================ >>>>>> $ >>>>>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM >>>>>> ldapsearch -xLLLZZ >>>>>> -h ipa2.example.com >>>>>> >>>>>> -s base >>>>>> -b "" >>>>>> >>>>>> 'objectclass=*' vendorVersion >>>>>> dn: >>>>>> vendorVersion: >>>>>> 389-Directory/1.3.1.22.a1 >>>>>> B2014.073.1751 >>>>>> ================================ >>>>>> >>>>>> ipa2 -> ipa >>>>>> ================================ >>>>>> $ >>>>>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM >>>>>> ldapsearch -xLLLZZ >>>>>> -h ipa.example.com >>>>>> >>>>>> -s base >>>>>> -b "" >>>>>> >>>>>> 'objectclass=*' vendorVersion >>>>>> ldap_start_tls: Connect error (-11) >>>>>> additional info: TLS error >>>>>> -8172:Peer's certificate issuer >>>>>> has been >>>>>> marked as not trusted by the user. >>>>>> ================================ >>>>>> >>>>>> The original IPA trusts the >>>>>> replica (since it signed the cert, I >>>>>> assume), but the replica doesn't >>>>>> trust the main IPA server. I guess >>>>>> the ZZ option would have shown me >>>>>> the failure that I missed in my >>>>>> initial ldapsearch tests. >>>>>> >>>>>> -Z[Z] Issue StartTLS (Transport >>>>>> Layer Security) extended >>>>>> operation. If >>>>>> you use -ZZ, the command will >>>>>> require the operation to >>>>>> be suc- >>>>>> cessful. >>>>>> >>>>>> i.e. use SSL, and force a successful >>>>>> handshake >>>>>> >>>>>> >>>>>> Anyway, what's the best way to >>>>>> remedy this in a way that makes IPA >>>>>> happy? (I've found that LDAP can >>>>>> have different requirements on which >>>>>> certs go where). >>>>>> >>>>>> >>>>>> I'm not sure. >>>>>> ipa-server-install/ipa-replica-prepare/ipa-replica-install >>>>>> is supposed to take care of >>>>>> installing the CA cert properly for >>>>>> you. If >>>>>> you try to hack it and install the CA >>>>>> cert manually, you will probably >>>>>> miss something else that ipa install >>>>>> did not do. >>>>>> >>>>>> I think the only way to ensure that >>>>>> you have a properly configured ipa >>>>>> server + replicas is to get all of >>>>>> the ipa commands completing successfully. >>>>>> >>>>>> Which means going back to the drawing >>>>>> board and starting over from scratch. >>>>>> >>>>>> >>>>>> You can compare the certs that each side >>>>>> is using with: >>>>>> >>>>>> # certutil -L -d >>>>>> /etc/dirsrv/slapd-EXAMPLE-COM >>>>>> >>>>>> Did you by chance replace the SSL server >>>>>> certs that IPA uses on your working master? >>>>>> >>>>>> rob >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.obaterspok at gmail.com Tue Apr 8 05:14:46 2014 From: john.obaterspok at gmail.com (John Obaterspok) Date: Tue, 8 Apr 2014 07:14:46 +0200 Subject: [Freeipa-users] Win7 machine occasionally not able to lookup ipa hosts In-Reply-To: References: <4F1A553C69F348149FFDE23E589E57B5@willsheldon.com> Message-ID: Well, I think I found the cause for the Windows PC's not able to lookup IPA hosts. It seems there was 2 DNS Server entries in the Router. Primary entry pointing to internal IPA server while secondary pointing to ISP. -- john 2014-03-23 22:34 GMT+01:00 John Obaterspok : > Hello, > > I just experience this again.ipa server not pingable by name but by ip. Did > a ipconfig /all > file, then ipconfig /renew. Then only lines that differ is > the lease expire: > > - Lease expires. . . . . . . . . . . : 2014-03-24 20:04:28 > + Lease expires. . . . . . . . . . . : 2014-03-24 22:28:09 > > Any other suggestions? > > -- john > > > 2014-03-23 18:52 GMT+01:00 Will Sheldon : > >> >> What is the difference in the output of "ipconfig /all" before and after >> the "ipconfig /renew"? >> >> >> Kind regards, >> >> Will Sheldon >> >> On Sunday, March 23, 2014 at 1:21 AM, John Obaterspok wrote: >> >> Hello, >> >> A couple of times each day the win 7 machine is not able to lookup hosts >> on the ipa domain. A ipconfig /renew always allows ipa hosts to be >> resolvable again. >> >> Any ideas why this happens? >> >> -- john >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > From abokovoy at redhat.com Tue Apr 8 05:27:01 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 8 Apr 2014 08:27:01 +0300 Subject: [Freeipa-users] [SOLVED] Unable to establish trust with FreeIPA and Active Directory In-Reply-To: <20140404154207.GZ3094@redhat.com> References: <77D4DA314ADF354BBE2686CBBAB9DD790D404E00@EDHC01WEX02.bsc.bscal.com> <20140403191202.GA4947@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D404F68@EDHC01WEX02.bsc.bscal.com> <20140404043406.GV3094@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D4051BE@EDHC01WEX02.bsc.bscal.com> <20140404152522.GY3094@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D40522C@EDHC01WEX02.bsc.bscal.com> <20140404154207.GZ3094@redhat.com> Message-ID: <20140408052701.GJ20958@redhat.com> On Fri, 04 Apr 2014, Alexander Bokovoy wrote: >>tevent: Destroying timer event 0x7facb82e9d30 >>"dcerpc_connect_timeout_handler" >^^ stopped just short of authenticating to smbd prior to ask it for >informational policy about the domain. > >This means there is some problem in what smbd thinks about your >admin at UNIX account. > >Can you do following: > ># for i in /var/log/samba/log.* ; do echo > $i ; done ># smbcontrol all debug 100 ># kinit admin at UNIX ># ipa trust-add sbx.local .... ># smbcontrol all debug 1 > >now archive logs in /var/log/samba/log.* and send them to me privately. After several rounds of capturing logs, we've solved the issue by finding out that IPv6 stack was completely disabled on the machine. Even though certain security guides may suggest disabling IPv6 stack when it is not in use, this suggestion is not very usable. IPv4 and IPv6 share the same port range on the local side, so it is a recommended programming practice for networking applications to only open IPv6 sockets. Standard C library (glibc, for example) handles transparently both IPv4 and IPv6 cases for the applications. Samba and some of other FreeIPA components open their networking sockets as IPv6 ones. Completely disabling IPv6 stack on the machine causes these requests to open a socket to fail as kernel will be responding "do not know this socket address family". If your security guidelines require disabling IPv6 address space, please don't add ipv6.disable=1 to the kernel commandline to disable the whole IPv6 stack. Instead, use ipv6.disable_ipv6=1. The latter option will keep the IPv6 stack functional but will not assign IPv6 addresses to any of your network devices. This is recommended approach for cases when you don't use IPv6 networking. Creating and adding to, for example, /etc/sysctl.d/ipv6.conf will avoid assigning IPv6 addresses to a specific network interface: # Disable IPv6 net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf..disable_ipv6 = 1 where interface0 is your specialized interface. Note that all we are requiring is that IPv6 stack is enabled at the kernel level and this is recommended way to develop networking applications for a long time already. I've updated http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup and http://www.freeipa.org/page/Deployment_Recommendations with this information. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Apr 8 05:28:49 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 8 Apr 2014 08:28:49 +0300 Subject: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory In-Reply-To: References: Message-ID: <20140408052849.GK20958@redhat.com> On Thu, 03 Apr 2014, Matthew W Hanley wrote: >I'm in the midst of setting up a trust with FreeIPA and Active >Directory and am receiving the following error: > ># ipa trust-add --type=ad ad.example.com --admin 'mwhanley' --password >Active directory domain administrator's password: > >ipa: ERROR: Cannot find specified domain or server name > >The FreeIPA server is running Fedora release 20, version 3.3.3-4 of >FreeIPA and I have turned on debugging and get the following: > [..] >TCP_DEFER_ACCEPT = 0 >Starting GENSEC mechanism spnego >Starting GENSEC submechanism gssapi_krb5 >Ticket in credentials cache for admin at ipaexample.com will expire in 84015 secs >gensec_gssapi: NO credentials were delegated >GSSAPI Connection will be cryptographically sealed > >I've also done an "ipactl restart" to no avail. Any help would be appreciated. See my another email today in this thread. If you have disabled IPv6 stack support in your kernel, please enable it and use suggesting in the another email if you ever need it disabled. -- / Alexander Bokovoy From sbose at redhat.com Tue Apr 8 07:20:04 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 8 Apr 2014 09:20:04 +0200 Subject: [Freeipa-users] [SOLVED] Unable to establish trust with FreeIPA and Active Directory In-Reply-To: <20140408052701.GJ20958@redhat.com> References: <77D4DA314ADF354BBE2686CBBAB9DD790D404E00@EDHC01WEX02.bsc.bscal.com> <20140403191202.GA4947@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D404F68@EDHC01WEX02.bsc.bscal.com> <20140404043406.GV3094@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D4051BE@EDHC01WEX02.bsc.bscal.com> <20140404152522.GY3094@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D40522C@EDHC01WEX02.bsc.bscal.com> <20140404154207.GZ3094@redhat.com> <20140408052701.GJ20958@redhat.com> Message-ID: <20140408072004.GH26337@localhost.localdomain> On Tue, Apr 08, 2014 at 08:27:01AM +0300, Alexander Bokovoy wrote: > On Fri, 04 Apr 2014, Alexander Bokovoy wrote: > >>tevent: Destroying timer event 0x7facb82e9d30 > >>"dcerpc_connect_timeout_handler" > >^^ stopped just short of authenticating to smbd prior to ask it for > >informational policy about the domain. > > > >This means there is some problem in what smbd thinks about your > >admin at UNIX account. > > > >Can you do following: > > > ># for i in /var/log/samba/log.* ; do echo > $i ; done > ># smbcontrol all debug 100 > ># kinit admin at UNIX > ># ipa trust-add sbx.local .... > ># smbcontrol all debug 1 > > > >now archive logs in /var/log/samba/log.* and send them to me privately. > > After several rounds of capturing logs, we've solved the issue by > finding out that IPv6 stack was completely disabled on the machine. > > Even though certain security guides may suggest disabling IPv6 stack > when it is not in use, this suggestion is not very usable. IPv4 and IPv6 > share the same port range on the local side, so it is a recommended > programming practice for networking applications to only open IPv6 > sockets. Standard C library (glibc, for example) handles transparently > both IPv4 and IPv6 cases for the applications. > > Samba and some of other FreeIPA components open their networking sockets > as IPv6 ones. Completely disabling IPv6 stack on the machine causes > these requests to open a socket to fail as kernel will be responding "do > not know this socket address family". > > If your security guidelines require disabling IPv6 address space, please > don't add ipv6.disable=1 to the kernel commandline to disable the whole > IPv6 stack. Instead, use ipv6.disable_ipv6=1. The latter option will > keep the IPv6 stack functional but will not assign IPv6 addresses to any > of your network devices. This is recommended approach for cases when > you don't use IPv6 networking. > > Creating and adding to, for example, /etc/sysctl.d/ipv6.conf will avoid > assigning IPv6 addresses to a specific network interface: > > # Disable IPv6 > net.ipv6.conf.all.disable_ipv6 = 1 > net.ipv6.conf..disable_ipv6 = 1 > > where interface0 is your specialized interface. Note that all we are > requiring is that IPv6 stack is enabled at the kernel level and this > is recommended way to develop networking applications for a long time > already. > > I've updated http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup > and http://www.freeipa.org/page/Deployment_Recommendations with this > information. Thank you for getting to the bottom of this. Do you think we should check this settings during ipa-adtrust-install or even during ipa-server-install? bye, Sumit > > > -- > / Alexander Bokovoy > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From abokovoy at redhat.com Tue Apr 8 07:32:48 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 8 Apr 2014 10:32:48 +0300 Subject: [Freeipa-users] [SOLVED] Unable to establish trust with FreeIPA and Active Directory In-Reply-To: <20140408072004.GH26337@localhost.localdomain> References: <77D4DA314ADF354BBE2686CBBAB9DD790D404E00@EDHC01WEX02.bsc.bscal.com> <20140403191202.GA4947@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D404F68@EDHC01WEX02.bsc.bscal.com> <20140404043406.GV3094@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D4051BE@EDHC01WEX02.bsc.bscal.com> <20140404152522.GY3094@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D40522C@EDHC01WEX02.bsc.bscal.com> <20140404154207.GZ3094@redhat.com> <20140408052701.GJ20958@redhat.com> <20140408072004.GH26337@localhost.localdomain> Message-ID: <20140408073007.GL20958@redhat.com> On Tue, 08 Apr 2014, Sumit Bose wrote: >On Tue, Apr 08, 2014 at 08:27:01AM +0300, Alexander Bokovoy wrote: >> On Fri, 04 Apr 2014, Alexander Bokovoy wrote: >> >>tevent: Destroying timer event 0x7facb82e9d30 >> >>"dcerpc_connect_timeout_handler" >> >^^ stopped just short of authenticating to smbd prior to ask it for >> >informational policy about the domain. >> > >> >This means there is some problem in what smbd thinks about your >> >admin at UNIX account. >> > >> >Can you do following: >> > >> ># for i in /var/log/samba/log.* ; do echo > $i ; done >> ># smbcontrol all debug 100 >> ># kinit admin at UNIX >> ># ipa trust-add sbx.local .... >> ># smbcontrol all debug 1 >> > >> >now archive logs in /var/log/samba/log.* and send them to me privately. >> >> After several rounds of capturing logs, we've solved the issue by >> finding out that IPv6 stack was completely disabled on the machine. >> >> Even though certain security guides may suggest disabling IPv6 stack >> when it is not in use, this suggestion is not very usable. IPv4 and IPv6 >> share the same port range on the local side, so it is a recommended >> programming practice for networking applications to only open IPv6 >> sockets. Standard C library (glibc, for example) handles transparently >> both IPv4 and IPv6 cases for the applications. >> >> Samba and some of other FreeIPA components open their networking sockets >> as IPv6 ones. Completely disabling IPv6 stack on the machine causes >> these requests to open a socket to fail as kernel will be responding "do >> not know this socket address family". >> >> If your security guidelines require disabling IPv6 address space, please >> don't add ipv6.disable=1 to the kernel commandline to disable the whole >> IPv6 stack. Instead, use ipv6.disable_ipv6=1. The latter option will >> keep the IPv6 stack functional but will not assign IPv6 addresses to any >> of your network devices. This is recommended approach for cases when >> you don't use IPv6 networking. >> >> Creating and adding to, for example, /etc/sysctl.d/ipv6.conf will avoid >> assigning IPv6 addresses to a specific network interface: >> >> # Disable IPv6 >> net.ipv6.conf.all.disable_ipv6 = 1 >> net.ipv6.conf..disable_ipv6 = 1 >> >> where interface0 is your specialized interface. Note that all we are >> requiring is that IPv6 stack is enabled at the kernel level and this >> is recommended way to develop networking applications for a long time >> already. >> >> I've updated http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup >> and http://www.freeipa.org/page/Deployment_Recommendations with this >> information. > >Thank you for getting to the bottom of this. Do you think we should >check this settings during ipa-adtrust-install or even during >ipa-server-install? I think we should do both. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Apr 8 13:34:56 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 8 Apr 2014 16:34:56 +0300 Subject: [Freeipa-users] External Collaboration Domains In-Reply-To: <53389BEA.9050905@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net> <20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net> <20140330182619.GA19628@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net> <53389BEA.9050905@redhat.com> Message-ID: <20140408133456.GR20958@redhat.com> On Sun, 30 Mar 2014, Dmitri Pal wrote: >On 03/30/2014 03:14 PM, Nordgren, Bryce L -FS wrote: >>>I think it does not really differ from what I described, conceptually. >>>It is, however, requiring much more work than what I described. >>> >>>FreeIPA has flat LDAP DIT. Adding support for separate OUs is in itself a non- >>>trivial task. >>Ah. Well since that's the case, separate OUs are gone. (You may have to hit "reload" in your browser to get the new figure.) It does require that the RDN of all external entities encode both the name and the realm of the external Kerberos principal in order to avoid collisions. Is the current "external user" provisioning method able to handle the same name coming from two domains or does it assume that collisions will never happen? >> >>>PKINIT use in Kerberos is a big issue. Right now certificates produced by >>>FreeIPA do not include special extension that Kerberos KDC requires to have >>>PKINIT working. We have a ticket to solve this but it depends on few items >>>missing in FreeIPA, Dogtag, and nss. Solving it is required for full OTP use, so >>>we might gain this feature sooner or later. >>The proposal actually doesn't involve producing kx509 certificates, only consuming them. :) I think these are two issues which can be handled in parallel rather than having one block the other. ;) >> >>>What's reasonable and can be relatively easily pulled in from your proposal is >>>a mechanism to get users automatically provisioned in FreeIPA based on >>>their cross realm identities. For example, for cross realm trust with AD we >>>have means to selectively block certain SIDs from being imported from the >>>AD. The rest is recognized and accepted but no local external groups created >>>for them. We simply can automate creating the groups on login attempt if >>>SIDs involved aren't blocked. This automation should solve majority of >>>administrative load. >> From my cursory examination of the code, I proposed auditing the KDC's AS and TGS conversations to trigger this automatic provisioning. Is this an approach worth keeping? >> >>I understand that IPA's bread and butter is to attach itself to a pre existing AD domain to simplify the administration of Linux machines within the same administrative boundaries. This is a subset of Use Case 1. I just want to make sure that there's a plan in place for situations where the domain of origin is not AD, and no SID is exported (the rest of Use Case 1, and Use Cases 2& 3.) This is just a generalization of the procedure to allow "AD" users access to services such that users from non-AD realms can also be included. >> >>Use Case 1 could be named "Intra-organizational cross-realm operation", Use Case 2 could be named "Inter-organizational cross realm operation", and Use Case 3 could be named "Multi-technology cross-realm operation". 2&3 involve independent administrative entities with a fair amount of autonomy. Traditional enterprise approaches are not valid for 2&3. :) >> >>Thanks for the review! >>Bryce >> >> >> >> >> >> >>This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. >> > > >Wow! >First of all thanks for a nice pictures and sharing your ideas. >A lot of work and though put into it. > >Let me just point couple things: >1) It looks like the whole idea is about creating entries for >external users on the server when external user authenticates via >KDC. But don't we already lookup cache these users in a local SSSD >cache and expose via the compat tree for legacy clients? >AFAIU the purpose is to be able to create local groups for the >external users. May be we can do something and use compat tree DNs >for external users? >In general it is better to distill the problem we are trying to >solve: did I get it right? > >2) I think PKINIT and related part of the proposal is not something >that we would do. >Instead of PKI based Ipsilon would use GSS proxy that implements >s4u2proxy + s4u2self to acquire a ticket on user behalf. >This functionality already exists, so there is no new code need. > >3) The case when you send TGT back to the client from Ipsilon that >authenticated user and acquired TGT on his behalf is an interesting >one. The intent for client to later use SSH is understandable though >hard to achieve. Currently there is no mechanism for Ipsilon or >Ipsilon like gateways to return the TGT for a user and pass it to >client browser. There is also no way a browser can save this TGT in >the cache. > >Bottom line: >Let us focus on the problem we are trying to solve here. Keep in mind >that we have not started designing IPA to IPA trusts and Kerberos to >IPA trusts. It might very well be that we would need to create some >external entries for those trusts so IMO looking into these trust >scenarios would reveal where our AD integration approach lacks >external info and needs to be extended. If we want to solve the high >level problem of trusts in general we need to build those specific >flows and see what data is not in ldap and we can get it there. A >simple mental exercise suggests that we would need something for >grouping of the identities coming from a vanilla trusted Kerberos >domain. May be this is something we should drill down as a next step? Now we have this tracked with the ticket https://fedorahosted.org/freeipa/ticket/4287 Bryce, please continue expanding on your potential use cases using the wiki page you've created. I'm not sure we are even close to start implementing this but gathering the information is a first step. I think Dmitri has some valid questions above that might be good to answer through your wiki page. -- / Alexander Bokovoy From dpal at redhat.com Tue Apr 8 13:42:30 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 08 Apr 2014 09:42:30 -0400 Subject: [Freeipa-users] External Collaboration Domains In-Reply-To: <20140408133456.GR20958@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net> <20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net> <20140330182619.GA19628@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net> <53389BEA.9050905@redhat.com> <20140408133456.GR20958@redhat.com> Message-ID: <5343FCC6.10209@redhat.com> On 04/08/2014 09:34 AM, Alexander Bokovoy wrote: > On Sun, 30 Mar 2014, Dmitri Pal wrote: >> On 03/30/2014 03:14 PM, Nordgren, Bryce L -FS wrote: >>>> I think it does not really differ from what I described, conceptually. >>>> It is, however, requiring much more work than what I described. >>>> >>>> FreeIPA has flat LDAP DIT. Adding support for separate OUs is in >>>> itself a non- >>>> trivial task. >>> Ah. Well since that's the case, separate OUs are gone. (You may have >>> to hit "reload" in your browser to get the new figure.) It does >>> require that the RDN of all external entities encode both the name >>> and the realm of the external Kerberos principal in order to avoid >>> collisions. Is the current "external user" provisioning method able >>> to handle the same name coming from two domains or does it assume >>> that collisions will never happen? >>> >>>> PKINIT use in Kerberos is a big issue. Right now certificates >>>> produced by >>>> FreeIPA do not include special extension that Kerberos KDC requires >>>> to have >>>> PKINIT working. We have a ticket to solve this but it depends on >>>> few items >>>> missing in FreeIPA, Dogtag, and nss. Solving it is required for >>>> full OTP use, so >>>> we might gain this feature sooner or later. >>> The proposal actually doesn't involve producing kx509 certificates, >>> only consuming them. :) I think these are two issues which can be >>> handled in parallel rather than having one block the other. ;) >>> >>>> What's reasonable and can be relatively easily pulled in from your >>>> proposal is >>>> a mechanism to get users automatically provisioned in FreeIPA based on >>>> their cross realm identities. For example, for cross realm trust >>>> with AD we >>>> have means to selectively block certain SIDs from being imported >>>> from the >>>> AD. The rest is recognized and accepted but no local external >>>> groups created >>>> for them. We simply can automate creating the groups on login >>>> attempt if >>>> SIDs involved aren't blocked. This automation should solve majority of >>>> administrative load. >>> From my cursory examination of the code, I proposed auditing the >>> KDC's AS and TGS conversations to trigger this automatic >>> provisioning. Is this an approach worth keeping? >>> >>> I understand that IPA's bread and butter is to attach itself to a >>> pre existing AD domain to simplify the administration of Linux >>> machines within the same administrative boundaries. This is a subset >>> of Use Case 1. I just want to make sure that there's a plan in place >>> for situations where the domain of origin is not AD, and no SID is >>> exported (the rest of Use Case 1, and Use Cases 2& 3.) This is >>> just a generalization of the procedure to allow "AD" users access to >>> services such that users from non-AD realms can also be included. >>> >>> Use Case 1 could be named "Intra-organizational cross-realm >>> operation", Use Case 2 could be named "Inter-organizational cross >>> realm operation", and Use Case 3 could be named "Multi-technology >>> cross-realm operation". 2&3 involve independent administrative >>> entities with a fair amount of autonomy. Traditional enterprise >>> approaches are not valid for 2&3. :) >>> >>> Thanks for the review! >>> Bryce >>> >>> >>> >>> >>> >>> >>> This electronic message contains information generated by the USDA >>> solely for the intended recipients. Any unauthorized interception of >>> this message or the use or disclosure of the information it contains >>> may violate the law and subject the violator to civil or criminal >>> penalties. If you believe you have received this message in error, >>> please notify the sender and delete the email immediately. >>> >> >> >> Wow! >> First of all thanks for a nice pictures and sharing your ideas. >> A lot of work and though put into it. >> >> Let me just point couple things: >> 1) It looks like the whole idea is about creating entries for >> external users on the server when external user authenticates via >> KDC. But don't we already lookup cache these users in a local SSSD >> cache and expose via the compat tree for legacy clients? >> AFAIU the purpose is to be able to create local groups for the >> external users. May be we can do something and use compat tree DNs >> for external users? >> In general it is better to distill the problem we are trying to >> solve: did I get it right? >> >> 2) I think PKINIT and related part of the proposal is not something >> that we would do. >> Instead of PKI based Ipsilon would use GSS proxy that implements >> s4u2proxy + s4u2self to acquire a ticket on user behalf. >> This functionality already exists, so there is no new code need. >> >> 3) The case when you send TGT back to the client from Ipsilon that >> authenticated user and acquired TGT on his behalf is an interesting >> one. The intent for client to later use SSH is understandable though >> hard to achieve. Currently there is no mechanism for Ipsilon or >> Ipsilon like gateways to return the TGT for a user and pass it to >> client browser. There is also no way a browser can save this TGT in >> the cache. >> >> Bottom line: >> Let us focus on the problem we are trying to solve here. Keep in mind >> that we have not started designing IPA to IPA trusts and Kerberos to >> IPA trusts. It might very well be that we would need to create some >> external entries for those trusts so IMO looking into these trust >> scenarios would reveal where our AD integration approach lacks >> external info and needs to be extended. If we want to solve the high >> level problem of trusts in general we need to build those specific >> flows and see what data is not in ldap and we can get it there. A >> simple mental exercise suggests that we would need something for >> grouping of the identities coming from a vanilla trusted Kerberos >> domain. May be this is something we should drill down as a next step? > Now we have this tracked with the ticket > https://fedorahosted.org/freeipa/ticket/4287 > > > Bryce, please continue expanding on your potential use cases using the > wiki page you've created. I'm not sure we are even close to start > implementing this but gathering the information is a first step. > > I think Dmitri has some valid questions above that might be good to > answer through your wiki page. > And may be we can start smaller. Can we have a concise definition of the speific problem we are trying to solve here. May be there are different ways to solve it other than auto creating records. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Tue Apr 8 13:44:52 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 08 Apr 2014 09:44:52 -0400 Subject: [Freeipa-users] [SOLVED] Unable to establish trust with FreeIPA and Active Directory In-Reply-To: <20140408073007.GL20958@redhat.com> References: <77D4DA314ADF354BBE2686CBBAB9DD790D404E00@EDHC01WEX02.bsc.bscal.com> <20140403191202.GA4947@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D404F68@EDHC01WEX02.bsc.bscal.com> <20140404043406.GV3094@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D4051BE@EDHC01WEX02.bsc.bscal.com> <20140404152522.GY3094@redhat.com> <77D4DA314ADF354BBE2686CBBAB9DD790D40522C@EDHC01WEX02.bsc.bscal.com> <20140404154207.GZ3094@redhat.com> <20140408052701.GJ20958@redhat.com> <20140408072004.GH26337@localhost.localdomain> <20140408073007.GL20958@redhat.com> Message-ID: <5343FD54.5050507@redhat.com> On 04/08/2014 03:32 AM, Alexander Bokovoy wrote: > On Tue, 08 Apr 2014, Sumit Bose wrote: >> On Tue, Apr 08, 2014 at 08:27:01AM +0300, Alexander Bokovoy wrote: >>> On Fri, 04 Apr 2014, Alexander Bokovoy wrote: >>> >>tevent: Destroying timer event 0x7facb82e9d30 >>> >>"dcerpc_connect_timeout_handler" >>> >^^ stopped just short of authenticating to smbd prior to ask it for >>> >informational policy about the domain. >>> > >>> >This means there is some problem in what smbd thinks about your >>> >admin at UNIX account. >>> > >>> >Can you do following: >>> > >>> ># for i in /var/log/samba/log.* ; do echo > $i ; done >>> ># smbcontrol all debug 100 >>> ># kinit admin at UNIX >>> ># ipa trust-add sbx.local .... >>> ># smbcontrol all debug 1 >>> > >>> >now archive logs in /var/log/samba/log.* and send them to me >>> privately. >>> >>> After several rounds of capturing logs, we've solved the issue by >>> finding out that IPv6 stack was completely disabled on the machine. >>> >>> Even though certain security guides may suggest disabling IPv6 stack >>> when it is not in use, this suggestion is not very usable. IPv4 and >>> IPv6 >>> share the same port range on the local side, so it is a recommended >>> programming practice for networking applications to only open IPv6 >>> sockets. Standard C library (glibc, for example) handles transparently >>> both IPv4 and IPv6 cases for the applications. >>> >>> Samba and some of other FreeIPA components open their networking >>> sockets >>> as IPv6 ones. Completely disabling IPv6 stack on the machine causes >>> these requests to open a socket to fail as kernel will be responding >>> "do >>> not know this socket address family". >>> >>> If your security guidelines require disabling IPv6 address space, >>> please >>> don't add ipv6.disable=1 to the kernel commandline to disable the whole >>> IPv6 stack. Instead, use ipv6.disable_ipv6=1. The latter option will >>> keep the IPv6 stack functional but will not assign IPv6 addresses to >>> any >>> of your network devices. This is recommended approach for cases when >>> you don't use IPv6 networking. >>> >>> Creating and adding to, for example, /etc/sysctl.d/ipv6.conf will avoid >>> assigning IPv6 addresses to a specific network interface: >>> >>> # Disable IPv6 >>> net.ipv6.conf.all.disable_ipv6 = 1 >>> net.ipv6.conf..disable_ipv6 = 1 >>> >>> where interface0 is your specialized interface. Note that all we are >>> requiring is that IPv6 stack is enabled at the kernel level and this >>> is recommended way to develop networking applications for a long time >>> already. >>> >>> I've updated http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup >>> and http://www.freeipa.org/page/Deployment_Recommendations with this >>> information. >> >> Thank you for getting to the bottom of this. Do you think we should >> check this settings during ipa-adtrust-install or even during >> ipa-server-install? > I think we should do both. > Should we file a ticket? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From freeipa at stormcloud9.net Tue Apr 8 15:52:34 2014 From: freeipa at stormcloud9.net (Patrick Hemmer) Date: Tue, 08 Apr 2014 11:52:34 -0400 Subject: [Freeipa-users] /var/kerberos/krb5kdc/principal missing Message-ID: <53441B42.30809@stormcloud9.net> I'm having the exact same issue as http://www.redhat.com/archives/freeipa-users/2013-October/msg00009.html I upgraded from RHEL-6.3 to RHEL-6.5, and now FreeIPA won't start due to kadmind not starting. The kadmind.log contains an extremely unhelpful: Apr 08 11:31:20 i-31f62969 kadmind[20850](Error): No such file or directory while initializing, aborting Stracing `/usr/sbin/kadmind -P /var/run/kadmind.pid` results in: open("/var/kerberos/krb5kdc/principal", O_RDONLY) = -1 ENOENT (No such file or directory) gettimeofday({1396971844, 51536}, NULL) = 0 open("/etc/localtime", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 fstat(4, {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f25440dd000 read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0"..., 4096) = 3519 lseek(4, -2252, SEEK_CUR) = 1267 read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 4096) = 2252 close(4) = 0 munmap(0x7f25440dd000, 4096) = 0 write(3, "Apr 08 11:44:04 i-31f62969 kadmi"..., 105) = 105 write(2, "kadmind: No such file or directo"..., 64kadmind: No such file or directory while initializing, aborting) = 64 close(3) = 0 munmap(0x7f25440df000, 4096) = 0 exit_group(1) = ? As requested in the linked thread, the dbmodules section looks like this: [dbmodules] CLIFF.CLOUDBURRITO.COM = { db_library = ipadb.so } Another important item of note, I have another IPA server which has not been upgraded from 6.3 yet, and the file is missing there too, but kadmind is currently running just fine... Ideas? -Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Tue Apr 8 16:50:48 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Tue, 8 Apr 2014 16:50:48 +0000 Subject: [Freeipa-users] External Collaboration Domains In-Reply-To: <5343FCC6.10209@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net> <20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net> <20140330182619.GA19628@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net> <53389BEA.9050905@redhat.com> <20140408133456.GR20958@redhat.com> <5343FCC6.10209@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E6A7E8E@001FSN2MPN1-045.001f.mgd2.msft.net> Sorry for the delayed reply. This is "other duties as assigned" and the day job got in the way. :) However, the computer is busy running fits to data for the next day or so. My electronic master is thus distracted. > >> Wow! > >> First of all thanks for a nice pictures and sharing your ideas. > >> A lot of work and though put into it. You're welcome. Glad you liked it. > >> Let me just point couple things: > >> 1) It looks like the whole idea is about creating entries for > >> external users on the server when external user authenticates via > >> KDC. But don't we already lookup cache these users in a local SSSD > >> cache and expose via the compat tree for legacy clients? > >> AFAIU the purpose is to be able to create local groups for the > >> external users. May be we can do something and use compat tree DNs > >> for external users? > >> In general it is better to distill the problem we are trying to > >> solve: did I get it right? Close. The problem is to expose kerberized services in the local realm to users holding foreign credentials, supporting SSO wherever possible. This includes file sharing via NFS, kerberized web apps, ssh logins, and anything else the local realm has to offer. SSSD can handle ssh logins (if one considers it "handled" to transmit the password over the wire and abandon SSO), but cannot handle the former two. Also, if foreign users are going to participate in file sharing within the local realm, their UID/GIDs need to be synched among all endpoints in this realm. In general, since users can be coming in from many domains which do not coordinate such assignments among themselves, these IDs need to be harmonized. Furthermore, if users "enter" the local realm via Ipsilon because they're using OpenID or SAML, their point of origin may not maintain that type of information at all. The entity which handles this needs to have the responsibility for doing so on a realm wide basis. > >> 2) I think PKINIT and related part of the proposal is not something > >> that we would do. > >> Instead of PKI based Ipsilon would use GSS proxy that implements > >> s4u2proxy + s4u2self to acquire a ticket on user behalf. > >> This functionality already exists, so there is no new code need. As I understand it, you're suggesting that s4u2self is well suited to address use case three, and it has the added bonus of being already implemented. I don't have time to update the figures for that section now, but I'll put it on the list. To ensure I understand, the proposed flow is: Ipsilon obtains a service ticket to itself on behalf of the remote user via s4u2self. It then uses this service ticket in an s4u2proxy request to obtain a service ticket for krbtgt/LOCAL.REALM, which it then returns to the user. Presumably the only change in proposed auditing would be to monitor s4u2user exchanges for "first encounters" with foreign principals. PKINIT is involved in two use cases. Use case two allows native Kerberos cross realm operation without requiring the close coordination of admins from different domains. In addition, PKINIT is the gateway to interoperating with the grid security infrastructure (GSI) and federations of high-end computing facilities. S4u2self really doesn't address use case two. Presumably, s4u2self will be limited on the IPA side to a small list of whitelisted services such as Ipsilon. Failure to do so could be catastrophic. :) > >> 3) The case when you send TGT back to the client from Ipsilon that > >> authenticated user and acquired TGT on his behalf is an interesting > >> one. The intent for client to later use SSH is understandable though > >> hard to achieve. Currently there is no mechanism for Ipsilon or > >> Ipsilon like gateways to return the TGT for a user and pass it to > >> client browser. There is also no way a browser can save this TGT in > >> the cache. The browser has access to the cache, else it couldn't gssapi/spnego to kerberized websites. I think it's more accurate to say that there is not currently a widely supported mechanism which supports retrieving a Kerberos tgt over nonstandard channels. Fair enough. But use case 3 is not currently widely supported either. Supporting it dramatically reduces the administrative burden on the local realm admins (they don't have to create and maintain accounts for foreign users, or separately negotiate with all the realm admins of each cooperating organization). Supporting use case three also creates a collaborative workspace featuring console logins and secure filesharing while maintaining the ease of identity administration typically associated with federated web-based identities. While not widely supported, there have been some suggestions related to nonstandard tgt delivery. * IAKERB -- http://tools.ietf.org/html/draft-ietf-kitten-iakerb-01 * KDC Proxy -- http://www.freeipa.org/page/KDC_Proxy / MS-KKDCP http://msdn.microsoft.com/en-us/library/hh553774.aspx In addition, use case three also requires coming up with a unique map of users from non-Kerberos origins (OpenID/SAML/etc). If the solution is to be interoperable across realms, this mapping needs to be consistent across realms. Use case three is kind of the holy grail. If it were easy and quick, everyone would be doing it. I think the key is to identify capabilities such as: 1] auditing specific kinds of exchanges with the KDC to identify first contact with a foreign identity; and 2] synthesizing and harmonizing information about foreign identities. With these capabilities in place supporting native Kerberos cross-realm operation, it puts us in a better position to later support foreign identities supplied by a non-Kerberos provider. The bottom line for use case three is that much of the hard stuff can be dumped onto Ipsilon. IPA shouldn't be bothered with authenticating using foreign technologies, nor should it need to map user identities. IPA is Kerberos based and should deal with Kerberos cname/crealm string pairs. It just needs to identify cname/crealms it hasn't seen before and supply enough "extra" information to make the services/hosts in the local realm happy. > >> Bottom line: > >> Let us focus on the problem we are trying to solve here. Keep in mind > >> that we have not started designing IPA to IPA trusts and Kerberos to > >> IPA trusts. It might very well be that we would need to create some > >> external entries for those trusts so IMO looking into these trust > >> scenarios would reveal where our AD integration approach lacks > >> external info and needs to be extended. If we want to solve the high > >> level problem of trusts in general we need to build those specific > >> flows and see what data is not in ldap and we can get it there. A > >> simple mental exercise suggests that we would need something for > >> grouping of the identities coming from a vanilla trusted Kerberos > >> domain. May be this is something we should drill down as a next step? > > Now we have this tracked with the ticket > > https://fedorahosted.org/freeipa/ticket/4287 I agree. :) Further, I believe that if you offload the task of interacting with "alien authentication technologies" to something like Ipsilon, all foreign identities from any source will appear to IPA as if they are coming from a vanilla trusted Kerberos domain. Ipsilon does the mapping. > > Bryce, please continue expanding on your potential use cases using the > > wiki page you've created. I'm not sure we are even close to start > > implementing this but gathering the information is a first step. How do you think I should include interaction with grid security infrastructure? Technically, it's another use of PKINIT, so I'm not thinking it gets its own section. Maybe a paragraph in the existing use case 2? On the other hand, it's a whole separate world of identities. > > I think Dmitri has some valid questions above that might be good to > > answer through your wiki page. > > > And may be we can start smaller. Can we have a concise definition of the > speific problem we are trying to solve here. > May be there are different ways to solve it other than auto creating records. How about the opening of this email? " The problem is to expose kerberized services in the local realm to users holding foreign credentials, supporting SSO wherever possible. This includes file sharing via NFS, kerberized web apps, ssh logins, and anything else the local realm has to offer." Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From freeipa at stormcloud9.net Tue Apr 8 16:40:00 2014 From: freeipa at stormcloud9.net (Patrick Hemmer) Date: Tue, 08 Apr 2014 12:40:00 -0400 Subject: [Freeipa-users] /var/kerberos/krb5kdc/principal missing In-Reply-To: <53441B42.30809@stormcloud9.net> References: <53441B42.30809@stormcloud9.net> Message-ID: <53442660.7070407@stormcloud9.net> Figured it out. Somehow during the upgrade process, the default_realm changed to one of our other domains we use. I'm guessing some RPM postinstall script pulled the domain out of sssd.conf as that's the only place on the box where that domain is mentioned. We don't touch krb5.conf with any sort of configuration management utility. Anyway, after removing the domain from the krb5.conf and restoring the original settings, ipa started up normally. -Patrick ------------------------------------------------------------------------ *From: *Patrick Hemmer *Sent: * 2014-04-08 11:52:34 E *To: *freeipa-users at redhat.com *Subject: *[Freeipa-users] /var/kerberos/krb5kdc/principal missing > I'm having the exact same issue as > http://www.redhat.com/archives/freeipa-users/2013-October/msg00009.html > I upgraded from RHEL-6.3 to RHEL-6.5, and now FreeIPA won't start due > to kadmind not starting. > > The kadmind.log contains an extremely unhelpful: > Apr 08 11:31:20 i-31f62969 kadmind[20850](Error): No such file or > directory while initializing, aborting > > Stracing `/usr/sbin/kadmind -P /var/run/kadmind.pid` results in: > open("/var/kerberos/krb5kdc/principal", O_RDONLY) = -1 ENOENT (No such > file or directory) > gettimeofday({1396971844, 51536}, NULL) = 0 > open("/etc/localtime", O_RDONLY) = 4 > fstat(4, {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 > fstat(4, {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > 0) = 0x7f25440dd000 > read(4, > "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0"..., > 4096) = 3519 > lseek(4, -2252, SEEK_CUR) = 1267 > read(4, > "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., > 4096) = 2252 > close(4) = 0 > munmap(0x7f25440dd000, 4096) = 0 > write(3, "Apr 08 11:44:04 i-31f62969 kadmi"..., 105) = 105 > write(2, "kadmind: No such file or directo"..., 64kadmind: No such > file or directory while initializing, aborting) = 64 > close(3) = 0 > munmap(0x7f25440df000, 4096) = 0 > exit_group(1) = ? > > As requested in the linked thread, the dbmodules section looks like this: > [dbmodules] > CLIFF.CLOUDBURRITO.COM = { > db_library = ipadb.so > } > > Another important item of note, I have another IPA server which has > not been upgraded from 6.3 yet, and the file is missing there too, but > kadmind is currently running just fine... > > Ideas? > > -Patrick > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Apr 8 17:33:53 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Apr 2014 13:33:53 -0400 Subject: [Freeipa-users] /var/kerberos/krb5kdc/principal missing In-Reply-To: <53442660.7070407@stormcloud9.net> References: <53441B42.30809@stormcloud9.net> <53442660.7070407@stormcloud9.net> Message-ID: <53443301.5030207@redhat.com> Patrick Hemmer wrote: > Figured it out. > Somehow during the upgrade process, the default_realm changed to one of > our other domains we use. I'm guessing some RPM postinstall script > pulled the domain out of sssd.conf as that's the only place on the box > where that domain is mentioned. We don't touch krb5.conf with any sort > of configuration management utility. > > Anyway, after removing the domain from the krb5.conf and restoring the > original settings, ipa started up normally. That's really strange.. I wonder if authconfig is doing something. What exactly did the file look like? We do try to update it to fix the dbmodules line but we already know the realm and domain from /etc/ipa/default.conf. rob > > -Patrick > > > ------------------------------------------------------------------------ > *From: *Patrick Hemmer > *Sent: * 2014-04-08 11:52:34 E > *To: *freeipa-users at redhat.com > *Subject: *[Freeipa-users] /var/kerberos/krb5kdc/principal missing > >> I'm having the exact same issue as >> http://www.redhat.com/archives/freeipa-users/2013-October/msg00009.html >> I upgraded from RHEL-6.3 to RHEL-6.5, and now FreeIPA won't start due >> to kadmind not starting. >> >> The kadmind.log contains an extremely unhelpful: >> Apr 08 11:31:20 i-31f62969 kadmind[20850](Error): No such file or >> directory while initializing, aborting >> >> Stracing `/usr/sbin/kadmind -P /var/run/kadmind.pid` results in: >> open("/var/kerberos/krb5kdc/principal", O_RDONLY) = -1 ENOENT (No such >> file or directory) >> gettimeofday({1396971844, 51536}, NULL) = 0 >> open("/etc/localtime", O_RDONLY) = 4 >> fstat(4, {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 >> fstat(4, {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 >> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, >> 0) = 0x7f25440dd000 >> read(4, >> "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0"..., >> 4096) = 3519 >> lseek(4, -2252, SEEK_CUR) = 1267 >> read(4, >> "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., >> 4096) = 2252 >> close(4) = 0 >> munmap(0x7f25440dd000, 4096) = 0 >> write(3, "Apr 08 11:44:04 i-31f62969 kadmi"..., 105) = 105 >> write(2, "kadmind: No such file or directo"..., 64kadmind: No such >> file or directory while initializing, aborting) = 64 >> close(3) = 0 >> munmap(0x7f25440df000, 4096) = 0 >> exit_group(1) = ? >> >> As requested in the linked thread, the dbmodules section looks like this: >> [dbmodules] >> CLIFF.CLOUDBURRITO.COM = { >> db_library = ipadb.so >> } >> >> Another important item of note, I have another IPA server which has >> not been upgraded from 6.3 yet, and the file is missing there too, but >> kadmind is currently running just fine... >> >> Ideas? >> >> -Patrick >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From freeipa at stormcloud9.net Tue Apr 8 17:40:01 2014 From: freeipa at stormcloud9.net (Patrick Hemmer) Date: Tue, 08 Apr 2014 13:40:01 -0400 Subject: [Freeipa-users] /var/kerberos/krb5kdc/principal missing In-Reply-To: <53443301.5030207@redhat.com> References: <53441B42.30809@stormcloud9.net> <53442660.7070407@stormcloud9.net> <53443301.5030207@redhat.com> Message-ID: <53443471.6040507@stormcloud9.net> This is what the non-functional version looked like: includedir /var/lib/sss/pubconf/krb5.include.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = CLOUD.COM dns_lookup_realm = false dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes [realms] CLIFF.CLOUDBURRITO.COM = { kdc = i-31f62969.ipa-server.us-west-1.cliff.cloudburrito.com:88 master_kdc = i-31f62969.ipa-server.us-west-1.cliff.cloudburrito.com:88 admin_server = i-31f62969.ipa-server.us-west-1.cliff.cloudburrito.com:749 default_domain = cliff.cloudburrito.com pkinit_anchors = FILE:/etc/ipa/ca.crt } CLOUD.COM = { kdc = i-6775b715.ipa-server.us-east-1.cloud.com kdc = i-32e87151.ipa-server.us-east-1.cloud.com admin_server = i-31f62969.ipa-server.us-west-1.cliff.cloudburrito.com:749 } [domain_realm] .cliff.cloudburrito.com = CLIFF.CLOUDBURRITO.COM cliff.cloudburrito.com = CLIFF.CLOUDBURRITO.COM cloud.com = CLOUD.COM .cloud.com = CLOUD.COM [dbmodules] CLIFF.CLOUDBURRITO.COM = { db_library = ipadb.so } This is what I did to fix it: --- /etc/krb5.conf.orig 2014-04-08 12:33:01.376525373 -0400 +++ /etc/krb5.conf 2014-04-08 12:33:33.214975855 -0400 @@ -6,7 +6,7 @@ admin_server = FILE:/var/log/kadmind.log [libdefaults] - default_realm = CLOUD.COM + default_realm = CLIFF.CLOUDBURRITO.COM dns_lookup_realm = false dns_lookup_kdc = true rdns = false @@ -22,18 +22,10 @@ pkinit_anchors = FILE:/etc/ipa/ca.crt } - CLOUD.COM = { - kdc = i-6775b715.ipa-server.us-east-1.cloud.com - kdc = i-32e87151.ipa-server.us-east-1.cloud.com - admin_server = i-31f62969.ipa-server.us-west-1.cliff.cloudburrito.com:749 - } - [domain_realm] .cliff.cloudburrito.com = CLIFF.CLOUDBURRITO.COM cliff.cloudburrito.com = CLIFF.CLOUDBURRITO.COM - cloud.com = CLOUD.COM - .cloud.com = CLOUD.COM [dbmodules] CLIFF.CLOUDBURRITO.COM = { db_library = ipadb.so -Patrick ------------------------------------------------------------------------ *From: *Rob Crittenden *Sent: * 2014-04-08 13:33:53 E *To: *Patrick Hemmer , freeipa-users at redhat.com *Subject: *Re: [Freeipa-users] /var/kerberos/krb5kdc/principal missing > Patrick Hemmer wrote: >> Figured it out. >> Somehow during the upgrade process, the default_realm changed to one of >> our other domains we use. I'm guessing some RPM postinstall script >> pulled the domain out of sssd.conf as that's the only place on the box >> where that domain is mentioned. We don't touch krb5.conf with any sort >> of configuration management utility. >> >> Anyway, after removing the domain from the krb5.conf and restoring the >> original settings, ipa started up normally. > > That's really strange.. I wonder if authconfig is doing something. > What exactly did the file look like? We do try to update it to fix the > dbmodules line but we already know the realm and domain from > /etc/ipa/default.conf. > > rob > >> >> -Patrick >> >> >> ------------------------------------------------------------------------ >> *From: *Patrick Hemmer >> *Sent: * 2014-04-08 11:52:34 E >> *To: *freeipa-users at redhat.com >> *Subject: *[Freeipa-users] /var/kerberos/krb5kdc/principal missing >> >>> I'm having the exact same issue as >>> http://www.redhat.com/archives/freeipa-users/2013-October/msg00009.html >>> I upgraded from RHEL-6.3 to RHEL-6.5, and now FreeIPA won't start due >>> to kadmind not starting. >>> >>> The kadmind.log contains an extremely unhelpful: >>> Apr 08 11:31:20 i-31f62969 kadmind[20850](Error): No such file or >>> directory while initializing, aborting >>> >>> Stracing `/usr/sbin/kadmind -P /var/run/kadmind.pid` results in: >>> open("/var/kerberos/krb5kdc/principal", O_RDONLY) = -1 ENOENT (No such >>> file or directory) >>> gettimeofday({1396971844, 51536}, NULL) = 0 >>> open("/etc/localtime", O_RDONLY) = 4 >>> fstat(4, {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 >>> fstat(4, {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 >>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, >>> 0) = 0x7f25440dd000 >>> read(4, >>> "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0"..., >>> 4096) = 3519 >>> lseek(4, -2252, SEEK_CUR) = 1267 >>> read(4, >>> "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., >>> 4096) = 2252 >>> close(4) = 0 >>> munmap(0x7f25440dd000, 4096) = 0 >>> write(3, "Apr 08 11:44:04 i-31f62969 kadmi"..., 105) = 105 >>> write(2, "kadmind: No such file or directo"..., 64kadmind: No such >>> file or directory while initializing, aborting) = 64 >>> close(3) = 0 >>> munmap(0x7f25440df000, 4096) = 0 >>> exit_group(1) = ? >>> >>> As requested in the linked thread, the dbmodules section looks like >>> this: >>> [dbmodules] >>> CLIFF.CLOUDBURRITO.COM = { >>> db_library = ipadb.so >>> } >>> >>> Another important item of note, I have another IPA server which has >>> not been upgraded from 6.3 yet, and the file is missing there too, but >>> kadmind is currently running just fine... >>> >>> Ideas? >>> >>> -Patrick >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maleko42 at gmail.com Tue Apr 8 19:17:21 2014 From: maleko42 at gmail.com (Mark Gardner) Date: Tue, 8 Apr 2014 15:17:21 -0400 Subject: [Freeipa-users] freeIPA client sudo / sssd setup Message-ID: I know I'm missing something simple. But I just can't get this ipa client to accept any sudo rules. -sh-4.1$ sudo -l [sudo] password for testadm at domain.com: User testadm at domain.com is not allowed to run sudo on cypress. -sh-4.1$ id uid=11659(testadm at domain.com) gid=11659(testadm at domain.com) groups=11659(testadm at domain. com),160400007(ad_klasadm) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 -sh-4.1$ kinit admin Password for admin at HOSTED.DOMAIN.COM: -sh-4.1$ ipa sudorule-show operations Rule name: operations Description: KLAS / System Admins Enabled: TRUE Command category: all Users: localadm User Groups: ad_operations, ad_operations_external, ad_klasadm, ad_klasadm_external /var/log/sssd/sssd_sudo.log (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting rules for [testadm] from [DOMAIN.COM] (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requestinginfo about [testadm at DOMAIN.COM] (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [testadm at DOMAIN.COM] (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving rules for [testadm at DOMAIN.COM] from [DOMAIN.COM] (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sysdb_search_group_by_gid] (0x0400): No such entry (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser= testadm at DOMAIN.COM )(sudoUser=#11659)(sudoUser=%ad_klasadm)(sudoUser=+*))(&(dataExpireTimestamp<=1396984126)))] (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sysdb_search_group_by_gid] (0x0400): No such entry (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=testadm at DOMAIN.COM )(sudoUser=#11659)(sudoUser=%ad_klasadm)(sudoUser=+*)))] (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 1 rules for [testadm at DOMAIN.COM] (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [client_recv] (0x0200): Client disconnected! [root at cypress etc]# cat nsswitch.conf # # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=return]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Valid entries include: # # nisplus Use NIS+ (NIS version 3) # nis Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files # db Use the local database (.db) files # compat Use NIS on compat mode # hesiod Use Hesiod for user lookups # [NOTFOUND=return] Stop searching if not found so far # # To use db, put the "db" in front of "files" for entries you want to be # looked up first in the databases # # Example: #passwd: db files nisplus nis #shadow: db files nisplus nis #group: db files nisplus nis passwd: files sss shadow: files sss group: files sss sudoers: files sss #hosts: db files nisplus nis dns hosts: files dns # Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss publickey: nisplus automount: files aliases: files nisplus [root at cypress etc]# cd sssd [root at cypress sssd]# ls sssd.conf sssd.conf.deleted sssd.conf.sv [root at cypress sssd]# cat sssd.conf [domain/hosted.domain.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = hosted.domain.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = cypress.hosted.domain.com chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, ipa.hosted.domain.com ldap_tls_cacert = /etc/ipa/ca.crt debug_level=6 # # sudo integration # sudo_provider = ldap ldap_uri = ldap://ipa.hosted.domain.com ldap_sudo_search_base = ou=sudoers,dc=hosted,dc=domain,dc=com ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/cypress.hosted.domain.com ldap_sasl_realm = HOSTED.DOMAIN.COM krb5_server = ipa.hosted.domain.com [sssd] services = nss, pam, ssh, pac, sudo config_file_version = 2 domains = hosted.domain.com debug_level=6 [nss] [pam] [sudo] debug_level=6 [autofs] [ssh] [pac] [root at cypress sssd]# -------------- next part -------------- An HTML attachment was scrubbed... URL: From genadipost at gmail.com Tue Apr 8 19:30:47 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Tue, 8 Apr 2014 22:30:47 +0300 Subject: [Freeipa-users] freeIPA client sudo / sssd setup In-Reply-To: References: Message-ID: Have you installed libsss_sudo? Try to follow the instruction here: https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html and http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf 2014-04-08 22:17 GMT+03:00 Mark Gardner : > I know I'm missing something simple. But I just can't get this ipa client > to accept any sudo rules. > > -sh-4.1$ sudo -l > [sudo] password for testadm at domain.com: > User testadm at domain.com is not allowed to run sudo on cypress. > -sh-4.1$ id > uid=11659(testadm at domain.com) gid=11659(testadm at domain.com) > groups=11659(testadm at domain. > com),160400007(ad_klasadm) > context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > > -sh-4.1$ kinit admin > Password for admin at HOSTED.DOMAIN.COM: > -sh-4.1$ ipa sudorule-show operations > Rule name: operations > Description: KLAS / System Admins > Enabled: TRUE > Command category: all > Users: localadm > User Groups: ad_operations, ad_operations_external, ad_klasadm, > ad_klasadm_external > > /var/log/sssd/sssd_sudo.log > (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_cmd_parse_query_done] > (0x0200): Requesting rules for [testadm] from [DOMAIN.COM] > (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_get_user] (0x0200): > Requestinginfo about [testadm at DOMAIN.COM] > (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_get_user] (0x0400): > Returning info for user [testadm at DOMAIN.COM] > (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_get_rules] (0x0400): > Retrieving rules for [testadm at DOMAIN.COM] from [DOMAIN.COM] > (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sysdb_search_group_by_gid] > (0x0400): No such entry > (Tue Apr 8 15:08:46 2014) [sssd[sudo]] > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser= > testadm at DOMAIN.COM > )(sudoUser=#11659)(sudoUser=%ad_klasadm)(sudoUser=+*))(&(dataExpireTimestamp<=1396984126)))] > (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sysdb_search_group_by_gid] > (0x0400): No such entry > (Tue Apr 8 15:08:46 2014) [sssd[sudo]] > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=testadm at DOMAIN.COM > )(sudoUser=#11659)(sudoUser=%ad_klasadm)(sudoUser=+*)))] > (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] > (0x0400): Returning 1 rules for [testadm at DOMAIN.COM] > (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [client_recv] (0x0200): Client > disconnected! > > > [root at cypress etc]# cat nsswitch.conf > # > # /etc/nsswitch.conf > # > # An example Name Service Switch config file. This file should be > # sorted with the most-used services at the beginning. > # > # The entry '[NOTFOUND=return]' means that the search for an > # entry should stop if the search in the previous entry turned > # up nothing. Note that if the search failed due to some other reason > # (like no NIS server responding) then the search continues with the > # next entry. > # > # Valid entries include: > # > # nisplus Use NIS+ (NIS version 3) > # nis Use NIS (NIS version 2), also called YP > # dns Use DNS (Domain Name Service) > # files Use the local files > # db Use the local database (.db) files > # compat Use NIS on compat mode > # hesiod Use Hesiod for user lookups > # [NOTFOUND=return] Stop searching if not found so far > # > > # To use db, put the "db" in front of "files" for entries you want to be > # looked up first in the databases > # > # Example: > #passwd: db files nisplus nis > #shadow: db files nisplus nis > #group: db files nisplus nis > > passwd: files sss > shadow: files sss > group: files sss > sudoers: files sss > > #hosts: db files nisplus nis dns > hosts: files dns > > # Example - obey only what nisplus tells us... > #services: nisplus [NOTFOUND=return] files > #networks: nisplus [NOTFOUND=return] files > #protocols: nisplus [NOTFOUND=return] files > #rpc: nisplus [NOTFOUND=return] files > #ethers: nisplus [NOTFOUND=return] files > #netmasks: nisplus [NOTFOUND=return] files > > bootparams: nisplus [NOTFOUND=return] files > > ethers: files > netmasks: files > networks: files > protocols: files > rpc: files > services: files sss > > netgroup: files sss > > publickey: nisplus > > automount: files > aliases: files nisplus > > [root at cypress etc]# cd sssd > [root at cypress sssd]# ls > sssd.conf sssd.conf.deleted sssd.conf.sv > [root at cypress sssd]# cat sssd.conf > [domain/hosted.domain.com] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = hosted.domain.com > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = cypress.hosted.domain.com > chpass_provider = ipa > ipa_dyndns_update = True > ipa_server = _srv_, ipa.hosted.domain.com > ldap_tls_cacert = /etc/ipa/ca.crt > debug_level=6 > > # > # sudo integration > # > sudo_provider = ldap > ldap_uri = ldap://ipa.hosted.domain.com > ldap_sudo_search_base = ou=sudoers,dc=hosted,dc=domain,dc=com > ldap_sasl_mech = GSSAPI > ldap_sasl_authid = host/cypress.hosted.domain.com > ldap_sasl_realm = HOSTED.DOMAIN.COM > krb5_server = ipa.hosted.domain.com > > > [sssd] > services = nss, pam, ssh, pac, sudo > config_file_version = 2 > domains = hosted.domain.com > debug_level=6 > > [nss] > > > [pam] > > > [sudo] > debug_level=6 > > [autofs] > > [ssh] > > > [pac] > > [root at cypress sssd]# > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan.f77 at gmail.com Tue Apr 8 19:52:19 2014 From: nathan.f77 at gmail.com (Nathan Broadbent) Date: Tue, 8 Apr 2014 12:52:19 -0700 Subject: [Freeipa-users] freeIPA client sudo / sssd setup In-Reply-To: References: Message-ID: > > I know I'm missing something simple. But I just can't get this ipa >> client to accept any sudo rules. >> >> I rand into the same issue. It's not documented anywhere, but you need to enable the 'sudo' service in /etc/sssd/sssd.conf You need to change: [sssd] services = nss, pam, ssh to: [sssd] services = nss, pam, ssh, sudo and then restart sssd. (sudo service sssd restart) Best, Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Tue Apr 8 20:24:58 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 8 Apr 2014 22:24:58 +0200 Subject: [Freeipa-users] freeIPA client sudo / sssd setup In-Reply-To: References: Message-ID: <20140408202457.GA23487@mail.corp.redhat.com> On (08/04/14 12:52), Nathan Broadbent wrote: >> >> I know I'm missing something simple. But I just can't get this ipa >>> client to accept any sudo rules. >>> >>> >I rand into the same issue. It's not documented anywhere, but you need to >enable the 'sudo' service in /etc/sssd/sssd.conf > >You need to change: >[sssd] >services = nss, pam, ssh > >to: >[sssd] >services = nss, pam, ssh, sudo > > >and then restart sssd. (sudo service sssd restart) man sssd-sudo says: CONFIGURING SSSD TO FETCH SUDO RULES All configuration that is needed on SSSD side is to extend the list of services with "sudo" in [sssd] section of sssd.conf(5). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I would say it is documented, but nobody pointed you to manual pages. LS From nathan.f77 at gmail.com Tue Apr 8 20:34:55 2014 From: nathan.f77 at gmail.com (Nathan Broadbent) Date: Tue, 8 Apr 2014 13:34:55 -0700 Subject: [Freeipa-users] freeIPA client sudo / sssd setup In-Reply-To: <20140408202457.GA23487@mail.corp.redhat.com> References: <20140408202457.GA23487@mail.corp.redhat.com> Message-ID: > > man sssd-sudo says: > CONFIGURING SSSD TO FETCH SUDO RULES > All configuration that is needed on SSSD side is > to extend the list of services with "sudo" in [sssd] section of > sssd.conf(5). > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I would say it is documented, but nobody pointed you to manual pages. > > Ah, you are right, sorry I said it was undocumented. I think it's a good idea to enable sssd-sudo by default when we run ipa-client-install, or at least, add it as an option to the ipa-client-install script. As a new user, I also spent a while trying to figure out why my sudo rules weren't having any effect. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Tue Apr 8 20:42:55 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 8 Apr 2014 22:42:55 +0200 Subject: [Freeipa-users] freeIPA client sudo / sssd setup In-Reply-To: References: <20140408202457.GA23487@mail.corp.redhat.com> Message-ID: <20140408204254.GB23487@mail.corp.redhat.com> On (08/04/14 13:34), Nathan Broadbent wrote: >> >> man sssd-sudo says: >> CONFIGURING SSSD TO FETCH SUDO RULES >> All configuration that is needed on SSSD side is >> to extend the list of services with "sudo" in [sssd] section of >> sssd.conf(5). >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> I would say it is documented, but nobody pointed you to manual pages. >> >> >Ah, you are right, sorry I said it was undocumented. I think it's a good >idea to enable sssd-sudo by default when we run ipa-client-install, or at >least, add it as an option to the ipa-client-install script. As a new user, >I also spent a while trying to figure out why my sudo rules weren't having >any effect. Work in progress https://fedorahosted.org/freeipa/ticket/3358 You can add yourself to CC if you are intrested in this ticket. LS From justin.brown at fandingo.org Tue Apr 8 21:42:57 2014 From: justin.brown at fandingo.org (Justin Brown) Date: Tue, 8 Apr 2014 16:42:57 -0500 Subject: [Freeipa-users] Partial Domain Authority Message-ID: I'm sure that I'm doing this very wrong, but I'm wondering if anyone can offer any solutions. I currently have a relatively small domain that's used internally. Let's say fandingo.org. This domain covers various class C networks on 192.168.0.0/16. Currently, there's an Active Directory server that provides internal (and forwarding) DNS for fandingo.org. I'm in the experimentation phase with FreeIPA in this environment and don't want to modify anything outside of FreeIPA for the time being. FreeIPA is setup with DNS and has the fandingo.org domain controllers setup as forwarders. I have my laptop joined to the FreeIPA domain, but that's where the problem starts. I can correctly resolve any *.fandingo.org resource in FreeIPA. The problem is that I want to resolve *.fandingo.org resources that are defined in the Active Directory DNS. Does anyone know how I can configure FreeIPA/BIND to forward all requests (even those for its own domain) that it can't satisfy rather than returning NXDOMAIN? Thanks, Justin From simo at redhat.com Tue Apr 8 22:06:58 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 08 Apr 2014 18:06:58 -0400 Subject: [Freeipa-users] Partial Domain Authority In-Reply-To: References: Message-ID: <1396994818.19767.4.camel@willson.li.ssimo.org> On Tue, 2014-04-08 at 16:42 -0500, Justin Brown wrote: > I'm sure that I'm doing this very wrong, but I'm wondering if anyone > can offer any solutions. > > I currently have a relatively small domain that's used internally. > Let's say fandingo.org. This domain covers various class C networks on > 192.168.0.0/16. Currently, there's an Active Directory server that > provides internal (and forwarding) DNS for fandingo.org. I'm in the > experimentation phase with FreeIPA in this environment and don't want > to modify anything outside of FreeIPA for the time being. > > FreeIPA is setup with DNS and has the fandingo.org domain controllers > setup as forwarders. I have my laptop joined to the FreeIPA domain, > but that's where the problem starts. I can correctly resolve any > *.fandingo.org resource in FreeIPA. The problem is that I want to > resolve *.fandingo.org resources that are defined in the Active > Directory DNS. > > Does anyone know how I can configure FreeIPA/BIND to forward all > requests (even those for its own domain) that it can't satisfy rather > than returning NXDOMAIN? Is FreeIPA shadowing an AD domain ? Ie are the Ad domain and FreeIPA domain using the same domain name ? That would be bad. If you want to manage fadnigo.org in AD it would be a better idea to create a ipa.fandingo.org domain for IPA. Then set forwarders *both* way (or just delegate the domain from AD), to IPA, so all clients regardless of what DNS server are using can resolve both *fandingo.org hosts (via AD DNS) and *.ipa.fandingo.org hosts (via FreeIPa DNS). Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Apr 8 23:44:41 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 08 Apr 2014 19:44:41 -0400 Subject: [Freeipa-users] External Collaboration Domains In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E6A7E8E@001FSN2MPN1-045.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net> <20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net> <20140330182619.GA19628@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net> <53389BEA.9050905@redhat.com> <20140408133456.GR20958@redhat.com> <5343FCC6.10209@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A7E8E@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <534489E9.9090809@redhat.com> On 04/08/2014 12:50 PM, Nordgren, Bryce L -FS wrote: > Sorry for the delayed reply. This is "other duties as assigned" and the day job got in the way. :) However, the computer is busy running fits to data for the next day or so. My electronic master is thus distracted. > >>>> Wow! >>>> First of all thanks for a nice pictures and sharing your ideas. >>>> A lot of work and though put into it. > You're welcome. Glad you liked it. > >>>> Let me just point couple things: >>>> 1) It looks like the whole idea is about creating entries for >>>> external users on the server when external user authenticates via >>>> KDC. But don't we already lookup cache these users in a local SSSD >>>> cache and expose via the compat tree for legacy clients? >>>> AFAIU the purpose is to be able to create local groups for the >>>> external users. May be we can do something and use compat tree DNs >>>> for external users? >>>> In general it is better to distill the problem we are trying to >>>> solve: did I get it right? > Close. The problem is to expose kerberized services in the local realm to users holding foreign credentials, supporting SSO wherever possible. This includes file sharing via NFS, kerberized web apps, ssh logins, and anything else the local realm has to offer. SSSD can handle ssh logins (if one considers it "handled" to transmit the password over the wire and abandon SSO), but cannot handle the former two. This is already handled with the trusts feature with AD. It is handled by SSO and using Kerberos ticket renegotiation between two domains. The similar approach would work for IPA to IPA and IPA to Kerberos. In the IPA to IPA case we will have authorization data in the ticket that would help with this. I am sorry I fail to see a driver and use case here. But may be I am missing something obvious. > Also, if foreign users are going to participate in file sharing within the local realm, their UID/GIDs need to be synched among all endpoints in this realm. But they already are at least in the AD case! Same can be applied to other cases. > In general, since users can be coming in from many domains which do not coordinate such assignments among themselves, these IDs need to be harmonized. Furthermore, if users "enter" the local realm via Ipsilon because they're using OpenID or SAML, their point of origin may not maintain that type of information at all. The entity which handles this needs to have the responsibility for doing so on a realm wide basis. You might be right here but we yet to understand whether there are actually the flows that would require creation of such users and which part would be in charge of doing them. It might be very well that Ipsilon will be seeing new external users first and will be creating them as needed based on the policies. I actually suspect that this would be the case. But we are not there yet even as a use case. > > >>>> 2) I think PKINIT and related part of the proposal is not something >>>> that we would do. >>>> Instead of PKI based Ipsilon would use GSS proxy that implements >>>> s4u2proxy + s4u2self to acquire a ticket on user behalf. >>>> This functionality already exists, so there is no new code need. > > As I understand it, you're suggesting that s4u2self is well suited to address use case three, and it has the added bonus of being already implemented. I don't have time to update the figures for that section now, but I'll put it on the list. To ensure I understand, the proposed flow is: Ipsilon obtains a service ticket to itself on behalf of the remote user via s4u2self. It then uses this service ticket in an s4u2proxy request to obtain a service ticket for krbtgt/LOCAL.REALM, Yes so far > which it then returns to the user. This part is a gray area. I do not think protocol allows for it. But I am still not sure it is needed. Let us say we have an application. User U presents a credential X to the application A. Application needs to perform an operation against application B on behalf of the user. It will do a call using GSS API. GSS API will use GSS proxy (already available in Fedora and RHEL7). GSS Proxy is already capable of the s4u2self + s4u2proxy it can do it behind the scenes and provide everything needs for the connection from A to B be authenticated using user's identity. This is the direction we have been going and this is the area we are expanding on. > Presumably the only change in proposed auditing would be to monitor s4u2user exchanges for "first encounters" with foreign principals. I am still not buying into the whole idea that intercepting the cross realm kerberos traffic is the right step to synthesize remote users. For AD integration we do not need that because the external groups can be created when you define HBAC and resolved at runtime using info from the ticket, no need to create user entries. The same will happen with IPA <-> IPA. I think it is a good practice not to create user entries for the users that you do not control. For UID and GID if users is from AD we have two options - create UID/GID from SID or use it from AD itself by performing a lookup from SSSD client. We still have a use case that we have not solved. This is the use case when deployment wants to use UID/GID stored in IPA but user coming over the trust. But in this case the user will be already created in IPA. This is sort of migration use case from an old NIS setups. As new users will be added on AD side they will not need POSIX attributes in IdM since the SID to UID/GID conversion will kick in. So even in this case automatic creation of entries does not seem to be needed. > > PKINIT is involved in two use cases. Use case two allows native Kerberos cross realm operation without requiring the close coordination of admins from different domains. In addition, PKINIT is the gateway to interoperating with the grid security infrastructure (GSI) and federations of high-end computing facilities. S4u2self really doesn't address use case two. > > Presumably, s4u2self will be limited on the IPA side to a small list of whitelisted services such as Ipsilon. Failure to do so could be catastrophic. :) There are already ways to control it in IPA they are just not exposed in UI or CLI > >>>> 3) The case when you send TGT back to the client from Ipsilon that >>>> authenticated user and acquired TGT on his behalf is an interesting >>>> one. The intent for client to later use SSH is understandable though >>>> hard to achieve. Currently there is no mechanism for Ipsilon or >>>> Ipsilon like gateways to return the TGT for a user and pass it to >>>> client browser. There is also no way a browser can save this TGT in >>>> the cache. > The browser has access to the cache, else it couldn't gssapi/spnego to kerberized websites. I think it's more accurate to say that there is not currently a widely supported mechanism which supports retrieving a Kerberos tgt over nonstandard channels. ...and _saving_ it on the client system for other components to use. The key part is that browser can read the cache but it can't write to it. There however an idea tham may be browsers can be taught to use IEKERB. But this would be quire an effort to make browsers do that. If they are taught then the exchange would happen behind the scenes but kinit will be sort of integrated into browser and run on the browser side. > > Fair enough. But use case 3 is not currently widely supported either. Supporting it dramatically reduces the administrative burden on the local realm admins (they don't have to create and maintain accounts for foreign users, or separately negotiate with all the realm admins of each cooperating organization). Supporting use case three also creates a collaborative workspace featuring console logins and secure filesharing while maintaining the ease of identity administration typically associated with federated web-based identities. Existing trusts already support that. Please watch the videos that we prepare for summit next week once they are published. It will give you some hints. > > While not widely supported, there have been some suggestions related to nonstandard tgt delivery. > > * IAKERB -- http://tools.ietf.org/html/draft-ietf-kitten-iakerb-01 > * KDC Proxy -- http://www.freeipa.org/page/KDC_Proxy / MS-KKDCP http://msdn.microsoft.com/en-us/library/hh553774.aspx > > In addition, use case three also requires coming up with a unique map of users from non-Kerberos origins (OpenID/SAML/etc). If the solution is to be interoperable across realms, this mapping needs to be consistent across realms. > > Use case three is kind of the holy grail. If it were easy and quick, everyone would be doing it. I think the key is to identify capabilities such as: 1] auditing specific kinds of exchanges with the KDC to identify first contact with a foreign identity; and 2] synthesizing and harmonizing information about foreign identities. With these capabilities in place supporting native Kerberos cross-realm operation, it puts us in a better position to later support foreign identities supplied by a non-Kerberos provider. > > The bottom line for use case three is that much of the hard stuff can be dumped onto Ipsilon. IPA shouldn't be bothered with authenticating using foreign technologies, nor should it need to map user identities. IPA is Kerberos based and should deal with Kerberos cname/crealm string pairs. It just needs to identify cname/crealms it hasn't seen before and supply enough "extra" information to make the services/hosts in the local realm happy. May be. So can we split the proposal into smaller parts? May be have a high level page that describes what we want to accomplish and then take it from there? So far I see that creation of the external users might be needed only if the users are coming from non kerberos sources. > >>>> Bottom line: >>>> Let us focus on the problem we are trying to solve here. Keep in mind >>>> that we have not started designing IPA to IPA trusts and Kerberos to >>>> IPA trusts. It might very well be that we would need to create some >>>> external entries for those trusts so IMO looking into these trust >>>> scenarios would reveal where our AD integration approach lacks >>>> external info and needs to be extended. If we want to solve the high >>>> level problem of trusts in general we need to build those specific >>>> flows and see what data is not in ldap and we can get it there. A >>>> simple mental exercise suggests that we would need something for >>>> grouping of the identities coming from a vanilla trusted Kerberos >>>> domain. May be this is something we should drill down as a next step? >>> Now we have this tracked with the ticket >>> https://fedorahosted.org/freeipa/ticket/4287 > I agree. :) Further, I believe that if you offload the task of interacting with "alien authentication technologies" to something like Ipsilon, all foreign identities from any source will appear to IPA as if they are coming from a vanilla trusted Kerberos domain. Ipsilon does the mapping. And may be creation in needed... > >>> Bryce, please continue expanding on your potential use cases using the >>> wiki page you've created. I'm not sure we are even close to start >>> implementing this but gathering the information is a first step. > How do you think I should include interaction with grid security infrastructure? Technically, it's another use of PKINIT, so I'm not thinking it gets its own section. Maybe a paragraph in the existing use case 2? On the other hand, it's a whole separate world of identities. The page now is too long and complex. It is hard to follow it touches many use cases and flow can can be discussed independently. I agree that this needs to be sorted out but let us build it from a smaller blocks and get people on board. So far you lost most of the audience :-) Let us start small - use cases and agree on them. Then we can take then one at a time and see where the overlaps and common patterns. It is great that you already have an uber picture in mind but it is hard to align an uber picture with pictures others have. If you build it gradually you also build agreement and buy-in that this is what and how we age going to do long term as a community. Keep in mind that some of the areas that you are concerned about we have not though about much. We acknowledged their existence but they are a bit too far in future for it to be practical to talk about them yet. > >>> I think Dmitri has some valid questions above that might be good to >>> answer through your wiki page. >>> >> And may be we can start smaller. Can we have a concise definition of the >> speific problem we are trying to solve here. >> May be there are different ways to solve it other than auto creating records. > How about the opening of this email? " The problem is to expose kerberized services in the local realm to users holding foreign credentials, supporting SSO wherever possible. This includes file sharing via NFS, kerberized web apps, ssh logins, and anything else the local realm has to offer." Sure however I would start with a wiki page that would create a table: Remote/Local NFS Web application SSH Something else Trusted AD <-------- Solved with trusts -----------> Trusted IdM <--------Will be solved with trusts ----> External not Kerberos user ??? ??? ??? ... So what we really trying to do is to define how users that do not have Kerberos identity in the local realm and not authenticating Kerberos would be able to access resources. This is a fine goal so let us create sub pages in places of ??? and see what makes sense and what not. IMO it would be easier to digest this way. Agree? > > Bryce Thanks for being patient with us it is really appreciated. We are glad that you are pushing things forward, we just might be a bit slow to grasp your ideas :-) > > > > > This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From shreerajkarulkar at yahoo.com Wed Apr 9 00:22:46 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Tue, 8 Apr 2014 17:22:46 -0700 (PDT) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1396278876.85775.YahooMailNeo@web160104.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <53051B35.2050409@redhat.com> <1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com! > <53051F62.40405@redhat.com> <1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com! > <53052E64.3050903@redhat.com> <1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.c! ! om> <53061B18.40001@redhat.com> <1392926335.76571.YahooMailNeo@web160105.mail.bf1.yahoo.com> <53066CD0.5080501@redhat.! ! com> <1392958339.79606.YahooMailNeo@web160106.mail.bf1.yahoo.com> <1395265074.69093.YahooMailNeo@web160101.mail.bf1.yahoo! ! .com> <532A9E07.6040604@redhat.com> <1395445491.29606.YahooMailNeo@web160105.mail.bf1.yahoo.com> <532DFCD0.8060907@redhat.com> <1395685201.97247.YahooMailNeo@web160104.mail.bf1.yahoo.com> <5331353C.9030603@redhat.com> <1396046096.70517.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5339756D.5080108@redhat.com> <1396278174.64201.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5339853E.8080108@redhat! ! .com> <1396278876.85775.YahooMailNeo@web160104.mail.bf1.yahoo.com> Message-ID: <1397002966.79747.YahooMailNeo@web160103.mail.bf1.yahoo.com> Not sure if anyone read my last reply I was still not having any luck. Anyways I found the file which was causing it to contact the old IP address just a few minutes ago. Though I would share with you in case someone else may need it. I started going through the directory listed in the krb5.conf file [ includedir /var/lib/sss/pubconf/krb5.include.d/ ] Just one level up there was a file called kdcinfo.MYDOMAIN.COM which had the old IP address. I changed it to the new one and kinit started working fine. I was able to install ipa-client without any issues. I still cannot figure out why only one of my several servers behaved this way. Thanks ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Monday, March 31, 2014 8:22 AM, Shree wrote: Excellent Rob I see that it is trying the IP address on the main master (ldap.mydomain) and not the ldap2.mydomain. So how do I fix it or where do I find that? ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Monday, March 31, 2014 8:09 AM, Rob Crittenden wrote: Shree wrote: > Rob > This is what I get. Realm is case-sensitive, try skarulkar at MYDOMAIN.COM rob > > [root at www ~]# KRB5_TRACE=/dev/stdout kinit skarulkar at mydomain.com > [14858] 1396278013.584391: Getting initial credentials for > skarulkar at mydomain.com > [14858] 1396278013.584975: Sending request (188 bytes) to mydomain.com > [14858] 1396278013.585470: Retrying AS request with master KDC > [14858] 1396278013.585492: Getting initial credentials for > skarulkar at mydomain.com > [14858] 1396278013.585848: Sending request (188 bytes) to mydomain.com > (master) > kinit: Cannot find KDC for requested realm while getting initial credentials > [root at www ~]# > > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > On Monday, March 31, 2014 7:02 AM, Rob Crittenden > wrote: > Shree wrote: >? > Martin >? > First of all thank you so much for your detailed analysis. I got a >? > chance to finally take a look at it today. I tried your suggested >? > changes to the /etc/krb5.conf and I now get the following response. >? > >? > [root at www ~]# kinit >? > kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting >? > initial credentials >? > [root at www ~]# kinit skarulkar >? > kinit: Cannot contact any KDC for realm ''MYDOMAIN.COM' while getting >? > initial credentials >? > [root at www ~]# vi /etc/krb5.conf >? > [root at www ~]# kinit skarulkar at mydomain.com > >? > kinit: Cannot find KDC for requested realm while getting initial > credentials >? > >? > Now I have seen this issue earlier in the project but I don't remember >? > what I did to fix this. >? > >? > ldap.mydomain.com is our primary which connects to ldap2.mydomain.com >? > that exists in a separate VLAN? through specific ACLs in the firewall. >? > They sync with each other fine. My clients are only able to talk to >? > ldap2.mydomain.com. And out of 40 + clients that I moved from ldap to >? > ldap2 I only seem to have issue with this last one? >? > I have even tried dropping a test VM in the same VLAN and it had no >? > issues joining the IPA. So that rules out any ACL misconfigurations to >? > this VLAN. > > Did you try the tracing that Martin suggested? > > rob > >? > >? > >? > Shreeraj >? > > ---------------------------------------------------------------------------------------- >? > >? > >? > Change is the only Constant ! >? > >? > >? > On Tuesday, March 25, 2014 12:55 AM, Martin Kosek > wrote: >? > It searching for ldap.mydomain.com because you still have DNS SRV record >? > _kerberos._udp.mydomain.com. pointing to it. I would start there. >? > >? > As for the failure, I would check that the generated /etc/krb5.conf is >? > correct: >? > >? > ~~~~~~~~~ >? > includedir /var/lib/sss/pubconf/krb5.include.d/ >? > >? > [libdefaults] >? > default_realm = MYDOMAIN.COM >? >? ? dns_lookup_realm = false >? >? ? dns_lookup_kdc = false >? >? ? rdns = false >? >? ? ticket_lifetime = 24h >? >? ? forwardable = yes >? > >? > [realms] >? >? ? MYDOMAIN.COM = { >? >? ? ? kdc = ldap2.mydomain.com:88 >? >? ? ? master_kdc = ldap2.mydomain.com:88 >? >? ? ? admin_server = ldap2.mydomain.com:749 >? >? ? ? default_domain = mydomain.com >? >? ? ? pkinit_anchors = FILE:/etc/ipa/ca.crt >? >? ? } >? > >? > [domain_realm] >? >? ? .mydomain.com = MYDOMAIN.COM >? >? ? mydomain.com = MYDOMAIN.COM >? >? ? .mydomain.com = MYDOMAIN.COM >? >? ? mydomain.com = MYDOMAIN.COM >? > ~~~~~~~~ >? > >? > (I assume you did more anonymizing that expected, ipa-client-install >? > does not >? > generate 2 domain_realm mappings unless client domain is different that >? > server >? > domain (e.g. client.other.mydomain.com and server.mydomain.com)). >? > >? > What I would do in your place is to: >? > 1) Backup your current /etc/krb5.conf >? > 2) Replace it with the krb5.conf which was generated during >? > ipa-client-install >? > (you can find non-anonymized version in ipaclient-install.log) >? > 3) Try to kinit: kinit skarulkar at MYDOMAIN.COM > >? > > >? > >? > Then it will be easier to troubleshoot. To get more information what > kinit >? > actually does, try enabling a trace: >? > >? > # KRB5_TRACE=/dev/stdout kinit skarulkar at MYDOMAIN.COM > >? > > >? > >? > You will be then able to see if it really connects to right IP > address which >? > would enable you to debug further. >? > >? > Martin >? > >? > On 03/24/2014 07:20 PM, Shree wrote: >? >? > If you look at the attached logs, you can see it is going to the >? > correct dns server. dig information is also correct. There is something >? > else going on I can figure out what? >? >? > >? >? > >? >? > >? >? > Shreeraj >? >? > >? > > ---------------------------------------------------------------------------------------- >? > >? >? > >? >? > Change is the only Constant ! >? >? > >? >? > >? >? > >? >? > On Saturday, March 22, 2014 2:12 PM, Dmitri Pal >? > >> wrote: >? >? > >? >? > On 03/21/2014 07:44 PM, Shree wrote: >? >? > Hi >? >? >> Attaching the install log. It complains about unable to reach >? >? >? ? ? ? certain ports, however my tests by using telnet were > successful. >? >? >? ? ? ? Also to refresh your memory the client should be reaching for >? >? >? ? ? ? the replica lda2.mydomain.com and not ldap.mydomain.com > which it >? >? >? ? ? ? does for the most part but I found a couple of instances of >? >? >? ? ldap.mydomain.com in the log. Let me know what you find. I can't >? >? >? ? ? ? believe I migrated over 40 servers and only this one refuses to >? >? >? ? ? ? install ipa-client. >? >? >> >? >? >> >? >? > If it is getting to the wrong server then it is either looking at >? >? >? ? the wrong DNS server (see resolve.conf) which is telling it to use >? >? >? ? the wrong IPA server (may be from some old try/POC) or it has some >? >? >? ? explicit entries entered in /etc/hosts. >? >? > >? >? > >? >? > >? >? > >? >? >> >? >? >> >? >? >> Shreeraj >? >? >> >? > > ---------------------------------------------------------------------------------------- >? > >? >? >> >? >? >> Change is the only Constant ! >? >? >> >? >? >> >? >? >> >? >? >> On Thursday, March 20, 2014 4:29 AM, Martin Kosek > >? > >> wrote: >? >? >> >? >? >> On 03/19/2014 10:37 PM, Shree wrote: >? >? >> >? >? >>> Hello >? >? >>> I was able to successfully move all my clients to >? >? >? ? ? ? ? ? ? ? ? the replica except on the process I had to > upgrade the >? >? >? ? ? ? ? ? ? ? ? client to "ipa-client-3.0.0-37.el6.x86_64" and some >? >? >? ? ? ? ? ? ? ? ? times run a --uninstall >? >? >>> >? >? >>> . Bit it works for the most part. Have been >? >? >? ? ? ? ? ? ? ? ? struggling with one last host with errors like below. >? >? >? ? ? ? ? ? ? ? ? I have tested the port connectivity using telnet and >? >? >? ? ? ? ? ? ? netcat commands but the install thinks these ports are >? >? >? ? ? ? ? ? ? ? ? blocked? >? >? >>> >? >? >>> >? >? >>> >? >? >>> >? >? >>> kerberos authentication failed >? >? >>> kinit: Cannot contact any KDC for realm >? >? >? ? ? ? ? ? ? ? ? 'MYDOMAIN.COM' while getting initial credentials >? >? >>> >? >? >>> Please make sure the following ports are opened >? >? >? ? ? ? ? ? ? ? ? in the firewall settings: >? >? >>>? TCP: 80, 88, 389 >? >? >>>? ? ? UDP: 88 (at least one of TCP/UDP ports 88 >? >? >? ? ? ? ? ? ? ? ? has to be open) >? >? >>> Also note that following ports are necessary for >? >? >? ? ? ? ? ? ? ? ? ipa-client working properly after enrollment: >? >? >>>? ? ? TCP: 464 >? >? >>>? ? ? UDP: 464, 123 (if NTP enabled) >? >? >>> Installation failed. Rolling back changes. >? >? >>> Disabling client Kerberos and LDAP configurations >? >? >>> Redundant SSSD configuration file >? >? > /etc/sssd/sssd.conf was moved to >? >? >? ? ? ? ? ? ? ? ? /etc/sssd/sssd.conf.deleted >? >? >>> Restoring client configuration files >? >? >>> Client uninstall complete. >? >? >>> [root at www > /]# > >? >? >>> >? >? >>> In the /var/log/ipaclient-install.log I also see >? >? >? ? ? ? ? ? ? ? ? things like below. I get Autodiscovery failures but I >? >? >? ? ? ? ? ? ? ? ? am manually entering things and they have been >? >? >? ? working. >? >? >>> >? >? >>> 2014-03-19T21:13:47Z DEBUG Found: >? >? >? ? ? ? ? ? ? ? ? cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com >? >? >>> 2014-03-19T21:13:47Z DEBUG Discovery result: >? >? >? ? ? ? ? ? ? ? ? Success; server=ldap2.mydomain.com, >? >? >? ? ? ? ? ? ? ? ? domain=mydomain.com, kdc=ldap.mydomain.com, >? >? >? ? ? ? ? ? ? ? ? basedn=dc=mydomain,dc=com >? >? >>> 2014-03-19T21:13:47Z DEBUG Validated servers: >? >? >? ldap2.mydomain.com >? >? >>> 2014-03-19T21:13:47Z WARNING The failure to use >? >? >? ? ? ? ? ? ? DNS to find your IPA server indicates that your >? >? >? ? ? ? ? ? ? ? ? resolv.conf file is not properly configured. >? >? >>> 2014-03-19T21:13:47Z INFO Autodiscovery of >? >? >? ? ? ? ? ? ? ? ? servers for failover cannot work with this >? >? >? ? ? ? ? ? ? ? ? configuration. >? >? >>> 2014-03-19T21:13:47Z INFO 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. >? >? >> >? >? >> Ok. I would guess you have some DNS issue. But it is >? >? >? ? ? ? ? ? ? ? hard to tell without the >? >? >> entire ipaclient-install.log of the failed installation. >? >? >> >? >? >> Martin >? >? >> >? >? >> >? >? >> >? >? >> >? > > >? >? > >? > >? > >? > >? > >? > >? > _______________________________________________ >? > Freeipa-users mailing list >? > Freeipa-users at redhat.com >? > https://www.redhat.com/mailman/listinfo/freeipa-users >? > > > > _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Apr 9 06:41:06 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 9 Apr 2014 08:41:06 +0200 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1397002966.79747.YahooMailNeo@web160103.mail.bf1.yahoo.com> References: <532A9E07.6040604@redhat.com> <1395445491.29606.YahooMailNeo@web160105.mail.bf1.yahoo.com> <532DFCD0.8060907@redhat.com> <1395685201.97247.YahooMailNeo@web160104.mail.bf1.yahoo.com> <5331353C.9030603@redhat.com> <1396046096.70517.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5339756D.5080108@redhat.com> <1396278174.64201.YahooMailNeo@web160103.mail.bf1.yahoo.com> <1396278876.85775.YahooMailNeo@web160104.mail.bf1.yahoo.com> <1397002966.79747.YahooMailNeo@web160103.mail.bf1.yahoo.com> Message-ID: <20140409064106.GB10259@hendrix.brq.redhat.com> On Tue, Apr 08, 2014 at 05:22:46PM -0700, Shree wrote: > Not sure if anyone read my last reply I was still not having any luck. Anyways I found the file which was causing it to contact the old IP address just a few minutes ago. Though I would share with you in case someone else may need it. I started going through the directory listed in the krb5.conf file > > [ includedir /var/lib/sss/pubconf/krb5.include.d/ ] > > Just one level up there was a file called kdcinfo.MYDOMAIN.COM which had the old IP address. I changed it to the new one and kinit started working fine. I was able to install ipa-client without any issues. I still cannot figure out why only one of my several servers behaved this way. > > Thanks This file is generated by SSSD and tells the IP address of a KDC that the SSSD discovered to libkrb5. The reason is that you want applications that rely on Kerberos configuration only (for example kinit) to be able to use the KDCs SSSD uses without having to duplicate information in both sssd.conf and krb5.conf and also make sure that both sssd and libkrb5 really talk to the same server. The file is normally generated when SSSD goes online after startup and should be removed either when SSSD goes offline for one reason or another or when SSSD is shut down. If the file was around even if SSSD was not running, then I'd say it was a bug. But I admit I haven't read this whole thread, so I'm not 100% what was going on before. From mkosek at redhat.com Wed Apr 9 06:55:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Apr 2014 08:55:14 +0200 Subject: [Freeipa-users] freeIPA client sudo / sssd setup In-Reply-To: <20140408204254.GB23487@mail.corp.redhat.com> References: <20140408202457.GA23487@mail.corp.redhat.com> <20140408204254.GB23487@mail.corp.redhat.com> Message-ID: <5344EED2.3030901@redhat.com> On 04/08/2014 10:42 PM, Lukas Slebodnik wrote: > On (08/04/14 13:34), Nathan Broadbent wrote: >>> >>> man sssd-sudo says: >>> CONFIGURING SSSD TO FETCH SUDO RULES >>> All configuration that is needed on SSSD side is >>> to extend the list of services with "sudo" in [sssd] section of >>> sssd.conf(5). >>> >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> I would say it is documented, but nobody pointed you to manual pages. >>> >>> >> Ah, you are right, sorry I said it was undocumented. I think it's a good >> idea to enable sssd-sudo by default when we run ipa-client-install, or at >> least, add it as an option to the ipa-client-install script. As a new user, >> I also spent a while trying to figure out why my sudo rules weren't having >> any effect. > > Work in progress > https://fedorahosted.org/freeipa/ticket/3358 > > You can add yourself to CC if you are intrested in this ticket. > > LS Right. From FreeIPA 4.0, after you install an IPA server/client, you get sudo support from the very beginning, no additional configuration needed. All bells and whistles will be included. Martin From pspacek at redhat.com Wed Apr 9 07:29:06 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 09 Apr 2014 09:29:06 +0200 Subject: [Freeipa-users] Partial Domain Authority In-Reply-To: <1396994818.19767.4.camel@willson.li.ssimo.org> References: <1396994818.19767.4.camel@willson.li.ssimo.org> Message-ID: <5344F6C2.2050206@redhat.com> On 9.4.2014 00:06, Simo Sorce wrote: > On Tue, 2014-04-08 at 16:42 -0500, Justin Brown wrote: >> I'm sure that I'm doing this very wrong, but I'm wondering if anyone >> can offer any solutions. >> >> I currently have a relatively small domain that's used internally. >> Let's say fandingo.org. This domain covers various class C networks on >> 192.168.0.0/16. Currently, there's an Active Directory server that >> provides internal (and forwarding) DNS for fandingo.org. I'm in the >> experimentation phase with FreeIPA in this environment and don't want >> to modify anything outside of FreeIPA for the time being. >> >> FreeIPA is setup with DNS and has the fandingo.org domain controllers >> setup as forwarders. I have my laptop joined to the FreeIPA domain, >> but that's where the problem starts. I can correctly resolve any >> *.fandingo.org resource in FreeIPA. The problem is that I want to >> resolve *.fandingo.org resources that are defined in the Active >> Directory DNS. >> >> Does anyone know how I can configure FreeIPA/BIND to forward all >> requests (even those for its own domain) that it can't satisfy rather >> than returning NXDOMAIN? > > Is FreeIPA shadowing an AD domain ? > Ie are the Ad domain and FreeIPA domain using the same domain name ? > > That would be bad. > If you want to manage fadnigo.org in AD it would be a better idea to > create a ipa.fandingo.org domain for IPA. Then set forwarders *both* way > (or just delegate the domain from AD), to IPA, so all clients regardless > of what DNS server are using can resolve both *fandingo.org hosts (via > AD DNS) and *.ipa.fandingo.org hosts (via FreeIPa DNS). Let me add that name collisions/domain shadowing cannot be handled by standard means. The name resolution algorithm for authoritative server is standardized here: http://tools.ietf.org/html/rfc6672#section-3.2 See the end of step 3-C: If the "*" label does not exist, check whether the name we are looking for is the original QNAME in the query or a name we have followed due to a CNAME or DNAME. If the name is original, set an authoritative name error in the response and exit. Simo's proposal is the best thing you can do and it requires minimal changes on AD side (i.e. adding 2*(number of IPA servers) of DNS records to AD). Please see http://www.freeipa.org/page/Deployment_Recommendations . Have a nice day! -- Petr^2 Spacek From barrykfl at gmail.com Wed Apr 9 09:12:07 2014 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Wed, 9 Apr 2014 17:12:07 +0800 Subject: [Freeipa-users] err907 pn web interface Message-ID: Dear all: my server name is server1.def.abc.com and i ve applied a wild card cert successfully *.abc.com . A error pormpt out after as shown, Any idea ? can ipa accept wild card *.abc.com cert or must be server1.def.abc.comcertifcate. if i use a *.abc.net ...will it same effect? Does this error have serious side effect onthe ldap? thks -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: error907.jpg Type: image/jpeg Size: 88318 bytes Desc: not available URL: From ovalousek at vendavo.com Wed Apr 9 13:05:47 2014 From: ovalousek at vendavo.com (Ondrej Valousek) Date: Wed, 9 Apr 2014 13:05:47 +0000 Subject: [Freeipa-users] SAML 2.0 support Message-ID: <1B2E2C093FF3B7459F3C605C42E4B5040DFE63D5@exmb1> Hi List, Quick question, is something like SAML 2.0 support planned for IPA to help establishing SSO for a web based applications? I mean something similar to ADFS. Thanks, Ondrej -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Apr 9 13:15:41 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 09 Apr 2014 09:15:41 -0400 Subject: [Freeipa-users] SAML 2.0 support In-Reply-To: <1B2E2C093FF3B7459F3C605C42E4B5040DFE63D5@exmb1> References: <1B2E2C093FF3B7459F3C605C42E4B5040DFE63D5@exmb1> Message-ID: <1397049341.19767.26.camel@willson.li.ssimo.org> On Wed, 2014-04-09 at 13:05 +0000, Ondrej Valousek wrote: > Hi List, > Quick question, is something like SAML 2.0 support planned for IPA to help establishing SSO for a web based applications? I mean something similar to ADFS. I am working on a project called Ipsilon right now: https://git.fedorahosted.org/cgit/ipsilon.git/ This is an Identity Provider offering SAML 2.0 as the first deliverable (and in future other bridgin technologies like openid.oauth/etc..) This will integrate with IPA seamlessly and the aim is to make as simple to install and manage. Of course this is still in development, so it may take a little while to mature, but should be usable shortly. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Wed Apr 9 13:20:46 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 09 Apr 2014 15:20:46 +0200 Subject: [Freeipa-users] SAML 2.0 support In-Reply-To: <1397049341.19767.26.camel@willson.li.ssimo.org> References: <1B2E2C093FF3B7459F3C605C42E4B5040DFE63D5@exmb1> <1397049341.19767.26.camel@willson.li.ssimo.org> Message-ID: <5345492E.1080001@redhat.com> On 9.4.2014 15:15, Simo Sorce wrote: > On Wed, 2014-04-09 at 13:05 +0000, Ondrej Valousek wrote: >> Hi List, >> Quick question, is something like SAML 2.0 support planned for IPA to help establishing SSO for a web based applications? I mean something similar to ADFS. > > I am working on a project called Ipsilon right now: > https://git.fedorahosted.org/cgit/ipsilon.git/ > > This is an Identity Provider offering SAML 2.0 as the first deliverable > (and in future other bridgin technologies like openid.oauth/etc..) > > This will integrate with IPA seamlessly and the aim is to make as simple > to install and manage. > > Of course this is still in development, so it may take a little while to > mature, but should be usable shortly. This reminds me that OpenID Connect was standardized. An Python library is available from http://openid.net/developers/libraries/ -- Petr^2 Spacek From simo at redhat.com Wed Apr 9 13:54:29 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 09 Apr 2014 09:54:29 -0400 Subject: [Freeipa-users] SAML 2.0 support In-Reply-To: <5345492E.1080001@redhat.com> References: <1B2E2C093FF3B7459F3C605C42E4B5040DFE63D5@exmb1> <1397049341.19767.26.camel@willson.li.ssimo.org> <5345492E.1080001@redhat.com> Message-ID: <1397051669.19767.27.camel@willson.li.ssimo.org> On Wed, 2014-04-09 at 15:20 +0200, Petr Spacek wrote: > On 9.4.2014 15:15, Simo Sorce wrote: > > On Wed, 2014-04-09 at 13:05 +0000, Ondrej Valousek wrote: > >> Hi List, > >> Quick question, is something like SAML 2.0 support planned for IPA to help establishing SSO for a web based applications? I mean something similar to ADFS. > > > > I am working on a project called Ipsilon right now: > > https://git.fedorahosted.org/cgit/ipsilon.git/ > > > > This is an Identity Provider offering SAML 2.0 as the first deliverable > > (and in future other bridgin technologies like openid.oauth/etc..) > > > > This will integrate with IPA seamlessly and the aim is to make as simple > > to install and manage. > > > > Of course this is still in development, so it may take a little while to > > mature, but should be usable shortly. > > This reminds me that OpenID Connect was standardized. > > An Python library is available from > http://openid.net/developers/libraries/ openID connect is firmly in my crosshairs, no worries :) Simo. -- Simo Sorce * Red Hat, Inc * New York From atomlin at engineer.com Wed Apr 9 15:58:13 2014 From: atomlin at engineer.com (Andy Tomlin) Date: Wed, 9 Apr 2014 08:58:13 -0700 Subject: [Freeipa-users] DDNS with DHCPD and IPA In-Reply-To: <003101cf5069$2832f4d0$7898de70$@engineer.com> References: <006c01cf4f66$d8ad5390$8a07fab0$@engineer.com> <1396564152.4265.20.camel@strawberry.ad.adelaide.edu.au> <008701cf4f97$6f7e06e0$4e7a14a0$@engineer.com> <533F4401.6060202@redhat.com> <003101cf5069$2832f4d0$7898de70$@engineer.com> Message-ID: Ok, I added a howto page On Fri, Apr 4, 2014 at 5:51 PM, Andy Tomlin wrote: > Remove foot from mouth... sure. > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal > Sent: Friday, April 4, 2014 4:45 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] DDNS with DHCPD and IPA > > On 04/03/2014 07:50 PM, Andy Tomlin wrote: > > Awesome, adding the grant line with my key (DDNS_UPDATE) did the > > trick. This makes it perform exactly like old config. > > > > Thanks for the help. Someone should put this example in the docs. > > Would you mind writing a HowTo on our wiki? > > > > > -----Original Message----- > > From: freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of William Brown > > Sent: Thursday, April 3, 2014 3:29 PM > > To: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] DDNS with DHCPD and IPA > > > > On Thu, 2014-04-03 at 11:02 -0700, Andy Tomlin wrote: > >> That would be my preference, would then work same as bind/dhcpd > >> before switching to ipa. I just dont know how to do it correctly. > >> > >> > > This assumes dhcp and named are on the same system. > > > > For an unrelated project I wrote some docs here: > > > > http://tollgate.readthedocs.org/en/3.0.1/fedora-deploy.html#core-netwo > > rk > > > > And the example config files referenced are: > > > > https://github.com/micolous/tollgate/tree/master/docs/example/fedora > > > > The important parts are: > > > > rndc-confgen -a -r keyboard -b 256 > > chown named:named /etc/rndc.key > > > > In named.conf add after the options section: > > > > include "/etc/rndc.key"; > > > > In the zone (In ipa you will need to add this permission) > > > > grant rndc-key wildcard * ANY; > > > > Then in dhcpd: > > > > > > include "/etc/rndc.key"; > > > > And to the dhcpd range: > > > > > > zone dhcp.example.lan. { > > primary 127.0.0.1; > > key "rndc-key"; > > } > > > > > > zone 0.4.10.in-addr.arpa. { > > primary 127.0.0.1; > > key "rndc-key"; > > } > > > > > > This should coexist peacefully with freeipa, but try to make sure your > > DDNS updated zone is say dhcp.example.com rather than a zone you care > about. > > Consider you have a domain controller called x.example.com, and you > > allow DDNS to example.com. If someone set their hostname to x, they > > could take over the DNS records for your DC. Better to have a second > > zone to prevent this. > > > > -- > > William Brown > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Apr 9 17:06:19 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 09 Apr 2014 19:06:19 +0200 Subject: [Freeipa-users] Announcing bind-dyndb-ldap version 4.3 Message-ID: <53457E0B.1080401@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 4.3. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/ The new version has also been built for Fedora 20 and and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-4.3-1.fc20 == Changes in 4.3 and 4.2 == [1] LDAP update processing was fixed to prevent BIND from crashing during shutdown. [2] Record parsing was fixed to prevent child-zone data corruption in cases where parent zone example.com was hosted on the same server as child zone sub.example.com. (This bug was introduced in version 4.0.) == Upgrading == A server can be upgraded by installing updated RPM. BIND has to be restarted manually after the RPM installation. *Make sure that BIND can write to working directory as described in README* before you restart BIND. You will need to clean up configuration file /etc/named.conf if your configuration contains typos or other unsupported options. Downgrading back to any 3.x version is supported as long as record types not supported by old version are not utilized. == Feedback == Please provide comments, report bugs and send any other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr Spacek @ Red Hat From dpal at redhat.com Wed Apr 9 18:04:42 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 09 Apr 2014 14:04:42 -0400 Subject: [Freeipa-users] err907 pn web interface In-Reply-To: References: Message-ID: <53458BBA.5010603@redhat.com> On 04/09/2014 05:12 AM, barrykfl at gmail.com wrote: > Dear all: > my server name is server1.def.abc.com and > i ve applied a wild card cert successfully *.abc.com . What did you do to apply it? What versions of IPA do you run? Do you see anything in the HTTPD logs? > A error pormpt out after as shown, Any idea ? > can ipa accept wild card *.abc.com cert or must be > server1.def.abc.com certifcate. > if i use a *.abc.net ...will it same effect? > Does this error have serious side effect onthe ldap? No. This erro usually shows if something is wrong with SSL connection to the CA. Dropping the cert might have affected the trust chain. > thks > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Apr 9 18:04:57 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 09 Apr 2014 14:04:57 -0400 Subject: [Freeipa-users] err907 pn web interface In-Reply-To: References: Message-ID: <53458BC9.1070508@redhat.com> On 04/09/2014 05:12 AM, barrykfl at gmail.com wrote: > Dear all: > my server name is server1.def.abc.com and > i ve applied a wild card cert successfully *.abc.com . What did you do to apply it? What versions of IPA do you run? Do you see anything in the HTTPD logs? > A error pormpt out after as shown, Any idea ? > can ipa accept wild card *.abc.com cert or must be > server1.def.abc.com certifcate. > if i use a *.abc.net ...will it same effect? > Does this error have serious side effect onthe ldap? No. This error usually shows if something is wrong with SSL connection to the CA. Dropping the cert might have affected the trust chain. > thks > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Apr 9 18:20:01 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 09 Apr 2014 14:20:01 -0400 Subject: [Freeipa-users] DDNS with DHCPD and IPA In-Reply-To: References: <006c01cf4f66$d8ad5390$8a07fab0$@engineer.com> <1396564152.4265.20.camel@strawberry.ad.adelaide.edu.au> <008701cf4f97$6f7e06e0$4e7a14a0$@engineer.com> <533F4401.6060202@redhat.com> <003101cf5069$2832f4d0$7898de70$@engineer.com> Message-ID: <53458F51.7030001@redhat.com> On 04/09/2014 11:58 AM, Andy Tomlin wrote: > Ok, I added a howto page Thanks Martin, should be link it from HowTo page? > > > On Fri, Apr 4, 2014 at 5:51 PM, Andy Tomlin > wrote: > > Remove foot from mouth... sure. > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com > ] On Behalf Of Dmitri Pal > Sent: Friday, April 4, 2014 4:45 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] DDNS with DHCPD and IPA > > On 04/03/2014 07:50 PM, Andy Tomlin wrote: > > Awesome, adding the grant line with my key (DDNS_UPDATE) did the > > trick. This makes it perform exactly like old config. > > > > Thanks for the help. Someone should put this example in the docs. > > Would you mind writing a HowTo on our wiki? > > > > > -----Original Message----- > > From: freeipa-users-bounces at redhat.com > > > [mailto:freeipa-users-bounces at redhat.com > ] On Behalf Of William Brown > > Sent: Thursday, April 3, 2014 3:29 PM > > To: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] DDNS with DHCPD and IPA > > > > On Thu, 2014-04-03 at 11:02 -0700, Andy Tomlin wrote: > >> That would be my preference, would then work same as bind/dhcpd > >> before switching to ipa. I just dont know how to do it correctly. > >> > >> > > This assumes dhcp and named are on the same system. > > > > For an unrelated project I wrote some docs here: > > > > > http://tollgate.readthedocs.org/en/3.0.1/fedora-deploy.html#core-netwo > > rk > > > > And the example config files referenced are: > > > > https://github.com/micolous/tollgate/tree/master/docs/example/fedora > > > > The important parts are: > > > > rndc-confgen -a -r keyboard -b 256 > > chown named:named /etc/rndc.key > > > > In named.conf add after the options section: > > > > include "/etc/rndc.key"; > > > > In the zone (In ipa you will need to add this permission) > > > > grant rndc-key wildcard * ANY; > > > > Then in dhcpd: > > > > > > include "/etc/rndc.key"; > > > > And to the dhcpd range: > > > > > > zone dhcp.example.lan. { > > primary 127.0.0.1; > > key "rndc-key"; > > } > > > > > > zone 0.4.10.in-addr.arpa. { > > primary 127.0.0.1; > > key "rndc-key"; > > } > > > > > > This should coexist peacefully with freeipa, but try to make > sure your > > DDNS updated zone is say dhcp.example.com > rather than a zone you care > about. > > Consider you have a domain controller called x.example.com > , and you > > allow DDNS to example.com . If someone set > their hostname to x, they > > could take over the DNS records for your DC. Better to have a second > > zone to prevent this. > > > > -- > > William Brown > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From quest.monger at gmail.com Wed Apr 9 20:07:06 2014 From: quest.monger at gmail.com (quest monger) Date: Wed, 9 Apr 2014 16:07:06 -0400 Subject: [Freeipa-users] IPA client installation for Solaris 11. Message-ID: I have read through the official documentation here for Solaris-10 - http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html I have found a few web posts on how to make it work for Solaris-11. Have any of you tried adding a Solaris-11 host to an existing IPA server? If so, do you have any documentation/how-tos/instructions that i could use to do the same. Any help is appreciated. I am trying to do this to so I can centralize SSH authentication for all my Solaris-11 and Linux hosts. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Apr 9 20:36:24 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 09 Apr 2014 16:36:24 -0400 Subject: [Freeipa-users] IPA client installation for Solaris 11. In-Reply-To: References: Message-ID: <5345AF48.3030501@redhat.com> quest monger wrote: > > I have read through the official documentation here for Solaris-10 - > http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html > I have found a few web posts on how to make it work for Solaris-11. > Have any of you tried adding a Solaris-11 host to an existing IPA > server? If so, do you have any documentation/how-tos/instructions that i > could use to do the same. Any help is appreciated. > I am trying to do this to so I can centralize SSH authentication for all > my Solaris-11 and Linux hosts. That is pretty much all we've got. There is a bug open with some documentation updates, https://bugzilla.redhat.com/show_bug.cgi?id=815533 and some more in https://bugzilla.redhat.com/show_bug.cgi?id=801883 We use sssd to help with centralized SSH auth so it probably won't work as smoothly on Solaris as it does on sssd-based Linux systems. See sss_ssh_authorizedkeys(1) and sss_ssh_knownhostsproxy(8). This document describes how it works in IPA http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf rob From arthur at deus.pro Thu Apr 10 04:50:15 2014 From: arthur at deus.pro (Arthur Fayzullin) Date: Thu, 10 Apr 2014 10:50:15 +0600 Subject: [Freeipa-users] DDNS with DHCPD and IPA In-Reply-To: <53458F51.7030001@redhat.com> References: <006c01cf4f66$d8ad5390$8a07fab0$@engineer.com> <1396564152.4265.20.camel@strawberry.ad.adelaide.edu.au> <008701cf4f97$6f7e06e0$4e7a14a0$@engineer.com> <533F4401.6060202@redhat.com> <003101cf5069$2832f4d0$7898de70$@engineer.com> <53458F51.7030001@redhat.com> Message-ID: <53462307.1050203@deus.pro> If this http://www.freeipa.org/page/Howto/ISC_DHCPd_and_Dynamic_DNS_update is it, then it is quite not easy to understand what is it about. here, in mail-list it was much more understandable. 10.04.2014 00:20, Dmitri Pal ?????: > On 04/09/2014 11:58 AM, Andy Tomlin wrote: >> Ok, I added a howto page > > Thanks > Martin, should be link it from HowTo page? >> >> >> On Fri, Apr 4, 2014 at 5:51 PM, Andy Tomlin > > wrote: >> >> Remove foot from mouth... sure. >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> >> [mailto:freeipa-users-bounces at redhat.com >> ] On Behalf Of Dmitri Pal >> Sent: Friday, April 4, 2014 4:45 PM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] DDNS with DHCPD and IPA >> >> On 04/03/2014 07:50 PM, Andy Tomlin wrote: >> > Awesome, adding the grant line with my key (DDNS_UPDATE) did the >> > trick. This makes it perform exactly like old config. >> > >> > Thanks for the help. Someone should put this example in the docs. >> >> Would you mind writing a HowTo on our wiki? >> >> > >> > -----Original Message----- >> > From: freeipa-users-bounces at redhat.com >> >> > [mailto:freeipa-users-bounces at redhat.com >> ] On Behalf Of William Brown >> > Sent: Thursday, April 3, 2014 3:29 PM >> > To: freeipa-users at redhat.com >> > Subject: Re: [Freeipa-users] DDNS with DHCPD and IPA >> > >> > On Thu, 2014-04-03 at 11:02 -0700, Andy Tomlin wrote: >> >> That would be my preference, would then work same as bind/dhcpd >> >> before switching to ipa. I just dont know how to do it correctly. >> >> >> >> >> > This assumes dhcp and named are on the same system. >> > >> > For an unrelated project I wrote some docs here: >> > >> > >> http://tollgate.readthedocs.org/en/3.0.1/fedora-deploy.html#core-netwo >> > rk >> > >> > And the example config files referenced are: >> > >> > >> https://github.com/micolous/tollgate/tree/master/docs/example/fedora >> > >> > The important parts are: >> > >> > rndc-confgen -a -r keyboard -b 256 >> > chown named:named /etc/rndc.key >> > >> > In named.conf add after the options section: >> > >> > include "/etc/rndc.key"; >> > >> > In the zone (In ipa you will need to add this permission) >> > >> > grant rndc-key wildcard * ANY; >> > >> > Then in dhcpd: >> > >> > >> > include "/etc/rndc.key"; >> > >> > And to the dhcpd range: >> > >> > >> > zone dhcp.example.lan. { >> > primary 127.0.0.1; >> > key "rndc-key"; >> > } >> > >> > >> > zone 0.4.10.in-addr.arpa. { >> > primary 127.0.0.1; >> > key "rndc-key"; >> > } >> > >> > >> > This should coexist peacefully with freeipa, but try to make >> sure your >> > DDNS updated zone is say dhcp.example.com >> rather than a zone you care >> about. >> > Consider you have a domain controller called x.example.com >> , and you >> > allow DDNS to example.com . If someone set >> their hostname to x, they >> > could take over the DNS records for your DC. Better to have a >> second >> > zone to prevent this. >> > >> > -- >> > William Brown > > >> > >> > _______________________________________________ >> > Freeipa-users mailing list >> > Freeipa-users at redhat.com >> > https://www.redhat.com/mailman/listinfo/freeipa-users >> > >> > _______________________________________________ >> > Freeipa-users mailing list >> > Freeipa-users at redhat.com >> > https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rashard.Kelly at sita.aero Thu Apr 10 06:31:05 2014 From: Rashard.Kelly at sita.aero (Rashard.Kelly at sita.aero) Date: Thu, 10 Apr 2014 02:31:05 -0400 Subject: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials Message-ID: Hello all When I try to execute and commands from the an ipa-replica I get [rkelly at replicahostname ~]$ ipa user-find ipa: ERROR: did not receive Kerberos credentials [rkelly at replicahostname ~]$ kinit Password for rkelly at IPA2.DC.SITA.AERO: [rkelly at replicahostname ~]$ ipa user-find ipa: ERROR: did not receive Kerberos credentials [rkelly at replicahostname ~]$ klist klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_1599100000_qojy7v) I thought perhaps the two are out of sync [root at replicahostname ~]# ipa-replica-manage re-initialize --from liipaxs010p.ipa2.dc.sita.aero Invalid password ipa-replica-conncheck says communication is ok. I looked at the httpd, secure,and krb log and none show any activity when I execute the commands above. Im lost any clues as to where I can look for answers? Thank You, Rashard Kelly This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. See you at 2014 Air Transport IT Summit, 17-19 June 2014 Click here to register http://www.sitasummit.aero -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Apr 10 07:05:40 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 10 Apr 2014 09:05:40 +0200 Subject: [Freeipa-users] DDNS with DHCPD and IPA In-Reply-To: <53462307.1050203@deus.pro> References: <006c01cf4f66$d8ad5390$8a07fab0$@engineer.com> <1396564152.4265.20.camel@strawberry.ad.adelaide.edu.au> <008701cf4f97$6f7e06e0$4e7a14a0$@engineer.com> <533F4401.6060202@redhat.com> <003101cf5069$2832f4d0$7898de70$@engineer.com> <53458F51.7030001@redhat.com> <53462307.1050203@deus.pro> Message-ID: <534642C4.9090401@redhat.com> On 04/10/2014 06:50 AM, Arthur Fayzullin wrote: > If this > http://www.freeipa.org/page/Howto/ISC_DHCPd_and_Dynamic_DNS_update is it, > then it is quite not easy to understand what is it about. > here, in mail-list it was much more understandable. The HOWTOs provided in http://www.freeipa.org/page/HowTos are mostly FreeIPA community provided pages. FreeIPA developers cannot have direct experience with integration with all 3rd party projects which is why we welcome help from community with documenting the integration procedures. If you think the HOWTO is not clear enough, please feel free update it and make it more clear and thus help others too. > 10.04.2014 00:20, Dmitri Pal ?????: >> On 04/09/2014 11:58 AM, Andy Tomlin wrote: >>> Ok, I added a howto page >> >> Thanks >> Martin, should be link it from HowTo page? It was linked. I just updated the page and added better formatting and interlinks. Martin From mkosek at redhat.com Thu Apr 10 07:10:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 10 Apr 2014 09:10:35 +0200 Subject: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials In-Reply-To: References: Message-ID: <534643EB.6010701@redhat.com> On 04/10/2014 08:31 AM, Rashard.Kelly at sita.aero wrote: > Hello all > > > When I try to execute and commands from the an ipa-replica I get > > [rkelly at replicahostname ~]$ ipa user-find > ipa: ERROR: did not receive Kerberos credentials > [rkelly at replicahostname ~]$ kinit > Password for rkelly at IPA2.DC.SITA.AERO: ... > [rkelly at replicahostname ~]$ klist > klist: Credentials cache permissions incorrect while setting cache flags > (ticket cache FILE:/tmp/krb5cc_1599100000_qojy7v) What are the file permissions on /tmp/krb5cc_1599100000_qojy7v ? I assume that it was made readable to everyone which made Kerberos libraries refused using the CCACHE. Martin From abokovoy at redhat.com Thu Apr 10 07:25:46 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 10 Apr 2014 10:25:46 +0300 Subject: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials In-Reply-To: References: Message-ID: <20140410072546.GU20958@redhat.com> On Thu, 10 Apr 2014, Rashard.Kelly at sita.aero wrote: >Hello all > > >When I try to execute and commands from the an ipa-replica I get > >[rkelly at replicahostname ~]$ ipa user-find >ipa: ERROR: did not receive Kerberos credentials >[rkelly at replicahostname ~]$ kinit >Password for rkelly at IPA2.DC.SITA.AERO: >[rkelly at replicahostname ~]$ ipa user-find >ipa: ERROR: did not receive Kerberos credentials >[rkelly at replicahostname ~]$ klist >klist: Credentials cache permissions incorrect while setting cache flags >(ticket cache FILE:/tmp/krb5cc_1599100000_qojy7v) > >I thought perhaps the two are out of sync >[root at replicahostname ~]# ipa-replica-manage re-initialize --from >liipaxs010p.ipa2.dc.sita.aero >Invalid password > > >ipa-replica-conncheck says communication is ok. > >I looked at the httpd, secure,and krb log and none show any activity when >I execute the commands above. Im lost any clues as to where I can look for >answers? Let's put IPA commands aside and first find out what's wrong with your Kerberos infra. Looking at your ticket cache file name (FILE:/tmp/krb5cc_1599100000_qojy7v) I assume you have come to this machine via SSH and the ticket cache is created by the sshd or sssd. The message you received out of klist is shown if ccache file is either: - unaccessible for the user - is a directory rather than a file - is a broken symlink - blocked by some app with explusive locks - cannot be open for a write Please provide output of $ cat /proc/mounts | grep /tmp $ echo $KRB5CCNAME $ ls -lZ /tmp/krb5cc_1599100000_qojy7v $ KRB5_TRACE=/dev/stderr kinit $ KRB5_TRACE=/dev/stderr klist You can temporarily overcome this issue by selecting a different ticket cache by setting KRB5CCNAME environmental variable: $ export KRB5CCNAME=$HOME/.krb5cc $ kinit $ ipa user-find ... However, it would be good to solve the issue to avoid repeating these problems -- / Alexander Bokovoy From matthew.symonds at switchconcepts.com Thu Apr 10 12:03:13 2014 From: matthew.symonds at switchconcepts.com (Matthew Symonds) Date: Thu, 10 Apr 2014 13:03:13 +0100 Subject: [Freeipa-users] LDAP Authentication with expired passwords Message-ID: We have a few services using IPA via LDAP. E.G. Apache connecting to ldap:///cn=users,cn=accounts,dc=ipa,dc=?uid This works fine but users with expired passwords are still able to authenticate. Is there any way to stop this in FreeIPA, or do I have to check krbPasswordExpiration in my user filter? Thanks Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rashard.Kelly at sita.aero Thu Apr 10 12:37:25 2014 From: Rashard.Kelly at sita.aero (Rashard.Kelly at sita.aero) Date: Thu, 10 Apr 2014 08:37:25 -0400 Subject: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials In-Reply-To: <20140410072546.GU20958@redhat.com> References: <20140410072546.GU20958@redhat.com> Message-ID: The krb5 files are not readable by everyone. There are multiple krb5 files in tmp, should they automatically be readable by all? BTW our users do not have home directories if that makes a difference. [rkelly at replicahostname ~]$ ls -lZ /tmp |grep krb -rw------- root root ? krb5cc_0 -rw------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd -rw------- rkelly rkelly ? krb5cc_1599100000_oKtZFE -rw------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 -rw------- apache apache ? krb5cc_48 ipa-server-selinux-3.0.0-37.el6.x86_64 ipa-client-3.0.0-37.el6.x86_64 ipa-server-3.0.0-37.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 ipa-python-3.0.0-37.el6.x86_64 ipa-admintools-3.0.0-37.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.x86_64 python-iniparse-0.3.1-2.1.el6.noarch [rkelly at replicahostname ~]$ cat /proc/mounts | grep /tmp /dev/mapper/system-tmp_vol /tmp ext4 rw,relatime,barrier=1,data=ordered 0 0 [rkelly at replicahostname ~]$ echo $KRB5CCNAME FILE:/tmp/krb5cc_1599100000_oKtZFE [rkelly at replicahostname ~]$ ls -lZ /tmp/krb5cc_1599100000_oKtZFE -rw------- rkelly rkelly ? /tmp/krb5cc_1599100000_oKtZFE [rkelly at replicahostname ~]$ KRB5_TRACE=/dev/stderr kinit [14559] 1397132474.221287: Getting initial credentials for rkelly at DOMAIN [14559] 1397132474.221510: Sending request (191 bytes) to DOMAIN [14559] 1397132474.221677: Sending initial UDP request to dgram 10.228.20.25:88 [14559] 1397132474.225248: Received answer from dgram 10.228.20.25:88 [14559] 1397132474.225287: Response was from master KDC [14559] 1397132474.225306: Received error from KDC: -1765328359/Additional pre-authentication required [14559] 1397132474.225331: Processing preauth types: 136, 19, 2, 133 [14559] 1397132474.225343: Selected etype info: etype aes256-cts, salt "IPA2.DC.SITA.AEROrkelly", params "" [14559] 1397132474.225346: Received cookie: MIT Password for rkelly at DOMAIN: [14559] 1397132484.255381: AS key obtained for encrypted timestamp: aes256-cts/DBF7 [14559] 1397132484.255432: Encrypted timestamp (for 1397132484.255390): plain 301AA011180F32303134303431303132323132345AA105020303E59E, encrypted 321A6A1E297880D1E2D1BF069D6D44136D7A2A0D3AAFC3209CB9B4E5BAAE59E928559E47FD0A140F68D377A8398D7CAB4B735D0612247A7C [14559] 1397132484.255453: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success [14559] 1397132484.255457: Produced preauth for next request: 133, 2 [14559] 1397132484.255474: Sending request (286 bytes) to DOMAIN (master) [14559] 1397132484.255560: Sending initial UDP request to dgram 10.228.20.25:88 [14559] 1397132484.262563: Received answer from dgram 10.228.20.25:88 [14559] 1397132484.262593: Processing preauth types: 19 [14559] 1397132484.262600: Selected etype info: etype aes256-cts, salt "DOMAINrkelly", params "" [14559] 1397132484.262603: Produced preauth for next request: (empty) [14559] 1397132484.262609: AS key determined by preauth: aes256-cts/DBF7 [14559] 1397132484.262650: Decrypted AS reply; session key is: aes256-cts/B097 [14559] 1397132484.262664: FAST negotiation: available [14559] 1397132484.262681: Initializing FILE:/tmp/krb5cc_1599100000_oKtZFE with default princ rkelly at DOMAIN [rkelly at replicahostname ~]$ KRB5_TRACE=/dev/stderr klist klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_1599100000_oKtZFE) -- Thank You, Rashard Kelly From: Alexander Bokovoy To: Rashard.Kelly at sita.aero Cc: freeipa-users at redhat.com Date: 04/10/2014 03:25 AM Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials On Thu, 10 Apr 2014, Rashard.Kelly at sita.aero wrote: >Hello all > > >When I try to execute and commands from the an ipa-replica I get > >[rkelly at replicahostname ~]$ ipa user-find >ipa: ERROR: did not receive Kerberos credentials >[rkelly at replicahostname ~]$ kinit >Password for rkelly at IPA2.DC.SITA.AERO: >[rkelly at replicahostname ~]$ ipa user-find >ipa: ERROR: did not receive Kerberos credentials >[rkelly at replicahostname ~]$ klist >klist: Credentials cache permissions incorrect while setting cache flags >(ticket cache FILE:/tmp/krb5cc_1599100000_qojy7v) > >I thought perhaps the two are out of sync >[root at replicahostname ~]# ipa-replica-manage re-initialize --from >liipaxs010p.ipa2.dc.sita.aero >Invalid password > > >ipa-replica-conncheck says communication is ok. > >I looked at the httpd, secure,and krb log and none show any activity when >I execute the commands above. Im lost any clues as to where I can look for >answers? Let's put IPA commands aside and first find out what's wrong with your Kerberos infra. Looking at your ticket cache file name (FILE:/tmp/krb5cc_1599100000_qojy7v) I assume you have come to this machine via SSH and the ticket cache is created by the sshd or sssd. The message you received out of klist is shown if ccache file is either: - unaccessible for the user - is a directory rather than a file - is a broken symlink - blocked by some app with explusive locks - cannot be open for a write Please provide output of $ cat /proc/mounts | grep /tmp $ echo $KRB5CCNAME $ ls -lZ /tmp/krb5cc_1599100000_qojy7v $ KRB5_TRACE=/dev/stderr kinit $ KRB5_TRACE=/dev/stderr klist You can temporarily overcome this issue by selecting a different ticket cache by setting KRB5CCNAME environmental variable: $ export KRB5CCNAME=$HOME/.krb5cc $ kinit $ ipa user-find ... However, it would be good to solve the issue to avoid repeating these problems -- / Alexander Bokovoy This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. See you at 2014 Air Transport IT Summit, 17-19 June 2014 Click here to register http://www.sitasummit.aero -------------- next part -------------- An HTML attachment was scrubbed... URL: From quest.monger at gmail.com Thu Apr 10 15:41:27 2014 From: quest.monger at gmail.com (quest monger) Date: Thu, 10 Apr 2014 11:41:27 -0400 Subject: [Freeipa-users] IPA client installation for Solaris 11. In-Reply-To: <5345AF48.3030501@redhat.com> References: <5345AF48.3030501@redhat.com> Message-ID: Thanks Rob, those bug reports help. One more question, in the official Solaris 10 documentation, i see this stuff - -a proxyPassword={NS1}*fbc123a92116812* userPassword:: *e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ*= Is there a way to generate that password hash for a new password. I think that should be part of the documentation, dont want all Solaris IPA users to be using the same password and corresponding hash. Thanks. On Wed, Apr 9, 2014 at 4:36 PM, Rob Crittenden wrote: > quest monger wrote: > >> >> I have read through the official documentation here for Solaris-10 - >> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_ >> Guide/Configuring_an_IPA_Client_on_Solaris.html >> I have found a few web posts on how to make it work for Solaris-11. >> Have any of you tried adding a Solaris-11 host to an existing IPA >> server? If so, do you have any documentation/how-tos/instructions that i >> could use to do the same. Any help is appreciated. >> I am trying to do this to so I can centralize SSH authentication for all >> my Solaris-11 and Linux hosts. >> > > That is pretty much all we've got. There is a bug open with some > documentation updates, https://bugzilla.redhat.com/show_bug.cgi?id=815533and some more in > https://bugzilla.redhat.com/show_bug.cgi?id=801883 > > We use sssd to help with centralized SSH auth so it probably won't work as > smoothly on Solaris as it does on sssd-based Linux systems. See > sss_ssh_authorizedkeys(1) and sss_ssh_knownhostsproxy(8). > > This document describes how it works in IPA > http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rashard.Kelly at sita.aero Thu Apr 10 15:55:05 2014 From: Rashard.Kelly at sita.aero (Rashard.Kelly at sita.aero) Date: Thu, 10 Apr 2014 11:55:05 -0400 Subject: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials In-Reply-To: References: <20140410072546.GU20958@redhat.com> Message-ID: I can run commands after changing the permissions on the files, but why is it generating files that are not world readable? [rkelly at replicahostname ~]$ ll total 84 -rw-r--r-- 1 root root 2428 Apr 9 22:34 krb5cc_0 -rw-r--r-- 1 xs05144 xs05144 1146 Apr 3 16:10 krb5cc_1599000020_u5RRhd -rw-r--r-- 1 rkelly rkelly 569 Apr 10 15:14 krb5cc_1599100000_CUkupo -rw-r--r-- 1 rkelly rkelly 1873 Apr 9 23:40 krb5cc_1599100000_ZekyY0 -rw-r--r-- 1 apache apache 662 Apr 10 06:02 krb5cc_48 [rkelly at replicahostname ~]$ klist Ticket cache: FILE:/tmp/krb5cc_1599100000_CUkupo Default principal: rkelly at DOMAIN Valid starting Expires Service principal 04/10/14 15:14:40 04/11/14 15:14:40 krbtgt/IPA2.DC.SITA.AERO at DOMAIN [rkelly at replicahostname ~]$ ipa user-find kelly -------------- 1 user matched -------------- User login: rkelly First name: Rashard Last name: KElly Home directory: /home/rkelly Login shell: /bin/sh Email address: rkelly at domain UID: 1599100000 GID: 1599100000 Account disabled: False Password: True Kerberos keys available: True ---------------------------- Number of entries returned 1 ---------------------------- Thank You, Rashard Kelly From: Rashard.Kelly at sita.aero To: Alexander Bokovoy Cc: freeipa-users at redhat.com Date: 04/10/2014 08:42 AM Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials Sent by: freeipa-users-bounces at redhat.com The krb5 files are not readable by everyone. There are multiple krb5 files in tmp, should they automatically be readable by all? BTW our users do not have home directories if that makes a difference. [rkelly at replicahostname ~]$ ls -lZ /tmp |grep krb -rw------- root root ? krb5cc_0 -rw------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd -rw------- rkelly rkelly ? krb5cc_1599100000_oKtZFE -rw------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 -rw------- apache apache ? krb5cc_48 ipa-server-selinux-3.0.0-37.el6.x86_64 ipa-client-3.0.0-37.el6.x86_64 ipa-server-3.0.0-37.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 ipa-python-3.0.0-37.el6.x86_64 ipa-admintools-3.0.0-37.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.x86_64 python-iniparse-0.3.1-2.1.el6.noarch [rkelly at replicahostname ~]$ cat /proc/mounts | grep /tmp /dev/mapper/system-tmp_vol /tmp ext4 rw,relatime,barrier=1,data=ordered 0 0 [rkelly at replicahostname ~]$ echo $KRB5CCNAME FILE:/tmp/krb5cc_1599100000_oKtZFE [rkelly at replicahostname ~]$ ls -lZ /tmp/krb5cc_1599100000_oKtZFE -rw------- rkelly rkelly ? /tmp/krb5cc_1599100000_oKtZFE [rkelly at replicahostname ~]$ KRB5_TRACE=/dev/stderr kinit [14559] 1397132474.221287: Getting initial credentials for rkelly at DOMAIN [14559] 1397132474.221510: Sending request (191 bytes) to DOMAIN [14559] 1397132474.221677: Sending initial UDP request to dgram 10.228.20.25:88 [14559] 1397132474.225248: Received answer from dgram 10.228.20.25:88 [14559] 1397132474.225287: Response was from master KDC [14559] 1397132474.225306: Received error from KDC: -1765328359/Additional pre-authentication required [14559] 1397132474.225331: Processing preauth types: 136, 19, 2, 133 [14559] 1397132474.225343: Selected etype info: etype aes256-cts, salt "IPA2.DC.SITA.AEROrkelly", params "" [14559] 1397132474.225346: Received cookie: MIT Password for rkelly at DOMAIN: [14559] 1397132484.255381: AS key obtained for encrypted timestamp: aes256-cts/DBF7 [14559] 1397132484.255432: Encrypted timestamp (for 1397132484.255390): plain 301AA011180F32303134303431303132323132345AA105020303E59E, encrypted 321A6A1E297880D1E2D1BF069D6D44136D7A2A0D3AAFC3209CB9B4E5BAAE59E928559E47FD0A140F68D377A8398D7CAB4B735D0612247A7C [14559] 1397132484.255453: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success [14559] 1397132484.255457: Produced preauth for next request: 133, 2 [14559] 1397132484.255474: Sending request (286 bytes) to DOMAIN (master) [14559] 1397132484.255560: Sending initial UDP request to dgram 10.228.20.25:88 [14559] 1397132484.262563: Received answer from dgram 10.228.20.25:88 [14559] 1397132484.262593: Processing preauth types: 19 [14559] 1397132484.262600: Selected etype info: etype aes256-cts, salt "DOMAINrkelly", params "" [14559] 1397132484.262603: Produced preauth for next request: (empty) [14559] 1397132484.262609: AS key determined by preauth: aes256-cts/DBF7 [14559] 1397132484.262650: Decrypted AS reply; session key is: aes256-cts/B097 [14559] 1397132484.262664: FAST negotiation: available [14559] 1397132484.262681: Initializing FILE:/tmp/krb5cc_1599100000_oKtZFE with default princ rkelly at DOMAIN [rkelly at replicahostname ~]$ KRB5_TRACE=/dev/stderr klist klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_1599100000_oKtZFE) -- Thank You, Rashard Kelly From: Alexander Bokovoy To: Rashard.Kelly at sita.aero Cc: freeipa-users at redhat.com Date: 04/10/2014 03:25 AM Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials On Thu, 10 Apr 2014, Rashard.Kelly at sita.aero wrote: >Hello all > > >When I try to execute and commands from the an ipa-replica I get > >[rkelly at replicahostname ~]$ ipa user-find >ipa: ERROR: did not receive Kerberos credentials >[rkelly at replicahostname ~]$ kinit >Password for rkelly at IPA2.DC.SITA.AERO: >[rkelly at replicahostname ~]$ ipa user-find >ipa: ERROR: did not receive Kerberos credentials >[rkelly at replicahostname ~]$ klist >klist: Credentials cache permissions incorrect while setting cache flags >(ticket cache FILE:/tmp/krb5cc_1599100000_qojy7v) > >I thought perhaps the two are out of sync >[root at replicahostname ~]# ipa-replica-manage re-initialize --from >liipaxs010p.ipa2.dc.sita.aero >Invalid password > > >ipa-replica-conncheck says communication is ok. > >I looked at the httpd, secure,and krb log and none show any activity when >I execute the commands above. Im lost any clues as to where I can look for >answers? Let's put IPA commands aside and first find out what's wrong with your Kerberos infra. Looking at your ticket cache file name (FILE:/tmp/krb5cc_1599100000_qojy7v) I assume you have come to this machine via SSH and the ticket cache is created by the sshd or sssd. The message you received out of klist is shown if ccache file is either: - unaccessible for the user - is a directory rather than a file - is a broken symlink - blocked by some app with explusive locks - cannot be open for a write Please provide output of $ cat /proc/mounts | grep /tmp $ echo $KRB5CCNAME $ ls -lZ /tmp/krb5cc_1599100000_qojy7v $ KRB5_TRACE=/dev/stderr kinit $ KRB5_TRACE=/dev/stderr klist You can temporarily overcome this issue by selecting a different ticket cache by setting KRB5CCNAME environmental variable: $ export KRB5CCNAME=$HOME/.krb5cc $ kinit $ ipa user-find ... However, it would be good to solve the issue to avoid repeating these problems -- / Alexander Bokovoy This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. See you at 2014 Air Transport IT Summit, 17-19 June 2014 Click here to register http://www.sitasummit.aero _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. See you at 2014 Air Transport IT Summit, 17-19 June 2014 Click here to register http://www.sitasummit.aero -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Apr 10 16:07:20 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 10 Apr 2014 12:07:20 -0400 Subject: [Freeipa-users] LDAP Authentication with expired passwords In-Reply-To: References: Message-ID: <5346C1B8.8040301@redhat.com> On 04/10/2014 08:03 AM, Matthew Symonds wrote: > We have a few services using IPA via LDAP. > > E.G. Apache connecting > to ldap:///cn=users,cn=accounts,dc=ipa,dc=?uid > > This works fine but users with expired passwords are still able to > authenticate. > > Is there any way to stop this in FreeIPA, or do I have to > check krbPasswordExpiration in my user filter? There is no way to stop it. You can read about the reasons in the ticket and mentioned threads. https://fedorahosted.org/freeipa/ticket/1539#comment:13 Using it in the access control filter would be a reasonable workaround. > > Thanks > Matt > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Apr 10 16:09:31 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 10 Apr 2014 12:09:31 -0400 Subject: [Freeipa-users] IPA client installation for Solaris 11. In-Reply-To: References: <5345AF48.3030501@redhat.com> Message-ID: <5346C23B.8080503@redhat.com> On 04/10/2014 11:41 AM, quest monger wrote: > Thanks Rob, those bug reports help. > One more question, in the official Solaris 10 documentation, i see > this stuff - > > -aproxyPassword={NS1}*fbc123a92116812* > userPassword::*e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ*= > > Is there a way to generate that password hash for a new password. I > think that should be part of the documentation, dont want all Solaris > IPA users to be using the same password and corresponding hash. > Can you rephrase the question? It is unclear what hash you are asking about. If you are using IPA you do not need local password hashes. > Thanks. > > > > > On Wed, Apr 9, 2014 at 4:36 PM, Rob Crittenden > wrote: > > quest monger wrote: > > > I have read through the official documentation here for > Solaris-10 - > http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html > I have found a few web posts on how to make it work for > Solaris-11. > Have any of you tried adding a Solaris-11 host to an existing IPA > server? If so, do you have any > documentation/how-tos/instructions that i > could use to do the same. Any help is appreciated. > I am trying to do this to so I can centralize SSH > authentication for all > my Solaris-11 and Linux hosts. > > > That is pretty much all we've got. There is a bug open with some > documentation updates, > https://bugzilla.redhat.com/show_bug.cgi?id=815533 and some more > in https://bugzilla.redhat.com/show_bug.cgi?id=801883 > > We use sssd to help with centralized SSH auth so it probably won't > work as smoothly on Solaris as it does on sssd-based Linux > systems. See sss_ssh_authorizedkeys(1) and sss_ssh_knownhostsproxy(8). > > This document describes how it works in IPA > http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf > > rob > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Apr 10 16:10:15 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 10 Apr 2014 18:10:15 +0200 Subject: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials In-Reply-To: References: <20140410072546.GU20958@redhat.com> Message-ID: <20140410161015.GH27972@localhost.localdomain> On Thu, Apr 10, 2014 at 11:55:05AM -0400, Rashard.Kelly at sita.aero wrote: > I can run commands after changing the permissions on the files, but why is > it generating files that are not world readable? > > [rkelly at replicahostname ~]$ ll > total 84 > -rw-r--r-- 1 root root 2428 Apr 9 22:34 krb5cc_0 > -rw-r--r-- 1 xs05144 xs05144 1146 Apr 3 16:10 krb5cc_1599000020_u5RRhd > -rw-r--r-- 1 rkelly rkelly 569 Apr 10 15:14 krb5cc_1599100000_CUkupo > -rw-r--r-- 1 rkelly rkelly 1873 Apr 9 23:40 krb5cc_1599100000_ZekyY0 > -rw-r--r-- 1 apache apache 662 Apr 10 06:02 krb5cc_48 Please don't do this, the credential cache files are similar to your password, only the user itself should be allowed to read it. When you use ls with the -Z option there is a '?' where the SELinux context should be printed. Maybe there are issues with your SELinux setup which prevent access to the ccache files? Can you try SELinux in permissive mode? If there are still issues running klist which strace might give some more details why the ccache file cannot be read. HTH bye, Sumit > > [rkelly at replicahostname ~]$ klist > Ticket cache: FILE:/tmp/krb5cc_1599100000_CUkupo > Default principal: rkelly at DOMAIN > > Valid starting Expires Service principal > 04/10/14 15:14:40 04/11/14 15:14:40 krbtgt/IPA2.DC.SITA.AERO at DOMAIN > > [rkelly at replicahostname ~]$ ipa user-find kelly > -------------- > 1 user matched > -------------- > User login: rkelly > First name: Rashard > Last name: KElly > Home directory: /home/rkelly > Login shell: /bin/sh > Email address: rkelly at domain > UID: 1599100000 > GID: 1599100000 > Account disabled: False > Password: True > Kerberos keys available: True > ---------------------------- > Number of entries returned 1 > ---------------------------- > Thank You, > Rashard Kelly > > > > From: Rashard.Kelly at sita.aero > To: Alexander Bokovoy > Cc: freeipa-users at redhat.com > Date: 04/10/2014 08:42 AM > Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos > credentials > Sent by: freeipa-users-bounces at redhat.com > > > > The krb5 files are not readable by everyone. There are multiple krb5 files > in tmp, should they automatically be readable by all? BTW our users do not > have home directories if that makes a difference. > > [rkelly at replicahostname ~]$ ls -lZ /tmp |grep krb > -rw------- root root ? krb5cc_0 > -rw------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd > -rw------- rkelly rkelly ? krb5cc_1599100000_oKtZFE > -rw------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 > -rw------- apache apache ? krb5cc_48 > > ipa-server-selinux-3.0.0-37.el6.x86_64 > ipa-client-3.0.0-37.el6.x86_64 > ipa-server-3.0.0-37.el6.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 > ipa-python-3.0.0-37.el6.x86_64 > ipa-admintools-3.0.0-37.el6.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > libipa_hbac-1.9.2-129.el6_5.4.x86_64 > python-iniparse-0.3.1-2.1.el6.noarch > > [rkelly at replicahostname ~]$ cat /proc/mounts | grep /tmp > /dev/mapper/system-tmp_vol /tmp ext4 rw,relatime,barrier=1,data=ordered 0 > 0 > [rkelly at replicahostname ~]$ echo $KRB5CCNAME > FILE:/tmp/krb5cc_1599100000_oKtZFE > > [rkelly at replicahostname ~]$ ls -lZ /tmp/krb5cc_1599100000_oKtZFE > -rw------- rkelly rkelly ? /tmp/krb5cc_1599100000_oKtZFE > > [rkelly at replicahostname ~]$ KRB5_TRACE=/dev/stderr kinit > [14559] 1397132474.221287: Getting initial credentials for rkelly at DOMAIN > [14559] 1397132474.221510: Sending request (191 bytes) to DOMAIN > [14559] 1397132474.221677: Sending initial UDP request to dgram > 10.228.20.25:88 > [14559] 1397132474.225248: Received answer from dgram 10.228.20.25:88 > [14559] 1397132474.225287: Response was from master KDC > [14559] 1397132474.225306: Received error from KDC: -1765328359/Additional > pre-authentication required > [14559] 1397132474.225331: Processing preauth types: 136, 19, 2, 133 > [14559] 1397132474.225343: Selected etype info: etype aes256-cts, salt > "IPA2.DC.SITA.AEROrkelly", params "" > [14559] 1397132474.225346: Received cookie: MIT > Password for rkelly at DOMAIN: > [14559] 1397132484.255381: AS key obtained for encrypted timestamp: > aes256-cts/DBF7 > [14559] 1397132484.255432: Encrypted timestamp (for 1397132484.255390): > plain 301AA011180F32303134303431303132323132345AA105020303E59E, encrypted > 321A6A1E297880D1E2D1BF069D6D44136D7A2A0D3AAFC3209CB9B4E5BAAE59E928559E47FD0A140F68D377A8398D7CAB4B735D0612247A7C > > [14559] 1397132484.255453: Preauth module encrypted_timestamp (2) > (flags=1) returned: 0/Success > [14559] 1397132484.255457: Produced preauth for next request: 133, 2 > [14559] 1397132484.255474: Sending request (286 bytes) to DOMAIN (master) > [14559] 1397132484.255560: Sending initial UDP request to dgram > 10.228.20.25:88 > [14559] 1397132484.262563: Received answer from dgram 10.228.20.25:88 > [14559] 1397132484.262593: Processing preauth types: 19 > [14559] 1397132484.262600: Selected etype info: etype aes256-cts, salt > "DOMAINrkelly", params "" > [14559] 1397132484.262603: Produced preauth for next request: (empty) > [14559] 1397132484.262609: AS key determined by preauth: aes256-cts/DBF7 > [14559] 1397132484.262650: Decrypted AS reply; session key is: > aes256-cts/B097 > [14559] 1397132484.262664: FAST negotiation: available > [14559] 1397132484.262681: Initializing FILE:/tmp/krb5cc_1599100000_oKtZFE > with default princ rkelly at DOMAIN > > [rkelly at replicahostname ~]$ KRB5_TRACE=/dev/stderr klist > klist: Credentials cache permissions incorrect while setting cache flags > (ticket cache FILE:/tmp/krb5cc_1599100000_oKtZFE) > > -- > > > Thank You, > Rashard Kelly > > > > > From: Alexander Bokovoy > To: Rashard.Kelly at sita.aero > Cc: freeipa-users at redhat.com > Date: 04/10/2014 03:25 AM > Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos > credentials > > > > On Thu, 10 Apr 2014, Rashard.Kelly at sita.aero wrote: > >Hello all > > > > > >When I try to execute and commands from the an ipa-replica I get > > > >[rkelly at replicahostname ~]$ ipa user-find > >ipa: ERROR: did not receive Kerberos credentials > >[rkelly at replicahostname ~]$ kinit > >Password for rkelly at IPA2.DC.SITA.AERO: > >[rkelly at replicahostname ~]$ ipa user-find > >ipa: ERROR: did not receive Kerberos credentials > >[rkelly at replicahostname ~]$ klist > >klist: Credentials cache permissions incorrect while setting cache flags > >(ticket cache FILE:/tmp/krb5cc_1599100000_qojy7v) > > > >I thought perhaps the two are out of sync > >[root at replicahostname ~]# ipa-replica-manage re-initialize --from > >liipaxs010p.ipa2.dc.sita.aero > >Invalid password > > > > > >ipa-replica-conncheck says communication is ok. > > > >I looked at the httpd, secure,and krb log and none show any activity when > >I execute the commands above. Im lost any clues as to where I can look > for > >answers? > Let's put IPA commands aside and first find out what's wrong with your > Kerberos infra. Looking at your ticket cache file name > (FILE:/tmp/krb5cc_1599100000_qojy7v) I assume you have come to this > machine via SSH and the ticket cache is created by the sshd or sssd. > > The message you received out of klist is shown if ccache file is either: > - unaccessible for the user > - is a directory rather than a file > - is a broken symlink > - blocked by some app with explusive locks > - cannot be open for a write > > Please provide output of > $ cat /proc/mounts | grep /tmp > $ echo $KRB5CCNAME > $ ls -lZ /tmp/krb5cc_1599100000_qojy7v > $ KRB5_TRACE=/dev/stderr kinit > $ KRB5_TRACE=/dev/stderr klist > > You can temporarily overcome this issue by selecting a different ticket > cache by setting KRB5CCNAME environmental variable: > > $ export KRB5CCNAME=$HOME/.krb5cc > $ kinit > $ ipa user-find > ... > > However, it would be good to solve the issue to avoid repeating these > problems > > > > -- > / Alexander Bokovoy > > > This document is strictly confidential and intended only for use by the > addressee unless otherwise stated. If you are not the intended recipient, > please notify the sender immediately and delete it from your system. See > you at 2014 Air Transport IT Summit, 17-19 June 2014 Click here to > register http://www.sitasummit.aero > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > This document is strictly confidential and intended only for use by the > addressee unless otherwise stated. If you are not the intended recipient, > please notify the sender immediately and delete it from your system. > See you at 2014 Air Transport IT Summit, 17-19 June 2014 > > Click here to register http://www.sitasummit.aero > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From quest.monger at gmail.com Thu Apr 10 16:18:47 2014 From: quest.monger at gmail.com (quest monger) Date: Thu, 10 Apr 2014 12:18:47 -0400 Subject: [Freeipa-users] IPA client installation for Solaris 11. In-Reply-To: <5346C23B.8080503@redhat.com> References: <5345AF48.3030501@redhat.com> <5346C23B.8080503@redhat.com> Message-ID: Sorry about that. So I am Looking at the Solaris 10 client documentation here - http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html It says do the following on Solaris client - ldapclient manual ... -a proxyPassword={NS1}fbc123a92116812 ... Whats that proxyPassword for? Thanks. On Thu, Apr 10, 2014 at 12:09 PM, Dmitri Pal wrote: > On 04/10/2014 11:41 AM, quest monger wrote: > > Thanks Rob, those bug reports help. > One more question, in the official Solaris 10 documentation, i see this > stuff - > > -a proxyPassword={NS1}*fbc123a92116812* > > userPassword:: *e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ*= > > > Is there a way to generate that password hash for a new password. I > think that should be part of the documentation, dont want all Solaris IPA > users to be using the same password and corresponding hash. > > Can you rephrase the question? > It is unclear what hash you are asking about. > If you are using IPA you do not need local password hashes. > > > Thanks. > > > > > On Wed, Apr 9, 2014 at 4:36 PM, Rob Crittenden wrote: > >> quest monger wrote: >> >>> >>> I have read through the official documentation here for Solaris-10 - >>> >>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html >>> I have found a few web posts on how to make it work for Solaris-11. >>> Have any of you tried adding a Solaris-11 host to an existing IPA >>> server? If so, do you have any documentation/how-tos/instructions that i >>> could use to do the same. Any help is appreciated. >>> I am trying to do this to so I can centralize SSH authentication for all >>> my Solaris-11 and Linux hosts. >>> >> >> That is pretty much all we've got. There is a bug open with some >> documentation updates, https://bugzilla.redhat.com/show_bug.cgi?id=815533and some more in >> https://bugzilla.redhat.com/show_bug.cgi?id=801883 >> >> We use sssd to help with centralized SSH auth so it probably won't work >> as smoothly on Solaris as it does on sssd-based Linux systems. See >> sss_ssh_authorizedkeys(1) and sss_ssh_knownhostsproxy(8). >> >> This document describes how it works in IPA >> http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf >> >> rob >> > > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bclark at tendrilinc.com Thu Apr 10 16:24:17 2014 From: bclark at tendrilinc.com (Brent Clark) Date: Thu, 10 Apr 2014 10:24:17 -0600 Subject: [Freeipa-users] Using puppet to add servers to IPA Message-ID: Hello, I'm looking to use puppet to add my servers to IPA automatically. This would be used when building VMs from templates and their first puppet run would add them into IPA. I am wondering if anyone has any success with doing this? Any thing I should consider... any gotchas. Thanks! -- Brent S. Clark NOC Engineer 2580 55th St. | Boulder, Colorado 80301 www.tendrilinc.com | blog This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Apr 10 16:30:32 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 10 Apr 2014 12:30:32 -0400 Subject: [Freeipa-users] IPA client installation for Solaris 11. In-Reply-To: References: <5345AF48.3030501@redhat.com> <5346C23B.8080503@redhat.com> Message-ID: <5346C728.1040001@redhat.com> On 04/10/2014 12:18 PM, quest monger wrote: > Sorry about that. So I am Looking at the Solaris 10 client > documentation here - > http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html > > > It says do the following on Solaris client - > > ldapclient manual > ... > -a proxyPassword={NS1}fbc123a92116812 > ... > > > Whats that proxyPassword for? > I suspect that it is a password that corresponds to the proxy user. The client component on Solaris (pure speculation on my side) seems to use proxy user to connect to LDAP server and do some operations for the host. It is similar to SSSD but SSSD does not use passwords, it uses keytabs if talks to IPA. Solaris uses passwords but to prevent them from being stored in configuration in clear the are "obfuscated" with the NS1 method http://stuff.iain.cx/2008/05/03/ns103eb2365be169abbe3a45088a10a/ I suspect there should be some tool on Solaris that takes password and creates an obfuscated string like this. Thanks Dmitri > Thanks. > > > > On Thu, Apr 10, 2014 at 12:09 PM, Dmitri Pal > wrote: > > On 04/10/2014 11:41 AM, quest monger wrote: >> Thanks Rob, those bug reports help. >> One more question, in the official Solaris 10 documentation, i >> see this stuff - >> >> -aproxyPassword={NS1}*fbc123a92116812* >> userPassword::*e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ*= >> >> Is there a way to generate that password hash for a new password. >> I think that should be part of the documentation, dont want all >> Solaris IPA users to be using the same password and corresponding >> hash. >> > Can you rephrase the question? > It is unclear what hash you are asking about. > If you are using IPA you do not need local password hashes. > > >> Thanks. >> >> >> >> >> On Wed, Apr 9, 2014 at 4:36 PM, Rob Crittenden >> > wrote: >> >> quest monger wrote: >> >> >> I have read through the official documentation here for >> Solaris-10 - >> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html >> I have found a few web posts on how to make it work for >> Solaris-11. >> Have any of you tried adding a Solaris-11 host to an >> existing IPA >> server? If so, do you have any >> documentation/how-tos/instructions that i >> could use to do the same. Any help is appreciated. >> I am trying to do this to so I can centralize SSH >> authentication for all >> my Solaris-11 and Linux hosts. >> >> >> That is pretty much all we've got. There is a bug open with >> some documentation updates, >> https://bugzilla.redhat.com/show_bug.cgi?id=815533 and some >> more in https://bugzilla.redhat.com/show_bug.cgi?id=801883 >> >> We use sssd to help with centralized SSH auth so it probably >> won't work as smoothly on Solaris as it does on sssd-based >> Linux systems. See sss_ssh_authorizedkeys(1) and >> sss_ssh_knownhostsproxy(8). >> >> This document describes how it works in IPA >> http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf >> >> rob >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stbenjam at redhat.com Thu Apr 10 16:33:59 2014 From: stbenjam at redhat.com (Stephen Benjamin) Date: Thu, 10 Apr 2014 12:33:59 -0400 (EDT) Subject: [Freeipa-users] Using puppet to add servers to IPA In-Reply-To: References: Message-ID: <1701852125.4230674.1397147639579.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Brent Clark" > To: freeipa-users at redhat.com > Sent: Thursday, April 10, 2014 6:24:17 PM > Subject: [Freeipa-users] Using puppet to add servers to IPA > > Hello, > > I'm looking to use puppet to add my servers to IPA automatically. This > would be used when building VMs from templates and their first puppet run > would add them into IPA. I have a puppet module that does this: http://github.com/stbenjam/puppet-ipaclient Harvard IT also has one that seems to have a lot more features (including things like replicas): https://github.com/huit/puppet-ipa > > I am wondering if anyone has any success with doing this? Any thing I > should consider... any gotchas. > > Thanks! > > -- > Brent S. Clark > NOC Engineer > > 2580 55th St. | Boulder, Colorado 80301 > www.tendrilinc.com | blog > > > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the sender. > Please note that any views or opinions presented in this email are solely > those of the author and do not necessarily represent those of the company. > Finally, the recipient should check this email and any attachments for the > presence of viruses. > The company accepts no liability for any damage caused by any virus > transmitted by this email. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Thu Apr 10 16:34:15 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 10 Apr 2014 12:34:15 -0400 Subject: [Freeipa-users] Using puppet to add servers to IPA In-Reply-To: References: Message-ID: <5346C807.2030208@redhat.com> On 04/10/2014 12:24 PM, Brent Clark wrote: > Hello, > > I'm looking to use puppet to add my servers to IPA automatically. This > would be used when building VMs from templates and their first puppet > run would add them into IPA. Google returns this http://forge.puppetlabs.com/tags/freeipa https://github.com/purpleidea/puppet-ipa > > I am wondering if anyone has any success with doing this? Any thing I > should consider... any gotchas. > > Thanks! > > -- > Brent S. Clark > NOC Engineer > > 2580 55th St. | Boulder, Colorado 80301 > www.tendrilinc.com | blog > > > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the sender. > Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. > Finally, the recipient should check this email and any attachments for the presence of viruses. > The company accepts no liability for any damage caused by any virus transmitted by this email. > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Apr 10 17:04:09 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Apr 2014 13:04:09 -0400 Subject: [Freeipa-users] IPA client installation for Solaris 11. In-Reply-To: <5346C728.1040001@redhat.com> References: <5345AF48.3030501@redhat.com> <5346C23B.8080503@redhat.com> <5346C728.1040001@redhat.com> Message-ID: <5346CF09.1060007@redhat.com> Dmitri Pal wrote: > On 04/10/2014 12:18 PM, quest monger wrote: >> Sorry about that. So I am Looking at the Solaris 10 client >> documentation here - >> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html >> >> >> It says do the following on Solaris client - >> >> ldapclient manual >> ... >> -a proxyPassword={NS1}fbc123a92116812 >> ... >> >> >> Whats that proxyPassword for? >> > > I suspect that it is a password that corresponds to the proxy user. > The client component on Solaris (pure speculation on my side) seems to > use proxy user to connect to LDAP server and do some operations for the > host. It is similar to SSSD but SSSD does not use passwords, it uses > keytabs if talks to IPA. There are a number of different profile levels available, see http://docs.oracle.com/cd/E23824_01/html/821-1455/ldapsecure-66.html#ldapsecure-74 proxy is usually a shared account that the Solaris box uses to authenticate to the LDAP server. > Solaris uses passwords but to prevent them from being stored in > configuration in clear the are "obfuscated" with the NS1 method > http://stuff.iain.cx/2008/05/03/ns103eb2365be169abbe3a45088a10a/ > I suspect there should be some tool on Solaris that takes password and > creates an obfuscated string like this. I didn't experiment using a proxy password inside a profile. I'll bet that if you manually enroll a client then you can dig out the password on that local system and store that in the profile. There is also a self level which uses Kerberos. I've never used it myself (it may be newer than my experience with Solaris) but there are some fairly detailed docs on it at http://docs.oracle.com/cd/E23824_01/html/821-1455/clientsetup-49.html#gdzpl rob > > Thanks > Dmitri > >> Thanks. >> >> >> >> On Thu, Apr 10, 2014 at 12:09 PM, Dmitri Pal > > wrote: >> >> On 04/10/2014 11:41 AM, quest monger wrote: >>> Thanks Rob, those bug reports help. >>> One more question, in the official Solaris 10 documentation, i >>> see this stuff - >>> >>> -aproxyPassword={NS1}*fbc123a92116812* >>> userPassword::*e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ*= >>> >>> Is there a way to generate that password hash for a new password. >>> I think that should be part of the documentation, dont want all >>> Solaris IPA users to be using the same password and corresponding >>> hash. >>> >> Can you rephrase the question? >> It is unclear what hash you are asking about. >> If you are using IPA you do not need local password hashes. >> >> >>> Thanks. >>> >>> >>> >>> >>> On Wed, Apr 9, 2014 at 4:36 PM, Rob Crittenden >>> > wrote: >>> >>> quest monger wrote: >>> >>> >>> I have read through the official documentation here for >>> Solaris-10 - >>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html >>> I have found a few web posts on how to make it work for >>> Solaris-11. >>> Have any of you tried adding a Solaris-11 host to an >>> existing IPA >>> server? If so, do you have any >>> documentation/how-tos/instructions that i >>> could use to do the same. Any help is appreciated. >>> I am trying to do this to so I can centralize SSH >>> authentication for all >>> my Solaris-11 and Linux hosts. >>> >>> >>> That is pretty much all we've got. There is a bug open with >>> some documentation updates, >>> https://bugzilla.redhat.com/show_bug.cgi?id=815533 and some >>> more in https://bugzilla.redhat.com/show_bug.cgi?id=801883 >>> >>> We use sssd to help with centralized SSH auth so it probably >>> won't work as smoothly on Solaris as it does on sssd-based >>> Linux systems. See sss_ssh_authorizedkeys(1) and >>> sss_ssh_knownhostsproxy(8). >>> >>> This document describes how it works in IPA >>> http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf >>> >>> rob >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From Johan.Petersson at sscspace.com Thu Apr 10 17:37:33 2014 From: Johan.Petersson at sscspace.com (Johan Petersson) Date: Thu, 10 Apr 2014 17:37:33 +0000 Subject: [Freeipa-users] IPA client installation for Solaris 11. In-Reply-To: <5346CF09.1060007@redhat.com> References: <5345AF48.3030501@redhat.com> <5346C23B.8080503@redhat.com> <5346C728.1040001@redhat.com>,<5346CF09.1060007@redhat.com> Message-ID: <558C15177F5E714F83334217C9A197DF01604ABCF2@SSC-MBX2.ssc.internal> Proxy user is only necessary if you disable anonymous bind on the IPA LDAP. Example configuration for making Solaris 11 work as an IPA client. If you want autofs of shared NFS home directory too, let me know and i can provide it. I will add this and more to IPA Wiki when i can find the time to go through it properly and polish away some rough edges. I hope it can provide some help. Solaris 11.1 IPA lient configuration. First make sure that the Solaris 11 machine are using the proper DNS and NTP servers. On the IPA server or Client run: ipa host-add --force --ip-address=192.168.0.1 solaris.example.com ipa-getkeytab -s ipaserver.example.com -p host/solaris.example.com -k /tmp/solaris.keytab Move the keytab to the Solaris machine /etc/krb5/krb5.keytab Make sure it have the proper owner and permissions: chown root:sys /etc/krb5/krb5.keytab chmod 700 /etc/krb5/krb5.keytab Edit /etc/nsswitch.ldap, replace "ldap" with "dns" from the "hosts" and "ipnodes" lines: hosts: files dns ipnodes: files dns Edit /etc/krb5/krb5.conf: [libdefaults] default_realm = EXAMPLE.COM verify_ap_req_nofail = false [realms] EXAMPLE.COM = { kdc = ipaserver.example.com admin_server = ipaserver.example.com } [domain_realm] example.com = EXAMPLE.COM .example.com = EXAMPLE.COM Run the ldapclient with the default DUAProfile. The "-a domainName= example.com" is needed so that ldapclient does not stop and complain about missing nisdomain name. ldapclient -v init -a profilename=default -a domainName=example.com ipaserver.example.com In Solaris 11.1 the pam configuration have changed but for simplicity i still use the /etc/pam.conf: login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_cred.so.1 login auth sufficient pam_krb5.so.1 login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1 other auth requisite pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 other auth required pam_unix_cred.so.1 other auth sufficient pam_krb5.so.1 other auth required pam_unix_auth.so.1 other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 other password requisite pam_authtok_check.so.1 force_check other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Rob Crittenden [rcritten at redhat.com] Sent: Thursday, April 10, 2014 19:04 To: dpal at redhat.com; quest monger Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] IPA client installation for Solaris 11. Dmitri Pal wrote: > On 04/10/2014 12:18 PM, quest monger wrote: >> Sorry about that. So I am Looking at the Solaris 10 client >> documentation here - >> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html >> >> >> It says do the following on Solaris client - >> >> ldapclient manual >> ... >> -a proxyPassword={NS1}fbc123a92116812 >> ... >> >> >> Whats that proxyPassword for? >> > > I suspect that it is a password that corresponds to the proxy user. > The client component on Solaris (pure speculation on my side) seems to > use proxy user to connect to LDAP server and do some operations for the > host. It is similar to SSSD but SSSD does not use passwords, it uses > keytabs if talks to IPA. There are a number of different profile levels available, see http://docs.oracle.com/cd/E23824_01/html/821-1455/ldapsecure-66.html#ldapsecure-74 proxy is usually a shared account that the Solaris box uses to authenticate to the LDAP server. > Solaris uses passwords but to prevent them from being stored in > configuration in clear the are "obfuscated" with the NS1 method > http://stuff.iain.cx/2008/05/03/ns103eb2365be169abbe3a45088a10a/ > I suspect there should be some tool on Solaris that takes password and > creates an obfuscated string like this. I didn't experiment using a proxy password inside a profile. I'll bet that if you manually enroll a client then you can dig out the password on that local system and store that in the profile. There is also a self level which uses Kerberos. I've never used it myself (it may be newer than my experience with Solaris) but there are some fairly detailed docs on it at http://docs.oracle.com/cd/E23824_01/html/821-1455/clientsetup-49.html#gdzpl rob > > Thanks > Dmitri > >> Thanks. >> >> >> >> On Thu, Apr 10, 2014 at 12:09 PM, Dmitri Pal > > wrote: >> >> On 04/10/2014 11:41 AM, quest monger wrote: >>> Thanks Rob, those bug reports help. >>> One more question, in the official Solaris 10 documentation, i >>> see this stuff - >>> >>> -aproxyPassword={NS1}*fbc123a92116812* >>> userPassword::*e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ*= >>> >>> Is there a way to generate that password hash for a new password. >>> I think that should be part of the documentation, dont want all >>> Solaris IPA users to be using the same password and corresponding >>> hash. >>> >> Can you rephrase the question? >> It is unclear what hash you are asking about. >> If you are using IPA you do not need local password hashes. >> >> >>> Thanks. >>> >>> >>> >>> >>> On Wed, Apr 9, 2014 at 4:36 PM, Rob Crittenden >>> > wrote: >>> >>> quest monger wrote: >>> >>> >>> I have read through the official documentation here for >>> Solaris-10 - >>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html >>> I have found a few web posts on how to make it work for >>> Solaris-11. >>> Have any of you tried adding a Solaris-11 host to an >>> existing IPA >>> server? If so, do you have any >>> documentation/how-tos/instructions that i >>> could use to do the same. Any help is appreciated. >>> I am trying to do this to so I can centralize SSH >>> authentication for all >>> my Solaris-11 and Linux hosts. >>> >>> >>> That is pretty much all we've got. There is a bug open with >>> some documentation updates, >>> https://bugzilla.redhat.com/show_bug.cgi?id=815533 and some >>> more in https://bugzilla.redhat.com/show_bug.cgi?id=801883 >>> >>> We use sssd to help with centralized SSH auth so it probably >>> won't work as smoothly on Solaris as it does on sssd-based >>> Linux systems. See sss_ssh_authorizedkeys(1) and >>> sss_ssh_knownhostsproxy(8). >>> >>> This document describes how it works in IPA >>> http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf >>> >>> rob >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users This e-mail is private and confidential between the sender and the addressee. In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above if any misdirection. From dpal at redhat.com Thu Apr 10 17:39:25 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 10 Apr 2014 13:39:25 -0400 Subject: [Freeipa-users] IPA client installation for Solaris 11. In-Reply-To: <558C15177F5E714F83334217C9A197DF01604ABCF2@SSC-MBX2.ssc.internal> References: <5345AF48.3030501@redhat.com> <5346C23B.8080503@redhat.com> <5346C728.1040001@redhat.com>, <5346CF09.1060007@redhat.com> <558C15177F5E714F83334217C9A197DF01604ABCF2@SSC-MBX2.ssc.internal> Message-ID: <5346D74D.4040003@redhat.com> On 04/10/2014 01:37 PM, Johan Petersson wrote: > Proxy user is only necessary if you disable anonymous bind on the IPA LDAP. > > Example configuration for making Solaris 11 work as an IPA client. > If you want autofs of shared NFS home directory too, let me know and i can provide it. > I will add this and more to IPA Wiki when i can find the time to go through it properly and polish away some rough edges. > I hope it can provide some help. > > Solaris 11.1 IPA lient configuration. > > First make sure that the Solaris 11 machine are using the proper DNS and NTP servers. > > On the IPA server or Client run: > > ipa host-add --force --ip-address=192.168.0.1 solaris.example.com > > ipa-getkeytab -s ipaserver.example.com -p host/solaris.example.com -k /tmp/solaris.keytab > > Move the keytab to the Solaris machine /etc/krb5/krb5.keytab > > Make sure it have the proper owner and permissions: > > chown root:sys /etc/krb5/krb5.keytab > chmod 700 /etc/krb5/krb5.keytab > > Edit /etc/nsswitch.ldap, replace "ldap" with "dns" from the "hosts" and "ipnodes" lines: > > hosts: files dns > ipnodes: files dns > > Edit /etc/krb5/krb5.conf: > > [libdefaults] > default_realm = EXAMPLE.COM > verify_ap_req_nofail = false > [realms] > EXAMPLE.COM = { > kdc = ipaserver.example.com > admin_server = ipaserver.example.com > } > > [domain_realm] > example.com = EXAMPLE.COM > .example.com = EXAMPLE.COM > > > Run the ldapclient with the default DUAProfile. > The "-a domainName= example.com" is needed so that ldapclient does not stop and complain about missing nisdomain name. > > ldapclient -v init -a profilename=default -a domainName=example.com ipaserver.example.com > > In Solaris 11.1 the pam configuration have changed but for simplicity i still use the /etc/pam.conf: > > login auth requisite pam_authtok_get.so.1 > login auth required pam_dhkeys.so.1 > login auth required pam_unix_cred.so.1 > login auth sufficient pam_krb5.so.1 > login auth required pam_unix_auth.so.1 > login auth required pam_dial_auth.so.1 > > other auth requisite pam_authtok_get.so.1 > other auth required pam_dhkeys.so.1 > other auth required pam_unix_cred.so.1 > other auth sufficient pam_krb5.so.1 > other auth required pam_unix_auth.so.1 > > other account requisite pam_roles.so.1 > other account required pam_unix_account.so.1 > other account required pam_krb5.so.1 > > other password requisite pam_authtok_check.so.1 force_check > other password sufficient pam_krb5.so.1 > other password required pam_authtok_store.so.1 I smell a HowTo wiki page... > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Rob Crittenden [rcritten at redhat.com] > Sent: Thursday, April 10, 2014 19:04 > To: dpal at redhat.com; quest monger > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] IPA client installation for Solaris 11. > > Dmitri Pal wrote: >> On 04/10/2014 12:18 PM, quest monger wrote: >>> Sorry about that. So I am Looking at the Solaris 10 client >>> documentation here - >>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html >>> >>> >>> It says do the following on Solaris client - >>> >>> ldapclient manual >>> ... >>> -a proxyPassword={NS1}fbc123a92116812 >>> ... >>> >>> >>> Whats that proxyPassword for? >>> >> I suspect that it is a password that corresponds to the proxy user. >> The client component on Solaris (pure speculation on my side) seems to >> use proxy user to connect to LDAP server and do some operations for the >> host. It is similar to SSSD but SSSD does not use passwords, it uses >> keytabs if talks to IPA. > There are a number of different profile levels available, see > http://docs.oracle.com/cd/E23824_01/html/821-1455/ldapsecure-66.html#ldapsecure-74 > > proxy is usually a shared account that the Solaris box uses to > authenticate to the LDAP server. > >> Solaris uses passwords but to prevent them from being stored in >> configuration in clear the are "obfuscated" with the NS1 method >> http://stuff.iain.cx/2008/05/03/ns103eb2365be169abbe3a45088a10a/ >> I suspect there should be some tool on Solaris that takes password and >> creates an obfuscated string like this. > I didn't experiment using a proxy password inside a profile. I'll bet > that if you manually enroll a client then you can dig out the password > on that local system and store that in the profile. > > There is also a self level which uses Kerberos. I've never used it > myself (it may be newer than my experience with Solaris) but there are > some fairly detailed docs on it at > http://docs.oracle.com/cd/E23824_01/html/821-1455/clientsetup-49.html#gdzpl > > rob >> Thanks >> Dmitri >> >>> Thanks. >>> >>> >>> >>> On Thu, Apr 10, 2014 at 12:09 PM, Dmitri Pal >> > wrote: >>> >>> On 04/10/2014 11:41 AM, quest monger wrote: >>>> Thanks Rob, those bug reports help. >>>> One more question, in the official Solaris 10 documentation, i >>>> see this stuff - >>>> >>>> -aproxyPassword={NS1}*fbc123a92116812* >>>> userPassword::*e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ*= >>>> >>>> Is there a way to generate that password hash for a new password. >>>> I think that should be part of the documentation, dont want all >>>> Solaris IPA users to be using the same password and corresponding >>>> hash. >>>> >>> Can you rephrase the question? >>> It is unclear what hash you are asking about. >>> If you are using IPA you do not need local password hashes. >>> >>> >>>> Thanks. >>>> >>>> >>>> >>>> >>>> On Wed, Apr 9, 2014 at 4:36 PM, Rob Crittenden >>>> > wrote: >>>> >>>> quest monger wrote: >>>> >>>> >>>> I have read through the official documentation here for >>>> Solaris-10 - >>>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html >>>> I have found a few web posts on how to make it work for >>>> Solaris-11. >>>> Have any of you tried adding a Solaris-11 host to an >>>> existing IPA >>>> server? If so, do you have any >>>> documentation/how-tos/instructions that i >>>> could use to do the same. Any help is appreciated. >>>> I am trying to do this to so I can centralize SSH >>>> authentication for all >>>> my Solaris-11 and Linux hosts. >>>> >>>> >>>> That is pretty much all we've got. There is a bug open with >>>> some documentation updates, >>>> https://bugzilla.redhat.com/show_bug.cgi?id=815533 and some >>>> more in https://bugzilla.redhat.com/show_bug.cgi?id=801883 >>>> >>>> We use sssd to help with centralized SSH auth so it probably >>>> won't work as smoothly on Solaris as it does on sssd-based >>>> Linux systems. See sss_ssh_authorizedkeys(1) and >>>> sss_ssh_knownhostsproxy(8). >>>> >>>> This document describes how it works in IPA >>>> http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf >>>> >>>> rob >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > This e-mail is private and confidential between the sender and the addressee. > In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above if any misdirection. > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From Rashard.Kelly at sita.aero Thu Apr 10 18:32:06 2014 From: Rashard.Kelly at sita.aero (Rashard.Kelly at sita.aero) Date: Thu, 10 Apr 2014 14:32:06 -0400 Subject: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials In-Reply-To: <20140410161015.GH27972@localhost.localdomain> References: <20140410072546.GU20958@redhat.com> <20140410161015.GH27972@localhost.localdomain> Message-ID: SELinux is disabled, I changed the permissions back to the old ones and I have the problem again, although as root I can kinit as myself and can run commands. But not as the regular user. Do you have any strace examples to share? [root at replicahostname /tmp]# ll -Za drwxrwxrwt. root root system_u:object_r:tmp_t:s0 . dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. -rw------- rkelly rkelly ? .bash_history drwxrwxrwt root root ? .ICE-unix drwxrwxr-x rkelly rkelly ? .ipa -r-------- root root ? krb5cc_0 -r-------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd -r-------- rkelly rkelly ? krb5cc_1599100000_CUkupo -r-------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 -r-------- apache apache ? krb5cc_48 = [root at replicahostname /tmp]# klist klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_1599100000_CUkupo) [root at liipaxs007p /tmp]# cat /etc/sysconfig/selinux # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=disabled # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted Thank You, Rashard Kelly From: Sumit Bose To: Rashard.Kelly at sita.aero Cc: freeipa-users at redhat.com Date: 04/10/2014 12:31 PM Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials On Thu, Apr 10, 2014 at 11:55:05AM -0400, Rashard.Kelly at sita.aero wrote: > I can run commands after changing the permissions on the files, but why is > it generating files that are not world readable? > > [rkelly at replicahostname ~]$ ll > total 84 > -rw-r--r-- 1 root root 2428 Apr 9 22:34 krb5cc_0 > -rw-r--r-- 1 xs05144 xs05144 1146 Apr 3 16:10 krb5cc_1599000020_u5RRhd > -rw-r--r-- 1 rkelly rkelly 569 Apr 10 15:14 krb5cc_1599100000_CUkupo > -rw-r--r-- 1 rkelly rkelly 1873 Apr 9 23:40 krb5cc_1599100000_ZekyY0 > -rw-r--r-- 1 apache apache 662 Apr 10 06:02 krb5cc_48 Please don't do this, the credential cache files are similar to your password, only the user itself should be allowed to read it. When you use ls with the -Z option there is a '?' where the SELinux context should be printed. Maybe there are issues with your SELinux setup which prevent access to the ccache files? Can you try SELinux in permissive mode? If there are still issues running klist which strace might give some more details why the ccache file cannot be read. HTH bye, Sumit > > [rkelly at replicahostname ~]$ klist > Ticket cache: FILE:/tmp/krb5cc_1599100000_CUkupo > Default principal: rkelly at DOMAIN > > Valid starting Expires Service principal > 04/10/14 15:14:40 04/11/14 15:14:40 krbtgt/IPA2.DC.SITA.AERO at DOMAIN > > [rkelly at replicahostname ~]$ ipa user-find kelly > -------------- > 1 user matched > -------------- > User login: rkelly > First name: Rashard > Last name: KElly > Home directory: /home/rkelly > Login shell: /bin/sh > Email address: rkelly at domain > UID: 1599100000 > GID: 1599100000 > Account disabled: False > Password: True > Kerberos keys available: True > ---------------------------- > Number of entries returned 1 > ---------------------------- > Thank You, > Rashard Kelly > > > > From: Rashard.Kelly at sita.aero > To: Alexander Bokovoy > Cc: freeipa-users at redhat.com > Date: 04/10/2014 08:42 AM > Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos > credentials > Sent by: freeipa-users-bounces at redhat.com > > > > The krb5 files are not readable by everyone. There are multiple krb5 files > in tmp, should they automatically be readable by all? BTW our users do not > have home directories if that makes a difference. > > [rkelly at replicahostname ~]$ ls -lZ /tmp |grep krb > -rw------- root root ? krb5cc_0 > -rw------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd > -rw------- rkelly rkelly ? krb5cc_1599100000_oKtZFE > -rw------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 > -rw------- apache apache ? krb5cc_48 > > ipa-server-selinux-3.0.0-37.el6.x86_64 > ipa-client-3.0.0-37.el6.x86_64 > ipa-server-3.0.0-37.el6.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 > ipa-python-3.0.0-37.el6.x86_64 > ipa-admintools-3.0.0-37.el6.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > libipa_hbac-1.9.2-129.el6_5.4.x86_64 > python-iniparse-0.3.1-2.1.el6.noarch > > [rkelly at replicahostname ~]$ cat /proc/mounts | grep /tmp > /dev/mapper/system-tmp_vol /tmp ext4 rw,relatime,barrier=1,data=ordered 0 > 0 > [rkelly at replicahostname ~]$ echo $KRB5CCNAME > FILE:/tmp/krb5cc_1599100000_oKtZFE > > [rkelly at replicahostname ~]$ ls -lZ /tmp/krb5cc_1599100000_oKtZFE > -rw------- rkelly rkelly ? /tmp/krb5cc_1599100000_oKtZFE > > [rkelly at replicahostname ~]$ KRB5_TRACE=/dev/stderr kinit > [14559] 1397132474.221287: Getting initial credentials for rkelly at DOMAIN > [14559] 1397132474.221510: Sending request (191 bytes) to DOMAIN > [14559] 1397132474.221677: Sending initial UDP request to dgram > 10.228.20.25:88 > [14559] 1397132474.225248: Received answer from dgram 10.228.20.25:88 > [14559] 1397132474.225287: Response was from master KDC > [14559] 1397132474.225306: Received error from KDC: -1765328359/Additional > pre-authentication required > [14559] 1397132474.225331: Processing preauth types: 136, 19, 2, 133 > [14559] 1397132474.225343: Selected etype info: etype aes256-cts, salt > "IPA2.DC.SITA.AEROrkelly", params "" > [14559] 1397132474.225346: Received cookie: MIT > Password for rkelly at DOMAIN: > [14559] 1397132484.255381: AS key obtained for encrypted timestamp: > aes256-cts/DBF7 > [14559] 1397132484.255432: Encrypted timestamp (for 1397132484.255390): > plain 301AA011180F32303134303431303132323132345AA105020303E59E, encrypted > 321A6A1E297880D1E2D1BF069D6D44136D7A2A0D3AAFC3209CB9B4E5BAAE59E928559E47FD0A140F68D377A8398D7CAB4B735D0612247A7C > > [14559] 1397132484.255453: Preauth module encrypted_timestamp (2) > (flags=1) returned: 0/Success > [14559] 1397132484.255457: Produced preauth for next request: 133, 2 > [14559] 1397132484.255474: Sending request (286 bytes) to DOMAIN (master) > [14559] 1397132484.255560: Sending initial UDP request to dgram > 10.228.20.25:88 > [14559] 1397132484.262563: Received answer from dgram 10.228.20.25:88 > [14559] 1397132484.262593: Processing preauth types: 19 > [14559] 1397132484.262600: Selected etype info: etype aes256-cts, salt > "DOMAINrkelly", params "" > [14559] 1397132484.262603: Produced preauth for next request: (empty) > [14559] 1397132484.262609: AS key determined by preauth: aes256-cts/DBF7 > [14559] 1397132484.262650: Decrypted AS reply; session key is: > aes256-cts/B097 > [14559] 1397132484.262664: FAST negotiation: available > [14559] 1397132484.262681: Initializing FILE:/tmp/krb5cc_1599100000_oKtZFE > with default princ rkelly at DOMAIN > > [rkelly at replicahostname ~]$ KRB5_TRACE=/dev/stderr klist > klist: Credentials cache permissions incorrect while setting cache flags > (ticket cache FILE:/tmp/krb5cc_1599100000_oKtZFE) > > -- > > > Thank You, > Rashard Kelly > > > > > From: Alexander Bokovoy > To: Rashard.Kelly at sita.aero > Cc: freeipa-users at redhat.com > Date: 04/10/2014 03:25 AM > Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos > credentials > > > > On Thu, 10 Apr 2014, Rashard.Kelly at sita.aero wrote: > >Hello all > > > > > >When I try to execute and commands from the an ipa-replica I get > > > >[rkelly at replicahostname ~]$ ipa user-find > >ipa: ERROR: did not receive Kerberos credentials > >[rkelly at replicahostname ~]$ kinit > >Password for rkelly at IPA2.DC.SITA.AERO: > >[rkelly at replicahostname ~]$ ipa user-find > >ipa: ERROR: did not receive Kerberos credentials > >[rkelly at replicahostname ~]$ klist > >klist: Credentials cache permissions incorrect while setting cache flags > >(ticket cache FILE:/tmp/krb5cc_1599100000_qojy7v) > > > >I thought perhaps the two are out of sync > >[root at replicahostname ~]# ipa-replica-manage re-initialize --from > >liipaxs010p.ipa2.dc.sita.aero > >Invalid password > > > > > >ipa-replica-conncheck says communication is ok. > > > >I looked at the httpd, secure,and krb log and none show any activity when > >I execute the commands above. Im lost any clues as to where I can look > for > >answers? > Let's put IPA commands aside and first find out what's wrong with your > Kerberos infra. Looking at your ticket cache file name > (FILE:/tmp/krb5cc_1599100000_qojy7v) I assume you have come to this > machine via SSH and the ticket cache is created by the sshd or sssd. > > The message you received out of klist is shown if ccache file is either: > - unaccessible for the user > - is a directory rather than a file > - is a broken symlink > - blocked by some app with explusive locks > - cannot be open for a write > > Please provide output of > $ cat /proc/mounts | grep /tmp > $ echo $KRB5CCNAME > $ ls -lZ /tmp/krb5cc_1599100000_qojy7v > $ KRB5_TRACE=/dev/stderr kinit > $ KRB5_TRACE=/dev/stderr klist > > You can temporarily overcome this issue by selecting a different ticket > cache by setting KRB5CCNAME environmental variable: > > $ export KRB5CCNAME=$HOME/.krb5cc > $ kinit > $ ipa user-find > ... > > However, it would be good to solve the issue to avoid repeating these > problems > > > > -- > / Alexander Bokovoy > > > This document is strictly confidential and intended only for use by the > addressee unless otherwise stated. If you are not the intended recipient, > please notify the sender immediately and delete it from your system. See > you at 2014 Air Transport IT Summit, 17-19 June 2014 Click here to > register http://www.sitasummit.aero > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > This document is strictly confidential and intended only for use by the > addressee unless otherwise stated. If you are not the intended recipient, > please notify the sender immediately and delete it from your system. > See you at 2014 Air Transport IT Summit, 17-19 June 2014 > > Click here to register http://www.sitasummit.aero > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. See you at 2014 Air Transport IT Summit, 17-19 June 2014 Click here to register http://www.sitasummit.aero -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Apr 10 18:44:02 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 10 Apr 2014 20:44:02 +0200 Subject: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials In-Reply-To: References: <20140410072546.GU20958@redhat.com> <20140410161015.GH27972@localhost.localdomain> Message-ID: <20140410184402.GI27972@localhost.localdomain> On Thu, Apr 10, 2014 at 02:32:06PM -0400, Rashard.Kelly at sita.aero wrote: > SELinux is disabled, I changed the permissions back to the old ones and I > have the problem again, although as root I can kinit as myself and can run > commands. But not as the regular user. Do you have any strace examples to > share? > > > [root at replicahostname /tmp]# ll -Za > drwxrwxrwt. root root system_u:object_r:tmp_t:s0 . > dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. > -rw------- rkelly rkelly ? .bash_history > drwxrwxrwt root root ? .ICE-unix > drwxrwxr-x rkelly rkelly ? .ipa > -r-------- root root ? krb5cc_0 > -r-------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd > -r-------- rkelly rkelly ? krb5cc_1599100000_CUkupo > -r-------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 > -r-------- apache apache ? krb5cc_48 > = > > [root at replicahostname /tmp]# klist > klist: Credentials cache permissions incorrect while setting cache flags > (ticket cache FILE:/tmp/krb5cc_1599100000_CUkupo) strace -o /tmp/klist.out -s 512 klist The needed output will be in /tmp/klist.out. bye, Sumit > > > [root at liipaxs007p /tmp]# cat /etc/sysconfig/selinux > # This file controls the state of SELinux on the system. > # SELINUX= can take one of these three values: > # enforcing - SELinux security policy is enforced. > # permissive - SELinux prints warnings instead of enforcing. > # disabled - SELinux is fully disabled. > SELINUX=disabled > # SELINUXTYPE= type of policy in use. Possible values are: > # targeted - Only targeted network daemons are protected. > # strict - Full SELinux protection. > SELINUXTYPE=targeted > > > Thank You, > Rashard Kelly > > > > > From: Sumit Bose > To: Rashard.Kelly at sita.aero > Cc: freeipa-users at redhat.com > Date: 04/10/2014 12:31 PM > Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos > credentials > > > > On Thu, Apr 10, 2014 at 11:55:05AM -0400, Rashard.Kelly at sita.aero wrote: > > I can run commands after changing the permissions on the files, but why > is > > it generating files that are not world readable? > > > > [rkelly at replicahostname ~]$ ll > > total 84 > > -rw-r--r-- 1 root root 2428 Apr 9 22:34 krb5cc_0 > > -rw-r--r-- 1 xs05144 xs05144 1146 Apr 3 16:10 > krb5cc_1599000020_u5RRhd > > -rw-r--r-- 1 rkelly rkelly 569 Apr 10 15:14 > krb5cc_1599100000_CUkupo > > -rw-r--r-- 1 rkelly rkelly 1873 Apr 9 23:40 > krb5cc_1599100000_ZekyY0 > > -rw-r--r-- 1 apache apache 662 Apr 10 06:02 krb5cc_48 > > Please don't do this, the credential cache files are similar to your > password, only the user itself should be allowed to read it. > > When you use ls with the -Z option there is a '?' where the SELinux > context should be printed. Maybe there are issues with your SELinux > setup which prevent access to the ccache files? Can you try SELinux in > permissive mode? If there are still issues running klist which strace > might give some more details why the ccache file cannot be read. > > HTH > > bye, > Sumit > > > > > [rkelly at replicahostname ~]$ klist > > Ticket cache: FILE:/tmp/krb5cc_1599100000_CUkupo > > Default principal: rkelly at DOMAIN > > > > Valid starting Expires Service principal > > 04/10/14 15:14:40 04/11/14 15:14:40 krbtgt/IPA2.DC.SITA.AERO at DOMAIN > > > > [rkelly at replicahostname ~]$ ipa user-find kelly > > -------------- > > 1 user matched > > -------------- > > User login: rkelly > > First name: Rashard > > Last name: KElly > > Home directory: /home/rkelly > > Login shell: /bin/sh > > Email address: rkelly at domain > > UID: 1599100000 > > GID: 1599100000 > > Account disabled: False > > Password: True > > Kerberos keys available: True > > ---------------------------- > > Number of entries returned 1 > > ---------------------------- > > Thank You, > > Rashard Kelly > > > > > > > > From: Rashard.Kelly at sita.aero > > To: Alexander Bokovoy > > Cc: freeipa-users at redhat.com > > Date: 04/10/2014 08:42 AM > > Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos > > > credentials > > Sent by: freeipa-users-bounces at redhat.com > > > > > > > > The krb5 files are not readable by everyone. There are multiple krb5 > files > > in tmp, should they automatically be readable by all? BTW our users do > not > > have home directories if that makes a difference. > > > > [rkelly at replicahostname ~]$ ls -lZ /tmp |grep krb > > -rw------- root root ? krb5cc_0 > > -rw------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd > > -rw------- rkelly rkelly ? krb5cc_1599100000_oKtZFE > > -rw------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 > > -rw------- apache apache ? krb5cc_48 > > > > ipa-server-selinux-3.0.0-37.el6.x86_64 > > ipa-client-3.0.0-37.el6.x86_64 > > ipa-server-3.0.0-37.el6.x86_64 > > ipa-pki-common-theme-9.0.3-7.el6.noarch > > libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 > > ipa-python-3.0.0-37.el6.x86_64 > > ipa-admintools-3.0.0-37.el6.x86_64 > > ipa-pki-ca-theme-9.0.3-7.el6.noarch > > libipa_hbac-1.9.2-129.el6_5.4.x86_64 > > python-iniparse-0.3.1-2.1.el6.noarch > > > > [rkelly at replicahostname ~]$ cat /proc/mounts | grep /tmp > > /dev/mapper/system-tmp_vol /tmp ext4 rw,relatime,barrier=1,data=ordered > 0 > > 0 > > [rkelly at replicahostname ~]$ echo $KRB5CCNAME > > FILE:/tmp/krb5cc_1599100000_oKtZFE > > > > [rkelly at replicahostname ~]$ ls -lZ /tmp/krb5cc_1599100000_oKtZFE > > -rw------- rkelly rkelly ? /tmp/krb5cc_1599100000_oKtZFE > > > > [rkelly at replicahostname ~]$ KRB5_TRACE=/dev/stderr kinit > > [14559] 1397132474.221287: Getting initial credentials for rkelly at DOMAIN > > > [14559] 1397132474.221510: Sending request (191 bytes) to DOMAIN > > [14559] 1397132474.221677: Sending initial UDP request to dgram > > 10.228.20.25:88 > > [14559] 1397132474.225248: Received answer from dgram 10.228.20.25:88 > > [14559] 1397132474.225287: Response was from master KDC > > [14559] 1397132474.225306: Received error from KDC: > -1765328359/Additional > > pre-authentication required > > [14559] 1397132474.225331: Processing preauth types: 136, 19, 2, 133 > > [14559] 1397132474.225343: Selected etype info: etype aes256-cts, salt > > "IPA2.DC.SITA.AEROrkelly", params "" > > [14559] 1397132474.225346: Received cookie: MIT > > Password for rkelly at DOMAIN: > > [14559] 1397132484.255381: AS key obtained for encrypted timestamp: > > aes256-cts/DBF7 > > [14559] 1397132484.255432: Encrypted timestamp (for 1397132484.255390): > > plain 301AA011180F32303134303431303132323132345AA105020303E59E, > encrypted > > > 321A6A1E297880D1E2D1BF069D6D44136D7A2A0D3AAFC3209CB9B4E5BAAE59E928559E47FD0A140F68D377A8398D7CAB4B735D0612247A7C > > > > > [14559] 1397132484.255453: Preauth module encrypted_timestamp (2) > > (flags=1) returned: 0/Success > > [14559] 1397132484.255457: Produced preauth for next request: 133, 2 > > [14559] 1397132484.255474: Sending request (286 bytes) to DOMAIN > (master) > > [14559] 1397132484.255560: Sending initial UDP request to dgram > > 10.228.20.25:88 > > [14559] 1397132484.262563: Received answer from dgram 10.228.20.25:88 > > [14559] 1397132484.262593: Processing preauth types: 19 > > [14559] 1397132484.262600: Selected etype info: etype aes256-cts, salt > > "DOMAINrkelly", params "" > > [14559] 1397132484.262603: Produced preauth for next request: (empty) > > [14559] 1397132484.262609: AS key determined by preauth: aes256-cts/DBF7 > > > [14559] 1397132484.262650: Decrypted AS reply; session key is: > > aes256-cts/B097 > > [14559] 1397132484.262664: FAST negotiation: available > > [14559] 1397132484.262681: Initializing > FILE:/tmp/krb5cc_1599100000_oKtZFE > > with default princ rkelly at DOMAIN > > > > [rkelly at replicahostname ~]$ KRB5_TRACE=/dev/stderr klist > > klist: Credentials cache permissions incorrect while setting cache flags > > > (ticket cache FILE:/tmp/krb5cc_1599100000_oKtZFE) > > > > -- > > > > > > Thank You, > > Rashard Kelly > > > > > > > > > > From: Alexander Bokovoy > > To: Rashard.Kelly at sita.aero > > Cc: freeipa-users at redhat.com > > Date: 04/10/2014 03:25 AM > > Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos > > > credentials > > > > > > > > On Thu, 10 Apr 2014, Rashard.Kelly at sita.aero wrote: > > >Hello all > > > > > > > > >When I try to execute and commands from the an ipa-replica I get > > > > > >[rkelly at replicahostname ~]$ ipa user-find > > >ipa: ERROR: did not receive Kerberos credentials > > >[rkelly at replicahostname ~]$ kinit > > >Password for rkelly at IPA2.DC.SITA.AERO: > > >[rkelly at replicahostname ~]$ ipa user-find > > >ipa: ERROR: did not receive Kerberos credentials > > >[rkelly at replicahostname ~]$ klist > > >klist: Credentials cache permissions incorrect while setting cache > flags > > >(ticket cache FILE:/tmp/krb5cc_1599100000_qojy7v) > > > > > >I thought perhaps the two are out of sync > > >[root at replicahostname ~]# ipa-replica-manage re-initialize --from > > >liipaxs010p.ipa2.dc.sita.aero > > >Invalid password > > > > > > > > >ipa-replica-conncheck says communication is ok. > > > > > >I looked at the httpd, secure,and krb log and none show any activity > when > > >I execute the commands above. Im lost any clues as to where I can look > > for > > >answers? > > Let's put IPA commands aside and first find out what's wrong with your > > Kerberos infra. Looking at your ticket cache file name > > (FILE:/tmp/krb5cc_1599100000_qojy7v) I assume you have come to this > > machine via SSH and the ticket cache is created by the sshd or sssd. > > > > The message you received out of klist is shown if ccache file is either: > > - unaccessible for the user > > - is a directory rather than a file > > - is a broken symlink > > - blocked by some app with explusive locks > > - cannot be open for a write > > > > Please provide output of > > $ cat /proc/mounts | grep /tmp > > $ echo $KRB5CCNAME > > $ ls -lZ /tmp/krb5cc_1599100000_qojy7v > > $ KRB5_TRACE=/dev/stderr kinit > > $ KRB5_TRACE=/dev/stderr klist > > > > You can temporarily overcome this issue by selecting a different ticket > > cache by setting KRB5CCNAME environmental variable: > > > > $ export KRB5CCNAME=$HOME/.krb5cc > > $ kinit > > $ ipa user-find > > ... > > > > However, it would be good to solve the issue to avoid repeating these > > problems > > > > > > > > -- > > / Alexander Bokovoy > > > > > > This document is strictly confidential and intended only for use by the > > addressee unless otherwise stated. If you are not the intended > recipient, > > please notify the sender immediately and delete it from your system. See > > > you at 2014 Air Transport IT Summit, 17-19 June 2014 Click here to > > register http://www.sitasummit.aero > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > This document is strictly confidential and intended only for use by the > > addressee unless otherwise stated. If you are not the intended > recipient, > > please notify the sender immediately and delete it from your system. > > See you at 2014 Air Transport IT Summit, 17-19 June 2014 > > > > Click here to register http://www.sitasummit.aero > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > This document is strictly confidential and intended only for use by the > addressee unless otherwise stated. If you are not the intended recipient, > please notify the sender immediately and delete it from your system. > See you at 2014 Air Transport IT Summit, 17-19 June 2014 > > Click here to register http://www.sitasummit.aero > > From gharris at teamexpansion.org Thu Apr 10 21:05:51 2014 From: gharris at teamexpansion.org (Greg Harris) Date: Thu, 10 Apr 2014 17:05:51 -0400 Subject: [Freeipa-users] Rekey Self-signed CA Message-ID: <0C120FD1-DFE1-46B7-BA5F-5F64C058C823@teamexpansion.org> I feel dumb, but I cannot seem to find anything about this. How do I rekey the self-signed CA cert for IdM/IPA? It seems like it should be something simple, but I?m not finding anything. CentOS 6.5 install. If you?ve got a place to point me towards, that would be wonderful. Thanks, Greg Harris -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Apr 10 21:29:05 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Apr 2014 17:29:05 -0400 Subject: [Freeipa-users] Rekey Self-signed CA In-Reply-To: <0C120FD1-DFE1-46B7-BA5F-5F64C058C823@teamexpansion.org> References: <0C120FD1-DFE1-46B7-BA5F-5F64C058C823@teamexpansion.org> Message-ID: <53470D21.9040704@redhat.com> Greg Harris wrote: > I feel dumb, but I cannot seem to find anything about this. How do I > rekey the self-signed CA cert for IdM/IPA? It seems like it should be > something simple, but I?m not finding anything. CentOS 6.5 install. If > you?ve got a place to point me towards, that would be wonderful. Need more information on your installation, including the version. Are you running the IPA CA? And what do you mean by re-key (and why do you want to)? rob From bnordgren at fs.fed.us Thu Apr 10 21:40:19 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Thu, 10 Apr 2014 21:40:19 +0000 Subject: [Freeipa-users] External Collaboration Domains In-Reply-To: <534489E9.9090809@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net> <20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net> <20140330182619.GA19628@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net> <53389BEA.9050905@redhat.com> <20140408133456.GR20958@redhat.com> <5343FCC6.10209@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A7E8E@001FSN2MPN1-045.001f.mgd2.msft.net> <534489E9.9090809@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E6A8756@001FSN2MPN1-045.001f.mgd2.msft.net> > > Close. The problem is to expose kerberized services in the local realm to > users holding foreign credentials, supporting SSO wherever possible. This > includes file sharing via NFS, kerberized web apps, ssh logins, and anything > else the local realm has to offer. SSSD can handle ssh logins (if one considers > it "handled" to transmit the password over the wire and abandon SSO), but > cannot handle the former two. > > This is already handled with the trusts feature with AD. It is handled by SSO > and using Kerberos ticket renegotiation between two domains. > The similar approach would work for IPA to IPA and IPA to Kerberos. In the > IPA to IPA case we will have authorization data in the ticket that would help > with this. > I am sorry I fail to see a driver and use case here. But may be I am missing > something obvious. Trusts are only feasible between tightly coordinated realms and with the involvement of admins. The use case is a collaboration realm, where users (not admins) drive the connections between realms. This precipitates everything in the proposal. If the user is coming from an AD realm, there may not be a trust, and it may be inappropriate to have an admin form one if there are only three or four users binding the two realms together. The AD realm may be behind the institutional firewall and the KDC inaccessible, making PKINIT a good choice. Perhaps kx509 certificates are not available from the home realm, making OpenID or SAML a good choice. A theme in your previous message was that some use case is already covered because the admin can explicitly take some action to handle it, and each instance (each new trust) needs to be individually created and then managed. The point of this RFE is that the admin can set up a realm which responds to how users travel from realm to realm, offering both flexibility for the manner in which users authenticate and consistency for the services offered by the realm. It's a different mindset that makes the use case invisible. :) Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From dpal at redhat.com Thu Apr 10 23:31:38 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 10 Apr 2014 19:31:38 -0400 Subject: [Freeipa-users] External Collaboration Domains In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E6A8756@001FSN2MPN1-045.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net> <20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net> <20140330182619.GA19628@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net> <53389BEA.9050905@redhat.com> <20140408133456.GR20958@redhat.com> <5343FCC6.10209@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A7E8E@001FSN2MPN1-045.001f.mgd2.msft.net> <534489E9.9090809@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8756@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <534729DA.2070003@redhat.com> On 04/10/2014 05:40 PM, Nordgren, Bryce L -FS wrote: >>> Close. The problem is to expose kerberized services in the local realm to >> users holding foreign credentials, supporting SSO wherever possible. This >> includes file sharing via NFS, kerberized web apps, ssh logins, and anything >> else the local realm has to offer. SSSD can handle ssh logins (if one considers >> it "handled" to transmit the password over the wire and abandon SSO), but >> cannot handle the former two. >> >> This is already handled with the trusts feature with AD. It is handled by SSO >> and using Kerberos ticket renegotiation between two domains. >> The similar approach would work for IPA to IPA and IPA to Kerberos. In the >> IPA to IPA case we will have authorization data in the ticket that would help >> with this. >> I am sorry I fail to see a driver and use case here. But may be I am missing >> something obvious. > Trusts are only feasible between tightly coordinated realms and with the involvement of admins. The use case is a collaboration realm, where users (not admins) drive the connections between realms. This precipitates everything in the proposal. If the user is coming from an AD realm, there may not be a trust, and it may be inappropriate to have an admin form one if there are only three or four users binding the two realms together. The AD realm may be behind the institutional firewall and the KDC inaccessible, making PKINIT a good choice. Perhaps kx509 certificates are not available from the home realm, making OpenID or SAML a good choice. > > A theme in your previous message was that some use case is already covered because the admin can explicitly take some action to handle it, and each instance (each new trust) needs to be individually created and then managed. The point of this RFE is that the admin can set up a realm which responds to how users travel from realm to realm, offering both flexibility for the manner in which users authenticate and consistency for the services offered by the realm. > > It's a different mindset that makes the use case invisible. :) I guess we just do not see this scenario in practice yet. The users that come from an external realm would come via SAML or similar and interact with a service provided by the local realm. In this case an external user needs to be mapped to the role by the service. Such user does not need to have a special user account, principal, UID/GID as he is not going to access the vanilla services and infrastructure on the low level. He is sort of guest, a tenant, and will be handle by a provided service rather than infra. The service can cache the user information for future but not more than that. Sorry I have a mindset that suggest that allowing external users to auto-materialize in my internal enterprise domain servicing my infa is a bad idea. May be it comes from the deep belief that the role of IdM is to only serve local identities inside the local namespace and federate with other namespaces using trusts or SAML and similar. Can you give me an example of a real world scenario when a local domain would welcome user accounts to be synthesized out of the thin air? Thanks Dmitri > > Bryce > > > > > > > > > This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From gharris at teamexpansion.org Thu Apr 10 22:16:53 2014 From: gharris at teamexpansion.org (Greg Harris) Date: Thu, 10 Apr 2014 18:16:53 -0400 Subject: [Freeipa-users] Rekey Self-signed CA In-Reply-To: <53470D21.9040704@redhat.com> References: <0C120FD1-DFE1-46B7-BA5F-5F64C058C823@teamexpansion.org> <53470D21.9040704@redhat.com> Message-ID: Rob, Thanks for the quick response. It?s version 3.0, as included in CentOS 6.5 EPEL. Yes, I?m running the IPA CA, installed as a self-signed setup. By rekey, I mean generating a new Public/Private key pair for the CA certificate, and then subsequently rekeying all of the certs below. Main reason? Heartbleed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Apr 11 00:30:37 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Apr 2014 20:30:37 -0400 Subject: [Freeipa-users] Rekey Self-signed CA In-Reply-To: References: <0C120FD1-DFE1-46B7-BA5F-5F64C058C823@teamexpansion.org> <53470D21.9040704@redhat.com> Message-ID: <534737AD.4060101@redhat.com> Greg Harris wrote: > Rob, > > Thanks for the quick response. It?s version 3.0, as included in CentOS > 6.5 EPEL. Yes, I?m running the IPA CA, installed as a self-signed > setup. By rekey, I mean generating a new Public/Private key pair for > the CA certificate, and then subsequently rekeying all of the certs > below. Main reason? Heartbleed. No worries then. The IPA CA (dogtag) uses NSS for crypto so there is no way the CA private key could have been exposed. If you've issued SSL certs from the IPA CA for services running OpenSSL you could re-issue those to be on the safe side, but IPA itself uses only NSS on its servers. rob From barrykfl at gmail.com Fri Apr 11 04:16:12 2014 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Fri, 11 Apr 2014 12:16:12 +0800 Subject: [Freeipa-users] add a cert of .net insetad of .com error ? Message-ID: Dear all: I added *.abc.net cet to certutil -d /etc/httpd/alias and /etc/dirsrv/slapd-ABC-COM But error comes out after when i login the UI of service and cick in entry . cannot connect to 'https://cert1.abc.com:443/ca/agent/ca/displayBySerial': [Errno -12276] (SSL_ERROR_BAD_CERT_DOMAIN) Unable to communicate securely with peer: requested domain name does not match the server's certificate. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Apr 11 12:47:17 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Apr 2014 08:47:17 -0400 Subject: [Freeipa-users] add a cert of .net insetad of .com error ? In-Reply-To: References: Message-ID: <5347E455.2050005@redhat.com> barrykfl at gmail.com wrote: > Dear all: > > I added *.abc.net cet to certutil -d /etc/httpd/alias > and /etc/dirsrv/slapd-ABC-COM > > But error comes out after when i login the UI of service and cick in entry . > > cannot connect to > 'https://cert1.abc.com:443/ca/agent/ca/displayBySerial': [Errno -12276] > (SSL_ERROR_BAD_CERT_DOMAIN) Unable to communicate securely with peer: > requested domain name does not match the server's certificate. This is the SSL MITM protection. The subject of the certificate on the server needs to match the hostname that the client is requesting. You can't just change the domain name of your installation by replacing the certificates. rob From gharris at teamexpansion.org Fri Apr 11 01:19:03 2014 From: gharris at teamexpansion.org (Greg Harris) Date: Thu, 10 Apr 2014 21:19:03 -0400 Subject: [Freeipa-users] Rekey Self-signed CA In-Reply-To: <534737AD.4060101@redhat.com> References: <0C120FD1-DFE1-46B7-BA5F-5F64C058C823@teamexpansion.org> <53470D21.9040704@redhat.com> <534737AD.4060101@redhat.com> Message-ID: <023CB99A-F32E-4121-8224-7D661464F403@teamexpansion.org> > No worries then. The IPA CA (dogtag) uses NSS for crypto so there is no way the CA private key could have been exposed. > > If you've issued SSL certs from the IPA CA for services running OpenSSL you could re-issue those to be on the safe side, but IPA itself uses only NSS on its servers. > > rob > Ok, that makes sense. I figured out that the back end, dogtag, was using NSS, but it looked like the web GUI was using OpenSSL. Re-issuing SSL certs for services looks simple enough through the GUI. Thanks for your help. All that aside, is there a way to rekey the IPA CA? I?d hate to see the same type of vulnerability announced next week for NSS and not have any recourse. Thank you. From Rashard.Kelly at sita.aero Fri Apr 11 12:56:37 2014 From: Rashard.Kelly at sita.aero (Rashard.Kelly at sita.aero) Date: Fri, 11 Apr 2014 08:56:37 -0400 Subject: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials In-Reply-To: <20140410184402.GI27972@localhost.localdomain> References: <20140410072546.GU20958@redhat.com> <20140410161015.GH27972@localhost.localdomain> <20140410184402.GI27972@localhost.localdomain> Message-ID: Thanks for the command! [rkelly at liipaxs007p ~]$ strace -o /tmp/klist.out -s 512 klist klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_1599100000_CUkupo) [rkelly at liipaxs007p ~]$ cat klist.out execve("/usr/bin/klist", ["klist"], [/* 25 vars */]) = 0 brk(0) = 0x7f0e2e93a000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e2e64c000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=33362, ...}) = 0 mmap(NULL, 33362, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f0e2e643000 close(3) = 0 open("/lib64/libkrb5.so.3", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000\264\201\2426\0\0\0@\0\0\0\0\0\0\0\210b\16\0\0\0\0\0\0\0\0\0@\0008\0\7\0@\0\37\0\36\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200\2426\0\0\0\0\0\200\2426\0\0\0d\240\r\0\0\0\0\0d\240\r\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\252\r\0\0\0\0\0X\252\255\2426\0\0\0X\252\255\2426\0\0\0\360\254\0\0\0\0\0\0H\260\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`:\16\0\0\0\0\0`:\256\2426\0\0\0`:\256\2426\0\0\0\0\2\0\0\0\0\0\0\0\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\310\1\0\0\0\0\0\0\310\1\200\2426\0\0\0\310\1\200\2426\0\0\0$\0\0\0\0\0\0\0$\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\340d\f\0\0\0\0\0\340d\214\2426\0\0\0\340d\214\2426\0\0\0$1\0\0\0\0\0\0$1\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0R\345td\4\0\0\0X\252\r\0\0\0\0\0X\252\255\2426\0\0\0X\252\255\2426\0\0\0\250\225\0\0\0\0\0\0\250\225\0\0\0\0\0\0\1\0\0\0\0\0\0\0\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\225\353\267L,\n\36\27\0244 at 6\24Z\0029\377\244\211-\0\0\0\0\t\2\0\0\350\0\0\0@\0\0\0\f\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=944712, ...}) = 0 mmap(NULL, 3037856, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0e2e148000 mprotect(0x7f0e2e223000, 2093056, PROT_NONE) = 0 mmap(0x7f0e2e422000, 49152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xda000) = 0x7f0e2e422000 close(3) = 0 open("/lib64/libk5crypto.so.3", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320C\300(7\0\0\0@\0\0\0\0\0\0\0\260\255\2\0\0\0\0\0\0\0\0\0@\0008\0\7\0@\0\37\0\36\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300(7\0\0\0\0\0\300(7\0\0\0\324\206\2\0\0\0\0\0\324\206\2\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0@\221\2\0\0\0\0\0@\221\342(7\0\0\0@\221\342(7\0\0\0\230\21\0\0\0\0\0\0h \0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0H\235\2\0\0\0\0\0H\235\342(7\0\0\0H\235\342(7\0\0\0\340\1\0\0\0\0\0\0\340\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\310\1\0\0\0\0\0\0\310\1\300(7\0\0\0\310\1\300(7\0\0\0$\0\0\0\0\0\0\0$\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334W\2\0\0\0\0\0\334W\302(7\0\0\0\334W\302(7\0\0\0\274\6\0\0\0\0\0\0\274\6\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0R\345td\4\0\0\0@\221\2\0\0\0\0\0@\221\342(7\0\0\0@\221\342(7\0\0\0\300\16\0\0\0\0\0\0\300\16\0\0\0\0\0\0\1\0\0\0\0\0\0\0\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\320.}1I\225\1\30\0\232\201\231t4\342\213}\236\311\262\0\0\0\0a\0\0\0-\0\0\0\20\0\0\0\n\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=177520, ...}) = 0 mmap(NULL, 2273704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0e2df1c000 mprotect(0x7f0e2df45000, 2097152, PROT_NONE) = 0 mmap(0x7f0e2e145000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x29000) = 0x7f0e2e145000 mmap(0x7f0e2e147000, 424, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f0e2e147000 close(3) = 0 open("/lib64/libcom_err.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\23\0\2436\0\0\0@\0\0\0\0\0\0\0\250;\0\0\0\0\0\0\0\0\0\0@\0008\0\10\0@\0\37\0\36\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2436\0\0\0\0\0\0\2436\0\0\0\214$\0\0\0\0\0\0\214$\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\254-\0\0\0\0\0\0\254- \2436\0\0\0\254- \2436\0\0\0\214\3\0\0\0\0\0\0\4\4\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\360-\0\0\0\0\0\0\360- \2436\0\0\0\360- \2436\0\0\0\260\1\0\0\0\0\0\0\260\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0\2\0\0\0\0\0\0\0\2\0\2436\0\0\0\0\2\0\2436\0\0\0$\0\0\0\0\0\0\0$\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0\254-\0\0\0\0\0\0\254- \2436\0\0\0\254- \2436\0\0\0\0\0\0\0\0\0\0\0\31\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0P\345td\4\0\0\0\304 \0\0\0\0\0\0\304 \0\2436\0\0\0\304 \0\2436\0\0\0\254\0\0\0\0\0\0\0\254\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0R\345td\4\0\0\0\254-\0\0\0\0\0\0\254- \2436\0\0\0\254- \2436\0\0\0T\2\0\0\0\0\0\0T\2\0\0\0\0\0\0\1\0\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=17256, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e2e642000 mmap(NULL, 2109872, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0e2dd18000 mprotect(0x7f0e2dd1b000, 2093056, PROT_NONE) = 0 mmap(0x7f0e2df1a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f0e2df1a000 close(3) = 0 open("/lib64/libkrb5support.so.0", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@*@(7\0\0\0@\0\0\0\0\0\0\0`\255\0\0\0\0\0\0\0\0\0\0@\0008\0\7\0@\0\37\0\36\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0@(7\0\0\0\0\0@(7\0\0\0\f\233\0\0\0\0\0\0\f\233\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\360\234\0\0\0\0\0\0\360\234`(7\0\0\0\360\234`(7\0\0\0\300\5\0\0\0\0\0\0`\7\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0P\235\0\0\0\0\0\0P\235`(7\0\0\0P\235`(7\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\310\1\0\0\0\0\0\0\310\1@(7\0\0\0\310\1@(7\0\0\0$\0\0\0\0\0\0\0$\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\354\206\0\0\0\0\0\0\354\206@(7\0\0\0\354\206@(7\0\0\0D\3\0\0\0\0\0\0D\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0R\345td\4\0\0\0\360\234\0\0\0\0\0\0\360\234`(7\0\0\0\360\234`(7\0\0\0\20\3\0\0\0\0\0\0\20\3\0\0\0\0\0\0\1\0\0\0\0\0\0\0\4\0\0\0\24\0\0\0\3\0\0\0GNU\0Z\374\276\240\326.\3403W\24\314\272\267\272\200\216*\26\2\214\0\0\0\0%\0\0\0J\0\0\0\10\0\0\0\t\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=46368, ...}) = 0 mmap(NULL, 2139216, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0e2db0d000 mprotect(0x7f0e2db17000, 2093056, PROT_NONE) = 0 mmap(0x7f0e2dd16000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x9000) = 0x7f0e2dd16000 close(3) = 0 open("/lib64/libkeyutils.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\v\0(7\0\0\0@\0\0\0\0\0\0\0\360)\0\0\0\0\0\0\0\0\0\0@\0008\0\7\0@\0\35\0\34\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(7\0\0\0\0\0\0(7\0\0\0l\25\0\0\0\0\0\0l\25\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\340\35 (7\0\0\0\340\35 (7\0\0\0`\2\0\0\0\0\0\0p\2\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (7\0\0\0\20\36 (7\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\310\1\0\0\0\0\0\0\310\1\0(7\0\0\0\310\1\0(7\0\0\0$\0\0\0\0\0\0\0$\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\350\21\0\0\0\0\0\0\350\21\0(7\0\0\0\350\21\0(7\0\0\0\324\0\0\0\0\0\0\0\324\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0R\345td\4\0\0\0\340\35\0\0\0\0\0\0\340\35 (7\0\0\0\340\35 (7\0\0\0 \2\0\0\0\0\0\0 \2\0\0\0\0\0\0\1\0\0\0\0\0\0\0\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\212\2074\33470]\214\302\357\217\214>^\2401q\333\7\354\0\0\0\0\21\0\0\0\10\0\0\0\4\0\0\0\10\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=12592, ...}) = 0 mmap(NULL, 2105424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0e2d90a000 mprotect(0x7f0e2d90c000, 2093056, PROT_NONE) = 0 mmap(0x7f0e2db0b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f0e2db0b000 close(3) = 0 open("/lib64/libresolv.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\00009\0%7\0\0\0@\0\0\0\0\0\0\0\340\263\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0%\0$\0\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\0%7\0\0\0@\0\0%7\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\2607\1\0\0\0\0\0\2607\1%7\0\0\0\2607\1%7\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0%7\0\0\0\0\0\0%7\0\0\0$Y\1\0\0\0\0\0$Y\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\300d\1\0\0\0\0\0\300d!%7\0\0\0\300d!%7\0\0\0\240\r\0\0\0\0\0\0\3105\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\350m\1\0\0\0\0\0\350m!%7\0\0\0\350m!%7\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\0%7\0\0\0008\2\0%7\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\3147\1\0\0\0\0\0\3147\1%7\0\0\0\3147\1%7\0\0\0\254\3\0\0\0\0\0\0\254\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=113952, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e2e641000 mmap(NULL, 2202248, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0e2d6f0000 mprotect(0x7f0e2d706000, 2097152, PROT_NONE) = 0 mmap(0x7f0e2d906000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0x7f0e2d906000 mmap(0x7f0e2d908000, 6792, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f0e2d908000 close(3) = 0 open("/lib64/libselinux.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0PX@$7\0\0\0@\0\0\0\0\0\0\0\20\337\1\0\0\0\0\0\0\0\0\0@\0008\0\10\0@\0\37\0\36\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0@$7\0\0\0\0\0@$7\0\0\0\274\306\1\0\0\0\0\0\274\306\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\20\315\1\0\0\0\0\0\20\315a$7\0\0\0\20\315a$7\0\0\0\224\7\0\0\0\0\0\0H\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240\315\1\0\0\0\0\0\240\315a$7\0\0\0\240\315a$7\0\0\0\260\1\0\0\0\0\0\0\260\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0\2\0\0\0\0\0\0\0\2@$7\0\0\0\0\2@$7\0\0\0$\0\0\0\0\0\0\0$\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0\20\315\1\0\0\0\0\0\20\315a$7\0\0\0\20\315a$7\0\0\0\0\0\0\0\0\0\0\0\241\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\0\0\0\324\217\1\0\0\0\0\0\324\217A$7\0\0\0\324\217A$7\0\0\0\274\10\0\0\0\0\0\0\274\10\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0R\345td\4\0\0\0\20\315\1\0\0\0\0\0\20\315a$7\0\0\0\20\315a$7\0\0\0\360\2\0\0\0\0\0\0\360\2\0\0\0\0\0\0\1\0\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=124624, ...}) = 0 mmap(NULL, 2221912, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0e2d4d1000 mprotect(0x7f0e2d4ee000, 2093056, PROT_NONE) = 0 mmap(0x7f0e2d6ed000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c000) = 0x7f0e2d6ed000 mmap(0x7f0e2d6ef000, 1880, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f0e2d6ef000 close(3) = 0 open("/lib64/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\r\200\"7\0\0\0@\0\0\0\0\0\0\0\310N\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0%\0$\0\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\200\"7\0\0\0@\0\200\"7\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0P\32\0\0\0\0\0\0P\32\200\"7\0\0\0P\32\200\"7\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200\"7\0\0\0\0\0\200\"7\0\0\0\360\37\0\0\0\0\0\0\360\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\0\0\0\0\0\0`-\240\"7\0\0\0`-\240\"7\0\0\0\30\3\0\0\0\0\0\0\240\3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\240\"7\0\0\0\240-\240\"7\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\200\"7\0\0\0008\2\200\"7\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0l\32\0\0\0\0\0\0l\32\200\"7\0\0\0l\32\200\"7\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=22536, ...}) = 0 mmap(NULL, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0e2d2cd000 mprotect(0x7f0e2d2cf000, 2097152, PROT_NONE) = 0 mmap(0x7f0e2d4cf000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f0e2d4cf000 close(3) = 0 open("/lib64/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000\356\301\"7\0\0\0@\0\0\0\0\0\0\0PS\35\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300\"7\0\0\0@\0\300\"7\0\0\0000\2\0\0\0\0\0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \251\25\0\0\0\0\0 \251\325\"7\0\0\0 \251\325\"7\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300\"7\0\0\0\0\0\300\"7\0\0\0\324\240\30\0\0\0\0\0\324\240\30\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\0\247\30\0\0\0\0\0\0\247\370\"7\0\0\0\0\247\370\"7\0\0\0\230F\0\0\0\0\0\0\10\222\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0@\333\30\0\0\0\0\0@\333\370\"7\0\0\0@\333\370\"7\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0p\2\0\0\0\0\0\0p\2\300\"7\0\0\0p\2\300\"7\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0\0\247\30\0\0\0\0\0\0\247\370\"7\0\0\0\0\247\370\"7\0\0\0\20\0\0\0\0\0\0\0h\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\0\0\0<\251\25\0\0\0\0\0<\251\325\"7\0\0\0<\251\325\"7\0\0\0$f\0\0\0\0\0\0$f\0\0\0\0\0\0\4\0\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1926800, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e2e640000 mmap(NULL, 3750152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0e2cf39000 mprotect(0x7f0e2d0c4000, 2093056, PROT_NONE) = 0 mmap(0x7f0e2d2c3000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18a000) = 0x7f0e2d2c3000 mmap(0x7f0e2d2c8000, 18696, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f0e2d2c8000 close(3) = 0 open("/lib64/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340]@\2436\0\0\0@\0\0\0\0\0\0\0\250/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0@\2436\0\0\0@\0@\2436\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0000\30\1\0\0\0\0\0000\30A\2436\0\0\0000\30A\2436\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0@\2436\0\0\0\0\0@\2436\0\0\0\360m\1\0\0\0\0\0\360m\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\220{\1\0\0\0\0\0\220{a\2436\0\0\0\220{a\2436\0\0\0\340\6\0\0\0\0\0\0`H\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\220}\1\0\0\0\0\0\220}a\2436\0\0\0\220}a\2436\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2@\2436\0\0\0008\2@\2436\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0L\30\1\0\0\0\0\0L\30A\2436\0\0\0L\30A\2436\0\0\0\\\n\0\0\0\0\0\0\\\n\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=145896, ...}) = 0 mmap(NULL, 2212848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0e2cd1c000 mprotect(0x7f0e2cd33000, 2097152, PROT_NONE) = 0 mmap(0x7f0e2cf33000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f0e2cf33000 mmap(0x7f0e2cf35000, 13296, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f0e2cf35000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e2e63f000 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e2e63d000 arch_prctl(ARCH_SET_FS, 0x7f0e2e63d7c0) = 0 mprotect(0x7f0e2cf33000, 4096, PROT_READ) = 0 mprotect(0x7f0e2d2c3000, 16384, PROT_READ) = 0 mprotect(0x7f0e2d4cf000, 4096, PROT_READ) = 0 mprotect(0x7f0e2d6ed000, 4096, PROT_READ) = 0 mprotect(0x7f0e2d906000, 4096, PROT_READ) = 0 mprotect(0x7f0e2db0b000, 4096, PROT_READ) = 0 mprotect(0x7f0e2dd16000, 4096, PROT_READ) = 0 mprotect(0x7f0e2df1a000, 4096, PROT_READ) = 0 mprotect(0x7f0e2e145000, 4096, PROT_READ) = 0 mprotect(0x7f0e2e422000, 40960, PROT_READ) = 0 mprotect(0x7f0e2e855000, 4096, PROT_READ) = 0 mprotect(0x7f0e2e64d000, 4096, PROT_READ) = 0 munmap(0x7f0e2e643000, 33362) = 0 set_tid_address(0x7f0e2e63da90) = 21876 set_robust_list(0x7f0e2e63daa0, 0x18) = 0 futex(0x7fffd260e7cc, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0x7fffd260e7cc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7f0e2e63d7c0) = -1 EAGAIN (Resource temporarily unavailable) rt_sigaction(SIGRTMIN, {0x7f0e2cd21c60, [], SA_RESTORER|SA_SIGINFO, 0x7f0e2cd2b710}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x7f0e2cd21cf0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f0e2cd2b710}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM_INFINITY}) = 0 statfs("/selinux", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=2967348, f_bfree=2276402, f_bavail=2125670, f_files=753664, f_ffree=693049, f_fsid={-1461466328, -1363287150}, f_namelen=255, f_frsize=4096}) = 0 brk(0) = 0x7f0e2e93a000 brk(0x7f0e2e95b000) = 0x7f0e2e95b000 open("/proc/filesystems", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e2e64b000 read(3, "nodev\tsysfs\nnodev\trootfs\nnodev\tbdev\nnodev\tproc\nnodev\tcgroup\nnodev\tcpuset\nnodev\ttmpfs\nnodev\tdevtmpfs\nnodev\tbinfmt_misc\nnodev\tdebugfs\nnodev\tsecurityfs\nnodev\tsockfs\nnodev\tusbfs\nnodev\tpipefs\nnodev\tanon_inodefs\nnodev\tinotifyfs\nnodev\tdevpts\nnodev\tramfs\nnodev\thugetlbfs\n\tiso9660\nnodev\tpstore\nnodev\tmqueue\n\text4\n\text3\nnodev\tautofs\n", 1024) = 323 read(3, "", 1024) = 0 close(3) = 0 munmap(0x7f0e2e64b000, 4096) = 0 open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=99158576, ...}) = 0 mmap(NULL, 99158576, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f0e26e8b000 close(3) = 0 open("/etc/localtime", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0 fstat(3, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e2e64b000 read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\4\0\0\0\0\0\0UTC\0\0\0TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\4\0\0\0\0\0\0UTC\0\0\0\nUTC0\n", 4096) = 118 lseek(3, -62, SEEK_CUR) = 56 read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\4\0\0\0\0\0\0UTC\0\0\0\nUTC0\n", 4096) = 62 close(3) = 0 munmap(0x7f0e2e64b000, 4096) = 0 futex(0x7f0e2dd17308, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f0e2dd17290, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f0e2e42d2c0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f0e2e42d730, FUTEX_WAKE_PRIVATE, 2147483647) = 0 stat("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=742, ...}) = 0 open("/etc/krb5.conf", O_RDONLY) = 3 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 fstat(3, {st_mode=S_IFREG|0644, st_size=742, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e2e64b000 read(3, "includedir /var/lib/sss/pubconf/krb5.include.d/\n\n[logging]\n default = FILE:/var/log/krb5libs.log\n kdc = FILE:/var/log/krb5kdc.log\n admin_server = FILE:/var/log/kadmind.log\n\n[libdefaults]\n default_realm = IPA2.DC.SITA.AERO\n dns_lookup_realm = false\n dns_lookup_kdc = true\n rdns = false\n ticket_lifetime = 24h\n forwardable = yes\n\n[realms]\n IPA2.DC.SITA.AERO = {\n kdc = liipaxs007p.ipa2.dc.sita.aero:88\n master_kdc = liipaxs007p.ipa2.dc.sita.aero:88\n admin_server = liipaxs007p.ipa2.dc.sita.aero:749\n default_do"..., 4096) = 742 open("/var/lib/sss/pubconf/krb5.include.d/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4 fcntl(4, F_GETFD) = 0x1 (flags FD_CLOEXEC) getdents(4, /* 2 entries */, 32768) = 48 getdents(4, /* 0 entries */, 32768) = 0 close(4) = 0 read(3, "", 4096) = 0 close(3) = 0 munmap(0x7f0e2e64b000, 4096) = 0 open("/dev/urandom", O_RDONLY) = 3 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 fstat(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 read(3, "\202\263\251V\30000$IrwS*D\21\213\357x\234CmP\300~\253\235\233$\311\231u\17\221\16\315\4\245\266w\20\356A|\2759\3756\361\360H}\242A\16Nt6D\25F\3\211:1", 64) = 64 close(3) = 0 open("/dev/urandom", O_RDONLY) = 3 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 fstat(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 read(3, "\226\10\337\230\205\301@\32xC\241\n\337C\3707(\350\324\356\361\267\252\210Xv7\354\376\263\344\177\241\357\275\271\317\201\255\352\240\223\32\325~\232_\3353=\212z\276\0Z\27786s\250\30\312\351\331", 64) = 64 close(3) = 0 futex(0x7f0e2e1462c0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 open("/tmp/krb5cc_1599100000_CUkupo", O_RDONLY) = -1 EACCES (Permission denied) open("/usr/share/locale/locale.alias", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=2512, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e2e64b000 read(3, "# Locale name alias data base.\n# Copyright (C) 1996-2001,2003,2007 Free Software Foundation, Inc.\n#\n# This program is free software; you can redistribute it and/or modify\n# it under the terms of the GNU General Public License as published by\n# the Free Software Foundation; either version 2, or (at your option)\n# any later version.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR "..., 4096) = 2512 read(3, "", 4096) = 0 close(3) = 0 munmap(0x7f0e2e64b000, 4096) = 0 open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/mit-krb5.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US.utf8/LC_MESSAGES/mit-krb5.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US/LC_MESSAGES/mit-krb5.mo", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=410, ...}) = 0 mmap(NULL, 410, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f0e2e64b000 close(3) = 0 open("/usr/share/locale/en.UTF-8/LC_MESSAGES/mit-krb5.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en.utf8/LC_MESSAGES/mit-krb5.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en/LC_MESSAGES/mit-krb5.mo", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "klist", 5) = 5 write(2, ": ", 2) = 2 write(2, "Credentials cache permissions incorrect", 39) = 39 write(2, " ", 1) = 1 write(2, "while setting cache flags (ticket cache FILE:/tmp/krb5cc_1599100000_CUkupo)", 75) = 75 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 write(2, "\n", 1) = 1 exit_group(1) Thank You, Rashard Kelly From: Sumit Bose To: Rashard.Kelly at sita.aero Cc: freeipa-users at redhat.com Date: 04/10/2014 02:44 PM Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials On Thu, Apr 10, 2014 at 02:32:06PM -0400, Rashard.Kelly at sita.aero wrote: > SELinux is disabled, I changed the permissions back to the old ones and I > have the problem again, although as root I can kinit as myself and can run > commands. But not as the regular user. Do you have any strace examples to > share? > > > [root at replicahostname /tmp]# ll -Za > drwxrwxrwt. root root system_u:object_r:tmp_t:s0 . > dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. > -rw------- rkelly rkelly ? .bash_history > drwxrwxrwt root root ? .ICE-unix > drwxrwxr-x rkelly rkelly ? .ipa > -r-------- root root ? krb5cc_0 > -r-------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd > -r-------- rkelly rkelly ? krb5cc_1599100000_CUkupo > -r-------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 > -r-------- apache apache ? krb5cc_48 > = > > [root at replicahostname /tmp]# klist > klist: Credentials cache permissions incorrect while setting cache flags > (ticket cache FILE:/tmp/krb5cc_1599100000_CUkupo) strace -o /tmp/klist.out -s 512 klist The needed output will be in /tmp/klist.out. bye, Sumit > > > [root at liipaxs007p /tmp]# cat /etc/sysconfig/selinux > # This file controls the state of SELinux on the system. > # SELINUX= can take one of these three values: > # enforcing - SELinux security policy is enforced. > # permissive - SELinux prints warnings instead of enforcing. > # disabled - SELinux is fully disabled. > SELINUX=disabled > # SELINUXTYPE= type of policy in use. Possible values are: > # targeted - Only targeted network daemons are protected. > # strict - Full SELinux protection. > SELINUXTYPE=targeted > > > Thank You, > Rashard Kelly > > > > > From: Sumit Bose > To: Rashard.Kelly at sita.aero > Cc: freeipa-users at redhat.com > Date: 04/10/2014 12:31 PM > Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos > credentials > > > > On Thu, Apr 10, 2014 at 11:55:05AM -0400, Rashard.Kelly at sita.aero wrote: > > I can run commands after changing the permissions on the files, but why > is > > it generating files that are not world readable? > > > > [rkelly at replicahostname ~]$ ll > > total 84 > > -rw-r--r-- 1 root root 2428 Apr 9 22:34 krb5cc_0 > > -rw-r--r-- 1 xs05144 xs05144 1146 Apr 3 16:10 > krb5cc_1599000020_u5RRhd > > -rw-r--r-- 1 rkelly rkelly 569 Apr 10 15:14 > krb5cc_1599100000_CUkupo > > -rw-r--r-- 1 rkelly rkelly 1873 Apr 9 23:40 > krb5cc_1599100000_ZekyY0 > > -rw-r--r-- 1 apache apache 662 Apr 10 06:02 krb5cc_48 > > Please don't do this, the credential cache files are similar to your > password, only the user itself should be allowed to read it. > > When you use ls with the -Z option there is a '?' where the SELinux > context should be printed. Maybe there are issues with your SELinux > setup which prevent access to the ccache files? Can you try SELinux in > permissive mode? If there are still issues running klist which strace > might give some more details why the ccache file cannot be read. > > HTH > > bye, > Sumit > > > > > [rkelly at replicahostname ~]$ klist > > Ticket cache: FILE:/tmp/krb5cc_1599100000_CUkupo > > Default principal: rkelly at DOMAIN > > > > Valid starting Expires Service principal > > 04/10/14 15:14:40 04/11/14 15:14:40 krbtgt/IPA2.DC.SITA.AERO at DOMAIN > > > > [rkelly at replicahostname ~]$ ipa user-find kelly > > -------------- > > 1 user matched > > -------------- > > User login: rkelly > > First name: Rashard > > Last name: KElly > > Home directory: /home/rkelly > > Login shell: /bin/sh > > Email address: rkelly at domain > > UID: 1599100000 > > GID: 1599100000 > > Account disabled: False > > Password: True > > Kerberos keys available: True > > ---------------------------- > > Number of entries returned 1 > > ---------------------------- > > Thank You, > > Rashard Kelly > > > > > > > > From: Rashard.Kelly at sita.aero > > To: Alexander Bokovoy > > Cc: freeipa-users at redhat.com > > Date: 04/10/2014 08:42 AM > > Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos > > > credentials > > Sent by: freeipa-users-bounces at redhat.com > > > > > > > > The krb5 files are not readable by everyone. There are multiple krb5 > files > > in tmp, should they automatically be readable by all? BTW our users do > not > > have home directories if that makes a difference. > > > > [rkelly at replicahostname ~]$ ls -lZ /tmp |grep krb > > -rw------- root root ? krb5cc_0 > > -rw------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd > > -rw------- rkelly rkelly ? krb5cc_1599100000_oKtZFE > > -rw------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 > > -rw------- apache apache ? krb5cc_48 > > > > ipa-server-selinux-3.0.0-37.el6.x86_64 > > ipa-client-3.0.0-37.el6.x86_64 > > ipa-server-3.0.0-37.el6.x86_64 > > ipa-pki-common-theme-9.0.3-7.el6.noarch > > libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 > > ipa-python-3.0.0-37.el6.x86_64 > > ipa-admintools-3.0.0-37.el6.x86_64 > > ipa-pki-ca-theme-9.0.3-7.el6.noarch > > libipa_hbac-1.9.2-129.el6_5.4.x86_64 > > python-iniparse-0.3.1-2.1.el6.noarch > > > > [rkelly at replicahostname ~]$ cat /proc/mounts | grep /tmp > > /dev/mapper/system-tmp_vol /tmp ext4 rw,relatime,barrier=1,data=ordered > 0 > > 0 > > [rkelly at replicahostname ~]$ echo $KRB5CCNAME > > FILE:/tmp/krb5cc_1599100000_oKtZFE > > > > [rkelly at replicahostname ~]$ ls -lZ /tmp/krb5cc_1599100000_oKtZFE > > -rw------- rkelly rkelly ? /tmp/krb5cc_1599100000_oKtZFE > > > > [rkelly at replicahostname ~]$ KRB5_TRACE=/dev/stderr kinit > > [14559] 1397132474.221287: Getting initial credentials for rkelly at DOMAIN > > > [14559] 1397132474.221510: Sending request (191 bytes) to DOMAIN > > [14559] 1397132474.221677: Sending initial UDP request to dgram > > 10.228.20.25:88 > > [14559] 1397132474.225248: Received answer from dgram 10.228.20.25:88 > > [14559] 1397132474.225287: Response was from master KDC > > [14559] 1397132474.225306: Received error from KDC: > -1765328359/Additional > > pre-authentication required > > [14559] 1397132474.225331: Processing preauth types: 136, 19, 2, 133 > > [14559] 1397132474.225343: Selected etype info: etype aes256-cts, salt > > "IPA2.DC.SITA.AEROrkelly", params "" > > [14559] 1397132474.225346: Received cookie: MIT > > Password for rkelly at DOMAIN: > > [14559] 1397132484.255381: AS key obtained for encrypted timestamp: > > aes256-cts/DBF7 > > [14559] 1397132484.255432: Encrypted timestamp (for 1397132484.255390): > > plain 301AA011180F32303134303431303132323132345AA105020303E59E, > encrypted > > > 321A6A1E297880D1E2D1BF069D6D44136D7A2A0D3AAFC3209CB9B4E5BAAE59E928559E47FD0A140F68D377A8398D7CAB4B735D0612247A7C > > > > > [14559] 1397132484.255453: Preauth module encrypted_timestamp (2) > > (flags=1) returned: 0/Success > > [14559] 1397132484.255457: Produced preauth for next request: 133, 2 > > [14559] 1397132484.255474: Sending request (286 bytes) to DOMAIN > (master) > > [14559] 1397132484.255560: Sending initial UDP request to dgram > > 10.228.20.25:88 > > [14559] 1397132484.262563: Received answer from dgram 10.228.20.25:88 > > [14559] 1397132484.262593: Processing preauth types: 19 > > [14559] 1397132484.262600: Selected etype info: etype aes256-cts, salt > > "DOMAINrkelly", params "" > > [14559] 1397132484.262603: Produced preauth for next request: (empty) > > [14559] 1397132484.262609: AS key determined by preauth: aes256-cts/DBF7 > > > [14559] 1397132484.262650: Decrypted AS reply; session key is: > > aes256-cts/B097 > > [14559] 1397132484.262664: FAST negotiation: available > > [14559] 1397132484.262681: Initializing > FILE:/tmp/krb5cc_1599100000_oKtZFE > > with default princ rkelly at DOMAIN > > > > [rkelly at replicahostname ~]$ KRB5_TRACE=/dev/stderr klist > > klist: Credentials cache permissions incorrect while setting cache flags > > > (ticket cache FILE:/tmp/krb5cc_1599100000_oKtZFE) > > > > -- > > > > > > Thank You, > > Rashard Kelly > > > > > > > > > > From: Alexander Bokovoy > > To: Rashard.Kelly at sita.aero > > Cc: freeipa-users at redhat.com > > Date: 04/10/2014 03:25 AM > > Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos > > > credentials > > > > > > > > On Thu, 10 Apr 2014, Rashard.Kelly at sita.aero wrote: > > >Hello all > > > > > > > > >When I try to execute and commands from the an ipa-replica I get > > > > > >[rkelly at replicahostname ~]$ ipa user-find > > >ipa: ERROR: did not receive Kerberos credentials > > >[rkelly at replicahostname ~]$ kinit > > >Password for rkelly at IPA2.DC.SITA.AERO: > > >[rkelly at replicahostname ~]$ ipa user-find > > >ipa: ERROR: did not receive Kerberos credentials > > >[rkelly at replicahostname ~]$ klist > > >klist: Credentials cache permissions incorrect while setting cache > flags > > >(ticket cache FILE:/tmp/krb5cc_1599100000_qojy7v) > > > > > >I thought perhaps the two are out of sync > > >[root at replicahostname ~]# ipa-replica-manage re-initialize --from > > >liipaxs010p.ipa2.dc.sita.aero > > >Invalid password > > > > > > > > >ipa-replica-conncheck says communication is ok. > > > > > >I looked at the httpd, secure,and krb log and none show any activity > when > > >I execute the commands above. Im lost any clues as to where I can look > > for > > >answers? > > Let's put IPA commands aside and first find out what's wrong with your > > Kerberos infra. Looking at your ticket cache file name > > (FILE:/tmp/krb5cc_1599100000_qojy7v) I assume you have come to this > > machine via SSH and the ticket cache is created by the sshd or sssd. > > > > The message you received out of klist is shown if ccache file is either: > > - unaccessible for the user > > - is a directory rather than a file > > - is a broken symlink > > - blocked by some app with explusive locks > > - cannot be open for a write > > > > Please provide output of > > $ cat /proc/mounts | grep /tmp > > $ echo $KRB5CCNAME > > $ ls -lZ /tmp/krb5cc_1599100000_qojy7v > > $ KRB5_TRACE=/dev/stderr kinit > > $ KRB5_TRACE=/dev/stderr klist > > > > You can temporarily overcome this issue by selecting a different ticket > > cache by setting KRB5CCNAME environmental variable: > > > > $ export KRB5CCNAME=$HOME/.krb5cc > > $ kinit > > $ ipa user-find > > ... > > > > However, it would be good to solve the issue to avoid repeating these > > problems > > > > > > > > -- > > / Alexander Bokovoy > > > > > > This document is strictly confidential and intended only for use by the > > addressee unless otherwise stated. If you are not the intended > recipient, > > please notify the sender immediately and delete it from your system. See > > > you at 2014 Air Transport IT Summit, 17-19 June 2014 Click here to > > register http://www.sitasummit.aero > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > This document is strictly confidential and intended only for use by the > > addressee unless otherwise stated. If you are not the intended > recipient, > > please notify the sender immediately and delete it from your system. > > See you at 2014 Air Transport IT Summit, 17-19 June 2014 > > > > Click here to register http://www.sitasummit.aero > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > This document is strictly confidential and intended only for use by the > addressee unless otherwise stated. If you are not the intended recipient, > please notify the sender immediately and delete it from your system. > See you at 2014 Air Transport IT Summit, 17-19 June 2014 > > Click here to register http://www.sitasummit.aero > > This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. See you at 2014 Air Transport IT Summit, 17-19 June 2014 Click here to register http://www.sitasummit.aero -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Apr 11 13:06:48 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 11 Apr 2014 16:06:48 +0300 Subject: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials In-Reply-To: References: <20140410072546.GU20958@redhat.com> <20140410161015.GH27972@localhost.localdomain> <20140410184402.GI27972@localhost.localdomain> Message-ID: <20140411130648.GX20958@redhat.com> On Fri, 11 Apr 2014, Rashard.Kelly at sita.aero wrote: >futex(0x7f0e2e1462c0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 >open("/tmp/krb5cc_1599100000_CUkupo", O_RDONLY) = -1 EACCES (Permission >denied) Are you sure you don't have SELinux really running and enabled? Because the following output makes me really worry: >> [root at replicahostname /tmp]# ll -Za >> drwxrwxrwt. root root system_u:object_r:tmp_t:s0 . >> dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. >> -rw------- rkelly rkelly ? .bash_history >> drwxrwxrwt root root ? .ICE-unix >> drwxrwxr-x rkelly rkelly ? .ipa >> -r-------- root root ? krb5cc_0 >> -r-------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd >> -r-------- rkelly rkelly ? krb5cc_1599100000_CUkupo >> -r-------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 These rkelly:rkelly krb5cc_* files have no SELinux label and should be readable to the owner. Can you show: [root] # sestatus [root] # audit2why -b -w -t avc -- / Alexander Bokovoy From Rashard.Kelly at sita.aero Fri Apr 11 13:42:41 2014 From: Rashard.Kelly at sita.aero (Rashard.Kelly at sita.aero) Date: Fri, 11 Apr 2014 09:42:41 -0400 Subject: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials In-Reply-To: <20140411130648.GX20958@redhat.com> References: <20140410072546.GU20958@redhat.com> <20140410161015.GH27972@localhost.localdomain> <20140410184402.GI27972@localhost.localdomain> <20140411130648.GX20958@redhat.com> Message-ID: [root at replicahostname ~]# sestatus SELinux status: disabled [root at replicahostname ~]# audit2why -b -w -t avc [root at replicahostname ~]# Nothing in the audit log after audit2why came back either. Thank You, Rashard Kelly From: Alexander Bokovoy To: Rashard.Kelly at sita.aero Cc: Sumit Bose , freeipa-users at redhat.com Date: 04/11/2014 09:06 AM Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials On Fri, 11 Apr 2014, Rashard.Kelly at sita.aero wrote: >futex(0x7f0e2e1462c0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 >open("/tmp/krb5cc_1599100000_CUkupo", O_RDONLY) = -1 EACCES (Permission >denied) Are you sure you don't have SELinux really running and enabled? Because the following output makes me really worry: >> [root at replicahostname /tmp]# ll -Za >> drwxrwxrwt. root root system_u:object_r:tmp_t:s0 . >> dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. >> -rw------- rkelly rkelly ? .bash_history >> drwxrwxrwt root root ? .ICE-unix >> drwxrwxr-x rkelly rkelly ? .ipa >> -r-------- root root ? krb5cc_0 >> -r-------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd >> -r-------- rkelly rkelly ? krb5cc_1599100000_CUkupo >> -r-------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 These rkelly:rkelly krb5cc_* files have no SELinux label and should be readable to the owner. Can you show: [root] # sestatus [root] # audit2why -b -w -t avc -- / Alexander Bokovoy This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. See you at 2014 Air Transport IT Summit, 17-19 June 2014 Click here to register http://www.sitasummit.aero -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Fri Apr 11 13:54:26 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 11 Apr 2014 15:54:26 +0200 Subject: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials In-Reply-To: References: <20140410072546.GU20958@redhat.com> <20140410161015.GH27972@localhost.localdomain> <20140410184402.GI27972@localhost.localdomain> <20140411130648.GX20958@redhat.com> Message-ID: <20140411135426.GL27972@localhost.localdomain> On Fri, Apr 11, 2014 at 09:42:41AM -0400, Rashard.Kelly at sita.aero wrote: > [root at replicahostname ~]# sestatus > SELinux status: disabled > [root at replicahostname ~]# audit2why -b -w -t avc > [root at replicahostname ~]# > > > Nothing in the audit log after audit2why came back either. That's odd. Can you read the file with od? od /tmp/krb5cc_1599100000_CUkupo don't send the output just check if it is readable of if od returns an error as well? Are there any odd filesystem permission on your klist binary like s-bit set? ls -alZ $(which klist) (her you can send the output :-) bye, Sumit > > > Thank You, > Rashard Kelly > > > > From: Alexander Bokovoy > To: Rashard.Kelly at sita.aero > Cc: Sumit Bose , freeipa-users at redhat.com > Date: 04/11/2014 09:06 AM > Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos > credentials > > > > On Fri, 11 Apr 2014, Rashard.Kelly at sita.aero wrote: > >futex(0x7f0e2e1462c0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 > >open("/tmp/krb5cc_1599100000_CUkupo", O_RDONLY) = -1 EACCES (Permission > >denied) > > Are you sure you don't have SELinux really running and enabled? > > Because the following output makes me really worry: > >> [root at replicahostname /tmp]# ll -Za > >> drwxrwxrwt. root root system_u:object_r:tmp_t:s0 . > >> dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. > >> -rw------- rkelly rkelly ? .bash_history > >> drwxrwxrwt root root ? .ICE-unix > >> drwxrwxr-x rkelly rkelly ? .ipa > >> -r-------- root root ? krb5cc_0 > >> -r-------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd > >> -r-------- rkelly rkelly ? krb5cc_1599100000_CUkupo > >> -r-------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 > These rkelly:rkelly krb5cc_* files have no SELinux label and should be > readable to the owner. > > Can you show: > > [root] # sestatus > [root] # audit2why -b -w -t avc > > > -- > / Alexander Bokovoy > > > This document is strictly confidential and intended only for use by the > addressee unless otherwise stated. If you are not the intended recipient, > please notify the sender immediately and delete it from your system. > See you at 2014 Air Transport IT Summit, 17-19 June 2014 > > Click here to register http://www.sitasummit.aero > > From Rashard.Kelly at sita.aero Fri Apr 11 15:22:55 2014 From: Rashard.Kelly at sita.aero (Rashard.Kelly at sita.aero) Date: Fri, 11 Apr 2014 11:22:55 -0400 Subject: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials In-Reply-To: <20140411135426.GL27972@localhost.localdomain> References: <20140410072546.GU20958@redhat.com> <20140410161015.GH27972@localhost.localdomain> <20140410184402.GI27972@localhost.localdomain> <20140411130648.GX20958@redhat.com> <20140411135426.GL27972@localhost.localdomain> Message-ID: I changed the permissions to world readable to test, afterward I changed it back to be readable only by the owner. The problem then reappeared. [rkelly at replicahostname ~]$ ls -lZa| grep krb -r-------- root root ? krb5cc_0 -r-------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd -r-------- rkelly rkelly ? krb5cc_1599100000_CUkupo -r-------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 -r-------- apache apache ? krb5cc_48 [rkelly at replicahostname ~]$ od /tmp/krb5cc_1599100000_CUkupo od: /tmp/krb5cc_1599100000_CUkupo: Permission denied Thank You, Rashard Kelly SITA Senior Linux Specialist From: Sumit Bose To: Rashard.Kelly at sita.aero Cc: Alexander Bokovoy , freeipa-users at redhat.com Date: 04/11/2014 09:54 AM Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials On Fri, Apr 11, 2014 at 09:42:41AM -0400, Rashard.Kelly at sita.aero wrote: > [root at replicahostname ~]# sestatus > SELinux status: disabled > [root at replicahostname ~]# audit2why -b -w -t avc > [root at replicahostname ~]# > > > Nothing in the audit log after audit2why came back either. That's odd. Can you read the file with od? od /tmp/krb5cc_1599100000_CUkupo don't send the output just check if it is readable of if od returns an error as well? Are there any odd filesystem permission on your klist binary like s-bit set? ls -alZ $(which klist) (her you can send the output :-) bye, Sumit > > > Thank You, > Rashard Kelly > > > > From: Alexander Bokovoy > To: Rashard.Kelly at sita.aero > Cc: Sumit Bose , freeipa-users at redhat.com > Date: 04/11/2014 09:06 AM > Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos > credentials > > > > On Fri, 11 Apr 2014, Rashard.Kelly at sita.aero wrote: > >futex(0x7f0e2e1462c0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 > >open("/tmp/krb5cc_1599100000_CUkupo", O_RDONLY) = -1 EACCES (Permission > >denied) > > Are you sure you don't have SELinux really running and enabled? > > Because the following output makes me really worry: > >> [root at replicahostname /tmp]# ll -Za > >> drwxrwxrwt. root root system_u:object_r:tmp_t:s0 . > >> dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. > >> -rw------- rkelly rkelly ? .bash_history > >> drwxrwxrwt root root ? .ICE-unix > >> drwxrwxr-x rkelly rkelly ? .ipa > >> -r-------- root root ? krb5cc_0 > >> -r-------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd > >> -r-------- rkelly rkelly ? krb5cc_1599100000_CUkupo > >> -r-------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 > These rkelly:rkelly krb5cc_* files have no SELinux label and should be > readable to the owner. > > Can you show: > > [root] # sestatus > [root] # audit2why -b -w -t avc > > > -- > / Alexander Bokovoy > > > This document is strictly confidential and intended only for use by the > addressee unless otherwise stated. If you are not the intended recipient, > please notify the sender immediately and delete it from your system. > See you at 2014 Air Transport IT Summit, 17-19 June 2014 > > Click here to register http://www.sitasummit.aero > > This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. See you at 2014 Air Transport IT Summit, 17-19 June 2014 Click here to register http://www.sitasummit.aero -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Fri Apr 11 15:49:32 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 11 Apr 2014 17:49:32 +0200 Subject: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials In-Reply-To: References: <20140410161015.GH27972@localhost.localdomain> <20140410184402.GI27972@localhost.localdomain> <20140411130648.GX20958@redhat.com> <20140411135426.GL27972@localhost.localdomain> Message-ID: <20140411154931.GG21725@mail.corp.redhat.com> On (11/04/14 11:22), Rashard.Kelly at sita.aero wrote: >I changed the permissions to world readable to test, afterward I changed >it back to be readable only by the owner. The problem then reappeared. > >[rkelly at replicahostname ~]$ ls -lZa| grep krb >-r-------- root root ? krb5cc_0 >-r-------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd >-r-------- rkelly rkelly ? krb5cc_1599100000_CUkupo >-r-------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 >-r-------- apache apache ? krb5cc_48 >[rkelly at replicahostname ~]$ od /tmp/krb5cc_1599100000_CUkupo >od: /tmp/krb5cc_1599100000_CUkupo: Permission denied > >Thank You, >Rashard Kelly >SITA Senior Linux Specialist > I am not sure it will help with disabled selinux, but you can try to restore selinux context restorecon -R /tmp/ Can you remove 2nd ccache file /tmp/krb5cc_1599100000_ZekyY0 as user rkelly? LS From sbose at redhat.com Fri Apr 11 15:57:54 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 11 Apr 2014 17:57:54 +0200 Subject: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials In-Reply-To: References: <20140410161015.GH27972@localhost.localdomain> <20140410184402.GI27972@localhost.localdomain> <20140411130648.GX20958@redhat.com> <20140411135426.GL27972@localhost.localdomain> Message-ID: <20140411155754.GM27972@localhost.localdomain> On Fri, Apr 11, 2014 at 11:22:55AM -0400, Rashard.Kelly at sita.aero wrote: > I changed the permissions to world readable to test, afterward I changed > it back to be readable only by the owner. The problem then reappeared. > > [rkelly at replicahostname ~]$ ls -lZa| grep krb > -r-------- root root ? krb5cc_0 > -r-------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd > -r-------- rkelly rkelly ? krb5cc_1599100000_CUkupo > -r-------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 > -r-------- apache apache ? krb5cc_48 > [rkelly at replicahostname ~]$ od /tmp/krb5cc_1599100000_CUkupo > od: /tmp/krb5cc_1599100000_CUkupo: Permission denied hm, either your filesystem is broken or there is an issue with duplicate UIDs. Can you check if the filesystem UID matches yours: stat krb5cc_1599100000_CUkupo should show the numerial UID for the file and id will show yours. HTH bye, Sumit > > Thank You, > Rashard Kelly > SITA Senior Linux Specialist > > > > > From: Sumit Bose > To: Rashard.Kelly at sita.aero > Cc: Alexander Bokovoy , freeipa-users at redhat.com > Date: 04/11/2014 09:54 AM > Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos > credentials > > > > On Fri, Apr 11, 2014 at 09:42:41AM -0400, Rashard.Kelly at sita.aero wrote: > > [root at replicahostname ~]# sestatus > > SELinux status: disabled > > [root at replicahostname ~]# audit2why -b -w -t avc > > [root at replicahostname ~]# > > > > > > Nothing in the audit log after audit2why came back either. > > That's odd. Can you read the file with od? > > od /tmp/krb5cc_1599100000_CUkupo > > don't send the output just check if it is readable of if od returns an > error as well? > > Are there any odd filesystem permission on your klist binary like s-bit > set? > > ls -alZ $(which klist) > > (her you can send the output :-) > > bye, > Sumit > > > > > > Thank You, > > Rashard Kelly > > > > > > > > From: Alexander Bokovoy > > To: Rashard.Kelly at sita.aero > > Cc: Sumit Bose , freeipa-users at redhat.com > > Date: 04/11/2014 09:06 AM > > Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos > > > credentials > > > > > > > > On Fri, 11 Apr 2014, Rashard.Kelly at sita.aero wrote: > > >futex(0x7f0e2e1462c0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 > > >open("/tmp/krb5cc_1599100000_CUkupo", O_RDONLY) = -1 EACCES (Permission > > >denied) > > > > Are you sure you don't have SELinux really running and enabled? > > > > Because the following output makes me really worry: > > >> [root at replicahostname /tmp]# ll -Za > > >> drwxrwxrwt. root root system_u:object_r:tmp_t:s0 . > > >> dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. > > >> -rw------- rkelly rkelly ? .bash_history > > >> drwxrwxrwt root root ? .ICE-unix > > >> drwxrwxr-x rkelly rkelly ? .ipa > > >> -r-------- root root ? krb5cc_0 > > >> -r-------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd > > >> -r-------- rkelly rkelly ? krb5cc_1599100000_CUkupo > > >> -r-------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 > > These rkelly:rkelly krb5cc_* files have no SELinux label and should be > > readable to the owner. > > > > Can you show: > > > > [root] # sestatus > > [root] # audit2why -b -w -t avc > > > > > > -- > > / Alexander Bokovoy > > > > > > This document is strictly confidential and intended only for use by the > > addressee unless otherwise stated. If you are not the intended > recipient, > > please notify the sender immediately and delete it from your system. > > See you at 2014 Air Transport IT Summit, 17-19 June 2014 > > > > Click here to register http://www.sitasummit.aero > > > > > > > This document is strictly confidential and intended only for use by the > addressee unless otherwise stated. If you are not the intended recipient, > please notify the sender immediately and delete it from your system. > See you at 2014 Air Transport IT Summit, 17-19 June 2014 > > Click here to register http://www.sitasummit.aero > > From rcritten at redhat.com Fri Apr 11 17:38:43 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Apr 2014 13:38:43 -0400 Subject: [Freeipa-users] Rekey Self-signed CA In-Reply-To: <023CB99A-F32E-4121-8224-7D661464F403@teamexpansion.org> References: <0C120FD1-DFE1-46B7-BA5F-5F64C058C823@teamexpansion.org> <53470D21.9040704@redhat.com> <534737AD.4060101@redhat.com> <023CB99A-F32E-4121-8224-7D661464F403@teamexpansion.org> Message-ID: <534828A3.5090209@redhat.com> Greg Harris wrote: >> No worries then. The IPA CA (dogtag) uses NSS for crypto so there is no way the CA private key could have been exposed. >> >> If you've issued SSL certs from the IPA CA for services running OpenSSL you could re-issue those to be on the safe side, but IPA itself uses only NSS on its servers. >> >> rob >> > Ok, that makes sense. I figured out that the back end, dogtag, was using NSS, but it looked like the web GUI was using OpenSSL. Re-issuing SSL certs for services looks simple enough through the GUI. Thanks for your help. The GUI uses NSS as well, via mod_nss. We use OpenSSL for some client libraries in IPA, but so far no servers. We dodged a bullet there. > All that aside, is there a way to rekey the IPA CA? I?d hate to see the same type of vulnerability announced next week for NSS and not have any recourse. No. You don't re-key a CA, you create a new one. If the CA private key is exposed then it's game over. We don't currently provide a way to rip out the CA and install a replacement. I'm going to get my thoughts together and file an IPA ticket to look into that. It is a non-trivial thing though, and with replication it only gets more interesting. rob From Rashard.Kelly at sita.aero Fri Apr 11 17:41:02 2014 From: Rashard.Kelly at sita.aero (Rashard.Kelly at sita.aero) Date: Fri, 11 Apr 2014 13:41:02 -0400 Subject: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials (SOLVED) In-Reply-To: <20140411155754.GM27972@localhost.localdomain> References: <20140410161015.GH27972@localhost.localdomain> <20140410184402.GI27972@localhost.localdomain> <20140411130648.GX20958@redhat.com> <20140411135426.GL27972@localhost.localdomain> <20140411155754.GM27972@localhost.localdomain> Message-ID: Thank you so much, it was the user id. There was an account with the same user name leftover from a previous effort. Thanks to everyone for the time. Thank You, Rashard Kelly From: Sumit Bose To: Rashard.Kelly at sita.aero Cc: Alexander Bokovoy , freeipa-users at redhat.com Date: 04/11/2014 11:58 AM Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials On Fri, Apr 11, 2014 at 11:22:55AM -0400, Rashard.Kelly at sita.aero wrote: > I changed the permissions to world readable to test, afterward I changed > it back to be readable only by the owner. The problem then reappeared. > > [rkelly at replicahostname ~]$ ls -lZa| grep krb > -r-------- root root ? krb5cc_0 > -r-------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd > -r-------- rkelly rkelly ? krb5cc_1599100000_CUkupo > -r-------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 > -r-------- apache apache ? krb5cc_48 > [rkelly at replicahostname ~]$ od /tmp/krb5cc_1599100000_CUkupo > od: /tmp/krb5cc_1599100000_CUkupo: Permission denied hm, either your filesystem is broken or there is an issue with duplicate UIDs. Can you check if the filesystem UID matches yours: stat krb5cc_1599100000_CUkupo should show the numerial UID for the file and id will show yours. HTH bye, Sumit > > Thank You, > Rashard Kelly > SITA Senior Linux Specialist > > > > > From: Sumit Bose > To: Rashard.Kelly at sita.aero > Cc: Alexander Bokovoy , freeipa-users at redhat.com > Date: 04/11/2014 09:54 AM > Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos > credentials > > > > On Fri, Apr 11, 2014 at 09:42:41AM -0400, Rashard.Kelly at sita.aero wrote: > > [root at replicahostname ~]# sestatus > > SELinux status: disabled > > [root at replicahostname ~]# audit2why -b -w -t avc > > [root at replicahostname ~]# > > > > > > Nothing in the audit log after audit2why came back either. > > That's odd. Can you read the file with od? > > od /tmp/krb5cc_1599100000_CUkupo > > don't send the output just check if it is readable of if od returns an > error as well? > > Are there any odd filesystem permission on your klist binary like s-bit > set? > > ls -alZ $(which klist) > > (her you can send the output :-) > > bye, > Sumit > > > > > > Thank You, > > Rashard Kelly > > > > > > > > From: Alexander Bokovoy > > To: Rashard.Kelly at sita.aero > > Cc: Sumit Bose , freeipa-users at redhat.com > > Date: 04/11/2014 09:06 AM > > Subject: Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos > > > credentials > > > > > > > > On Fri, 11 Apr 2014, Rashard.Kelly at sita.aero wrote: > > >futex(0x7f0e2e1462c0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 > > >open("/tmp/krb5cc_1599100000_CUkupo", O_RDONLY) = -1 EACCES (Permission > > >denied) > > > > Are you sure you don't have SELinux really running and enabled? > > > > Because the following output makes me really worry: > > >> [root at replicahostname /tmp]# ll -Za > > >> drwxrwxrwt. root root system_u:object_r:tmp_t:s0 . > > >> dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. > > >> -rw------- rkelly rkelly ? .bash_history > > >> drwxrwxrwt root root ? .ICE-unix > > >> drwxrwxr-x rkelly rkelly ? .ipa > > >> -r-------- root root ? krb5cc_0 > > >> -r-------- xs05144 xs05144 ? krb5cc_1599000020_u5RRhd > > >> -r-------- rkelly rkelly ? krb5cc_1599100000_CUkupo > > >> -r-------- rkelly rkelly ? krb5cc_1599100000_ZekyY0 > > These rkelly:rkelly krb5cc_* files have no SELinux label and should be > > readable to the owner. > > > > Can you show: > > > > [root] # sestatus > > [root] # audit2why -b -w -t avc > > > > > > -- > > / Alexander Bokovoy > > > > > > This document is strictly confidential and intended only for use by the > > addressee unless otherwise stated. If you are not the intended > recipient, > > please notify the sender immediately and delete it from your system. > > See you at 2014 Air Transport IT Summit, 17-19 June 2014 > > > > Click here to register http://www.sitasummit.aero > > > > > > > This document is strictly confidential and intended only for use by the > addressee unless otherwise stated. If you are not the intended recipient, > please notify the sender immediately and delete it from your system. > See you at 2014 Air Transport IT Summit, 17-19 June 2014 > > Click here to register http://www.sitasummit.aero > > This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. See you at 2014 Air Transport IT Summit, 17-19 June 2014 Click here to register http://www.sitasummit.aero -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Fri Apr 11 20:22:01 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Fri, 11 Apr 2014 20:22:01 +0000 Subject: [Freeipa-users] External Collaboration Domains In-Reply-To: <534729DA.2070003@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net> <20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net> <20140330182619.GA19628@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net> <53389BEA.9050905@redhat.com> <20140408133456.GR20958@redhat.com> <5343FCC6.10209@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A7E8E@001FSN2MPN1-045.001f.mgd2.msft.net> <534489E9.9090809@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8756@001FSN2MPN1-045.001f.mgd2.msft.net> <534729DA.2070003@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E6A8B5B@001FSN2MPN1-045.001f.mgd2.msft.net> > I guess we just do not see this scenario in practice yet. What I've found in the last decade is that scientists and CIO types cannot talk for lack of a common language. CIO types believe in closed systems over which they have complete control. Scientists are funded to work with others from other organizations. This is how they bring money into the organization, advance their careers, and perform the business of the agency. Talking exclusively with CIO types will actively prevent enterprise support of this collaboration domain notion from ever coming into practice. They will need ready to deploy tools in order to support this. Currently, standard practice is to kick us off the corporate network completely and hope we obey the tomes of security literature in our copious amounts of free time. We've been doing it forever. But it's been treated as exceptions to the rule by the CIO, instead of "this is how they operate all the time". Hence, it's been at the small scale because it's been handled individually by members of every single project, few of whom have any patience for learning ldap or Kerberos. > The users that come from an external realm would come via SAML or similar > and interact with a service provided by the local realm. In this case an > external user needs to be mapped to the role by the service. Here's where I don't think we're connecting. Services in the local realm include console logins via ssh, a stand alone processing box which the external user needs to tend, access to workgroup-scale HPC resources, or an sftp/nfs server. Collaboration is not limited to web services. Actually, if you asked me to come up with a real world example where collaboration happened only via web based services, I wouldn't be able to do it. We're always sharing code, setting up processing servers, setting up a shared data repository, etc. Web based services may play a big role, but it's never been the exclusive mechanism to my memory. > Sorry I have a mindset that suggest that allowing external users to auto- > materialize in my internal enterprise domain servicing my infa is a bad idea. > May be it comes from the deep belief that the role of IdM is to only serve > local identities inside the local namespace and federate with other > namespaces using trusts or SAML and similar. I'm not sure we're disagreeing. However, unless you also believe that the role of the IdM is also to hobble the local realm such that it is only capable of supporting collaboration via web based services, something has to provide UID/SID/GID for external users. You cannot assume these are maintained elsewhere (i.e., if the user's home realm is SAML, OpenID, or vanilla Kerberos). Any synthesized UID/SID/GID parameters are contained within the local realm and do not apply in the realm of origin. The IdM is still serving the purpose you envision. It cannot authenticate these external users and does not manage their passwords. It just makes sure that the necessary attributes are present within the local realm, and that the set of necessary attributes is self consistent. These suggestions are for an explicitly created collaboration realm which has a one-way trust from the host organization's internal infra to the collaboration domain. Nothing will "auto-materialize" on the internal corporate network. None of these services are offered on the internal corporate network. > Can you give me an example of a real world scenario when a local domain > would welcome user accounts to be synthesized out of the thin air? A] It's not out of thin air. Proof of identity must be established via Kerberos trust, PKINIT or authentication against an external identity provider (SAML/OpenID). I'd want control over whether the realm is setup with a whitelist or a blacklist of IdPs, and what's on that list. B (background)] My organization operates an Enterprise AD as well as two SAML identity sources. Getting someone in AD involves paperwork, a 4-6 month delay, and background checks, conferring on them full privileges to the enterprise network. In addition, AD is completely inaccessible to the cooperator unless we buy them a corporate imaged machine and require that they VPN in to the corporate network to get credentials for the public-facing collaboration realm. The SAML IdPs are segregated by the degree of assurance of the user's identity (level 1 is basically self registration with an email account; level 2 is you show up at a USDA service center with your driver's license, and you might also have to have a sponsor). Neither SAML credential permits access to the enterprise network. Our SAML IdPs are public-facing. So right off the bat, even if we're not part of a SAML federation, it's better to get cooperators SAML identities than AD identities because its more appropriate to the level of access they need and the means of access they possess...so long as they can ssh in, share files, and participate in groups. C] If I am trying to ssh into one of our collaboration resources when I'm visiting a collaborator, I'm forced to use my SAML credentials because I can't reach AD. Because we will not be synchronizing all users against our SAML IdPs, my SAML account must be autocreated. D] Assuming I can persuade USDA to join the InCommon SAML federation, I'd want user accounts to be autocreated in our collaboration realm based on SAML credentials. We will not be synchronizing IPA external users against the union of all accounts in all IdPs in the federation, so external users must be autocreated. E] Users from our own AD should be recognized, but not as a "lump". Each user needs to be able to join groups in the collaboration realm individually. This would require creating a DN for them in LDAP (according to the IdM docs). It's not desirable to replicate all 50000 users from AD to IPA, just the ones who actually connect and use services, so the users who choose to connect must be autocreated. F] Users from SAML/OpenID based sources also need to participate in groups, for this they need a DN and therefore must be autocreated. G] Users holding valid grid computing credentials (also kx509 certificates) should be autocreated. (again, admin control over whitelist or blacklist of IdPs would be desirable.) Again, they need to be able to participate in groups, requiring a DN, requiring autocreation. Note that all the above represents authentication. Individual machines and services will be configured by the system owners for authorization. (e.g., before sshing from a collaborator's facility, I'd have to set my machine up to authorize my SAML credentials.) Also note that nearly everyone is an external user to this collaboration domain, even the users managed by the host organization. Yes, we do have a collaboration domain in real life (limited to me, our research group and about 100 explicitly managed external users). Yes our CIO is evaluating how to support such an activity at scale. No, the solution I describe here is not implemented. This is my wish list after doing this for a decade and creating accounts on individual machines. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From dpal at redhat.com Fri Apr 11 21:58:25 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 11 Apr 2014 17:58:25 -0400 Subject: [Freeipa-users] External Collaboration Domains In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E6A8B5B@001FSN2MPN1-045.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net> <20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net> <20140330182619.GA19628@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net> <53389BEA.9050905@redhat.com> <20140408133456.GR20958@redhat.com> <5343FCC6.10209@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A7E8E@001FSN2MPN1-045.001f.mgd2.msft.net> <534489E9.9090809@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8756@001FSN2MPN1-045.001f.mgd2.msft.net> <534729DA.2070003@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8B5B@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <53486581.9020906@redhat.com> On 04/11/2014 04:22 PM, Nordgren, Bryce L -FS wrote: >> I guess we just do not see this scenario in practice yet. > What I've found in the last decade is that scientists and CIO types cannot talk for lack of a common language. CIO types believe in closed systems over which they have complete control. Scientists are funded to work with others from other organizations. This is how they bring money into the organization, advance their careers, and perform the business of the agency. Talking exclusively with CIO types will actively prevent enterprise support of this collaboration domain notion from ever coming into practice. They will need ready to deploy tools in order to support this. Currently, standard practice is to kick us off the corporate network completely and hope we obey the tomes of security literature in our copious amounts of free time. > > We've been doing it forever. But it's been treated as exceptions to the rule by the CIO, instead of "this is how they operate all the time". Hence, it's been at the small scale because it's been handled individually by members of every single project, few of whom have any patience for learning ldap or Kerberos. We do not have much experience with setups and workflows as you describe. We are mostly serving the CIO's vision of "inside is my namespace". OK so I think now I am ready to define a use case based on what you are describing. There is a groups pf people that belong to different organizations, for example universities that launch a project together. They have the identities in their own home organization (domains). There is a "hosting" organization that some of the members of the group might belong to. Jointly all the users want to be able to access the systems that belong to the project, this includes login into the systems accessing file shares and web applications that constitute the joint project. They also want to be able to SSO as much as possible without creating additional identities and having a separate password. The home organization in this case would have trust relations with the hosting organization. The goal is to make it possible for the home organization to understand external identities accessing resources on the file system level thus POSIX attributes need to be generated, assigned and managed for those users. Does it sound about right? It this the problem we are solving? >> The users that come from an external realm would come via SAML or similar >> and interact with a service provided by the local realm. In this case an >> external user needs to be mapped to the role by the service. > Here's where I don't think we're connecting. Services in the local realm include console logins via ssh, a stand alone processing box which the external user needs to tend, access to workgroup-scale HPC resources, or an sftp/nfs server. I took a note of this when I wrote the use case above. Frankly this is the first time I hear about such case or more that IPA is relevant is such setups. May be it is finally grew to become relevant to reach new horizons. > > Collaboration is not limited to web services. Actually, if you asked me to come up with a real world example where collaboration happened only via web based services, I wouldn't be able to do it. Any Saas application. Google docs for enterprise, SFDC etc. > We're always sharing code, setting up processing servers, setting up a shared data repository, etc. Web based services may play a big role, but it's never been the exclusive mechanism to my memory. OK, note taken. I wonder though how common is this scenario/use case. The fact that we hear about it for the first time and having hard time understanding the use case makes me think that it is yet not that common. We would need to see what is the dynamics though and whether the world is moving towards or away from this case becoming a popular one. But assume it is. > >> Sorry I have a mindset that suggest that allowing external users to auto- >> materialize in my internal enterprise domain servicing my infa is a bad idea. >> May be it comes from the deep belief that the role of IdM is to only serve >> local identities inside the local namespace and federate with other >> namespaces using trusts or SAML and similar. > I'm not sure we're disagreeing. However, unless you also believe that the role of the IdM is also to hobble the local realm such that it is only capable of supporting collaboration via web based services, something has to provide UID/SID/GID for external users. You cannot assume these are maintained elsewhere (i.e., if the user's home realm is SAML, OpenID, or vanilla Kerberos). Any synthesized UID/SID/GID parameters are contained within the local realm and do not apply in the realm of origin. The IdM is still serving the purpose you envision. It cannot authenticate these external users and does not manage their passwords. It just makes sure that the necessary attributes are present within the local realm, and that the set of necessary attributes is self consistent. > > These suggestions are for an explicitly created collaboration realm which has a one-way trust from the host organization's internal infra to the collaboration domain. Nothing will "auto-materialize" on the internal corporate network. None of these services are offered on the internal corporate network. OK. Let be paraphrase so that I understand (referring to the use case I mentioned above). Home organization will set a special IPA based domain for every external organization. It will be one way trusted but the hosting organization. This special "collaboration" domain will be the one where the entries are automatically created when external user comes in, right? I am not sure I understand the authentication workflow in this case but may be it is listed below... > >> Can you give me an example of a real world scenario when a local domain >> would welcome user accounts to be synthesized out of the thin air? > A] It's not out of thin air. Proof of identity must be established via Kerberos trust, PKINIT or authentication against an external identity provider (SAML/OpenID). I'd want control over whether the realm is setup with a whitelist or a blacklist of IdPs, and what's on that list. This is where I have a bit of a problem because we have a protocol mixture. I can understand if an external user access a web application (lab control like OpenStack or something like) to launch a VM or a job. In this case he can be authenticated against external trusted IdP via SAML or such but then his POSIX attributes are not needed. If this user then tries to SSH into the system there are three options: a) Use user name and password - but this means that user needs to have an account in the hosting domain this he is effectively just added to the hosting domain as a full account b) There is a Kerberos SSO - but then his home domain needs to be trusted by his hosting domain. If it is possible the solution based on trusts exists. But I suspect CIOs do not like it ;-) so it is unlikely would be done in real life. c) SSH keys or Certs - they need to at least be uploaded and trusted by the hosting realm but they can be managed by hosting realm too and given to the user. There is no option to use SAML or OpenID with SSH but to get to the system on the system level you need to SSH. So until SSH supports SAML or similar the whole idea would not fly. > > B (background)] My organization operates an Enterprise AD as well as two SAML identity sources. Getting someone in AD involves paperwork, a 4-6 month delay, and background checks, conferring on them full privileges to the enterprise network. In addition, AD is completely inaccessible to the cooperator unless we buy them a corporate imaged machine and require that they VPN in to the corporate network to get credentials for the public-facing collaboration realm. The SAML IdPs are segregated by the degree of assurance of the user's identity (level 1 is basically self registration with an email account; level 2 is you show up at a USDA service center with your driver's license, and you might also have to have a sponsor). Neither SAML credential permits access to the enterprise network. Our SAML IdPs are public-facing. So right off the bat, even if we're not part of a SAML federation, it's better to get cooperators SAML identities than AD identities because its more appropriate to the level of access they need and the means of access they possess...so long as they can ssh in, share files, and participate in groups. There is where I see a leap of faith. SAML -> SSH. It is not possible. And I am not sure OpenSSH would be interested to support it. They had hard time supporting Certs. > C] If I am trying to ssh into one of our collaboration resources when I'm visiting a collaborator, I'm forced to use my SAML credentials because I can't reach AD. Because we will not be synchronizing all users against our SAML IdPs, my SAML account must be autocreated. The account can be created but the local password has to be created too. In this case you are just a local user that can also federate from external. If we admin that we can't make a leap of faith then we get to the scenario: a) Once has to register external users and give them local passwords. b) These accounts can be linked to the external IdPs so that if the user comes from the external source using SAML then he is trusted and mapped to his local account. IMO this will be possible with the technologies or projects currently being worked on: Ipsilon, apache modules, gss proxy etc. The only part that is not covered is user provisioning. I would think that user provisioning would be a good RFE for Ipsilon. To support mapping or local users to the external IdPs we would need Ipsilon to not only create but be able to map external identities to internal identities. Here is how it might work: User from a remote domain hits a service in the hosting domain for the first time. Service redirects to Ipsilon IdP for assertion. Ipsilon redirects back to Org IdP to provide assertion or authenticate using OpenID (or like) The dome domain presents a proof of the authentication. Ipsilon sees that this is a trusted users and does a lookup in the home domain. The user is not found. Ipsilon creates user and save the mapping of this user to the external identity source in additional attributes. It then issues an internal SAML assertion for the newly created identity and redirects user to the application. Application checks that it is an assertion from Ipsilon and lets user in. If user then tries to SSH he is asked to change and set his password and no he is a full user that can access the hosting domain (it might be collaboration domain as you call it) both ways. The next time user uses the service there will be the same workflow but the entry will be found and thus the assertion will be issued right away. I think it makes sense. It is just a bit down the road for Ipsilon. We have not been drilling down in this direction but IMO it is possible. I would like to hear Simo's opinion on this matter. > > D] Assuming I can persuade USDA to join the InCommon SAML federation, I'd want user accounts to be autocreated in our collaboration realm based on SAML credentials. We will not be synchronizing IPA external users against the union of all accounts in all IdPs in the federation, so external users must be autocreated. I think I described it above. IMO IdP is the better place for this not the KDC. > > E] Users from our own AD should be recognized, but not as a "lump". Each user needs to be able to join groups in the collaboration realm individually. This would require creating a DN for them in LDAP (according to the IdM docs). It's not desirable to replicate all 50000 users from AD to IPA, just the ones who actually connect and use services, so the users who choose to connect must be autocreated. OK. Makes sense. Since I do not expect that the domains would really be accessible over Ldap and Kerberos directly relying on SAML would be the solution to pursue. > > F] Users from SAML/OpenID based sources also need to participate in groups, for this they need a DN and therefore must be autocreated. :-) ^ > > G] Users holding valid grid computing credentials (also kx509 certificates) should be autocreated. (again, admin control over whitelist or blacklist of IdPs would be desirable.) Again, they need to be able to participate in groups, requiring a DN, requiring autocreation. OK. but the kx509 certs from which CA? I assume that we are talking about collaboration CA, so there is really no relation to the home domain and home CA. > > Note that all the above represents authentication. Individual machines and services will be configured by the system owners for authorization. (e.g., before sshing from a collaborator's facility, I'd have to set my machine up to authorize my SAML credentials.) Also note that nearly everyone is an external user to this collaboration domain, even the users managed by the host organization. > > Yes, we do have a collaboration domain in real life (limited to me, our research group and about 100 explicitly managed external users). Yes our CIO is evaluating how to support such an activity at scale. No, the solution I describe here is not implemented. This is my wish list after doing this for a decade and creating accounts on individual machines. OK this all makes sense. The only difference in the views is that IMO this auto creation is not a function of IPA's KDC but rather of the external IdP like Ipsilon that has the while list and black list and for the identities coming from white list sources it can optionaly issue user add command. I think we are on the right path to enable what you are looking for just doing it slightly differently from what you are suggesting. Based on this discussion I suggest we open an RFE and plan for it when we have: 1) IPA <-> IPA trusts 2) Ipsilon implemented. Then we would be able to combine the two, add a call for provisioning and finally help you solve the problem you are interested in solving. Are you interested in helping with moving 1) or 2) forward as a prerequisite for the ultimate goal? Thanks Dmitri > Bryce > > > > > This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From simo at redhat.com Fri Apr 11 22:50:23 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 11 Apr 2014 18:50:23 -0400 Subject: [Freeipa-users] External Collaboration Domains In-Reply-To: <53486581.9020906@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net> <20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net> <20140330182619.GA19628@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net> <53389BEA.9050905@redhat.com> <20140408133456.GR20958@redhat.com> <5343FCC6.10209@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A7E8E@001FSN2MPN1-045.001f.mgd2.msft.net> <534489E9.9090809@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8756@001FSN2MPN1-045.001f.mgd2.msft.net> <534729DA.2070003@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8B5B@001FSN2MPN1-045.001f.mgd2.msft.net> <53486581.9020906@redhat.com> Message-ID: <1397256623.19767.142.camel@willson.li.ssimo.org> On Fri, 2014-04-11 at 17:58 -0400, Dmitri Pal wrote: > > C] If I am trying to ssh into one of our collaboration resources > when I'm visiting a collaborator, I'm forced to use my SAML > credentials because I can't reach AD. Because we will not be > synchronizing all users against our SAML IdPs, my SAML account must be > autocreated. > > The account can be created but the local password has to be created > too. > In this case you are just a local user that can also federate from > external. > If we admin that we can't make a leap of faith then we get to the > scenario: > > a) Once has to register external users and give them local passwords. > b) These accounts can be linked to the external IdPs so that if the > user > comes from the external source using SAML then he is trusted and > mapped > to his local account. > > IMO this will be possible with the technologies or projects currently > being worked on: Ipsilon, apache modules, gss proxy etc. > The only part that is not covered is user provisioning. I would think > that user provisioning would be a good RFE for Ipsilon. > To support mapping or local users to the external IdPs we would need > Ipsilon to not only create but be able to map external identities to > internal identities. > > Here is how it might work: > > User from a remote domain hits a service in the hosting domain for > the > first time. > Service redirects to Ipsilon IdP for assertion. > Ipsilon redirects back to Org IdP to provide assertion or > authenticate > using OpenID (or like) > The dome domain presents a proof of the authentication. > Ipsilon sees that this is a trusted users and does a lookup in the > home > domain. > The user is not found. > Ipsilon creates user and save the mapping of this user to the > external > identity source in additional attributes. > It then issues an internal SAML assertion for the newly created > identity > and redirects user to the application. > Application checks that it is an assertion from Ipsilon and lets user > in. > > If user then tries to SSH he is asked to change and set his password > and > no he is a full user that can access the hosting domain (it might be > collaboration domain as you call it) both ways. > > The next time user uses the service there will be the same workflow > but > the entry will be found and thus the assertion will be issued right > away. > > I think it makes sense. > It is just a bit down the road for Ipsilon. We have not been drilling > down in this direction but IMO it is possible. > I would like to hear Simo's opinion on this matter. I assume this could be done, to some degree. With SAML you wouldn't be able to check anything in the user's own SAML IdP unless the 2 organizations Idp's have been previously linked. With OpenID connect it may be possible to pull information if the other organization system allows their users to trust arbitrary applications, but it may not be always allowed. The main issue I see is that this would only allow to create a user, but it is unclear to me how this would allow SSO, we could store a cookie with the user's name from the Idp, so that if the user uses always the same browser it may be automatically chained to its Idp of origin, otherwise at least a username or password will have to be provided by the user. > It is indeed a bit down the road, but we can start thinking about these scenarios now ... from the POV of Ipsilon this chaining and cookie and all would basically just be a login plugin, shouldn't require any additional code in the core. Simo. -- Simo Sorce * Red Hat, Inc * New York From bnordgren at fs.fed.us Sat Apr 12 00:47:49 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Sat, 12 Apr 2014 00:47:49 +0000 Subject: [Freeipa-users] External Collaboration Domains In-Reply-To: <53486581.9020906@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net> <20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net> <20140330182619.GA19628@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net> <53389BEA.9050905@redhat.com> <20140408133456.GR20958@redhat.com> <5343FCC6.10209@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A7E8E@001FSN2MPN1-045.001f.mgd2.msft.net> <534489E9.9090809@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8756@001FSN2MPN1-045.001f.mgd2.msft.net> <534729DA.2070003@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8B5B@001FSN2MPN1-045.001f.mgd2.msft.net> <53486581.9020906@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E6A8C10@001FSN2MPN1-045.001f.mgd2.msft.net> > There is a groups pf people that belong to different organizations, for > example universities that launch a project together. They have the identities > in their own home organization (domains). There is a "hosting" organization > that some of the members of the group might belong to. Jointly all the users > want to be able to access the systems that belong to the project, this > includes login into the systems accessing file shares and web applications that > constitute the joint project. They also want to be able to SSO as much as > possible without creating additional identities and having a separate > password. The home organization in this case would have trust relations with > the hosting organization. > The goal is to make it possible for the home organization to understand > external identities accessing resources on the file system level thus POSIX > attributes need to be generated, assigned and managed for those users. > > > Does it sound about right? It this the problem we are solving? Perfect. I'll make a new wiki page with that text and pictures tomorrow. :) > > Collaboration is not limited to web services. Actually, if you asked me to > come up with a real world example where collaboration happened only via > web based services, I wouldn't be able to do it. > > Any Saas application. > Google docs for enterprise, SFDC etc. True. However, I've never been part of a project where these are all you need. These things do play a role, but aren't comprehensive. > OK, note taken. I wonder though how common is this scenario/use case. > The fact that we hear about it for the first time and having hard time > understanding the use case makes me think that it is yet not that common. > We would need to see what is the dynamics though and whether the world > is moving towards or away from this case becoming a popular one. > But assume it is. I think it's common at the small scale and typically addressed by individual projects renting dedicated servers at hosting farms. New accounts local to the machines are usually created. However, over the past ten years I've found that if I've set up "infrastructure", there's no shortage of people who want to leverage it. This tends to cause my tiny solution to scale up and out beyond what I'm willing to support. I suspect that if CIOs were given a notion of what kind of support to offer their users, you may see more demand for something like this. > OK. Let be paraphrase so that I understand (referring to the use case I > mentioned above). > > Home organization will set a special IPA based domain for every external > organization. It will be one way trusted but the hosting organization. > This special "collaboration" domain will be the one where the entries are > automatically created when external user comes in, right? Essentially. I was thinking "home organization" would set up a single IPA based domain with a one-way trust from the internal corporate infra. As you mention, this domain would be where the automatically created external users appear. This single collaboration domain would be the connection point for inter-organizational trusts (vanilla Kerberos/IPA/AD) and would host the identity gateway (Ipsilon). Is there a need for one domain per organization you want to collaborate with? > b) There is a Kerberos SSO - but then his home domain needs to be > trusted by his hosting domain. If it is possible the solution based on > trusts exists. But I suspect CIOs do not like it ;-) so it is unlikely > would be done in real life. Thinking 5 years down the line, if multiple participating organizations had collaboration domains, CIOs may be a little more promiscuous with the vanilla Kerberos trusts between them. Don't rule out Kerberos SSO just yet. :) > There is no option to use SAML or OpenID with SSH but to get to the > system on the system level you need to SSH. > So until SSH supports SAML or similar the whole idea would not fly. I wouldn't try to make all domain services aware of all identity technologies. Option d is use case 3 in the RFE. (Ipsilon obtains TGT for external user and forwards to client). The method of forwarding is what needs to be explored. It seemed to me that the method of getting the ticket from the KDC was fixed on s4u2user / s4u2proxy. However, the RFE is structured such that IPA is prepared to service foreign user requests from an Ipsilon-like HTTP gateway, or an RFC6595-like gssapi/saml acceptor or a RFC6616-like gssapl/openid acceptor. The resolution of the technical approach to use case three is not a blocker. > There is where I see a leap of faith. SAML -> SSH. It is not possible. > And I am not sure OpenSSH would be interested to support it. They had > hard time supporting Certs. No SAML->SSH. Even if it were possible, it would involve configuring every host in the domain individually. Ick. Browser->Gateway->TGT->Service TKT->SSH. Like normal. GSSAPI/OpenID->GSSAPI acceptor->TGT->Service TKT->SSH. Like normal. or GSSAPI/SAML->GSSAPI acceptor->TGT->Service TKT->SSH. Like normal. > The account can be created but the local password has to be created too. > In this case you are just a local user that can also federate from external. Gateway gets ticket using s4u2user / s4u2proxy. Forwards ticket. No password. :) > IMO this will be possible with the technologies or projects currently > being worked on: Ipsilon, apache modules, gss proxy etc. > The only part that is not covered is user provisioning. I would think > that user provisioning would be a good RFE for Ipsilon. External users need a presence in LDAP regardless of their origin (need to participate in groups). Ipsilon will not see external users from Kerberos trusts, including: * vanilla Kerberos trusts (all POSIX info needs to be synthesized) * AD trust (possibly needing POSIX attributes, possibly needing them remapped to avoid collisions). * TBD IPA trusts (possibly need POSIX attributes remapped to avoid collisions). IPA (specifically, the KDC) is the arbiter of all access to all services in the realm. There is no other single point of monitoring or control. > To support mapping or local users to the external IdPs we would need > Ipsilon to not only create but be able to map external identities to > internal identities. I believe external identities will need to be mapped to cname/crealm pairs. The mapped crealm will NOT be internal/local. I might be "bnordgren at SAML://idp.usda.gov/geeklogin/" The mapping should be universal so the authenticated user can cross Kerberos trusts without worrying that different realms map the ID differently. > Here is how it might work: > [...] > I think it makes sense. Your proposal requires creating a local account for the external user. If we were to accept the need to do that, would it not be simpler to kerberize the local webapps and the user would spnego/gssapi after kiniting? > > D] Assuming I can persuade USDA to join the InCommon SAML federation, > I'd want user accounts to be autocreated in our collaboration realm based on > SAML credentials. We will not be synchronizing IPA external users against the > union of all accounts in all IdPs in the federation, so external users must be > autocreated. > > I think I described it above. > IMO IdP is the better place for this not the KDC. I would be willing to accept this if you can show me how the IdP catches all the external users, not just the ones coming in from SAML or OpenID. I see a crack that my AD account will fall through. :) > > E] Users from our own AD should be recognized, but not as a "lump". Each > user needs to be able to join groups in the collaboration realm individually. > This would require creating a DN for them in LDAP (according to the IdM > docs). It's not desirable to replicate all 50000 users from AD to IPA, just the > ones who actually connect and use services, so the users who choose to > connect must be autocreated. > > OK. Makes sense. Since I do not expect that the domains would really be > accessible over Ldap and Kerberos directly relying on SAML would be the > solution to pursue. Kerberos is the least common denominator. It's also in the critical path. Nobody gets any services without a ticket. :) > OK. but the kx509 certs from which CA? I assume that we are talking > about collaboration CA, so there is really no relation to the home > domain and home CA. TBD. Configurable. Future. ;) Note if the realm was configured to accept kx509 from the home CA, it would allow the home domain's AD to stay behind the firewall while allowing me to access the collaboration realm from a partner's facility. > I think we are on the right path to enable what you are looking for just > doing it slightly differently from what you are suggesting. I'm patient. And I can deal with workarounds in the near term as long as they lead up to a long term solution. I do want the long term solution not to involve creating/managing local accounts (w/passwords and a local crealm) when a federated account exists. Also, I am not yet convinced that Ipsilon will catch external users coming in on Kerberos trusts. Plus, putting the creation of IPA external users in the hands of an external service would seem to bind IPA and Ipsilon together when they don't need to be. If Ipsilon were a generic HTTP IdP<->Kerberos gateway, it would also work for AD, for vanilla Kerberos domains, and for KRB/LDAP domains. I'm not sure I would choose that unless there were no other options. However, "running code wins". Make me something that works and I don't need to look to closely at it. :) > Based on this discussion I suggest we open an RFE and plan for it when > we have: > 1) IPA <-> IPA trusts > 2) Ipsilon > implemented. Then we would be able to combine the two, add a call for > provisioning and finally help you solve the problem you are interested > in solving. I'm not sure I understand how #1 factors into this plan? Did I miss that bit? > Are you interested in helping with moving 1) or 2) forward as a > prerequisite for the ultimate goal? Interest is rarely my problem; time is. :) Also, I need to wrap my head around things before coding. With regard to #1, I'm more or less itching to restructure trusts such that vanilla Kerberos is the general case, and IPA->AD, IPA->IPA, and IPA->KRB/LDAP are special cases where extra information may be available (email addy, gecos, sn, POSIX attrs etc.) For #2, I've been trying to find info on Ipsilon and failing. I have a vague notion that it's an HTTP gateway between web technologies and the Kerberos based IPA. Maybe I could interrogate someone and make a wiki page or three. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From fredy.sanchez at modmed.com Fri Apr 11 14:37:35 2014 From: fredy.sanchez at modmed.com (Fredy Sanchez) Date: Fri, 11 Apr 2014 10:37:35 -0400 Subject: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing. Message-ID: Hi all, We asked this same question at discussions.apple.com, but figured we'd have better luck here. I apologize in advance if this is the wrong forum. We are switching from Synology (DSM 5) to Mavericks server (v3.1.1. running in Mavericks 10.9.2) for File Sharing. We use a FreeIPA (ipa-server.x86_64 3.0.0-37.el6) backend for SSO, and the Mac server seems correctly bound to it. Unfortunately, although we can add usernames to the shares for the initial config, the usernames transform to UIDs after (only for SSO accounts; local accounts are not affected). That is, when we go to edit the permissions for a share, all we see are UIDs. We can always figure out the username from the UID, but this is an extra step we don't want to have. We've tried reinstalling the Mac server app from scratch, re-binding to the FreeIPA backend, changing mappings in Directory Utility (for example, mapping GeneratedUID to uid, which is the username), recreating the shares and permissions, etc. Here are more details about the binding: * The binding happens thru a custom package we created based primarily on http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 * Sys Prefs, Users & Groups, Login Options show the server bound to the FreeIPA backend with the green dot * The following mappings are in place in Directory Utility, Services, LDAPv3, FreeIPA backend Users: inetOrgPerson AuthenticationAuthority: uid GeneratedUID: random number in uppercase HomeDirectory: #/Users/$uid$ NFSHomeDirectory: #/Users/$uid$ OriginalHomeDirectory: #/Users/$uid$ PrimaryGroupID: gidNumber RealName: cn RecordName: uid UniqueID: uidNumber UserShell: loginShell Groups: posixgroup PrimaryGroupID: gidNumber RecordName: cn The search bases are correct * Directory Utility, Directory Editor shows the right info for the users. * $ id $USERNAME shows the right information for the user FreeIPA is working beautifully for our Mac / Linux environment. We provide directory services to about 300 hosts, and 200 employees using it; and haven't had any problems LDAP wise until now. So we think we are missing a mapping here. Any ideas? -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine (561) 880-2998 x237 fredy.sanchez at modmed.com *Need IT support?* Visit https://mmit.zendesk.com - - -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sun Apr 13 12:50:12 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 13 Apr 2014 08:50:12 -0400 Subject: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing. In-Reply-To: References: Message-ID: <534A8804.8030408@redhat.com> On 04/11/2014 10:37 AM, Fredy Sanchez wrote: > Hi all, > > We asked this same question at discussions.apple.com > , but figured we'd have better luck > here. I apologize in advance if this is the wrong forum. > > We are switching from Synology (DSM 5) to Mavericks server (v3.1.1. > running in Mavericks 10.9.2) for File Sharing. We use a FreeIPA > (ipa-server.x86_64 3.0.0-37.el6) backend for SSO, and the Mac > server seems correctly bound to it. Unfortunately, although we can add > usernames to the shares for the initial config, the usernames > transform to UIDs after (only for SSO accounts; local accounts are not > affected). That is, when we go to edit the permissions for a share, > all we see are UIDs. We can always figure out the username from the > UID, but this is an extra step we don't want to have. We've tried > reinstalling the Mac server app from scratch, re-binding to the > FreeIPA backend, changing mappings in Directory Utility (for example, > mapping GeneratedUID to uid, which is the username), recreating the > shares and permissions, etc. Here are more details about the binding: > > * The binding happens thru a custom package we created based primarily > on > http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 > * Sys Prefs, Users & Groups, Login Options show the server bound to > the FreeIPA backend with the green dot > * The following mappings are in place in Directory Utility, Services, > LDAPv3, FreeIPA backend > Users: inetOrgPerson > AuthenticationAuthority: uid > GeneratedUID: random number in uppercase > HomeDirectory: #/Users/$uid$ > NFSHomeDirectory: #/Users/$uid$ > OriginalHomeDirectory: #/Users/$uid$ > PrimaryGroupID: gidNumber > RealName: cn > RecordName: uid > UniqueID: uidNumber I do not have a clue about such setup but if the UID shows somewhere it should not be and there is a mapping attribute that can be mapped to different unique identifiers and currently points to UID I would start there. Have you tried mapping UniqueID to uid instead of uidNumber? > UserShell: loginShell > Groups: posixgroup > PrimaryGroupID: gidNumber > RecordName: cn > The search bases are correct > * Directory Utility, Directory Editor shows the right info for the users. > * $ id $USERNAME shows the right information for the user > > FreeIPA is working beautifully for our Mac / Linux environment. We > provide directory services to about 300 hosts, and 200 employees using > it; and haven't had any problems LDAP wise until now. So we think we > are missing a mapping here. Any ideas? > > -- > Cheers, > > Fredy Sanchez > IT Manager @ Modernizing Medicine > (561) 880-2998 x237 > fredy.sanchez at modmed.com > > *Need IT support?* Visit https://mmit.zendesk.com > > > * > > > * * > * > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sun Apr 13 13:21:46 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 13 Apr 2014 09:21:46 -0400 Subject: [Freeipa-users] External Collaboration Domains In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E6A8C10@001FSN2MPN1-045.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net> <20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net> <20140330182619.GA19628@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net> <53389BEA.9050905@redhat.com> <20140408133456.GR20958@redhat.com> <5343FCC6.10209@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A7E8E@001FSN2MPN1-045.001f.mgd2.msft.net> <534489E9.9090809@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8756@001FSN2MPN1-045.001f.mgd2.msft.net> <534729DA.2070003@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8B5B@001FSN2MPN1-045.001f.mgd2.msft.net> <53486581.9020906@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8C10@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <534A8F6A.9090708@redhat.com> On 04/11/2014 08:47 PM, Nordgren, Bryce L -FS wrote: >> There is a groups pf people that belong to different organizations, for >> example universities that launch a project together. They have the identities >> in their own home organization (domains). There is a "hosting" organization >> that some of the members of the group might belong to. Jointly all the users >> want to be able to access the systems that belong to the project, this >> includes login into the systems accessing file shares and web applications that >> constitute the joint project. They also want to be able to SSO as much as >> possible without creating additional identities and having a separate >> password. The home organization in this case would have trust relations with >> the hosting organization. >> The goal is to make it possible for the home organization to understand >> external identities accessing resources on the file system level thus POSIX >> attributes need to be generated, assigned and managed for those users. >> >> >> Does it sound about right? It this the problem we are solving? > Perfect. I'll make a new wiki page with that text and pictures tomorrow. :) > > >>> Collaboration is not limited to web services. Actually, if you asked me to >> come up with a real world example where collaboration happened only via >> web based services, I wouldn't be able to do it. >> >> Any Saas application. >> Google docs for enterprise, SFDC etc. > True. However, I've never been part of a project where these are all you need. These things do play a role, but aren't comprehensive. > >> OK, note taken. I wonder though how common is this scenario/use case. >> The fact that we hear about it for the first time and having hard time >> understanding the use case makes me think that it is yet not that common. >> We would need to see what is the dynamics though and whether the world >> is moving towards or away from this case becoming a popular one. >> But assume it is. > I think it's common at the small scale and typically addressed by individual projects renting dedicated servers at hosting farms. New accounts local to the machines are usually created. > > However, over the past ten years I've found that if I've set up "infrastructure", there's no shortage of people who want to leverage it. This tends to cause my tiny solution to scale up and out beyond what I'm willing to support. I suspect that if CIOs were given a notion of what kind of support to offer their users, you may see more demand for something like this. > >> OK. Let be paraphrase so that I understand (referring to the use case I >> mentioned above). >> >> Home organization will set a special IPA based domain for every external >> organization. It will be one way trusted but the hosting organization. >> This special "collaboration" domain will be the one where the entries are >> automatically created when external user comes in, right? > Essentially. I was thinking "home organization" would set up a single IPA based domain with a one-way trust from the internal corporate infra. As you mention, this domain would be where the automatically created external users appear. This single collaboration domain would be the connection point for inter-organizational trusts (vanilla Kerberos/IPA/AD) and would host the identity gateway (Ipsilon). > > Is there a need for one domain per organization you want to collaborate with? Probably not. But this is not significant for the design. >> b) There is a Kerberos SSO - but then his home domain needs to be >> trusted by his hosting domain. If it is possible the solution based on >> trusts exists. But I suspect CIOs do not like it ;-) so it is unlikely >> would be done in real life. > Thinking 5 years down the line, if multiple participating organizations had collaboration domains, CIOs may be a little more promiscuous with the vanilla Kerberos trusts between them. Don't rule out Kerberos SSO just yet. :) We will see when we get there. I am all for it but I see much easier ways of the federation via other means in shorter time. > >> There is no option to use SAML or OpenID with SSH but to get to the >> system on the system level you need to SSH. >> So until SSH supports SAML or similar the whole idea would not fly. > I wouldn't try to make all domain services aware of all identity technologies. > > Option d is use case 3 in the RFE. (Ipsilon obtains TGT for external user and forwards to client). The method of forwarding is what needs to be explored. It seemed to me that the method of getting the ticket from the KDC was fixed on s4u2user / s4u2proxy. You can get the ticket on the server but you can't deliver it to the client side. > > However, the RFE is structured such that IPA is prepared to service foreign user requests from an Ipsilon-like HTTP gateway, or an RFC6595-like gssapi/saml acceptor or a RFC6616-like gssapl/openid acceptor. The resolution of the technical approach to use case three is not a blocker. > > >> There is where I see a leap of faith. SAML -> SSH. It is not possible. >> And I am not sure OpenSSH would be interested to support it. They had >> hard time supporting Certs. > No SAML->SSH. Even if it were possible, it would involve configuring every host in the domain individually. Ick. > > Browser->Gateway->TGT->Service TKT->SSH. Like normal. There is no way to deliver TGT to the client. Also there is no TGT on the server. TGT can be acquired only using the real credential by principal in the initial auth. But this means that principal has a local credential (password, cert, token...). But this means it is not an external account any more. Full stop. Sorry. > GSSAPI/OpenID->GSSAPI acceptor->TGT->Service TKT->SSH. Like normal. or Does not work. Not possible. You can't get TGT using any kind of service ticket. > GSSAPI/SAML->GSSAPI acceptor->TGT->Service TKT->SSH. Like normal. See above. This is the flaw in the whole idea. As I said there are two problems: a) You can't get TGT using a service ticket b) If you got a ticker on the server side there is no way to deliver this ticket out of band not over kerberos protocol and stick it into the client. Knowing Kerberos community for 6 years I would say the chances for this to change are close to 0. I am not sure wheather it is even a good idea to change it. Also the change would require a change to all the browsers and this is a showstopper in itself. I think it would be easier to create an SSH client plugin that uses existing protocols and flows but it is again a huge task in itself. >> The account can be created but the local password has to be created too. >> In this case you are just a local user that can also federate from external. > Gateway gets ticket using s4u2user / s4u2proxy. Forwards ticket. No password. :) There is no way to send the ticket back to the client. gateway itself would not have access to that ticket too. It can act on behalf of the user but not send tickets around. > >> IMO this will be possible with the technologies or projects currently >> being worked on: Ipsilon, apache modules, gss proxy etc. >> The only part that is not covered is user provisioning. I would think >> that user provisioning would be a good RFE for Ipsilon. > External users need a presence in LDAP regardless of their origin (need to participate in groups). Ipsilon will not see external users from Kerberos trusts, including: > * vanilla Kerberos trusts (all POSIX info needs to be synthesized) > * AD trust (possibly needing POSIX attributes, possibly needing them remapped to avoid collisions). > * TBD IPA trusts (possibly need POSIX attributes remapped to avoid collisions). > > IPA (specifically, the KDC) is the arbiter of all access to all services in the realm. There is no other single point of monitoring or control. > >> To support mapping or local users to the external IdPs we would need >> Ipsilon to not only create but be able to map external identities to >> internal identities. > I believe external identities will need to be mapped to cname/crealm pairs. The mapped crealm will NOT be internal/local. I might be "bnordgren at SAML://idp.usda.gov/geeklogin/" The mapping should be universal so the authenticated user can cross Kerberos trusts without worrying that different realms map the ID differently. > > >> Here is how it might work: >> [...] >> I think it makes sense. > Your proposal requires creating a local account for the external user. If we were to accept the need to do that, would it not be simpler to kerberize the local webapps and the user would spnego/gssapi after kiniting? Kerberizing something is very hard. We have been doing it for many years and the pace is really slow. > >>> D] Assuming I can persuade USDA to join the InCommon SAML federation, >> I'd want user accounts to be autocreated in our collaboration realm based on >> SAML credentials. We will not be synchronizing IPA external users against the >> union of all accounts in all IdPs in the federation, so external users must be >> autocreated. >> >> I think I described it above. >> IMO IdP is the better place for this not the KDC. > I would be willing to accept this if you can show me how the IdP catches all the external users, not just the ones coming in from SAML or OpenID. I see a crack that my AD account will fall through. :) The AD accounts are already taken care of but the AD trust feature, please setup a trust and see for yourself. > >>> E] Users from our own AD should be recognized, but not as a "lump". Each >> user needs to be able to join groups in the collaboration realm individually. >> This would require creating a DN for them in LDAP (according to the IdM >> docs). It's not desirable to replicate all 50000 users from AD to IPA, just the >> ones who actually connect and use services, so the users who choose to >> connect must be autocreated. >> >> OK. Makes sense. Since I do not expect that the domains would really be >> accessible over Ldap and Kerberos directly relying on SAML would be the >> solution to pursue. > Kerberos is the least common denominator. It's also in the critical path. Nobody gets any services without a ticket. :) You are assuming what Kerberos can and can't do thus you have design that has some fundamental flaws. > >> OK. but the kx509 certs from which CA? I assume that we are talking >> about collaboration CA, so there is really no relation to the home >> domain and home CA. > TBD. Configurable. Future. ;) > > Note if the realm was configured to accept kx509 from the home CA, it would allow the home domain's AD to stay behind the firewall while allowing me to access the collaboration realm from a partner's facility. > >> I think we are on the right path to enable what you are looking for just >> doing it slightly differently from what you are suggesting. > I'm patient. And I can deal with workarounds in the near term as long as they lead up to a long term solution. I do want the long term solution not to involve creating/managing local accounts (w/passwords and a local crealm) when a federated account exists. Also, I am not yet convinced that Ipsilon will catch external users coming in on Kerberos trusts. The trusts wil ltake care of the users on the fly. Please get familiar with what we already did for AD trusts. It handles users without syncing them. Similar will be done for other trusts. > Plus, putting the creation of IPA external users in the hands of an external service would seem to bind IPA and Ipsilon together when they don't need to be. If Ipsilon were a generic HTTP IdP<->Kerberos gateway, it would also work for AD, for vanilla Kerberos domains, and for KRB/LDAP domains. I'm not sure I would choose that unless there were no other options. I think it will be pluggable to be able to create users in whatever identity store it is configured to create. > > However, "running code wins". Make me something that works and I don't need to look to closely at it. :) > >> Based on this discussion I suggest we open an RFE and plan for it when >> we have: >> 1) IPA <-> IPA trusts >> 2) Ipsilon >> implemented. Then we would be able to combine the two, add a call for >> provisioning and finally help you solve the problem you are interested >> in solving. > I'm not sure I understand how #1 factors into this plan? Did I miss that bit? This takes care of one of the types of the trusts you are worried about. > >> Are you interested in helping with moving 1) or 2) forward as a >> prerequisite for the ultimate goal? > Interest is rarely my problem; time is. :) Also, I need to wrap my head around things before coding. With regard to #1, I'm more or less itching to restructure trusts such that vanilla Kerberos is the general case, Probably will be last in our list of Kerberos based trusts becuase I suspect that it would be easier to move to IPA and then do the trusts. > and IPA->AD, This is done. Please check it out. > IPA->IPA, Needs a lot of work. And this is where I suggest you can help. > and IPA->KRB/LDAP are special cases where extra information may be available (email addy, gecos, sn, POSIX attrs etc.) I think it is just easier to migrate to IPA and use IPA to IPA trusts. We already have use cases where extra data is needed from external sources. There is a ticket in IPA trac. I just do not recall the number. > > For #2, I've been trying to find info on Ipsilon and failing. I have a vague notion that it's an HTTP gateway between web technologies and the Kerberos based IPA. Maybe I could interrogate someone and make a wiki page or three. There is not much info about it. There is a site with code. It is a python based IdP focusing on making configuring SAML based SSO easy. https://fedorahosted.org/ipsilon/ Simo, it might make sense to put some designs on the wiki for people to become familiar. > > Bryce > > > > > This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. > Bottom line. IPA <-> IPA is the next step. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From quest.monger at gmail.com Mon Apr 14 08:07:03 2014 From: quest.monger at gmail.com (quest monger) Date: Mon, 14 Apr 2014 04:07:03 -0400 Subject: [Freeipa-users] IPA client installation for Solaris 11. In-Reply-To: <558C15177F5E714F83334217C9A197DF01604ABCF2@SSC-MBX2.ssc.internal> References: <5345AF48.3030501@redhat.com> <5346C23B.8080503@redhat.com> <5346C728.1040001@redhat.com> <5346CF09.1060007@redhat.com> <558C15177F5E714F83334217C9A197DF01604ABCF2@SSC-MBX2.ssc.internal> Message-ID: Hi Johan, Wow, that worked. Thank you for all the info. I have a few more questions - Sudo - How do I get sudo working. I have not changed anything on the server side (default FreeIPA install config). Do I need to setup or add sudo policies to the usr/group on the server side? Home Dir - On my CentOS clients, I got it configured such that a home Dir is created the first time a user has a successful login (used ipa-client-install --mkhomedir). Can we do the same for Solaris servers? Again, thank you for this info. I can verify that these instructions worked on a Oracle Solaris 11.1 SPARC machine. Once I have everything nailed out, i will respond to this thread with all the steps Thanks. On Thu, Apr 10, 2014 at 1:37 PM, Johan Petersson < Johan.Petersson at sscspace.com> wrote: > Proxy user is only necessary if you disable anonymous bind on the IPA LDAP. > > Example configuration for making Solaris 11 work as an IPA client. > If you want autofs of shared NFS home directory too, let me know and i can > provide it. > I will add this and more to IPA Wiki when i can find the time to go > through it properly and polish away some rough edges. > I hope it can provide some help. > > Solaris 11.1 IPA lient configuration. > > First make sure that the Solaris 11 machine are using the proper DNS and > NTP servers. > > On the IPA server or Client run: > > ipa host-add --force --ip-address=192.168.0.1 solaris.example.com > > ipa-getkeytab -s ipaserver.example.com -p host/solaris.example.com -k > /tmp/solaris.keytab > > Move the keytab to the Solaris machine /etc/krb5/krb5.keytab > > Make sure it have the proper owner and permissions: > > chown root:sys /etc/krb5/krb5.keytab > chmod 700 /etc/krb5/krb5.keytab > > Edit /etc/nsswitch.ldap, replace "ldap" with "dns" from the "hosts" and > "ipnodes" lines: > > hosts: files dns > ipnodes: files dns > > Edit /etc/krb5/krb5.conf: > > [libdefaults] > default_realm = EXAMPLE.COM > verify_ap_req_nofail = false > [realms] > EXAMPLE.COM = { > kdc = ipaserver.example.com > admin_server = ipaserver.example.com > } > > [domain_realm] > example.com = EXAMPLE.COM > .example.com = EXAMPLE.COM > > > Run the ldapclient with the default DUAProfile. > The "-a domainName= example.com" is needed so that ldapclient does not > stop and complain about missing nisdomain name. > > ldapclient -v init -a profilename=default -a domainName=example.com > ipaserver.example.com > > In Solaris 11.1 the pam configuration have changed but for simplicity i > still use the /etc/pam.conf: > > login auth requisite pam_authtok_get.so.1 > login auth required pam_dhkeys.so.1 > login auth required pam_unix_cred.so.1 > login auth sufficient pam_krb5.so.1 > login auth required pam_unix_auth.so.1 > login auth required pam_dial_auth.so.1 > > other auth requisite pam_authtok_get.so.1 > other auth required pam_dhkeys.so.1 > other auth required pam_unix_cred.so.1 > other auth sufficient pam_krb5.so.1 > other auth required pam_unix_auth.so.1 > > other account requisite pam_roles.so.1 > other account required pam_unix_account.so.1 > other account required pam_krb5.so.1 > > other password requisite pam_authtok_check.so.1 force_check > other password sufficient pam_krb5.so.1 > other password required pam_authtok_store.so.1 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] > on behalf of Rob Crittenden [rcritten at redhat.com] > Sent: Thursday, April 10, 2014 19:04 > To: dpal at redhat.com; quest monger > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] IPA client installation for Solaris 11. > > Dmitri Pal wrote: > > On 04/10/2014 12:18 PM, quest monger wrote: > >> Sorry about that. So I am Looking at the Solaris 10 client > >> documentation here - > >> > http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html > >> > >> > >> It says do the following on Solaris client - > >> > >> ldapclient manual > >> ... > >> -a proxyPassword={NS1}fbc123a92116812 > >> ... > >> > >> > >> Whats that proxyPassword for? > >> > > > > I suspect that it is a password that corresponds to the proxy user. > > The client component on Solaris (pure speculation on my side) seems to > > use proxy user to connect to LDAP server and do some operations for the > > host. It is similar to SSSD but SSSD does not use passwords, it uses > > keytabs if talks to IPA. > > There are a number of different profile levels available, see > > http://docs.oracle.com/cd/E23824_01/html/821-1455/ldapsecure-66.html#ldapsecure-74 > > proxy is usually a shared account that the Solaris box uses to > authenticate to the LDAP server. > > > Solaris uses passwords but to prevent them from being stored in > > configuration in clear the are "obfuscated" with the NS1 method > > http://stuff.iain.cx/2008/05/03/ns103eb2365be169abbe3a45088a10a/ > > I suspect there should be some tool on Solaris that takes password and > > creates an obfuscated string like this. > > I didn't experiment using a proxy password inside a profile. I'll bet > that if you manually enroll a client then you can dig out the password > on that local system and store that in the profile. > > There is also a self level which uses Kerberos. I've never used it > myself (it may be newer than my experience with Solaris) but there are > some fairly detailed docs on it at > http://docs.oracle.com/cd/E23824_01/html/821-1455/clientsetup-49.html#gdzpl > > rob > > > > Thanks > > Dmitri > > > >> Thanks. > >> > >> > >> > >> On Thu, Apr 10, 2014 at 12:09 PM, Dmitri Pal >> > wrote: > >> > >> On 04/10/2014 11:41 AM, quest monger wrote: > >>> Thanks Rob, those bug reports help. > >>> One more question, in the official Solaris 10 documentation, i > >>> see this stuff - > >>> > >>> -aproxyPassword={NS1}*fbc123a92116812* > >>> > userPassword::*e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ*= > >>> > >>> Is there a way to generate that password hash for a new password. > >>> I think that should be part of the documentation, dont want all > >>> Solaris IPA users to be using the same password and corresponding > >>> hash. > >>> > >> Can you rephrase the question? > >> It is unclear what hash you are asking about. > >> If you are using IPA you do not need local password hashes. > >> > >> > >>> Thanks. > >>> > >>> > >>> > >>> > >>> On Wed, Apr 9, 2014 at 4:36 PM, Rob Crittenden > >>> > wrote: > >>> > >>> quest monger wrote: > >>> > >>> > >>> I have read through the official documentation here for > >>> Solaris-10 - > >>> > http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html > >>> I have found a few web posts on how to make it work for > >>> Solaris-11. > >>> Have any of you tried adding a Solaris-11 host to an > >>> existing IPA > >>> server? If so, do you have any > >>> documentation/how-tos/instructions that i > >>> could use to do the same. Any help is appreciated. > >>> I am trying to do this to so I can centralize SSH > >>> authentication for all > >>> my Solaris-11 and Linux hosts. > >>> > >>> > >>> That is pretty much all we've got. There is a bug open with > >>> some documentation updates, > >>> https://bugzilla.redhat.com/show_bug.cgi?id=815533 and some > >>> more in https://bugzilla.redhat.com/show_bug.cgi?id=801883 > >>> > >>> We use sssd to help with centralized SSH auth so it probably > >>> won't work as smoothly on Solaris as it does on sssd-based > >>> Linux systems. See sss_ssh_authorizedkeys(1) and > >>> sss_ssh_knownhostsproxy(8). > >>> > >>> This document describes how it works in IPA > >>> > http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf > >>> > >>> rob > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Freeipa-users mailing list > >>> Freeipa-users at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-users > >> > >> > >> -- > >> Thank you, > >> Dmitri Pal > >> > >> Sr. Engineering Manager IdM portfolio > >> Red Hat, Inc. > >> > >> > >> _______________________________________________ > >> Freeipa-users mailing list > >> Freeipa-users at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-users > >> > >> > > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager IdM portfolio > > Red Hat, Inc. > > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > This e-mail is private and confidential between the sender and the > addressee. > In the event of misdirection, the recipient is prohibited from using, > copying or disseminating it or any information in it. Please notify the > above if any misdirection. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Apr 14 10:23:10 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 14 Apr 2014 12:23:10 +0200 Subject: [Freeipa-users] External Collaboration Domains In-Reply-To: <534A8F6A.9090708@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net> <20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net> <20140330182619.GA19628@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net> <53389BEA.9050905@redhat.com> <20140408133456.GR20958@redhat.com> <5343FCC6.10209@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A7E8E@001FSN2MPN1-045.001f.mgd2.msft.net> <534489E9.9090809@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8756@001FSN2MPN1-045.001f.mgd2.msft.net> <534729DA.2070003@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8B5B@001FSN2MPN1-045.001f.mgd2.msft.net> <53486581.9020906@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8C10@001FSN2MPN1-045.001f.mgd2.msft.net> <534A8F6A.9090708@redhat.com> Message-ID: <534BB70E.4020303@redhat.com> On 13.4.2014 15:21, Dmitri Pal wrote: >>> There is where I see a leap of faith. SAML -> SSH. It is not possible. >>> And I am not sure OpenSSH would be interested to support it. They had >>> hard time supporting Certs. >> No SAML->SSH. Even if it were possible, it would involve configuring every >> host in the domain individually. Ick. >> >> Browser->Gateway->TGT->Service TKT->SSH. Like normal. > > There is no way to deliver TGT to the client. Also there is no TGT on the > server. TGT can be acquired only using the real credential by principal in the > initial auth. But this means that principal has a local credential (password, > cert, token...). But this means it is not an external account any more. > Full stop. Sorry. > >> GSSAPI/OpenID->GSSAPI acceptor->TGT->Service TKT->SSH. Like normal. or > > Does not work. Not possible. You can't get TGT using any kind of service ticket. > >> GSSAPI/SAML->GSSAPI acceptor->TGT->Service TKT->SSH. Like normal. > > See above. This is the flaw in the whole idea. > > > As I said there are two problems: > a) You can't get TGT using a service ticket > b) If you got a ticker on the server side there is no way to deliver this > ticket out of band not over kerberos protocol and stick it into the client. Please note that Ticket Granting service is extensible. Nowadays we have plain Kerberos and PKINIT built on top of it. PKINIT is different way how to get TGT (in comparison to plain Kerberos). I think it would be possible to build some machinery around that. Variant (A) - IdP + PKINIT: A1) User authenticates to his SAML/OpenID provider (external domain) A2) User locally generates CSR A3) User contacts IdP (gssapi/saml ; gssapi/openid) and sends CSR to the IdP A4) IdP returns short-lived certificate (validity period matches policy for TGT) A5) User presents certificate issued by IdP to KDC A6) KDC authenticates user via PKINIT and issues TGT as usual This variant doesn't require any change to Kerberos protocol. It needs IdP with CA + some client software automating described steps. Of course, it would be possible to add a new mechanism like PKINIT. Obvious disadvantage is that it require changes in Kerberos protocol - i.e. definition of the new mechanism and implementation to KDC and Kerberos libraries. Variant (B) - IdP without PKINIT is almost the same, just uses symmetric crypto: A1) User authenticates to his SAML/OpenID provider (external domain) A2) User contacts IdP (gssapi/saml ; gssapi/openid) and sends authentication request A4) IdP changes principal password to some random value and sends keytab back to the user (via GSSAPI-secured connection) A5) User uses keytab to get TGT from KDC Obvious problem is that keytab received by user has to be short-lived. For example, IdP could generate a new random password for user principal 1 minute after sending keytab to the user. This could work if the whole process should be automated. Is seems that variant (B) should be really simple to code/script when we have SAML/OpenID capable IdP. > Knowing Kerberos community for 6 years I would say the chances for this to > change are close to 0. I am not sure wheather it is even a good idea to change > it. Also the change would require a change to all the browsers and this is a > showstopper in itself. > > I think it would be easier to create an SSH client plugin that uses existing > protocols and flows but it is again a huge task in itself. IMHO GSSAPI is the right layer to focus on, not the SSH itself. -- Petr^2 Spacek From mkosek at redhat.com Mon Apr 14 11:30:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 14 Apr 2014 13:30:04 +0200 Subject: [Freeipa-users] FreeIPA Training Series - FreeIPA 3.3 and SSSD 1.11 Message-ID: <534BC6BC.3070307@redhat.com> Hello FreeIPA and SSSD users, Our team just published FreeIPA&SSSD training presentations created in the event of successful stabilization of FreeIPA 3.3 and SSSD 1.11 branches which introduced a lot of AD Trust related enhancements and other bug fixes. I uploaded all the presentations to FreeIPA.org site, see http://www.freeipa.org/page/Documentation#FreeIPA_Training_Series I would like to welcome you to look at the presentations, I hope they will help you learn about the stuff we have been working on since the last Training Series round released almost a year ago. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From rcritten at redhat.com Mon Apr 14 13:37:22 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Apr 2014 09:37:22 -0400 Subject: [Freeipa-users] add a cert of .net insetad of .com error ? In-Reply-To: References: <5347E455.2050005@redhat.com> Message-ID: <534BE492.7090401@redhat.com> Please keep replies on the list. barrykfl at gmail.com wrote: > Is it meant that i cannot use def.abc.net cert for > the host def.abc.com ??? Correct. > only i can used is same as hostname and domain ...or wildcard *.abc,com ? For now yes. Eventually we may be able to use SNI to use certificates with multiple names but we aren't there yet. rob > > Thanks > > > > 2014-04-11 20:47 GMT+08:00 Rob Crittenden >: > > barrykfl at gmail.com wrote: > > Dear all: > > I added *.abc.net cet to > certutil -d /etc/httpd/alias > > and /etc/dirsrv/slapd-ABC-COM > > But error comes out after when i login the UI of service and > cick in entry . > > cannot connect to > 'https://cert1.abc.com:443/ca/__agent/ca/displayBySerial > ': [Errno > -12276] > (SSL_ERROR_BAD_CERT_DOMAIN) Unable to communicate securely with > peer: > requested domain name does not match the server's certificate. > > > This is the SSL MITM protection. The subject of the certificate on > the server needs to match the hostname that the client is requesting. > > You can't just change the domain name of your installation by > replacing the certificates. > > rob > > From simo at redhat.com Mon Apr 14 13:53:46 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 14 Apr 2014 09:53:46 -0400 Subject: [Freeipa-users] External Collaboration Domains In-Reply-To: <534BB70E.4020303@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net> <20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net> <20140330182619.GA19628@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net> <53389BEA.9050905@redhat.com> <20140408133456.GR20958@redhat.com> <5343FCC6.10209@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A7E8E@001FSN2MPN1-045.001f.mgd2.msft.net> <534489E9.9090809@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8756@001FSN2MPN1-045.001f.mgd2.msft.net> <534729DA.2070003@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8B5B@001FSN2MPN1-045.001f.mgd2.msft.net> <53486581.9020906@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8C10@001FSN2MPN1-045.001f.mgd2.msft.net> <534A8F6A.9090708@redhat.com> <534BB70E.4020303@redhat.com> Message-ID: <1397483626.19767.242.camel@willson.li.ssimo.org> On Mon, 2014-04-14 at 12:23 +0200, Petr Spacek wrote: > On 13.4.2014 15:21, Dmitri Pal wrote: > >>> There is where I see a leap of faith. SAML -> SSH. It is not possible. > >>> And I am not sure OpenSSH would be interested to support it. They had > >>> hard time supporting Certs. > >> No SAML->SSH. Even if it were possible, it would involve configuring every > >> host in the domain individually. Ick. > >> > >> Browser->Gateway->TGT->Service TKT->SSH. Like normal. > > > > There is no way to deliver TGT to the client. Also there is no TGT on the > > server. TGT can be acquired only using the real credential by principal in the > > initial auth. But this means that principal has a local credential (password, > > cert, token...). But this means it is not an external account any more. > > Full stop. Sorry. > > > >> GSSAPI/OpenID->GSSAPI acceptor->TGT->Service TKT->SSH. Like normal. or > > > > Does not work. Not possible. You can't get TGT using any kind of service ticket. > > > >> GSSAPI/SAML->GSSAPI acceptor->TGT->Service TKT->SSH. Like normal. > > > > See above. This is the flaw in the whole idea. > > > > > > As I said there are two problems: > > a) You can't get TGT using a service ticket > > b) If you got a ticker on the server side there is no way to deliver this > > ticket out of band not over kerberos protocol and stick it into the client. > > Please note that Ticket Granting service is extensible. Nowadays we have plain > Kerberos and PKINIT built on top of it. PKINIT is different way how to get TGT > (in comparison to plain Kerberos). > > I think it would be possible to build some machinery around that. > > Variant (A) - IdP + PKINIT: > A1) User authenticates to his SAML/OpenID provider (external domain) > A2) User locally generates CSR > A3) User contacts IdP (gssapi/saml ; gssapi/openid) and sends CSR to the IdP > A4) IdP returns short-lived certificate (validity period matches policy for TGT) > A5) User presents certificate issued by IdP to KDC > A6) KDC authenticates user via PKINIT and issues TGT as usual > > This variant doesn't require any change to Kerberos protocol. It needs IdP > with CA + some client software automating described steps. > > > Of course, it would be possible to add a new mechanism like PKINIT. Obvious > disadvantage is that it require changes in Kerberos protocol - i.e. definition > of the new mechanism and implementation to KDC and Kerberos libraries. > > > Variant (B) - IdP without PKINIT is almost the same, just uses symmetric crypto: > A1) User authenticates to his SAML/OpenID provider (external domain) > A2) User contacts IdP (gssapi/saml ; gssapi/openid) and sends authentication > request > A4) IdP changes principal password to some random value and sends keytab back > to the user (via GSSAPI-secured connection) > A5) User uses keytab to get TGT from KDC > > Obvious problem is that keytab received by user has to be short-lived. For > example, IdP could generate a new random password for user principal 1 minute > after sending keytab to the user. > > This could work if the whole process should be automated. http://www.umich.edu/~x509/ I already have a plan to implement this in Ipsilon eventually :-) > Is seems that variant (B) should be really simple to code/script when we have > SAML/OpenID capable IdP. It can be done indeed. Simo. -- Simo Sorce * Red Hat, Inc * New York From mario.p.gonzalez at gmail.com Mon Apr 14 21:13:06 2014 From: mario.p.gonzalez at gmail.com (Mario Gonzalez) Date: Mon, 14 Apr 2014 23:13:06 +0200 Subject: [Freeipa-users] Locked out admin Message-ID: <534C4F62.7020404@gmail.com> Hi, I changed the max password life parameter to 30000 and now I cannot get back in to undo it. If I try to do 'kinit admin' I only get a 'Password expired. You must change it now' dialog that ends with: kinit: Password has expired while getting initial credentials Unfortunately as this is the 'admin' account I cannot undo the damage. Is there any way to fix this or have I messed up totally? br mario; From Steven.Jones at vuw.ac.nz Mon Apr 14 21:20:19 2014 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 14 Apr 2014 21:20:19 +0000 Subject: [Freeipa-users] Locked out admin In-Reply-To: <534C4F62.7020404@gmail.com> References: <534C4F62.7020404@gmail.com> Message-ID: <3b444cb9185b4ed68dcc66416adc9b25@SINPR04MB298.apcprd04.prod.outlook.com> Login a directory manager? regards Steven Jones Technical Specialist - Linux RHCE Victoria University ITS, Level 8 Rankin Brown Building, Wellington, NZ 6012 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com on behalf of Mario Gonzalez Sent: Tuesday, 15 April 2014 9:13 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] Locked out admin Hi, I changed the max password life parameter to 30000 and now I cannot get back in to undo it. If I try to do 'kinit admin' I only get a 'Password expired. You must change it now' dialog that ends with: kinit: Password has expired while getting initial credentials Unfortunately as this is the 'admin' account I cannot undo the damage. Is there any way to fix this or have I messed up totally? br mario; _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Mon Apr 14 21:25:01 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Apr 2014 17:25:01 -0400 Subject: [Freeipa-users] Locked out admin In-Reply-To: <3b444cb9185b4ed68dcc66416adc9b25@SINPR04MB298.apcprd04.prod.outlook.com> References: <534C4F62.7020404@gmail.com> <3b444cb9185b4ed68dcc66416adc9b25@SINPR04MB298.apcprd04.prod.outlook.com> Message-ID: <534C522D.40606@redhat.com> Steven Jones wrote: > Login a directory manager? Right, something like: $ ldappasswd -x -D 'cn=directory manager' -W -S uid=admin,cn=users,cn=accounts,dc=example,dc=com And don't set the maxlife to anything greater than say 4000. rob > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University ITS, > > Level 8 Rankin Brown Building, > > Wellington, NZ > > 6012 > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com on behalf of Mario Gonzalez > Sent: Tuesday, 15 April 2014 9:13 a.m. > To: freeipa-users at redhat.com > Subject: [Freeipa-users] Locked out admin > > Hi, > > I changed the max password life parameter to 30000 and now I cannot get > back in to undo it. If I try to do 'kinit admin' I only get a 'Password > expired. You must change it now' dialog that ends with: > > kinit: Password has expired while getting initial credentials > > Unfortunately as this is the 'admin' account I cannot undo the damage. > > Is there any way to fix this or have I messed up totally? > > br > mario; > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From mario.p.gonzalez at gmail.com Mon Apr 14 21:49:49 2014 From: mario.p.gonzalez at gmail.com (Mario Gonzalez) Date: Mon, 14 Apr 2014 23:49:49 +0200 Subject: [Freeipa-users] Locked out admin In-Reply-To: <534C522D.40606@redhat.com> References: <534C4F62.7020404@gmail.com> <3b444cb9185b4ed68dcc66416adc9b25@SINPR04MB298.apcprd04.prod.outlook.com> <534C522D.40606@redhat.com> Message-ID: <534C57FD.7090109@gmail.com> Den 14. april 2014 23:25, skrev Rob Crittenden: > Steven Jones wrote: >> Login a directory manager? > > Right, something like: > > $ ldappasswd -x -D 'cn=directory manager' -W -S > uid=admin,cn=users,cn=accounts,dc=example,dc=com > > And don't set the maxlife to anything greater than say 4000. > > rob > Thanks! That worked like a charm. mario; From mkosek at redhat.com Tue Apr 15 06:23:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 15 Apr 2014 08:23:53 +0200 Subject: [Freeipa-users] Locked out admin In-Reply-To: <534C57FD.7090109@gmail.com> References: <534C4F62.7020404@gmail.com> <3b444cb9185b4ed68dcc66416adc9b25@SINPR04MB298.apcprd04.prod.outlook.com> <534C522D.40606@redhat.com> <534C57FD.7090109@gmail.com> Message-ID: <534CD079.1080100@redhat.com> On 04/14/2014 11:49 PM, Mario Gonzalez wrote: > Den 14. april 2014 23:25, skrev Rob Crittenden: >> Steven Jones wrote: >>> Login a directory manager? >> >> Right, something like: >> >> $ ldappasswd -x -D 'cn=directory manager' -W -S >> uid=admin,cn=users,cn=accounts,dc=example,dc=com >> >> And don't set the maxlife to anything greater than say 4000. >> >> rob >> > > Thanks! > > That worked like a charm. > > mario; Good to hear! Just to close the loop, this is something that was addressed upstream already. https://fedorahosted.org/freeipa/ticket/3817 It should be fixed in FreeIPA 3.3.0 and later. Martin From simo at redhat.com Tue Apr 15 13:30:53 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 15 Apr 2014 09:30:53 -0400 Subject: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing. In-Reply-To: References: Message-ID: <1397568653.19767.289.camel@willson.li.ssimo.org> On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: > Hi all, > > We asked this same question at discussions.apple.com, but figured we'd have > better luck here. I apologize in advance if this is the wrong forum. > > We are switching from Synology (DSM 5) to Mavericks server (v3.1.1. running > in Mavericks 10.9.2) for File Sharing. We use a FreeIPA (ipa-server.x86_64 > 3.0.0-37.el6) backend for SSO, and the Mac server seems correctly > bound to it. Unfortunately, although we can add usernames to the shares for > the initial config, the usernames transform to UIDs after (only for SSO > accounts; local accounts are not affected). That is, when we go to edit the > permissions for a share, all we see are UIDs. We can always figure out the > username from the UID, but this is an extra step we don't want to have. > We've tried reinstalling the Mac server app from scratch, re-binding to the > FreeIPA backend, changing mappings in Directory Utility (for example, > mapping GeneratedUID to uid, which is the username), recreating the shares > and permissions, etc. Here are more details about the binding: > > * The binding happens thru a custom package we created based primarily on > http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 > * Sys Prefs, Users & Groups, Login Options show the server bound to the > FreeIPA backend with the green dot > * The following mappings are in place in Directory Utility, Services, > LDAPv3, FreeIPA backend > > Users: inetOrgPerson > AuthenticationAuthority: uid > GeneratedUID: random number in uppercase > HomeDirectory: #/Users/$uid$ > NFSHomeDirectory: #/Users/$uid$ > OriginalHomeDirectory: #/Users/$uid$ > PrimaryGroupID: gidNumber > RealName: cn > RecordName: uid > UniqueID: uidNumber > UserShell: loginShell > Groups: posixgroup > PrimaryGroupID: gidNumber > RecordName: cn > > The search bases are correct > > * Directory Utility, Directory Editor shows the right info for the users. > * $ id $USERNAME shows the right information for the user > > FreeIPA is working beautifully for our Mac / Linux environment. We provide > directory services to about 300 hosts, and 200 employees using it; and > haven't had any problems LDAP wise until now. So we think we are missing a > mapping here. Any ideas? Fredy, I quickly tried to check for some documentation on how to configure this stuff, but found only useless superficial guides on how to find the pointy/clicky buttons to push to enable the service. I am not a Mac expert by a long shot so I cannot help you much here. Is there any guide available on how to use this service with other LDAP servers, like openLDAP or Active Directory ? We can probably draw some conclusions from there. Simo. -- Simo Sorce * Red Hat, Inc * New York From bnordgren at fs.fed.us Tue Apr 15 22:05:15 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Tue, 15 Apr 2014 22:05:15 +0000 Subject: [Freeipa-users] External Collaboration Domains In-Reply-To: <1397483626.19767.242.camel@willson.li.ssimo.org> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net> <20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net> <20140330182619.GA19628@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net> <53389BEA.9050905@redhat.com> <20140408133456.GR20958@redhat.com> <5343FCC6.10209@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A7E8E@001FSN2MPN1-045.001f.mgd2.msft.net> <534489E9.9090809@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8756@001FSN2MPN1-045.001f.mgd2.msft.net> <534729DA.2070003@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8B5B@001FSN2MPN1-045.001f.mgd2.msft.net> <53486581.9020906@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8C10@001FSN2MPN1-045.001f.mgd2.msft.net> <534A8F6A.9090708@redhat.com> <534BB70E.4020303@redhat.com> <1397483626.19767.242.camel@willson.li.ssimo.org> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E6AB133@001FSN2MPN1-044.001f.mgd2.msft.net> > > Variant (A) - IdP + PKINIT: > > A1) User authenticates to his SAML/OpenID provider (external domain) > > A2) User locally generates CSR > > A3) User contacts IdP (gssapi/saml ; gssapi/openid) and sends CSR to > > the IdP > > A4) IdP returns short-lived certificate (validity period matches > > policy for TGT) > > A5) User presents certificate issued by IdP to KDC > > A6) KDC authenticates user via PKINIT and issues TGT as usual > > > > This variant doesn't require any change to Kerberos protocol. It needs > > IdP with CA + some client software automating described steps. > > > > > > Variant (B) - IdP without PKINIT is almost the same, just uses symmetric > crypto: > > A1) User authenticates to his SAML/OpenID provider (external domain) > > A2) User contacts IdP (gssapi/saml ; gssapi/openid) and sends > > authentication request > > A4) IdP changes principal password to some random value and sends > > keytab back to the user (via GSSAPI-secured connection) > > A5) User uses keytab to get TGT from KDC > > > > Obvious problem is that keytab received by user has to be short-lived. > > For example, IdP could generate a new random password for user > > principal 1 minute after sending keytab to the user. Interesting notion. My understanding of B is that KDC would need an entry for the user in order to store the shared secret. This may "interact" with the principal name mapping in some hard-to-understand-right-now ways. For instance: KDC manages "EXAMPLE.ORG". User is coming in from google openID account. Pretend "mapped" Kerberos principal is: username at OPENID:www.google.com/openid/provider/url Can the KDC for EXAMPLE.ORG store that? I can see approach A working because the user principal doesn't have to exist in the KDC. Seems like case "B" involves a shared secret between external user and the local KDC, whereas approach A doesn't. I would vote for making the lifetime of the shared secret be derived from the lifetime of the credential the person used to get it. (if the openID session is good for 12 hours, the keytab should be too.) I don't see a need to null out the keytab after one minute. > > > > This could work if the whole process should be automated. > > http://www.umich.edu/~x509/ > > I already have a plan to implement this in Ipsilon eventually :-) +1 +1 Perhaps the NSCA MyProxy CA also has some ideas worth implementing? It seems to be geared to a full-on PKI environment, where it issues derived (proxy) certificates for users to use in a login session. It appears that it could make kx509 certs as it is configurable w.r.t. what fields appear in the generated certificates and how identities are mapped. Also, it has client side programs for certificate storage and retrieval. Some concepts may be worth stealing. :) Overall, it appears to me that short-lived certs (approach A) have a certain time-tested feel to them earned by many years of regular use captured in RFC3820. Approach A, in the parlance of RFC3820, could potentially be expressed as "External users delegate to a local Kerberos session the right to use their non-Kerberos identity by causing a proxy kx509 certificate to be issued." The cross-technology aspect makes the wording weird, since you rarely consider self-delegation to be delegation. The only real addition here is the use of the proxy certificates to gain entry to the local Kerberos universe. Short-lived "long term secrets" don't have this pedigree. Also, not real fond of transmitting the shared secret over the network, as required by B (even if it is a one-time-use thing. Makes me twitchy.) For that reason I might lean towards approach A, but would be happy with either. Approach A has the client map the identities to generate the CSR. The IdP un-maps them to verify before issuing credentials. Seems this requires mapping strategy to be coordinated, perhaps standardized? Approach B, I presume, puts control of the mapping in the hands of the IdP? I assume this mapping would need to be coordinated with any realms to which this IPA is connected by trust, regardless of whether A or B is chosen? Things to think about... > > Is seems that variant (B) should be really simple to code/script when > > we have SAML/OpenID capable IdP. > > It can be done indeed. I need to rework my RFE with diagrams to capture either A or B. Do you have a preference? Should I put both in as options? One comment/question: in both A and B, step 1 seems superfluous? Gssapi/saml and gssapi/openid both support initial authentication, if no cached creds exist, I think. Could step one be dropped and/or integrated into step A3 or B2? I'm still not understanding why transferring a TGT via a browser is more difficult than linking to a file-based representation of it and ensuring there's a "helper application" ready to handle that mime type on the client. (By "handle", I mean store in the local cache.) Presumably, the IdP could communicate the reply key to the client securely, but that's more or less the same as transmitting the shared secret over the network. That puts the browser TGT solution on par with "B" for me. What I am seeing is two suggestions which eliminate the need for such a transfer, whether it be trivial or impossible. It's all good. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From cwhittl at gmail.com Tue Apr 15 22:33:28 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Tue, 15 Apr 2014 17:33:28 -0500 Subject: [Freeipa-users] Updated Mavericks (MAC) Client setup or am I doing something wrong? Message-ID: <6e53824700b1267a3832075e5729eb@ip-10-0-3-140> An HTML attachment was scrubbed... URL: From barrykfl at gmail.com Wed Apr 16 02:34:09 2014 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Wed, 16 Apr 2014 10:34:09 +0800 Subject: [Freeipa-users] Handle openssl issue Message-ID: Dear all: http://heartbleed.com/ < openssl announced before. We use 3rd part official cert ref. to this and convert to pck12 format by openssl. ( centos 6.4 ipa 3.0) http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP any patch for ipa need to added or OS level ? Regards Barry -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan.f77 at gmail.com Wed Apr 16 02:39:19 2014 From: nathan.f77 at gmail.com (Nathan Broadbent) Date: Tue, 15 Apr 2014 19:39:19 -0700 Subject: [Freeipa-users] Handle openssl issue In-Reply-To: References: Message-ID: Hi Barry, FreeIPA only uses OpenSSL for some client libraries. The web server and CA components are not affected by heartbleed. Best, Nathan On Tue, Apr 15, 2014 at 7:34 PM, wrote: > Dear all: > > http://heartbleed.com/ < openssl announced before. > > We use 3rd part official cert ref. to this and convert to pck12 format by > openssl. ( centos 6.4 ipa 3.0) > > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > > any patch for ipa need to added or OS level ? > > > Regards > > Barry > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.kreuter at bytesource.net Wed Apr 16 18:08:38 2014 From: david.kreuter at bytesource.net (David Kreuter) Date: Wed, 16 Apr 2014 20:08:38 +0200 (CEST) Subject: [Freeipa-users] PasswordAuthentication option for SSH In-Reply-To: <6353ab6b-1e34-461d-86d2-38c701002601@zimbra.bytesource.net> Message-ID: <8b4314e6-fc2f-4981-950c-ff5c0b372a04@zimbra.bytesource.net> Hi, Today I faced the issue that Kerberos authentication stopped working after disabling PasswordAuthentication in /etc/ssh/sshd_config on a FreeIPA client. The deactivation of this option was done due to security issues. Is it really necessary to have this option set to yes when using Keberos authentication? IPA client 3.0.0 IPA server 3.3.2 Thanking you in advance. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From cto at sshchicago.org Wed Apr 16 18:40:47 2014 From: cto at sshchicago.org (Christopher Swingler) Date: Wed, 16 Apr 2014 13:40:47 -0500 Subject: [Freeipa-users] Running a FreeIPA replica in a limited-resource environment Message-ID: <6589E607-F886-4290-93C1-A6510AF2FA08@sshchicago.org> Hello, FreeIPA list. We're looking to start using FreeIPA to replace our standard 389 LDAP server on our public web server. That public web server also houses a public wiki, which currently authenticates against 389. We're running FreeIPA on site in our hackerspace, but are working toward a goal of a federated login system between all of our public and internal systems. My plan, as it stands, is to set up a VPN link between our public web server and our space, and set up a master-master replication between a FreeIPA server running onsite, and another on our public web server. The limitation I'm currently considering is that our public web server is limited on resources - it's a VM with 1GB of RAM, on which we're already running Apache, Mediawiki, and an IRC bot. The VM is currently donated by a member. We're a little crunched on resources as it is, and I fear that spinning up a full FreeIPA replica on that system may push us over the edge of resource constraints. Is it possible to tune FreeIPA to run with fewer resources, or replicate only the portions of it that we really need running remotely (just the LDAP server)? Thanks! Christopher Swingler CTO South Side Hackerspace Chicago 2233 South Throop St | Unit 214 | Chicago, IL 60608 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Apr 16 18:50:39 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 14:50:39 -0400 Subject: [Freeipa-users] PasswordAuthentication option for SSH In-Reply-To: <8b4314e6-fc2f-4981-950c-ff5c0b372a04@zimbra.bytesource.net> References: <8b4314e6-fc2f-4981-950c-ff5c0b372a04@zimbra.bytesource.net> Message-ID: <1397674239.19767.451.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 20:08 +0200, David Kreuter wrote: > Hi, > > > Today I faced the issue that Kerberos authentication stopped working > after disabling PasswordAuthentication in /etc/ssh/sshd_config on a > FreeIPA client. The deactivation of this option was done due to > security issues. > > > Is it really necessary to have this option set to yes when using > Keberos authentication? No, GSSAPI authentication does not need PasswordAuthentication, of course it requires valid kerberos credentials on the client and a valid keytab on the server. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Apr 16 18:56:39 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 14:56:39 -0400 Subject: [Freeipa-users] Running a FreeIPA replica in a limited-resource environment In-Reply-To: <6589E607-F886-4290-93C1-A6510AF2FA08@sshchicago.org> References: <6589E607-F886-4290-93C1-A6510AF2FA08@sshchicago.org> Message-ID: <1397674599.19767.456.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 13:40 -0500, Christopher Swingler wrote: > Hello, FreeIPA list. > > We're looking to start using FreeIPA to replace our standard 389 LDAP > server on our public web server. > > That public web server also houses a public wiki, which currently > authenticates against 389. We're running FreeIPA on site in our > hackerspace, but are working toward a goal of a federated login system > between all of our public and internal systems. > > My plan, as it stands, is to set up a VPN link between our public web > server and our space, and set up a master-master replication between a > FreeIPA server running onsite, and another on our public web server. > > The limitation I'm currently considering is that our public web server > is limited on resources - it's a VM with 1GB of RAM, on which we're > already running Apache, Mediawiki, and an IRC bot. The VM is currently > donated by a member. We're a little crunched on resources as it is, > and I fear that spinning up a full FreeIPA replica on that system may > push us over the edge of resource constraints. > > Is it possible to tune FreeIPA to run with fewer resources, or > replicate only the portions of it that we really need running remotely > (just the LDAP server)? If you avoid configureing the replica as a CA and a DNS server you'll have only a handful of services running, namely 389ds, krb5kdc, kadmind, httpd, ipa_memcahed. Unless you plan on doing maintenance via the public instance, what you could do is to manually turn off kadmind and ipa_memcached on that instance. The managment UI would sto pworking and you wouldn't be able to change password through that server so you may want to avoid advertizing it on your internal newtork, but it should otherwise work for authentication on your satellite VM. Note however that if you are replicating just to allow for redundancy in authentication what you could do instead is to use pam based authentication for your applications and use sssd on the system. Using password based authentication via pam/sssd would allow sssd to cache password hashes of the users and allow authentication even when the VPN link fails and would be much more lightweight. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From david.kreuter at bytesource.net Wed Apr 16 20:28:52 2014 From: david.kreuter at bytesource.net (David Kreuter) Date: Wed, 16 Apr 2014 22:28:52 +0200 (CEST) Subject: [Freeipa-users] PasswordAuthentication option for SSH In-Reply-To: <1397674239.19767.451.camel@willson.li.ssimo.org> Message-ID: <7d23415c-64c7-4173-99d2-b974c38fe1dd@zimbra.bytesource.net> On client side the valid Kerberos ticket is present. The following SSH configuration is used on the machine where the IPA client is running: /etc/ssh/sshd_config ---cut--- PasswordAuthentication yes KerberosAuthentication no PubkeyAuthentication yes UsePAM yes GSSAPIAuthentication yes AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys ---cut--- Just checked the machine again, password authentication is used as fallback, because the Keberos setup on this machine seems to be messed up. I have tried to uninstall the client and reinstalled it. During the installation I'm getting following message: "A RA is not configured on the server. Not requesting host certificate." Trying to request the certificate manually leads in: ipa-getcert request -d /etc/pki/nssdb -n Server-Cert -K HOST/ -N 'CN=,O=EXAMPLE.INFO' -v Error org.fedorahosted.certmonger.duplicate: Certificate at same location is already used by request with nickname "20140416200517" So to certificate is already there. Do you have some hints? ----- Original Message ----- From: "Simo Sorce" To: "David Kreuter" Cc: freeipa-users at redhat.com Sent: Wednesday, 16 April, 2014 8:50:39 PM Subject: Re: [Freeipa-users] PasswordAuthentication option for SSH On Wed, 2014-04-16 at 20:08 +0200, David Kreuter wrote: > Hi, > > > Today I faced the issue that Kerberos authentication stopped working > after disabling PasswordAuthentication in /etc/ssh/sshd_config on a > FreeIPA client. The deactivation of this option was done due to > security issues. > > > Is it really necessary to have this option set to yes when using > Keberos authentication? No, GSSAPI authentication does not need PasswordAuthentication, of course it requires valid kerberos credentials on the client and a valid keytab on the server. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Wed Apr 16 21:43:47 2014 From: sakodak at gmail.com (KodaK) Date: Wed, 16 Apr 2014 16:43:47 -0500 Subject: [Freeipa-users] sudo env_keep option Message-ID: I'm trying to specify env_keep variables. I can't seem to be able to pass more than one. env_keep=FOO works, env_keep="FOO BAR" does not. Specifying multiple env_keep options also doesn't work (I didn't expect it to.) Is there some special thing I'm missing? Thanks, --Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Wed Apr 16 21:57:59 2014 From: sakodak at gmail.com (KodaK) Date: Wed, 16 Apr 2014 16:57:59 -0500 Subject: [Freeipa-users] sudo env_keep option [solved] Message-ID: As usual, I figured this out pretty much as soon as I posted. Fix: separate options, but subsequent options need to be += EX: env_keep=FOO env_keep+=BAR --Jason On Wed, Apr 16, 2014 at 4:43 PM, KodaK wrote: > I'm trying to specify env_keep variables. I can't seem to be able to pass > more than one. > > env_keep=FOO > > works, > > env_keep="FOO BAR" > > does not. > > Specifying multiple env_keep options also doesn't work (I didn't expect it > to.) > > Is there some special thing I'm missing? > > Thanks, > > --Jason > -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Apr 16 22:06:05 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 18:06:05 -0400 Subject: [Freeipa-users] [SOLVED] Re: FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing. In-Reply-To: References: <1397568653.19767.289.camel@willson.li.ssimo.org> Message-ID: <1397685965.19767.471.camel@willson.li.ssimo.org> Good! And thanks for letting us know, it may help other users too. Simo. On Wed, 2014-04-16 at 17:58 -0400, Fredy Sanchez wrote: > Hi Simo, > > Thanks for your reply. Good old Google pointed me to > https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/open-ldap_bind_script/Mac_OpenLDAP_bind_script.sh, > which gave me the idea of > updating the RealName mapping to displayName. This solved the problem, I'll > have to recreate the permissions for every share, but the user names now > show up, and stick. No more UIDs. > > > On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce wrote: > > > On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: > > > Hi all, > > > > > > We asked this same question at discussions.apple.com, but figured we'd > > have > > > better luck here. I apologize in advance if this is the wrong forum. > > > > > > We are switching from Synology (DSM 5) to Mavericks server (v3.1.1. > > running > > > in Mavericks 10.9.2) for File Sharing. We use a FreeIPA > > (ipa-server.x86_64 > > > 3.0.0-37.el6) backend for SSO, and the Mac server seems correctly > > > bound to it. Unfortunately, although we can add usernames to the shares > > for > > > the initial config, the usernames transform to UIDs after (only for SSO > > > accounts; local accounts are not affected). That is, when we go to edit > > the > > > permissions for a share, all we see are UIDs. We can always figure out > > the > > > username from the UID, but this is an extra step we don't want to have. > > > We've tried reinstalling the Mac server app from scratch, re-binding to > > the > > > FreeIPA backend, changing mappings in Directory Utility (for example, > > > mapping GeneratedUID to uid, which is the username), recreating the > > shares > > > and permissions, etc. Here are more details about the binding: > > > > > > * The binding happens thru a custom package we created based primarily on > > > > > http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 > > > * Sys Prefs, Users & Groups, Login Options show the server bound to the > > > FreeIPA backend with the green dot > > > * The following mappings are in place in Directory Utility, Services, > > > LDAPv3, FreeIPA backend > > > > > > Users: inetOrgPerson > > > AuthenticationAuthority: uid > > > GeneratedUID: random number in uppercase > > > HomeDirectory: #/Users/$uid$ > > > NFSHomeDirectory: #/Users/$uid$ > > > OriginalHomeDirectory: #/Users/$uid$ > > > PrimaryGroupID: gidNumber > > > RealName: cn > > > RecordName: uid > > > UniqueID: uidNumber > > > UserShell: loginShell > > > Groups: posixgroup > > > PrimaryGroupID: gidNumber > > > RecordName: cn > > > > > > The search bases are correct > > > > > > * Directory Utility, Directory Editor shows the right info for the users. > > > * $ id $USERNAME shows the right information for the user > > > > > > FreeIPA is working beautifully for our Mac / Linux environment. We > > provide > > > directory services to about 300 hosts, and 200 employees using it; and > > > haven't had any problems LDAP wise until now. So we think we are missing > > a > > > mapping here. Any ideas? > > > > Fredy, > > I quickly tried to check for some documentation on how to configure this > > stuff, but found only useless superficial guides on how to find the > > pointy/clicky buttons to push to enable the service. > > > > I am not a Mac expert by a long shot so I cannot help you much here. > > > > Is there any guide available on how to use this service with other LDAP > > servers, like openLDAP or Active Directory ? We can probably draw some > > conclusions from there. > > > > Simo. > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > > > > > -- Simo Sorce * Red Hat, Inc * New York From fredy.sanchez at modmed.com Wed Apr 16 21:58:19 2014 From: fredy.sanchez at modmed.com (Fredy Sanchez) Date: Wed, 16 Apr 2014 17:58:19 -0400 Subject: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing. In-Reply-To: <1397568653.19767.289.camel@willson.li.ssimo.org> References: <1397568653.19767.289.camel@willson.li.ssimo.org> Message-ID: Hi Simo, Thanks for your reply. Good old Google pointed me to https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/open-ldap_bind_script/Mac_OpenLDAP_bind_script.sh, which gave me the idea of updating the RealName mapping to displayName. This solved the problem, I'll have to recreate the permissions for every share, but the user names now show up, and stick. No more UIDs. On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce wrote: > On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: > > Hi all, > > > > We asked this same question at discussions.apple.com, but figured we'd > have > > better luck here. I apologize in advance if this is the wrong forum. > > > > We are switching from Synology (DSM 5) to Mavericks server (v3.1.1. > running > > in Mavericks 10.9.2) for File Sharing. We use a FreeIPA > (ipa-server.x86_64 > > 3.0.0-37.el6) backend for SSO, and the Mac server seems correctly > > bound to it. Unfortunately, although we can add usernames to the shares > for > > the initial config, the usernames transform to UIDs after (only for SSO > > accounts; local accounts are not affected). That is, when we go to edit > the > > permissions for a share, all we see are UIDs. We can always figure out > the > > username from the UID, but this is an extra step we don't want to have. > > We've tried reinstalling the Mac server app from scratch, re-binding to > the > > FreeIPA backend, changing mappings in Directory Utility (for example, > > mapping GeneratedUID to uid, which is the username), recreating the > shares > > and permissions, etc. Here are more details about the binding: > > > > * The binding happens thru a custom package we created based primarily on > > > http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 > > * Sys Prefs, Users & Groups, Login Options show the server bound to the > > FreeIPA backend with the green dot > > * The following mappings are in place in Directory Utility, Services, > > LDAPv3, FreeIPA backend > > > > Users: inetOrgPerson > > AuthenticationAuthority: uid > > GeneratedUID: random number in uppercase > > HomeDirectory: #/Users/$uid$ > > NFSHomeDirectory: #/Users/$uid$ > > OriginalHomeDirectory: #/Users/$uid$ > > PrimaryGroupID: gidNumber > > RealName: cn > > RecordName: uid > > UniqueID: uidNumber > > UserShell: loginShell > > Groups: posixgroup > > PrimaryGroupID: gidNumber > > RecordName: cn > > > > The search bases are correct > > > > * Directory Utility, Directory Editor shows the right info for the users. > > * $ id $USERNAME shows the right information for the user > > > > FreeIPA is working beautifully for our Mac / Linux environment. We > provide > > directory services to about 300 hosts, and 200 employees using it; and > > haven't had any problems LDAP wise until now. So we think we are missing > a > > mapping here. Any ideas? > > Fredy, > I quickly tried to check for some documentation on how to configure this > stuff, but found only useless superficial guides on how to find the > pointy/clicky buttons to push to enable the service. > > I am not a Mac expert by a long shot so I cannot help you much here. > > Is there any guide available on how to use this service with other LDAP > servers, like openLDAP or Active Directory ? We can probably draw some > conclusions from there. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine (561) 880-2998 x237 fredy.sanchez at modmed.com *Need IT support?* Visit https://mmit.zendesk.com - - -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.kreuter at bytesource.net Wed Apr 16 22:11:11 2014 From: david.kreuter at bytesource.net (David Kreuter) Date: Thu, 17 Apr 2014 00:11:11 +0200 (CEST) Subject: [Freeipa-users] Keberos authentication - Unspecified GSS failure In-Reply-To: <93622cdf-5ecb-4036-a2ac-3e0709efdb6f@zimbra.bytesource.net> Message-ID: Yesterday I installed the FreeIPA client on machine and after the installation the login with password worked fine. After that I tried to login with a valid Kerberos ticket and it failed. First i traced the ssh login: ssh -vvv david at test.example.com ---cut--- debug2: key: /home/david/.ssh/id_rsa (0x7f2ad3112d80), debug2: key: /home/david/.ssh/id_dsa ((nil)), debug2: key: /home/david/.ssh/id_ecdsa ((nil)), debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-keyex debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-keyex debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug2: we did not send a packet, disable method debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/david/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug1: Trying private key: /home/david/.ssh/id_dsa debug3: no such identity: /home/david/.ssh/id_dsa: No such file or directory debug1: Trying private key: /home/david/.ssh/id_ecdsa debug3: no such identity: /home/david/.ssh/id_ecdsa: No such file or directory debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey,gssapi-keyex,gssapi-with-mic). ---cut--- Then I enabled the log for SSH on the IPA client machine and faced following error: ---cut--- Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 0 failures 0 Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: initializing for "david" Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_RHOST to "10.100.3.2" Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_TTY to "ssh" Apr 16 23:43:18 infra01 sshd[9941]: debug1: userauth-request for user david service ssh-connection method gssapi-with-mic Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 1 failures 0 Apr 16 23:43:18 infra01 sshd[9940]: debug1: Unspecified GSS failure. Minor code may provide more information\nNo key table entry found matching host/infra01@\n ---cut--- Unspecified GSS failure. Minor code may provide more information.No key table entry found matching host/infra01@\n. After that I tried to receive a ticket on the IPA client machine and everything worked fine: kinit klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: david@.INFO Valid starting Expires Service principal 04/16/14 23:24:51 04/17/14 23:24:47 krbtgt/... 04/16/14 23:25:51 04/17/14 23:24:47 host/... kvno -k /etc/krb5.keytab host/... host/...: kvno = 1, keytab entry valid So the Kerberos setup on the machine seems to be fine, but still the login SSH using Keberos is not working. GSSAPI is correctly enabled in the sshd configuration file. Any hint is highly appreciated. Thanks. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Apr 16 22:12:06 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 16 Apr 2014 18:12:06 -0400 Subject: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing. In-Reply-To: References: <1397568653.19767.289.camel@willson.li.ssimo.org> Message-ID: <534F0036.6070101@redhat.com> Fredy Sanchez wrote: > Hi Simo, > > Thanks for your reply. Good old Google pointed me to > https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/open-l > dap_bind_script/Mac_OpenLDAP_bind_script.sh, which gave me the idea of > updating the RealName mapping to displayName. This solved the problem, > I'll have to recreate the permissions for every share, but the user > names now show up, and stick. No more UIDs. Great. Any chance you can write something and post a howto on our wiki? Or send the details to me and I'll write something up? thanks rob > > > On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce > wrote: > > On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: > > Hi all, > > > > We asked this same question at discussions.apple.com > , but figured we'd have > > better luck here. I apologize in advance if this is the wrong forum. > > > > We are switching from Synology (DSM 5) to Mavericks server > (v3.1.1. running > > in Mavericks 10.9.2) for File Sharing. We use a FreeIPA > (ipa-server.x86_64 > > 3.0.0-37.el6) backend for SSO, and the Mac server seems > correctly > > bound to it. Unfortunately, although we can add usernames to the > shares for > > the initial config, the usernames transform to UIDs after (only > for SSO > > accounts; local accounts are not affected). That is, when we go > to edit the > > permissions for a share, all we see are UIDs. We can always > figure out the > > username from the UID, but this is an extra step we don't want to > have. > > We've tried reinstalling the Mac server app from scratch, > re-binding to the > > FreeIPA backend, changing mappings in Directory Utility (for example, > > mapping GeneratedUID to uid, which is the username), recreating > the shares > > and permissions, etc. Here are more details about the binding: > > > > * The binding happens thru a custom package we created based > primarily on > > > http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 > > * Sys Prefs, Users & Groups, Login Options show the server bound > to the > > FreeIPA backend with the green dot > > * The following mappings are in place in Directory Utility, Services, > > LDAPv3, FreeIPA backend > > > > Users: inetOrgPerson > > AuthenticationAuthority: uid > > GeneratedUID: random number in uppercase > > HomeDirectory: #/Users/$uid$ > > NFSHomeDirectory: #/Users/$uid$ > > OriginalHomeDirectory: #/Users/$uid$ > > PrimaryGroupID: gidNumber > > RealName: cn > > RecordName: uid > > UniqueID: uidNumber > > UserShell: loginShell > > Groups: posixgroup > > PrimaryGroupID: gidNumber > > RecordName: cn > > > > The search bases are correct > > > > * Directory Utility, Directory Editor shows the right info for > the users. > > * $ id $USERNAME shows the right information for the user > > > > FreeIPA is working beautifully for our Mac / Linux environment. > We provide > > directory services to about 300 hosts, and 200 employees using > it; and > > haven't had any problems LDAP wise until now. So we think we are > missing a > > mapping here. Any ideas? > > Fredy, > I quickly tried to check for some documentation on how to configure this > stuff, but found only useless superficial guides on how to find the > pointy/clicky buttons to push to enable the service. > > I am not a Mac expert by a long shot so I cannot help you much here. > > Is there any guide available on how to use this service with other LDAP > servers, like openLDAP or Active Directory ? We can probably draw some > conclusions from there. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > > > > -- > Cheers, > > Fredy Sanchez > IT Manager @ Modernizing Medicine > (561) 880-2998 x237 > fredy.sanchez at modmed.com > > *Need IT support?* Visit https://mmit.zendesk.com > > > * > > > * * > * > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From rcritten at redhat.com Wed Apr 16 22:13:48 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 16 Apr 2014 18:13:48 -0400 Subject: [Freeipa-users] Keberos authentication - Unspecified GSS failure In-Reply-To: References: Message-ID: <534F009C.1090806@redhat.com> David Kreuter wrote: > Yesterday I installed the FreeIPA client on machine and after the > installation the login with password worked fine. After that I tried to > login with a valid Kerberos ticket and it failed. First i traced the ssh > login: > > ssh -vvv david at test.example.com > ---cut--- > debug2: key: /home/david/.ssh/id_rsa (0x7f2ad3112d80), > debug2: key: /home/david/.ssh/id_dsa ((nil)), > debug2: key: /home/david/.ssh/id_ecdsa ((nil)), > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic > debug3: start over, passed a different list > publickey,gssapi-keyex,gssapi-with-mic > debug3: preferred > gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password > debug3: authmethod_lookup gssapi-keyex > debug3: remaining preferred: > gssapi-with-mic,publickey,keyboard-interactive,password > debug3: authmethod_is_enabled gssapi-keyex > debug1: Next authentication method: gssapi-keyex > debug1: No valid Key exchange context > debug2: we did not send a packet, disable method > debug3: authmethod_lookup gssapi-with-mic > debug3: remaining preferred: publickey,keyboard-interactive,password > debug3: authmethod_is_enabled gssapi-with-mic > debug1: Next authentication method: gssapi-with-mic > debug2: we sent a gssapi-with-mic packet, wait for reply > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic > debug2: we sent a gssapi-with-mic packet, wait for reply > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic > debug2: we sent a gssapi-with-mic packet, wait for reply > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic > debug2: we sent a gssapi-with-mic packet, wait for reply > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic > debug2: we did not send a packet, disable method > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Offering RSA public key: /home/david/.ssh/id_rsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic > debug1: Trying private key: /home/david/.ssh/id_dsa > debug3: no such identity: /home/david/.ssh/id_dsa: No such file or directory > debug1: Trying private key: /home/david/.ssh/id_ecdsa > debug3: no such identity: /home/david/.ssh/id_ecdsa: No such file or > directory > debug2: we did not send a packet, disable method > debug1: No more authentication methods to try. > Permission denied (publickey,gssapi-keyex,gssapi-with-mic). > ---cut--- > > Then I enabled the log for SSH on the IPA client machine and faced > following error: > > ---cut--- > Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 0 failures 0 > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: initializing for "david" > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_RHOST to > "10.100.3.2" > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_TTY to "ssh" > Apr 16 23:43:18 infra01 sshd[9941]: debug1: userauth-request for user > david service ssh-connection method gssapi-with-mic > Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 1 failures 0 > Apr 16 23:43:18 infra01 sshd[9940]: debug1: Unspecified GSS failure. > Minor code may provide more information\nNo key table entry found > matching host/infra01@\n > ---cut--- > > Unspecified GSS failure. Minor code may provide more information.No key > table entry found matching host/infra01@\n. > > After that I tried to receive a ticket on the IPA client machine and > everything worked fine: > > kinit > klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: david@.INFO > > Valid starting Expires Service principal > 04/16/14 23:24:51 04/17/14 23:24:47 krbtgt/... > 04/16/14 23:25:51 04/17/14 23:24:47 host/... > > kvno -k /etc/krb5.keytab host/... > host/...: kvno = 1, keytab entry valid > > So the Kerberos setup on the machine seems to be fine, but still the > login SSH using Keberos is not working. GSSAPI is correctly enabled in > the sshd configuration file. Any hint is highly appreciated. Thanks. > Seems like sshd looked for the wrong key. Run klist -kt /etc/krb5.keytab and see what principal is there. sshd didn't look for a FQDN according to your log. rob From simo at redhat.com Wed Apr 16 22:18:42 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 18:18:42 -0400 Subject: [Freeipa-users] Keberos authentication - Unspecified GSS failure In-Reply-To: <534F009C.1090806@redhat.com> References: <534F009C.1090806@redhat.com> Message-ID: <1397686722.19767.476.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 18:13 -0400, Rob Crittenden wrote: > David Kreuter wrote: > > Yesterday I installed the FreeIPA client on machine and after the > > installation the login with password worked fine. After that I tried to > > login with a valid Kerberos ticket and it failed. First i traced the ssh > > login: > > > > ssh -vvv david at test.example.com > > ---cut--- > > debug2: key: /home/david/.ssh/id_rsa (0x7f2ad3112d80), > > debug2: key: /home/david/.ssh/id_dsa ((nil)), > > debug2: key: /home/david/.ssh/id_ecdsa ((nil)), > > debug1: Authentications that can continue: > > publickey,gssapi-keyex,gssapi-with-mic > > debug3: start over, passed a different list > > publickey,gssapi-keyex,gssapi-with-mic > > debug3: preferred > > gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password > > debug3: authmethod_lookup gssapi-keyex > > debug3: remaining preferred: > > gssapi-with-mic,publickey,keyboard-interactive,password > > debug3: authmethod_is_enabled gssapi-keyex > > debug1: Next authentication method: gssapi-keyex > > debug1: No valid Key exchange context > > debug2: we did not send a packet, disable method > > debug3: authmethod_lookup gssapi-with-mic > > debug3: remaining preferred: publickey,keyboard-interactive,password > > debug3: authmethod_is_enabled gssapi-with-mic > > debug1: Next authentication method: gssapi-with-mic > > debug2: we sent a gssapi-with-mic packet, wait for reply > > debug1: Authentications that can continue: > > publickey,gssapi-keyex,gssapi-with-mic > > debug2: we sent a gssapi-with-mic packet, wait for reply > > debug1: Authentications that can continue: > > publickey,gssapi-keyex,gssapi-with-mic > > debug2: we sent a gssapi-with-mic packet, wait for reply > > debug1: Authentications that can continue: > > publickey,gssapi-keyex,gssapi-with-mic > > debug2: we sent a gssapi-with-mic packet, wait for reply > > debug1: Authentications that can continue: > > publickey,gssapi-keyex,gssapi-with-mic > > debug2: we did not send a packet, disable method > > debug3: authmethod_lookup publickey > > debug3: remaining preferred: keyboard-interactive,password > > debug3: authmethod_is_enabled publickey > > debug1: Next authentication method: publickey > > debug1: Offering RSA public key: /home/david/.ssh/id_rsa > > debug3: send_pubkey_test > > debug2: we sent a publickey packet, wait for reply > > debug1: Authentications that can continue: > > publickey,gssapi-keyex,gssapi-with-mic > > debug1: Trying private key: /home/david/.ssh/id_dsa > > debug3: no such identity: /home/david/.ssh/id_dsa: No such file or directory > > debug1: Trying private key: /home/david/.ssh/id_ecdsa > > debug3: no such identity: /home/david/.ssh/id_ecdsa: No such file or > > directory > > debug2: we did not send a packet, disable method > > debug1: No more authentication methods to try. > > Permission denied (publickey,gssapi-keyex,gssapi-with-mic). > > ---cut--- > > > > Then I enabled the log for SSH on the IPA client machine and faced > > following error: > > > > ---cut--- > > Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 0 failures 0 > > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: initializing for "david" > > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_RHOST to > > "10.100.3.2" > > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_TTY to "ssh" > > Apr 16 23:43:18 infra01 sshd[9941]: debug1: userauth-request for user > > david service ssh-connection method gssapi-with-mic > > Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 1 failures 0 > > Apr 16 23:43:18 infra01 sshd[9940]: debug1: Unspecified GSS failure. > > Minor code may provide more information\nNo key table entry found > > matching host/infra01@\n > > ---cut--- > > > > Unspecified GSS failure. Minor code may provide more information.No key > > table entry found matching host/infra01@\n. > > > > After that I tried to receive a ticket on the IPA client machine and > > everything worked fine: > > > > kinit > > klist > > Ticket cache: FILE:/tmp/krb5cc_0 > > Default principal: david@.INFO > > > > Valid starting Expires Service principal > > 04/16/14 23:24:51 04/17/14 23:24:47 krbtgt/... > > 04/16/14 23:25:51 04/17/14 23:24:47 host/... > > > > kvno -k /etc/krb5.keytab host/... > > host/...: kvno = 1, keytab entry valid > > > > So the Kerberos setup on the machine seems to be fine, but still the > > login SSH using Keberos is not working. GSSAPI is correctly enabled in > > the sshd configuration file. Any hint is highly appreciated. Thanks. > > > > Seems like sshd looked for the wrong key. Run klist -kt /etc/krb5.keytab > and see what principal is there. sshd didn't look for a FQDN according > to your log. FYI: If your hosts for some reason has a non qualified name and you can't fix the issue due to some other broken software requiring short, unqualified, hostnames, you can look into setting the following in krb5.conf: ignore_acceptor_hostname = true Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Apr 17 06:47:40 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Apr 2014 08:47:40 +0200 Subject: [Freeipa-users] Running a FreeIPA replica in a limited-resource environment In-Reply-To: <1397674599.19767.456.camel@willson.li.ssimo.org> References: <6589E607-F886-4290-93C1-A6510AF2FA08@sshchicago.org> <1397674599.19767.456.camel@willson.li.ssimo.org> Message-ID: <534F790C.4050203@redhat.com> On 04/16/2014 08:56 PM, Simo Sorce wrote: > On Wed, 2014-04-16 at 13:40 -0500, Christopher Swingler wrote: >> Hello, FreeIPA list. >> >> We're looking to start using FreeIPA to replace our standard 389 LDAP >> server on our public web server. >> >> That public web server also houses a public wiki, which currently >> authenticates against 389. We're running FreeIPA on site in our >> hackerspace, but are working toward a goal of a federated login system >> between all of our public and internal systems. >> >> My plan, as it stands, is to set up a VPN link between our public web >> server and our space, and set up a master-master replication between a >> FreeIPA server running onsite, and another on our public web server. >> >> The limitation I'm currently considering is that our public web server >> is limited on resources - it's a VM with 1GB of RAM, on which we're >> already running Apache, Mediawiki, and an IRC bot. The VM is currently >> donated by a member. We're a little crunched on resources as it is, >> and I fear that spinning up a full FreeIPA replica on that system may >> push us over the edge of resource constraints. >> >> Is it possible to tune FreeIPA to run with fewer resources, or >> replicate only the portions of it that we really need running remotely >> (just the LDAP server)? > > If you avoid configureing the replica as a CA and a DNS server you'll > have only a handful of services running, namely 389ds, krb5kdc, kadmind, > httpd, ipa_memcahed. > > Unless you plan on doing maintenance via the public instance, what you > could do is to manually turn off kadmind and ipa_memcached on that > instance. The managment UI would sto pworking and you wouldn't be able > to change password through that server so you may want to avoid > advertizing it on your internal newtork, but it should otherwise work > for authentication on your satellite VM. > > Note however that if you are replicating just to allow for redundancy in > authentication what you could do instead is to use pam based > authentication for your applications and use sssd on the system. Using > password based authentication via pam/sssd would allow sssd to cache > password hashes of the users and allow authentication even when the VPN > link fails and would be much more lightweight. > > HTH, > Simo. > Right. This may be a job for the Web App Authentication modules we have been working on: http://www.freeipa.org/page/Web_App_Authentication If wiki is running on apache, I am thinking the central authentication could be solved with mod_intercept_form_submit or extensions based on authentication via REMOTE_USER, like http://www.mediawiki.org/wiki/Extension:AutomaticREMOTE_USER If this is not something that does not work for you, stripped down FreeIPA + LDAP authentication plugin should work: http://www.mediawiki.org/wiki/Extension:LDAP_Authentication Martin From fredy.sanchez at modmed.com Wed Apr 16 22:40:48 2014 From: fredy.sanchez at modmed.com (Fredy Sanchez) Date: Wed, 16 Apr 2014 18:40:48 -0400 Subject: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing. In-Reply-To: <534F0036.6070101@redhat.com> References: <1397568653.19767.289.camel@willson.li.ssimo.org> <534F0036.6070101@redhat.com> Message-ID: Sure Rob, we'll put something together and send it to you for publishing. Give us a few days. We'll also sanitize our enrollment package and share it w/ you too. This is what we use to enroll our Macs, a one time install that does what ipa-client-install does for Linux, including these LDAP mappings. We love FreeIPA and will be really happy if this helps any other users with Mac fleets. On Wed, Apr 16, 2014 at 6:12 PM, Rob Crittenden wrote: > Fredy Sanchez wrote: > >> Hi Simo, >> >> Thanks for your reply. Good old Google pointed me to >> https://github.com/rtrouton/rtrouton_scripts/blob/master/ >> rtrouton_scripts/open-l >> dap_bind_script/Mac_OpenLDAP_bind_script.sh, which gave me the idea of >> updating the RealName mapping to displayName. This solved the problem, >> I'll have to recreate the permissions for every share, but the user >> names now show up, and stick. No more UIDs. >> > > Great. Any chance you can write something and post a howto on our wiki? Or > send the details to me and I'll write something up? > > thanks > > rob > > >> >> On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce > > wrote: >> >> On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: >> > Hi all, >> > >> > We asked this same question at discussions.apple.com >> , but figured we'd have >> >> > better luck here. I apologize in advance if this is the wrong >> forum. >> > >> > We are switching from Synology (DSM 5) to Mavericks server >> (v3.1.1. running >> > in Mavericks 10.9.2) for File Sharing. We use a FreeIPA >> (ipa-server.x86_64 >> > 3.0.0-37.el6) backend for SSO, and the Mac server seems >> correctly >> > bound to it. Unfortunately, although we can add usernames to the >> shares for >> > the initial config, the usernames transform to UIDs after (only >> for SSO >> > accounts; local accounts are not affected). That is, when we go >> to edit the >> > permissions for a share, all we see are UIDs. We can always >> figure out the >> > username from the UID, but this is an extra step we don't want to >> have. >> > We've tried reinstalling the Mac server app from scratch, >> re-binding to the >> > FreeIPA backend, changing mappings in Directory Utility (for >> example, >> > mapping GeneratedUID to uid, which is the username), recreating >> the shares >> > and permissions, etc. Here are more details about the binding: >> > >> > * The binding happens thru a custom package we created based >> primarily on >> > >> http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7. >> 2F10.8 >> > * Sys Prefs, Users & Groups, Login Options show the server bound >> to the >> > FreeIPA backend with the green dot >> > * The following mappings are in place in Directory Utility, >> Services, >> > LDAPv3, FreeIPA backend >> > >> > Users: inetOrgPerson >> > AuthenticationAuthority: uid >> > GeneratedUID: random number in uppercase >> > HomeDirectory: #/Users/$uid$ >> > NFSHomeDirectory: #/Users/$uid$ >> > OriginalHomeDirectory: #/Users/$uid$ >> > PrimaryGroupID: gidNumber >> > RealName: cn >> > RecordName: uid >> > UniqueID: uidNumber >> > UserShell: loginShell >> > Groups: posixgroup >> > PrimaryGroupID: gidNumber >> > RecordName: cn >> > >> > The search bases are correct >> > >> > * Directory Utility, Directory Editor shows the right info for >> the users. >> > * $ id $USERNAME shows the right information for the user >> > >> > FreeIPA is working beautifully for our Mac / Linux environment. >> We provide >> > directory services to about 300 hosts, and 200 employees using >> it; and >> > haven't had any problems LDAP wise until now. So we think we are >> missing a >> > mapping here. Any ideas? >> >> Fredy, >> I quickly tried to check for some documentation on how to configure >> this >> stuff, but found only useless superficial guides on how to find the >> pointy/clicky buttons to push to enable the service. >> >> I am not a Mac expert by a long shot so I cannot help you much here. >> >> Is there any guide available on how to use this service with other >> LDAP >> servers, like openLDAP or Active Directory ? We can probably draw some >> conclusions from there. >> >> Simo. >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> >> >> >> -- >> Cheers, >> >> Fredy Sanchez >> IT Manager @ Modernizing Medicine >> (561) 880-2998 x237 >> fredy.sanchez at modmed.com >> >> *Need IT support?* Visit https://mmit.zendesk.com >> >> >> * >> >> >> * * >> * >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine (561) 880-2998 x237 fredy.sanchez at modmed.com *Need IT support?* Visit https://mmit.zendesk.com - - -------------- next part -------------- An HTML attachment was scrubbed... URL: From wxu.hccl at gmail.com Thu Apr 17 13:42:12 2014 From: wxu.hccl at gmail.com (Will Last) Date: Thu, 17 Apr 2014 21:42:12 +0800 Subject: [Freeipa-users] nothing sync'ed to AD Message-ID: Hi, I have got a freeipa server (pa-server-3.0.0-37) running on centos 6.5 and am trying to set up sync with/to AD on win 2008/R2, basically following https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory.html. The sync agreement is bi-directional by default. But only AD users are sync'ed to freeipa and none of the users on freeipa is sync'ed to ad, which is what I really cared for. Even a re-initialization from AD won't help (ipa-replica-manage re-initialize --from ad.example.com ). I have turned debugging on (nsslapd-errorlog-level to 8192), but did not see any obvious clue. Thanks in advance for any help! -Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Apr 17 14:16:33 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Apr 2014 10:16:33 -0400 Subject: [Freeipa-users] nothing sync'ed to AD In-Reply-To: References: Message-ID: <534FE241.7070602@redhat.com> Will Last wrote: > Hi, > > I have got a freeipa server (pa-server-3.0.0-37) running on centos 6.5 > and am trying to set up sync with/to AD on win 2008/R2, basically > following > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory.html. > The sync agreement is bi-directional by default. But only AD users are > sync'ed to freeipa and none of the users on freeipa is sync'ed to ad, > which is what I really cared for. Even a re-initialization from AD won't > help (ipa-replica-manage re-initialize --from ad.example.com > ). I have turned debugging on > (nsslapd-errorlog-level to 8192), but did not see any obvious clue. > > Thanks in advance for any help! This is working as designed. IPA-only users are not synced to AD. The bidirectional part is that changes to an AD user synced to IPA on the IPA side will be synced back to AD. rob From pspacek at redhat.com Thu Apr 17 16:17:23 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 17 Apr 2014 18:17:23 +0200 Subject: [Freeipa-users] nothing sync'ed to AD In-Reply-To: <534FE241.7070602@redhat.com> References: <534FE241.7070602@redhat.com> Message-ID: <534FFE93.4040202@redhat.com> On 17.4.2014 16:16, Rob Crittenden wrote: > Will Last wrote: >> Hi, >> >> I have got a freeipa server (pa-server-3.0.0-37) running on centos 6.5 >> and am trying to set up sync with/to AD on win 2008/R2, basically >> following >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory.html. >> >> The sync agreement is bi-directional by default. But only AD users are >> sync'ed to freeipa and none of the users on freeipa is sync'ed to ad, >> which is what I really cared for. Even a re-initialization from AD won't >> help (ipa-replica-manage re-initialize --from ad.example.com >> ). I have turned debugging on >> (nsslapd-errorlog-level to 8192), but did not see any obvious clue. >> >> Thanks in advance for any help! > > This is working as designed. IPA-only users are not synced to AD. The > bidirectional part is that changes to an AD user synced to IPA on the IPA side > will be synced back to AD. Maybe you will be more interested in http://www.freeipa.org/page/Trusts Let us know if you have any question! -- Petr^2 Spacek From lincoln.fessenden at jefferson.edu Thu Apr 17 17:52:42 2014 From: lincoln.fessenden at jefferson.edu (Lincoln Fessenden) Date: Thu, 17 Apr 2014 13:52:42 -0400 Subject: [Freeipa-users] Client Install - I'm clueless Message-ID: <20140417175239.GA3558@lcf004.edison.tju.edu> Hi folks! First time I played with this was yesterday so forgive me if I am way behind the median user here. I installed the server twice, both times on RHEL 6.5. Seems to work just fine and the install goes smooth. First install of the client was on a RHEL 7 beta machine, which worked but I could not get server exclusion rules working (all or nothing), hence the server reinstall. Next I tried ipa-client on a brand new RHEL 6.5 box. This will NOT complete installation and the same is true for 5.10. Different errors though. 6.5 errors out after sending xml to the ipa-server and 5.10 right after I provide the domain name. Since both of these machines are new installs and current for the release, I have got to believe I am missing something somewhere - some missing software dependency? I almost never have seen software in the enterprise repository that is just broken... Help? -- Lincoln Fessenden Jeff-IT Production Operations Manager Senior Linux Systems Administrator 215-503-0986 The information contained in this transmission contains privileged and confidential information. It is intended only for the use of the person named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CAUTION: Intended recipients should NOT use email communication for emergent or urgent health care matters. From dpal at redhat.com Thu Apr 17 18:16:29 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 17 Apr 2014 14:16:29 -0400 Subject: [Freeipa-users] External Collaboration Domains In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E6AB133@001FSN2MPN1-044.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net> <5333519A.2060206@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net> <20140330182619.GA19628@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net> <53389BEA.9050905@redhat.com> <20140408133456.GR20958@redhat.com> <5343FCC6.10209@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A7E8E@001FSN2MPN1-045.001f.mgd2.msft.net> <534489E9.9090809@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8756@001FSN2MPN1-045.001f.mgd2.msft.net> <534729DA.2070003@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8B5B@001FSN2MPN1-045.001f.mgd2.msft.net> <53486581.9020906@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6A8C10@001FSN2MPN1-045.001f.mgd2.msft.net> <534A8F6A.9090708@redhat.com> <534BB70E.4020303@redhat.com> <1397483626.19767.242.camel@willson.li.ssimo.org> <82E7C9A01FD0764CACDD35D10F5DFB6E6AB133@001FSN2MPN1-044.001f.mgd2.msft! .net> Message-ID: <53501A7D.7010008@redhat.com> On 04/15/2014 06:05 PM, Nordgren, Bryce L -FS wrote: >>> Variant (A) - IdP + PKINIT: >>> A1) User authenticates to his SAML/OpenID provider (external domain) >>> A2) User locally generates CSR >>> A3) User contacts IdP (gssapi/saml ; gssapi/openid) and sends CSR to >>> the IdP >>> A4) IdP returns short-lived certificate (validity period matches >>> policy for TGT) >>> A5) User presents certificate issued by IdP to KDC >>> A6) KDC authenticates user via PKINIT and issues TGT as usual >>> >>> This variant doesn't require any change to Kerberos protocol. It needs >>> IdP with CA + some client software automating described steps. >>> >>> >>> Variant (B) - IdP without PKINIT is almost the same, just uses symmetric >> crypto: >>> A1) User authenticates to his SAML/OpenID provider (external domain) >>> A2) User contacts IdP (gssapi/saml ; gssapi/openid) and sends >>> authentication request >>> A4) IdP changes principal password to some random value and sends >>> keytab back to the user (via GSSAPI-secured connection) >>> A5) User uses keytab to get TGT from KDC >>> >>> Obvious problem is that keytab received by user has to be short-lived. >>> For example, IdP could generate a new random password for user >>> principal 1 minute after sending keytab to the user. > Interesting notion. My understanding of B is that KDC would need an entry for the user in order to store the shared secret. This may "interact" with the principal name mapping in some hard-to-understand-right-now ways. For instance: > > KDC manages "EXAMPLE.ORG". > > User is coming in from google openID account. Pretend "mapped" Kerberos principal is: username at OPENID:www.google.com/openid/provider/url > > Can the KDC for EXAMPLE.ORG store that? I can see approach A working because the user principal doesn't have to exist in the KDC. Seems like case "B" involves a shared secret between external user and the local KDC, whereas approach A doesn't. > > I would vote for making the lifetime of the shared secret be derived from the lifetime of the credential the person used to get it. (if the openID session is good for 12 hours, the keytab should be too.) I don't see a need to null out the keytab after one minute. > >>> This could work if the whole process should be automated. >> http://www.umich.edu/~x509/ >> >> I already have a plan to implement this in Ipsilon eventually :-) > > +1 > +1 > > Perhaps the NSCA MyProxy CA also has some ideas worth implementing? It seems to be geared to a full-on PKI environment, where it issues derived (proxy) certificates for users to use in a login session. It appears that it could make kx509 certs as it is configurable w.r.t. what fields appear in the generated certificates and how identities are mapped. Also, it has client side programs for certificate storage and retrieval. Some concepts may be worth stealing. :) We already stole Dogtag. We will enable user certs support there. It is the question of time and resources. > Overall, it appears to me that short-lived certs (approach A) have a certain time-tested feel to them earned by many years of regular use captured in RFC3820. Approach A, in the parlance of RFC3820, could potentially be expressed as "External users delegate to a local Kerberos session the right to use their non-Kerberos identity by causing a proxy kx509 certificate to be issued." The cross-technology aspect makes the wording weird, since you rarely consider self-delegation to be delegation. The only real addition here is the use of the proxy certificates to gain entry to the local Kerberos universe. > > Short-lived "long term secrets" don't have this pedigree. Also, not real fond of transmitting the shared secret over the network, as required by B (even if it is a one-time-use thing. Makes me twitchy.) For that reason I might lean towards approach A, but would be happy with either. > > Approach A has the client map the identities to generate the CSR. The IdP un-maps them to verify before issuing credentials. Seems this requires mapping strategy to be coordinated, perhaps standardized? Approach B, I presume, puts control of the mapping in the hands of the IdP? I assume this mapping would need to be coordinated with any realms to which this IPA is connected by trust, regardless of whether A or B is chosen? Things to think about... > >>> Is seems that variant (B) should be really simple to code/script when >>> we have SAML/OpenID capable IdP. >> It can be done indeed. > I need to rework my RFE with diagrams to capture either A or B. Do you have a preference? Should I put both in as options? Probably both but I do not like B too. > > One comment/question: in both A and B, step 1 seems superfluous? Gssapi/saml and gssapi/openid both support initial authentication, if no cached creds exist, I think. Could step one be dropped and/or integrated into step A3 or B2? I think so. > I'm still not understanding why transferring a TGT via a browser is more difficult than linking to a file-based representation of it and ensuring there's a "helper application" ready to handle that mime type on the client. There is already a way in the browser to deliver a cert or save a file. The cert can also be sent by kerberos as was pointed out. There is no capability in browser to save TGT into ticket cache. And I am not sure it is a good idea to allow it to. I also not sure about putty/ssh client making it support either of the options would be a challenge. > (By "handle", I mean store in the local cache.) Presumably, the IdP could communicate the reply key to the client securely, but that's more or less the same as transmitting the shared secret over the network. That puts the browser TGT solution on par with "B" for me. What I am seeing is two suggestions which eliminate the need for such a transfer, whether it be trivial or impossible. It's all good. Shared key approach looks like a hack and requires new concepts and new features in the client. Approach A required PKINIT. I am not sure It also would require distributions of the "collaboration domain's CA certs". In all proposals the weakest link is the client side. If we can hide everything under GSSAPI would be best. Then we would not need the client changes to applications (only latest GSSAPI, configuration and certificates). > > Bryce > > > > > This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From quest.monger at gmail.com Thu Apr 17 18:42:11 2014 From: quest.monger at gmail.com (quest monger) Date: Thu, 17 Apr 2014 14:42:11 -0400 Subject: [Freeipa-users] setup key-based ssh using freeipa Message-ID: I have setup freeipa server, and added a centos client that my ipa users can now ssh too by using the freeipa account credentials. Now, i would like my users to be able to ssh to this centos client using keys. I read this - http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA _Guide/user-keys.html I generated the key-pair, and added the public key to user account in freeipa web console. Towards the end of that document, i found this - "After uploading the user keys, configure SSSD to use FreeIPA as one of its identity domains and set up OpenSSH to use the SSSD tooling for managing user keys." No instructions in the document on how to do this. Do i need to do anything on the centos client-side to make this work? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Thu Apr 17 20:29:32 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Thu, 17 Apr 2014 15:29:32 -0500 Subject: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing. In-Reply-To: References: <1397568653.19767.289.camel@willson.li.ssimo.org> <534F0036.6070101@redhat.com> Message-ID: I was able to take that script and with some customizing get it to work with Mavericks.... This should work, I tried to do a find and replace to make it work like the github one. On Wed, Apr 16, 2014 at 5:40 PM, Fredy Sanchez wrote: > Sure Rob, we'll put something together and send it to you for publishing. > Give us a few days. We'll also sanitize our enrollment package and share it > w/ you too. This is what we use to enroll our Macs, a one time install that > does what ipa-client-install does for Linux, including these LDAP mappings. > We love FreeIPA and will be really happy if this helps any other users with > Mac fleets. > > > On Wed, Apr 16, 2014 at 6:12 PM, Rob Crittenden wrote: > >> Fredy Sanchez wrote: >> >>> Hi Simo, >>> >>> Thanks for your reply. Good old Google pointed me to >>> https://github.com/rtrouton/rtrouton_scripts/blob/master/ >>> rtrouton_scripts/open-l >>> dap_bind_script/Mac_OpenLDAP_bind_script.sh, which gave me the idea of >>> updating the RealName mapping to displayName. This solved the problem, >>> I'll have to recreate the permissions for every share, but the user >>> names now show up, and stick. No more UIDs. >>> >> >> Great. Any chance you can write something and post a howto on our wiki? >> Or send the details to me and I'll write something up? >> >> thanks >> >> rob >> >> >>> >>> On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce >> > wrote: >>> >>> On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: >>> > Hi all, >>> > >>> > We asked this same question at discussions.apple.com >>> , but figured we'd have >>> >>> > better luck here. I apologize in advance if this is the wrong >>> forum. >>> > >>> > We are switching from Synology (DSM 5) to Mavericks server >>> (v3.1.1. running >>> > in Mavericks 10.9.2) for File Sharing. We use a FreeIPA >>> (ipa-server.x86_64 >>> > 3.0.0-37.el6) backend for SSO, and the Mac server seems >>> correctly >>> > bound to it. Unfortunately, although we can add usernames to the >>> shares for >>> > the initial config, the usernames transform to UIDs after (only >>> for SSO >>> > accounts; local accounts are not affected). That is, when we go >>> to edit the >>> > permissions for a share, all we see are UIDs. We can always >>> figure out the >>> > username from the UID, but this is an extra step we don't want to >>> have. >>> > We've tried reinstalling the Mac server app from scratch, >>> re-binding to the >>> > FreeIPA backend, changing mappings in Directory Utility (for >>> example, >>> > mapping GeneratedUID to uid, which is the username), recreating >>> the shares >>> > and permissions, etc. Here are more details about the binding: >>> > >>> > * The binding happens thru a custom package we created based >>> primarily on >>> > >>> http://linsec.ca/Using_FreeIPA_for_User_ >>> Authentication#Mac_OS_X_10.7.2F10.8 >>> > * Sys Prefs, Users & Groups, Login Options show the server bound >>> to the >>> > FreeIPA backend with the green dot >>> > * The following mappings are in place in Directory Utility, >>> Services, >>> > LDAPv3, FreeIPA backend >>> > >>> > Users: inetOrgPerson >>> > AuthenticationAuthority: uid >>> > GeneratedUID: random number in uppercase >>> > HomeDirectory: #/Users/$uid$ >>> > NFSHomeDirectory: #/Users/$uid$ >>> > OriginalHomeDirectory: #/Users/$uid$ >>> > PrimaryGroupID: gidNumber >>> > RealName: cn >>> > RecordName: uid >>> > UniqueID: uidNumber >>> > UserShell: loginShell >>> > Groups: posixgroup >>> > PrimaryGroupID: gidNumber >>> > RecordName: cn >>> > >>> > The search bases are correct >>> > >>> > * Directory Utility, Directory Editor shows the right info for >>> the users. >>> > * $ id $USERNAME shows the right information for the user >>> > >>> > FreeIPA is working beautifully for our Mac / Linux environment. >>> We provide >>> > directory services to about 300 hosts, and 200 employees using >>> it; and >>> > haven't had any problems LDAP wise until now. So we think we are >>> missing a >>> > mapping here. Any ideas? >>> >>> Fredy, >>> I quickly tried to check for some documentation on how to configure >>> this >>> stuff, but found only useless superficial guides on how to find the >>> pointy/clicky buttons to push to enable the service. >>> >>> I am not a Mac expert by a long shot so I cannot help you much here. >>> >>> Is there any guide available on how to use this service with other >>> LDAP >>> servers, like openLDAP or Active Directory ? We can probably draw >>> some >>> conclusions from there. >>> >>> Simo. >>> >>> -- >>> Simo Sorce * Red Hat, Inc * New York >>> >>> >>> >>> >>> -- >>> Cheers, >>> >>> Fredy Sanchez >>> IT Manager @ Modernizing Medicine >>> (561) 880-2998 x237 >>> fredy.sanchez at modmed.com >>> >>> *Need IT support?* Visit https://mmit.zendesk.com >>> >>> >>> * >>> >>> >>> * * >>> * >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >> > > > -- > Cheers, > > Fredy Sanchez > IT Manager @ Modernizing Medicine > (561) 880-2998 x237 > fredy.sanchez at modmed.com > > *Need IT support?* Visit https://mmit.zendesk.com > > - > > > - > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FREEIPABindScript.sh Type: application/x-sh Size: 7238 bytes Desc: not available URL: From dpal at redhat.com Thu Apr 17 21:34:28 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 17 Apr 2014 17:34:28 -0400 Subject: [Freeipa-users] PasswordAuthentication option for SSH In-Reply-To: <7d23415c-64c7-4173-99d2-b974c38fe1dd@zimbra.bytesource.net> References: <7d23415c-64c7-4173-99d2-b974c38fe1dd@zimbra.bytesource.net> Message-ID: <535048E4.50801@redhat.com> On 04/16/2014 04:28 PM, David Kreuter wrote: > On client side the valid Kerberos ticket is present. The following SSH > configuration is used on the machine where the IPA client is running: > > /etc/ssh/sshd_config > ---cut--- > PasswordAuthentication yes > KerberosAuthentication no > PubkeyAuthentication yes > UsePAM yes > GSSAPIAuthentication yes > AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys > ---cut--- > > Just checked the machine again, password authentication is used as > fallback, because the Keberos setup on this machine seems to be messed > up. I have tried to uninstall the client and reinstalled it. During > the installation I'm getting following message: > > "A RA is not configured on the server. Not requesting host certificate." > > Trying to request the certificate manually leads in: > > ipa-getcert request -d /etc/pki/nssdb -n Server-Cert -K HOST/ -N > 'CN=,O=EXAMPLE.INFO' -v > > Error org.fedorahosted.certmonger.duplicate: Certificate at same > location is already used by request with nickname "20140416200517" When you removed the client certmonger was still tracking certs from the previous install. Use cermonger to un-track old cert(s) and try to re-install again. That should solve this problem. I think is fixed in the latest version of IPA client. As for SSH I think a quick search on the net renders several guides that show how to setup OpenSSH with GSSAPI. > > So to certificate is already there. Do you have some hints? > > > ------------------------------------------------------------------------ > *From: *"Simo Sorce" > *To: *"David Kreuter" > *Cc: *freeipa-users at redhat.com > *Sent: *Wednesday, 16 April, 2014 8:50:39 PM > *Subject: *Re: [Freeipa-users] PasswordAuthentication option for SSH > > On Wed, 2014-04-16 at 20:08 +0200, David Kreuter wrote: > > Hi, > > > > > > Today I faced the issue that Kerberos authentication stopped working > > after disabling PasswordAuthentication in /etc/ssh/sshd_config on a > > FreeIPA client. The deactivation of this option was done due to > > security issues. > > > > > > Is it really necessary to have this option set to yes when using > > Keberos authentication? > > No, GSSAPI authentication does not need PasswordAuthentication, of > course it requires valid kerberos credentials on the client and a valid > keytab on the server. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Apr 17 21:45:35 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 17 Apr 2014 17:45:35 -0400 Subject: [Freeipa-users] Client Install - I'm clueless In-Reply-To: <20140417175239.GA3558@lcf004.edison.tju.edu> References: <20140417175239.GA3558@lcf004.edison.tju.edu> Message-ID: <53504B7F.1020807@redhat.com> On 04/17/2014 01:52 PM, Lincoln Fessenden wrote: > Hi folks! > First time I played with this was yesterday so forgive me if I am way behind the median user here. > I installed the server twice, both times on RHEL 6.5. Seems to work just fine and the install goes smooth. First install of the client was on a RHEL 7 beta machine, which worked but I could not get server exclusion rules working (all or nothing), hence the server reinstall. Next I tried ipa-client on a brand new RHEL 6.5 box. This will NOT complete installation and the same is true for 5.10. Different errors though. 6.5 errors out after sending xml to the ipa-server and 5.10 right after I provide the domain name. Since both of these machines are new installs and current for the release, I have got to believe I am missing something somewhere - some missing software dependency? I almost never have seen software in the enterprise repository that is just broken... Help? > Most likely there some DNS issues. Please check your DNS, /etc/hosts, etc. Can you provide any client install logs? That would really help. Also http://www.freeipa.org/page/Troubleshooting might be helpful. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Apr 17 21:48:35 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 17 Apr 2014 17:48:35 -0400 Subject: [Freeipa-users] setup key-based ssh using freeipa In-Reply-To: References: Message-ID: <53504C33.3070701@redhat.com> On 04/17/2014 02:42 PM, quest monger wrote: > I have setup freeipa server, and added a centos client that my ipa > users can now ssh too by using the freeipa account credentials. > Now, i would like my users to be able to ssh to this centos client > using keys. > I read this - > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/user-keys.html > I generated the key-pair, and added the public key to user account in > freeipa web console. > > Towards the end of that document, i found this - > "After uploading the user keys, configure SSSD to use FreeIPA as one > of its identity domains and set up OpenSSH to use the SSSD tooling for > managing user keys." > No instructions in the document on how to do this. > > Do i need to do anything on the centos client-side to make this work? > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users yum install ipa-client then run ipa-client-install with arguments you need (see man pages or manual) which will configure your client. Depending on the version it will also be able to configure SSH integration. See man on ipa-client-install -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Apr 17 22:27:37 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Apr 2014 18:27:37 -0400 Subject: [Freeipa-users] Client Install - I'm clueless In-Reply-To: <53504B7F.1020807@redhat.com> References: <20140417175239.GA3558@lcf004.edison.tju.edu> <53504B7F.1020807@redhat.com> Message-ID: <53505559.5080603@redhat.com> Dmitri Pal wrote: > On 04/17/2014 01:52 PM, Lincoln Fessenden wrote: >> Hi folks! >> First time I played with this was yesterday so forgive me if I am way >> behind the median user here. >> I installed the server twice, both times on RHEL 6.5. Seems to work >> just fine and the install goes smooth. First install of the client >> was on a RHEL 7 beta machine, which worked but I could not get server >> exclusion rules working (all or nothing), hence the server reinstall. >> Next I tried ipa-client on a brand new RHEL 6.5 box. This will NOT >> complete installation and the same is true for 5.10. Different errors >> though. 6.5 errors out after sending xml to the ipa-server and 5.10 >> right after I provide the domain name. Since both of these machines >> are new installs and current for the release, I have got to believe I >> am missing something somewhere - some missing software dependency? I >> almost never have seen software in the enterprise repository that is >> just broken... Help? >> > Most likely there some DNS issues. Please check your DNS, /etc/hosts, etc. > > Can you provide any client install logs? > That would really help. > > Also http://www.freeipa.org/page/Troubleshooting might be helpful. > Yes, seeing the errors would be quite helpful too, the more context the better (/var/log/ipaclient-install.log). rob From david.kreuter at bytesource.net Fri Apr 18 08:14:43 2014 From: david.kreuter at bytesource.net (David Kreuter) Date: Fri, 18 Apr 2014 10:14:43 +0200 (CEST) Subject: [Freeipa-users] Keberos authentication - Unspecified GSS failure In-Reply-To: <534F009C.1090806@redhat.com> Message-ID: <5f6aceff-47e8-4676-badf-1d46058a24d8@zimbra.bytesource.net> klist -kt /etc/krb5.keytab showing me the right principals: KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 1 04/16/14 23:12:58 host/@ 1 04/16/14 23:12:58 host/@ 1 04/16/14 23:12:58 host/@ 1 04/16/14 23:12:58 host/@ The principal for the machine are displayed with the right FQDN. Also the machine has the right hostname containing the right domain and the machine can be resolved correctly via DNS. I have added the mentioned option to kerberos configuration and the login with Kerberos authentication is working now: [libdefaults] ignore_acceptor_hostname = true I'm still wondering what is wrong with the machine's configuration. ----- Original Message ----- From: "Rob Crittenden" To: "David Kreuter" , freeipa-users at redhat.com Sent: Thursday, 17 April, 2014 12:13:48 AM Subject: Re: [Freeipa-users] Keberos authentication - Unspecified GSS failure David Kreuter wrote: > Yesterday I installed the FreeIPA client on machine and after the > installation the login with password worked fine. After that I tried to > login with a valid Kerberos ticket and it failed. First i traced the ssh > login: > > ssh -vvv david at test.example.com > ---cut--- > debug2: key: /home/david/.ssh/id_rsa (0x7f2ad3112d80), > debug2: key: /home/david/.ssh/id_dsa ((nil)), > debug2: key: /home/david/.ssh/id_ecdsa ((nil)), > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic > debug3: start over, passed a different list > publickey,gssapi-keyex,gssapi-with-mic > debug3: preferred > gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password > debug3: authmethod_lookup gssapi-keyex > debug3: remaining preferred: > gssapi-with-mic,publickey,keyboard-interactive,password > debug3: authmethod_is_enabled gssapi-keyex > debug1: Next authentication method: gssapi-keyex > debug1: No valid Key exchange context > debug2: we did not send a packet, disable method > debug3: authmethod_lookup gssapi-with-mic > debug3: remaining preferred: publickey,keyboard-interactive,password > debug3: authmethod_is_enabled gssapi-with-mic > debug1: Next authentication method: gssapi-with-mic > debug2: we sent a gssapi-with-mic packet, wait for reply > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic > debug2: we sent a gssapi-with-mic packet, wait for reply > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic > debug2: we sent a gssapi-with-mic packet, wait for reply > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic > debug2: we sent a gssapi-with-mic packet, wait for reply > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic > debug2: we did not send a packet, disable method > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Offering RSA public key: /home/david/.ssh/id_rsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic > debug1: Trying private key: /home/david/.ssh/id_dsa > debug3: no such identity: /home/david/.ssh/id_dsa: No such file or directory > debug1: Trying private key: /home/david/.ssh/id_ecdsa > debug3: no such identity: /home/david/.ssh/id_ecdsa: No such file or > directory > debug2: we did not send a packet, disable method > debug1: No more authentication methods to try. > Permission denied (publickey,gssapi-keyex,gssapi-with-mic). > ---cut--- > > Then I enabled the log for SSH on the IPA client machine and faced > following error: > > ---cut--- > Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 0 failures 0 > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: initializing for "david" > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_RHOST to > "10.100.3.2" > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_TTY to "ssh" > Apr 16 23:43:18 infra01 sshd[9941]: debug1: userauth-request for user > david service ssh-connection method gssapi-with-mic > Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 1 failures 0 > Apr 16 23:43:18 infra01 sshd[9940]: debug1: Unspecified GSS failure. > Minor code may provide more information\nNo key table entry found > matching host/infra01@\n > ---cut--- > > Unspecified GSS failure. Minor code may provide more information.No key > table entry found matching host/infra01@\n. > > After that I tried to receive a ticket on the IPA client machine and > everything worked fine: > > kinit > klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: david@.INFO > > Valid starting Expires Service principal > 04/16/14 23:24:51 04/17/14 23:24:47 krbtgt/... > 04/16/14 23:25:51 04/17/14 23:24:47 host/... > > kvno -k /etc/krb5.keytab host/... > host/...: kvno = 1, keytab entry valid > > So the Kerberos setup on the machine seems to be fine, but still the > login SSH using Keberos is not working. GSSAPI is correctly enabled in > the sshd configuration file. Any hint is highly appreciated. Thanks. > Seems like sshd looked for the wrong key. Run klist -kt /etc/krb5.keytab and see what principal is there. sshd didn't look for a FQDN according to your log. rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Fri Apr 18 13:38:37 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Fri, 18 Apr 2014 08:38:37 -0500 Subject: [Freeipa-users] Questions about Logs Message-ID: One of the big rocks I am trying to accomplish is the ability to audit access information and password resets. I know the audit capabilities is on the road map for the future so I'm trying to make due with what I have. 1) is all the above information in the access log? 2) do you know of any 3rd party online tools to view those logs in a more readable format then the /var/log/dirsrv/slapd- access file? 3) Any idea on rough time period for the full audit capabilities? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Apr 18 13:49:50 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 18 Apr 2014 09:49:50 -0400 Subject: [Freeipa-users] Keberos authentication - Unspecified GSS failure In-Reply-To: <5f6aceff-47e8-4676-badf-1d46058a24d8@zimbra.bytesource.net> References: <5f6aceff-47e8-4676-badf-1d46058a24d8@zimbra.bytesource.net> Message-ID: <1397828990.2628.154.camel@willson.li.ssimo.org> On Fri, 2014-04-18 at 10:14 +0200, David Kreuter wrote: > klist -kt /etc/krb5.keytab showing me the right principals: > > > > KVNO Timestamp Principal > ---- ----------------- -------------------------------------------------------- > 1 04/16/14 23:12:58 host/@ > 1 04/16/14 23:12:58 host/@ 1 04/16/14 23:12:58 host/@ 1 04/16/14 23:12:58 host/@ > > > The principal for the machine are displayed with the right FQDN. Also the machine has the right hostname containing the right domain and the machine can be resolved correctly via DNS. > > > I have added the mentioned option to kerberos configuration and the login with Kerberos authentication is working now: > > > > [libdefaults] > ignore_acceptor_hostname = true > > > I'm still wondering what is wrong with the machine's configuration. Do you have the shortname as first entry in /etc/hosts ? If so put it second or remove it. Simo. > ----- Original Message ----- > > From: "Rob Crittenden" > To: "David Kreuter" , freeipa-users at redhat.com > Sent: Thursday, 17 April, 2014 12:13:48 AM > Subject: Re: [Freeipa-users] Keberos authentication - Unspecified GSS failure > > David Kreuter wrote: > > Yesterday I installed the FreeIPA client on machine and after the > > installation the login with password worked fine. After that I tried to > > login with a valid Kerberos ticket and it failed. First i traced the ssh > > login: > > > > ssh -vvv david at test.example.com > > ---cut--- > > debug2: key: /home/david/.ssh/id_rsa (0x7f2ad3112d80), > > debug2: key: /home/david/.ssh/id_dsa ((nil)), > > debug2: key: /home/david/.ssh/id_ecdsa ((nil)), > > debug1: Authentications that can continue: > > publickey,gssapi-keyex,gssapi-with-mic > > debug3: start over, passed a different list > > publickey,gssapi-keyex,gssapi-with-mic > > debug3: preferred > > gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password > > debug3: authmethod_lookup gssapi-keyex > > debug3: remaining preferred: > > gssapi-with-mic,publickey,keyboard-interactive,password > > debug3: authmethod_is_enabled gssapi-keyex > > debug1: Next authentication method: gssapi-keyex > > debug1: No valid Key exchange context > > debug2: we did not send a packet, disable method > > debug3: authmethod_lookup gssapi-with-mic > > debug3: remaining preferred: publickey,keyboard-interactive,password > > debug3: authmethod_is_enabled gssapi-with-mic > > debug1: Next authentication method: gssapi-with-mic > > debug2: we sent a gssapi-with-mic packet, wait for reply > > debug1: Authentications that can continue: > > publickey,gssapi-keyex,gssapi-with-mic > > debug2: we sent a gssapi-with-mic packet, wait for reply > > debug1: Authentications that can continue: > > publickey,gssapi-keyex,gssapi-with-mic > > debug2: we sent a gssapi-with-mic packet, wait for reply > > debug1: Authentications that can continue: > > publickey,gssapi-keyex,gssapi-with-mic > > debug2: we sent a gssapi-with-mic packet, wait for reply > > debug1: Authentications that can continue: > > publickey,gssapi-keyex,gssapi-with-mic > > debug2: we did not send a packet, disable method > > debug3: authmethod_lookup publickey > > debug3: remaining preferred: keyboard-interactive,password > > debug3: authmethod_is_enabled publickey > > debug1: Next authentication method: publickey > > debug1: Offering RSA public key: /home/david/.ssh/id_rsa > > debug3: send_pubkey_test > > debug2: we sent a publickey packet, wait for reply > > debug1: Authentications that can continue: > > publickey,gssapi-keyex,gssapi-with-mic > > debug1: Trying private key: /home/david/.ssh/id_dsa > > debug3: no such identity: /home/david/.ssh/id_dsa: No such file or directory > > debug1: Trying private key: /home/david/.ssh/id_ecdsa > > debug3: no such identity: /home/david/.ssh/id_ecdsa: No such file or > > directory > > debug2: we did not send a packet, disable method > > debug1: No more authentication methods to try. > > Permission denied (publickey,gssapi-keyex,gssapi-with-mic). > > ---cut--- > > > > Then I enabled the log for SSH on the IPA client machine and faced > > following error: > > > > ---cut--- > > Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 0 failures 0 > > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: initializing for "david" > > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_RHOST to > > "10.100.3.2" > > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_TTY to "ssh" > > Apr 16 23:43:18 infra01 sshd[9941]: debug1: userauth-request for user > > david service ssh-connection method gssapi-with-mic > > Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 1 failures 0 > > Apr 16 23:43:18 infra01 sshd[9940]: debug1: Unspecified GSS failure. > > Minor code may provide more information\nNo key table entry found > > matching host/infra01@\n > > ---cut--- > > > > Unspecified GSS failure. Minor code may provide more information.No key > > table entry found matching host/infra01@\n. > > > > After that I tried to receive a ticket on the IPA client machine and > > everything worked fine: > > > > kinit > > klist > > Ticket cache: FILE:/tmp/krb5cc_0 > > Default principal: david@.INFO > > > > Valid starting Expires Service principal > > 04/16/14 23:24:51 04/17/14 23:24:47 krbtgt/... > > 04/16/14 23:25:51 04/17/14 23:24:47 host/... > > > > kvno -k /etc/krb5.keytab host/... > > host/...: kvno = 1, keytab entry valid > > > > So the Kerberos setup on the machine seems to be fine, but still the > > login SSH using Keberos is not working. GSSAPI is correctly enabled in > > the sshd configuration file. Any hint is highly appreciated. Thanks. > > > > Seems like sshd looked for the wrong key. Run klist -kt /etc/krb5.keytab > and see what principal is there. sshd didn't look for a FQDN according > to your log. > > rob > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York From david at bytesource.net Fri Apr 18 14:03:56 2014 From: david at bytesource.net (David Kreuter) Date: Fri, 18 Apr 2014 16:03:56 +0200 Subject: [Freeipa-users] Keberos authentication - Unspecified GSS failure In-Reply-To: <1397828990.2628.154.camel@willson.li.ssimo.org> References: <5f6aceff-47e8-4676-badf-1d46058a24d8@zimbra.bytesource.net> <1397828990.2628.154.camel@willson.li.ssimo.org> Message-ID: <5b4d7911-7c87-45a6-ab96-e8c54e301e0c@email.android.com> Exactly, this was the issue. After fixing the etc hosts configuration kerberos authentication works fine for this machine without having this special krb option set. Thanks! On 18 April 2014 15:49:50 CEST, Simo Sorce wrote: >On Fri, 2014-04-18 at 10:14 +0200, David Kreuter wrote: >> klist -kt /etc/krb5.keytab showing me the right principals: >> >> >> >> KVNO Timestamp Principal >> ---- ----------------- >-------------------------------------------------------- >> 1 04/16/14 23:12:58 host/@ >> 1 04/16/14 23:12:58 host/@ 1 04/16/14 23:12:58 >host/@ 1 04/16/14 23:12:58 host/@realm> >> >> >> The principal for the machine are displayed with the right FQDN. Also >the machine has the right hostname containing the right domain and the >machine can be resolved correctly via DNS. >> >> >> I have added the mentioned option to kerberos configuration and the >login with Kerberos authentication is working now: >> >> >> >> [libdefaults] >> ignore_acceptor_hostname = true >> >> >> I'm still wondering what is wrong with the machine's configuration. > >Do you have the shortname as first entry in /etc/hosts ? >If so put it second or remove it. > >Simo. > > >> ----- Original Message ----- >> >> From: "Rob Crittenden" >> To: "David Kreuter" , >freeipa-users at redhat.com >> Sent: Thursday, 17 April, 2014 12:13:48 AM >> Subject: Re: [Freeipa-users] Keberos authentication - Unspecified GSS >failure >> >> David Kreuter wrote: >> > Yesterday I installed the FreeIPA client on machine and after the >> > installation the login with password worked fine. After that I >tried to >> > login with a valid Kerberos ticket and it failed. First i traced >the ssh >> > login: >> > >> > ssh -vvv david at test.example.com >> > ---cut--- >> > debug2: key: /home/david/.ssh/id_rsa (0x7f2ad3112d80), >> > debug2: key: /home/david/.ssh/id_dsa ((nil)), >> > debug2: key: /home/david/.ssh/id_ecdsa ((nil)), >> > debug1: Authentications that can continue: >> > publickey,gssapi-keyex,gssapi-with-mic >> > debug3: start over, passed a different list >> > publickey,gssapi-keyex,gssapi-with-mic >> > debug3: preferred >> > >gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password >> > debug3: authmethod_lookup gssapi-keyex >> > debug3: remaining preferred: >> > gssapi-with-mic,publickey,keyboard-interactive,password >> > debug3: authmethod_is_enabled gssapi-keyex >> > debug1: Next authentication method: gssapi-keyex >> > debug1: No valid Key exchange context >> > debug2: we did not send a packet, disable method >> > debug3: authmethod_lookup gssapi-with-mic >> > debug3: remaining preferred: >publickey,keyboard-interactive,password >> > debug3: authmethod_is_enabled gssapi-with-mic >> > debug1: Next authentication method: gssapi-with-mic >> > debug2: we sent a gssapi-with-mic packet, wait for reply >> > debug1: Authentications that can continue: >> > publickey,gssapi-keyex,gssapi-with-mic >> > debug2: we sent a gssapi-with-mic packet, wait for reply >> > debug1: Authentications that can continue: >> > publickey,gssapi-keyex,gssapi-with-mic >> > debug2: we sent a gssapi-with-mic packet, wait for reply >> > debug1: Authentications that can continue: >> > publickey,gssapi-keyex,gssapi-with-mic >> > debug2: we sent a gssapi-with-mic packet, wait for reply >> > debug1: Authentications that can continue: >> > publickey,gssapi-keyex,gssapi-with-mic >> > debug2: we did not send a packet, disable method >> > debug3: authmethod_lookup publickey >> > debug3: remaining preferred: keyboard-interactive,password >> > debug3: authmethod_is_enabled publickey >> > debug1: Next authentication method: publickey >> > debug1: Offering RSA public key: /home/david/.ssh/id_rsa >> > debug3: send_pubkey_test >> > debug2: we sent a publickey packet, wait for reply >> > debug1: Authentications that can continue: >> > publickey,gssapi-keyex,gssapi-with-mic >> > debug1: Trying private key: /home/david/.ssh/id_dsa >> > debug3: no such identity: /home/david/.ssh/id_dsa: No such file or >directory >> > debug1: Trying private key: /home/david/.ssh/id_ecdsa >> > debug3: no such identity: /home/david/.ssh/id_ecdsa: No such file >or >> > directory >> > debug2: we did not send a packet, disable method >> > debug1: No more authentication methods to try. >> > Permission denied (publickey,gssapi-keyex,gssapi-with-mic). >> > ---cut--- >> > >> > Then I enabled the log for SSH on the IPA client machine and faced >> > following error: >> > >> > ---cut--- >> > Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 0 failures 0 >> > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: initializing for >"david" >> > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_RHOST >to >> > "10.100.3.2" >> > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_TTY to >"ssh" >> > Apr 16 23:43:18 infra01 sshd[9941]: debug1: userauth-request for >user >> > david service ssh-connection method gssapi-with-mic >> > Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 1 failures 0 >> > Apr 16 23:43:18 infra01 sshd[9940]: debug1: Unspecified GSS >failure. >> > Minor code may provide more information\nNo key table entry found >> > matching host/infra01@\n >> > ---cut--- >> > >> > Unspecified GSS failure. Minor code may provide more information.No >key >> > table entry found matching host/infra01@\n. >> > >> > After that I tried to receive a ticket on the IPA client machine >and >> > everything worked fine: >> > >> > kinit >> > klist >> > Ticket cache: FILE:/tmp/krb5cc_0 >> > Default principal: david@.INFO >> > >> > Valid starting Expires Service principal >> > 04/16/14 23:24:51 04/17/14 23:24:47 krbtgt/... >> > 04/16/14 23:25:51 04/17/14 23:24:47 host/... >> > >> > kvno -k /etc/krb5.keytab host/... >> > host/...: kvno = 1, keytab entry valid >> > >> > So the Kerberos setup on the machine seems to be fine, but still >the >> > login SSH using Keberos is not working. GSSAPI is correctly enabled >in >> > the sshd configuration file. Any hint is highly appreciated. >Thanks. >> > >> >> Seems like sshd looked for the wrong key. Run klist -kt >/etc/krb5.keytab >> and see what principal is there. sshd didn't look for a FQDN >according >> to your log. >> >> rob >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > >-- >Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- An HTML attachment was scrubbed... URL: From wxu.hccl at gmail.com Fri Apr 18 00:38:08 2014 From: wxu.hccl at gmail.com (Will Last) Date: Fri, 18 Apr 2014 08:38:08 +0800 Subject: [Freeipa-users] nothing sync'ed to AD In-Reply-To: <534FE241.7070602@redhat.com> References: <534FE241.7070602@redhat.com> Message-ID: Many thanks, Bob, for letting me know that I missed the important point as designed, and for giving me the confidence that my setup is correct after scratching my head for two weeks:-D. So, is there any solution for my case, i.e., *using an already setup freeipa as the primary service, and AD as the secondary (only for those dependent on AD)*, in addition to Petr's suggestion to setup freeipa-AD trust? I prefer to maintain user info in freeipa and let AD sync from freeipa. But unfortunately, this is not designed to be so. Did anyone try the idea of export users from freeipa and then import into AD, since they both use LDAP? At least for the initial pseudo/manual sync. It would be great to share your experience with us. Thanks! On Thu, Apr 17, 2014 at 10:16 PM, Rob Crittenden wrote: > Will Last wrote: > >> Hi, >> >> I have got a freeipa server (pa-server-3.0.0-37) running on centos 6.5 >> and am trying to set up sync with/to AD on win 2008/R2, basically >> following >> https://access.redhat.com/site/documentation/en-US/Red_ >> Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ >> active-directory.html. >> The sync agreement is bi-directional by default. But only AD users are >> sync'ed to freeipa and none of the users on freeipa is sync'ed to ad, >> which is what I really cared for. Even a re-initialization from AD won't >> help (ipa-replica-manage re-initialize --from ad.example.com >> ). I have turned debugging on >> >> (nsslapd-errorlog-level to 8192), but did not see any obvious clue. >> >> Thanks in advance for any help! >> > > This is working as designed. IPA-only users are not synced to AD. The > bidirectional part is that changes to an AD user synced to IPA on the IPA > side will be synced back to AD. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cto at sshchicago.org Sat Apr 19 01:15:37 2014 From: cto at sshchicago.org (Christopher Swingler) Date: Fri, 18 Apr 2014 20:15:37 -0500 Subject: [Freeipa-users] Adding custom attributes in User Settings screen in FreeIPA UI Message-ID: <6BAEAC4C-F7AF-4B09-BF86-2C2893632237@sshchicago.org> If I've extended the LDAP schema to add in some custom attributes, is it possible to have those show up under Identity > Users > [username] > Settings, perhaps under "MISC. INFORMATION"? I've already added the custom class under IPA Server > Configuration > Default user objectclasses, but it would be great if I can edit this information within the FreeIPA UI without having to write something up elsewhere. If this is possible, my google-fu isn't really getting me anywhere. :-) Have a great weekend, all! Christopher Swingler CTO South Side Hackerspace Chicago 2233 South Throop St | Unit 214 | Chicago, IL 60608 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.holway at gmail.com Sat Apr 19 13:12:34 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Sat, 19 Apr 2014 14:12:34 +0100 Subject: [Freeipa-users] Root certificates Message-ID: Hello, I would like to install the root certificate from my freeipa installation into some browsers and other clients. If this statement makes sense; does anyone have a guide for this? Thanks, Andrew From tompos at martos.bme.hu Sat Apr 19 13:25:42 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Sat, 19 Apr 2014 15:25:42 +0200 Subject: [Freeipa-users] Root certificates In-Reply-To: References: Message-ID: <53527956.1040609@martos.bme.hu> On 04/19/2014 03:12 PM, Andrew Holway wrote: > Hello, > > I would like to install the root certificate from my freeipa > installation into some browsers and other clients. > > If this statement makes sense; does anyone have a guide for this? > All you need to do is installing http://ipaserver/ipa/config/ca.crt . tamas From tompos at martos.bme.hu Sat Apr 19 13:25:42 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Sat, 19 Apr 2014 15:25:42 +0200 Subject: [Freeipa-users] Root certificates In-Reply-To: References: Message-ID: <53527956.1040609@martos.bme.hu> On 04/19/2014 03:12 PM, Andrew Holway wrote: > Hello, > > I would like to install the root certificate from my freeipa > installation into some browsers and other clients. > > If this statement makes sense; does anyone have a guide for this? > All you need to do is installing http://ipaserver/ipa/config/ca.crt . tamas From dpal at redhat.com Sat Apr 19 16:29:51 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 19 Apr 2014 12:29:51 -0400 Subject: [Freeipa-users] nothing sync'ed to AD In-Reply-To: References: <534FE241.7070602@redhat.com> Message-ID: <5352A47F.10102@redhat.com> On 04/17/2014 08:38 PM, Will Last wrote: > Many thanks, Bob, for letting me know that I missed the important > point as designed, and for giving me the confidence that my setup is > correct after scratching my head for two weeks:-D. > > So, is there any solution for my case, i.e., *using an already setup > freeipa as the primary service, and AD as the secondary (only for > those dependent on AD)*, in addition to Petr's suggestion to setup > freeipa-AD trust? I prefer to maintain user info in freeipa and let AD > sync from freeipa. But unfortunately, this is not designed to be so. > Did anyone try the idea of export users from freeipa and then import > into AD, since they both use LDAP? At least for the initial > pseudo/manual sync. It would be great to share your experience with us. > We are aware of this use case. It is still quite a rare one so we have not addressed it as there are more pressing configurations that are more common. Generally our recommendation in this case will be to rely on the 2-way trusts but it is not implemented yet. The export import part will work except passwords. Password hashes are different in AD than in IPA (and standard Kerberos/LDAP) so you can sync users but not passwords. The best option is for you to explore the 389 DS sync setup and try to apply it to IPA. But there will be dragons and it might require some development to make plugins work in the right way. IPA has a plugin to the base DS plugin so it might require some adjustment if you want to make two way sync work. Here is the starting point. http://port389.org/wiki/Howto:WindowsSync Thanks Dmitri > Thanks! > > > On Thu, Apr 17, 2014 at 10:16 PM, Rob Crittenden > wrote: > > Will Last wrote: > > Hi, > > I have got a freeipa server (pa-server-3.0.0-37) running on > centos 6.5 > and am trying to set up sync with/to AD on win 2008/R2, basically > following > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory.html. > The sync agreement is bi-directional by default. But only AD > users are > sync'ed to freeipa and none of the users on freeipa is sync'ed > to ad, > which is what I really cared for. Even a re-initialization > from AD won't > help (ipa-replica-manage re-initialize --from ad.example.com > > ). I have turned debugging on > > (nsslapd-errorlog-level to 8192), but did not see any obvious > clue. > > Thanks in advance for any help! > > > This is working as designed. IPA-only users are not synced to AD. > The bidirectional part is that changes to an AD user synced to IPA > on the IPA side will be synced back to AD. > > rob > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sat Apr 19 16:33:53 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 19 Apr 2014 12:33:53 -0400 Subject: [Freeipa-users] Questions about Logs In-Reply-To: References: Message-ID: <5352A571.7030905@redhat.com> On 04/18/2014 09:38 AM, Chris Whittle wrote: > One of the big rocks I am trying to accomplish is the ability to audit > access information and password resets. I know the audit > capabilities is on the road map for the future so I'm trying to make > due with what I have. > > 1) is all the above information in the access log? > 2) do you know of any 3rd party online tools to view those logs in a > more readable format then the /var/log/dirsrv/slapd- access file? > 3) Any idea on rough time period for the full audit capabilities? Our plan is to start sending log into journald nd then use its capabilities to centralize the logs. You then would be able to point traditional log processing tools like Logstash, Splunk, Zabbix etc. to it. Ticket is https://fedorahosted.org/freeipa/ticket/4296 It is currently pointing 4.2 which means that the earliest we will start looking into it in about 9-12 months. Thanks Dmitri > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sat Apr 19 16:36:28 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 19 Apr 2014 12:36:28 -0400 Subject: [Freeipa-users] Adding custom attributes in User Settings screen in FreeIPA UI In-Reply-To: <6BAEAC4C-F7AF-4B09-BF86-2C2893632237@sshchicago.org> References: <6BAEAC4C-F7AF-4B09-BF86-2C2893632237@sshchicago.org> Message-ID: <5352A60C.7020306@redhat.com> On 04/18/2014 09:15 PM, Christopher Swingler wrote: > If I've extended the LDAP schema to add in some custom attributes, is > it possible to have those show up under Identity > Users > [username] > > Settings, perhaps under "MISC. INFORMATION"? > > I've already added the custom class under IPA Server > Configuration > > Default user objectclasses, but it would be great if I can edit this > information within the FreeIPA UI without having to write something up > elsewhere. > > If this is possible, my google-fu isn't really getting me anywhere. :-) It looks like you are looking for this: http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf > > Have a great weekend, all! > > Christopher Swingler > /CTO/ > South Side Hackerspace Chicago > 2233 South Throop St | Unit 214 | Chicago, IL 60608 > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Sat Apr 19 18:01:41 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Sat, 19 Apr 2014 18:01:41 +0000 Subject: [Freeipa-users] External domain use case wiki page Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E6B004C@001FSN2MPN1-044.001f.mgd2.msft.net> http://www.freeipa.org/page/External_Collaboration_Domains This is mostly Dimitri's text, but I did butcher it some. Also has a figure. Will update the external users RFE next. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Sat Apr 19 23:46:12 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Sat, 19 Apr 2014 23:46:12 +0000 Subject: [Freeipa-users] External collaboration edits Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E6B00D0@001FSN2MPN1-044.001f.mgd2.msft.net> I've run out of time for today, but the external collaboration pages are slowly evolving. http://www.freeipa.org/page/External_Users_in_IPA Dimitri observed that my RFE page was too long. I observe it also has too much stuff unrelated to the actual meat of the RFE. So I factored out most of the Kerberos stuff into a different page. I also tried to focus the RFE to just creating entries in LDAP for external users so they can: a] participate in POSIX groups; and b] have locally-defined POSIX attributes. http://www.freeipa.org/page/Collaboration_with_Kerberos This is where all the Kerberos stuff went. I also added in "Option A" from Petr's email. Option B will come along later, when I pick this up again. Mechanism three has more to do with Ipsilon than IPA, and basic functions required of the Ipsilon gateway server are articulated there (regardless of the particular authentication method.) Send comments to the list. I really appreciate Option A! Send more stuff I didn't think of. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhu_junca at yahoo.ca Sun Apr 20 03:29:09 2014 From: zhu_junca at yahoo.ca (Carl E. Ma) Date: Sat, 19 Apr 2014 23:29:09 -0400 Subject: [Freeipa-users] experience using IPA in a mixed environment In-Reply-To: <534299F6.8090200@redhat.com> References: <1396715090.39565.YahooMailNeo@web140903.mail.bf1.yahoo.com> <534299F6.8090200@redhat.com> Message-ID: <53533F05.90908@yahoo.ca> Hi Rob/all, The original freeipa-client 2.1.4 on ubuntu 12.04 doesn't have "ipa-client-automount" command. I manually configured the autofs as following: ===*/etc/autofs_ldap_autofs*=== root at ecs-94a55510:/etc# more autofs_ldap_auth.conf ===end of autofs_ldap_autofs=== ===*/etc/default/autof**s*=== MASTER_MAP_NAME="automountmapname=auto.master,cn=default,cn=automount,dc=ecs,dc=ads,dc=xxx,dc=com" LOGGING="debug" MAP_OBJECT_CLASS="automountMap" ENTRY_OBJECT_CLASS="automount" MAP_ATTRIBUTE="automountMapName" ENTRY_ATTRIBUTE="automountKey" VALUE_ATTRIBUTE="automountInformation" LDAP_URI="ldap://ecs-1a5d4287.ecs.ads.xxx.com" SEARCH_BASE="cn=default,cn=automount,dc=ecs,dc=ads,dc=xxx,dc=com" ===end of /etc/default/autofs=== ===*/etc/nsswitch.conf*=== passwd: compat sss group: compat sss shadow: compat hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis sss sudoers: files ldap automount: files ldap ===end of /etc/nsswitch.conf=== ===*/etc/default/nfs-common*=== NEED_STATD= STATDOPTS= NEED_IDMAP=yes NEED_GSSD=yes ===end of nfs-common=== ===here is*/etc/auto.master*=== #cat "+auto.master" >> /etc/auto.master ===end of auto.master=== On IPA server, I add the NFS service for that client as: # ipa service-add nfs/ecs-94a55510.ecs.ads.xxx.com But none ldap automount maps are shown in "automount -m" output. From below syslog error messages, client server can't directly connect to IPA(ldap server) for auto.master map. *===* root at ecs-94a55510:/etc# automount -m find_server: trying server uri ldap://ecs-1a5d4287.ecs.ads.xxx.com init_ldap_connection: lookup(ldap): TLS required but START_TLS failed: Connect error lookup(ldap): couldn't connect to server ldap://ecs-1a5d4287.ecs.ads.xxx.com do_reconnect: lookup(ldap): failed to find available server autofs dump map information =========================== global options: none configured no master map entries found In /var/log/syslog, here are the errors: Apr 19 23:09:40 ecs-94a55510 automount[17476]: parse_init: parse(sun): init gathered global options: (null) Apr 19 23:09:40 ecs-94a55510 automount[17476]: lookup_nss_read_master: reading master ldap auto.master Apr 19 23:09:40 ecs-94a55510 automount[17476]: parse_init: parse(sun): init gathered global options: (null) Apr 19 23:09:40 ecs-94a55510 automount[17476]: lookup(file): failed to read included master map auto.master *===* The same ubuntu 12.04 host, sudo also can't retrieve sudoers information from IPA server using ldap(sudo on ubuntu 12.04 doesn't support sssd), I double the problem is with ldap client function on this host. If I missed anything obvious, please let me know. thanks, carl On 14-04-07 08:28 AM, Rob Crittenden wrote: > Carl E. Ma wrote: >> Hi, >> >> My environment has Redhat5, 6, Centos 6.x and Ubuntu 12.04. Following >> Redhat identity management manual, I am able to configure user >> authentication, kerberos NFS, SSSD and autofs on most of my systems. >> >> The only trouble is integrating ubuntu 12.04 with autofs. >> >> 1. automount in /etc/nsswitch.conf doesn't recognize sss as the name >> service, you need to put ldap instead. >> 2. automount on ubuntu 12.04 doesn't recognize the auto.master map >> from IPA server. >> >> On our IPA server: >> ipaserver# ipa automountlocation-tofiles default >> /etc/auto.master: >> /- /etc/auto.direct >> /home /etc/auto.home >> --------------------------- >> /etc/auto.direct: >> --------------------------- >> /etc/auto.home: >> * -fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192 >> nfs:/opt/shares/home/& >> >> >>> From ubuntu 12.04 IPA client: >> #automount -f -d <=shows it can't find the auto.master map, in >> /etc/default/autofs, I tried both ways to specify the auto.master map. >> == >> #cat /etc/default/autofs | grep MASTER >> #MASTER_MAP_NAME="automountmapname=auto.master,cn=default,cn=automount,dc=x,dc=x,dc=x,dc=com" >> >> MASTER_MAP_NAME="auto.master" >> == >> >>> From the error messages, it seems automount on ubuntu doesn't lookup >>> LDAP for auto.master information. >> >> Apr 4 17:25:26 ecs-94a55510 automount[1032]: lookup(file): file map >> /etc/automountmapname=auto.master,cn=default,cn=automount,dc=x,dc=x,dc=x,dc=com >> missing or not readable >> >> Although I am using pam to automount user home directory, i am >> curious whether anyone else experienced the same problem, or maybe I >> missed something. > > Can you provide more information on how you configured automount (e.g. > can we see the config files)? Did you use the ipa-client-automount > command or configure things by hand? > > rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.holway at gmail.com Sun Apr 20 06:29:03 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Sun, 20 Apr 2014 07:29:03 +0100 Subject: [Freeipa-users] Root certificates In-Reply-To: <53527956.1040609@martos.bme.hu> References: <53527956.1040609@martos.bme.hu> Message-ID: >> I would like to install the root certificate from my freeipa >> installation into some browsers and other clients. >> >> If this statement makes sense; does anyone have a guide for this? >> > > All you need to do is installing http://ipaserver/ipa/config/ca.crt . Brilliant! Thanks. From quest.monger at gmail.com Sun Apr 20 08:17:34 2014 From: quest.monger at gmail.com (quest monger) Date: Sun, 20 Apr 2014 04:17:34 -0400 Subject: [Freeipa-users] setup key-based ssh using freeipa In-Reply-To: <53504C33.3070701@redhat.com> References: <53504C33.3070701@redhat.com> Message-ID: I already ran that command to configure centos host as client. I used 'ipa-client-install --mkhomedir --no-ntp'. Now my IPA users are able to SSH to that box, using passwords set in IPA. Next I would like them to SSH using keys. When I looked through the document for more info, I found this line - 'After uploading the user keys, configure SSSD to use FreeIPA as one of its identity domains and set up OpenSSH to use the SSSD tooling for managing user keys.' I was hoping someone can shed light on how to do that. Or if someone has configured their IPA clients to enable key-based SSH to clients, can they please share their experience. Thanks. On Thu, Apr 17, 2014 at 5:48 PM, Dmitri Pal wrote: > On 04/17/2014 02:42 PM, quest monger wrote: > > I have setup freeipa server, and added a centos client that my ipa users > can now ssh too by using the freeipa account credentials. > Now, i would like my users to be able to ssh to this centos client using > keys. > I read this - http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA > _Guide/user-keys.html > I generated the key-pair, and added the public key to user account in > freeipa web console. > > Towards the end of that document, i found this - > "After uploading the user keys, configure SSSD to use FreeIPA as one of > its identity domains and set up OpenSSH to use the SSSD tooling for > managing user keys." > No instructions in the document on how to do this. > > Do i need to do anything on the centos client-side to make this work? > > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > yum install ipa-client > > then run ipa-client-install with arguments you need (see man pages or > manual) which will configure your client. Depending on the version it will > also be able to configure SSH integration. > > See man on ipa-client-install > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.holway at gmail.com Sun Apr 20 08:29:56 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Sun, 20 Apr 2014 09:29:56 +0100 Subject: [Freeipa-users] setup key-based ssh using freeipa In-Reply-To: References: <53504C33.3070701@redhat.com> Message-ID: This should just work. Are you sure that you added the key properly? Make sure you click the "update" link after adding the key. I often made this mistake in the past. On 20 April 2014 09:17, quest monger wrote: > I already ran that command to configure centos host as client. I used > 'ipa-client-install --mkhomedir --no-ntp'. > Now my IPA users are able to SSH to that box, using passwords set in IPA. > Next I would like them to SSH using keys. > When I looked through the document for more info, I found this line - 'After > uploading the user keys, configure SSSD to use FreeIPA as one of its > identity domains and set up OpenSSH to use the SSSD tooling for managing > user keys.' > I was hoping someone can shed light on how to do that. Or if someone has > configured their IPA clients to enable key-based SSH to clients, can they > please share their experience. > > Thanks. > > > > On Thu, Apr 17, 2014 at 5:48 PM, Dmitri Pal wrote: >> >> On 04/17/2014 02:42 PM, quest monger wrote: >> >> I have setup freeipa server, and added a centos client that my ipa users >> can now ssh too by using the freeipa account credentials. >> Now, i would like my users to be able to ssh to this centos client using >> keys. >> I read this - >> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/user-keys.html >> I generated the key-pair, and added the public key to user account in >> freeipa web console. >> >> Towards the end of that document, i found this - >> "After uploading the user keys, configure SSSD to use FreeIPA as one of >> its identity domains and set up OpenSSH to use the SSSD tooling for managing >> user keys." >> No instructions in the document on how to do this. >> >> Do i need to do anything on the centos client-side to make this work? >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> yum install ipa-client >> >> then run ipa-client-install with arguments you need (see man pages or >> manual) which will configure your client. Depending on the version it will >> also be able to configure SSH integration. >> >> See man on ipa-client-install >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From simo at redhat.com Sun Apr 20 14:38:37 2014 From: simo at redhat.com (Simo Sorce) Date: Sun, 20 Apr 2014 10:38:37 -0400 Subject: [Freeipa-users] Root certificates In-Reply-To: References: <53527956.1040609@martos.bme.hu> Message-ID: <1398004717.2628.216.camel@willson.li.ssimo.org> On Sun, 2014-04-20 at 07:29 +0100, Andrew Holway wrote: > >> I would like to install the root certificate from my freeipa > >> installation into some browsers and other clients. > >> > >> If this statement makes sense; does anyone have a guide for this? > >> > > > > All you need to do is installing http://ipaserver/ipa/config/ca.crt . > > Brilliant! Thanks. The FreeIPA certificate is also available on each freeipa client in /etc/ipa/ca.crt, it is downloaded there securely so you know it is the real one. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Sun Apr 20 15:37:05 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 20 Apr 2014 11:37:05 -0400 Subject: [Freeipa-users] External collaboration edits In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E6B00D0@001FSN2MPN1-044.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6B00D0@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: <5353E9A1.2010609@redhat.com> On 04/19/2014 07:46 PM, Nordgren, Bryce L -FS wrote: > > I've run out of time for today, but the external collaboration pages > are slowly evolving. > > http://www.freeipa.org/page/External_Users_in_IPA > > Dimitri observed that my RFE page was too long. I observe it also has > too much stuff unrelated to the actual meat of the RFE. So I factored > out most of the Kerberos stuff into a different page. I also tried to > focus the RFE to just creating entries in LDAP for external users so > they can: a] participate in POSIX groups; and b] have locally-defined > POSIX attributes. > > http://www.freeipa.org/page/Collaboration_with_Kerberos > > This is where all the Kerberos stuff went. I also added in "Option A" > from Petr's email. Option B will come along later, when I pick this up > again. Mechanism three has more to do with Ipsilon than IPA, and basic > functions required of the Ipsilon gateway server are articulated there > (regardless of the particular authentication method.) > > Send comments to the list. I really appreciate Option A! Send more > stuff I didn't think of. > Last week was Red Hat summit. Things piled up. I will try to get to these pages by the end of the week. > > Bryce > > > > > > This electronic message contains information generated by the USDA > solely for the intended recipients. Any unauthorized interception of > this message or the use or disclosure of the information it contains > may violate the law and subject the violator to civil or criminal > penalties. If you believe you have received this message in error, > please notify the sender and delete the email immediately. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Apr 21 12:32:17 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 21 Apr 2014 08:32:17 -0400 Subject: [Freeipa-users] experience using IPA in a mixed environment In-Reply-To: <53533F05.90908@yahoo.ca> References: <1396715090.39565.YahooMailNeo@web140903.mail.bf1.yahoo.com> <534299F6.8090200@redhat.com> <53533F05.90908@yahoo.ca> Message-ID: <53550FD1.2090203@redhat.com> Carl E. Ma wrote: > Hi Rob/all, > > The original freeipa-client 2.1.4 on ubuntu 12.04 doesn't have > "ipa-client-automount" command. I manually configured the autofs as > following: > > ===*/etc/autofs_ldap_autofs*=== > root at ecs-94a55510:/etc# more autofs_ldap_auth.conf > > > > usetls="yes" > tlsrequired="yes" > authrequired="yes" > authtype="GSSAPI" > clientprinc="host/ecs-94a55510.ecs.ads.xxx.com at ECS.ADS.XXX.COM" > credentialcache="/tmp/krb5cc_0" > > /> > ===end of autofs_ldap_autofs=== > ===*/etc/default/autof**s*=== > MASTER_MAP_NAME="automountmapname=auto.master,cn=default,cn=automount,dc=ecs,dc=ads,dc=xxx,dc=com" > LOGGING="debug" > MAP_OBJECT_CLASS="automountMap" > ENTRY_OBJECT_CLASS="automount" > MAP_ATTRIBUTE="automountMapName" > ENTRY_ATTRIBUTE="automountKey" > VALUE_ATTRIBUTE="automountInformation" > LDAP_URI="ldap://ecs-1a5d4287.ecs.ads.xxx.com" > SEARCH_BASE="cn=default,cn=automount,dc=ecs,dc=ads,dc=xxx,dc=com" > ===end of /etc/default/autofs=== > ===*/etc/nsswitch.conf*=== > passwd: compat sss > group: compat sss > shadow: compat > > hosts: files dns > networks: files > > protocols: db files > services: db files > ethers: db files > rpc: db files > > netgroup: nis sss > sudoers: files ldap > automount: files ldap > ===end of /etc/nsswitch.conf=== > ===*/etc/default/nfs-common*=== > NEED_STATD= > STATDOPTS= > NEED_IDMAP=yes > NEED_GSSD=yes > ===end of nfs-common=== > ===here is*/etc/auto.master*=== > #cat "+auto.master" >> /etc/auto.master > ===end of auto.master=== > > On IPA server, I add the NFS service for that client as: > # ipa service-add nfs/ecs-94a55510.ecs.ads.xxx.com > > But none ldap automount maps are shown in "automount -m" output. From > below syslog error messages, client server can't directly connect to > IPA(ldap server) for auto.master map. > *===* > root at ecs-94a55510:/etc# automount -m > find_server: trying server uri ldap://ecs-1a5d4287.ecs.ads.xxx.com > init_ldap_connection: lookup(ldap): TLS required but START_TLS failed: > Connect error > lookup(ldap): couldn't connect to server ldap://ecs-1a5d4287.ecs.ads.xxx.com > do_reconnect: lookup(ldap): failed to find available server > > autofs dump map information > =========================== > > global options: none configured > no master map entries found > > In /var/log/syslog, here are the errors: > Apr 19 23:09:40 ecs-94a55510 automount[17476]: parse_init: parse(sun): > init gathered global options: (null) > Apr 19 23:09:40 ecs-94a55510 automount[17476]: lookup_nss_read_master: > reading master ldap auto.master > Apr 19 23:09:40 ecs-94a55510 automount[17476]: parse_init: parse(sun): > init gathered global options: (null) > Apr 19 23:09:40 ecs-94a55510 automount[17476]: lookup(file): failed to > read included master map auto.master > *===* > > The same ubuntu 12.04 host, sudo also can't retrieve sudoers information > from IPA server using ldap(sudo on ubuntu 12.04 doesn't support sssd), I > double the problem is with ldap client function on this host. If I > missed anything obvious, please let me know. Update the openldap configuration file (/etc/openldap/ldap.conf on Fedora/RHEL) and add TLS_CACERT /etc/ipa/ca.crt rob From lincoln.fessenden at jefferson.edu Mon Apr 21 13:56:16 2014 From: lincoln.fessenden at jefferson.edu (Lincoln Fessenden) Date: Mon, 21 Apr 2014 09:56:16 -0400 Subject: [Freeipa-users] Client Install - I'm clueless In-Reply-To: <53505559.5080603@redhat.com> References: <20140417175239.GA3558@lcf004.edison.tju.edu> <53504B7F.1020807@redhat.com> <53505559.5080603@redhat.com> Message-ID: <20140421135616.GB27974@lcf004.edison.tju.edu> Thanks go to both you and Dmitri Pal for responding to me. When I got your messages I decided to do a clean install and capture the errors for you and, wouldn't ya know it, they worked fine. :) On Thu, Apr 17, 2014 at 06:27:37PM -0400, Rob Crittenden wrote: > Dmitri Pal wrote: > >On 04/17/2014 01:52 PM, Lincoln Fessenden wrote: > >>Hi folks! > >>First time I played with this was yesterday so forgive me if I am way > >>behind the median user here. > >>I installed the server twice, both times on RHEL 6.5. Seems to work > >>just fine and the install goes smooth. First install of the client > >>was on a RHEL 7 beta machine, which worked but I could not get server > >>exclusion rules working (all or nothing), hence the server reinstall. > >>Next I tried ipa-client on a brand new RHEL 6.5 box. This will NOT > >>complete installation and the same is true for 5.10. Different errors > >>though. 6.5 errors out after sending xml to the ipa-server and 5.10 > >>right after I provide the domain name. Since both of these machines > >>are new installs and current for the release, I have got to believe I > >>am missing something somewhere - some missing software dependency? I > >>almost never have seen software in the enterprise repository that is > >>just broken... Help? > >> > >Most likely there some DNS issues. Please check your DNS, /etc/hosts, etc. > > > >Can you provide any client install logs? > >That would really help. > > > >Also http://www.freeipa.org/page/Troubleshooting might be helpful. > > > > Yes, seeing the errors would be quite helpful too, the more context > the better (/var/log/ipaclient-install.log). > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Lincoln Fessenden Jeff-IT Production Operations Manager Senior Linux Systems Administrator 215-503-0986 The information contained in this transmission contains privileged and confidential information. It is intended only for the use of the person named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CAUTION: Intended recipients should NOT use email communication for emergent or urgent health care matters. From deanhunter at comcast.net Mon Apr 21 19:05:47 2014 From: deanhunter at comcast.net (Dean Hunter) Date: Mon, 21 Apr 2014 14:05:47 -0500 Subject: [Freeipa-users] Could not chdir to home directory /home/net/dean: Permission denied Message-ID: <1398107147.23195.8.camel@host.hunter.org> I am sorry, but I have forgotten where to start to diagnose this problem. Please remind me. [dean at host ~]$ ssh desktop.hunter.org Last login: Sun Apr 20 21:12:38 2014 from host.hunter.org Could not chdir to home directory /home/net/dean: Permission denied -bash: /home/net/dean/.bash_profile: Permission denied -bash-4.2$ pwd / -bash-4.2$ ls -l /home total 4 drwx------. 4 local local 4096 Apr 20 21:04 local drwxr-xr-x. 3 root root 0 Apr 21 13:48 net -bash-4.2$ ls -l /home/net total 8 drwx--x---. 29 dean dean 4096 Apr 20 21:28 dean -bash-4.2$ ls -l /home/net/dean ls: cannot access /home/net/dean: Permission denied -bash-4.2$ whoami dean -bash-4.2$ exit logout -bash: /home/net/dean/.bash_logout: Permission denied Connection to desktop.hunter.org closed. [dean at host ~]$ desktop.hunter.org is a VM that I have rebuilt several times trying to work around this problem. ipa-client-install and ipa-client-automount completed without error messages. /home/net/dean is accessible when I log-in through gdm and Virtual Machine Manager. -------------- next part -------------- An HTML attachment was scrubbed... URL: From raubvogel at gmail.com Mon Apr 21 19:51:51 2014 From: raubvogel at gmail.com (Mauricio Tavares) Date: Mon, 21 Apr 2014 15:51:51 -0400 Subject: [Freeipa-users] Could not chdir to home directory /home/net/dean: Permission denied In-Reply-To: <1398107147.23195.8.camel@host.hunter.org> References: <1398107147.23195.8.camel@host.hunter.org> Message-ID: On Mon, Apr 21, 2014 at 3:05 PM, Dean Hunter wrote: > I am sorry, but I have forgotten where to start to diagnose this problem. > Please remind me. > > [dean at host ~]$ ssh desktop.hunter.org > Last login: Sun Apr 20 21:12:38 2014 from host.hunter.org > Could not chdir to home directory /home/net/dean: Permission denied > -bash: /home/net/dean/.bash_profile: Permission denied > -bash-4.2$ pwd > / > -bash-4.2$ ls -l /home > total 4 > drwx------. 4 local local 4096 Apr 20 21:04 local > drwxr-xr-x. 3 root root 0 Apr 21 13:48 net > -bash-4.2$ ls -l /home/net > total 8 > drwx--x---. 29 dean dean 4096 Apr 20 21:28 dean > -bash-4.2$ ls -l /home/net/dean > ls: cannot access /home/net/dean: Permission denied > -bash-4.2$ whoami > dean > -bash-4.2$ exit > logout > -bash: /home/net/dean/.bash_logout: Permission denied > Connection to desktop.hunter.org closed. > [dean at host ~]$ > > desktop.hunter.org is a VM that I have rebuilt several times trying to work > around this problem. ipa-client-install and ipa-client-automount completed > without error messages. /home/net/dean is accessible when I log-in through > gdm and Virtual Machine Manager. > If you were using pam, I would say the config for when you ssh in is different than that for when you use gdm. Specifically it is not getting creating a cache file when you log in. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From deanhunter at comcast.net Mon Apr 21 20:03:22 2014 From: deanhunter at comcast.net (Dean Hunter) Date: Mon, 21 Apr 2014 15:03:22 -0500 Subject: [Freeipa-users] Could not chdir to home directory /home/net/dean: Permission denied In-Reply-To: <1398107147.23195.8.camel@host.hunter.org> References: <1398107147.23195.8.camel@host.hunter.org> Message-ID: <1398110602.23195.13.camel@host.hunter.org> On Mon, 2014-04-21 at 14:05 -0500, Dean Hunter wrote: > I am sorry, but I have forgotten where to start to diagnose this > problem. Please remind me. > > [dean at host ~]$ ssh desktop.hunter.org > Last login: Sun Apr 20 21:12:38 2014 from host.hunter.org > Could not chdir to home directory /home/net/dean: Permission denied > -bash: /home/net/dean/.bash_profile: Permission denied > -bash-4.2$ pwd > / > -bash-4.2$ ls -l /home > total 4 > drwx------. 4 local local 4096 Apr 20 21:04 local > drwxr-xr-x. 3 root root 0 Apr 21 13:48 net > -bash-4.2$ ls -l /home/net > total 8 > drwx--x---. 29 dean dean 4096 Apr 20 21:28 dean > -bash-4.2$ ls -l /home/net/dean > ls: cannot access /home/net/dean: Permission denied > -bash-4.2$ whoami > dean > -bash-4.2$ exit > logout > -bash: /home/net/dean/.bash_logout: Permission denied > Connection to desktop.hunter.org closed. > [dean at host ~]$ > > desktop.hunter.org is a VM that I have rebuilt several times trying to > work around this problem. ipa-client-install and ipa-client-automount > completed without error messages. /home/net/dean is accessible when I > log-in through gdm and Virtual Machine Manager. > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Now it appears as though that ssh fails to access the auto-mount home directory until after successful gdm log-in: [dean at host ~]$ ssh desktop.hunter.org Last login: Mon Apr 21 14:34:51 2014 from host.hunter.org [dean at desktop ~]$ pwd /home/net/dean [dean at desktop ~]$ sudo -l Matching Defaults entries for dean on desktop: requiretty, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin User dean may run the following commands on desktop: (root : root) NOPASSWD: ALL [dean at desktop ~]$ yum list installed freeipa-* Loaded plugins: langpacks, refresh-packagekit Installed Packages freeipa-client.x86_64 3.3.4-3.fc20 @local-updates freeipa-python.x86_64 3.3.4-3.fc20 @local-updates [dean at desktop ~]$ logout Connection to desktop.hunter.org closed. [dean at host ~]$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From raubvogel at gmail.com Mon Apr 21 20:19:09 2014 From: raubvogel at gmail.com (Mauricio Tavares) Date: Mon, 21 Apr 2014 16:19:09 -0400 Subject: [Freeipa-users] Could not chdir to home directory /home/net/dean: Permission denied In-Reply-To: <1398110602.23195.13.camel@host.hunter.org> References: <1398107147.23195.8.camel@host.hunter.org> <1398110602.23195.13.camel@host.hunter.org> Message-ID: On Mon, Apr 21, 2014 at 4:03 PM, Dean Hunter wrote: > On Mon, 2014-04-21 at 14:05 -0500, Dean Hunter wrote: > > I am sorry, but I have forgotten where to start to diagnose this problem. > Please remind me. > > [dean at host ~]$ ssh desktop.hunter.org > Last login: Sun Apr 20 21:12:38 2014 from host.hunter.org > Could not chdir to home directory /home/net/dean: Permission denied > -bash: /home/net/dean/.bash_profile: Permission denied > -bash-4.2$ pwd > / > -bash-4.2$ ls -l /home > total 4 > drwx------. 4 local local 4096 Apr 20 21:04 local > drwxr-xr-x. 3 root root 0 Apr 21 13:48 net > -bash-4.2$ ls -l /home/net > total 8 > drwx--x---. 29 dean dean 4096 Apr 20 21:28 dean > -bash-4.2$ ls -l /home/net/dean > ls: cannot access /home/net/dean: Permission denied > -bash-4.2$ whoami > dean > -bash-4.2$ exit > logout > -bash: /home/net/dean/.bash_logout: Permission denied > Connection to desktop.hunter.org closed. > [dean at host ~]$ > > desktop.hunter.org is a VM that I have rebuilt several times trying to work > around this problem. ipa-client-install and ipa-client-automount completed > without error messages. /home/net/dean is accessible when I log-in through > gdm and Virtual Machine Manager. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > Now it appears as though that ssh fails to access the auto-mount home > directory until after successful gdm log-in: > I still suck at osssd (I assume the host you are connecting to is rh/centos/fedora), but in pam you have to define each way you are logging (gdm, ssh, screensaver) in to get a kerberos ticket, and create the cache in /tmp after you are successfully authenticated. automount then can use that ticket to do its thing. You will also notice if you kinit manually you will then be able to cd to that directory. That is where I would start looking at. > > [dean at host ~]$ ssh desktop.hunter.org > Last login: Mon Apr 21 14:34:51 2014 from host.hunter.org > [dean at desktop ~]$ pwd > /home/net/dean > [dean at desktop ~]$ sudo -l > Matching Defaults entries for dean on desktop: > requiretty, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE > INPUTRC > KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG > LC_ADDRESS > LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT > LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER > LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET > XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin > > User dean may run the following commands on desktop: > (root : root) NOPASSWD: ALL > [dean at desktop ~]$ yum list installed freeipa-* > Loaded plugins: langpacks, refresh-packagekit > Installed Packages > freeipa-client.x86_64 3.3.4-3.fc20 > @local-updates > freeipa-python.x86_64 3.3.4-3.fc20 > @local-updates > [dean at desktop ~]$ logout > > Connection to desktop.hunter.org closed. > [dean at host ~]$ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From Dave.Jones at spilgames.com Tue Apr 22 14:15:29 2014 From: Dave.Jones at spilgames.com (Dave Jones) Date: Tue, 22 Apr 2014 14:15:29 +0000 Subject: [Freeipa-users] AD-IPA sync from multiple AD controllers Message-ID: Hi, According to the IPA 3.0 Identity Management Guide chapter 15.1: "Synchronization can only be configured with one Active Directory domain controller. However, it is possible to have a list of failover Active Directory domain controllers.? Later on, chapter 15.6 ?Managing Password Synchronisation? states that the "Password Sync Service must be installed on each Active Directory domain controller." Do we need multiple AD-IPA replication agreements when there are multiple AD controllers in an AD domain? Cheers, Dave From rcritten at redhat.com Tue Apr 22 14:57:45 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Apr 2014 10:57:45 -0400 Subject: [Freeipa-users] AD-IPA sync from multiple AD controllers In-Reply-To: References: Message-ID: <53568369.2060304@redhat.com> Dave Jones wrote: > Hi, > > According to the IPA 3.0 Identity Management Guide chapter 15.1: > > "Synchronization can only be configured with one Active Directory domain > controller. However, it is possible to have a list of failover Active > Directory domain controllers.? > > Later on, chapter 15.6 ?Managing Password Synchronisation? states that the > "Password Sync Service must be installed on each Active Directory domain > controller." > > Do we need multiple AD-IPA replication agreements when there are multiple > AD controllers in an AD domain? No. You need the passsync service installed on all controllers because there is no way of knowing where a user will change their password. This service captures the cleartext password and sends it, over SSL, to the IPA server so we can store it. We need the cleartext password because we can't use the AD password hash directly. rob From Dave.Jones at spilgames.com Wed Apr 23 07:52:40 2014 From: Dave.Jones at spilgames.com (Dave Jones) Date: Wed, 23 Apr 2014 07:52:40 +0000 Subject: [Freeipa-users] AD-IPA sync from multiple AD controllers In-Reply-To: <53568369.2060304@redhat.com> References: <53568369.2060304@redhat.com> Message-ID: Thanks for the clarification Rob, you confirmed what I already thought. On 22/04/14 16:57, "Rob Crittenden" wrote: >Dave Jones wrote: >> Hi, >> >> According to the IPA 3.0 Identity Management Guide chapter 15.1: >> >> "Synchronization can only be configured with one Active Directory >>domain >> controller. However, it is possible to have a list of failover Active >> Directory domain controllers.? >> >> Later on, chapter 15.6 ?Managing Password Synchronisation? states that >>the >> "Password Sync Service must be installed on each Active Directory domain >> controller." >> >> Do we need multiple AD-IPA replication agreements when there are >>multiple >> AD controllers in an AD domain? > >No. You need the passsync service installed on all controllers because >there is no way of knowing where a user will change their password. This >service captures the cleartext password and sends it, over SSL, to the >IPA server so we can store it. We need the cleartext password because we >can't use the AD password hash directly. > >rob From pspacek at redhat.com Wed Apr 23 08:55:45 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 23 Apr 2014 10:55:45 +0200 Subject: [Freeipa-users] AD-IPA sync from multiple AD controllers In-Reply-To: References: <53568369.2060304@redhat.com> Message-ID: <53578011.5010203@redhat.com> On 23.4.2014 09:52, Dave Jones wrote: > Thanks for the clarification Rob, you confirmed what I already thought. Dave, it would be great if you could rephrase problematic paragraphs in docs to make it understandable. If you can spend few minutes on it, please see http://www.freeipa.org/page/Contribute/Documentation Thanks! Petr^2 Spacek > On 22/04/14 16:57, "Rob Crittenden" wrote: > >> Dave Jones wrote: >>> Hi, >>> >>> According to the IPA 3.0 Identity Management Guide chapter 15.1: >>> >>> "Synchronization can only be configured with one Active Directory >>> domain >>> controller. However, it is possible to have a list of failover Active >>> Directory domain controllers.? >>> >>> Later on, chapter 15.6 ?Managing Password Synchronisation? states that >>> the >>> "Password Sync Service must be installed on each Active Directory domain >>> controller." >>> >>> Do we need multiple AD-IPA replication agreements when there are >>> multiple >>> AD controllers in an AD domain? >> >> No. You need the passsync service installed on all controllers because >> there is no way of knowing where a user will change their password. This >> service captures the cleartext password and sends it, over SSL, to the >> IPA server so we can store it. We need the cleartext password because we >> can't use the AD password hash directly. From stbenjam at redhat.com Wed Apr 23 14:00:34 2014 From: stbenjam at redhat.com (Stephen Benjamin) Date: Wed, 23 Apr 2014 10:00:34 -0400 (EDT) Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <1507663006.4219737.1398260957556.JavaMail.zimbra@redhat.com> Message-ID: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> Hi All, As part of the next release of Foreman, 1.5, realm join integration is being introduced. The first provider is, of course, FreeIPA. :-) The first release candidate of 1.5 is out now and I'd really appreciate it if anyone wants to give the FreeIPA integration a good workout. You can see it in action during today's sprint demo starting at about 36 minutes in: https://www.youtube.com/watch?v=XliDyFFi-SI#t=36m00 Docs about the FreeIPA stuff are here: http://theforeman.org/manuals/1.5/index.html#4.3.11FreeIPARealm If you run into any problems, I'm happy to help, I'm stbenjam over on #theforeman or #freeipa IRC channels. Note - There's at least one bug whose fix should be merged in RC2: unenrolled hosts aren't deleted from IPA correctly. Otherwise it should all work as advertised! Thanks!! Stephen -- Stephen Benjamin stephen at redhat.com ______________________________________________________ Reg. Adresse: Rudower Chaussee 29, D-12489 Berlin Handelsregister: Amtsgericht Muenchen HRB 153243 Gesch?ftsf?hrer: Mark Hegarty,Charlie Peters, Michael Cunningham, Charles Cachera From dpal at redhat.com Wed Apr 23 20:16:16 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 23 Apr 2014 16:16:16 -0400 Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> Message-ID: <53581F90.3030802@redhat.com> On 04/23/2014 10:00 AM, Stephen Benjamin wrote: > Hi All, > > As part of the next release of Foreman, 1.5, realm join integration > is being introduced. The first provider is, of course, FreeIPA. :-) > > The first release candidate of 1.5 is out now and I'd really > appreciate it if anyone wants to give the FreeIPA integration a good > workout. You can see it in action during today's sprint demo starting > at about 36 minutes in: > > https://www.youtube.com/watch?v=XliDyFFi-SI#t=36m00 > > Docs about the FreeIPA stuff are here: > > http://theforeman.org/manuals/1.5/index.html#4.3.11FreeIPARealm > > If you run into any problems, I'm happy to help, I'm stbenjam > over on #theforeman or #freeipa IRC channels. > > Note - There's at least one bug whose fix should be merged in RC2: > unenrolled hosts aren't deleted from IPA correctly. Otherwise it > should all work as advertised! > > Thanks!! > > Stephen > > Very cool! Several questions: - Is it using IPA smart proxy and if not when and how it will? We would probably need to add the instruction on how to set it up instead of the native one. I suspect there are some differences and the reason why one would be used over another. - I think the setup script should probably be a part of IPA smart proxy project rather than a part of Foreman. IMO it is in the boat as mart proxy as it links IPA and Foreman together. What do you think? May be there should be spacial repo in IPA. As we move forward we would need to have more and more simple scripts to setup specific integration aspects with different projects. This is just the first one of them so we need to define what we want to do with the next one when it emerges. - You have FreeIPA there as a realm type. Would it be possible to change this string because in RHEL it is called "Identity Management"? - Does this support a case when the machine needs to be re-provisioned? Does it do the right cleanup? - Moving forward it might make sense to be able to pass other parameters to the realm join to pass to ipa client install. I think we need to explore this more. For example do you want to configure SUDO or automaint integration on the provisioned host? Do you want to generate and upload host fingerprint, etc. Where is the right place to track this work? This is all that comes to mind so far. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From stbenjam at redhat.com Wed Apr 23 21:07:58 2014 From: stbenjam at redhat.com (Stephen Benjamin) Date: Wed, 23 Apr 2014 17:07:58 -0400 (EDT) Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <53581F90.3030802@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <53581F90.3030802@redhat.com> Message-ID: <51109989.4612124.1398287278791.JavaMail.zimbra@redhat.com> Hi, ----- Original Message ----- > From: "Dmitri Pal" > To: freeipa-users at redhat.com, stbenjam at redhat.com > Sent: Wednesday, April 23, 2014 10:16:16 PM > Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 > > On 04/23/2014 10:00 AM, Stephen Benjamin wrote: > > Hi All, > > > > As part of the next release of Foreman, 1.5, realm join integration > > is being introduced. The first provider is, of course, FreeIPA. :-) > > > > The first release candidate of 1.5 is out now and I'd really > > appreciate it if anyone wants to give the FreeIPA integration a good > > workout. You can see it in action during today's sprint demo starting > > at about 36 minutes in: > > > > https://www.youtube.com/watch?v=XliDyFFi-SI#t=36m00 > > > > Docs about the FreeIPA stuff are here: > > > > http://theforeman.org/manuals/1.5/index.html#4.3.11FreeIPARealm > > > > If you run into any problems, I'm happy to help, I'm stbenjam > > over on #theforeman or #freeipa IRC channels. > > > > Note - There's at least one bug whose fix should be merged in RC2: > > unenrolled hosts aren't deleted from IPA correctly. Otherwise it > > should all work as advertised! > > > > Thanks!! > > > > Stephen > > > > > Very cool! > > Several questions: > - Is it using IPA smart proxy and if not when and how it will? We would > probably need to add the instruction on how to set it up instead of the > native one. I suspect there are some differences and the reason why one > would be used over another. It is using a provider built-in to the Foreman Smart Proxy. However, Rob and I collaborated to ensure the APIs are compatible. You should be able to swap out the Foreman proxy for the FreeIPA proxy when it's released. Having the proxy in your repos, and very easily configured is brilliant, it makes the user experience so much better. We do need to make sure it gets SSL authentication enabled. But over time, I expect Foreman's proxy to be deprecated and most people to use FreeIPA's, but we do need ours for older versions. > - I think the setup script should probably be a part of IPA smart proxy > project rather than a part of Foreman. IMO it is in the boat as mart > proxy as it links IPA and Foreman together. What do you think? May be > there should be spacial repo in IPA. As we move forward we would need to > have more and more simple scripts to setup specific integration aspects > with different projects. This is just the first one of them so we need > to define what we want to do with the next one when it emerges. The setup script in the video is just creating some permissions we need, it's here: http://projects.theforeman.org/projects/foreman/wiki/IPASmartProxyUser I would kind of like to see this added to FreeIPA as a role, or somehow distributed with the FreeIPA proxy package. I opened an issue about this a while back: https://fedorahosted.org/freeipa/ticket/4252 > - You have FreeIPA there as a realm type. Would it be possible to change > this string because in RHEL it is called "Identity Management"? "FreeIPA" is used pretty much everywhere, like config files. Just the UI wouldn't be a big issue to alter, if you want to change it for Satellite. > - Does this support a case when the machine needs to be re-provisioned? > Does it do the right cleanup? Yup, it disables the host if enrolled, and then requests a new OTP during re-provision. If you update the host group in Foreman, we also send that as a userclass attribute for use with automembership, although automembership currently works on initial creation. > - Moving forward it might make sense to be able to pass other parameters > to the realm join to pass to ipa client install. I think we need to > explore this more. For example do you want to configure SUDO or > automaint integration on the provisioned host? Do you want to generate > and upload host fingerprint, etc. Where is the right place to track this > work? The OTP is accessible to any provisioning template or snippet, so you can do things however you want. We ship some provisioning templates distributed with Foreman, which use either 1 or 2 ways: Fedora 20+ (and RHEL 7+): - Built in Anaconda realm join, https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration < Fedora 20, RHEL 6, etc: - Kickstart snippet: https://github.com/theforeman/community-templates/blob/master/snippets/freeipa_register.erb For Anaconda realm join, I don't see where you can pass additional options to the installer. For the FreeIPA snippet, you can add a global parameter to add arbitrary command line options to ipa-client-install. The snippet and provisioning can be customized however, and special cases may want to make use of foreman_hooks: https://github.com/theforeman/foreman_hooks However, I specifically predicted the sudoers question, so I have this blog post about it: https://bitbin.de/blog/2014/04/freeipa-sudoers-with-puppet-foreman/ I haven't investigated automount, maybe it's something I can consider adding to the ipaclient puppet module. Thanks for the e-mail! I'm definitely interested in feedback. Feature requests, PR's, etc are all welcome too :-) http://projects.theforeman.org/projects/foreman/issues/new - Stephen From dpal at redhat.com Wed Apr 23 22:28:48 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 23 Apr 2014 18:28:48 -0400 Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <51109989.4612124.1398287278791.JavaMail.zimbra@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <53581F90.3030802@redhat.com> <51109989.4612124.1398287278791.JavaMail.zimbra@redhat.com> Message-ID: <53583EA0.9040104@redhat.com> On 04/23/2014 05:07 PM, Stephen Benjamin wrote: > Hi, > > ----- Original Message ----- >> From: "Dmitri Pal" >> To: freeipa-users at redhat.com, stbenjam at redhat.com >> Sent: Wednesday, April 23, 2014 10:16:16 PM >> Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 >> >> On 04/23/2014 10:00 AM, Stephen Benjamin wrote: >>> Hi All, >>> >>> As part of the next release of Foreman, 1.5, realm join integration >>> is being introduced. The first provider is, of course, FreeIPA. :-) >>> >>> The first release candidate of 1.5 is out now and I'd really >>> appreciate it if anyone wants to give the FreeIPA integration a good >>> workout. You can see it in action during today's sprint demo starting >>> at about 36 minutes in: >>> >>> https://www.youtube.com/watch?v=XliDyFFi-SI#t=36m00 >>> >>> Docs about the FreeIPA stuff are here: >>> >>> http://theforeman.org/manuals/1.5/index.html#4.3.11FreeIPARealm >>> >>> If you run into any problems, I'm happy to help, I'm stbenjam >>> over on #theforeman or #freeipa IRC channels. >>> >>> Note - There's at least one bug whose fix should be merged in RC2: >>> unenrolled hosts aren't deleted from IPA correctly. Otherwise it >>> should all work as advertised! >>> >>> Thanks!! >>> >>> Stephen >>> >>> >> Very cool! >> >> Several questions: >> - Is it using IPA smart proxy and if not when and how it will? We would >> probably need to add the instruction on how to set it up instead of the >> native one. I suspect there are some differences and the reason why one >> would be used over another. > It is using a provider built-in to the Foreman Smart Proxy. However, Rob > and I collaborated to ensure the APIs are compatible. You should be able > to swap out the Foreman proxy for the FreeIPA proxy when it's released. I know, I am sort of asking for documentation and comparison so that people would know which one we prefer them to use and why. > Having the proxy in your repos, and very easily configured is > brilliant, it makes the user experience so much better. We do need to > make sure it gets SSL authentication enabled. But over time, I expect > Foreman's proxy to be deprecated and most people to use FreeIPA's, but > we do need ours for older versions. OK. > >> - I think the setup script should probably be a part of IPA smart proxy >> project rather than a part of Foreman. IMO it is in the boat as mart >> proxy as it links IPA and Foreman together. What do you think? May be >> there should be spacial repo in IPA. As we move forward we would need to >> have more and more simple scripts to setup specific integration aspects >> with different projects. This is just the first one of them so we need >> to define what we want to do with the next one when it emerges. > The setup script in the video is just creating some permissions we > need, it's here: > > http://projects.theforeman.org/projects/foreman/wiki/IPASmartProxyUser > > I would kind of like to see this added to FreeIPA as a role, or somehow > distributed with the FreeIPA proxy package. > > I opened an issue about this a while back: > https://fedorahosted.org/freeipa/ticket/4252 Yes we have it in the right bucket so this is coming. The question is more about where it really belongs and in what shape of form. Should be an out of box setup so that once you install IPA it is already ready for Foreman integration? Should it be a script that is run on the server? Than can be something like: ipa-enable-integration command with arguments: --foreman - would load everything needed for foreman --OpenStack - would load everything needed for OpenStack --foo - will handle foo ... The alternative is to have a script with proxy in the proxy package. That would work too. I just do not knwo what approach is best thus asking the question. > >> - You have FreeIPA there as a realm type. Would it be possible to change >> this string because in RHEL it is called "Identity Management"? > "FreeIPA" is used pretty much everywhere, like config files. Just the UI > wouldn't be a big issue to alter, if you want to change it for Satellite. Yes that would be the case, I think. > >> - Does this support a case when the machine needs to be re-provisioned? >> Does it do the right cleanup? > Yup, it disables the host if enrolled, and then requests a new OTP during > re-provision. > > If you update the host group in Foreman, we also send that as a userclass > attribute for use with automembership, although automembership currently > works on initial creation. Good > >> - Moving forward it might make sense to be able to pass other parameters >> to the realm join to pass to ipa client install. I think we need to >> explore this more. For example do you want to configure SUDO or >> automaint integration on the provisioned host? Do you want to generate >> and upload host fingerprint, etc. Where is the right place to track this >> work? > The OTP is accessible to any provisioning template or snippet, so you > can do things however you want. > > We ship some provisioning templates distributed with Foreman, which > use either 1 or 2 ways: > > Fedora 20+ (and RHEL 7+): > - Built in Anaconda realm join, https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration I do not see a reason for realmd to be used in this case. It does not add any value on top the ipa-client-install and actually limits the amount of the command arguments that can be passed to the client install script. There are two ways to overcome it: make realmd capable of passing arguments it does not know to ipa-client install (that would be a realmd rfe) or use ipa-client-install directly. I think direct use is OK here because one is using IPA smart proxy and expecting the systems to connect to IPA and not to AD. > < Fedora 20, RHEL 6, etc: > - Kickstart snippet: https://github.com/theforeman/community-templates/blob/master/snippets/freeipa_register.erb > > For Anaconda realm join, I don't see where you can pass additional options > to the installer. For the FreeIPA snippet, you can add a global > parameter to add arbitrary command line options to ipa-client-install. See above. I think we should just go and do a direct call to ipa-client-install > > The snippet and provisioning can be customized however, and special > cases may want to make use of foreman_hooks: > > https://github.com/theforeman/foreman_hooks Yes but i do not see what else is needed yet. Potentially there we can start adding SRV records when the deployes system is know to run a particular server. > > However, I specifically predicted the sudoers question, so I > have this blog post about it: > > https://bitbin.de/blog/2014/04/freeipa-sudoers-with-puppet-foreman/ I am not sure it is doing the right thing. In the blog you specify bindpw for SUDO, this means you are configuring SUDO without SSSD integration. If you use IPA it is a command switch on the ipa-client-install command to enable sudo, ssh or automount integration (at least in the latest versions of IPA). I think we should focus on that. https://fedorahosted.org/freeipa/ticket/3740 https://fedorahosted.org/freeipa/ticket/3358 <- but one can run command after install to enable integration with SUDO Honza, martin can you please add the details about SSH and SELinux integration > > I haven't investigated automount, maybe it's something I can > consider adding to the ipaclient puppet module. I see it more as apart of the initial client setup and check boxes: do you want SUDO integration y/n; do you want automount y/n; do you want SELinux user mapping y/n; Do you want SSH integration y/n. Once you deploy you usually do not change these things because they are dictated by general policy rather than something that you turn on and off. > > Thanks for the e-mail! I'm definitely interested in feedback. > Feature requests, PR's, etc are all welcome too :-) We will be putting some PR do not worry! Let us have a plan around open questions here and then I will start reaching out and sharing the news. > > http://projects.theforeman.org/projects/foreman/issues/new > > > - Stephen > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From stbenjam at redhat.com Wed Apr 23 23:23:16 2014 From: stbenjam at redhat.com (Stephen Benjamin) Date: Wed, 23 Apr 2014 19:23:16 -0400 (EDT) Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <53583EA0.9040104@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <53581F90.3030802@redhat.com> <51109989.4612124.1398287278791.JavaMail.zimbra@redhat.com> <53583EA0.9040104@redhat.com> Message-ID: <713211054.4700804.1398295396344.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Dmitri Pal" > To: "Stephen Benjamin" > Cc: freeipa-users at redhat.com > Sent: Thursday, April 24, 2014 12:28:48 AM > Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 > > >> Several questions: > >> - Is it using IPA smart proxy and if not when and how it will? We would > >> probably need to add the instruction on how to set it up instead of the > >> native one. I suspect there are some differences and the reason why one > >> would be used over another. > > It is using a provider built-in to the Foreman Smart Proxy. However, Rob > > and I collaborated to ensure the APIs are compatible. You should be able > > to swap out the Foreman proxy for the FreeIPA proxy when it's released. > > I know, I am sort of asking for documentation and comparison so that > people would know which one we prefer them to use and why. Ok, is there an idea of when the proxy will be released in FreeIPA? 4.0? Or earlier? When it happens, I'll link to it in the Foreman documentation. > > Having the proxy in your repos, and very easily configured is > > brilliant, it makes the user experience so much better. We do need to > > make sure it gets SSL authentication enabled. But over time, I expect > > Foreman's proxy to be deprecated and most people to use FreeIPA's, but > > we do need ours for older versions. > > OK. > > > > >> - I think the setup script should probably be a part of IPA smart proxy > >> project rather than a part of Foreman. IMO it is in the boat as mart > >> proxy as it links IPA and Foreman together. What do you think? May be > >> there should be spacial repo in IPA. As we move forward we would need to > >> have more and more simple scripts to setup specific integration aspects > >> with different projects. This is just the first one of them so we need > >> to define what we want to do with the next one when it emerges. > > The setup script in the video is just creating some permissions we > > need, it's here: > > > > http://projects.theforeman.org/projects/foreman/wiki/IPASmartProxyUser > > > > I would kind of like to see this added to FreeIPA as a role, or somehow > > distributed with the FreeIPA proxy package. > > > > I opened an issue about this a while back: > > https://fedorahosted.org/freeipa/ticket/4252 > > Yes we have it in the right bucket so this is coming. > > The question is more about where it really belongs and in what shape of > form. > Should be an out of box setup so that once you install IPA it is already > ready for Foreman integration? Should it be a script that is run on the > server? Than can be something like: > ipa-enable-integration > command with arguments: > --foreman - would load everything needed for foreman > --OpenStack - would load everything needed for OpenStack > --foo - will handle foo > ... > The alternative is to have a script with proxy in the proxy package. > That would work too. > I just do not knwo what approach is best thus asking the question. Whatever fits with FreeIPA way of doing things...I think just the most important thing is it's relatively easy to setup. > > >> - You have FreeIPA there as a realm type. Would it be possible to change > >> this string because in RHEL it is called "Identity Management"? > > "FreeIPA" is used pretty much everywhere, like config files. Just the UI > > wouldn't be a big issue to alter, if you want to change it for Satellite. > > > Yes that would be the case, I think. > > > > >> - Does this support a case when the machine needs to be re-provisioned? > >> Does it do the right cleanup? > > Yup, it disables the host if enrolled, and then requests a new OTP during > > re-provision. > > > > If you update the host group in Foreman, we also send that as a userclass > > attribute for use with automembership, although automembership currently > > works on initial creation. > > Good > > > > >> - Moving forward it might make sense to be able to pass other parameters > >> to the realm join to pass to ipa client install. I think we need to > >> explore this more. For example do you want to configure SUDO or > >> automaint integration on the provisioned host? Do you want to generate > >> and upload host fingerprint, etc. Where is the right place to track this > >> work? > > The OTP is accessible to any provisioning template or snippet, so you > > can do things however you want. > > > > We ship some provisioning templates distributed with Foreman, which > > use either 1 or 2 ways: > > > > Fedora 20+ (and RHEL 7+): > > - Built in Anaconda realm join, > > https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration > > I do not see a reason for realmd to be used in this case. It does not > add any value on top the ipa-client-install and actually limits the > amount of the command arguments that can be passed to the client install > script. There are two ways to overcome it: make realmd capable of > passing arguments it does not know to ipa-client install (that would be > a realmd rfe) or use ipa-client-install directly. I think direct use is > OK here because one is using IPA smart proxy and expecting the systems > to connect to IPA and not to AD. Well, Foreman will support Active Directory via adcli, when I have a chance to implement the smart proxy - hopefully for Foreman 1.6. Using realmd makes it work regardless of the underlying realm type. I have no horse in the race, but to me, realmd is there and it looks nice to have it just work out of the box. It's one anaconda directive, versus many lines of a an IPA-specific snippet. I would prefer that the work should be done to make realmd have sensible defaults and take some extra options for the specific provider. That's probably not possible immediately, so I'm open to the idea of not using it for FreeIPA. At the end of the day, Foreman delivers the OTP, and users are free to customize things however they want. I see the templates as suggestions with just some sane defaults. If the templates aren't sane, templates are pretty easy to contribute to: https://github.com/theforeman/community-templates And the more I think about it, maybe the freeipa snippet isn't entirely sane and needs some extending (more about this below). > > < Fedora 20, RHEL 6, etc: > > - Kickstart snippet: > > https://github.com/theforeman/community-templates/blob/master/snippets/freeipa_register.erb > > > > For Anaconda realm join, I don't see where you can pass additional options > > to the installer. For the FreeIPA snippet, you can add a global > > parameter to add arbitrary command line options to ipa-client-install. > > See above. I think we should just go and do a direct call to > ipa-client-install > > > > > The snippet and provisioning can be customized however, and special > > cases may want to make use of foreman_hooks: > > > > https://github.com/theforeman/foreman_hooks > > Yes but i do not see what else is needed yet. > Potentially there we can start adding SRV records when the deployes > system is know to run a particular server. > > > > > However, I specifically predicted the sudoers question, so I > > have this blog post about it: > > > > https://bitbin.de/blog/2014/04/freeipa-sudoers-with-puppet-foreman/ > > I am not sure it is doing the right thing. In the blog you specify > bindpw for SUDO, this means you are configuring SUDO without SSSD > integration. If you use IPA it is a command switch on the > ipa-client-install command to enable sudo, ssh or automount integration > (at least in the latest versions of IPA). I think we should focus on that. I'm very interested in this... I wrote the ipaclient module a year ago to suit a specific need for me. I have some consulting customers who use it, but I haven't had much feedback about it from anyone. Suggestions for changes to how I do things would be much appreciated. The way ipaclient is doing things works on *everything*, from a 2-year old release of RH IdM, to the 3.4 nightly I tested not too long ago. It's used in the wild, so I can't just break the compatability there -- but, can I use SSSD setup even on the older versions of IPA? Do you have some info about how to get that working? If so, I'll gladly go to that. > https://fedorahosted.org/freeipa/ticket/3740 > https://fedorahosted.org/freeipa/ticket/3358 <- but one can run command > after install to enable integration with SUDO > > Honza, martin can you please add the details about SSH and SELinux > integration > > > > > > I haven't investigated automount, maybe it's something I can > > consider adding to the ipaclient puppet module. > > I see it more as apart of the initial client setup and check boxes: do > you want SUDO integration y/n; do you want automount y/n; do you want > SELinux user mapping y/n; Do you want SSH integration y/n. Once you > deploy you usually do not change these things because they are dictated > by general policy rather than something that you turn on and off. Right, for this we'd need to extend the freeipa_snippet, and use Foreman parameters for these options. I think it's a great idea, and something I'd gladly implement. For Foreman 1.5, we've really fixed the templates now for the release, but this is something that could probably go into 1.5.1 if the details are hammered out. I'd really appreciate an issue opened about this. How do older versions of IPA respond to unknown options (say, if they don't support sudoers)? I guess I need some kind of matrix of what's supported for each version, so that I can do the appropriate things. > > > > Thanks for the e-mail! I'm definitely interested in feedback. > > Feature requests, PR's, etc are all welcome too :-) > > We will be putting some PR do not worry! > Let us have a plan around open questions here and then I will start > reaching out and sharing the news. Yup, great feedback, thanks! > > > > > http://projects.theforeman.org/projects/foreman/issues/new > > > > > > - Stephen > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > From fredy.sanchez at modmed.com Wed Apr 23 21:57:28 2014 From: fredy.sanchez at modmed.com (Fredy Sanchez) Date: Wed, 23 Apr 2014 17:57:28 -0400 Subject: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing. In-Reply-To: References: <1397568653.19767.289.camel@willson.li.ssimo.org> <534F0036.6070101@redhat.com> Message-ID: Hi all, Sorry for the delay. I am sharing with you a couple of scripts and files we use to enroll our Macs (ML and Mavericks) into our FreeIPA domain. Using Luggage ( https://github.com/unixorn/luggage), we package all of these into a one click installer that can be deployed via ARD, Munki, etc. Now, our environment has very specific requirements, so feel free to ask if there's something you don't understand or that seems incomplete. These assume you already know what FreeIPA is, and have it up and running. These also assume that all the server pre-staging (for example, that all applicable DNS records are already created) for the "enrollee" is done. In sum, these are ideal if all you are missing is to start enrolling Macs into the FreeIPA domain. And you'll have to modify the files to match your FreeIPA domain; we are using example.com for this. The preflight script (freeipa-client-preinstall.sh) will "clean" the environment of the enrollee, and backup existing files that will be modified during the enrollment process. It * Sets the DNS search domain * Adds a "local" search domain to the enrollee to speed up the login process if no FreeIPA server is available during login * Backs up edu.mit.Kerberos if it exists * Backs up krb5.conf if it exists * Backs up any existing LDAP info * Backs up /Library/Preferences/com.apple.loginwindow.plist The postflight script (freeipa-client-postinstall.sh) performs the enrollment. It * Sets email notifications to know if the enrollment failed or succeeded. These notifications will include the who and the why, and a hardware profile from the enrollee that we find useful * Sets and tests many variables needed for a successful enrollment like NTP syncing, a valid hostname, and whether or not all applicable hosts resolve thru your DNS servers * Adjusts /Library/Preferences/com.apple.loginwindow to work properly w/ FreeIPA accounts * Gets opendirectoryd ready for FreeIPA * Enrolls the host to FreeIPA thru multiple keytab manipulations * Gets around problems with anonymous binds in LDAP by using a "hidden" user for enrollments * Configures the SSH client for GSSAPI authentication * Creates host keys and adds them to FreeIPA * Deletes local user account and leaves home directory intact. This will allow the owner of the machine to log back in using his/her FreeIPA credentials w/out noticing any changes. Of course, for this to happen transparently the home directory has to be massaged. Please let me know if you'd like to know how we do this. I am omitting the details for now as this outside the scope, me thinks. The files inside the Payload folder are: The authorization and screensaver files are FreeIPA ready ones. The postflight script above puts them where they need to go (/private/etc/pam.d). The postflight will add a /private/etc/ipa folder to the enrollee. This folder must contain the following files: ca-crt, ca-crt-selfsigned, example.enroll.keytab. These will make more sense as you go thru the code. These are private, so I am not sharing them. The postflight script will also put FreeIPA ready versions of edu.mit.Kerberos and multiple LDAP config files where they need to go (follow the folder structure in the .zip file attached). These we are sharing; you will have to modify them to match your FreeIPA domain. And this is it. Apologies for the long read. We welcome your feedback; if you have any please send it my way :-) On Thu, Apr 17, 2014 at 4:29 PM, Chris Whittle wrote: > I was able to take that script and with some customizing get it to work > with Mavericks.... This should work, I tried to do a find and replace to > make it work like the github one. > > > On Wed, Apr 16, 2014 at 5:40 PM, Fredy Sanchez wrote: > >> Sure Rob, we'll put something together and send it to you for publishing. >> Give us a few days. We'll also sanitize our enrollment package and share it >> w/ you too. This is what we use to enroll our Macs, a one time install that >> does what ipa-client-install does for Linux, including these LDAP mappings. >> We love FreeIPA and will be really happy if this helps any other users with >> Mac fleets. >> >> >> On Wed, Apr 16, 2014 at 6:12 PM, Rob Crittenden wrote: >> >>> Fredy Sanchez wrote: >>> >>>> Hi Simo, >>>> >>>> Thanks for your reply. Good old Google pointed me to >>>> https://github.com/rtrouton/rtrouton_scripts/blob/master/ >>>> rtrouton_scripts/open-l >>>> dap_bind_script/Mac_OpenLDAP_bind_script.sh, which gave me the idea of >>>> updating the RealName mapping to displayName. This solved the problem, >>>> I'll have to recreate the permissions for every share, but the user >>>> names now show up, and stick. No more UIDs. >>>> >>> >>> Great. Any chance you can write something and post a howto on our wiki? >>> Or send the details to me and I'll write something up? >>> >>> thanks >>> >>> rob >>> >>> >>>> >>>> On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce >>> > wrote: >>>> >>>> On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: >>>> > Hi all, >>>> > >>>> > We asked this same question at discussions.apple.com >>>> , but figured we'd have >>>> >>>> > better luck here. I apologize in advance if this is the wrong >>>> forum. >>>> > >>>> > We are switching from Synology (DSM 5) to Mavericks server >>>> (v3.1.1. running >>>> > in Mavericks 10.9.2) for File Sharing. We use a FreeIPA >>>> (ipa-server.x86_64 >>>> > 3.0.0-37.el6) backend for SSO, and the Mac server seems >>>> correctly >>>> > bound to it. Unfortunately, although we can add usernames to the >>>> shares for >>>> > the initial config, the usernames transform to UIDs after (only >>>> for SSO >>>> > accounts; local accounts are not affected). That is, when we go >>>> to edit the >>>> > permissions for a share, all we see are UIDs. We can always >>>> figure out the >>>> > username from the UID, but this is an extra step we don't want to >>>> have. >>>> > We've tried reinstalling the Mac server app from scratch, >>>> re-binding to the >>>> > FreeIPA backend, changing mappings in Directory Utility (for >>>> example, >>>> > mapping GeneratedUID to uid, which is the username), recreating >>>> the shares >>>> > and permissions, etc. Here are more details about the binding: >>>> > >>>> > * The binding happens thru a custom package we created based >>>> primarily on >>>> > >>>> http://linsec.ca/Using_FreeIPA_for_User_ >>>> Authentication#Mac_OS_X_10.7.2F10.8 >>>> > * Sys Prefs, Users & Groups, Login Options show the server bound >>>> to the >>>> > FreeIPA backend with the green dot >>>> > * The following mappings are in place in Directory Utility, >>>> Services, >>>> > LDAPv3, FreeIPA backend >>>> > >>>> > Users: inetOrgPerson >>>> > AuthenticationAuthority: uid >>>> > GeneratedUID: random number in uppercase >>>> > HomeDirectory: #/Users/$uid$ >>>> > NFSHomeDirectory: #/Users/$uid$ >>>> > OriginalHomeDirectory: #/Users/$uid$ >>>> > PrimaryGroupID: gidNumber >>>> > RealName: cn >>>> > RecordName: uid >>>> > UniqueID: uidNumber >>>> > UserShell: loginShell >>>> > Groups: posixgroup >>>> > PrimaryGroupID: gidNumber >>>> > RecordName: cn >>>> > >>>> > The search bases are correct >>>> > >>>> > * Directory Utility, Directory Editor shows the right info for >>>> the users. >>>> > * $ id $USERNAME shows the right information for the user >>>> > >>>> > FreeIPA is working beautifully for our Mac / Linux environment. >>>> We provide >>>> > directory services to about 300 hosts, and 200 employees using >>>> it; and >>>> > haven't had any problems LDAP wise until now. So we think we are >>>> missing a >>>> > mapping here. Any ideas? >>>> >>>> Fredy, >>>> I quickly tried to check for some documentation on how to configure >>>> this >>>> stuff, but found only useless superficial guides on how to find the >>>> pointy/clicky buttons to push to enable the service. >>>> >>>> I am not a Mac expert by a long shot so I cannot help you much here. >>>> >>>> Is there any guide available on how to use this service with other >>>> LDAP >>>> servers, like openLDAP or Active Directory ? We can probably draw >>>> some >>>> conclusions from there. >>>> >>>> Simo. >>>> >>>> -- >>>> Simo Sorce * Red Hat, Inc * New York >>>> >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> >>>> Fredy Sanchez >>>> IT Manager @ Modernizing Medicine >>>> (561) 880-2998 x237 >>>> fredy.sanchez at modmed.com >>>> >>>> *Need IT support?* Visit https://mmit.zendesk.com >>>> >>>> >>>> * >>>> >>>> >>>> * * >>>> * >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> >>> >> >> >> -- >> Cheers, >> >> Fredy Sanchez >> IT Manager @ Modernizing Medicine >> (561) 880-2998 x237 >> fredy.sanchez at modmed.com >> >> *Need IT support?* Visit https://mmit.zendesk.com >> >> - >> >> >> - >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine (561) 880-2998 x237 fredy.sanchez at modmed.com *Need IT support?* Visit https://mmit.zendesk.com - - -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredy.sanchez at modmed.com Wed Apr 23 21:58:37 2014 From: fredy.sanchez at modmed.com (Fredy Sanchez) Date: Wed, 23 Apr 2014 17:58:37 -0400 Subject: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing. In-Reply-To: References: <1397568653.19767.289.camel@willson.li.ssimo.org> <534F0036.6070101@redhat.com> Message-ID: And here is the attachment. On Wed, Apr 23, 2014 at 5:57 PM, Fredy Sanchez wrote: > Hi all, > > Sorry for the delay. > > I am sharing with you a couple of scripts and files we use to enroll our > Macs (ML and Mavericks) into our FreeIPA domain. Using Luggage ( > https://github.com/unixorn/luggage), we package all of these into a one > click installer that can be deployed via ARD, Munki, etc. Now, our > environment has very specific requirements, so feel free to ask if there's > something you don't understand or that seems incomplete. > > These assume you already know what FreeIPA is, and have it up and running. > These also assume that all the server pre-staging (for example, that all > applicable DNS records are already created) for the "enrollee" is done. In > sum, these are ideal if all you are missing is to start enrolling Macs into > the FreeIPA domain. And you'll have to modify the files to match your > FreeIPA domain; we are using example.com for this. > > The preflight script (freeipa-client-preinstall.sh) will "clean" the > environment of the enrollee, and backup existing files that will be > modified during the enrollment process. It > * Sets the DNS search domain > * Adds a "local" search domain to the enrollee to speed up the login > process if no FreeIPA server is available during login > * Backs up edu.mit.Kerberos if it exists > * Backs up krb5.conf if it exists > * Backs up any existing LDAP info > * Backs up /Library/Preferences/com.apple.loginwindow.plist > > The postflight script (freeipa-client-postinstall.sh) performs the > enrollment. It > * Sets email notifications to know if the enrollment failed or succeeded. > These notifications will include the who and the why, and a hardware > profile from the enrollee that we find useful > * Sets and tests many variables needed for a successful enrollment like > NTP syncing, a valid hostname, and whether or not all applicable hosts > resolve thru your DNS servers > * Adjusts /Library/Preferences/com.apple.loginwindow to work properly w/ > FreeIPA accounts > * Gets opendirectoryd ready for FreeIPA > * Enrolls the host to FreeIPA thru multiple keytab manipulations > * Gets around problems with anonymous binds in LDAP by using a "hidden" > user for enrollments > * Configures the SSH client for GSSAPI authentication > * Creates host keys and adds them to FreeIPA > * Deletes local user account and leaves home directory intact. This will > allow the owner of the machine to log back in using his/her FreeIPA > credentials w/out noticing any changes. Of course, for this to happen > transparently the home directory has to be massaged. Please let me know if > you'd like to know how we do this. I am omitting the details for now as > this outside the scope, me thinks. > > The files inside the Payload folder are: > > The authorization and screensaver files are FreeIPA ready ones. The > postflight script above puts them where they need to go > (/private/etc/pam.d). > > The postflight will add a /private/etc/ipa folder to the enrollee. This > folder must contain the following files: ca-crt, ca-crt-selfsigned, > example.enroll.keytab. These will make more sense as you go thru the code. > These are private, so I am not sharing them. > > The postflight script will also put FreeIPA ready versions of > edu.mit.Kerberos and multiple LDAP config files where they need to go > (follow the folder structure in the .zip file attached). These we are > sharing; you will have to modify them to match your FreeIPA domain. > > And this is it. Apologies for the long read. We welcome your feedback; if > you have any please send it my way :-) > > > > On Thu, Apr 17, 2014 at 4:29 PM, Chris Whittle wrote: > >> I was able to take that script and with some customizing get it to work >> with Mavericks.... This should work, I tried to do a find and replace to >> make it work like the github one. >> >> >> On Wed, Apr 16, 2014 at 5:40 PM, Fredy Sanchez wrote: >> >>> Sure Rob, we'll put something together and send it to you for >>> publishing. Give us a few days. We'll also sanitize our enrollment package >>> and share it w/ you too. This is what we use to enroll our Macs, a one time >>> install that does what ipa-client-install does for Linux, including these >>> LDAP mappings. We love FreeIPA and will be really happy if this helps any >>> other users with Mac fleets. >>> >>> >>> On Wed, Apr 16, 2014 at 6:12 PM, Rob Crittenden wrote: >>> >>>> Fredy Sanchez wrote: >>>> >>>>> Hi Simo, >>>>> >>>>> Thanks for your reply. Good old Google pointed me to >>>>> https://github.com/rtrouton/rtrouton_scripts/blob/master/ >>>>> rtrouton_scripts/open-l >>>>> dap_bind_script/Mac_OpenLDAP_bind_script.sh, which gave me the idea of >>>>> updating the RealName mapping to displayName. This solved the problem, >>>>> I'll have to recreate the permissions for every share, but the user >>>>> names now show up, and stick. No more UIDs. >>>>> >>>> >>>> Great. Any chance you can write something and post a howto on our wiki? >>>> Or send the details to me and I'll write something up? >>>> >>>> thanks >>>> >>>> rob >>>> >>>> >>>>> >>>>> On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce >>>> > wrote: >>>>> >>>>> On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: >>>>> > Hi all, >>>>> > >>>>> > We asked this same question at discussions.apple.com >>>>> , but figured we'd have >>>>> >>>>> > better luck here. I apologize in advance if this is the wrong >>>>> forum. >>>>> > >>>>> > We are switching from Synology (DSM 5) to Mavericks server >>>>> (v3.1.1. running >>>>> > in Mavericks 10.9.2) for File Sharing. We use a FreeIPA >>>>> (ipa-server.x86_64 >>>>> > 3.0.0-37.el6) backend for SSO, and the Mac server seems >>>>> correctly >>>>> > bound to it. Unfortunately, although we can add usernames to the >>>>> shares for >>>>> > the initial config, the usernames transform to UIDs after (only >>>>> for SSO >>>>> > accounts; local accounts are not affected). That is, when we go >>>>> to edit the >>>>> > permissions for a share, all we see are UIDs. We can always >>>>> figure out the >>>>> > username from the UID, but this is an extra step we don't want >>>>> to >>>>> have. >>>>> > We've tried reinstalling the Mac server app from scratch, >>>>> re-binding to the >>>>> > FreeIPA backend, changing mappings in Directory Utility (for >>>>> example, >>>>> > mapping GeneratedUID to uid, which is the username), recreating >>>>> the shares >>>>> > and permissions, etc. Here are more details about the binding: >>>>> > >>>>> > * The binding happens thru a custom package we created based >>>>> primarily on >>>>> > >>>>> http://linsec.ca/Using_FreeIPA_for_User_ >>>>> Authentication#Mac_OS_X_10.7.2F10.8 >>>>> > * Sys Prefs, Users & Groups, Login Options show the server bound >>>>> to the >>>>> > FreeIPA backend with the green dot >>>>> > * The following mappings are in place in Directory Utility, >>>>> Services, >>>>> > LDAPv3, FreeIPA backend >>>>> > >>>>> > Users: inetOrgPerson >>>>> > AuthenticationAuthority: uid >>>>> > GeneratedUID: random number in uppercase >>>>> > HomeDirectory: #/Users/$uid$ >>>>> > NFSHomeDirectory: #/Users/$uid$ >>>>> > OriginalHomeDirectory: #/Users/$uid$ >>>>> > PrimaryGroupID: gidNumber >>>>> > RealName: cn >>>>> > RecordName: uid >>>>> > UniqueID: uidNumber >>>>> > UserShell: loginShell >>>>> > Groups: posixgroup >>>>> > PrimaryGroupID: gidNumber >>>>> > RecordName: cn >>>>> > >>>>> > The search bases are correct >>>>> > >>>>> > * Directory Utility, Directory Editor shows the right info for >>>>> the users. >>>>> > * $ id $USERNAME shows the right information for the user >>>>> > >>>>> > FreeIPA is working beautifully for our Mac / Linux environment. >>>>> We provide >>>>> > directory services to about 300 hosts, and 200 employees using >>>>> it; and >>>>> > haven't had any problems LDAP wise until now. So we think we are >>>>> missing a >>>>> > mapping here. Any ideas? >>>>> >>>>> Fredy, >>>>> I quickly tried to check for some documentation on how to >>>>> configure this >>>>> stuff, but found only useless superficial guides on how to find the >>>>> pointy/clicky buttons to push to enable the service. >>>>> >>>>> I am not a Mac expert by a long shot so I cannot help you much >>>>> here. >>>>> >>>>> Is there any guide available on how to use this service with other >>>>> LDAP >>>>> servers, like openLDAP or Active Directory ? We can probably draw >>>>> some >>>>> conclusions from there. >>>>> >>>>> Simo. >>>>> >>>>> -- >>>>> Simo Sorce * Red Hat, Inc * New York >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Cheers, >>>>> >>>>> Fredy Sanchez >>>>> IT Manager @ Modernizing Medicine >>>>> (561) 880-2998 x237 >>>>> fredy.sanchez at modmed.com >>>>> >>>>> *Need IT support?* Visit https://mmit.zendesk.com >>>>> >>>>> >>>>> * >>>>> >>>>> >>>>> * * >>>>> * >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> >>>>> >>>> >>> >>> >>> -- >>> Cheers, >>> >>> Fredy Sanchez >>> IT Manager @ Modernizing Medicine >>> (561) 880-2998 x237 >>> fredy.sanchez at modmed.com >>> >>> *Need IT support?* Visit https://mmit.zendesk.com >>> >>> - >>> >>> >>> - >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >> >> > > > -- > Cheers, > > Fredy Sanchez > IT Manager @ Modernizing Medicine > (561) 880-2998 x237 > fredy.sanchez at modmed.com > > *Need IT support?* Visit https://mmit.zendesk.com > > - > > > - > > -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine (561) 880-2998 x237 fredy.sanchez at modmed.com *Need IT support?* Visit https://mmit.zendesk.com - - -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FreeIPA-client.zip Type: application/zip Size: 24451 bytes Desc: not available URL: From andrew.holway at gmail.com Thu Apr 24 19:24:05 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 24 Apr 2014 20:24:05 +0100 Subject: [Freeipa-users] services and openSSL and stuff Message-ID: Hello, I would like to use freeipa CA to manage certs for our organisation. In testing this out I have created an SSL key with the following. openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key This CSR I pasted into the service certificate UI and have a tick next to "Valid Certificate Present" however I am a little unsure where to go from here. I assume I need to install a signed certificate with ipa-getcert request or so but, as my understanding of ssl is so terrible, I am unsure how to proceed. Please help! Ta Andrew From dpal at redhat.com Thu Apr 24 20:21:50 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 24 Apr 2014 16:21:50 -0400 Subject: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing. In-Reply-To: References: <1397568653.19767.289.camel@willson.li.ssimo.org> <534F0036.6070101@redhat.com> Message-ID: <5359725E.7020802@redhat.com> On 04/23/2014 05:58 PM, Fredy Sanchez wrote: > And here is the attachment. > Thank you for the contribution! We will review and ask questions if there are any. We also welcome any other comments and reviews before we publish it as a solution on the wiki. Thanks Dmitri > > On Wed, Apr 23, 2014 at 5:57 PM, Fredy Sanchez > > wrote: > > Hi all, > > Sorry for the delay. > > I am sharing with you a couple of scripts and files we use to > enroll our Macs (ML and Mavericks) into our FreeIPA domain. Using > Luggage (https://github.com/unixorn/luggage), we package all of > these into a one click installer that can be deployed via ARD, > Munki, etc. Now, our environment has very specific requirements, > so feel free to ask if there's something you don't understand or > that seems incomplete. > > These assume you already know what FreeIPA is, and have it up and > running. These also assume that all the server pre-staging (for > example, that all applicable DNS records are already created) for > the "enrollee" is done. In sum, these are ideal if all you are > missing is to start enrolling Macs into the FreeIPA domain. And > you'll have to modify the files to match your FreeIPA domain; we > are using example.com for this. > > The preflight script (freeipa-client-preinstall.sh) will "clean" > the environment of the enrollee, and backup existing files that > will be modified during the enrollment process. It > * Sets the DNS search domain > * Adds a "local" search domain to the enrollee to speed up the > login process if no FreeIPA server is available during login > * Backs up edu.mit.Kerberos if it exists > * Backs up krb5.conf if it exists > * Backs up any existing LDAP info > * Backs up /Library/Preferences/com.apple.loginwindow.plist > > The postflight script (freeipa-client-postinstall.sh) performs the > enrollment. It > * Sets email notifications to know if the enrollment failed or > succeeded. These notifications will include the who and the why, > and a hardware profile from the enrollee that we find useful > * Sets and tests many variables needed for a successful enrollment > like NTP syncing, a valid hostname, and whether or not all > applicable hosts resolve thru your DNS servers > * Adjusts /Library/Preferences/com.apple.loginwindow to work > properly w/ FreeIPA accounts > * Gets opendirectoryd ready for FreeIPA > * Enrolls the host to FreeIPA thru multiple keytab manipulations > * Gets around problems with anonymous binds in LDAP by using a > "hidden" user for enrollments > * Configures the SSH client for GSSAPI authentication > * Creates host keys and adds them to FreeIPA > * Deletes local user account and leaves home directory intact. > This will allow the owner of the machine to log back in using > his/her FreeIPA credentials w/out noticing any changes. Of course, > for this to happen transparently the home directory has to be > massaged. Please let me know if you'd like to know how we do this. > I am omitting the details for now as this outside the scope, me > thinks. > > The files inside the Payload folder are: > > The authorization and screensaver files are FreeIPA ready ones. > The postflight script above puts them where they need to go > (/private/etc/pam.d). > > The postflight will add a /private/etc/ipa folder to the enrollee. > This folder must contain the following files: ca-crt, > ca-crt-selfsigned, example.enroll.keytab. These will make more > sense as you go thru the code. These are private, so I am not > sharing them. > > The postflight script will also put FreeIPA ready versions of > edu.mit.Kerberos and multiple LDAP config files where they need to > go (follow the folder structure in the .zip file attached). These > we are sharing; you will have to modify them to match your FreeIPA > domain. > > And this is it. Apologies for the long read. We welcome your > feedback; if you have any please send it my way :-) > > > > On Thu, Apr 17, 2014 at 4:29 PM, Chris Whittle > wrote: > > I was able to take that script and with some customizing get > it to work with Mavericks.... This should work, I tried to do > a find and replace to make it work like the github one. > > > On Wed, Apr 16, 2014 at 5:40 PM, Fredy Sanchez > > > wrote: > > Sure Rob, we'll put something together and send it to you > for publishing. Give us a few days. We'll also sanitize > our enrollment package and share it w/ you too. This is > what we use to enroll our Macs, a one time install that > does what ipa-client-install does for Linux, including > these LDAP mappings. We love FreeIPA and will be really > happy if this helps any other users with Mac fleets. > > > On Wed, Apr 16, 2014 at 6:12 PM, Rob Crittenden > > wrote: > > Fredy Sanchez wrote: > > Hi Simo, > > Thanks for your reply. Good old Google pointed me to > https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/open-l > dap_bind_script/Mac_OpenLDAP_bind_script.sh, which > gave me the idea of > updating the RealName mapping to displayName. This > solved the problem, > I'll have to recreate the permissions for every > share, but the user > names now show up, and stick. No more UIDs. > > > Great. Any chance you can write something and post a > howto on our wiki? Or send the details to me and I'll > write something up? > > thanks > > rob > > > > On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce > > >> > wrote: > > On Fri, 2014-04-11 at 10:37 -0400, Fredy > Sanchez wrote: > > Hi all, > > > > We asked this same question at > discussions.apple.com > , but figured > we'd have > > > better luck here. I apologize in advance if > this is the wrong forum. > > > > We are switching from Synology (DSM 5) to > Mavericks server > (v3.1.1. running > > in Mavericks 10.9.2) for File Sharing. We > use a FreeIPA > (ipa-server.x86_64 > > 3.0.0-37.el6) backend for SSO, and the Mac > server seems > correctly > > bound to it. Unfortunately, although we can > add usernames to the > shares for > > the initial config, the usernames transform > to UIDs after (only > for SSO > > accounts; local accounts are not affected). > That is, when we go > to edit the > > permissions for a share, all we see are > UIDs. We can always > figure out the > > username from the UID, but this is an extra > step we don't want to > have. > > We've tried reinstalling the Mac server app > from scratch, > re-binding to the > > FreeIPA backend, changing mappings in > Directory Utility (for example, > > mapping GeneratedUID to uid, which is the > username), recreating > the shares > > and permissions, etc. Here are more details > about the binding: > > > > * The binding happens thru a custom package > we created based > primarily on > > > http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 > > * Sys Prefs, Users & Groups, Login Options > show the server bound > to the > > FreeIPA backend with the green dot > > * The following mappings are in place in > Directory Utility, Services, > > LDAPv3, FreeIPA backend > > > > Users: inetOrgPerson > > AuthenticationAuthority: uid > > GeneratedUID: random number in uppercase > > HomeDirectory: #/Users/$uid$ > > NFSHomeDirectory: #/Users/$uid$ > > OriginalHomeDirectory: #/Users/$uid$ > > PrimaryGroupID: gidNumber > > RealName: cn > > RecordName: uid > > UniqueID: uidNumber > > UserShell: loginShell > > Groups: posixgroup > > PrimaryGroupID: gidNumber > > RecordName: cn > > > > The search bases are correct > > > > * Directory Utility, Directory Editor shows > the right info for > the users. > > * $ id $USERNAME shows the right > information for the user > > > > FreeIPA is working beautifully for our Mac > / Linux environment. > We provide > > directory services to about 300 hosts, and > 200 employees using > it; and > > haven't had any problems LDAP wise until > now. So we think we are > missing a > > mapping here. Any ideas? > > Fredy, > I quickly tried to check for some > documentation on how to configure this > stuff, but found only useless superficial > guides on how to find the > pointy/clicky buttons to push to enable the > service. > > I am not a Mac expert by a long shot so I > cannot help you much here. > > Is there any guide available on how to use > this service with other LDAP > servers, like openLDAP or Active Directory ? > We can probably draw some > conclusions from there. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > > > > -- > Cheers, > > Fredy Sanchez > IT Manager @ Modernizing Medicine > (561) 880-2998 x237 > fredy.sanchez at modmed.com > > > > > *Need IT support?* Visit https://mmit.zendesk.com > > > * > > > * * > * > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > Cheers, > > Fredy Sanchez > IT Manager @ Modernizing Medicine > (561) 880-2998 x237 > fredy.sanchez at modmed.com > > *Need IT support?* Visit https://mmit.zendesk.com > > > * > > > * * > * > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > Cheers, > > Fredy Sanchez > IT Manager @ Modernizing Medicine > (561) 880-2998 x237 > fredy.sanchez at modmed.com > > *Need IT support?* Visit https://mmit.zendesk.com > > > * > > > * * > * > > > > > -- > Cheers, > > Fredy Sanchez > IT Manager @ Modernizing Medicine > (561) 880-2998 x237 > fredy.sanchez at modmed.com > > *Need IT support?* Visit https://mmit.zendesk.com > > > * > > > * * > * > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dave.Jones at spilgames.com Thu Apr 24 20:19:58 2014 From: Dave.Jones at spilgames.com (Dave Jones) Date: Thu, 24 Apr 2014 20:19:58 +0000 Subject: [Freeipa-users] Are replica gpg files reusable? Message-ID: <475B6252-F1E9-4EFF-9FF3-7AE1E1F6E164@spilgames.com> Hi, Should the replica gpg created by ipa-replica-prepare be re-created when there have been trivial changes such as adding/modifying a user/group/password on the IPA server? What change of condition(s) in the ?master? IPA host would prevent reuse of a previously prepared replica gpg file, or otherwise render it invalid? Cheers, Dave From dpal at redhat.com Thu Apr 24 20:46:47 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 24 Apr 2014 16:46:47 -0400 Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <713211054.4700804.1398295396344.JavaMail.zimbra@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <53581F90.3030802@redhat.com> <51109989.4612124.1398287278791.JavaMail.zimbra@redhat.com> <53583EA0.9040104@redhat.com> <713211054.4700804.1398295396344.JavaMail.zimbra@redhat.com> Message-ID: <53597837.1030400@redhat.com> On 04/23/2014 07:23 PM, Stephen Benjamin wrote: > ----- Original Message ----- >> From: "Dmitri Pal" >> To: "Stephen Benjamin" >> Cc: freeipa-users at redhat.com >> Sent: Thursday, April 24, 2014 12:28:48 AM >> Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 >> >>>> Several questions: >>>> - Is it using IPA smart proxy and if not when and how it will? We would >>>> probably need to add the instruction on how to set it up instead of the >>>> native one. I suspect there are some differences and the reason why one >>>> would be used over another. >>> It is using a provider built-in to the Foreman Smart Proxy. However, Rob >>> and I collaborated to ensure the APIs are compatible. You should be able >>> to swap out the Foreman proxy for the FreeIPA proxy when it's released. >> I know, I am sort of asking for documentation and comparison so that >> people would know which one we prefer them to use and why. > Ok, is there an idea of when the proxy will be released in FreeIPA? > 4.0? Or earlier? When it happens, I'll link to it in the Foreman > documentation. I hope it will be available quite soon. 4.0 time frame seems like reasonable time frame. > >>> Having the proxy in your repos, and very easily configured is >>> brilliant, it makes the user experience so much better. We do need to >>> make sure it gets SSL authentication enabled. But over time, I expect >>> Foreman's proxy to be deprecated and most people to use FreeIPA's, but >>> we do need ours for older versions. >> OK. >> >>>> - I think the setup script should probably be a part of IPA smart proxy >>>> project rather than a part of Foreman. IMO it is in the boat as mart >>>> proxy as it links IPA and Foreman together. What do you think? May be >>>> there should be spacial repo in IPA. As we move forward we would need to >>>> have more and more simple scripts to setup specific integration aspects >>>> with different projects. This is just the first one of them so we need >>>> to define what we want to do with the next one when it emerges. >>> The setup script in the video is just creating some permissions we >>> need, it's here: >>> >>> http://projects.theforeman.org/projects/foreman/wiki/IPASmartProxyUser >>> >>> I would kind of like to see this added to FreeIPA as a role, or somehow >>> distributed with the FreeIPA proxy package. >>> >>> I opened an issue about this a while back: >>> https://fedorahosted.org/freeipa/ticket/4252 >> Yes we have it in the right bucket so this is coming. >> >> The question is more about where it really belongs and in what shape of >> form. >> Should be an out of box setup so that once you install IPA it is already >> ready for Foreman integration? Should it be a script that is run on the >> server? Than can be something like: >> ipa-enable-integration >> command with arguments: >> --foreman - would load everything needed for foreman >> --OpenStack - would load everything needed for OpenStack >> --foo - will handle foo >> ... >> The alternative is to have a script with proxy in the proxy package. >> That would work too. >> I just do not knwo what approach is best thus asking the question. > Whatever fits with FreeIPA way of doing things...I think just the most > important thing is it's relatively easy to setup. I do not know. This is a question to the rest of the list. Input welcome! > >>>> - You have FreeIPA there as a realm type. Would it be possible to change >>>> this string because in RHEL it is called "Identity Management"? >>> "FreeIPA" is used pretty much everywhere, like config files. Just the UI >>> wouldn't be a big issue to alter, if you want to change it for Satellite. >> >> Yes that would be the case, I think. >> >>>> - Does this support a case when the machine needs to be re-provisioned? >>>> Does it do the right cleanup? >>> Yup, it disables the host if enrolled, and then requests a new OTP during >>> re-provision. >>> >>> If you update the host group in Foreman, we also send that as a userclass >>> attribute for use with automembership, although automembership currently >>> works on initial creation. >> Good >> >>>> - Moving forward it might make sense to be able to pass other parameters >>>> to the realm join to pass to ipa client install. I think we need to >>>> explore this more. For example do you want to configure SUDO or >>>> automaint integration on the provisioned host? Do you want to generate >>>> and upload host fingerprint, etc. Where is the right place to track this >>>> work? >>> The OTP is accessible to any provisioning template or snippet, so you >>> can do things however you want. >>> >>> We ship some provisioning templates distributed with Foreman, which >>> use either 1 or 2 ways: >>> >>> Fedora 20+ (and RHEL 7+): >>> - Built in Anaconda realm join, >>> https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration >> I do not see a reason for realmd to be used in this case. It does not >> add any value on top the ipa-client-install and actually limits the >> amount of the command arguments that can be passed to the client install >> script. There are two ways to overcome it: make realmd capable of >> passing arguments it does not know to ipa-client install (that would be >> a realmd rfe) or use ipa-client-install directly. I think direct use is >> OK here because one is using IPA smart proxy and expecting the systems >> to connect to IPA and not to AD. > Well, Foreman will support Active Directory via adcli, when I have > a chance to implement the smart proxy - hopefully for Foreman 1.6. Using > realmd makes it work regardless of the underlying realm type. But you already have special differentiation between IPA and AD in the way you pre-seed the server. I think that realmd is more valuable for the laptop use case when it is not know in advance which server one needs to enroll with. As you notice below the more we drill down into what else IPA can provide fro the system the bigger the difference would be between IPA and AD command(s) and thus realmd would be less and less attractive for IPA case. Using realmd for AD case is the right approch though to simplify the setup and let realmd do all the tricks for you. > > I have no horse in the race, but to me, realmd is there and it looks nice > to have it just work out of the box. It's one anaconda directive, versus > many lines of a an IPA-specific snippet. See above > > I would prefer that the work should be done to make realmd have sensible > defaults and take some extra options for the specific provider. That's > probably not possible immediately, so I'm open to the idea of not using > it for FreeIPA. The problem I see is that realmd most likely would not be able to keep up with IPA capabilities and in some cases you might want to run more then one command for IPA configuration. > > At the end of the day, Foreman delivers the OTP, and users are free to > customize things however they want. I see the templates as suggestions > with just some sane defaults. > > If the templates aren't sane, templates are pretty easy to contribute to: > https://github.com/theforeman/community-templates It is a good start and we should work on making it more advanced over time. > > And the more I think about it, maybe the freeipa snippet isn't > entirely sane and needs some extending (more about this below). > > >>> < Fedora 20, RHEL 6, etc: >>> - Kickstart snippet: >>> https://github.com/theforeman/community-templates/blob/master/snippets/freeipa_register.erb >>> >>> For Anaconda realm join, I don't see where you can pass additional options >>> to the installer. For the FreeIPA snippet, you can add a global >>> parameter to add arbitrary command line options to ipa-client-install. >> See above. I think we should just go and do a direct call to >> ipa-client-install >> >>> The snippet and provisioning can be customized however, and special >>> cases may want to make use of foreman_hooks: >>> >>> https://github.com/theforeman/foreman_hooks >> Yes but i do not see what else is needed yet. >> Potentially there we can start adding SRV records when the deployes >> system is know to run a particular server. >> >>> However, I specifically predicted the sudoers question, so I >>> have this blog post about it: >>> >>> https://bitbin.de/blog/2014/04/freeipa-sudoers-with-puppet-foreman/ >> I am not sure it is doing the right thing. In the blog you specify >> bindpw for SUDO, this means you are configuring SUDO without SSSD >> integration. If you use IPA it is a command switch on the >> ipa-client-install command to enable sudo, ssh or automount integration >> (at least in the latest versions of IPA). I think we should focus on that. > I'm very interested in this... > > I wrote the ipaclient module a year ago to suit a specific need for me. > I have some consulting customers who use it, but I haven't had much > feedback about it from anyone. Suggestions for changes to how I do > things would be much appreciated. > > The way ipaclient is doing things works on *everything*, from a 2-year > old release of RH IdM, to the 3.4 nightly I tested not too long ago. Right. So this is where instead of relying on the command switches it might make sense to run commands (if they are available). I do not recall what the commands and switches are. This is where I need help from Martin and Honza. I know there is ipa-client-automount but I do not remember the names of the similar commands for SSH, SUDO and SELinux integration. > > It's used in the wild, so I can't just break the compatability there -- but, > can I use SSSD setup even on the older versions of IPA? Do you have > some info about how to get that working? If so, I'll gladly go to > that. I need help here. Martin? > > >> https://fedorahosted.org/freeipa/ticket/3740 >> https://fedorahosted.org/freeipa/ticket/3358 <- but one can run command >> after install to enable integration with SUDO >> >> Honza, martin can you please add the details about SSH and SELinux >> integration >> >> >>> I haven't investigated automount, maybe it's something I can >>> consider adding to the ipaclient puppet module. >> I see it more as apart of the initial client setup and check boxes: do >> you want SUDO integration y/n; do you want automount y/n; do you want >> SELinux user mapping y/n; Do you want SSH integration y/n. Once you >> deploy you usually do not change these things because they are dictated >> by general policy rather than something that you turn on and off. > Right, for this we'd need to extend the freeipa_snippet, and > use Foreman parameters for these options. I think it's a great idea, > and something I'd gladly implement. For Foreman 1.5, we've really > fixed the templates now for the release, but this is something > that could probably go into 1.5.1 if the details are hammered out. Martin & Honza please suggest how this can be accomplished using our commands. I would assume we can assume we are dealing with 6.4 and later, right? > > I'd really appreciate an issue opened about this. Where? > > How do older versions of IPA respond to unknown options (say, if they don't > support sudoers)? I guess I need some kind of matrix of > what's supported for each version, so that I can do the appropriate > things. Yes we should pass right options to the right clients but may be we can do some kind of introspaction based on the package version. Something like: if ipa-client package version is greater than X: add options k, l, m otherwise log that options k, l, m are not supported on the version if ipa-client package version is greater than Y: add options n, o, q, p otherwise log that options n, o, q, p are not supported on the version That might be a script that is run on the system rather than a part of the template and it would check the package version available and use only applicable options. Again here I would like to hear the opinion of the list. > > >>> Thanks for the e-mail! I'm definitely interested in feedback. >>> Feature requests, PR's, etc are all welcome too :-) >> We will be putting some PR do not worry! >> Let us have a plan around open questions here and then I will start >> reaching out and sharing the news. > Yup, great feedback, thanks! > > >>> http://projects.theforeman.org/projects/foreman/issues/new >>> >>> >>> - Stephen >>> >>> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Apr 24 20:54:29 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 24 Apr 2014 16:54:29 -0400 Subject: [Freeipa-users] services and openSSL and stuff In-Reply-To: References: Message-ID: <53597A05.5000106@redhat.com> On 04/24/2014 03:24 PM, Andrew Holway wrote: > Hello, > > I would like to use freeipa CA to manage certs for our organisation. > In testing this out I have created an SSL key with the following. > > openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key > > This CSR I pasted into the service certificate UI and have a tick next > to "Valid Certificate Present" however I am a little unsure where to > go from here. > > I assume I need to install a signed certificate with ipa-getcert > request or so but, as my understanding of ssl is so terrible, I am > unsure how to proceed. > > Please help! > > Ta > > Andrew > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users What are the certs for? If they are for systems and services you might make you life simpler by using certmonger on the system where your service will be running. Assuming it is fedora, RHEL, CentOS and such (not sure about Debian and Ubuntu, they might have certmonger too) you install ipa-client and it will configure certmonger to use IPA. See certmonger man pages to get the certs for the services. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From rcritten at redhat.com Thu Apr 24 21:40:36 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Apr 2014 17:40:36 -0400 Subject: [Freeipa-users] Are replica gpg files reusable? In-Reply-To: <475B6252-F1E9-4EFF-9FF3-7AE1E1F6E164@spilgames.com> References: <475B6252-F1E9-4EFF-9FF3-7AE1E1F6E164@spilgames.com> Message-ID: <535984D4.9020201@redhat.com> Dave Jones wrote: > Hi, > > Should the replica gpg created by ipa-replica-prepare be re-created when there have been trivial changes such as adding/modifying a user/group/password on the IPA server? > > What change of condition(s) in the ?master? IPA host would prevent reuse of a previously prepared replica gpg file, or otherwise render it invalid? I'm assuming there is some specific scenario you have in mind. Typically a replica file is not needed after a master is installed. The only exception is if you install without a CA and then decide to use ipa-ca-install to add it later. We generally recommend that a replica be installed fairly soon after preparation of the file, days, not months, but even then it may still be viable. As for data modification (users, groups, etc) it should have no impact whatsoever. Once a replica is installed it is a full IPA master and the 389-ds replication protocol will keep it in sync. rob From Dave.Jones at spilgames.com Thu Apr 24 22:15:27 2014 From: Dave.Jones at spilgames.com (Dave Jones) Date: Thu, 24 Apr 2014 22:15:27 +0000 Subject: [Freeipa-users] Are replica gpg files reusable? In-Reply-To: <535984D4.9020201@redhat.com> References: <475B6252-F1E9-4EFF-9FF3-7AE1E1F6E164@spilgames.com> <535984D4.9020201@redhat.com> Message-ID: <173E13E2-22C7-4533-AB5F-2CC97DBD14B6@spilgames.com> Hi Rob, I was considering installing replicas using puppet. Having pre-prepared replica files available would be easier than having to run an ipa-replica-prepare and scp copy. I had guessed the ldap/kerberos replication would handle the user/password/DNS updates, and that changing CA certificates would be the most likely cause of gpg file invalidation. Again, thank you for speedy response and clarification! Cheers, Dave On 24 Apr 2014, at 23:40, Rob Crittenden wrote: > Dave Jones wrote: >> Hi, >> >> Should the replica gpg created by ipa-replica-prepare be re-created when there have been trivial changes such as adding/modifying a user/group/password on the IPA server? >> >> What change of condition(s) in the ?master? IPA host would prevent reuse of a previously prepared replica gpg file, or otherwise render it invalid? > > I'm assuming there is some specific scenario you have in mind. > > Typically a replica file is not needed after a master is installed. The only exception is if you install without a CA and then decide to use ipa-ca-install to add it later. > > We generally recommend that a replica be installed fairly soon after preparation of the file, days, not months, but even then it may still be viable. > > As for data modification (users, groups, etc) it should have no impact whatsoever. Once a replica is installed it is a full IPA master and the 389-ds replication protocol will keep it in sync. > > rob From cwhittl at gmail.com Thu Apr 24 23:59:32 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Thu, 24 Apr 2014 18:59:32 -0500 Subject: [Freeipa-users] Free IPA and Google Apps Message-ID: An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Apr 25 07:07:47 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Apr 2014 09:07:47 +0200 Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <53597837.1030400@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <53581F90.3030802@redhat.com> <51109989.4612124.1398287278791.JavaMail.zimbra@redhat.com> <53583EA0.9040104@redhat.com> <713211054.4700804.1398295396344.JavaMail.zimbra@redhat.com> <53597837.1030400@redhat.com> Message-ID: <535A09C3.9030308@redhat.com> On 04/24/2014 10:46 PM, Dmitri Pal wrote: > On 04/23/2014 07:23 PM, Stephen Benjamin wrote: ... >>> I am not sure it is doing the right thing. In the blog you specify >>> bindpw for SUDO, this means you are configuring SUDO without SSSD >>> integration. If you use IPA it is a command switch on the >>> ipa-client-install command to enable sudo, ssh or automount integration >>> (at least in the latest versions of IPA). I think we should focus on that. >> I'm very interested in this... >> >> I wrote the ipaclient module a year ago to suit a specific need for me. >> I have some consulting customers who use it, but I haven't had much >> feedback about it from anyone. Suggestions for changes to how I do >> things would be much appreciated. >> >> The way ipaclient is doing things works on *everything*, from a 2-year >> old release of RH IdM, to the 3.4 nightly I tested not too long ago. > > Right. So this is where instead of relying on the command switches it might > make sense to run commands (if they are available). > I do not recall what the commands and switches are. This is where I need help > from Martin and Honza. > I know there is ipa-client-automount but I do not remember the names of the > similar commands for SSH, SUDO and SELinux integration. I updated FreeIPA.org Client article to hold the integration information: http://www.freeipa.org/page/Client#Integration >> It's used in the wild, so I can't just break the compatability there -- but, >> can I use SSSD setup even on the older versions of IPA? Do you have >> some info about how to get that working? If so, I'll gladly go to >> that. > > I need help here. Martin? I am not sure I understand the question. FreeIPA client compatibility is described on the wiki: http://www.freeipa.org/page/Client#Compatibility Are we talking about ipa-client-install options compatibility, or sssd.conf compatibility or even FreeIPA API compatibility? >>> https://fedorahosted.org/freeipa/ticket/3740 This is just a convenient command to ipa-client-install. Separate ipa-client-automount is there since FreeIPA 3.0. >>> https://fedorahosted.org/freeipa/ticket/3358 <- but one can run command >>> after install to enable integration with SUDO >>> >>> Honza, martin can you please add the details about SSH and SELinux >>> integration Sorry I did not spot the question earlier, please see the referred article I just wrote. If there are question, ask. >>>> I haven't investigated automount, maybe it's something I can >>>> consider adding to the ipaclient puppet module. >>> I see it more as apart of the initial client setup and check boxes: do >>> you want SUDO integration y/n; do you want automount y/n; do you want >>> SELinux user mapping y/n; Do you want SSH integration y/n. Once you >>> deploy you usually do not change these things because they are dictated >>> by general policy rather than something that you turn on and off. >> Right, for this we'd need to extend the freeipa_snippet, and >> use Foreman parameters for these options. I think it's a great idea, >> and something I'd gladly implement. For Foreman 1.5, we've really >> fixed the templates now for the release, but this is something >> that could probably go into 1.5.1 if the details are hammered out. > > Martin & Honza please suggest how this can be accomplished using our commands. > I would assume we can assume we are dealing with 6.4 and later, right? If talking about IPA in 6.4 and older: automount - run ipa-client-automount after ipa-client-install SUDO - configure manually (details in https://fedorahosted.org/freeipa/ticket/3358). Though I am afraid that sssd in 6.4 does not have ipa sudo provider. SSH - ready after ipa-client-install SELinux - this comes with ipa-client-install automatically, though I think it was very limited before 6.5 (https://bugzilla.redhat.com/show_bug.cgi?id=914433) > >> >> I'd really appreciate an issue opened about this. > > Where? > >> >> How do older versions of IPA respond to unknown options (say, if they don't >> support sudoers)? I guess I need some kind of matrix of >> what's supported for each version, so that I can do the appropriate >> things. ipa-client-install will fail if unknown option is passed. # ipa-client-install --foo Usage: ipa-client-install [options] ipa-client-install: error: no such option: --foo > > Yes we should pass right options to the right clients but may be we can do some > kind of introspaction based on the package version. > Something like: > > if ipa-client package version is greater than X: > add options k, l, m > otherwise > log that options k, l, m are not supported on the version > > if ipa-client package version is greater than Y: > add options n, o, q, p > otherwise > log that options n, o, q, p are not supported on the version > > That might be a script that is run on the system rather than a part of the > template and it would check the package version available and use only > applicable options. Again here I would like to hear the opinion of the list. It seems to me that all integration options are available in 6.4 (see above). The only exception is SUDO which needs to be configured manuallyP: - /etc/nsswitch.conf - NIS domain name - /etc/sssd/sssd.conf - configuration is different based on SSSD version. In 6.4 and 6.4, you need to manually configure SSSD SUDO LDAP provider (slide 12 in http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf), in 6.6/7.0 you will be able to just add sudo service in SSSD and utilize SSSD SUDO IPA provider. With FreeIPA 4.0, you do not need to do anything, you have SUDO client configuration for free. HTH, Martin From jcholast at redhat.com Fri Apr 25 07:44:37 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 25 Apr 2014 09:44:37 +0200 Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <535A09C3.9030308@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <53581F90.3030802@redhat.com> <51109989.4612124.1398287278791.JavaMail.zimbra@redhat.com> <53583EA0.9040104@redhat.com> <713211054.4700804.1398295396344.JavaMail.zimbra@redhat.com> <53597837.1030400@redhat.com> <535A09C3.9030308@redhat.com> Message-ID: <535A1265.8090803@redhat.com> On 25.4.2014 09:07, Martin Kosek wrote: > On 04/24/2014 10:46 PM, Dmitri Pal wrote: >> On 04/23/2014 07:23 PM, Stephen Benjamin wrote: > ... >>>> I am not sure it is doing the right thing. In the blog you specify >>>> bindpw for SUDO, this means you are configuring SUDO without SSSD >>>> integration. If you use IPA it is a command switch on the >>>> ipa-client-install command to enable sudo, ssh or automount integration >>>> (at least in the latest versions of IPA). I think we should focus on that. >>> I'm very interested in this... >>> >>> I wrote the ipaclient module a year ago to suit a specific need for me. >>> I have some consulting customers who use it, but I haven't had much >>> feedback about it from anyone. Suggestions for changes to how I do >>> things would be much appreciated. >>> >>> The way ipaclient is doing things works on *everything*, from a 2-year >>> old release of RH IdM, to the 3.4 nightly I tested not too long ago. >> >> Right. So this is where instead of relying on the command switches it might >> make sense to run commands (if they are available). >> I do not recall what the commands and switches are. This is where I need help >> from Martin and Honza. >> I know there is ipa-client-automount but I do not remember the names of the >> similar commands for SSH, SUDO and SELinux integration. > > I updated FreeIPA.org Client article to hold the integration information: > > http://www.freeipa.org/page/Client#Integration Updated the bit about SSHFP and added markup to prevent line wrapping in the middle of command and option names. > >>> It's used in the wild, so I can't just break the compatability there -- but, >>> can I use SSSD setup even on the older versions of IPA? Do you have >>> some info about how to get that working? If so, I'll gladly go to >>> that. >> >> I need help here. Martin? > > I am not sure I understand the question. FreeIPA client compatibility is > described on the wiki: > > http://www.freeipa.org/page/Client#Compatibility > > Are we talking about ipa-client-install options compatibility, or sssd.conf > compatibility or even FreeIPA API compatibility? > >>>> https://fedorahosted.org/freeipa/ticket/3740 > > This is just a convenient command to ipa-client-install. Separate > ipa-client-automount is there since FreeIPA 3.0. > >>>> https://fedorahosted.org/freeipa/ticket/3358 <- but one can run command >>>> after install to enable integration with SUDO >>>> >>>> Honza, martin can you please add the details about SSH and SELinux >>>> integration > > Sorry I did not spot the question earlier, please see the referred article I > just wrote. If there are question, ask. What Martin said. > >>>>> I haven't investigated automount, maybe it's something I can >>>>> consider adding to the ipaclient puppet module. >>>> I see it more as apart of the initial client setup and check boxes: do >>>> you want SUDO integration y/n; do you want automount y/n; do you want >>>> SELinux user mapping y/n; Do you want SSH integration y/n. Once you >>>> deploy you usually do not change these things because they are dictated >>>> by general policy rather than something that you turn on and off. >>> Right, for this we'd need to extend the freeipa_snippet, and >>> use Foreman parameters for these options. I think it's a great idea, >>> and something I'd gladly implement. For Foreman 1.5, we've really >>> fixed the templates now for the release, but this is something >>> that could probably go into 1.5.1 if the details are hammered out. >> >> Martin & Honza please suggest how this can be accomplished using our commands. >> I would assume we can assume we are dealing with 6.4 and later, right? > > If talking about IPA in 6.4 and older: > > automount - run ipa-client-automount after ipa-client-install > SUDO - configure manually (details in > https://fedorahosted.org/freeipa/ticket/3358). Though I am afraid that sssd in > 6.4 does not have ipa sudo provider. AFAIK you can use ldap sudo provider with IPA, see e.g. > SSH - ready after ipa-client-install > SELinux - this comes with ipa-client-install automatically, though I think it > was very limited before 6.5 (https://bugzilla.redhat.com/show_bug.cgi?id=914433) > >> >>> >>> I'd really appreciate an issue opened about this. >> >> Where? >> >>> >>> How do older versions of IPA respond to unknown options (say, if they don't >>> support sudoers)? I guess I need some kind of matrix of >>> what's supported for each version, so that I can do the appropriate >>> things. > > ipa-client-install will fail if unknown option is passed. > > # ipa-client-install --foo > Usage: ipa-client-install [options] > > ipa-client-install: error: no such option: --foo > > >> >> Yes we should pass right options to the right clients but may be we can do some >> kind of introspaction based on the package version. >> Something like: >> >> if ipa-client package version is greater than X: >> add options k, l, m >> otherwise >> log that options k, l, m are not supported on the version >> >> if ipa-client package version is greater than Y: >> add options n, o, q, p >> otherwise >> log that options n, o, q, p are not supported on the version >> >> That might be a script that is run on the system rather than a part of the >> template and it would check the package version available and use only >> applicable options. Again here I would like to hear the opinion of the list. > > It seems to me that all integration options are available in 6.4 (see above). > The only exception is SUDO which needs to be configured manuallyP: > - /etc/nsswitch.conf > - NIS domain name > - /etc/sssd/sssd.conf - configuration is different based on SSSD version. In > 6.4 and 6.4, you need to manually configure SSSD SUDO LDAP provider (slide 12 > in http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf), in > 6.6/7.0 you will be able to just add sudo service in SSSD and utilize SSSD SUDO > IPA provider. With FreeIPA 4.0, you do not need to do anything, you have SUDO > client configuration for free. > > HTH, > Martin > -- Jan Cholasta From andrew.holway at gmail.com Fri Apr 25 07:50:41 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 25 Apr 2014 08:50:41 +0100 Subject: [Freeipa-users] Hardening freeipa on the internet Message-ID: Hello, I am having a think about running freeipa on the open seas for more distributed organisations and would like to understand where the weaknesses might be. I would almost certainly only make the ui unavailable however I am unsure about the other services. Would this be a workable? Thanks, Andrew From andrew.holway at gmail.com Fri Apr 25 07:57:41 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 25 Apr 2014 08:57:41 +0100 Subject: [Freeipa-users] services and openSSL and stuff In-Reply-To: <53597A05.5000106@redhat.com> References: <53597A05.5000106@redhat.com> Message-ID: > What are the certs for? At the moment for a third party application however we would like to issue our own certs for everything SSL such as LDAPs or OpenVPN. It is quite a powerful feature to be able to install an organisations root key on a clients machine and then be able to bosh out certs at will however I am still on an interesting journey understanding the specific implications of this for the various client, operating systems and browsers. Thanks for the "certmonger" keyword :) > If they are for systems and services you might make you life simpler by > using certmonger on the system where your service will be running. > Assuming it is fedora, RHEL, CentOS and such (not sure about Debian and > Ubuntu, they might have certmonger too) you install ipa-client and it will > configure certmonger to use IPA. See certmonger man pages to get the certs > for the services. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From mkosek at redhat.com Fri Apr 25 08:03:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Apr 2014 10:03:13 +0200 Subject: [Freeipa-users] Free IPA and Google Apps In-Reply-To: References: Message-ID: <535A16C1.6050808@redhat.com> On 04/25/2014 01:59 AM, Chris Whittle wrote: > I am wanting to use Free IPA as the authentication source for Google Apps. I > can't seem to find any documentation on how to accomplish this. Anyone have any > experience they would be willing to share? Or install is on CentOS 6.5 fyi. I did a brief googling and it seems to me that Google Apps should be capable of LDAP based auth/synchronization: http://www.google.com/support/enterprise/static/gapps/docs/admin/en/gads/admin/config_ldap_auth.html Even better solution would be probably to use SAML: https://developers.google.com/google-apps/sso/saml_reference_implementation by utilizing a project Ipsilon that Simo (CCed) is working on. Martin From mkosek at redhat.com Fri Apr 25 08:11:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Apr 2014 10:11:15 +0200 Subject: [Freeipa-users] Hardening freeipa on the internet In-Reply-To: References: Message-ID: <535A18A3.1060202@redhat.com> On 04/25/2014 09:50 AM, Andrew Holway wrote: > Hello, > > I am having a think about running freeipa on the open seas for more > distributed organisations and would like to understand where the > weaknesses might be. I would almost certainly only make the ui > unavailable however I am unsure about the other services. > > Would this be a workable? > > Thanks, > > Andrew That's actually a very good question. I am currently working on a public FreeIPA demo on Red Hat OpenStack platform which I will make available in upcoming weeks and have few pointers for you: 1) If you have DNS configured, make sure that your FreeIPA DNS does not pose as open DNS resolver to avoid DNS amplification attacks. Following extension to named.conf options should be a good start: allow-transfer {"none";}; allow-recursion {"none";}; recursion no; version "[Secured]"; rate-limit { responses-per-second 15; }; 2) Prevention for NTP amplification attack More info here: https://support.steadfast.net/Knowledgebase/Article/View/106/0/preventing-ntp-amplification-attacks Does anybody know about other precautions that should be made besides standard hardening (SELinux, firewall, log audits)? Thanks, Martin From stbenjam at redhat.com Fri Apr 25 08:16:11 2014 From: stbenjam at redhat.com (Stephen Benjamin) Date: Fri, 25 Apr 2014 04:16:11 -0400 (EDT) Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <535A1265.8090803@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <53581F90.3030802@redhat.com> <51109989.4612124.1398287278791.JavaMail.zimbra@redhat.com> <53583EA0.9040104@redhat.com> <713211054.4700804.1398295396344.JavaMail.zimbra@redhat.com> <53597837.1030400@redhat.com> <535A09C3.9030308@redhat.com> <535A1265.8090803@redhat.com> Message-ID: <927812530.6156856.1398413771558.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jan Cholasta" > To: "Martin Kosek" , dpal at redhat.com, "Stephen Benjamin" > Cc: freeipa-users at redhat.com > Sent: Friday, April 25, 2014 9:44:37 AM > Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 > AFAIK you can use ldap sudo provider with IPA, see e.g. > I got this working, and seems to work across recent Fedora releases too. This at least removes the requirement on using the old bind password method. Thanks! Is there a way for sssd to use _srv_ for the krb5_server line? Here's an updated Kickstart snippet: https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb If we know what the Syntax will be for sudo (or will it be default in 4.0?), then I can include the logic already not to do it manually. - Stephen From mkosek at redhat.com Fri Apr 25 08:54:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Apr 2014 10:54:13 +0200 Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <927812530.6156856.1398413771558.JavaMail.zimbra@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <53581F90.3030802@redhat.com> <51109989.4612124.1398287278791.JavaMail.zimbra@redhat.com> <53583EA0.9040104@redhat.com> <713211054.4700804.1398295396344.JavaMail.zimbra@redhat.com> <53597837.1030400@redhat.com> <535A09C3.9030308@redhat.com> <535A1265.8090803@redhat.com> <927812530.6156856.1398413771558.JavaMail.zimbra@redhat.com> Message-ID: <535A22B5.4000304@redhat.com> On 04/25/2014 10:16 AM, Stephen Benjamin wrote: > ----- Original Message ----- >> From: "Jan Cholasta" >> To: "Martin Kosek" , dpal at redhat.com, "Stephen Benjamin" >> Cc: freeipa-users at redhat.com >> Sent: Friday, April 25, 2014 9:44:37 AM >> Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 > >> AFAIK you can use ldap sudo provider with IPA, see e.g. >> > > I got this working, and seems to work across recent Fedora releases too. > This at least removes the requirement on using the old bind password > method. Thanks! > > Is there a way for sssd to use _srv_ for the krb5_server line? > > Here's an updated Kickstart snippet: > https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb > > If we know what the Syntax will be for sudo (or will it be default > in 4.0?), then I can include the logic already not to do it manually. > > > - Stephen > Good! Few comments I saw when reading the snippet: For automount, you also want to use --server option and --unattended option (your version would freeze): # ipa-client-automount --server vm-086.example.com --unattended IPA server: vm-086.example.com Location: default Configured /etc/nsswitch.conf Configured /etc/sysconfig/nfs Configured /etc/idmapd.conf Started rpcidmapd Started rpcgssd Restarting sssd, waiting for it to become available. Started autofs This is example from RHEL-6.5. As for SUDO, did you test the setup? It seems to me you missed adding sss source to "sudoers" database in nsswitch.conf. You would also need to set NIS domain name, otherwise SUDO will not correctly recognize SUDO rules targeted on host groups, instead of hosts: authconfig --nisdomain example.com --update nisdomainname example.com On Fedora or RHEL > 7.0, you would also need to enable systemd service to make the NIS domain name setup persistent: # service rhel-domainname.service start or # service fedora-domainname.service start and # service rhel-domainname.service enable or # service fedora-domainname.service enable All these sudo client changes will come from free with FreeIPA 4.0. Martin From pspacek at redhat.com Fri Apr 25 09:00:22 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 25 Apr 2014 11:00:22 +0200 Subject: [Freeipa-users] Hardening freeipa on the internet In-Reply-To: <535A18A3.1060202@redhat.com> References: <535A18A3.1060202@redhat.com> Message-ID: <535A2426.3000908@redhat.com> On 25.4.2014 10:11, Martin Kosek wrote: > On 04/25/2014 09:50 AM, Andrew Holway wrote: >> Hello, >> >> I am having a think about running freeipa on the open seas for more >> distributed organisations and would like to understand where the >> weaknesses might be. I would almost certainly only make the ui >> unavailable however I am unsure about the other services. >> >> Would this be a workable? >> >> Thanks, >> >> Andrew > > That's actually a very good question. I am currently working on a public > FreeIPA demo on Red Hat OpenStack platform which I will make available in > upcoming weeks and have few pointers for you: > > 1) If you have DNS configured, make sure that your FreeIPA DNS does not pose as > open DNS resolver to avoid DNS amplification attacks. > > Following extension to named.conf options should be a good start: > > allow-transfer {"none";}; This configuration applies only to zones defined in named.conf and not to FreeIPA zones defined in LDAP. Make sure that allow-transfer is configured for FreeIPA zones: $ ipa dnszone-mod --allow-transfer="none;" example. > allow-recursion {"none";}; > recursion no; > version "[Secured]"; > rate-limit { > responses-per-second 15; You may need to modify this value to fit your needs. Further reading about DNS amplification attacks: http://www.us-cert.gov/ncas/alerts/TA13-088A Further reading about Response Rate Limiting: http://bkraft.fr/blog/bind_RRL_feature/ https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response-Rate-Limiting.html https://kb.isc.org/article/AA-00994/0 > }; > > 2) Prevention for NTP amplification attack > > More info here: > https://support.steadfast.net/Knowledgebase/Article/View/106/0/preventing-ntp-amplification-attacks Further reading about NTP amplification attacks: http://www.us-cert.gov/ncas/alerts/TA14-013A > Does anybody know about other precautions that should be made besides standard > hardening (SELinux, firewall, log audits)? I wonder if Kerberos over UDP could have the same problem... Maybe only if you have some principals with disabled pre-authentication. I don't know. Kerberos is not listed on http://www.us-cert.gov/ncas/alerts/TA14-017A ... -- Petr^2 Spacek From pspacek at redhat.com Fri Apr 25 09:06:22 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 25 Apr 2014 11:06:22 +0200 Subject: [Freeipa-users] Are replica gpg files reusable? In-Reply-To: <173E13E2-22C7-4533-AB5F-2CC97DBD14B6@spilgames.com> References: <475B6252-F1E9-4EFF-9FF3-7AE1E1F6E164@spilgames.com> <535984D4.9020201@redhat.com> <173E13E2-22C7-4533-AB5F-2CC97DBD14B6@spilgames.com> Message-ID: <535A258E.4090600@redhat.com> On 25.4.2014 00:15, Dave Jones wrote: > Hi Rob, > > I was considering installing replicas using puppet. Having pre-prepared replica files available would be easier than having to run an ipa-replica-prepare and scp copy. > > I had guessed the ldap/kerberos replication would handle the user/password/DNS updates, and that changing CA certificates would be the most likely cause of gpg file invalidation. I'm working on DNSSEC support in FreeIPA right now. It is possible that replica-file validity will lowered by this work. (We will need to distribute one new key as part of the replica file so the replica file will become invalid if the key was changed in meantime. Maybe we will find some other solution for it, I don't know ...) Petr^2 Spacek > On 24 Apr 2014, at 23:40, Rob Crittenden wrote: > >> Dave Jones wrote: >>> Hi, >>> >>> Should the replica gpg created by ipa-replica-prepare be re-created when there have been trivial changes such as adding/modifying a user/group/password on the IPA server? >>> >>> What change of condition(s) in the ?master? IPA host would prevent reuse of a previously prepared replica gpg file, or otherwise render it invalid? >> >> I'm assuming there is some specific scenario you have in mind. >> >> Typically a replica file is not needed after a master is installed. The only exception is if you install without a CA and then decide to use ipa-ca-install to add it later. >> >> We generally recommend that a replica be installed fairly soon after preparation of the file, days, not months, but even then it may still be viable. >> >> As for data modification (users, groups, etc) it should have no impact whatsoever. Once a replica is installed it is a full IPA master and the 389-ds replication protocol will keep it in sync. >> >> rob From stbenjam at redhat.com Fri Apr 25 11:23:37 2014 From: stbenjam at redhat.com (Stephen Benjamin) Date: Fri, 25 Apr 2014 07:23:37 -0400 (EDT) Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <535A22B5.4000304@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <53583EA0.9040104@redhat.com> <713211054.4700804.1398295396344.JavaMail.zimbra@redhat.com> <53597837.1030400@redhat.com> <535A09C3.9030308@redhat.com> <535A1265.8090803@redhat.com> <927812530.6156856.1398413771558.JavaMail.zimbra@redhat.com> <535A22B5.4000304@redhat.com> Message-ID: <1141824711.6334160.1398425017212.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Martin Kosek" > To: "Stephen Benjamin" , "Jan Cholasta" > Cc: dpal at redhat.com, freeipa-users at redhat.com, "Tomas Babej" > Sent: Friday, April 25, 2014 10:54:13 AM > Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 > > On 04/25/2014 10:16 AM, Stephen Benjamin wrote: > > ----- Original Message ----- > >> From: "Jan Cholasta" > >> To: "Martin Kosek" , dpal at redhat.com, "Stephen > >> Benjamin" > >> Cc: freeipa-users at redhat.com > >> Sent: Friday, April 25, 2014 9:44:37 AM > >> Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 > > > >> AFAIK you can use ldap sudo provider with IPA, see e.g. > >> > > > > I got this working, and seems to work across recent Fedora releases too. > > This at least removes the requirement on using the old bind password > > method. Thanks! > > > > Is there a way for sssd to use _srv_ for the krb5_server line? > > > > Here's an updated Kickstart snippet: > > https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb > > > > If we know what the Syntax will be for sudo (or will it be default > > in 4.0?), then I can include the logic already not to do it manually. > > > > > > - Stephen > > > > Good! Few comments I saw when reading the snippet: > > For automount, you also want to use --server option and --unattended option > (your version would freeze): > > # ipa-client-automount --server vm-086.example.com --unattended > IPA server: vm-086.example.com > Location: default > Configured /etc/nsswitch.conf > Configured /etc/sysconfig/nfs > Configured /etc/idmapd.conf > Started rpcidmapd > Started rpcgssd > Restarting sssd, waiting for it to become available. > Started autofs > > This is example from RHEL-6.5. > > As for SUDO, did you test the setup? It seems to me you missed adding sss > source to "sudoers" database in nsswitch.conf. > > You would also need to set NIS domain name, otherwise SUDO will not correctly > recognize SUDO rules targeted on host groups, instead of hosts: Ah right, the system I tested was already registered. Good catch, thanks. > authconfig --nisdomain example.com --update > nisdomainname example.com > > On Fedora or RHEL > 7.0, you would also need to enable systemd service to > make > the NIS domain name setup persistent: > > # service rhel-domainname.service start > or > # service fedora-domainname.service start Wow. Why was it done that way? It makes it difficult to write cross-distro things... How will we call that on EL clones? > and > > # service rhel-domainname.service enable > or > # service fedora-domainname.service enable > > All these sudo client changes will come from free with FreeIPA 4.0. > > Martin > From mkosek at redhat.com Fri Apr 25 11:44:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Apr 2014 13:44:32 +0200 Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <1141824711.6334160.1398425017212.JavaMail.zimbra@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <53583EA0.9040104@redhat.com> <713211054.4700804.1398295396344.JavaMail.zimbra@redhat.com> <53597837.1030400@redhat.com> <535A09C3.9030308@redhat.com> <535A1265.8090803@redhat.com> <927812530.6156856.1398413771558.JavaMail.zimbra@redhat.com> <535A22B5.4000304@redhat.com> <1141824711.6334160.1398425017212.JavaMail.zimbra@redhat.com> Message-ID: <535A4AA0.5090502@redhat.com> On 04/25/2014 01:23 PM, Stephen Benjamin wrote: ... >> authconfig --nisdomain example.com --update >> nisdomainname example.com >> >> On Fedora or RHEL > 7.0, you would also need to enable systemd service to >> make >> the NIS domain name setup persistent: >> >> # service rhel-domainname.service start >> or >> # service fedora-domainname.service start > > Wow. > > Why was it done that way? It makes it difficult to write > cross-distro things... /me sighs. Well, I had exactly same question but I never hear an answer. > How will we call that on EL clones? Umh... Maybe: systemctl start `ls /usr/lib/systemd/system/*-domainname.service | rev | cut -d'/' -f 1 | rev` ? ;-) Martin From cwhittl at gmail.com Fri Apr 25 12:27:44 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Fri, 25 Apr 2014 07:27:44 -0500 Subject: [Freeipa-users] Free IPA and Google Apps In-Reply-To: <535A16C1.6050808@redhat.com> References: <535A16C1.6050808@redhat.com> Message-ID: Thanks Martin, I found a few notes on FreeIPA and GADS but most were people saying not to do it on principal but nothing saying if it's possible or not. I like the SAML option, including the mysterious ipsilon (Is there anything more than the git repo yet?), but wonder how much control it has. Does it just allow them to SSO using their LDAP credentials? If I disable a user in LDAP does it only recognize that only during login or is it smart enough to kill their Google Apps sessions and make them login again? On Fri, Apr 25, 2014 at 3:03 AM, Martin Kosek wrote: > On 04/25/2014 01:59 AM, Chris Whittle wrote: > > I am wanting to use Free IPA as the authentication source for Google > Apps. I > > can't seem to find any documentation on how to accomplish this. Anyone > have any > > experience they would be willing to share? Or install is on CentOS 6.5 > fyi. > > I did a brief googling and it seems to me that Google Apps should be > capable of > LDAP based auth/synchronization: > > http://www.google.com/support/enterprise/static/gapps/docs/admin/en/gads/admin/config_ldap_auth.html > > Even better solution would be probably to use SAML: > https://developers.google.com/google-apps/sso/saml_reference_implementation > by utilizing a project Ipsilon that Simo (CCed) is working on. > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Fri Apr 25 12:39:25 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 25 Apr 2014 08:39:25 -0400 Subject: [Freeipa-users] Free IPA and Google Apps In-Reply-To: References: <535A16C1.6050808@redhat.com> Message-ID: <1398429565.2628.469.camel@willson.li.ssimo.org> On Fri, 2014-04-25 at 07:27 -0500, Chris Whittle wrote: > Thanks Martin, I found a few notes on FreeIPA and GADS but most were people > saying not to do it on principal but nothing saying if it's possible or not. > > I like the SAML option, including the mysterious ipsilon (Is there anything > more than the git repo yet?), but wonder how much control it has. At the moment no control at all. > Does it just allow them to SSO using their LDAP credentials? Yes. > If I disable a user in LDAP does it only recognize that only during login > or is it smart enough to kill their Google Apps sessions and make them > login again? At the moment no, in future, perhaps we can develop a plugin that will call a SSO logout to the remote applications the user logged into, but this will require the server to be more stateful. This feature is not available in the current code. Simo. From cwhittl at gmail.com Fri Apr 25 12:41:18 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Fri, 25 Apr 2014 07:41:18 -0500 Subject: [Freeipa-users] Free IPA and Google Apps In-Reply-To: <1398429565.2628.469.camel@willson.li.ssimo.org> References: <535A16C1.6050808@redhat.com> <1398429565.2628.469.camel@willson.li.ssimo.org> Message-ID: Thank you Simo! Does anyone have any more info/experience on using GADS and FreeIPA that they would be willing to share? On Fri, Apr 25, 2014 at 7:39 AM, Simo Sorce wrote: > On Fri, 2014-04-25 at 07:27 -0500, Chris Whittle wrote: > > Thanks Martin, I found a few notes on FreeIPA and GADS but most were > people > > saying not to do it on principal but nothing saying if it's possible or > not. > > > > I like the SAML option, including the mysterious ipsilon (Is there > anything > > more than the git repo yet?), but wonder how much control it has. > > At the moment no control at all. > > > Does it just allow them to SSO using their LDAP credentials? > > Yes. > > > If I disable a user in LDAP does it only recognize that only during login > > or is it smart enough to kill their Google Apps sessions and make them > > login again? > > At the moment no, in future, perhaps we can develop a plugin that will > call a SSO logout to the remote applications the user logged into, but > this will require the server to be more stateful. This feature is not > available in the current code. > > Simo. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Apr 25 13:29:38 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 25 Apr 2014 09:29:38 -0400 Subject: [Freeipa-users] Free IPA and Google Apps In-Reply-To: <1398429565.2628.469.camel@willson.li.ssimo.org> References: <535A16C1.6050808@redhat.com> <1398429565.2628.469.camel@willson.li.ssimo.org> Message-ID: <535A6342.8070306@redhat.com> On 04/25/2014 08:39 AM, Simo Sorce wrote: > On Fri, 2014-04-25 at 07:27 -0500, Chris Whittle wrote: >> Thanks Martin, I found a few notes on FreeIPA and GADS but most were people >> saying not to do it on principal but nothing saying if it's possible or not. >> >> I like the SAML option, including the mysterious ipsilon (Is there anything >> more than the git repo yet?), but wonder how much control it has. > At the moment no control at all. > >> Does it just allow them to SSO using their LDAP credentials? > Yes. > >> If I disable a user in LDAP does it only recognize that only during login >> or is it smart enough to kill their Google Apps sessions and make them >> login again? > At the moment no, in future, perhaps we can develop a plugin that will > call a SSO logout to the remote applications the user logged into, but > this will require the server to be more stateful. This feature is not > available in the current code. > > Simo. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Simo, how much Ipsilon is ready for a POC like this? I understand it is probably somewhere between alpha and beta quality but it might be a good exercise to try to set it up for a real use case. What do you think? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Fri Apr 25 13:42:39 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 25 Apr 2014 09:42:39 -0400 Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <535A4AA0.5090502@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <53583EA0.9040104@redhat.com> <713211054.4700804.1398295396344.JavaMail.zimbra@redhat.com> <53597837.1030400@redhat.com> <535A09C3.9030308@redhat.com> <535A1265.8090803@redhat.com> <927812530.6156856.1398413771558.JavaMail.zimbra@redhat.com> <535A22B5.4000304@redhat.com> <1141824711.6334160.1398425017212.JavaMail.zimbra@redhat.com> <535A4AA0.5090502@redhat.com> Message-ID: <535A664F.7050006@redhat.com> On 04/25/2014 07:44 AM, Martin Kosek wrote: > On 04/25/2014 01:23 PM, Stephen Benjamin wrote: > ... >>> authconfig --nisdomain example.com --update >>> nisdomainname example.com >>> >>> On Fedora or RHEL > 7.0, you would also need to enable systemd service to >>> make >>> the NIS domain name setup persistent: >>> >>> # service rhel-domainname.service start >>> or >>> # service fedora-domainname.service start >> Wow. >> >> Why was it done that way? It makes it difficult to write >> cross-distro things... > /me sighs. Well, I had exactly same question but I never hear an answer. > >> How will we call that on EL clones? > Umh... Maybe: > > systemctl start `ls /usr/lib/systemd/system/*-domainname.service | rev | cut > -d'/' -f 1 | rev` > > ? ;-) > > Martin Are you planning to have a toggle for SSH integration? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Fri Apr 25 13:45:05 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 25 Apr 2014 09:45:05 -0400 Subject: [Freeipa-users] Are replica gpg files reusable? In-Reply-To: <535A258E.4090600@redhat.com> References: <475B6252-F1E9-4EFF-9FF3-7AE1E1F6E164@spilgames.com> <535984D4.9020201@redhat.com> <173E13E2-22C7-4533-AB5F-2CC97DBD14B6@spilgames.com> <535A258E.4090600@redhat.com> Message-ID: <535A66E1.6060302@redhat.com> On 04/25/2014 05:06 AM, Petr Spacek wrote: > On 25.4.2014 00:15, Dave Jones wrote: >> Hi Rob, >> >> I was considering installing replicas using puppet. Having >> pre-prepared replica files available would be easier than having to >> run an ipa-replica-prepare and scp copy. >> >> I had guessed the ldap/kerberos replication would handle the >> user/password/DNS updates, and that changing CA certificates would be >> the most likely cause of gpg file invalidation. > > I'm working on DNSSEC support in FreeIPA right now. It is possible > that replica-file validity will lowered by this work. (We will need to > distribute one new key as part of the replica file so the replica file > will become invalid if the key was changed in meantime. Maybe we will > find some other solution for it, I don't know ...) > May be the solution is to run a cron job on the server that would prepare a replica file and refresh it under source control every so often? > Petr^2 Spacek > >> On 24 Apr 2014, at 23:40, Rob Crittenden wrote: >> >>> Dave Jones wrote: >>>> Hi, >>>> >>>> Should the replica gpg created by ipa-replica-prepare be re-created >>>> when there have been trivial changes such as adding/modifying a >>>> user/group/password on the IPA server? >>>> >>>> What change of condition(s) in the ?master? IPA host would prevent >>>> reuse of a previously prepared replica gpg file, or otherwise >>>> render it invalid? >>> >>> I'm assuming there is some specific scenario you have in mind. >>> >>> Typically a replica file is not needed after a master is installed. >>> The only exception is if you install without a CA and then decide to >>> use ipa-ca-install to add it later. >>> >>> We generally recommend that a replica be installed fairly soon after >>> preparation of the file, days, not months, but even then it may >>> still be viable. >>> >>> As for data modification (users, groups, etc) it should have no >>> impact whatsoever. Once a replica is installed it is a full IPA >>> master and the 389-ds replication protocol will keep it in sync. >>> >>> rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Fri Apr 25 13:49:05 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 25 Apr 2014 09:49:05 -0400 Subject: [Freeipa-users] services and openSSL and stuff In-Reply-To: References: <53597A05.5000106@redhat.com> Message-ID: <535A67D1.5020005@redhat.com> On 04/25/2014 03:57 AM, Andrew Holway wrote: >> What are the certs for? > At the moment for a third party application however we would like to > issue our own certs for everything SSL such as LDAPs or OpenVPN. It is > quite a powerful feature to be able to install an organisations root > key on a clients machine and then be able to bosh out certs at will > however I am still on an interesting journey understanding the > specific implications of this for the various client, operating > systems and browsers. > > Thanks for the "certmonger" keyword :) There are also some good docs and examples in the certmonger git repo in docs folder and here. http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/certmongerX.html Keep in mind that there are some limitations with what you want to accomplish. We are aware of it and want to address it. We just did not have a chance to get our hands on it. http://www.freeipa.org/page/V3/IPA_as_external_Puppet_CA > >> If they are for systems and services you might make you life simpler by >> using certmonger on the system where your service will be running. >> Assuming it is fedora, RHEL, CentOS and such (not sure about Debian and >> Ubuntu, they might have certmonger too) you install ipa-client and it will >> configure certmonger to use IPA. See certmonger man pages to get the certs >> for the services. >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From simo at redhat.com Fri Apr 25 13:51:36 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 25 Apr 2014 09:51:36 -0400 Subject: [Freeipa-users] Free IPA and Google Apps In-Reply-To: <535A6342.8070306@redhat.com> References: <535A16C1.6050808@redhat.com> <1398429565.2628.469.camel@willson.li.ssimo.org> <535A6342.8070306@redhat.com> Message-ID: <1398433896.2628.486.camel@willson.li.ssimo.org> On Fri, 2014-04-25 at 09:29 -0400, Dmitri Pal wrote: > On 04/25/2014 08:39 AM, Simo Sorce wrote: > > On Fri, 2014-04-25 at 07:27 -0500, Chris Whittle wrote: > >> Thanks Martin, I found a few notes on FreeIPA and GADS but most were people > >> saying not to do it on principal but nothing saying if it's possible or not. > >> > >> I like the SAML option, including the mysterious ipsilon (Is there anything > >> more than the git repo yet?), but wonder how much control it has. > > At the moment no control at all. > > > >> Does it just allow them to SSO using their LDAP credentials? > > Yes. > > > >> If I disable a user in LDAP does it only recognize that only during login > >> or is it smart enough to kill their Google Apps sessions and make them > >> login again? > > At the moment no, in future, perhaps we can develop a plugin that will > > call a SSO logout to the remote applications the user logged into, but > > this will require the server to be more stateful. This feature is not > > available in the current code. > > > > Simo. > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > Simo, how much Ipsilon is ready for a POC like this? > I understand it is probably somewhere between alpha and beta quality but > it might be a good exercise to try to set it up for a real use case. > What do you think? It can be tried, but I need to write some documentation on how to set it up first :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From stbenjam at redhat.com Fri Apr 25 13:52:33 2014 From: stbenjam at redhat.com (Stephen Benjamin) Date: Fri, 25 Apr 2014 09:52:33 -0400 (EDT) Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <535A664F.7050006@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <535A09C3.9030308@redhat.com> <535A1265.8090803@redhat.com> <927812530.6156856.1398413771558.JavaMail.zimbra@redhat.com> <535A22B5.4000304@redhat.com> <1141824711.6334160.1398425017212.JavaMail.zimbra@redhat.com> <535A4AA0.5090502@redhat.com> <535A664F.7050006@redhat.com> Message-ID: <902622681.6553125.1398433953610.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Dmitri Pal" > To: "Martin Kosek" , "Stephen Benjamin" > Cc: "Jan Cholasta" , freeipa-users at redhat.com, "Tomas Babej" > Sent: Friday, April 25, 2014 3:42:39 PM > Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 > > > Are you planning to have a toggle for SSH integration? There's freeipa_opts to pass options directly to the installer, so a user can directly pass anything they want. I can add the SSH flag if it's needed and a relatively common one... Is there anything else that should be added? I still have to give the snippet a workout to ensure it works on everything, but seems OK so far, even if it's not going to win any beauty contests. https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb From dpal at redhat.com Fri Apr 25 13:59:31 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 25 Apr 2014 09:59:31 -0400 Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <902622681.6553125.1398433953610.JavaMail.zimbra@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <535A09C3.9030308@redhat.com> <535A1265.8090803@redhat.com> <927812530.6156856.1398413771558.JavaMail.zimbra@redhat.com> <535A22B5.4000304@redhat.com> <1141824711.6334160.1398425017212.JavaMail.zimbra@redhat.com> <535A4AA0.5090502@redhat.com> <535A664F.7050006@redhat.com> <902622681.6553125.1398433953610.JavaMail.zimbra@redhat.com> Message-ID: <535A6A43.5090207@redhat.com> On 04/25/2014 09:52 AM, Stephen Benjamin wrote: > > ----- Original Message ----- >> From: "Dmitri Pal" >> To: "Martin Kosek" , "Stephen Benjamin" >> Cc: "Jan Cholasta" , freeipa-users at redhat.com, "Tomas Babej" >> Sent: Friday, April 25, 2014 3:42:39 PM >> Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 >> >> Are you planning to have a toggle for SSH integration? > There's freeipa_opts to pass options directly to the installer, so a user can > directly pass anything they want. > > I can add the SSH flag if it's needed and a relatively common one... > > Is there anything else that should be added? > > I still have to give the snippet a workout to ensure it works on everything, > but seems OK so far, even if it's not going to win any beauty contests. > > https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb > > Yeah I was not thrilled by sed but if we can't do better for now so be it. Can Foreman have defaults? So that SSH & SUDO are turned on by default but automount is not. I am not sure there is anything else for now. We might start getting into more advanced features like provisioning certs for other software components deployed on the same machine later. That however rises a question: is there a way to record in Foreman that the client system has been IPA enrolled, because if it was the software deployed on top might be able to leverage this fact and the configuration of this software would be different if the system is enrolled or not. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Fri Apr 25 14:00:35 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 25 Apr 2014 10:00:35 -0400 Subject: [Freeipa-users] Free IPA and Google Apps In-Reply-To: <1398433896.2628.486.camel@willson.li.ssimo.org> References: <535A16C1.6050808@redhat.com> <1398429565.2628.469.camel@willson.li.ssimo.org> <535A6342.8070306@redhat.com> <1398433896.2628.486.camel@willson.li.ssimo.org> Message-ID: <535A6A83.2000306@redhat.com> On 04/25/2014 09:51 AM, Simo Sorce wrote: > On Fri, 2014-04-25 at 09:29 -0400, Dmitri Pal wrote: >> On 04/25/2014 08:39 AM, Simo Sorce wrote: >>> On Fri, 2014-04-25 at 07:27 -0500, Chris Whittle wrote: >>>> Thanks Martin, I found a few notes on FreeIPA and GADS but most were people >>>> saying not to do it on principal but nothing saying if it's possible or not. >>>> >>>> I like the SAML option, including the mysterious ipsilon (Is there anything >>>> more than the git repo yet?), but wonder how much control it has. >>> At the moment no control at all. >>> >>>> Does it just allow them to SSO using their LDAP credentials? >>> Yes. >>> >>>> If I disable a user in LDAP does it only recognize that only during login >>>> or is it smart enough to kill their Google Apps sessions and make them >>>> login again? >>> At the moment no, in future, perhaps we can develop a plugin that will >>> call a SSO logout to the remote applications the user logged into, but >>> this will require the server to be more stateful. This feature is not >>> available in the current code. >>> >>> Simo. >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> Simo, how much Ipsilon is ready for a POC like this? >> I understand it is probably somewhere between alpha and beta quality but >> it might be a good exercise to try to set it up for a real use case. >> What do you think? > It can be tried, but I need to write some documentation on how to set it > up first :-) > > Simo. > Hint-hint, nudge-nudge :-) -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From simo at redhat.com Fri Apr 25 14:18:19 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 25 Apr 2014 10:18:19 -0400 Subject: [Freeipa-users] Free IPA and Google Apps In-Reply-To: <535A6A83.2000306@redhat.com> References: <535A16C1.6050808@redhat.com> <1398429565.2628.469.camel@willson.li.ssimo.org> <535A6342.8070306@redhat.com> <1398433896.2628.486.camel@willson.li.ssimo.org> <535A6A83.2000306@redhat.com> Message-ID: <1398435500.2628.489.camel@willson.li.ssimo.org> On Fri, 2014-04-25 at 10:00 -0400, Dmitri Pal wrote: > On 04/25/2014 09:51 AM, Simo Sorce wrote: > > On Fri, 2014-04-25 at 09:29 -0400, Dmitri Pal wrote: > >> On 04/25/2014 08:39 AM, Simo Sorce wrote: > >>> On Fri, 2014-04-25 at 07:27 -0500, Chris Whittle wrote: > >>>> Thanks Martin, I found a few notes on FreeIPA and GADS but most were people > >>>> saying not to do it on principal but nothing saying if it's possible or not. > >>>> > >>>> I like the SAML option, including the mysterious ipsilon (Is there anything > >>>> more than the git repo yet?), but wonder how much control it has. > >>> At the moment no control at all. > >>> > >>>> Does it just allow them to SSO using their LDAP credentials? > >>> Yes. > >>> > >>>> If I disable a user in LDAP does it only recognize that only during login > >>>> or is it smart enough to kill their Google Apps sessions and make them > >>>> login again? > >>> At the moment no, in future, perhaps we can develop a plugin that will > >>> call a SSO logout to the remote applications the user logged into, but > >>> this will require the server to be more stateful. This feature is not > >>> available in the current code. > >>> > >>> Simo. > >>> > >>> > >>> _______________________________________________ > >>> Freeipa-users mailing list > >>> Freeipa-users at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-users > >> > >> Simo, how much Ipsilon is ready for a POC like this? > >> I understand it is probably somewhere between alpha and beta quality but > >> it might be a good exercise to try to set it up for a real use case. > >> What do you think? > > It can be tried, but I need to write some documentation on how to set it > > up first :-) > > > > Simo. > > > Hint-hint, nudge-nudge :-) I know, I know. I got done with lasso and mod_auth_mellon patches, now I can go back to Ipsilon. If Jan gives me the go, I will cut a first release and start writing instruction, file for Fedora packages and all that Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Apr 25 14:18:22 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Apr 2014 10:18:22 -0400 Subject: [Freeipa-users] Are replica gpg files reusable? In-Reply-To: <535A66E1.6060302@redhat.com> References: <475B6252-F1E9-4EFF-9FF3-7AE1E1F6E164@spilgames.com> <535984D4.9020201@redhat.com> <173E13E2-22C7-4533-AB5F-2CC97DBD14B6@spilgames.com> <535A258E.4090600@redhat.com> <535A66E1.6060302@redhat.com> Message-ID: <535A6EAE.3010504@redhat.com> Dmitri Pal wrote: > On 04/25/2014 05:06 AM, Petr Spacek wrote: >> On 25.4.2014 00:15, Dave Jones wrote: >>> Hi Rob, >>> >>> I was considering installing replicas using puppet. Having >>> pre-prepared replica files available would be easier than having to >>> run an ipa-replica-prepare and scp copy. >>> >>> I had guessed the ldap/kerberos replication would handle the >>> user/password/DNS updates, and that changing CA certificates would be >>> the most likely cause of gpg file invalidation. >> >> I'm working on DNSSEC support in FreeIPA right now. It is possible >> that replica-file validity will lowered by this work. (We will need to >> distribute one new key as part of the replica file so the replica file >> will become invalid if the key was changed in meantime. Maybe we will >> find some other solution for it, I don't know ...) >> > > > May be the solution is to run a cron job on the server that would > prepare a replica file and refresh it under source control every so often? The downside is you could end up issuing a whole ton of certificates for the same service, the majority of which aren't being used, and are unrevoked. rob From stbenjam at redhat.com Fri Apr 25 14:29:25 2014 From: stbenjam at redhat.com (Stephen Benjamin) Date: Fri, 25 Apr 2014 10:29:25 -0400 (EDT) Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <535A6A43.5090207@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <927812530.6156856.1398413771558.JavaMail.zimbra@redhat.com> <535A22B5.4000304@redhat.com> <1141824711.6334160.1398425017212.JavaMail.zimbra@redhat.com> <535A4AA0.5090502@redhat.com> <535A664F.7050006@redhat.com> <902622681.6553125.1398433953610.JavaMail.zimbra@redhat.com> <535A6A43.5090207@redhat.com> Message-ID: <1256781215.6615977.1398436165506.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Dmitri Pal" > To: "Stephen Benjamin" > Cc: "Martin Kosek" , "Jan Cholasta" , freeipa-users at redhat.com, "Tomas Babej" > > Sent: Friday, April 25, 2014 3:59:31 PM > Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 > > On 04/25/2014 09:52 AM, Stephen Benjamin wrote: > > > > ----- Original Message ----- > >> From: "Dmitri Pal" > >> To: "Martin Kosek" , "Stephen Benjamin" > >> > >> Cc: "Jan Cholasta" , freeipa-users at redhat.com, "Tomas > >> Babej" > >> Sent: Friday, April 25, 2014 3:42:39 PM > >> Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 > >> > >> Are you planning to have a toggle for SSH integration? > > There's freeipa_opts to pass options directly to the installer, so a user > > can > > directly pass anything they want. > > > > I can add the SSH flag if it's needed and a relatively common one... > > > > Is there anything else that should be added? > > > > I still have to give the snippet a workout to ensure it works on > > everything, > > but seems OK so far, even if it's not going to win any beauty contests. > > > > https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb > > > > > Yeah I was not thrilled by sed but if we can't do better for now so be it. > > Can Foreman have defaults? > So that SSH & SUDO are turned on by default but automount is not. > I am not sure there is anything else for now. Yup, defaults are as you described. SSH integration can't currently be turned off but I'll add the flag. > We might start getting into more advanced features like provisioning > certs for other software components deployed on the same machine later. > That however rises a question: is there a way to record in Foreman that > the client system has been IPA enrolled, because if it was the software > deployed on top might be able to leverage this fact and the > configuration of this software would be different if the system is > enrolled or not. Foreman keeps track of which hosts are registered, so this information is available for use. Certificates could even be managed in Foreman via a puppet module (there's one out there for Certmonger, IIRC). > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > From dpal at redhat.com Fri Apr 25 16:21:21 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 25 Apr 2014 12:21:21 -0400 Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <1256781215.6615977.1398436165506.JavaMail.zimbra@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <927812530.6156856.1398413771558.JavaMail.zimbra@redhat.com> <535A22B5.4000304@redhat.com> <1141824711.6334160.1398425017212.JavaMail.zimbra@redhat.com> <535A4AA0.5090502@redhat.com> <535A664F.7050006@redhat.com> <902622681.6553125.1398433953610.JavaMail.zimbra@redhat.com> <535A6A43.5090207@redhat.com> <1256781215.6615977.1398436165506.JavaMail.zimbra@redhat.com> Message-ID: <535A8B81.5040900@redhat.com> On 04/25/2014 10:29 AM, Stephen Benjamin wrote: > ----- Original Message ----- >> From: "Dmitri Pal" >> To: "Stephen Benjamin" >> Cc: "Martin Kosek" , "Jan Cholasta" , freeipa-users at redhat.com, "Tomas Babej" >> >> Sent: Friday, April 25, 2014 3:59:31 PM >> Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 >> >> On 04/25/2014 09:52 AM, Stephen Benjamin wrote: >>> ----- Original Message ----- >>>> From: "Dmitri Pal" >>>> To: "Martin Kosek" , "Stephen Benjamin" >>>> >>>> Cc: "Jan Cholasta" , freeipa-users at redhat.com, "Tomas >>>> Babej" >>>> Sent: Friday, April 25, 2014 3:42:39 PM >>>> Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 >>>> >>>> Are you planning to have a toggle for SSH integration? >>> There's freeipa_opts to pass options directly to the installer, so a user >>> can >>> directly pass anything they want. >>> >>> I can add the SSH flag if it's needed and a relatively common one... >>> >>> Is there anything else that should be added? >>> >>> I still have to give the snippet a workout to ensure it works on >>> everything, >>> but seems OK so far, even if it's not going to win any beauty contests. >>> >>> https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb >>> >>> >> Yeah I was not thrilled by sed but if we can't do better for now so be it. >> >> Can Foreman have defaults? >> So that SSH & SUDO are turned on by default but automount is not. >> I am not sure there is anything else for now. > Yup, defaults are as you described. > > SSH integration can't currently be turned off but I'll add the flag. > > >> We might start getting into more advanced features like provisioning >> certs for other software components deployed on the same machine later. >> That however rises a question: is there a way to record in Foreman that >> the client system has been IPA enrolled, because if it was the software >> deployed on top might be able to leverage this fact and the >> configuration of this software would be different if the system is >> enrolled or not. > Foreman keeps track of which hosts are registered, so this information is > available for use. Certificates could even be managed in Foreman > via a puppet module (there's one out there for Certmonger, IIRC). Yes. This is the direction of the further expansion. Let us get back to it in couple months. > > >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From justin.brown at fandingo.org Fri Apr 25 16:48:53 2014 From: justin.brown at fandingo.org (Justin Brown) Date: Fri, 25 Apr 2014 11:48:53 -0500 Subject: [Freeipa-users] Are replica gpg files reusable? In-Reply-To: <535A6EAE.3010504@redhat.com> References: <475B6252-F1E9-4EFF-9FF3-7AE1E1F6E164@spilgames.com> <535984D4.9020201@redhat.com> <173E13E2-22C7-4533-AB5F-2CC97DBD14B6@spilgames.com> <535A258E.4090600@redhat.com> <535A66E1.6060302@redhat.com> <535A6EAE.3010504@redhat.com> Message-ID: This type of behavior is generally beyond what Puppet should do because it involves two systems retrieving information directly from one another and the puppet master can't reasonably serve as the repository of that information. Using a separate tool will likely work better. There's at least two ways that you could go with this. 1) Script and SSH The IPA master has a simple script that will just invoke ipa-replica-setup with the proper options and passwords. The new replica will get a Puppet exec resource that will SSH into the master, run the script, scp the resulting replica file, and invoke the replica install with that info. The problem with this solution is that credentials are sprinkled all over the place, and security is not good. Your Puppet manifest will need SSH credentials/keys, the master script needs IPA credentials, and the Puppet logs for the exec resource may contain passwords depending on how you implement it. 2) MCollective You'll need to write a MCollective agent that resides on the replica and master. The new replica will get a Puppet exec resource that will run the MCollective agent. The agent will connect to the master and invoke its half of the agent, which will create the replica file and read it back to the replica. Then, there's a second Puppet exec resource that will run ipa-replica-install. Security is better for a couple of reasons. First, ACLs can be used with MCollective to limit who can run this agent. Second, there's no SSH keys/passwords to exchange. Third, we can store the IPA DM and admin passwords in puppet facts (this works for the previous solution, too.). Both solutions are pretty simple and will get the job done, but I think the second one is better but does require MCollective installed and Ruby knowledge. On Fri, Apr 25, 2014 at 9:18 AM, Rob Crittenden wrote: > Dmitri Pal wrote: >> >> On 04/25/2014 05:06 AM, Petr Spacek wrote: >>> >>> On 25.4.2014 00:15, Dave Jones wrote: >>>> >>>> Hi Rob, >>>> >>>> I was considering installing replicas using puppet. Having >>>> pre-prepared replica files available would be easier than having to >>>> run an ipa-replica-prepare and scp copy. >>>> >>>> I had guessed the ldap/kerberos replication would handle the >>>> user/password/DNS updates, and that changing CA certificates would be >>>> the most likely cause of gpg file invalidation. >>> >>> >>> I'm working on DNSSEC support in FreeIPA right now. It is possible >>> that replica-file validity will lowered by this work. (We will need to >>> distribute one new key as part of the replica file so the replica file >>> will become invalid if the key was changed in meantime. Maybe we will >>> find some other solution for it, I don't know ...) >>> >> >> >> May be the solution is to run a cron job on the server that would >> prepare a replica file and refresh it under source control every so often? > > > The downside is you could end up issuing a whole ton of certificates for the > same service, the majority of which aren't being used, and are unrevoked. > > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Fri Apr 25 17:24:31 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 25 Apr 2014 13:24:31 -0400 Subject: [Freeipa-users] Are replica gpg files reusable? In-Reply-To: References: <475B6252-F1E9-4EFF-9FF3-7AE1E1F6E164@spilgames.com> <535984D4.9020201@redhat.com> <173E13E2-22C7-4533-AB5F-2CC97DBD14B6@spilgames.com> <535A258E.4090600@redhat.com> <535A66E1.6060302@redhat.com> <535A6EAE.3010504@redhat.com> Message-ID: <535A9A4F.5030002@redhat.com> On 04/25/2014 12:48 PM, Justin Brown wrote: > This type of behavior is generally beyond what Puppet should do > because it involves two systems retrieving information directly from > one another and the puppet master can't reasonably serve as the > repository of that information. Using a separate tool will likely work > better. There's at least two ways that you could go with this. > > 1) Script and SSH > > The IPA master has a simple script that will just invoke > ipa-replica-setup with the proper options and passwords. The new > replica will get a Puppet exec resource that will SSH into the master, > run the script, scp the resulting replica file, and invoke the replica > install with that info. > > The problem with this solution is that credentials are sprinkled all > over the place, and security is not good. Your Puppet manifest will > need SSH credentials/keys, the master script needs IPA credentials, > and the Puppet logs for the exec resource may contain passwords > depending on how you implement it. > > 2) MCollective > > You'll need to write a MCollective agent that resides on the replica > and master. The new replica will get a Puppet exec resource that will > run the MCollective agent. The agent will connect to the master and > invoke its half of the agent, which will create the replica file and > read it back to the replica. Then, there's a second Puppet exec > resource that will run ipa-replica-install. > > Security is better for a couple of reasons. First, ACLs can be used > with MCollective to limit who can run this agent. Second, there's no > SSH keys/passwords to exchange. Third, we can store the IPA DM and > admin passwords in puppet facts (this works for the previous solution, > too.). > > Both solutions are pretty simple and will get the job done, but I > think the second one is better but does require MCollective installed > and Ruby knowledge. Or we use Cockpit for that matter: http://sgallagh.wordpress.com/2013/12/09/proposal-freeipa-role-for-fedora-servers/ > > On Fri, Apr 25, 2014 at 9:18 AM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 04/25/2014 05:06 AM, Petr Spacek wrote: >>>> On 25.4.2014 00:15, Dave Jones wrote: >>>>> Hi Rob, >>>>> >>>>> I was considering installing replicas using puppet. Having >>>>> pre-prepared replica files available would be easier than having to >>>>> run an ipa-replica-prepare and scp copy. >>>>> >>>>> I had guessed the ldap/kerberos replication would handle the >>>>> user/password/DNS updates, and that changing CA certificates would be >>>>> the most likely cause of gpg file invalidation. >>>> >>>> I'm working on DNSSEC support in FreeIPA right now. It is possible >>>> that replica-file validity will lowered by this work. (We will need to >>>> distribute one new key as part of the replica file so the replica file >>>> will become invalid if the key was changed in meantime. Maybe we will >>>> find some other solution for it, I don't know ...) >>>> >>> >>> May be the solution is to run a cron job on the server that would >>> prepare a replica file and refresh it under source control every so often? >> >> The downside is you could end up issuing a whole ton of certificates for the >> same service, the majority of which aren't being used, and are unrevoked. >> >> >> rob >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From rcritten at redhat.com Fri Apr 25 18:05:53 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Apr 2014 14:05:53 -0400 Subject: [Freeipa-users] Are replica gpg files reusable? In-Reply-To: References: <475B6252-F1E9-4EFF-9FF3-7AE1E1F6E164@spilgames.com> <535984D4.9020201@redhat.com> <173E13E2-22C7-4533-AB5F-2CC97DBD14B6@spilgames.com> <535A258E.4090600@redhat.com> <535A66E1.6060302@redhat.com> <535A6EAE.3010504@redhat.com> Message-ID: <535AA401.2010004@redhat.com> Justin Brown wrote: > This type of behavior is generally beyond what Puppet should do > because it involves two systems retrieving information directly from > one another and the puppet master can't reasonably serve as the > repository of that information. Using a separate tool will likely work > better. There's at least two ways that you could go with this. > > 1) Script and SSH > > The IPA master has a simple script that will just invoke > ipa-replica-setup with the proper options and passwords. The new > replica will get a Puppet exec resource that will SSH into the master, > run the script, scp the resulting replica file, and invoke the replica > install with that info. > > The problem with this solution is that credentials are sprinkled all > over the place, and security is not good. Your Puppet manifest will > need SSH credentials/keys, the master script needs IPA credentials, > and the Puppet logs for the exec resource may contain passwords > depending on how you implement it. > > 2) MCollective > > You'll need to write a MCollective agent that resides on the replica > and master. The new replica will get a Puppet exec resource that will > run the MCollective agent. The agent will connect to the master and > invoke its half of the agent, which will create the replica file and > read it back to the replica. Then, there's a second Puppet exec > resource that will run ipa-replica-install. > > Security is better for a couple of reasons. First, ACLs can be used > with MCollective to limit who can run this agent. Second, there's no > SSH keys/passwords to exchange. Third, we can store the IPA DM and > admin passwords in puppet facts (this works for the previous solution, > too.). > > Both solutions are pretty simple and will get the job done, but I > think the second one is better but does require MCollective installed > and Ruby knowledge. Would that mean that anyone with shell access to the box could run facter and get the passwords? I guess one would need a well-defined HBAC rule to limit access. rob From andrew.holway at gmail.com Sat Apr 26 08:02:04 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Sat, 26 Apr 2014 09:02:04 +0100 Subject: [Freeipa-users] services and openSSL and stuff In-Reply-To: <535A67D1.5020005@redhat.com> References: <53597A05.5000106@redhat.com> <535A67D1.5020005@redhat.com> Message-ID: > There are also some good docs and examples in the certmonger git repo in > docs folder and here. > http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/certmongerX.html Hi, The docs seem to explain quite well how to request a certificate but not how to actually issue a certificate. I'm looking at guides like this - http://wiki.centos.org/HowTos/Https - and wondering how I fill in the bits that are missing. I guess the real issue that I am facing here is that I want to get an openssl certificate signed by freeipa which is nss. I am guessing that you cant do this with certmonger? Sorry if I am being somewhat confusing. Im struggling to get my head around all this. From andrew.holway at gmail.com Sat Apr 26 12:29:20 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Sat, 26 Apr 2014 13:29:20 +0100 Subject: [Freeipa-users] services and openSSL and stuff In-Reply-To: References: <53597A05.5000106@redhat.com> <535A67D1.5020005@redhat.com> Message-ID: I might as well write this down here :) I have found this mechanism works: On the service machine: - openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key # a common name must be entered here which is the hostname In the IPA interface: - Services - Add - HTTP/service.domain.com at DOMAIN.COM - New Certificate - Paste the output of the 'openssl' command - Get - Copy contents On the service machine: - Paste contents -> /etc/pki/tls/certs/ca.crt - Move private key -> /etc/pki/tls/certs/ca.key - adjust "SSLCertificateFile" in apache - adjust "SSLCertificateKeyFile" in apache However running: ipa-getcert request -f /etc/pki/tls/certs/ca.crt -k /etc/pki/tls/certs/ca.key -r replaces all of the above. It will return something like: "New signing request "20140426115309" added." If you want to replace the certificate run this first. ipa-getcert stop-tracking -i 20140426115309 Else you will see this message: Certificate at same location is already used by request with nickname "20140426115309". And here is some official docs I just found: http://www.freeipa.org/page/Certmonger#OpenSSL On 26 April 2014 09:02, Andrew Holway wrote: >> There are also some good docs and examples in the certmonger git repo in >> docs folder and here. >> http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/certmongerX.html > > Hi, > > The docs seem to explain quite well how to request a certificate but > not how to actually issue a certificate. I'm looking at guides like > this - http://wiki.centos.org/HowTos/Https - and wondering how I fill > in the bits that are missing. > > I guess the real issue that I am facing here is that I want to get an > openssl certificate signed by freeipa which is nss. I am guessing that > you cant do this with certmonger? > > Sorry if I am being somewhat confusing. Im struggling to get my head > around all this. From jhrozek at redhat.com Mon Apr 28 08:55:16 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 28 Apr 2014 10:55:16 +0200 Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <927812530.6156856.1398413771558.JavaMail.zimbra@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <53581F90.3030802@redhat.com> <51109989.4612124.1398287278791.JavaMail.zimbra@redhat.com> <53583EA0.9040104@redhat.com> <713211054.4700804.1398295396344.JavaMail.zimbra@redhat.com> <53597837.1030400@redhat.com> <535A09C3.9030308@redhat.com> <535A1265.8090803@redhat.com> <927812530.6156856.1398413771558.JavaMail.zimbra@redhat.com> Message-ID: <20140428085516.GC5122@hendrix.brq.redhat.com> On Fri, Apr 25, 2014 at 04:16:11AM -0400, Stephen Benjamin wrote: > ----- Original Message ----- > > From: "Jan Cholasta" > > To: "Martin Kosek" , dpal at redhat.com, "Stephen Benjamin" > > Cc: freeipa-users at redhat.com > > Sent: Friday, April 25, 2014 9:44:37 AM > > Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 > > > AFAIK you can use ldap sudo provider with IPA, see e.g. > > > > I got this working, and seems to work across recent Fedora releases too. > This at least removes the requirement on using the old bind password > method. Thanks! In recent Fedora releases, where the IPA sudo provider is available, the "legacy" LDAP provider should not be used. There might be problems with enumeration for instance when combining two different providers. > > Is there a way for sssd to use _srv_ for the krb5_server line? Yes, it should just work. > > Here's an updated Kickstart snippet: > https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb > > If we know what the Syntax will be for sudo (or will it be default > in 4.0?), then I can include the logic already not to do it manually. Sorry, I'm not sure I understand the question? With recent enough clients (6.6+, 7.0+, any supported Fedora) you should use sudo_provider=ipa, with older ones you should use sudo_provider=ldap From stbenjam at redhat.com Mon Apr 28 09:23:18 2014 From: stbenjam at redhat.com (Stephen Benjamin) Date: Mon, 28 Apr 2014 05:23:18 -0400 (EDT) Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <20140428085516.GC5122@hendrix.brq.redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <53583EA0.9040104@redhat.com> <713211054.4700804.1398295396344.JavaMail.zimbra@redhat.com> <53597837.1030400@redhat.com> <535A09C3.9030308@redhat.com> <535A1265.8090803@redhat.com> <927812530.6156856.1398413771558.JavaMail.zimbra@redhat.com> <20140428085516.GC5122@hendrix.brq.redhat.com> Message-ID: <1373660707.7503741.1398676998871.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jakub Hrozek" > To: freeipa-users at redhat.com > Sent: Monday, April 28, 2014 10:55:16 AM > Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 > > On Fri, Apr 25, 2014 at 04:16:11AM -0400, Stephen Benjamin wrote: > > ----- Original Message ----- > > > From: "Jan Cholasta" > > > To: "Martin Kosek" , dpal at redhat.com, "Stephen > > > Benjamin" > > > Cc: freeipa-users at redhat.com > > > Sent: Friday, April 25, 2014 9:44:37 AM > > > Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 > > > > > AFAIK you can use ldap sudo provider with IPA, see e.g. > > > > > > > I got this working, and seems to work across recent Fedora releases too. > > This at least removes the requirement on using the old bind password > > method. Thanks! > > In recent Fedora releases, where the IPA sudo provider is available, the > "legacy" LDAP provider should not be used. There might be problems with > enumeration for instance when combining two different providers. Can I have a link then to how this is setup? Do you also need the LDAP URL's, nisdomain, etc? Or is it just one setting and done? > > > > Is there a way for sssd to use _srv_ for the krb5_server line? > > Yes, it should just work. > > > > > Here's an updated Kickstart snippet: > > https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb > > > > If we know what the Syntax will be for sudo (or will it be default > > in 4.0?), then I can include the logic already not to do it manually. > > Sorry, I'm not sure I understand the question? With recent enough > clients (6.6+, 7.0+, any supported Fedora) you should use > sudo_provider=ipa, with older ones you should use sudo_provider=ldap It's been mentioned elsewhere in the thread that the ipa-client-install in some feature version will do this, if that's the case I shouldn't be doing in a kickstart snippet. Will it be like automount: ipa-client-automount, or will it be an install flag? Does it exist yet? From tbabej at redhat.com Mon Apr 28 09:33:55 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 28 Apr 2014 11:33:55 +0200 Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <1373660707.7503741.1398676998871.JavaMail.zimbra@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <53583EA0.9040104@redhat.com> <713211054.4700804.1398295396344.JavaMail.zimbra@redhat.com> <53597837.1030400@redhat.com> <535A09C3.9030308@redhat.com> <535A1265.8090803@redhat.com> <927812530.6156856.1398413771558.JavaMail.zimbra@redhat.com> <20140428085516.GC5122@hendrix.brq.redhat.com> <1373660707.7503741.1398676998871.JavaMail.zimbra@redhat.com> Message-ID: <535E2083.1090707@redhat.com> On 04/28/2014 11:23 AM, Stephen Benjamin wrote: > > ----- Original Message ----- >> From: "Jakub Hrozek" >> To: freeipa-users at redhat.com >> Sent: Monday, April 28, 2014 10:55:16 AM >> Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 >> >> On Fri, Apr 25, 2014 at 04:16:11AM -0400, Stephen Benjamin wrote: >>> ----- Original Message ----- >>>> From: "Jan Cholasta" >>>> To: "Martin Kosek" , dpal at redhat.com, "Stephen >>>> Benjamin" >>>> Cc: freeipa-users at redhat.com >>>> Sent: Friday, April 25, 2014 9:44:37 AM >>>> Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 >>>> AFAIK you can use ldap sudo provider with IPA, see e.g. >>>> >>> I got this working, and seems to work across recent Fedora releases too. >>> This at least removes the requirement on using the old bind password >>> method. Thanks! >> In recent Fedora releases, where the IPA sudo provider is available, the >> "legacy" LDAP provider should not be used. There might be problems with >> enumeration for instance when combining two different providers. > Can I have a link then to how this is setup? Do you also > need the LDAP URL's, nisdomain, etc? > > Or is it just one setting and done? > > >>> Is there a way for sssd to use _srv_ for the krb5_server line? >> Yes, it should just work. >> >>> Here's an updated Kickstart snippet: >>> https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb >>> >>> If we know what the Syntax will be for sudo (or will it be default >>> in 4.0?), then I can include the logic already not to do it manually. >> Sorry, I'm not sure I understand the question? With recent enough >> clients (6.6+, 7.0+, any supported Fedora) you should use >> sudo_provider=ipa, with older ones you should use sudo_provider=ldap > It's been mentioned elsewhere in the thread that the ipa-client-install > in some feature version will do this, if that's the case I shouldn't be > doing in a kickstart snippet. > > Will it be like automount: ipa-client-automount, or will it be an install > flag? Does it exist yet? It will be the default behaviour, that is, a flag will be available to turn it *off* (--no-sudo). Yes, patches are on review and close to being pushed (waiting for the CI coverage), it will be the part of the next upstream release. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Mon Apr 28 11:03:33 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 28 Apr 2014 07:03:33 -0400 Subject: [Freeipa-users] Best practices for core servers Message-ID: <535E3585.2070903@damascusgrp.com> We are planning to reconfigure our core Freeipa servers, basically building a replacement infrastructure and migrating to it. What we're planning right now is a core of three Freeipa servers each of which has a CA, with as much distribution of replication as we can manage. I imagine that means one of them replicates to the other two but am open to other ideas. For remote locations, we're planning to stand up caching-only DNS servers, as authenticating back to the main IPA servers works extremely well; it's just DNS that needs a little help. Any thoughts before I start setting these servers (VMs, most likely) up? -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 51f7de33e4b08d2bdb8b4860 Type: image/png Size: 28526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From pspacek at redhat.com Mon Apr 28 11:40:42 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 28 Apr 2014 13:40:42 +0200 Subject: [Freeipa-users] Best practices for core servers In-Reply-To: <535E3585.2070903@damascusgrp.com> References: <535E3585.2070903@damascusgrp.com> Message-ID: <535E3E3A.6070109@redhat.com> On 28.4.2014 13:03, Bret Wortman wrote: > We are planning to reconfigure our core Freeipa servers, basically building a > replacement infrastructure and migrating to it. What we're planning right now is > a core of three Freeipa servers each of which has a CA, with as much > distribution of replication as we can manage. I imagine that means one of them > replicates to the other two but am open to other ideas. > > For remote locations, we're planning to stand up caching-only DNS servers, as > authenticating back to the main IPA servers works extremely well; it's just DNS > that needs a little help. Could you be more specific? I'm very interested in any feedback about IPA DNS! Thank you! -- Petr^2 Spacek From bret.wortman at damascusgrp.com Mon Apr 28 11:52:36 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 28 Apr 2014 07:52:36 -0400 Subject: [Freeipa-users] Error creating new freeipa-server Message-ID: <535E4104.1040509@damascusgrp.com> I'm trying to stand up a new ipa server on a clean box, and I keep getting this error so _something_ is amiss but I'm not sure what: : Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/22]: creating certificate server user [2/22]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit status 1 Configuration of CA failed # In the /var/log/ipaserver-install.log, I see this: : : Installing CA into /var/lib/pki/pki-tomcat. Installation failed. 2014-04-28T11:43:46Z DEBUG stderr=pkispawn : ERROR ........ PKI subsystem 'CA' for instance 'pki-tomcat' already exists! 2014-04-28T11:432:46Z CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit status 1 2014-04-28T11:43:46Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 622, in run_script return_value = main_function() File "/usr/sbin/ipa-server-install", line 1074, in main dm_password, subject_base=options.subject) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 478, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.7/site-packages/ipaserver/isntall/service.py", line 364, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 604, in __spawn_instance raise RUntimeError('Configuration of CA failed') : : So it looks like somehow this has gotten configured already. Possibly Puppet copied over something it shouldn't have. What do I need to remove to make this step work without removing so much that I render something inoperable? -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 51f7de33e4b08d2bdb8b4860 Type: image/png Size: 28526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Mon Apr 28 11:57:07 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 28 Apr 2014 07:57:07 -0400 Subject: [Freeipa-users] Error creating new freeipa-server In-Reply-To: <535E4104.1040509@damascusgrp.com> References: <535E4104.1040509@damascusgrp.com> Message-ID: <535E4213.8090307@redhat.com> On 04/28/2014 07:52 AM, Bret Wortman wrote: > I'm trying to stand up a new ipa server on a clean box, and I keep > getting this error so _something_ is amiss but I'm not sure what: > > : > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes > 30 seconds > [1/22]: creating certificate server user > [2/22]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit > status 1 > Configuration of CA failed > # > > In the /var/log/ipaserver-install.log, I see this: > > : > : > Installing CA into /var/lib/pki/pki-tomcat. > > Installation failed. > > > 2014-04-28T11:43:46Z DEBUG stderr=pkispawn : ERROR ........ PKI > subsystem 'CA' for instance 'pki-tomcat' already exists! > > 2014-04-28T11:432:46Z CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit > status 1 > 2014-04-28T11:43:46Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 622, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-server-install", line 1074, in main > dm_password, subject_base=options.subject) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 478, in configure_instance > self.start_creation(runtime=210) > > File > "/usr/lib/python2.7/site-packages/ipaserver/isntall/service.py", line > 364, in start_creation > method() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 604, in __spawn_instance > raise RUntimeError('Configuration of CA failed') > : > : > > So it looks like somehow this has gotten configured already. Possibly > Puppet copied over something it shouldn't have. What do I need to > remove to make this step work without removing so much that I render > something inoperable? > > Run uninstall several times. Each time uninstall might clean next portion and untangle things so trying to do it several times pays off. Then check if there is a DS instance for PKI. If there is remove it and try again. > -- > *Bret Wortman* > > http://damascusgrp.com/ > http://about.me/wortmanbret > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 28526 bytes Desc: not available URL: From bret.wortman at damascusgrp.com Mon Apr 28 12:06:21 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 28 Apr 2014 08:06:21 -0400 Subject: [Freeipa-users] Error creating new freeipa-server In-Reply-To: <535E4213.8090307@redhat.com> References: <535E4104.1040509@damascusgrp.com> <535E4213.8090307@redhat.com> Message-ID: <535E443D.5000607@damascusgrp.com> Not to be thick, but what's the best way to check the DS instance for a pki entry? On 04/28/2014 07:57 AM, Dmitri Pal wrote: > On 04/28/2014 07:52 AM, Bret Wortman wrote: >> I'm trying to stand up a new ipa server on a clean box, and I keep >> getting this error so _something_ is amiss but I'm not sure what: >> >> : >> Configuring certificate server (pki-tomcatd): Estimated time 3 >> minutes 30 seconds >> [1/22]: creating certificate server user >> [2/22]: configuring certificate server instance >> ipa : CRITICAL failed to configure ca instance Command >> '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit >> status 1 >> Configuration of CA failed >> # >> >> In the /var/log/ipaserver-install.log, I see this: >> >> : >> : >> Installing CA into /var/lib/pki/pki-tomcat. >> >> Installation failed. >> >> >> 2014-04-28T11:43:46Z DEBUG stderr=pkispawn : ERROR ........ >> PKI subsystem 'CA' for instance 'pki-tomcat' already exists! >> >> 2014-04-28T11:432:46Z CRITICAL failed to configure ca instance >> Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned >> non-zero exit status 1 >> 2014-04-28T11:43:46Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 622, in run_script >> return_value = main_function() >> >> File "/usr/sbin/ipa-server-install", line 1074, in main >> dm_password, subject_base=options.subject) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> line 478, in configure_instance >> self.start_creation(runtime=210) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/isntall/service.py", line >> 364, in start_creation >> method() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> line 604, in __spawn_instance >> raise RUntimeError('Configuration of CA failed') >> : >> : >> >> So it looks like somehow this has gotten configured already. Possibly >> Puppet copied over something it shouldn't have. What do I need to >> remove to make this step work without removing so much that I render >> something inoperable? >> >> > Run uninstall several times. Each time uninstall might clean next > portion and untangle things so trying to do it several times pays off. > Then check if there is a DS instance for PKI. If there is remove it > and try again. > >> -- >> *Bret Wortman* >> >> http://damascusgrp.com/ >> http://about.me/wortmanbret >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 28526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From cwhittl at gmail.com Mon Apr 28 12:11:03 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Mon, 28 Apr 2014 07:11:03 -0500 Subject: [Freeipa-users] Google Apps Directory Sync and Free-IPA Message-ID: I've seen a lot of people have issues with making GADS work with FreeIPA. Does anyone have it working and care to share how? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Apr 28 12:17:10 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 28 Apr 2014 08:17:10 -0400 Subject: [Freeipa-users] Google Apps Directory Sync and Free-IPA In-Reply-To: References: Message-ID: <535E46C6.2070004@redhat.com> On 04/28/2014 08:11 AM, Chris Whittle wrote: > I've seen a lot of people have issues with making GADS work with > FreeIPA. Does anyone have it working and care to share how? > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users There was a thread last week. It had some hints. Also it ended up with Simo needing to put documentation about Ipsilon IdP so that we can show how to federate FreeIPA and Google but this is not done yet. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Apr 28 12:20:30 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 28 Apr 2014 08:20:30 -0400 Subject: [Freeipa-users] Error creating new freeipa-server In-Reply-To: <535E443D.5000607@damascusgrp.com> References: <535E4104.1040509@damascusgrp.com> <535E4213.8090307@redhat.com> <535E443D.5000607@damascusgrp.com> Message-ID: <535E478E.1010100@redhat.com> On 04/28/2014 08:06 AM, Bret Wortman wrote: > Not to be thick, but what's the best way to check the DS instance for > a pki entry? I do not remember the exact path and I do not have an instance handy. Something like /var/lib/dirsrv/PKI, do not want to mislead you. > > On 04/28/2014 07:57 AM, Dmitri Pal wrote: >> On 04/28/2014 07:52 AM, Bret Wortman wrote: >>> I'm trying to stand up a new ipa server on a clean box, and I keep >>> getting this error so _something_ is amiss but I'm not sure what: >>> >>> : >>> Configuring certificate server (pki-tomcatd): Estimated time 3 >>> minutes 30 seconds >>> [1/22]: creating certificate server user >>> [2/22]: configuring certificate server instance >>> ipa : CRITICAL failed to configure ca instance Command >>> '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit >>> status 1 >>> Configuration of CA failed >>> # >>> >>> In the /var/log/ipaserver-install.log, I see this: >>> >>> : >>> : >>> Installing CA into /var/lib/pki/pki-tomcat. >>> >>> Installation failed. >>> >>> >>> 2014-04-28T11:43:46Z DEBUG stderr=pkispawn : ERROR ........ >>> PKI subsystem 'CA' for instance 'pki-tomcat' already exists! >>> >>> 2014-04-28T11:432:46Z CRITICAL failed to configure ca instance >>> Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned >>> non-zero exit status 1 >>> 2014-04-28T11:43:46Z DEBUG File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line >>> 622, in run_script >>> return_value = main_function() >>> >>> File "/usr/sbin/ipa-server-install", line 1074, in main >>> dm_password, subject_base=options.subject) >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>> line 478, in configure_instance >>> self.start_creation(runtime=210) >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/isntall/service.py", >>> line 364, in start_creation >>> method() >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>> line 604, in __spawn_instance >>> raise RUntimeError('Configuration of CA failed') >>> : >>> : >>> >>> So it looks like somehow this has gotten configured already. >>> Possibly Puppet copied over something it shouldn't have. What do I >>> need to remove to make this step work without removing so much that >>> I render something inoperable? >>> >>> >> Run uninstall several times. Each time uninstall might clean next >> portion and untangle things so trying to do it several times pays off. >> Then check if there is a DS instance for PKI. If there is remove it >> and try again. >> >>> -- >>> *Bret Wortman* >>> >>> http://damascusgrp.com/ >>> http://about.me/wortmanbret >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 28526 bytes Desc: not available URL: From cwhittl at gmail.com Mon Apr 28 12:22:33 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Mon, 28 Apr 2014 07:22:33 -0500 Subject: [Freeipa-users] Google Apps Directory Sync and Free-IPA In-Reply-To: <535E46C6.2070004@redhat.com> References: <535E46C6.2070004@redhat.com> Message-ID: Ha! that was my thread about SAML vs GADS but there ended up not being any info on how to actually use GADS with Free IPA. It dropped after Simo saying he was going to work on getting docs for ipsilon (which from the conversation and I can gather is basically SAML) and I asked for someone who had experience with GADS so I started a new one for simplification. On Mon, Apr 28, 2014 at 7:17 AM, Dmitri Pal wrote: > On 04/28/2014 08:11 AM, Chris Whittle wrote: > > I've seen a lot of people have issues with making GADS work with FreeIPA. > Does anyone have it working and care to share how? > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > There was a thread last week. It had some hints. Also it ended up with > Simo needing to put documentation about Ipsilon IdP so that we can show how > to federate FreeIPA and Google but this is not done yet. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Apr 28 12:24:57 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 28 Apr 2014 08:24:57 -0400 Subject: [Freeipa-users] Google Apps Directory Sync and Free-IPA In-Reply-To: References: <535E46C6.2070004@redhat.com> Message-ID: <535E4899.5070503@redhat.com> On 04/28/2014 08:22 AM, Chris Whittle wrote: > Ha! that was my thread about SAML vs GADS but there ended up not being > any info on how to actually use GADS with Free IPA. It dropped after > Simo saying he was going to work on getting docs for ipsilon (which > from the conversation and I can gather is basically SAML) and I asked > for someone who had experience with GADS so I started a new one for > simplification. I do not think we have a better answer for you other than what Martin mentioned and SAML IdP Simo is working on. > > > On Mon, Apr 28, 2014 at 7:17 AM, Dmitri Pal > wrote: > > On 04/28/2014 08:11 AM, Chris Whittle wrote: >> I've seen a lot of people have issues with making GADS work with >> FreeIPA. Does anyone have it working and care to share how? >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > There was a thread last week. It had some hints. Also it ended up > with Simo needing to put documentation about Ipsilon IdP so that > we can show how to federate FreeIPA and Google but this is not > done yet. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Apr 28 12:33:30 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 28 Apr 2014 14:33:30 +0200 Subject: [Freeipa-users] Error creating new freeipa-server In-Reply-To: <535E4104.1040509@damascusgrp.com> References: <535E4104.1040509@damascusgrp.com> Message-ID: <535E4A9A.4000302@redhat.com> On 04/28/2014 01:52 PM, Bret Wortman wrote: > I'm trying to stand up a new ipa server on a clean box, and I keep > getting this error so _something_ is amiss but I'm not sure what: > > : > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes > 30 seconds > [1/22]: creating certificate server user > [2/22]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit status 1 > Configuration of CA failed > # > > In the /var/log/ipaserver-install.log, I see this: > > : > : > Installing CA into /var/lib/pki/pki-tomcat. > > Installation failed. > > > 2014-04-28T11:43:46Z DEBUG stderr=pkispawn : ERROR ........ PKI > subsystem 'CA' for instance 'pki-tomcat' already exists! > > 2014-04-28T11:432:46Z CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit status 1 > 2014-04-28T11:43:46Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 622, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-server-install", line 1074, in main > dm_password, subject_base=options.subject) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 478, in configure_instance > self.start_creation(runtime=210) > > File "/usr/lib/python2.7/site-packages/ipaserver/isntall/service.py", > line 364, in start_creation > method() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 604, in __spawn_instance > raise RUntimeError('Configuration of CA failed') > : > : > > So it looks like somehow this has gotten configured already. Possibly > Puppet copied over something it shouldn't have. What do I need to remove > to make this step work without removing so much that I render something > inoperable? According to the error you're getting, there is a CA instance already installed. After uninstalling IPA, destroy it with: pkidestroy -s CA -i pki-tomcat -- Petr? From bret.wortman at damascusgrp.com Mon Apr 28 12:41:11 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 28 Apr 2014 08:41:11 -0400 Subject: [Freeipa-users] Error creating new freeipa-server In-Reply-To: <535E478E.1010100@redhat.com> References: <535E4104.1040509@damascusgrp.com> <535E4213.8090307@redhat.com> <535E443D.5000607@damascusgrp.com> <535E478E.1010100@redhat.com> Message-ID: <550FA780-9C6C-4EE4-A35B-7BC01A44AE40@damascusgrp.com> I thought that might be it and didn't see anything but will look again. Bret Wortman http://bretwortman.com/ http://twitter.com/BretWortman > On Apr 28, 2014, at 8:20 AM, Dmitri Pal wrote: > >> On 04/28/2014 08:06 AM, Bret Wortman wrote: >> Not to be thick, but what's the best way to check the DS instance for a pki entry? > > I do not remember the exact path and I do not have an instance handy. Something like /var/lib/dirsrv/PKI, do not want to mislead you. > > >> >>> On 04/28/2014 07:57 AM, Dmitri Pal wrote: >>>> On 04/28/2014 07:52 AM, Bret Wortman wrote: >>>> I'm trying to stand up a new ipa server on a clean box, and I keep getting this error so _something_ is amiss but I'm not sure what: >>>> >>>> : >>>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds >>>> [1/22]: creating certificate server user >>>> [2/22]: configuring certificate server instance >>>> ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit status 1 >>>> Configuration of CA failed >>>> # >>>> >>>> In the /var/log/ipaserver-install.log, I see this: >>>> >>>> : >>>> : >>>> Installing CA into /var/lib/pki/pki-tomcat. >>>> >>>> Installation failed. >>>> >>>> >>>> 2014-04-28T11:43:46Z DEBUG stderr=pkispawn : ERROR ........ PKI subsystem 'CA' for instance 'pki-tomcat' already exists! >>>> >>>> 2014-04-28T11:432:46Z CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit status 1 >>>> 2014-04-28T11:43:46Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 622, in run_script >>>> return_value = main_function() >>>> >>>> File "/usr/sbin/ipa-server-install", line 1074, in main >>>> dm_password, subject_base=options.subject) >>>> >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 478, in configure_instance >>>> self.start_creation(runtime=210) >>>> >>>> File "/usr/lib/python2.7/site-packages/ipaserver/isntall/service.py", line 364, in start_creation >>>> method() >>>> >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 604, in __spawn_instance >>>> raise RUntimeError('Configuration of CA failed') >>>> : >>>> : >>>> >>>> So it looks like somehow this has gotten configured already. Possibly Puppet copied over something it shouldn't have. What do I need to remove to make this step work without removing so much that I render something inoperable? >>> Run uninstall several times. Each time uninstall might clean next portion and untangle things so trying to do it several times pays off. >>> Then check if there is a DS instance for PKI. If there is remove it and try again. >>> >>>> -- >>>> Bret Wortman >>>> >>>> http://damascusgrp.com/ >>>> http://about.me/wortmanbret >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2346 bytes Desc: not available URL: From bret.wortman at damascusgrp.com Mon Apr 28 12:41:37 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 28 Apr 2014 08:41:37 -0400 Subject: [Freeipa-users] Error creating new freeipa-server In-Reply-To: <535E4A9A.4000302@redhat.com> References: <535E4104.1040509@damascusgrp.com> <535E4A9A.4000302@redhat.com> Message-ID: Great. I'll try that next. Bret Wortman http://bretwortman.com/ http://twitter.com/BretWortman > On Apr 28, 2014, at 8:33 AM, Petr Viktorin wrote: > >> On 04/28/2014 01:52 PM, Bret Wortman wrote: >> I'm trying to stand up a new ipa server on a clean box, and I keep >> getting this error so _something_ is amiss but I'm not sure what: >> >> : >> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes >> 30 seconds >> [1/22]: creating certificate server user >> [2/22]: configuring certificate server instance >> ipa : CRITICAL failed to configure ca instance Command >> '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit status 1 >> Configuration of CA failed >> # >> >> In the /var/log/ipaserver-install.log, I see this: >> >> : >> : >> Installing CA into /var/lib/pki/pki-tomcat. >> >> Installation failed. >> >> >> 2014-04-28T11:43:46Z DEBUG stderr=pkispawn : ERROR ........ PKI >> subsystem 'CA' for instance 'pki-tomcat' already exists! >> >> 2014-04-28T11:432:46Z CRITICAL failed to configure ca instance Command >> '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit status 1 >> 2014-04-28T11:43:46Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 622, in run_script >> return_value = main_function() >> >> File "/usr/sbin/ipa-server-install", line 1074, in main >> dm_password, subject_base=options.subject) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >> 478, in configure_instance >> self.start_creation(runtime=210) >> >> File "/usr/lib/python2.7/site-packages/ipaserver/isntall/service.py", >> line 364, in start_creation >> method() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >> 604, in __spawn_instance >> raise RUntimeError('Configuration of CA failed') >> : >> : >> >> So it looks like somehow this has gotten configured already. Possibly >> Puppet copied over something it shouldn't have. What do I need to remove >> to make this step work without removing so much that I render something >> inoperable? > > > According to the error you're getting, there is a CA instance already installed. > After uninstalling IPA, destroy it with: > pkidestroy -s CA -i pki-tomcat > > > > -- > Petr? > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2346 bytes Desc: not available URL: From jhrozek at redhat.com Mon Apr 28 12:51:26 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 28 Apr 2014 14:51:26 +0200 Subject: [Freeipa-users] FreeIPA + Foreman 1.5 In-Reply-To: <1373660707.7503741.1398676998871.JavaMail.zimbra@redhat.com> References: <491816867.4236411.1398261634360.JavaMail.zimbra@redhat.com> <53583EA0.9040104@redhat.com> <713211054.4700804.1398295396344.JavaMail.zimbra@redhat.com> <53597837.1030400@redhat.com> <535A09C3.9030308@redhat.com> <535A1265.8090803@redhat.com> <927812530.6156856.1398413771558.JavaMail.zimbra@redhat.com> <20140428085516.GC5122@hendrix.brq.redhat.com> <1373660707.7503741.1398676998871.JavaMail.zimbra@redhat.com> Message-ID: <20140428125126.GJ5122@hendrix.brq.redhat.com> On Mon, Apr 28, 2014 at 05:23:18AM -0400, Stephen Benjamin wrote: > > > ----- Original Message ----- > > From: "Jakub Hrozek" > > To: freeipa-users at redhat.com > > Sent: Monday, April 28, 2014 10:55:16 AM > > Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 > > > > On Fri, Apr 25, 2014 at 04:16:11AM -0400, Stephen Benjamin wrote: > > > ----- Original Message ----- > > > > From: "Jan Cholasta" > > > > To: "Martin Kosek" , dpal at redhat.com, "Stephen > > > > Benjamin" > > > > Cc: freeipa-users at redhat.com > > > > Sent: Friday, April 25, 2014 9:44:37 AM > > > > Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 > > > > > > > AFAIK you can use ldap sudo provider with IPA, see e.g. > > > > > > > > > > I got this working, and seems to work across recent Fedora releases too. > > > This at least removes the requirement on using the old bind password > > > method. Thanks! > > > > In recent Fedora releases, where the IPA sudo provider is available, the > > "legacy" LDAP provider should not be used. There might be problems with > > enumeration for instance when combining two different providers. > > Can I have a link then to how this is setup? Do you also > need the LDAP URL's, nisdomain, etc? man sssd-ipa should have a nice example of setting up the sssd.conf for sudo_provider=ldap > > Or is it just one setting and done? With sudo_provider=ipa, it's just that one line. You still need to configure the nisdomain etc. > > > > > > > > Is there a way for sssd to use _srv_ for the krb5_server line? > > > > Yes, it should just work. > > > > > > > > Here's an updated Kickstart snippet: > > > https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb > > > > > > If we know what the Syntax will be for sudo (or will it be default > > > in 4.0?), then I can include the logic already not to do it manually. > > > > Sorry, I'm not sure I understand the question? With recent enough > > clients (6.6+, 7.0+, any supported Fedora) you should use > > sudo_provider=ipa, with older ones you should use sudo_provider=ldap > > It's been mentioned elsewhere in the thread that the ipa-client-install > in some feature version will do this, if that's the case I shouldn't be > doing in a kickstart snippet. > > Will it be like automount: ipa-client-automount, or will it be an install > flag? Does it exist yet? Looks like this feature is not implemented completely yet: https://fedorahosted.org/freeipa/ticket/3358 From pspacek at redhat.com Mon Apr 28 13:08:02 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 28 Apr 2014 15:08:02 +0200 Subject: [Freeipa-users] Hardening freeipa on the internet In-Reply-To: <535A2426.3000908@redhat.com> References: <535A18A3.1060202@redhat.com> <535A2426.3000908@redhat.com> Message-ID: <535E52B2.2030301@redhat.com> On 25.4.2014 11:00, Petr Spacek wrote: > On 25.4.2014 10:11, Martin Kosek wrote: >> On 04/25/2014 09:50 AM, Andrew Holway wrote: >>> Hello, >>> >>> I am having a think about running freeipa on the open seas for more >>> distributed organisations and would like to understand where the >>> weaknesses might be. I would almost certainly only make the ui >>> unavailable however I am unsure about the other services. >>> >>> Would this be a workable? >>> >>> Thanks, >>> >>> Andrew >> >> That's actually a very good question. I am currently working on a public >> FreeIPA demo on Red Hat OpenStack platform which I will make available in >> upcoming weeks and have few pointers for you: >> >> 1) If you have DNS configured, make sure that your FreeIPA DNS does not pose as >> open DNS resolver to avoid DNS amplification attacks. >> >> Following extension to named.conf options should be a good start: >> >> allow-transfer {"none";}; > This configuration applies only to zones defined in named.conf and not to > FreeIPA zones defined in LDAP. > > Make sure that allow-transfer is configured for FreeIPA zones: > $ ipa dnszone-mod --allow-transfer="none;" example. > >> allow-recursion {"none";}; >> recursion no; >> version "[Secured]"; >> rate-limit { >> responses-per-second 15; > You may need to modify this value to fit your needs. > > Further reading about DNS amplification attacks: > http://www.us-cert.gov/ncas/alerts/TA13-088A > > Further reading about Response Rate Limiting: > http://bkraft.fr/blog/bind_RRL_feature/ > > https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response-Rate-Limiting.html > > > https://kb.isc.org/article/AA-00994/0 > >> }; >> >> 2) Prevention for NTP amplification attack >> >> More info here: >> https://support.steadfast.net/Knowledgebase/Article/View/106/0/preventing-ntp-amplification-attacks >> > > Further reading about NTP amplification attacks: > http://www.us-cert.gov/ncas/alerts/TA14-013A > >> Does anybody know about other precautions that should be made besides standard >> hardening (SELinux, firewall, log audits)? > > I wonder if Kerberos over UDP could have the same problem... Maybe only if you > have some principals with disabled pre-authentication. I don't know. Kerberos > is not listed on > http://www.us-cert.gov/ncas/alerts/TA14-017A ... I realized that you probably want to disable anonymous access to LDAP. It will prevent random strangers to enumerate all users in your database... -- Petr^2 Spacek From bret.wortman at damascusgrp.com Mon Apr 28 14:21:51 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 28 Apr 2014 10:21:51 -0400 Subject: [Freeipa-users] Error creating new freeipa-server In-Reply-To: <535E4A9A.4000302@redhat.com> References: <535E4104.1040509@damascusgrp.com> <535E4A9A.4000302@redhat.com> Message-ID: <535E63FF.7050401@damascusgrp.com> On 04/28/2014 08:33 AM, Petr Viktorin wrote: > > According to the error you're getting, there is a CA instance already > installed. > After uninstalling IPA, destroy it with: > pkidestroy -s CA -i pki-tomcat > > I tried, this, but no joy. # pkidestroy -s CA -i pki-tomcat Loading deployment configuration from /var/lib/pki/pki-tomcat /ca/registry/ca/deployment.cfg. Uninstalling CA from /var/lib/pki/pki-tomcat. pkidestroy : WARNING ....... this 'CA' entry will NOT be deleted from security domain 'unknown'! pkidestroy : ERROR ....... No security domain defined. If this is an unconfigured instance, then that is OK. Otherwise, manually delete the entry from the security domain master. Uninstallation complete. # And then when I tried to run ipa-server-install, I got the same error again. I may just wipe the box and start over. It might take less time overall. Bret -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From bret.wortman at damascusgrp.com Mon Apr 28 14:27:27 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 28 Apr 2014 10:27:27 -0400 Subject: [Freeipa-users] Error creating new freeipa-server In-Reply-To: <535E63FF.7050401@damascusgrp.com> References: <535E4104.1040509@damascusgrp.com> <535E4A9A.4000302@redhat.com> <535E63FF.7050401@damascusgrp.com> Message-ID: <535E654F.5070802@damascusgrp.com> On 04/28/2014 10:21 AM, Bret Wortman wrote: > > On 04/28/2014 08:33 AM, Petr Viktorin wrote: >> >> According to the error you're getting, there is a CA instance already >> installed. >> After uninstalling IPA, destroy it with: >> pkidestroy -s CA -i pki-tomcat >> >> > I tried, this, but no joy. > > # pkidestroy -s CA -i pki-tomcat > Loading deployment configuration from /var/lib/pki/pki-tomcat > /ca/registry/ca/deployment.cfg. > Uninstalling CA from /var/lib/pki/pki-tomcat. > pkidestroy : WARNING ....... this 'CA' entry will NOT be deleted from > security domain 'unknown'! > pkidestroy : ERROR ....... No security domain defined. > If this is an unconfigured instance, then that is OK. > Otherwise, manually delete the entry from the security domain master. > > Uninstallation complete. > # > > And then when I tried to run ipa-server-install, I got the same error > again. I may just wipe the box and start over. It might take less time > overall. > > > Bret > This, BTW, is on F20 using freeipa 3.3.4-3 and pki-ca 10.1.1-1 (also dogtag-10.1.1-1). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From simo at redhat.com Mon Apr 28 14:32:43 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 28 Apr 2014 10:32:43 -0400 Subject: [Freeipa-users] Google Apps Directory Sync and Free-IPA In-Reply-To: <535E4899.5070503@redhat.com> References: <535E46C6.2070004@redhat.com> <535E4899.5070503@redhat.com> Message-ID: <1398695563.10424.48.camel@willson.li.ssimo.org> On Mon, 2014-04-28 at 08:24 -0400, Dmitri Pal wrote: > On 04/28/2014 08:22 AM, Chris Whittle wrote: > > Ha! that was my thread about SAML vs GADS but there ended up not being > > any info on how to actually use GADS with Free IPA. It dropped after > > Simo saying he was going to work on getting docs for ipsilon (which > > from the conversation and I can gather is basically SAML) and I asked > > for someone who had experience with GADS so I started a new one for > > simplification. > > I do not think we have a better answer for you other than what Martin > mentioned and SAML IdP Simo is working on. note that any other SAML IdP that has support for LDAP may work, for example http://picketlink.org/ may work for you if you have experience in setting up jboss based applications and know how to make your way in configuring such software. (I can't help here really). Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Apr 28 14:48:51 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Apr 2014 10:48:51 -0400 Subject: [Freeipa-users] Error creating new freeipa-server In-Reply-To: <535E654F.5070802@damascusgrp.com> References: <535E4104.1040509@damascusgrp.com> <535E4A9A.4000302@redhat.com> <535E63FF.7050401@damascusgrp.com> <535E654F.5070802@damascusgrp.com> Message-ID: <535E6A53.5030701@redhat.com> Bret Wortman wrote: > > On 04/28/2014 10:21 AM, Bret Wortman wrote: >> >> On 04/28/2014 08:33 AM, Petr Viktorin wrote: >>> >>> According to the error you're getting, there is a CA instance already >>> installed. >>> After uninstalling IPA, destroy it with: >>> pkidestroy -s CA -i pki-tomcat >>> >>> >> I tried, this, but no joy. >> >> # pkidestroy -s CA -i pki-tomcat >> Loading deployment configuration from /var/lib/pki/pki-tomcat >> /ca/registry/ca/deployment.cfg. >> Uninstalling CA from /var/lib/pki/pki-tomcat. >> pkidestroy : WARNING ....... this 'CA' entry will NOT be deleted from >> security domain 'unknown'! >> pkidestroy : ERROR ....... No security domain defined. >> If this is an unconfigured instance, then that is OK. >> Otherwise, manually delete the entry from the security domain master. >> >> Uninstallation complete. >> # >> >> And then when I tried to run ipa-server-install, I got the same error >> again. I may just wipe the box and start over. It might take less time >> overall. >> >> >> Bret >> > This, BTW, is on F20 using freeipa 3.3.4-3 and pki-ca 10.1.1-1 (also > dogtag-10.1.1-1). From the ipa-server installation output the error looks the same, but the underlying error should be different when there isn't already a PKI instance. If the PKI installer fails early enough we don't record that it was installed which is why ipa-server-install --uninstall doesn't remove it. We have a ticket open for this. rob From bret.wortman at damascusgrp.com Mon Apr 28 15:08:39 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 28 Apr 2014 11:08:39 -0400 Subject: [Freeipa-users] Error creating new freeipa-server In-Reply-To: <535E6A53.5030701@redhat.com> References: <535E4104.1040509@damascusgrp.com> <535E4A9A.4000302@redhat.com> <535E63FF.7050401@damascusgrp.com> <535E654F.5070802@damascusgrp.com> <535E6A53.5030701@redhat.com> Message-ID: <535E6EF7.8090100@damascusgrp.com> On 04/28/2014 10:48 AM, Rob Crittenden wrote: > Bret Wortman wrote: >> >> On 04/28/2014 10:21 AM, Bret Wortman wrote: >>> >>> On 04/28/2014 08:33 AM, Petr Viktorin wrote: >>>> >>>> According to the error you're getting, there is a CA instance already >>>> installed. >>>> After uninstalling IPA, destroy it with: >>>> pkidestroy -s CA -i pki-tomcat >>>> >>>> >>> I tried, this, but no joy. >>> >>> # pkidestroy -s CA -i pki-tomcat >>> Loading deployment configuration from /var/lib/pki/pki-tomcat >>> /ca/registry/ca/deployment.cfg. >>> Uninstalling CA from /var/lib/pki/pki-tomcat. >>> pkidestroy : WARNING ....... this 'CA' entry will NOT be deleted from >>> security domain 'unknown'! >>> pkidestroy : ERROR ....... No security domain defined. >>> If this is an unconfigured instance, then that is OK. >>> Otherwise, manually delete the entry from the security domain master. >>> >>> Uninstallation complete. >>> # >>> >>> And then when I tried to run ipa-server-install, I got the same error >>> again. I may just wipe the box and start over. It might take less time >>> overall. >>> >>> >>> Bret >>> >> This, BTW, is on F20 using freeipa 3.3.4-3 and pki-ca 10.1.1-1 (also >> dogtag-10.1.1-1). > > From the ipa-server installation output the error looks the same, but > the underlying error should be different when there isn't already a > PKI instance. > > If the PKI installer fails early enough we don't record that it was > installed which is why ipa-server-install --uninstall doesn't remove > it. We have a ticket open for this. > > rob > So is there a recommended way to clean it up and get it working? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From andrew.holway at gmail.com Mon Apr 28 15:11:51 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Mon, 28 Apr 2014 16:11:51 +0100 Subject: [Freeipa-users] Hardening freeipa on the internet In-Reply-To: <535E52B2.2030301@redhat.com> References: <535A18A3.1060202@redhat.com> <535A2426.3000908@redhat.com> <535E52B2.2030301@redhat.com> Message-ID: > I realized that you probably want to disable anonymous access to LDAP. It > will prevent random strangers to enumerate all users in your database... This sounds like a bug no? anonymous access to LDAP? > > > -- > Petr^2 Spacek > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From simo at redhat.com Mon Apr 28 15:16:45 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 28 Apr 2014 11:16:45 -0400 Subject: [Freeipa-users] Hardening freeipa on the internet In-Reply-To: References: <535A18A3.1060202@redhat.com> <535A2426.3000908@redhat.com> <535E52B2.2030301@redhat.com> Message-ID: <1398698205.10424.50.camel@willson.li.ssimo.org> On Mon, 2014-04-28 at 16:11 +0100, Andrew Holway wrote: > > I realized that you probably want to disable anonymous access to LDAP. It > > will prevent random strangers to enumerate all users in your database... > > This sounds like a bug no? anonymous access to LDAP? Historically many Linux and Unix OSs did not authenticate to LDAP to download POSIX info, so we allow by default to access a lot of the tree anonymously. We are in the process of changing how the permissions work in 4.0, and will contextually close down a lot more of the tree letting the admin more easily configure access. So, no it is not technically a bug, but it is something you want to look out for as an admin. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Apr 28 15:17:42 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Apr 2014 11:17:42 -0400 Subject: [Freeipa-users] Error creating new freeipa-server In-Reply-To: <535E6EF7.8090100@damascusgrp.com> References: <535E4104.1040509@damascusgrp.com> <535E4A9A.4000302@redhat.com> <535E63FF.7050401@damascusgrp.com> <535E654F.5070802@damascusgrp.com> <535E6A53.5030701@redhat.com> <535E6EF7.8090100@damascusgrp.com> Message-ID: <535E7116.9000903@redhat.com> Bret Wortman wrote: > > On 04/28/2014 10:48 AM, Rob Crittenden wrote: >> Bret Wortman wrote: >>> >>> On 04/28/2014 10:21 AM, Bret Wortman wrote: >>>> >>>> On 04/28/2014 08:33 AM, Petr Viktorin wrote: >>>>> >>>>> According to the error you're getting, there is a CA instance already >>>>> installed. >>>>> After uninstalling IPA, destroy it with: >>>>> pkidestroy -s CA -i pki-tomcat >>>>> >>>>> >>>> I tried, this, but no joy. >>>> >>>> # pkidestroy -s CA -i pki-tomcat >>>> Loading deployment configuration from /var/lib/pki/pki-tomcat >>>> /ca/registry/ca/deployment.cfg. >>>> Uninstalling CA from /var/lib/pki/pki-tomcat. >>>> pkidestroy : WARNING ....... this 'CA' entry will NOT be deleted from >>>> security domain 'unknown'! >>>> pkidestroy : ERROR ....... No security domain defined. >>>> If this is an unconfigured instance, then that is OK. >>>> Otherwise, manually delete the entry from the security domain master. >>>> >>>> Uninstallation complete. >>>> # >>>> >>>> And then when I tried to run ipa-server-install, I got the same error >>>> again. I may just wipe the box and start over. It might take less time >>>> overall. >>>> >>>> >>>> Bret >>>> >>> This, BTW, is on F20 using freeipa 3.3.4-3 and pki-ca 10.1.1-1 (also >>> dogtag-10.1.1-1). >> >> From the ipa-server installation output the error looks the same, but >> the underlying error should be different when there isn't already a >> PKI instance. >> >> If the PKI installer fails early enough we don't record that it was >> installed which is why ipa-server-install --uninstall doesn't remove >> it. We have a ticket open for this. >> >> rob >> > So is there a recommended way to clean it up and get it working? Re-run pkidestroy, then if the subsequent IPA install fails closely examine the logs to determine the reason. The problem in cases like this is that the first install fails and subsequent installs mask the original failure with this PKI re-install failure. rob From bret.wortman at damascusgrp.com Mon Apr 28 15:24:22 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 28 Apr 2014 11:24:22 -0400 Subject: [Freeipa-users] Error creating new freeipa-server In-Reply-To: <535E6EF7.8090100@damascusgrp.com> References: <535E4104.1040509@damascusgrp.com> <535E4A9A.4000302@redhat.com> <535E63FF.7050401@damascusgrp.com> <535E654F.5070802@damascusgrp.com> <535E6A53.5030701@redhat.com> <535E6EF7.8090100@damascusgrp.com> Message-ID: <535E72A6.8020403@damascusgrp.com> On 04/28/2014 11:08 AM, Bret Wortman wrote: > > On 04/28/2014 10:48 AM, Rob Crittenden wrote: >> Bret Wortman wrote: >>> >>> On 04/28/2014 10:21 AM, Bret Wortman wrote: >>>> >>>> On 04/28/2014 08:33 AM, Petr Viktorin wrote: >>>>> >>>>> According to the error you're getting, there is a CA instance already >>>>> installed. >>>>> After uninstalling IPA, destroy it with: >>>>> pkidestroy -s CA -i pki-tomcat >>>>> >>>>> >>>> I tried, this, but no joy. >>>> >>>> # pkidestroy -s CA -i pki-tomcat >>>> Loading deployment configuration from /var/lib/pki/pki-tomcat >>>> /ca/registry/ca/deployment.cfg. >>>> Uninstalling CA from /var/lib/pki/pki-tomcat. >>>> pkidestroy : WARNING ....... this 'CA' entry will NOT be deleted from >>>> security domain 'unknown'! >>>> pkidestroy : ERROR ....... No security domain defined. >>>> If this is an unconfigured instance, then that is OK. >>>> Otherwise, manually delete the entry from the security domain master. >>>> >>>> Uninstallation complete. >>>> # >>>> >>>> And then when I tried to run ipa-server-install, I got the same error >>>> again. I may just wipe the box and start over. It might take less time >>>> overall. >>>> >>>> >>>> Bret >>>> >>> This, BTW, is on F20 using freeipa 3.3.4-3 and pki-ca 10.1.1-1 (also >>> dogtag-10.1.1-1). >> >> From the ipa-server installation output the error looks the same, but >> the underlying error should be different when there isn't already a >> PKI instance. >> >> If the PKI installer fails early enough we don't record that it was >> installed which is why ipa-server-install --uninstall doesn't remove >> it. We have a ticket open for this. >> >> rob >> > So is there a recommended way to clean it up and get it working? > Never mind; I found the bug (953488) which said to: # pkidestroy -s CA -i pki-tomcat ERROR: PKI instance '/var/lib/pki/pki-tomcat' does NOT exist! # rm -rf /var/log/pki/pki-tomcat # rm -rf /etc/sysconfig/pki-tomcat # rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat # rm -rf /var/lib/pki/pki-tomcat # rm -rf /etc/pki/pki-tomcat # ipa-server-install --uninstall And re-run installation. This didn't work for me. Was there another bug that I missed? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From bret.wortman at damascusgrp.com Mon Apr 28 15:44:30 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 28 Apr 2014 11:44:30 -0400 Subject: [Freeipa-users] Error creating new freeipa-server In-Reply-To: <535E7116.9000903@redhat.com> References: <535E4104.1040509@damascusgrp.com> <535E4A9A.4000302@redhat.com> <535E63FF.7050401@damascusgrp.com> <535E654F.5070802@damascusgrp.com> <535E6A53.5030701@redhat.com> <535E6EF7.8090100@damascusgrp.com> <535E7116.9000903@redhat.com> Message-ID: <535E775E.6030806@damascusgrp.com> On 04/28/2014 11:17 AM, Rob Crittenden wrote: > Bret Wortman wrote: >> So is there a recommended way to clean it up and get it working? > > Re-run pkidestroy, then if the subsequent IPA install fails closely > examine the logs to determine the reason. The problem in cases like > this is that the first install fails and subsequent installs mask the > original failure with this PKI re-install failure. > > rob > Okay, here's the log from when it starts configuring PKI: 2014-04-28T15:23:45Z DEBUG [2/22]: configuring certificate server instance 2014-04-28T15:23:45Z DEBUG Contents of pkispawn configuration file (/tmp/tmpdCm6rt): [CA] pki_security_domain_name = IPA pki_enable_proxy = True pki_restart_configured_instance = False pki_backup_keys = True pki-backup_password = XXXXXXXX pki_client_database_dir = /tmp/tmp-rVoTR2 pki_client_database_password = XXXXXXXX pki_client_database_purge = False pki_client_pkcs12_password = XXXXXXXX pki_admin_name = admin pki_admin_uid = admin pki_admin_email = root at localhost pki_admin_password = XXXXXXXX pki_admin_nickname = ipa-ca-agent pki_admin_subject_dn = cn=ipa-ca-agent,O=FOO.NET pki_client_admin_cert_p12 = /root/ca-agent.p12 pki_ds_ldap_port = 389 pki_ds_password = XXXXXXXX pki_ds_base_dn = o=ipaca pki_ds_database = ipaca pki_subsystem_subject+dn = cn=CA Subsystem,O=FOO.NET pki_ocsp_signing_subject_dn = cn=OCSP Subsystem,O=FOO.NET pki_ssl_server_subject_dn = cn=zsipa.foo.net,O=FOO.NET pki_audit_signing_subject_dn = cn=CA Audit,O=FOO.NET pki_ca_signing_subject_dn = cn-Certificate Authority,O=FOO.NET pki_subsystem_nickname = subsystemCert cert-pki-ca pki_ocsp_signing_nickname = ocspSigningCert cert-pki-ca pki_ssl_server_nickname = Server-Cert cert-pki-ca pki_audit_signing_nickname = auditSigningCert cert-pki-ca pki_ca_signing_nickname = caSigningCert cert-pki-ca 2014-04-28T15:23:45Z DEBUG Starting external process 2014-04-28T15:23:45Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpdCm6rt 2014-04-28T15:23:45Z DEBUG Process finished, return code=1 2014-04-28T15:23:45Z DEBUG stdout=Loading deployment configuration from /tmp/tmpdCm6rt. Installing CA into /var/lib/pki/pki-tomcat. Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg Installation failed. 2014-04-28T15:24:46Z DEBUG stderr=pkispawn : ERROR ....... server failed to restart 2014-04-28T15:24:46Z CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpdCm6rt' returned non-zero exit status 1 2014-04-28T15:24:46Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 622, in run_script return_value = main_function() File "/usr/sbin/ipa-server-install", line 1074, in main dm_password, subject_base=options.subject) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 478, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.7/site-packages/ipaserver/isntall/service.py", line 364, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 604, in __spawn_instance raise RUntimeError('Configuration of CA failed') 2014-04-28T15:24:46Z DEBUG The ipa-server-install command failed, exception: RuntimeError: Configuration of CA failed And that's the end of the log. Nothing here looks terribly informative to me, and this is what the log looks like every time I look at it. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Apr 28 15:52:39 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Apr 2014 11:52:39 -0400 Subject: [Freeipa-users] Error creating new freeipa-server In-Reply-To: <535E775E.6030806@damascusgrp.com> References: <535E4104.1040509@damascusgrp.com> <535E4A9A.4000302@redhat.com> <535E63FF.7050401@damascusgrp.com> <535E654F.5070802@damascusgrp.com> <535E6A53.5030701@redhat.com> <535E6EF7.8090100@damascusgrp.com> <535E7116.9000903@redhat.com> <535E775E.6030806@damascusgrp.com> Message-ID: <535E7947.6010901@redhat.com> Bret Wortman wrote: > > On 04/28/2014 11:17 AM, Rob Crittenden wrote: >> Bret Wortman wrote: >>> So is there a recommended way to clean it up and get it working? >> >> Re-run pkidestroy, then if the subsequent IPA install fails closely >> examine the logs to determine the reason. The problem in cases like >> this is that the first install fails and subsequent installs mask the >> original failure with this PKI re-install failure. >> >> rob >> > Okay, here's the log from when it starts configuring PKI: > > 2014-04-28T15:23:45Z DEBUG [2/22]: configuring certificate server > instance > 2014-04-28T15:23:45Z DEBUG Contents of pkispawn configuration file > (/tmp/tmpdCm6rt): > [CA] > pki_security_domain_name = IPA > pki_enable_proxy = True > pki_restart_configured_instance = False > pki_backup_keys = True > pki-backup_password = XXXXXXXX > pki_client_database_dir = /tmp/tmp-rVoTR2 > pki_client_database_password = XXXXXXXX > pki_client_database_purge = False > pki_client_pkcs12_password = XXXXXXXX > pki_admin_name = admin > pki_admin_uid = admin > pki_admin_email = root at localhost > pki_admin_password = XXXXXXXX > pki_admin_nickname = ipa-ca-agent > pki_admin_subject_dn = cn=ipa-ca-agent,O=FOO.NET > pki_client_admin_cert_p12 = /root/ca-agent.p12 > pki_ds_ldap_port = 389 > pki_ds_password = XXXXXXXX > pki_ds_base_dn = o=ipaca > pki_ds_database = ipaca > pki_subsystem_subject+dn = cn=CA Subsystem,O=FOO.NET > pki_ocsp_signing_subject_dn = cn=OCSP Subsystem,O=FOO.NET > pki_ssl_server_subject_dn = cn=zsipa.foo.net,O=FOO.NET > pki_audit_signing_subject_dn = cn=CA Audit,O=FOO.NET > pki_ca_signing_subject_dn = cn-Certificate Authority,O=FOO.NET > pki_subsystem_nickname = subsystemCert cert-pki-ca > pki_ocsp_signing_nickname = ocspSigningCert cert-pki-ca > pki_ssl_server_nickname = Server-Cert cert-pki-ca > pki_audit_signing_nickname = auditSigningCert cert-pki-ca > pki_ca_signing_nickname = caSigningCert cert-pki-ca > > > 2014-04-28T15:23:45Z DEBUG Starting external process > 2014-04-28T15:23:45Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpdCm6rt > 2014-04-28T15:23:45Z DEBUG Process finished, return code=1 > 2014-04-28T15:23:45Z DEBUG stdout=Loading deployment configuration from > /tmp/tmpdCm6rt. > Installing CA into /var/lib/pki/pki-tomcat. > Storing deployment configuration into > /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg > > Installation failed. > > > 2014-04-28T15:24:46Z DEBUG stderr=pkispawn : ERROR ....... server > failed to restart > > 2014-04-28T15:24:46Z CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmpdCm6rt' returned non-zero exit > status 1 > 2014-04-28T15:24:46Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 622, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-server-install", line 1074, in main > dm_password, subject_base=options.subject) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 478, in configure_instance > self.start_creation(runtime=210) > > File "/usr/lib/python2.7/site-packages/ipaserver/isntall/service.py", > line 364, in start_creation > method() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 604, in __spawn_instance > raise RUntimeError('Configuration of CA failed') > > > 2014-04-28T15:24:46Z DEBUG The ipa-server-install command failed, > exception: RuntimeError: Configuration of CA failed > > And that's the end of the log. Nothing here looks terribly informative > to me, and this is what the log looks like every time I look at it. > The error is different whether there is an existing PKI instance or not. The next set of logs to look at are in /var/log/pki. It says there is a startup failure so I'd start with /var/log/pki/pki-tomcat/catalina.out . Also interesting may be the pki-ca-spawn and debug logs found within that directory structure. I'd also look for SELinux errors with ausearch -m AVC -ts recent rob From bret.wortman at damascusgrp.com Mon Apr 28 16:07:26 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 28 Apr 2014 12:07:26 -0400 Subject: [Freeipa-users] Error creating new freeipa-server In-Reply-To: <535E7947.6010901@redhat.com> References: <535E4104.1040509@damascusgrp.com> <535E4A9A.4000302@redhat.com> <535E63FF.7050401@damascusgrp.com> <535E654F.5070802@damascusgrp.com> <535E6A53.5030701@redhat.com> <535E6EF7.8090100@damascusgrp.com> <535E7116.9000903@redhat.com> <535E775E.6030806@damascusgrp.com> <535E7947.6010901@redhat.com> Message-ID: <535E7CBE.30102@damascusgrp.com> On 04/28/2014 11:52 AM, Rob Crittenden wrote: > Bret Wortman wrote: >> >> On 04/28/2014 11:17 AM, Rob Crittenden wrote: >>> Bret Wortman wrote: >>>> So is there a recommended way to clean it up and get it working? >>> >>> Re-run pkidestroy, then if the subsequent IPA install fails closely >>> examine the logs to determine the reason. The problem in cases like >>> this is that the first install fails and subsequent installs mask the >>> original failure with this PKI re-install failure. >>> >>> rob >>> >> Okay, here's the log from when it starts configuring PKI: >> >> 2014-04-28T15:23:45Z DEBUG [2/22]: configuring certificate server >> instance >> 2014-04-28T15:23:45Z DEBUG Contents of pkispawn configuration file >> (/tmp/tmpdCm6rt): >> [CA] >> pki_security_domain_name = IPA >> pki_enable_proxy = True >> pki_restart_configured_instance = False >> pki_backup_keys = True >> pki-backup_password = XXXXXXXX >> pki_client_database_dir = /tmp/tmp-rVoTR2 >> pki_client_database_password = XXXXXXXX >> pki_client_database_purge = False >> pki_client_pkcs12_password = XXXXXXXX >> pki_admin_name = admin >> pki_admin_uid = admin >> pki_admin_email = root at localhost >> pki_admin_password = XXXXXXXX >> pki_admin_nickname = ipa-ca-agent >> pki_admin_subject_dn = cn=ipa-ca-agent,O=FOO.NET >> pki_client_admin_cert_p12 = /root/ca-agent.p12 >> pki_ds_ldap_port = 389 >> pki_ds_password = XXXXXXXX >> pki_ds_base_dn = o=ipaca >> pki_ds_database = ipaca >> pki_subsystem_subject+dn = cn=CA Subsystem,O=FOO.NET >> pki_ocsp_signing_subject_dn = cn=OCSP Subsystem,O=FOO.NET >> pki_ssl_server_subject_dn = cn=zsipa.foo.net,O=FOO.NET >> pki_audit_signing_subject_dn = cn=CA Audit,O=FOO.NET >> pki_ca_signing_subject_dn = cn-Certificate Authority,O=FOO.NET >> pki_subsystem_nickname = subsystemCert cert-pki-ca >> pki_ocsp_signing_nickname = ocspSigningCert cert-pki-ca >> pki_ssl_server_nickname = Server-Cert cert-pki-ca >> pki_audit_signing_nickname = auditSigningCert cert-pki-ca >> pki_ca_signing_nickname = caSigningCert cert-pki-ca >> >> >> 2014-04-28T15:23:45Z DEBUG Starting external process >> 2014-04-28T15:23:45Z DEBUG args=/usr/sbin/pkispawn -s CA -f >> /tmp/tmpdCm6rt >> 2014-04-28T15:23:45Z DEBUG Process finished, return code=1 >> 2014-04-28T15:23:45Z DEBUG stdout=Loading deployment configuration from >> /tmp/tmpdCm6rt. >> Installing CA into /var/lib/pki/pki-tomcat. >> Storing deployment configuration into >> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg >> >> Installation failed. >> >> >> 2014-04-28T15:24:46Z DEBUG stderr=pkispawn : ERROR ....... server >> failed to restart >> >> 2014-04-28T15:24:46Z CRITICAL failed to configure ca instance Command >> '/usr/sbin/pkispawn -s CA -f /tmp/tmpdCm6rt' returned non-zero exit >> status 1 >> 2014-04-28T15:24:46Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 622, in run_script >> return_value = main_function() >> >> File "/usr/sbin/ipa-server-install", line 1074, in main >> dm_password, subject_base=options.subject) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >> 478, in configure_instance >> self.start_creation(runtime=210) >> >> File "/usr/lib/python2.7/site-packages/ipaserver/isntall/service.py", >> line 364, in start_creation >> method() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >> 604, in __spawn_instance >> raise RUntimeError('Configuration of CA failed') >> >> >> 2014-04-28T15:24:46Z DEBUG The ipa-server-install command failed, >> exception: RuntimeError: Configuration of CA failed >> >> And that's the end of the log. Nothing here looks terribly informative >> to me, and this is what the log looks like every time I look at it. >> > > The error is different whether there is an existing PKI instance or not. > > The next set of logs to look at are in /var/log/pki. It says there is > a startup failure so I'd start with > */var/log/pki/pki-tomcat/catalina.out* . Also interesting may be the > pki-ca-spawn and debug logs found within that directory structure. > > I'd also look for SELinux errors with ausearch -m AVC -ts recent This did the trick. Something was hanging out on port 8443, though neither lsof nor netstat would show me what it was. I rebooted the server and then it proceeded past this without a hiccup. Thanks, Rob and everyone else for helping me navigate the logs! Bret -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From simon.williams at thehelpfulcat.com Mon Apr 28 16:34:27 2014 From: simon.williams at thehelpfulcat.com (Simon Williams) Date: Mon, 28 Apr 2014 17:34:27 +0100 Subject: [Freeipa-users] Google Apps Directory Sync and Free-IPA In-Reply-To: <1398695563.10424.48.camel@willson.li.ssimo.org> References: <535E46C6.2070004@redhat.com> <535E4899.5070503@redhat.com> <1398695563.10424.48.camel@willson.li.ssimo.org> Message-ID: I do have it working, but I have Atlassian Crowd sitting between FreeIPA and the Google Apps log in. On 28 Apr 2014 15:44, "Simo Sorce" wrote: > On Mon, 2014-04-28 at 08:24 -0400, Dmitri Pal wrote: > > On 04/28/2014 08:22 AM, Chris Whittle wrote: > > > Ha! that was my thread about SAML vs GADS but there ended up not being > > > any info on how to actually use GADS with Free IPA. It dropped after > > > Simo saying he was going to work on getting docs for ipsilon (which > > > from the conversation and I can gather is basically SAML) and I asked > > > for someone who had experience with GADS so I started a new one for > > > simplification. > > > > I do not think we have a better answer for you other than what Martin > > mentioned and SAML IdP Simo is working on. > > note that any other SAML IdP that has support for LDAP may work, for > example http://picketlink.org/ may work for you if you have experience > in setting up jboss based applications and know how to make your way in > configuring such software. (I can't help here really). > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Mon Apr 28 17:19:44 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 28 Apr 2014 13:19:44 -0400 Subject: [Freeipa-users] Can't use "ipa" commands on brand new ipa server instance Message-ID: <535E8DB0.4050302@damascusgrp.com> I just got a new ipa server instantiated and haven't actually installed any users or hosts on it yet. No replicas. No migrated data. Yet when I run any "ipa" commands from the command line, it behaves exactly as our older, troubled servers do and exits the login session immediately, whether I'm connected at the console or via ssh. Further, when I run strace to try to capture what might be going on, the behavior stops. "Script" also prevents commands from exiting, but this is really disconcerting. I was chalking this up to the fact that our database had become corrupted by our replication problems, but now I'm thinking it might be environmental, though our original IPA servers are running F18 and this new instance is F20. I need some stability here, and CLI is part of that. What might be causing the CLI to not work at all when coupled to a TTY device, as that seems to be the critical piece? Could this be related to the servers being VMs? -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 51f7de33e4b08d2bdb8b4860 Type: image/png Size: 28526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From bret.wortman at damascusgrp.com Mon Apr 28 17:25:04 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 28 Apr 2014 13:25:04 -0400 Subject: [Freeipa-users] Can't use "ipa" commands on brand new ipa server instance In-Reply-To: <535E8DB0.4050302@damascusgrp.com> References: <535E8DB0.4050302@damascusgrp.com> Message-ID: <535E8EF0.9040606@damascusgrp.com> On 04/28/2014 01:19 PM, Bret Wortman wrote: > I just got a new ipa server instantiated and haven't actually > installed any users or hosts on it yet. No replicas. No migrated data. > > Yet when I run any "ipa" commands from the command line, it behaves > exactly as our older, troubled servers do and exits the login session > immediately, whether I'm connected at the console or via ssh. Further, > when I run strace to try to capture what might be going on, the > behavior stops. "Script" also prevents commands from exiting, but this > is really disconcerting. I was chalking this up to the fact that our > database had become corrupted by our replication problems, but now I'm > thinking it might be environmental, though our original IPA servers > are running F18 and this new instance is F20. > > I need some stability here, and CLI is part of that. What might be > causing the CLI to not work at all when coupled to a TTY device, as > that seems to be the critical piece? Could this be related to the > servers being VMs? > BTW, we have this running on F20 on a different network and it works just fine. The network on which the failures are occurring isn't internet-connected; is there something that's trying to connect back to redhat? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From simo at redhat.com Mon Apr 28 17:32:36 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 28 Apr 2014 13:32:36 -0400 Subject: [Freeipa-users] Can't use "ipa" commands on brand new ipa server instance In-Reply-To: <535E8EF0.9040606@damascusgrp.com> References: <535E8DB0.4050302@damascusgrp.com> <535E8EF0.9040606@damascusgrp.com> Message-ID: <1398706356.10424.64.camel@willson.li.ssimo.org> On Mon, 2014-04-28 at 13:25 -0400, Bret Wortman wrote: > On 04/28/2014 01:19 PM, Bret Wortman wrote: > > I just got a new ipa server instantiated and haven't actually > > installed any users or hosts on it yet. No replicas. No migrated data. > > > > Yet when I run any "ipa" commands from the command line, it behaves > > exactly as our older, troubled servers do and exits the login session > > immediately, whether I'm connected at the console or via ssh. Further, > > when I run strace to try to capture what might be going on, the > > behavior stops. "Script" also prevents commands from exiting, but this > > is really disconcerting. I was chalking this up to the fact that our > > database had become corrupted by our replication problems, but now I'm > > thinking it might be environmental, though our original IPA servers > > are running F18 and this new instance is F20. > > > > I need some stability here, and CLI is part of that. What might be > > causing the CLI to not work at all when coupled to a TTY device, as > > that seems to be the critical piece? Could this be related to the > > servers being VMs? > > > BTW, we have this running on F20 on a different network and it works > just fine. The network on which the failures are occurring isn't > internet-connected; is there something that's trying to connect back to > redhat? no. What shell do you use ? Simo. -- Simo Sorce * Red Hat, Inc * New York From bret.wortman at damascusgrp.com Mon Apr 28 17:43:09 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 28 Apr 2014 13:43:09 -0400 Subject: [Freeipa-users] Can't use "ipa" commands on brand new ipa server instance In-Reply-To: <1398706356.10424.64.camel@willson.li.ssimo.org> References: <535E8DB0.4050302@damascusgrp.com> <535E8EF0.9040606@damascusgrp.com> <1398706356.10424.64.camel@willson.li.ssimo.org> Message-ID: <535E932D.40703@damascusgrp.com> bash. On 04/28/2014 01:32 PM, Simo Sorce wrote: > On Mon, 2014-04-28 at 13:25 -0400, Bret Wortman wrote: >> On 04/28/2014 01:19 PM, Bret Wortman wrote: >>> I just got a new ipa server instantiated and haven't actually >>> installed any users or hosts on it yet. No replicas. No migrated data. >>> >>> Yet when I run any "ipa" commands from the command line, it behaves >>> exactly as our older, troubled servers do and exits the login session >>> immediately, whether I'm connected at the console or via ssh. Further, >>> when I run strace to try to capture what might be going on, the >>> behavior stops. "Script" also prevents commands from exiting, but this >>> is really disconcerting. I was chalking this up to the fact that our >>> database had become corrupted by our replication problems, but now I'm >>> thinking it might be environmental, though our original IPA servers >>> are running F18 and this new instance is F20. >>> >>> I need some stability here, and CLI is part of that. What might be >>> causing the CLI to not work at all when coupled to a TTY device, as >>> that seems to be the critical piece? Could this be related to the >>> servers being VMs? >>> >> BTW, we have this running on F20 on a different network and it works >> just fine. The network on which the failures are occurring isn't >> internet-connected; is there something that's trying to connect back to >> redhat? > no. > > What shell do you use ? > > Simo. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Mon Apr 28 17:46:13 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 28 Apr 2014 13:46:13 -0400 Subject: [Freeipa-users] Can't use "ipa" commands on brand new ipa server instance In-Reply-To: <535E8EF0.9040606@damascusgrp.com> References: <535E8DB0.4050302@damascusgrp.com> <535E8EF0.9040606@damascusgrp.com> Message-ID: <535E93E5.2060102@redhat.com> On 04/28/2014 01:25 PM, Bret Wortman wrote: > > On 04/28/2014 01:19 PM, Bret Wortman wrote: >> I just got a new ipa server instantiated and haven't actually >> installed any users or hosts on it yet. No replicas. No migrated data. >> >> Yet when I run any "ipa" commands from the command line, it behaves >> exactly as our older, troubled servers do and exits the login session >> immediately, whether I'm connected at the console or via ssh. >> Further, when I run strace to try to capture what might be going on, >> the behavior stops. "Script" also prevents commands from exiting, but >> this is really disconcerting. I was chalking this up to the fact that >> our database had become corrupted by our replication problems, but >> now I'm thinking it might be environmental, though our original IPA >> servers are running F18 and this new instance is F20. >> >> I need some stability here, and CLI is part of that. What might be >> causing the CLI to not work at all when coupled to a TTY device, as >> that seems to be the critical piece? Could this be related to the >> servers being VMs? >> > BTW, we have this running on F20 on a different network and it works > just fine. The network on which the failures are occurring isn't > internet-connected; is there something that's trying to connect back > to redhat? > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users No but i wonder what your DNS setup is? If it is a different subnet can it be that it sees some other Kerberos and/or LDAP server (AD for example) and gets confused? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Apr 28 17:53:17 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 28 Apr 2014 13:53:17 -0400 Subject: [Freeipa-users] Can't use "ipa" commands on brand new ipa server instance In-Reply-To: <535E932D.40703@damascusgrp.com> References: <535E8DB0.4050302@damascusgrp.com> <535E8EF0.9040606@damascusgrp.com> <1398706356.10424.64.camel@willson.li.ssimo.org> <535E932D.40703@damascusgrp.com> Message-ID: <1398707597.10424.68.camel@willson.li.ssimo.org> > On 04/28/2014 01:32 PM, Simo Sorce wrote: > > On Mon, 2014-04-28 at 13:25 -0400, Bret Wortman wrote: > >> On 04/28/2014 01:19 PM, Bret Wortman wrote: > >>> I just got a new ipa server instantiated and haven't actually > >>> installed any users or hosts on it yet. No replicas. No migrated data. > >>> > >>> Yet when I run any "ipa" commands from the command line, it behaves > >>> exactly as our older, troubled servers do and exits the login session > >>> immediately, whether I'm connected at the console or via ssh. Further, > >>> when I run strace to try to capture what might be going on, the > >>> behavior stops. "Script" also prevents commands from exiting, but this > >>> is really disconcerting. I was chalking this up to the fact that our > >>> database had become corrupted by our replication problems, but now I'm > >>> thinking it might be environmental, though our original IPA servers > >>> are running F18 and this new instance is F20. > >>> > >>> I need some stability here, and CLI is part of that. What might be > >>> causing the CLI to not work at all when coupled to a TTY device, as > >>> that seems to be the critical piece? Could this be related to the > >>> servers being VMs? > >>> > >> BTW, we have this running on F20 on a different network and it works > >> just fine. The network on which the failures are occurring isn't > >> internet-connected; is there something that's trying to connect back to > >> redhat? > > no. > > > > What shell do you use ? On Mon, 2014-04-28 at 13:43 -0400, Bret Wortman wrote: > bash. Does it make any difference if you redirect stdin before calling the command ? Simo. -- Simo Sorce * Red Hat, Inc * New York From bret.wortman at damascusgrp.com Mon Apr 28 18:05:23 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 28 Apr 2014 14:05:23 -0400 Subject: [Freeipa-users] Can't use "ipa" commands on brand new ipa server instance In-Reply-To: <1398707597.10424.68.camel@willson.li.ssimo.org> References: <535E8DB0.4050302@damascusgrp.com> <535E8EF0.9040606@damascusgrp.com> <1398706356.10424.64.camel@willson.li.ssimo.org> <535E932D.40703@damascusgrp.com> <1398707597.10424.68.camel@willson.li.ssimo.org> Message-ID: <535E9863.7070509@damascusgrp.com> On 04/28/2014 01:53 PM, Simo Sorce wrote: >> On 04/28/2014 01:32 PM, Simo Sorce wrote: >>> On Mon, 2014-04-28 at 13:25 -0400, Bret Wortman wrote: >>>> On 04/28/2014 01:19 PM, Bret Wortman wrote: >>>>> I just got a new ipa server instantiated and haven't actually >>>>> installed any users or hosts on it yet. No replicas. No migrated data. >>>>> >>>>> Yet when I run any "ipa" commands from the command line, it behaves >>>>> exactly as our older, troubled servers do and exits the login session >>>>> immediately, whether I'm connected at the console or via ssh. Further, >>>>> when I run strace to try to capture what might be going on, the >>>>> behavior stops. "Script" also prevents commands from exiting, but this >>>>> is really disconcerting. I was chalking this up to the fact that our >>>>> database had become corrupted by our replication problems, but now I'm >>>>> thinking it might be environmental, though our original IPA servers >>>>> are running F18 and this new instance is F20. >>>>> >>>>> I need some stability here, and CLI is part of that. What might be >>>>> causing the CLI to not work at all when coupled to a TTY device, as >>>>> that seems to be the critical piece? Could this be related to the >>>>> servers being VMs? >>>>> >>>> BTW, we have this running on F20 on a different network and it works >>>> just fine. The network on which the failures are occurring isn't >>>> internet-connected; is there something that's trying to connect back to >>>> redhat? >>> no. >>> >>> What shell do you use ? > On Mon, 2014-04-28 at 13:43 -0400, Bret Wortman wrote: >> bash. > Does it make any difference if you redirect stdin before calling the > command ? > > Simo. > No, I found the problem. A "power" user had written a bash function that redefined "ipa" and dropped it into /etc/profile.d. We're about to have a little chat. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From simo at redhat.com Mon Apr 28 18:10:08 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 28 Apr 2014 14:10:08 -0400 Subject: [Freeipa-users] Can't use "ipa" commands on brand new ipa server instance In-Reply-To: <535E9863.7070509@damascusgrp.com> References: <535E8DB0.4050302@damascusgrp.com> <535E8EF0.9040606@damascusgrp.com> <1398706356.10424.64.camel@willson.li.ssimo.org> <535E932D.40703@damascusgrp.com> <1398707597.10424.68.camel@willson.li.ssimo.org> <535E9863.7070509@damascusgrp.com> Message-ID: <1398708608.10424.71.camel@willson.li.ssimo.org> On Mon, 2014-04-28 at 14:05 -0400, Bret Wortman wrote: > On 04/28/2014 01:53 PM, Simo Sorce wrote: > >> On 04/28/2014 01:32 PM, Simo Sorce wrote: > >>> On Mon, 2014-04-28 at 13:25 -0400, Bret Wortman wrote: > >>>> On 04/28/2014 01:19 PM, Bret Wortman wrote: > >>>>> I just got a new ipa server instantiated and haven't actually > >>>>> installed any users or hosts on it yet. No replicas. No migrated data. > >>>>> > >>>>> Yet when I run any "ipa" commands from the command line, it behaves > >>>>> exactly as our older, troubled servers do and exits the login session > >>>>> immediately, whether I'm connected at the console or via ssh. Further, > >>>>> when I run strace to try to capture what might be going on, the > >>>>> behavior stops. "Script" also prevents commands from exiting, but this > >>>>> is really disconcerting. I was chalking this up to the fact that our > >>>>> database had become corrupted by our replication problems, but now I'm > >>>>> thinking it might be environmental, though our original IPA servers > >>>>> are running F18 and this new instance is F20. > >>>>> > >>>>> I need some stability here, and CLI is part of that. What might be > >>>>> causing the CLI to not work at all when coupled to a TTY device, as > >>>>> that seems to be the critical piece? Could this be related to the > >>>>> servers being VMs? > >>>>> > >>>> BTW, we have this running on F20 on a different network and it works > >>>> just fine. The network on which the failures are occurring isn't > >>>> internet-connected; is there something that's trying to connect back to > >>>> redhat? > >>> no. > >>> > >>> What shell do you use ? > > On Mon, 2014-04-28 at 13:43 -0400, Bret Wortman wrote: > >> bash. > > Does it make any difference if you redirect stdin before calling the > > command ? > > > > Simo. > > > No, I found the problem. A "power" user had written a bash function that > redefined "ipa" and dropped it into /etc/profile.d. We're about to have > a little chat. lol! glad you found it :) Simo. -- Simo Sorce * Red Hat, Inc * New York From bill at pecknet.com Mon Apr 28 19:31:46 2014 From: bill at pecknet.com (Bill Peck) Date: Mon, 28 Apr 2014 15:31:46 -0400 Subject: [Freeipa-users] Can't use "ipa" commands on brand new ipa server instance In-Reply-To: <1398708608.10424.71.camel@willson.li.ssimo.org> References: <535E8DB0.4050302@damascusgrp.com> <535E8EF0.9040606@damascusgrp.com> <1398706356.10424.64.camel@willson.li.ssimo.org> <535E932D.40703@damascusgrp.com> <1398707597.10424.68.camel@willson.li.ssimo.org> <535E9863.7070509@damascusgrp.com> <1398708608.10424.71.camel@willson.li.ssimo.org> Message-ID: Let me guess, ipa logs you out so you can go have a beer? On Mon, Apr 28, 2014 at 2:10 PM, Simo Sorce wrote: > On Mon, 2014-04-28 at 14:05 -0400, Bret Wortman wrote: > > On 04/28/2014 01:53 PM, Simo Sorce wrote: > > >> On 04/28/2014 01:32 PM, Simo Sorce wrote: > > >>> On Mon, 2014-04-28 at 13:25 -0400, Bret Wortman wrote: > > >>>> On 04/28/2014 01:19 PM, Bret Wortman wrote: > > >>>>> I just got a new ipa server instantiated and haven't actually > > >>>>> installed any users or hosts on it yet. No replicas. No migrated > data. > > >>>>> > > >>>>> Yet when I run any "ipa" commands from the command line, it behaves > > >>>>> exactly as our older, troubled servers do and exits the login > session > > >>>>> immediately, whether I'm connected at the console or via ssh. > Further, > > >>>>> when I run strace to try to capture what might be going on, the > > >>>>> behavior stops. "Script" also prevents commands from exiting, but > this > > >>>>> is really disconcerting. I was chalking this up to the fact that > our > > >>>>> database had become corrupted by our replication problems, but now > I'm > > >>>>> thinking it might be environmental, though our original IPA servers > > >>>>> are running F18 and this new instance is F20. > > >>>>> > > >>>>> I need some stability here, and CLI is part of that. What might be > > >>>>> causing the CLI to not work at all when coupled to a TTY device, as > > >>>>> that seems to be the critical piece? Could this be related to the > > >>>>> servers being VMs? > > >>>>> > > >>>> BTW, we have this running on F20 on a different network and it works > > >>>> just fine. The network on which the failures are occurring isn't > > >>>> internet-connected; is there something that's trying to connect > back to > > >>>> redhat? > > >>> no. > > >>> > > >>> What shell do you use ? > > > On Mon, 2014-04-28 at 13:43 -0400, Bret Wortman wrote: > > >> bash. > > > Does it make any difference if you redirect stdin before calling the > > > command ? > > > > > > Simo. > > > > > No, I found the problem. A "power" user had written a bash function that > > redefined "ipa" and dropped it into /etc/profile.d. We're about to have > > a little chat. > > lol! > > glad you found it :) > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Mon Apr 28 20:19:30 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 28 Apr 2014 16:19:30 -0400 Subject: [Freeipa-users] Can't use "ipa" commands on brand new ipa server instance In-Reply-To: References: <535E8DB0.4050302@damascusgrp.com> <535E8EF0.9040606@damascusgrp.com> <1398706356.10424.64.camel@willson.li.ssimo.org> <535E932D.40703@damascusgrp.com> <1398707597.10424.68.camel@willson.li.ssimo.org> <535E9863.7070509@damascusgrp.com> <1398708608.10424.71.camel@willson.li.ssimo.org> Message-ID: <535EB7D2.5090605@damascusgrp.com> Oh, I like that idea. A lot. On 04/28/2014 03:31 PM, Bill Peck wrote: > Let me guess, ipa logs you out so you can go have a beer? > > > On Mon, Apr 28, 2014 at 2:10 PM, Simo Sorce > wrote: > > On Mon, 2014-04-28 at 14:05 -0400, Bret Wortman wrote: > > On 04/28/2014 01:53 PM, Simo Sorce wrote: > > >> On 04/28/2014 01:32 PM, Simo Sorce wrote: > > >>> On Mon, 2014-04-28 at 13:25 -0400, Bret Wortman wrote: > > >>>> On 04/28/2014 01:19 PM, Bret Wortman wrote: > > >>>>> I just got a new ipa server instantiated and haven't actually > > >>>>> installed any users or hosts on it yet. No replicas. No > migrated data. > > >>>>> > > >>>>> Yet when I run any "ipa" commands from the command line, > it behaves > > >>>>> exactly as our older, troubled servers do and exits the > login session > > >>>>> immediately, whether I'm connected at the console or via > ssh. Further, > > >>>>> when I run strace to try to capture what might be going > on, the > > >>>>> behavior stops. "Script" also prevents commands from > exiting, but this > > >>>>> is really disconcerting. I was chalking this up to the > fact that our > > >>>>> database had become corrupted by our replication problems, > but now I'm > > >>>>> thinking it might be environmental, though our original > IPA servers > > >>>>> are running F18 and this new instance is F20. > > >>>>> > > >>>>> I need some stability here, and CLI is part of that. What > might be > > >>>>> causing the CLI to not work at all when coupled to a TTY > device, as > > >>>>> that seems to be the critical piece? Could this be related > to the > > >>>>> servers being VMs? > > >>>>> > > >>>> BTW, we have this running on F20 on a different network and > it works > > >>>> just fine. The network on which the failures are occurring > isn't > > >>>> internet-connected; is there something that's trying to > connect back to > > >>>> redhat? > > >>> no. > > >>> > > >>> What shell do you use ? > > > On Mon, 2014-04-28 at 13:43 -0400, Bret Wortman wrote: > > >> bash. > > > Does it make any difference if you redirect stdin before > calling the > > > command ? > > > > > > Simo. > > > > > No, I found the problem. A "power" user had written a bash > function that > > redefined "ipa" and dropped it into /etc/profile.d. We're about > to have > > a little chat. > > lol! > > glad you found it :) > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From cwhittl at gmail.com Mon Apr 28 20:47:27 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Mon, 28 Apr 2014 15:47:27 -0500 Subject: [Freeipa-users] Google Apps Directory Sync and Free-IPA In-Reply-To: References: <535E46C6.2070004@redhat.com> <535E4899.5070503@redhat.com> <1398695563.10424.48.camel@willson.li.ssimo.org> Message-ID: Thanks Simon I'm not sure it'll work for what I need.... I really wish someone had Google Apps Directory Sync either working or not working so I can either research more or strike it off my list On Mon, Apr 28, 2014 at 11:34 AM, Simon Williams < simon.williams at thehelpfulcat.com> wrote: > I do have it working, but I have Atlassian Crowd sitting between FreeIPA > and the Google Apps log in. > On 28 Apr 2014 15:44, "Simo Sorce" wrote: > >> On Mon, 2014-04-28 at 08:24 -0400, Dmitri Pal wrote: >> > On 04/28/2014 08:22 AM, Chris Whittle wrote: >> > > Ha! that was my thread about SAML vs GADS but there ended up not being >> > > any info on how to actually use GADS with Free IPA. It dropped after >> > > Simo saying he was going to work on getting docs for ipsilon (which >> > > from the conversation and I can gather is basically SAML) and I asked >> > > for someone who had experience with GADS so I started a new one for >> > > simplification. >> > >> > I do not think we have a better answer for you other than what Martin >> > mentioned and SAML IdP Simo is working on. >> >> note that any other SAML IdP that has support for LDAP may work, for >> example http://picketlink.org/ may work for you if you have experience >> in setting up jboss based applications and know how to make your way in >> configuring such software. (I can't help here really). >> >> Simo. >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Tue Apr 29 02:34:42 2014 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 29 Apr 2014 02:34:42 +0000 Subject: [Freeipa-users] RHEL7 rc 64bit In-Reply-To: <535E9863.7070509@damascusgrp.com> References: <535E8DB0.4050302@damascusgrp.com> <535E8EF0.9040606@damascusgrp.com> <1398706356.10424.64.camel@willson.li.ssimo.org> <535E932D.40703@damascusgrp.com> <1398707597.10424.68.camel@willson.li.ssimo.org>, <535E9863.7070509@damascusgrp.com> Message-ID: <1398738881766.69636@vuw.ac.nz> Hi, Would it be expected that a RHEL7rc machine would be connectible to IPA on RHEL6.5? Just tried and it doesnt seem to be. regards Steven Jones Technical Specialist - Linux RHCE Victoria University ITS, Level 8 Rankin Brown Building, Wellington, NZ 6012 0064 4 463 6272 From pspacek at redhat.com Tue Apr 29 07:06:48 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 29 Apr 2014 09:06:48 +0200 Subject: [Freeipa-users] [SOLVED] Can't use "ipa" commands on brand new ipa server instance In-Reply-To: <535E9863.7070509@damascusgrp.com> References: <535E8DB0.4050302@damascusgrp.com> <535E8EF0.9040606@damascusgrp.com> <1398706356.10424.64.camel@willson.li.ssimo.org> <535E932D.40703@damascusgrp.com> <1398707597.10424.68.camel@willson.li.ssimo.org> <535E9863.7070509@damascusgrp.com> Message-ID: <535F4F88.9010601@redhat.com> On 28.4.2014 20:05, Bret Wortman wrote: > On 04/28/2014 01:53 PM, Simo Sorce wrote: >>> On 04/28/2014 01:32 PM, Simo Sorce wrote: >>>> On Mon, 2014-04-28 at 13:25 -0400, Bret Wortman wrote: >>>>> On 04/28/2014 01:19 PM, Bret Wortman wrote: >>>>>> I just got a new ipa server instantiated and haven't actually >>>>>> installed any users or hosts on it yet. No replicas. No migrated data. >>>>>> >>>>>> Yet when I run any "ipa" commands from the command line, it behaves >>>>>> exactly as our older, troubled servers do and exits the login session >>>>>> immediately, whether I'm connected at the console or via ssh. Further, >>>>>> when I run strace to try to capture what might be going on, the >>>>>> behavior stops. "Script" also prevents commands from exiting, but this >>>>>> is really disconcerting. I was chalking this up to the fact that our >>>>>> database had become corrupted by our replication problems, but now I'm >>>>>> thinking it might be environmental, though our original IPA servers >>>>>> are running F18 and this new instance is F20. >>>>>> >>>>>> I need some stability here, and CLI is part of that. What might be >>>>>> causing the CLI to not work at all when coupled to a TTY device, as >>>>>> that seems to be the critical piece? Could this be related to the >>>>>> servers being VMs? >>>>>> >>>>> BTW, we have this running on F20 on a different network and it works >>>>> just fine. The network on which the failures are occurring isn't >>>>> internet-connected; is there something that's trying to connect back to >>>>> redhat? >>>> no. >>>> >>>> What shell do you use ? >> On Mon, 2014-04-28 at 13:43 -0400, Bret Wortman wrote: >>> bash. >> Does it make any difference if you redirect stdin before calling the >> command ? >> >> Simo. > No, I found the problem. A "power" user had written a bash function that > redefined "ipa" and dropped it into /etc/profile.d. We're about to have a > little chat. To sum it up for people coming from search engines: It is not a FreeIPA problem, it is pure PEBKAC [0] :-) [0] http://en.wikipedia.org/wiki/User_error#PEBKAC -- Petr^2 Spacek From lincoln.fessenden at jefferson.edu Tue Apr 29 11:18:35 2014 From: lincoln.fessenden at jefferson.edu (Lincoln Fessenden) Date: Tue, 29 Apr 2014 07:18:35 -0400 Subject: [Freeipa-users] RHEL7 rc 64bit In-Reply-To: <1398738881766.69636@vuw.ac.nz> References: <535E8DB0.4050302@damascusgrp.com> <535E8EF0.9040606@damascusgrp.com> <1398706356.10424.64.camel@willson.li.ssimo.org> <535E932D.40703@damascusgrp.com> <1398707597.10424.68.camel@willson.li.ssimo.org> <535E9863.7070509@damascusgrp.com> <1398738881766.69636@vuw.ac.nz> Message-ID: <20140429111833.GA8896@lcf004.edison.tju.edu> It worked for me in testing. On Tue, Apr 29, 2014 at 02:34:42AM +0000, Steven Jones wrote: > Hi, > > Would it be expected that a RHEL7rc machine would be connectible to IPA on RHEL6.5? > > Just tried and it doesnt seem to be. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University ITS, > > Level 8 Rankin Brown Building, > > Wellington, NZ > > 6012 > > 0064 4 463 6272 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Lincoln Fessenden Jeff-IT Production Operations Manager Senior Linux Systems Administrator 215-503-0986 The information contained in this transmission contains privileged and confidential information. It is intended only for the use of the person named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CAUTION: Intended recipients should NOT use email communication for emergent or urgent health care matters. From simo at redhat.com Tue Apr 29 12:56:04 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 29 Apr 2014 08:56:04 -0400 Subject: [Freeipa-users] RHEL7 rc 64bit In-Reply-To: <1398738881766.69636@vuw.ac.nz> References: <535E8DB0.4050302@damascusgrp.com> <535E8EF0.9040606@damascusgrp.com> <1398706356.10424.64.camel@willson.li.ssimo.org> <535E932D.40703@damascusgrp.com> <1398707597.10424.68.camel@willson.li.ssimo.org> , <535E9863.7070509@damascusgrp.com> <1398738881766.69636@vuw.ac.nz> Message-ID: <1398776164.10424.77.camel@willson.li.ssimo.org> On Tue, 2014-04-29 at 02:34 +0000, Steven Jones wrote: > Hi, > > Would it be expected that a RHEL7rc machine would be connectible to IPA on RHEL6.5? > > Just tried and it doesnt seem to be. Details please. Simo. -- Simo Sorce * Red Hat, Inc * New York From bret.wortman at damascusgrp.com Tue Apr 29 17:22:25 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 29 Apr 2014 13:22:25 -0400 Subject: [Freeipa-users] Switching a client from one set of IPA servers to another Message-ID: <535FDFD1.9060208@damascusgrp.com> I'd like to test migrating our clients from the old IPA infrastructure to our newer F20-based servers but am having trouble with our first clients. Unenrolling them from the old IPA servers went fine, but when I try to enroll them with the newer ones, the logs report: # ipa-client-install -U --server zsipa.foo.net --domain foo.net --password obscured --mkhomdir --enable-dns-updates LDAP Error: Connect error: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. LDAP Error: Connect error: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. Failed to verify that zsipa.foo.net is an IPA Server. This may mean that the remote server is not up or is not reachable due to network or firewall settings. : : Installation failed. Rolling back changes. IPA client is not configured on this system. # ps aux | grep firewalld| grep -v grep # getenforce Disabled # cat /var/log/ipaclient-install.log : : DEBUG [LDAP server check] DEBUG Verifying that zsipa.foo.net (realm foo.net) is an IPA server DEBUG Init LDAP connection with: ldap://zsipa.foo.net:389 ERROR LDAP Error: Connect error: TLS error -8173:Peer's certificate issuer has been marked as not trusted by the user. DEBUG Discovery result: UNKNOWN_ERROR; server=None, domain=foo.net, kdc=zsipa.foo.net, basedn=None DEBUG Validated servers: DEBUG will use discovered domain: foo.net DEBUG IPA Server not found DEBUG [IPA Discovery] Starting IPA discovery with domain=foo.net, servers=['zsipa.foo.net'], hostname=jsutil.foo.net DEBUG Server and domain forced DEBUG [Kerberos realm search] DEBUG Search DNS for TXT record of _kerberos.foo.net DEBUG DNS record found: DNSResult::name:_kerberos.foo.net.,type:16,class:1,rdata={data:FOO.NET} DEBUG Search DNS for SRV record of _kerberos._udp.foo.net.,type:33,class:1,rdata={priority:0,port:88,weight:100,server:zsipa.foo.net.} DEBUG [LDAP server check] DEBUG Verifying that zsipa.foo.net (realm FOO.NET)is an IPA server DEBUG Init LDAP connection with: ldap://zsipa.foo.net:389 ERROR LDAP Error: Connect error: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. DEBUG Discovery result: UNKNOWN_ERROR; server=None, domain=foo.net, kdc=zsipa.foo.net, basedn=None DEBUG Validated servers: ERROR Failed to verify that zsipa.foo.net is an IPA Server. ERROR This may mean that the remote server is not up or is not reachable due to network or firewall settings. INFO Please make sure the following ports are opened in the firewall settings: TCP: 80, 88, 389 UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that following ports are necessary for ipa-client working properly after enrollment: TCP: 464 UDP: 464, 123 (if NTP enabled) DEBUG (zspia.foo.net: Provided as option) ERROR Installation failed. Rolling back changes. ERROR IPA client is not configured on this system. I removed the timestamps for readability. It seems to me that something from the old version is hanging around and getting in the way, or that something in the setup of the new server isn't quite complete -- which seems more likely, and where should I be looking for the actual cause? Is this a problem with a certificate or with the server not being discoverable? -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From bret.wortman at damascusgrp.com Tue Apr 29 17:40:18 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 29 Apr 2014 13:40:18 -0400 Subject: [Freeipa-users] Switching a client from one set of IPA servers to another In-Reply-To: <535FDFD1.9060208@damascusgrp.com> References: <535FDFD1.9060208@damascusgrp.com> Message-ID: <535FE402.9050508@damascusgrp.com> Crap. Thought I caught this before I sent it. # rm -f /etc/ipa/ca.crt On 04/29/2014 01:22 PM, Bret Wortman wrote: > I'd like to test migrating our clients from the old IPA infrastructure > to our newer F20-based servers but am having trouble with our first > clients. Unenrolling them from the old IPA servers went fine, but when > I try to enroll them with the newer ones, the logs report: > > # ipa-client-install -U --server zsipa.foo.net --domain foo.net > --password obscured --mkhomdir --enable-dns-updates > LDAP Error: Connect error: TLS error -8172:Peer's certificate issuer > has been marked as not trusted by the user. > LDAP Error: Connect error: TLS error -8172:Peer's certificate issuer > has been marked as not trusted by the user. > Failed to verify that zsipa.foo.net is an IPA Server. > This may mean that the remote server is not up or is not reachable due > to network or firewall settings. > : > : > Installation failed. Rolling back changes. > IPA client is not configured on this system. > # ps aux | grep firewalld| grep -v grep > # getenforce > Disabled > # cat /var/log/ipaclient-install.log > : > : > DEBUG [LDAP server check] > DEBUG Verifying that zsipa.foo.net (realm foo.net) is an IPA server > DEBUG Init LDAP connection with: ldap://zsipa.foo.net:389 > ERROR LDAP Error: Connect error: TLS error -8173:Peer's certificate > issuer has been marked as not trusted by the user. > DEBUG Discovery result: UNKNOWN_ERROR; server=None, domain=foo.net, > kdc=zsipa.foo.net, basedn=None > DEBUG Validated servers: > DEBUG will use discovered domain: foo.net > DEBUG IPA Server not found > DEBUG [IPA Discovery] Starting IPA discovery with domain=foo.net, > servers=['zsipa.foo.net'], hostname=jsutil.foo.net > DEBUG Server and domain forced > DEBUG [Kerberos realm search] > DEBUG Search DNS for TXT record of _kerberos.foo.net > DEBUG DNS record found: > DNSResult::name:_kerberos.foo.net.,type:16,class:1,rdata={data:FOO.NET} > DEBUG Search DNS for SRV record of > _kerberos._udp.foo.net.,type:33,class:1,rdata={priority:0,port:88,weight:100,server:zsipa.foo.net.} > DEBUG [LDAP server check] > DEBUG Verifying that zsipa.foo.net (realm FOO.NET)is an IPA server > DEBUG Init LDAP connection with: ldap://zsipa.foo.net:389 > ERROR LDAP Error: Connect error: TLS error -8172:Peer's certificate > issuer has been marked as not trusted by the user. > DEBUG Discovery result: UNKNOWN_ERROR; server=None, domain=foo.net, > kdc=zsipa.foo.net, basedn=None > DEBUG Validated servers: > ERROR Failed to verify that zsipa.foo.net is an IPA Server. > ERROR This may mean that the remote server is not up or is not > reachable due to network or firewall settings. > INFO Please make sure the following ports are opened in the firewall > settings: > TCP: 80, 88, 389 > UDP: 88 (at least one of TCP/UDP ports 88 has to be open) > Also note that following ports are necessary for ipa-client working > properly after enrollment: > TCP: 464 > UDP: 464, 123 (if NTP enabled) > DEBUG (zspia.foo.net: Provided as option) > ERROR Installation failed. Rolling back changes. > ERROR IPA client is not configured on this system. > > I removed the timestamps for readability. > > It seems to me that something from the old version is hanging around > and getting in the way, or that something in the setup of the new > server isn't quite complete -- which seems more likely, and where > should I be looking for the actual cause? Is this a problem with a > certificate or with the server not being discoverable? > > > -- > *Bret Wortman* > > http://damascusgrp.com/ > http://about.me/wortmanbret > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Apr 29 17:38:34 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Apr 2014 13:38:34 -0400 Subject: [Freeipa-users] Switching a client from one set of IPA servers to another In-Reply-To: <535FDFD1.9060208@damascusgrp.com> References: <535FDFD1.9060208@damascusgrp.com> Message-ID: <535FE39A.9000904@redhat.com> Bret Wortman wrote: > I'd like to test migrating our clients from the old IPA infrastructure > to our newer F20-based servers but am having trouble with our first > clients. Unenrolling them from the old IPA servers went fine, but when I > try to enroll them with the newer ones, the logs report: > > # ipa-client-install -U --server zsipa.foo.net --domain foo.net > --password obscured --mkhomdir --enable-dns-updates > LDAP Error: Connect error: TLS error -8172:Peer's certificate issuer has > been marked as not trusted by the user. > LDAP Error: Connect error: TLS error -8172:Peer's certificate issuer has > been marked as not trusted by the user. > Failed to verify that zsipa.foo.net is an IPA Server. > This may mean that the remote server is not up or is not reachable due > to network or firewall settings. > : > : > Installation failed. Rolling back changes. > IPA client is not configured on this system. > # ps aux | grep firewalld| grep -v grep > # getenforce > Disabled > # cat /var/log/ipaclient-install.log > : > : > DEBUG [LDAP server check] > DEBUG Verifying that zsipa.foo.net (realm foo.net) is an IPA server > DEBUG Init LDAP connection with: ldap://zsipa.foo.net:389 > ERROR LDAP Error: Connect error: TLS error -8173:Peer's certificate > issuer has been marked as not trusted by the user. > DEBUG Discovery result: UNKNOWN_ERROR; server=None, domain=foo.net, > kdc=zsipa.foo.net, basedn=None > DEBUG Validated servers: > DEBUG will use discovered domain: foo.net > DEBUG IPA Server not found > DEBUG [IPA Discovery] Starting IPA discovery with domain=foo.net, > servers=['zsipa.foo.net'], hostname=jsutil.foo.net > DEBUG Server and domain forced > DEBUG [Kerberos realm search] > DEBUG Search DNS for TXT record of _kerberos.foo.net > DEBUG DNS record found: > DNSResult::name:_kerberos.foo.net.,type:16,class:1,rdata={data:FOO.NET} > DEBUG Search DNS for SRV record of > _kerberos._udp.foo.net.,type:33,class:1,rdata={priority:0,port:88,weight:100,server:zsipa.foo.net.} > DEBUG [LDAP server check] > DEBUG Verifying that zsipa.foo.net (realm FOO.NET)is an IPA server > DEBUG Init LDAP connection with: ldap://zsipa.foo.net:389 > ERROR LDAP Error: Connect error: TLS error -8172:Peer's certificate > issuer has been marked as not trusted by the user. > DEBUG Discovery result: UNKNOWN_ERROR; server=None, domain=foo.net, > kdc=zsipa.foo.net, basedn=None > DEBUG Validated servers: > ERROR Failed to verify that zsipa.foo.net is an IPA Server. > ERROR This may mean that the remote server is not up or is not reachable > due to network or firewall settings. > INFO Please make sure the following ports are opened in the firewall > settings: > TCP: 80, 88, 389 > UDP: 88 (at least one of TCP/UDP ports 88 has to be open) > Also note that following ports are necessary for ipa-client working > properly after enrollment: > TCP: 464 > UDP: 464, 123 (if NTP enabled) > DEBUG (zspia.foo.net: Provided as option) > ERROR Installation failed. Rolling back changes. > ERROR IPA client is not configured on this system. > > I removed the timestamps for readability. > > It seems to me that something from the old version is hanging around and > getting in the way, or that something in the setup of the new server > isn't quite complete -- which seems more likely, and where should I be > looking for the actual cause? Is this a problem with a certificate or > with the server not being discoverable? You don't say what release the clients are but try removing /etc/ipa/ca.crt. This is fixed in newer releases. rob From Steven.Jones at vuw.ac.nz Tue Apr 29 23:21:30 2014 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 29 Apr 2014 23:21:30 +0000 Subject: [Freeipa-users] RHEL7 rc 64bit In-Reply-To: <1398776164.10424.77.camel@willson.li.ssimo.org> References: <535E8DB0.4050302@damascusgrp.com> <535E8EF0.9040606@damascusgrp.com> <1398706356.10424.64.camel@willson.li.ssimo.org> <535E932D.40703@damascusgrp.com> <1398707597.10424.68.camel@willson.li.ssimo.org> , <535E9863.7070509@damascusgrp.com> <1398738881766.69636@vuw.ac.nz>, <1398776164.10424.77.camel@willson.li.ssimo.org> Message-ID: <1398813690024.6395@vuw.ac.nz> Hi, Problem between keyboard and chair. When joining to the domain I missed a "-" infront of mkhomedir so doesnt create home directories and hence the gui bombs. regards Steven Jones Technical Specialist - Linux RHCE Victoria University ITS, Level 8 Rankin Brown Building, Wellington, NZ 6012 0064 4 463 6272 ________________________________________ From: Simo Sorce Sent: Wednesday, 30 April 2014 12:56 a.m. To: Steven Jones Cc: Freeipa-users at redhat.com Subject: Re: [Freeipa-users] RHEL7 rc 64bit On Tue, 2014-04-29 at 02:34 +0000, Steven Jones wrote: > Hi, > > Would it be expected that a RHEL7rc machine would be connectible to IPA on RHEL6.5? > > Just tried and it doesnt seem to be. Details please. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Apr 30 07:15:52 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 30 Apr 2014 09:15:52 +0200 Subject: [Freeipa-users] Best practices for core servers In-Reply-To: <535E3585.2070903@damascusgrp.com> References: <535E3585.2070903@damascusgrp.com> Message-ID: <5360A328.90903@redhat.com> On 04/28/2014 01:03 PM, Bret Wortman wrote: > We are planning to reconfigure our core Freeipa servers, basically building a > replacement infrastructure and migrating to it. What we're planning right now is > a core of three Freeipa servers each of which has a CA, with as much > distribution of replication as we can manage. I imagine that means one of them > replicates to the other two but am open to other ideas. You can configure them to replica to each other. > For remote locations, we're planning to stand up caching-only DNS servers, as > authenticating back to the main IPA servers works extremely well; it's just DNS > that needs a little help. > > Any thoughts before I start setting these servers (VMs, most likely) up? You may want to read our upstream Deployment Recommendations article, it may save you some bad decisions from the start: http://www.freeipa.org/page/Deployment_Recommendations If we see that we missed anything in this article, it would be great to enhance it. Martin From mkosek at redhat.com Wed Apr 30 07:19:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 30 Apr 2014 09:19:15 +0200 Subject: [Freeipa-users] Hardening freeipa on the internet In-Reply-To: <1398698205.10424.50.camel@willson.li.ssimo.org> References: <535A18A3.1060202@redhat.com> <535A2426.3000908@redhat.com> <535E52B2.2030301@redhat.com> <1398698205.10424.50.camel@willson.li.ssimo.org> Message-ID: <5360A3F3.7010006@redhat.com> On 04/28/2014 05:16 PM, Simo Sorce wrote: > On Mon, 2014-04-28 at 16:11 +0100, Andrew Holway wrote: >>> I realized that you probably want to disable anonymous access to LDAP. It >>> will prevent random strangers to enumerate all users in your database... >> >> This sounds like a bug no? anonymous access to LDAP? > > Historically many Linux and Unix OSs did not authenticate to LDAP to > download POSIX info, so we allow by default to access a lot of the tree > anonymously. > We are in the process of changing how the permissions work in 4.0, and > will contextually close down a lot more of the tree letting the admin > more easily configure access. > > So, no it is not technically a bug, but it is something you want to look > out for as an admin. > > Simo. > Let me just advertise the core feature of upcoming FreeIPA 4.0 which contains re-design of ACIs and permissions in FreeIPA: http://www.freeipa.org/page/V4/Permissions_V2 With this feature, it will be very easy to control visibility of different parts of FreeIPA DIT - i.e. for example allow POSIX user attributes for anonymous bot allow other attributes to authenticated only, same with groups, HBAC rules, ... Martin From artjazz at free.fr Wed Apr 30 09:26:37 2014 From: artjazz at free.fr (artjazz at free.fr) Date: Wed, 30 Apr 2014 11:26:37 +0200 Subject: [Freeipa-users] dse.ldif and dse.ldif.bak are lost Message-ID: <1398849996.5360c1cd0055a@imp.free.fr> Hi, I have 1 ipa master 'ipasrv' and 2 replicas 'iparpl1 iparpl2' installed with --setup-ca option. Since a few days I have an issue with '389 Directory Server' on the master (ipasrv) and on the 2nd replica (iparpl2) with the following messages: The configuration file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif was not restored from backup /etc/dirsrv/slapd-MYINSTANCE/dse.ldif.tmp, error -1 Apr 28 07:38:35 localhost ns-slapd: [28/Apr/2014:15:38:35 +0200] dse - The configuration file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif was not restored from backup /etc/dirsrv/slapd-MYINSTANCE/dse.ldif.bak, error -1 Apr 28 07:38:35 localhost ns-slapd: [28/Apr/2014:15:38:35 +0200] config - The given config file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif could not be accessed, Netscape Portable Runtime error -5950 (File not found.) The files dse.ldif and dse.ldif.bak are lost. On my 1st replica (iparpl1) everything is OK. No Full IPA backup and LDAP backup done on ipasrv and iparpl2. A) Can I restore those files from iparpl1 ? B) I am a little bit confused after reading the documentation on http://www.freeipa.org/page/Backup_and_Restore - can I consider that the ipa replicas are like ipa master ? In this case when I want to execute the manual procedure in chapter 'One Server Loss' 1. Clean deployment from the lost server by removing all replication agreements with it. from iparpl1 I have the following results: [root at iparpl1 ~]# ipa-replica-manage del iparpl2.mydomain 'iparpl1.mydomain' has no replication agreement for 'iparpl2.mydomaon' [root at iparpl1 ~]# ipa-replica-manage del ipasrv.mydomain Connection to 'ipasrv.mydomain' failed: Unable to delete replica 'ipasrv.mydomain' 2. Choose another FreeIPA Server with CA installed to become the first master Can I do this request from my 1st replica iparpl1 and how ? 3. Nominate this master to be the one in charge or renewing certs and publishing CRLS. This is a manual procedure at the moment. 4. Follow standard installation procedure to deploy a new master on a hardware/VM of your choice this request is to install a replica not a master ? Thanks for your help. From bret.wortman at damascusgrp.com Wed Apr 30 11:01:56 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 30 Apr 2014 07:01:56 -0400 Subject: [Freeipa-users] Best practices for core servers In-Reply-To: <5360A328.90903@redhat.com> References: <535E3585.2070903@damascusgrp.com> <5360A328.90903@redhat.com> Message-ID: <5360D824.5010006@damascusgrp.com> I can already see from this that our key problem may have been that we had one server functioning as the hub and every other remote replica had just one agreement, but those agreements were all with the hub. So that hub had ten agreements. Badness. We'll give this some good attention as we move forward. Thanks for the pointer, Martin. Bret On 04/30/2014 03:15 AM, Martin Kosek wrote: > On 04/28/2014 01:03 PM, Bret Wortman wrote: >> We are planning to reconfigure our core Freeipa servers, basically building a >> replacement infrastructure and migrating to it. What we're planning right now is >> a core of three Freeipa servers each of which has a CA, with as much >> distribution of replication as we can manage. I imagine that means one of them >> replicates to the other two but am open to other ideas. > You can configure them to replica to each other. > >> For remote locations, we're planning to stand up caching-only DNS servers, as >> authenticating back to the main IPA servers works extremely well; it's just DNS >> that needs a little help. >> >> Any thoughts before I start setting these servers (VMs, most likely) up? > You may want to read our upstream Deployment Recommendations article, it may > save you some bad decisions from the start: > > http://www.freeipa.org/page/Deployment_Recommendations > > If we see that we missed anything in this article, it would be great to enhance it. > > Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Wed Apr 30 12:38:00 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 30 Apr 2014 08:38:00 -0400 Subject: [Freeipa-users] Fwd: Re: dse.ldif and dse.ldif.bak are lost In-Reply-To: <5360EE6D.8030406@redhat.com> References: <5360EE6D.8030406@redhat.com> Message-ID: <5360EEA8.8010507@redhat.com> -------- Original Message -------- Subject: Re: [Freeipa-users] dse.ldif and dse.ldif.bak are lost Date: Wed, 30 Apr 2014 08:37:01 -0400 From: Dmitri Pal Reply-To: dpal at redhat.com Organization: Red Hat To: artjazz at free.fr On 04/30/2014 05:26 AM, artjazz at free.fr wrote: > Hi, > > I have 1 ipa master 'ipasrv' and 2 replicas 'iparpl1 iparpl2' installed with > --setup-ca option. > Since a few days I have an issue with '389 Directory Server' on the master > (ipasrv) and on the 2nd replica (iparpl2) with the following messages: > > The configuration file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif was not restored > from backup /etc/dirsrv/slapd-MYINSTANCE/dse.ldif.tmp, error -1 > Apr 28 07:38:35 localhost ns-slapd: [28/Apr/2014:15:38:35 +0200] dse - The > configuration file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif was not restored from > backup /etc/dirsrv/slapd-MYINSTANCE/dse.ldif.bak, error -1 > Apr 28 07:38:35 localhost ns-slapd: [28/Apr/2014:15:38:35 +0200] config - The > given config file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif could not be accessed, > Netscape Portable Runtime error -5950 (File not found.) > > The files dse.ldif and dse.ldif.bak are lost. > On my 1st replica (iparpl1) everything is OK. > > No Full IPA backup and LDAP backup done on ipasrv and iparpl2. > > A) Can I restore those files from iparpl1 ? > > B) I am a little bit confused after reading the documentation on > http://www.freeipa.org/page/Backup_and_Restore > - can I consider that the ipa replicas are like ipa master ? Yes they are especially if they have same components (CA). The only difference is the configuration. Replicas do not track renewals and do not generate CRLs. Bot nothing prevents you from shifting these two responsibilities from the first server you installed to one of the replicas. This is what the procedure is about > In this case when I want to execute the manual procedure in chapter 'One > Server Loss' > 1. Clean deployment from the lost server by removing all replication > agreements with it. > from iparpl1 I have the following results: > > [root at iparpl1 ~]# ipa-replica-manage del iparpl2.mydomain > 'iparpl1.mydomain' has no replication agreement for 'iparpl2.mydomaon' Why are you trying to delete the second replica? You need to delete the first server. [root at iparpl1 ~]# ipa-replica-manage del ipasrv.mydomain [root at iparpl2 ~]# ipa-replica-manage del ipasrv.mydomain You also want to create a replication agreement between replicas 1 & 2. > > [root at iparpl1 ~]# ipa-replica-manage del ipasrv.mydomain > Connection to 'ipasrv.mydomain' failed: > Unable to delete replica 'ipasrv.mydomain' What version do you have? In earlier versions there have been issues with deleting replicas and required manual steps. Search for CLEANRUV in the list archives. > > 2. Choose another FreeIPA Server with CA installed to become the first master > Can I do this request from my 1st replica iparpl1 and how ? Yes > > 3. Nominate this master to be the one in charge or renewing certs and > publishing CRLS. This is a manual procedure at the moment. > > 4. Follow standard installation procedure to deploy a new master on a > hardware/VM of your choice > this request is to install a replica not a master ? Now the server that does CRL publishing and cert tracking is your new master. You are deploying a new replica instead of the one that is now a new master. > > Thanks for your help. > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Apr 30 13:26:28 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 30 Apr 2014 07:26:28 -0600 Subject: [Freeipa-users] dse.ldif and dse.ldif.bak are lost In-Reply-To: <1398849996.5360c1cd0055a@imp.free.fr> References: <1398849996.5360c1cd0055a@imp.free.fr> Message-ID: <5360FA04.2080803@redhat.com> On 04/30/2014 03:26 AM, artjazz at free.fr wrote: > Hi, > > I have 1 ipa master 'ipasrv' and 2 replicas 'iparpl1 iparpl2' installed with > --setup-ca option. > Since a few days I have an issue with '389 Directory Server' on the master > (ipasrv) and on the 2nd replica (iparpl2) with the following messages: > > The configuration file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif was not restored > from backup /etc/dirsrv/slapd-MYINSTANCE/dse.ldif.tmp, error -1 > Apr 28 07:38:35 localhost ns-slapd: [28/Apr/2014:15:38:35 +0200] dse - The > configuration file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif was not restored from > backup /etc/dirsrv/slapd-MYINSTANCE/dse.ldif.bak, error -1 > Apr 28 07:38:35 localhost ns-slapd: [28/Apr/2014:15:38:35 +0200] config - The > given config file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif could not be accessed, > Netscape Portable Runtime error -5950 (File not found.) > > The files dse.ldif and dse.ldif.bak are lost. Was this a VM or a bare metal machine? If a VM, please consider not using a disk image file for the /etc partition to help avoid this problem in the future. What version of 389-ds-base? rpm -q 389-ds-base Do you have dse.ldif.startOK? ls -al /etc/dirsrv/slapd-MYINSTANCE > On my 1st replica (iparpl1) everything is OK. > > No Full IPA backup and LDAP backup done on ipasrv and iparpl2. > > A) Can I restore those files from iparpl1 ? dse.ldif? No, not without a lot of editing, since there is a lot of host-specific config > > B) I am a little bit confused after reading the documentation on > http://www.freeipa.org/page/Backup_and_Restore > - can I consider that the ipa replicas are like ipa master ? > In this case when I want to execute the manual procedure in chapter 'One > Server Loss' > 1. Clean deployment from the lost server by removing all replication > agreements with it. > from iparpl1 I have the following results: > > [root at iparpl1 ~]# ipa-replica-manage del iparpl2.mydomain > 'iparpl1.mydomain' has no replication agreement for 'iparpl2.mydomaon' > > [root at iparpl1 ~]# ipa-replica-manage del ipasrv.mydomain > Connection to 'ipasrv.mydomain' failed: > Unable to delete replica 'ipasrv.mydomain' > > 2. Choose another FreeIPA Server with CA installed to become the first master > Can I do this request from my 1st replica iparpl1 and how ? > > 3. Nominate this master to be the one in charge or renewing certs and > publishing CRLS. This is a manual procedure at the moment. > > 4. Follow standard installation procedure to deploy a new master on a > hardware/VM of your choice > this request is to install a replica not a master ? > > Thanks for your help. > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Wed Apr 30 13:31:52 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 30 Apr 2014 09:31:52 -0400 Subject: [Freeipa-users] dse.ldif and dse.ldif.bak are lost In-Reply-To: <1398849996.5360c1cd0055a@imp.free.fr> References: <1398849996.5360c1cd0055a@imp.free.fr> Message-ID: <5360FB48.8050904@redhat.com> artjazz at free.fr wrote: > Hi, > > I have 1 ipa master 'ipasrv' and 2 replicas 'iparpl1 iparpl2' installed with > --setup-ca option. > Since a few days I have an issue with '389 Directory Server' on the master > (ipasrv) and on the 2nd replica (iparpl2) with the following messages: > > The configuration file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif was not restored > from backup /etc/dirsrv/slapd-MYINSTANCE/dse.ldif.tmp, error -1 > Apr 28 07:38:35 localhost ns-slapd: [28/Apr/2014:15:38:35 +0200] dse - The > configuration file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif was not restored from > backup /etc/dirsrv/slapd-MYINSTANCE/dse.ldif.bak, error -1 > Apr 28 07:38:35 localhost ns-slapd: [28/Apr/2014:15:38:35 +0200] config - The > given config file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif could not be accessed, > Netscape Portable Runtime error -5950 (File not found.) > > The files dse.ldif and dse.ldif.bak are lost. > On my 1st replica (iparpl1) everything is OK. > > No Full IPA backup and LDAP backup done on ipasrv and iparpl2. > > A) Can I restore those files from iparpl1 ? Not easily. There is some instance-specific information. The 389-ds team may have some ideas. Do you know what happened? Were the servers crashing? Are there any other dse.ldif.* files there? There should at least be dse.ldif.startOK. That would be a place to start. > B) I am a little bit confused after reading the documentation on > http://www.freeipa.org/page/Backup_and_Restore > - can I consider that the ipa replicas are like ipa master ? > In this case when I want to execute the manual procedure in chapter 'One > Server Loss' > 1. Clean deployment from the lost server by removing all replication > agreements with it. > from iparpl1 I have the following results: > > [root at iparpl1 ~]# ipa-replica-manage del iparpl2.mydomain > 'iparpl1.mydomain' has no replication agreement for 'iparpl2.mydomaon' You can only delete a master from a server that has a replication agreement with it. I assume your topology was something like: ipa / \ iparpl1 iparpl2 This will leave iparpl2 as an IPA master in some places in the tree. Depending on the version of IPA you can use the -c flag to clean up a master that is now gone. > [root at iparpl1 ~]# ipa-replica-manage del ipasrv.mydomain > Connection to 'ipasrv.mydomain' failed: > Unable to delete replica 'ipasrv.mydomain' The --force flag will let this continue. > > 2. Choose another FreeIPA Server with CA installed to become the first master > Can I do this request from my 1st replica iparpl1 and how ? > http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master It matters what version of IPA you have. > 3. Nominate this master to be the one in charge or renewing certs and > publishing CRLS. This is a manual procedure at the moment. > > 4. Follow standard installation procedure to deploy a new master on a > hardware/VM of your choice > this request is to install a replica not a master ? All servers are masters to IPA. The only difference is which ones have a CA and DNS server. If iparpl1 does not have a CA installed then I'd try to get the initial IPA master back up, otherwise you will be stuck with no CA, no way to generate new replicas. rob From rmeggins at redhat.com Wed Apr 30 15:26:57 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 30 Apr 2014 09:26:57 -0600 Subject: [Freeipa-users] dse.ldif and dse.ldif.bak are lost In-Reply-To: <1398871324.5361151c71bfb@imp.free.fr> References: <1398849996.5360c1cd0055a@imp.free.fr> <5360FA04.2080803@redhat.com> <1398871324.5361151c71bfb@imp.free.fr> Message-ID: <53611641.9080601@redhat.com> On 04/30/2014 09:22 AM, artjazz at free.fr wrote: > Thanks a lot. My answers below. Please keep replies on list, for others to see. > > Selon Rich Megginson : > >> On 04/30/2014 03:26 AM, artjazz at free.fr wrote: >>> Hi, >>> >>> I have 1 ipa master 'ipasrv' and 2 replicas 'iparpl1 iparpl2' installed >> with >>> --setup-ca option. >>> Since a few days I have an issue with '389 Directory Server' on the master >>> (ipasrv) and on the 2nd replica (iparpl2) with the following messages: >>> >>> The configuration file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif was not >> restored >>> from backup /etc/dirsrv/slapd-MYINSTANCE/dse.ldif.tmp, error -1 >>> Apr 28 07:38:35 localhost ns-slapd: [28/Apr/2014:15:38:35 +0200] dse - The >>> configuration file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif was not restored >> from >>> backup /etc/dirsrv/slapd-MYINSTANCE/dse.ldif.bak, error -1 >>> Apr 28 07:38:35 localhost ns-slapd: [28/Apr/2014:15:38:35 +0200] config - >> The >>> given config file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif could not be >> accessed, >>> Netscape Portable Runtime error -5950 (File not found.) >>> >>> The files dse.ldif and dse.ldif.bak are lost. >> Was this a VM or a bare metal machine? If a VM, please consider not >> using a disk image file for the /etc partition to help avoid this >> problem in the future. > VM is a Virtual Machine. Please consider using something other than a disk image file for the /etc partition. And please consider doing the same for the /var/lib/dirsrv data (the actual dirsrv database files). > >> What version of 389-ds-base? rpm -q 389-ds-base > 389-ds-base-1.3.1.6-23.el7.x86_64 > >> Do you have dse.ldif.startOK? > Yes, I do, but when I tried to restore it with 'bak2db > /etc/dirsrv/slapd-MYINSTANCE/dse.ldif.startOK' > I have a lot of errors: Right. You don't restore this file with bak2db. You just use cp -p # cd /etc/dirsrv/slapd-MYINSTANCE # cp -p dse.ldif.startOK dse.ldif bak2db is only for the actual database data files (e.g. the files in /var/lib/dirsrv/slapd-MYINSTANCE/db) > > [30/Apr/2014:15:46:19 +0200] - valueset_value_syntax_cmp: > slapi_attr_values2keys_sv failed for type attributetypes > [30/Apr/2014:15:46:19 +0200] dse_read_one_file - The entry cn=schema in file > /etc/dirsrv/slapd-MYINSTANCE/schema/00core.ldif (lineno: 1) is invalid, error > code 21 (Invalid syntax) - attribute type aci: Unknown attribute syntax OID > "1.3.6.1.4.1.1466.115.121.1.15" > [30/Apr/2014:15:46:19 +0200] dse - Please edit the file to correct the reported > problems and then restart the server. > > > >> ls -al /etc/dirsrv/slapd-MYINSTANCE >> >>> On my 1st replica (iparpl1) everything is OK. >>> >>> No Full IPA backup and LDAP backup done on ipasrv and iparpl2. >>> >>> A) Can I restore those files from iparpl1 ? >> dse.ldif? No, not without a lot of editing, since there is a lot of >> host-specific config >> >>> B) I am a little bit confused after reading the documentation on >>> http://www.freeipa.org/page/Backup_and_Restore >>> - can I consider that the ipa replicas are like ipa master ? >>> In this case when I want to execute the manual procedure in chapter 'One >>> Server Loss' >>> 1. Clean deployment from the lost server by removing all replication >>> agreements with it. >>> from iparpl1 I have the following results: >>> >>> [root at iparpl1 ~]# ipa-replica-manage del iparpl2.mydomain >>> 'iparpl1.mydomain' has no replication agreement for 'iparpl2.mydomaon' >>> >>> [root at iparpl1 ~]# ipa-replica-manage del ipasrv.mydomain >>> Connection to 'ipasrv.mydomain' failed: >>> Unable to delete replica 'ipasrv.mydomain' >>> >>> 2. Choose another FreeIPA Server with CA installed to become the first >> master >>> Can I do this request from my 1st replica iparpl1 and how ? >>> >>> 3. Nominate this master to be the one in charge or renewing certs and >>> publishing CRLS. This is a manual procedure at the moment. >>> >>> 4. Follow standard installation procedure to deploy a new master on a >>> hardware/VM of your choice >>> this request is to install a replica not a master ? >>> >>> Thanks for your help. >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > > > > > > From artjazz at free.fr Wed Apr 30 16:22:40 2014 From: artjazz at free.fr (artjazz at free.fr) Date: Wed, 30 Apr 2014 18:22:40 +0200 Subject: [Freeipa-users] dse.ldif and dse.ldif.bak are lost In-Reply-To: <53611641.9080601@redhat.com> References: <1398849996.5360c1cd0055a@imp.free.fr> <5360FA04.2080803@redhat.com> <1398871324.5361151c71bfb@imp.free.fr> <53611641.9080601@redhat.com> Message-ID: <1398874960.536123501b806@imp.free.fr> Selon Rich Megginson : > On 04/30/2014 09:22 AM, artjazz at free.fr wrote: > > Thanks a lot. My answers below. > > Please keep replies on list, for others to see. Sorry, I knew it but I forgot. > > > > > Selon Rich Megginson : > > > >> On 04/30/2014 03:26 AM, artjazz at free.fr wrote: > >>> Hi, > >>> > >>> I have 1 ipa master 'ipasrv' and 2 replicas 'iparpl1 iparpl2' installed > >> with > >>> --setup-ca option. > >>> Since a few days I have an issue with '389 Directory Server' on the > master > >>> (ipasrv) and on the 2nd replica (iparpl2) with the following messages: > >>> > >>> The configuration file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif was not > >> restored > >>> from backup /etc/dirsrv/slapd-MYINSTANCE/dse.ldif.tmp, error -1 > >>> Apr 28 07:38:35 localhost ns-slapd: [28/Apr/2014:15:38:35 +0200] dse - > The > >>> configuration file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif was not restored > >> from > >>> backup /etc/dirsrv/slapd-MYINSTANCE/dse.ldif.bak, error -1 > >>> Apr 28 07:38:35 localhost ns-slapd: [28/Apr/2014:15:38:35 +0200] config - > >> The > >>> given config file /etc/dirsrv/slapd-MYINSTANCE/dse.ldif could not be > >> accessed, > >>> Netscape Portable Runtime error -5950 (File not found.) > >>> > >>> The files dse.ldif and dse.ldif.bak are lost. > >> Was this a VM or a bare metal machine? If a VM, please consider not > >> using a disk image file for the /etc partition to help avoid this > >> problem in the future. > > VM is a Virtual Machine. > > Please consider using something other than a disk image file for the > /etc partition. And please consider doing the same for the > /var/lib/dirsrv data (the actual dirsrv database files). > > > > >> What version of 389-ds-base? rpm -q 389-ds-base > > 389-ds-base-1.3.1.6-23.el7.x86_64 > > > >> Do you have dse.ldif.startOK? > > Yes, I do, but when I tried to restore it with 'bak2db > > /etc/dirsrv/slapd-MYINSTANCE/dse.ldif.startOK' > > I have a lot of errors: > > Right. You don't restore this file with bak2db. You just use cp -p > > # cd /etc/dirsrv/slapd-MYINSTANCE > # cp -p dse.ldif.startOK dse.ldif Thanks a lot, after this action everything is OK. Now, I have to create a Replication Agreements between ipasrv and iparpl1, because following the Rob Crittenden proposal with the --force flag, i did: [root at iparpl1 ~]# ipa-replica-manage --force del ipasrv.mydomain But when I read the Identity Management Guide, paragraph 25.5. Managing Replication Agreements Between IdM Servers I don't understand on which machine and what command I have to execute to have an agreement between ipasrv and iparpl1; Currently I have: [root at iparpl1 ~]# ipa-replica-manage list-ruv iparpl1.mydomain:389: 6 iparpl2.mydomain:389: 3 [root at ipasrv ~]# ipa-replica-manage list-ruv ipasrv.mydomain:389: 4 iparpl1.mydomain:389: 6 iparpl2.mydomain:389: 3 [root at iparpl2 ~]# ipa-replica-manage list-ruv iparpl2.mydomain:389: 3 ipasrv.mydomain:389: 4 iparpl1.mydomain:389: 6 > > bak2db is only for the actual database data files (e.g. the files in > /var/lib/dirsrv/slapd-MYINSTANCE/db) > > > > > [30/Apr/2014:15:46:19 +0200] - valueset_value_syntax_cmp: > > slapi_attr_values2keys_sv failed for type attributetypes > > [30/Apr/2014:15:46:19 +0200] dse_read_one_file - The entry cn=schema in > file > > /etc/dirsrv/slapd-MYINSTANCE/schema/00core.ldif (lineno: 1) is invalid, > error > > code 21 (Invalid syntax) - attribute type aci: Unknown attribute syntax OID > > "1.3.6.1.4.1.1466.115.121.1.15" > > [30/Apr/2014:15:46:19 +0200] dse - Please edit the file to correct the > reported > > problems and then restart the server. > > > > > > > >> ls -al /etc/dirsrv/slapd-MYINSTANCE > >> > >>> On my 1st replica (iparpl1) everything is OK. > >>> > >>> No Full IPA backup and LDAP backup done on ipasrv and iparpl2. > >>> > >>> A) Can I restore those files from iparpl1 ? > >> dse.ldif? No, not without a lot of editing, since there is a lot of > >> host-specific config > >> > >>> B) I am a little bit confused after reading the documentation on > >>> http://www.freeipa.org/page/Backup_and_Restore > >>> - can I consider that the ipa replicas are like ipa master ? > >>> In this case when I want to execute the manual procedure in chapter > 'One > >>> Server Loss' > >>> 1. Clean deployment from the lost server by removing all replication > >>> agreements with it. > >>> from iparpl1 I have the following results: > >>> > >>> [root at iparpl1 ~]# ipa-replica-manage del iparpl2.mydomain > >>> 'iparpl1.mydomain' has no replication agreement for 'iparpl2.mydomaon' > >>> > >>> [root at iparpl1 ~]# ipa-replica-manage del ipasrv.mydomain > >>> Connection to 'ipasrv.mydomain' failed: > >>> Unable to delete replica 'ipasrv.mydomain' > >>> > >>> 2. Choose another FreeIPA Server with CA installed to become the > first > >> master > >>> Can I do this request from my 1st replica iparpl1 and how ? > >>> > >>> 3. Nominate this master to be the one in charge or renewing certs and > >>> publishing CRLS. This is a manual procedure at the moment. > >>> > >>> 4. Follow standard installation procedure to deploy a new master on a > >>> hardware/VM of your choice > >>> this request is to install a replica not a master ? > >>> > >>> Thanks for your help. > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Freeipa-users mailing list > >>> Freeipa-users at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-users > >> > > > > > > > > > > > > > > > > From mitkany at gmail.com Wed Apr 30 21:10:31 2014 From: mitkany at gmail.com (Dimitar Georgievski) Date: Wed, 30 Apr 2014 17:10:31 -0400 Subject: [Freeipa-users] Automembership not working Message-ID: Hi, I am trying to create rules to place users in given user groups based on the value of their ou (Organization Unit) field in their profiles. For some reason it is not working, and I am trying to understand why. The rule is very simple and looks like this > ipa automember-find engineering > Grouping Type: group > --------------- > 1 rules matched > --------------- > Description: Add automatically Engineering users to engineering User > Group > Automember Rule: engineering > Inclusive Regex: ou=^Engineering With this rule in place I would expect all the new users with ou=Engineering to be automatically placed in the engineering user group. I am using FreeIPA v3.0.0 on CentOS 6.5 Thanks Dimitar -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Wed Apr 30 21:00:11 2014 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 30 Apr 2014 21:00:11 +0000 Subject: [Freeipa-users] Biasing which master clients talk to first In-Reply-To: <1398776164.10424.77.camel@willson.li.ssimo.org> References: <535E8DB0.4050302@damascusgrp.com> <535E8EF0.9040606@damascusgrp.com> <1398706356.10424.64.camel@willson.li.ssimo.org> <535E932D.40703@damascusgrp.com> <1398707597.10424.68.camel@willson.li.ssimo.org> , <535E9863.7070509@damascusgrp.com> <1398738881766.69636@vuw.ac.nz>, <1398776164.10424.77.camel@willson.li.ssimo.org> Message-ID: <1398891611066.44084@vuw.ac.nz> Hi, We have a master at our DR site which is "further way" than our 2 local masters, is there a way (in DNS say) that we could "encourage" clients to use the closer IPA masters? eg host -t SRV _ldap._tcp.ods.vuw.ac.nz _ldap._tcp.ods.vuw.ac.nz has SRV record 0 100 389 serveripa3 _ldap._tcp.ods.vuw.ac.nz has SRV record 0 100 389 serveripa2 _ldap._tcp.ods.vuw.ac.nz has SRV record 1 100 389 serveripa1 ? or what would be the best way? regards Steven From torsten.scholak at googlemail.com Wed Apr 30 20:17:58 2014 From: torsten.scholak at googlemail.com (Torsten Scholak) Date: Wed, 30 Apr 2014 16:17:58 -0400 Subject: [Freeipa-users] ipa <-> samba Message-ID: Hi there, I am considering to set up a smb2 server intended for certain windows machines and macs that are not member of the kerberos realm and hence not single sign-on enabled (read: guest machines). The server for the smb service runs a fresh Fedora 20 and is also holding an ipa replica. Let me strees that I don't need a domain controller nor the synchronization to one, just a way to allow samba to lookup and authenticate against credentials provided by freeipa. This is just a pet project in a non-production environment (home). I searched around a bit and found a number of guides and mailing list posts, e.g. https://www.mail-archive.com/freeipa-users at redhat.com/msg04928.html However, information tends to be scarce, scattered, and incomplete. Since most of it is rather old, I worry that it is horribly outdated. Today, how would I go about this? Is this configuration at all supported? Do I get samba 3 or samba 4 for that job? Do I use ldapsam as passdb backend? Do I need to extend the schema? Which attributes/objectclasses do users and groups have to have in order to work with samba? Do they have to be converted to posix objects? What is ipa-sam? Is there any documentation for ipa-sam? I'm not requesting a full step-by-step tutorial here, I just hope someone can point me in the right direction. Best, Torsten From abokovoy at redhat.com Wed Apr 30 21:44:08 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 1 May 2014 00:44:08 +0300 Subject: [Freeipa-users] ipa <-> samba In-Reply-To: References: Message-ID: <20140430214408.GT20958@redhat.com> On Wed, 30 Apr 2014, Torsten Scholak wrote: >Hi there, > >I am considering to set up a smb2 server intended for certain windows >machines and macs that are not member of the kerberos realm and hence >not single sign-on enabled (read: guest machines). > >The server for the smb service runs a fresh Fedora 20 and is also >holding an ipa replica. > >Let me strees that I don't need a domain controller nor the >synchronization to one, just a way to allow samba to lookup and >authenticate against credentials provided by freeipa. This is just a >pet project in a non-production environment (home). > >I searched around a bit and found a number of guides and mailing list >posts, e.g. >https://www.mail-archive.com/freeipa-users at redhat.com/msg04928.html >However, information tends to be scarce, scattered, and incomplete. >Since most of it is rather old, I worry that it is horribly outdated. For this specific case look at https://www.redhat.com/archives/freeipa-users/2013-April/msg00270.html and the thread around it. -- / Alexander Bokovoy From leigh.moulder at sri.com Wed Apr 30 22:45:29 2014 From: leigh.moulder at sri.com (Leigh Moulder) Date: Wed, 30 Apr 2014 15:45:29 -0700 Subject: [Freeipa-users] Integrating with Smart Cards Message-ID: <53617D09.6020201@sri.com> Hi all, I'm very new to FreeIPA, so I hope this isn't answered in documentation somewhere already. I'm working to get my infrastructure DIACAP approved, and part of this process includes unique user accounts with smart card integration. I was hoping that since FreeIPA utilizes Dogtag, I'd be able to use it for essentially everything, from LDAP, to certificate store, to smart card management. Unfortunately, the only references I was able to find were a handful of emails from a few years ago. I was wondering what the status of smart card integration was, and if it was completed yet. If so, where can I find the documentation to configure it. And if it's not currently in the works, does anyone know a viable solution. I'm currently running everything on RHEL 6.5, but would really rather stay away from their directory and certificate servers. Right now, I can't justify the price they're quoting me. Thanks in Advance, Leigh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4027 bytes Desc: S/MIME Cryptographic Signature URL: From Steven.Jones at vuw.ac.nz Wed Apr 30 23:58:53 2014 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 30 Apr 2014 23:58:53 +0000 Subject: [Freeipa-users] Integrating with Smart Cards In-Reply-To: <53617D09.6020201@sri.com> References: <53617D09.6020201@sri.com> Message-ID: <1398902332588.65864@vuw.ac.nz> Hi, We want to use 2FA tokens and cant because of a Kerberos issue. I assume if this hasnt been upgraded yet that you cant get the passthrough? I'll we interested to know if that is now not the case or at least an idea when it will be GA. regards Steven Jones Technical Specialist - Linux RHCE Victoria University ITS, Level 8 Rankin Brown Building, Wellington, NZ 6012 0064 4 463 6272