From dpal at redhat.com Sun Feb 1 00:09:25 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 31 Jan 2015 19:09:25 -0500 Subject: [Freeipa-users] sssd compatibility with older RHEL 6 minor releases. In-Reply-To: References: Message-ID: <54CD6EB5.3090105@redhat.com> On 01/31/2015 01:37 PM, Genadi Postrilko wrote: > Hello all. > > The environment i'm currently working to migrate under IPA identity > management contains mostly RHEL 6.2 servers. > I'm planing to use Active Directory Cross Forest Trust for Identities, > IPA as sudo provider, and all the other goodies that IPA provides. > > If i want to enjoy all the new features (at least most of them), i > know that clients have to be sssd version > 1.9. And if i want IPA to > be auto configured as sudo provider it has to be sssd > 1.11. > > When reading the mailing list i noticed that sssd 1.11 is mentioned as > feature of rhel 6.6. > What i would like and understand is what could go wrong if i will > install sssd 1.11 on rhel 6.2 servers.And what is is your general > recommendations for older RHEL 6 (minor) releases? It will pull a lot of dependencies and most of your system will look like 6.6 system Also the upgrade like this might reveal some issues as the upgrades are expected to be gradual. 1-2 versions is ok but 4 is quit a big leap. Overall it is a bit risky to do it. You have three options: - upgrade properly but probably in two steps 6.2 -> 6.4 -> 6.6 - use SSSD from 6.2 as is for now. It will have limited functionality but can leverage AD users from the trust. You would need to configure SSSD to use LDAP for authentication and point to compat tree of IPA to take advantage of the trust. See details here: http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf - take your chances and try a hybrid you propose but it is not a formally supported configuration. > > Thanks in advance, > Genadi. > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From william at firstyear.id.au Sun Feb 1 04:38:44 2015 From: william at firstyear.id.au (William) Date: Sun, 01 Feb 2015 15:08:44 +1030 Subject: [Freeipa-users] IPA-adtrust and addition of replicas Message-ID: <1422765524.4790.3.camel@firstyear.id.au> Hi, I have a single master instance of IPA 3.3.5 at the moment. I have configured this with IPA adtrust and run the adtrust preparation. I am about to add a second replica. The documentation[0][1] doesn't really go into what happens in this circumstance. Do I need to make any configuration on the replica once I have installed it? Or does the replica information file hint to the ipa-replica-installer that adtrust components must be configured? IE can my new replica act as a trust master, and will it correctly update attributes such as iPAntpassword? Sincerely, William [0] http://www.freeipa.org/page/V3/MultipleTrustServers [1] https://fedorahosted.org/freeipa/ticket/2189 From abokovoy at redhat.com Sun Feb 1 15:49:35 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 1 Feb 2015 17:49:35 +0200 Subject: [Freeipa-users] IPA-adtrust and addition of replicas In-Reply-To: <1422765524.4790.3.camel@firstyear.id.au> References: <1422765524.4790.3.camel@firstyear.id.au> Message-ID: <20150201154935.GZ6592@redhat.com> Hi, On Sun, 01 Feb 2015, William wrote: >Hi, > >I have a single master instance of IPA 3.3.5 at the moment. I have >configured this with IPA adtrust and run the adtrust preparation. I am >about to add a second replica. > >The documentation[0][1] doesn't really go into what happens in this >circumstance. Do I need to make any configuration on the replica once I >have installed it? Or does the replica information file hint to the >ipa-replica-installer that adtrust components must be configured? IE can >my new replica act as a trust master, and will it correctly update >attributes such as iPAntpassword? No, it will not. Although information about trust setup is in the replicated subtree, the plugins which get configured for the trust case are configured in cn=config which is not in the replicated subtree, thus they will need to be configured explicitly with ipa-adtrust-install on each replica which will provide services to IPA clients accessible by AD users. Password generation will be performed on such non-configured replica, though, because our password plugin will be able to generate ipaNTHash attribute for any user that has ipaNTSecurityIdentifier attribute. However, ipaNTSecurityIdentifier attribute is populated by sidgen plugin which is only activated when ipa-adtrust-install was run. Additionally, extdom plugin is what SSSD on IPA clients uses to request SID to name and name to SID resolution for AD users. It is also configured with the help of ipa-adtrust-install. Now, there is something interesting you've reminded me about by pointing to the ticket below: >[0] http://www.freeipa.org/page/V3/MultipleTrustServers >[1] https://fedorahosted.org/freeipa/ticket/2189 This ticket concerns enabling multiple IPA masters as domain controllers from Active Directory point of view. After running ipa-adtrust-install, the domain controllers will be advertised in the DNS service records and they will be contacted by AD DC at the point of validating trust (part of 'ipa trust-add' sequence). What I realized now is that with FreeIPA 3.3+ we moved ID resolution fully to SSSD and we technically don't need to run full 'domain controller' stack (e.g. Samba) on a master that only wants to resolve IDs rather than participating in a balancing of the domain controller duties. For such operation we could have a scaled-down version of ipa-adtrust-install which doesn't install Samba and configure it for use as a DC. Rather, it would install and configure required plugins (sidgen, extdom, but not cldap) to allow KDC to issue proper MS-PAC information to the master's host/fqdn at REALM key -- this is what will enable SSSD on the master to gain access to AD LDAP/Global Catalog over the trust. Such a lightweight configured 'domain controller' would only be able to resolve AD user/group identities but this is just what needed in majority of deployments. As result, with this approach we can also solve an issue of forced install of Samba on each master -- something we were looking to fix. We would still need to make sure we are falling back to a proper master to act on trust-related management operations with IPA CLI and web UI because without enabled Samba on the master we wouldn't be able to establish trust at all (or change few other bits). -- / Alexander Bokovoy From william at firstyear.id.au Sun Feb 1 22:56:43 2015 From: william at firstyear.id.au (William) Date: Mon, 02 Feb 2015 09:26:43 +1030 Subject: [Freeipa-users] IPA-adtrust and addition of replicas In-Reply-To: <20150201154935.GZ6592@redhat.com> References: <1422765524.4790.3.camel@firstyear.id.au> <20150201154935.GZ6592@redhat.com> Message-ID: <1422831403.3928.8.camel@firstyear.id.au> On Sun, 2015-02-01 at 17:49 +0200, Alexander Bokovoy wrote: > Hi, > > On Sun, 01 Feb 2015, William wrote: > >Hi, > > > >I have a single master instance of IPA 3.3.5 at the moment. I have > >configured this with IPA adtrust and run the adtrust preparation. I am > >about to add a second replica. > > > >The documentation[0][1] doesn't really go into what happens in this > >circumstance. Do I need to make any configuration on the replica once I > >have installed it? Or does the replica information file hint to the > >ipa-replica-installer that adtrust components must be configured? IE can > >my new replica act as a trust master, and will it correctly update > >attributes such as iPAntpassword? > No, it will not. Although information about trust setup is in the > replicated subtree, the plugins which get configured for the trust case are > configured in cn=config which is not in the replicated subtree, thus > they will need to be configured explicitly with ipa-adtrust-install on > each replica which will provide services to IPA clients accessible by AD > users. > > Password generation will be performed on such non-configured replica, > though, because our password plugin will be able to generate ipaNTHash > attribute for any user that has ipaNTSecurityIdentifier attribute. > However, ipaNTSecurityIdentifier attribute is populated by sidgen plugin > which is only activated when ipa-adtrust-install was run. Wow! From all this it really sounds like adding a replica in to an IPA domain where adtrust has been run could have a few edge cases. For example, what would happen if I create a new account on a replica without adtrust? Would sidgen run on the adtrust machine when it get's the record replicated to it? What does one need to do to setup my new replica as a potential adtrust replica? For example, I am about to decommission my old master, so I would like the adtrust setup to available on the new master. Is it just a case of running the adtrust-install tool again? > > Additionally, extdom plugin is what SSSD on IPA clients uses to request > SID to name and name to SID resolution for AD users. It is also > configured with the help of ipa-adtrust-install. > > Now, there is something interesting you've reminded me about by pointing > to the ticket below: > >[0] http://www.freeipa.org/page/V3/MultipleTrustServers > >[1] https://fedorahosted.org/freeipa/ticket/2189 > This ticket concerns enabling multiple IPA masters as domain controllers > from Active Directory point of view. After running ipa-adtrust-install, > the domain controllers will be advertised in the DNS service records and > they will be contacted by AD DC at the point of validating trust (part > of 'ipa trust-add' sequence). > > What I realized now is that with FreeIPA 3.3+ we moved ID resolution > fully to SSSD and we technically don't need to run full 'domain > controller' stack (e.g. Samba) on a master that only wants to resolve > IDs rather than participating in a balancing of the domain controller > duties. What are the domain controller duties separate from the ID resolution tasks? What components carry out the id resolution? > > For such operation we could have a scaled-down version of > ipa-adtrust-install which doesn't install Samba and configure it for use > as a DC. Rather, it would install and configure required plugins > (sidgen, extdom, but not cldap) to allow KDC to issue proper MS-PAC > information to the master's host/fqdn at REALM key -- this is what will > enable SSSD on the master to gain access to AD LDAP/Global Catalog over > the trust. > > Such a lightweight configured 'domain controller' would only be able to > resolve AD user/group identities but this is just what needed in > majority of deployments. As result, with this approach we can also solve > an issue of forced install of Samba on each master -- something we were > looking to fix. > This should be configured on replicas added to the network if adtrust has been run already. Perhaps this is something to consider also? Consistency through out the domain is a good thing. > We would still need to make sure we are falling back to a proper master > to act on trust-related management operations with IPA CLI and web UI > because without enabled Samba on the master we wouldn't be able to > establish trust at all (or change few other bits). > Thanks for your time. Sincerely, William From abokovoy at redhat.com Mon Feb 2 08:02:44 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Feb 2015 10:02:44 +0200 Subject: [Freeipa-users] IPA-adtrust and addition of replicas In-Reply-To: <1422831403.3928.8.camel@firstyear.id.au> References: <1422765524.4790.3.camel@firstyear.id.au> <20150201154935.GZ6592@redhat.com> <1422831403.3928.8.camel@firstyear.id.au> Message-ID: <20150202080244.GA6592@redhat.com> On Mon, 02 Feb 2015, William wrote: >On Sun, 2015-02-01 at 17:49 +0200, Alexander Bokovoy wrote: >> Hi, >> >> On Sun, 01 Feb 2015, William wrote: >> >Hi, >> > >> >I have a single master instance of IPA 3.3.5 at the moment. I have >> >configured this with IPA adtrust and run the adtrust preparation. I am >> >about to add a second replica. >> > >> >The documentation[0][1] doesn't really go into what happens in this >> >circumstance. Do I need to make any configuration on the replica once I >> >have installed it? Or does the replica information file hint to the >> >ipa-replica-installer that adtrust components must be configured? IE can >> >my new replica act as a trust master, and will it correctly update >> >attributes such as iPAntpassword? >> No, it will not. Although information about trust setup is in the >> replicated subtree, the plugins which get configured for the trust case are >> configured in cn=config which is not in the replicated subtree, thus >> they will need to be configured explicitly with ipa-adtrust-install on >> each replica which will provide services to IPA clients accessible by AD >> users. >> >> Password generation will be performed on such non-configured replica, >> though, because our password plugin will be able to generate ipaNTHash >> attribute for any user that has ipaNTSecurityIdentifier attribute. >> However, ipaNTSecurityIdentifier attribute is populated by sidgen plugin >> which is only activated when ipa-adtrust-install was run. > >Wow! From all this it really sounds like adding a replica in to an IPA >domain where adtrust has been run could have a few edge cases. For >example, what would happen if I create a new account on a replica >without adtrust? Would sidgen run on the adtrust machine when it get's >the record replicated to it? I think it might work. sidgen is a post operation and replication protocol uses normal ldap_*_ext() API to send new objects. >What does one need to do to setup my new replica as a potential adtrust >replica? For example, I am about to decommission my old master, so I >would like the adtrust setup to available on the new master. Is it just >a case of running the adtrust-install tool again? yes. >> >> Additionally, extdom plugin is what SSSD on IPA clients uses to request >> SID to name and name to SID resolution for AD users. It is also >> configured with the help of ipa-adtrust-install. >> >> Now, there is something interesting you've reminded me about by pointing >> to the ticket below: >> >[0] http://www.freeipa.org/page/V3/MultipleTrustServers >> >[1] https://fedorahosted.org/freeipa/ticket/2189 >> This ticket concerns enabling multiple IPA masters as domain controllers >> from Active Directory point of view. After running ipa-adtrust-install, >> the domain controllers will be advertised in the DNS service records and >> they will be contacted by AD DC at the point of validating trust (part >> of 'ipa trust-add' sequence). >> >> What I realized now is that with FreeIPA 3.3+ we moved ID resolution >> fully to SSSD and we technically don't need to run full 'domain >> controller' stack (e.g. Samba) on a master that only wants to resolve >> IDs rather than participating in a balancing of the domain controller >> duties. > >What are the domain controller duties separate from the ID resolution >tasks? What components carry out the id resolution? In discussing with Simo yesterday, we came to conclusion that we would call a 'full' master that provides features for trust as a 'trust controller'. Let's call the other configuration a 'trust agent'. A trust controller is a FreeIPA master which hosts: - LDAP server with sigden, extdom, and cldap plugins - KDC with IPA driver - Samba configured with ipasam PASSDB module - SSSD with ipa_server_mode=True - Global Catalog instance (a separate LDAP instance with an AD-compatible schema) A trust agent is a FreeIPA master which hosts - LDAP server with sigden and extdom - KDC with IPA driver - SSSD with ipa_server_mode=True As you can see, trus agent is a master that relies on SSSD to do resolution of IDs. Trust controller is used for managing trust: add trust agreements, enable/disable separate domains from a trusted forest to access FreeIPA resources, etc. Trust controller is also what Active Directory's domain controllers contact when validating the trust by means of SMB protocol using LSA calls which implies running a Samba server. >> For such operation we could have a scaled-down version of >> ipa-adtrust-install which doesn't install Samba and configure it for use >> as a DC. Rather, it would install and configure required plugins >> (sidgen, extdom, but not cldap) to allow KDC to issue proper MS-PAC >> information to the master's host/fqdn at REALM key -- this is what will >> enable SSSD on the master to gain access to AD LDAP/Global Catalog over >> the trust. >> >> Such a lightweight configured 'domain controller' would only be able to >> resolve AD user/group identities but this is just what needed in >> majority of deployments. As result, with this approach we can also solve >> an issue of forced install of Samba on each master -- something we were >> looking to fix. >> > >This should be configured on replicas added to the network if adtrust >has been run already. Perhaps this is something to consider also? >Consistency through out the domain is a good thing. Exactly. Good suggestion. One thing we need to solve here is that enabling sidgen and other components will require installing Samba libraries. This is something to consider -- do we want these libraries (not daemons) installed on every master? -- / Alexander Bokovoy From gcuppari at gmail.com Mon Feb 2 13:13:02 2015 From: gcuppari at gmail.com (Gerardo Cuppari) Date: Mon, 2 Feb 2015 10:13:02 -0300 Subject: [Freeipa-users] JSON error enrolling host (Fedora 21 / IPA 4.1.2) Message-ID: Hello! I am trying to enroll one host to my IPA server (4.1.2) and I am having one problem: the ipa-client-install script keeps giving me errors at the "forwarding ping to json server" step. My configuration is: - server.estudio.local 192.168.56.2 Fedora Server 21 ipa 4.1.2 - pc01.estudio.local 192.168.56.106 Fedora Works. 21 Both have firewalld down (just to test) and can reach each other. I've been trying to get this working without success (solved other minor issues) and so I'm asking for your help. The only way I can make it work is by adding the --force switch to ipa-client-install script but, that way, it just disregards errors. Thanks in advance!!! Here are my tests: SERVER ====== [root at server ~]# ipa ping ------------------------------------------- IPA server version 4.1.2. API version 2.109 ------------------------------------------- CLIENT ====== [root at pc01 ~]# dig server ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> server ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29286 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;server. IN A ;; Query time: 10 msec ;; SERVER: 192.168.56.2#53(192.168.56.2) ;; WHEN: lun feb 02 09:51:07 ART 2015 ;; MSG SIZE rcvd: 35 *********************************************** [root at pc01 ~]# nslookup server Server: 192.168.56.2 Address: 192.168.56.2#53 Name: server.estudio.local Address: 192.168.56.2 *********************************************** Here I disable chronyd so I can run the script without NTP sync errors: [root at pc01 ~]# systemctl disable chronyd Removed symlink /etc/systemd/system/multi-user.target.wants/chronyd.service. [root at pc01 ~]# service chronyd stop Redirecting to /bin/systemctl stop chronyd.service *********************************************** Without having "server.estudio.local" on /etc/hosts file: [root at pc01 ~]# ipa-client-install --enable-dns-updates --mkhomedir --ssh-trust-dns Skip server.estudio.local: cannot verify if this is an IPA server Provide your IPA server name (ex: ipa.example.com): server.estudio.local Skip server.estudio.local: cannot verify if this is an IPA server Failed to verify that server.estudio.local is an IPA Server. This may mean that the remote server is not up or is not reachable due to network or firewall settings. 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. IPA client is not configured on this system. *********************************************** Here I added hostname and IP address to /etc/hosts file (don't know why it doesn't work without it): [root at pc01 ~]# ipa-client-install --enable-dns-updates --mkhomedir --ssh-trust-dns Discovery was successful! Hostname: pc01.estudio.local Realm: ESTUDIO.LOCAL DNS Domain: estudio.local IPA Server: server.estudio.local BaseDN: dc=estudio,dc=local Continue to configure the system with these values? [no]: yes Synchronizing time with KDC... User authorized to enroll computers: admin Password for admin at ESTUDIO.LOCAL: Successfully retrieved CA cert Subject: CN=Certificate Authority,O=ESTUDIO.LOCAL Issuer: CN=Certificate Authority,O=ESTUDIO.LOCAL Valid From: Fri Jan 30 12:02:01 2015 UTC Valid Until: Tue Jan 30 12:02:01 2035 UTC Enrolled in IPA realm ESTUDIO.LOCAL Created /etc/ipa/default.conf New SSSD config will be created Configured sudoers in /etc/nsswitch.conf Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm ESTUDIO.LOCAL trying https://server.estudio.local/ipa/json Forwarding 'ping' to json server 'https://server.estudio.local/ipa/json' Cannot connect to the server due to Kerberos error: Kerberos error: ('Unspecified GSS failure. Minor code may provide more information', 851968)/("Cannot contact any KDC for realm 'ESTUDIO.LOCAL'", -1765328228). Trying with delegate=True trying https://server.estudio.local/ipa/json Forwarding 'ping' to json server 'https://server.estudio.local/ipa/json' Second connect with delegate=True also failed: Kerberos error: ('Unspecified GSS failure. Minor code may provide more information', 851968)/("Cannot contact any KDC for realm 'ESTUDIO.LOCAL'", -1765328228) Cannot connect to the IPA server RPC interface: Kerberos error: ('Unspecified GSS failure. Minor code may provide more information', 851968)/("Cannot contact any KDC for realm 'ESTUDIO.LOCAL'", -1765328228) Installation failed. Rolling back changes. Failed to list certificates in /etc/ipa/nssdb: Command ''/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L'' returned non-zero exit status 255 Failed to remove /etc/ipa/nssdb/cert8.db: [Errno 2] No existe el fichero o el directorio: '/etc/ipa/nssdb/cert8.db' Failed to remove /etc/ipa/nssdb/key3.db: [Errno 2] No existe el fichero o el directorio: '/etc/ipa/nssdb/key3.db' Failed to remove /etc/ipa/nssdb/secmod.db: [Errno 2] No existe el fichero o el directorio: '/etc/ipa/nssdb/secmod.db' Failed to remove /etc/ipa/nssdb/pwdfile.txt: [Errno 2] No existe el fichero o el directorio: '/etc/ipa/nssdb/pwdfile.txt' Unenrolling client from IPA server Unenrolling host failed: Error getting default Kerberos realm: host/domain name not found. Removing Kerberos service principals from /etc/krb5.keytab 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 nscd daemon is not installed, skip configuration nslcd daemon is not installed, skip configuration Client uninstall complete. *********************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Feb 2 14:42:47 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 02 Feb 2015 09:42:47 -0500 Subject: [Freeipa-users] JSON error enrolling host (Fedora 21 / IPA 4.1.2) In-Reply-To: References: Message-ID: <54CF8CE7.7050101@redhat.com> On 02/02/2015 08:13 AM, Gerardo Cuppari wrote: > Hello! I am trying to enroll one host to my IPA server (4.1.2) and I > am having one problem: the ipa-client-install script keeps giving me > errors at the "forwarding ping to json server" step. > > My configuration is: > - server.estudio.local192.168.56.2Fedora Server 21ipa 4.1.2 > - pc01.estudio.local192.168.56.106Fedora Works. 21 > > Both have firewalld down (just to test) and can reach each other. I've > been trying to get this working without success (solved other minor > issues) and so I'm asking for your help. > The only way I can make it work is by adding the --force switch to > ipa-client-install script but, that way, it just disregards errors. > > Thanks in advance!!! > > Here are my tests: > > SERVER > ====== > [root at server ~]# ipa ping > ------------------------------------------- > IPA server version 4.1.2. API version 2.109 > ------------------------------------------- > > CLIENT > ====== > [root at pc01 ~]# dig server > > ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> server > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29286 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;server. IN A > > ;; Query time: 10 msec > ;; SERVER: 192.168.56.2#53(192.168.56.2) > ;; WHEN: lun feb 02 09:51:07 ART 2015 > ;; MSG SIZE rcvd: 35 > > *********************************************** > > [root at pc01 ~]# nslookup server > Server: 192.168.56.2 > Address: 192.168.56.2#53 > > Name: server.estudio.local > Address: 192.168.56.2 > > *********************************************** > > Here I disable chronyd so I can run the script without NTP sync errors: > > [root at pc01 ~]# systemctl disable chronyd > Removed symlink > /etc/systemd/system/multi-user.target.wants/chronyd.service. > [root at pc01 ~]# service chronyd stop > Redirecting to /bin/systemctl stop chronyd.service > > *********************************************** > > Without having "server.estudio.local" on /etc/hosts file: > > [root at pc01 ~]# ipa-client-install --enable-dns-updates --mkhomedir > --ssh-trust-dns > Skip server.estudio.local: cannot verify if this is an IPA server > Provide your IPA server name (ex: ipa.example.com > ): server.estudio.local > Skip server.estudio.local: cannot verify if this is an IPA server > Failed to verify that server.estudio.local is an IPA Server. > This may mean that the remote server is not up or is not reachable due > to network or firewall settings. > 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. > IPA client is not configured on this system. > > > *********************************************** > > Here I added hostname and IP address to /etc/hosts file (don't know > why it doesn't work without it): > > [root at pc01 ~]# ipa-client-install --enable-dns-updates --mkhomedir > --ssh-trust-dns > Discovery was successful! > Hostname: pc01.estudio.local > Realm: ESTUDIO.LOCAL > DNS Domain: estudio.local > IPA Server: server.estudio.local > BaseDN: dc=estudio,dc=local > > Continue to configure the system with these values? [no]: yes > Synchronizing time with KDC... > User authorized to enroll computers: admin > Password for admin at ESTUDIO.LOCAL: > Successfully retrieved CA cert > Subject: CN=Certificate Authority,O=ESTUDIO.LOCAL > Issuer: CN=Certificate Authority,O=ESTUDIO.LOCAL > Valid From: Fri Jan 30 12:02:01 2015 UTC > Valid Until: Tue Jan 30 12:02:01 2035 UTC > > Enrolled in IPA realm ESTUDIO.LOCAL > Created /etc/ipa/default.conf > New SSSD config will be created > Configured sudoers in /etc/nsswitch.conf > Configured /etc/sssd/sssd.conf > Configured /etc/krb5.conf for IPA realm ESTUDIO.LOCAL > trying https://server.estudio.local/ipa/json > Forwarding 'ping' to json server 'https://server.estudio.local/ipa/json' > Cannot connect to the server due to Kerberos error: Kerberos error: > ('Unspecified GSS failure. Minor code may provide more information', > 851968)/("Cannot contact any KDC for realm 'ESTUDIO.LOCAL'", > -1765328228). Trying with delegate=True > trying https://server.estudio.local/ipa/json > Forwarding 'ping' to json server 'https://server.estudio.local/ipa/json' > Second connect with delegate=True also failed: Kerberos error: > ('Unspecified GSS failure. Minor code may provide more information', > 851968)/("Cannot contact any KDC for realm 'ESTUDIO.LOCAL'", -1765328228) > Cannot connect to the IPA server RPC interface: Kerberos error: > ('Unspecified GSS failure. Minor code may provide more information', > 851968)/("Cannot contact any KDC for realm 'ESTUDIO.LOCAL'", -1765328228) > Installation failed. Rolling back changes. > Failed to list certificates in /etc/ipa/nssdb: Command > ''/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L'' returned non-zero > exit status 255 > Failed to remove /etc/ipa/nssdb/cert8.db: [Errno 2] No existe el > fichero o el directorio: '/etc/ipa/nssdb/cert8.db' > Failed to remove /etc/ipa/nssdb/key3.db: [Errno 2] No existe el > fichero o el directorio: '/etc/ipa/nssdb/key3.db' > Failed to remove /etc/ipa/nssdb/secmod.db: [Errno 2] No existe el > fichero o el directorio: '/etc/ipa/nssdb/secmod.db' > Failed to remove /etc/ipa/nssdb/pwdfile.txt: [Errno 2] No existe el > fichero o el directorio: '/etc/ipa/nssdb/pwdfile.txt' > Unenrolling client from IPA server > Unenrolling host failed: Error getting default Kerberos realm: > host/domain name not found. > > Removing Kerberos service principals from /etc/krb5.keytab > 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 > nscd daemon is not installed, skip configuration > nslcd daemon is not installed, skip configuration > Client uninstall complete. > > *********************************************** > > > It seems like a DNS issue. It might be that DNS has entries that already define LDAP and Kerberos services but they are not IPA. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Feb 2 15:07:11 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 02 Feb 2015 16:07:11 +0100 Subject: [Freeipa-users] JSON error enrolling host (Fedora 21 / IPA 4.1.2) In-Reply-To: References: Message-ID: <54CF929F.5050905@redhat.com> On 02/02/15 14:13, Gerardo Cuppari wrote: > Hello! I am trying to enroll one host to my IPA server (4.1.2) and I > am having one problem: the ipa-client-install script keeps giving me > errors at the "forwarding ping to json server" step. > > My configuration is: > - server.estudio.local192.168.56.2Fedora Server 21ipa 4.1.2 > - pc01.estudio.local192.168.56.106Fedora Works. 21 > > Both have firewalld down (just to test) and can reach each other. I've > been trying to get this working without success (solved other minor > issues) and so I'm asking for your help. > The only way I can make it work is by adding the --force switch to > ipa-client-install script but, that way, it just disregards errors. > > Thanks in advance!!! > > Here are my tests: > > SERVER > ====== > [root at server ~]# ipa ping > ------------------------------------------- > IPA server version 4.1.2. API version 2.109 > ------------------------------------------- > > CLIENT > ====== > [root at pc01 ~]# dig server > > ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> server > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29286 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;server. IN A > > ;; Query time: 10 msec > ;; SERVER: 192.168.56.2#53(192.168.56.2) > ;; WHEN: lun feb 02 09:51:07 ART 2015 > ;; MSG SIZE rcvd: 35 > > *********************************************** > > [root at pc01 ~]# nslookup server > Server: 192.168.56.2 > Address: 192.168.56.2#53 > > Name: server.estudio.local > Address: 192.168.56.2 > > *********************************************** > > Here I disable chronyd so I can run the script without NTP sync errors: > > [root at pc01 ~]# systemctl disable chronyd > Removed symlink > /etc/systemd/system/multi-user.target.wants/chronyd.service. > [root at pc01 ~]# service chronyd stop > Redirecting to /bin/systemctl stop chronyd.service > > *********************************************** > > Without having "server.estudio.local" on /etc/hosts file: > > [root at pc01 ~]# ipa-client-install --enable-dns-updates --mkhomedir > --ssh-trust-dns > Skip server.estudio.local: cannot verify if this is an IPA server > Provide your IPA server name (ex: ipa.example.com > ): server.estudio.local > Skip server.estudio.local: cannot verify if this is an IPA server > Failed to verify that server.estudio.local is an IPA Server. > This may mean that the remote server is not up or is not reachable due > to network or firewall settings. > 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. > IPA client is not configured on this system. > > > *********************************************** > > Here I added hostname and IP address to /etc/hosts file (don't know > why it doesn't work without it): > > [root at pc01 ~]# ipa-client-install --enable-dns-updates --mkhomedir > --ssh-trust-dns > Discovery was successful! > Hostname: pc01.estudio.local > Realm: ESTUDIO.LOCAL > DNS Domain: estudio.local > IPA Server: server.estudio.local > BaseDN: dc=estudio,dc=local > > Continue to configure the system with these values? [no]: yes > Synchronizing time with KDC... > User authorized to enroll computers: admin > Password for admin at ESTUDIO.LOCAL: > Successfully retrieved CA cert > Subject: CN=Certificate Authority,O=ESTUDIO.LOCAL > Issuer: CN=Certificate Authority,O=ESTUDIO.LOCAL > Valid From: Fri Jan 30 12:02:01 2015 UTC > Valid Until: Tue Jan 30 12:02:01 2035 UTC > > Enrolled in IPA realm ESTUDIO.LOCAL > Created /etc/ipa/default.conf > New SSSD config will be created > Configured sudoers in /etc/nsswitch.conf > Configured /etc/sssd/sssd.conf > Configured /etc/krb5.conf for IPA realm ESTUDIO.LOCAL > trying https://server.estudio.local/ipa/json > Forwarding 'ping' to json server 'https://server.estudio.local/ipa/json' > Cannot connect to the server due to Kerberos error: Kerberos error: > ('Unspecified GSS failure. Minor code may provide more information', > 851968)/("Cannot contact any KDC for realm 'ESTUDIO.LOCAL'", > -1765328228). Trying with delegate=True > trying https://server.estudio.local/ipa/json > Forwarding 'ping' to json server 'https://server.estudio.local/ipa/json' > Second connect with delegate=True also failed: Kerberos error: > ('Unspecified GSS failure. Minor code may provide more information', > 851968)/("Cannot contact any KDC for realm 'ESTUDIO.LOCAL'", -1765328228) > Cannot connect to the IPA server RPC interface: Kerberos error: > ('Unspecified GSS failure. Minor code may provide more information', > 851968)/("Cannot contact any KDC for realm 'ESTUDIO.LOCAL'", -1765328228) > Installation failed. Rolling back changes. > Failed to list certificates in /etc/ipa/nssdb: Command > ''/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L'' returned non-zero > exit status 255 > Failed to remove /etc/ipa/nssdb/cert8.db: [Errno 2] No existe el > fichero o el directorio: '/etc/ipa/nssdb/cert8.db' > Failed to remove /etc/ipa/nssdb/key3.db: [Errno 2] No existe el > fichero o el directorio: '/etc/ipa/nssdb/key3.db' > Failed to remove /etc/ipa/nssdb/secmod.db: [Errno 2] No existe el > fichero o el directorio: '/etc/ipa/nssdb/secmod.db' > Failed to remove /etc/ipa/nssdb/pwdfile.txt: [Errno 2] No existe el > fichero o el directorio: '/etc/ipa/nssdb/pwdfile.txt' > Unenrolling client from IPA server > Unenrolling host failed: Error getting default Kerberos realm: > host/domain name not found. > > Removing Kerberos service principals from /etc/krb5.keytab > 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 > nscd daemon is not installed, skip configuration > nslcd daemon is not installed, skip configuration > Client uninstall complete. > > *********************************************** > > > Hello dig returns servfail, it may be issue. Can you check please /etc/named.conf on server, if there is dnssec-validation true ? If yes, please set the dnssec-validation to no, because you use domain name .local. it may cause troubles. If troubles persist, please send journalctl -u named-pkcs11 log. Martin^2 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Feb 2 15:17:49 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 02 Feb 2015 16:17:49 +0100 Subject: [Freeipa-users] JSON error enrolling host (Fedora 21 / IPA 4.1.2) In-Reply-To: <54CF929F.5050905@redhat.com> References: <54CF929F.5050905@redhat.com> Message-ID: <54CF951D.4090203@redhat.com> On 02/02/15 16:07, Martin Basti wrote: > On 02/02/15 14:13, Gerardo Cuppari wrote: >> Hello! I am trying to enroll one host to my IPA server (4.1.2) and I >> am having one problem: the ipa-client-install script keeps giving me >> errors at the "forwarding ping to json server" step. >> >> My configuration is: >> - server.estudio.local192.168.56.2Fedora Server 21ipa 4.1.2 >> - pc01.estudio.local192.168.56.106Fedora Works. 21 >> >> Both have firewalld down (just to test) and can reach each other. >> I've been trying to get this working without success (solved other >> minor issues) and so I'm asking for your help. >> The only way I can make it work is by adding the --force switch to >> ipa-client-install script but, that way, it just disregards errors. >> >> Thanks in advance!!! >> >> Here are my tests: >> >> SERVER >> ====== >> [root at server ~]# ipa ping >> ------------------------------------------- >> IPA server version 4.1.2. API version 2.109 >> ------------------------------------------- >> >> CLIENT >> ====== >> [root at pc01 ~]# dig server >> >> ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> server >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29286 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;server. IN A >> >> ;; Query time: 10 msec >> ;; SERVER: 192.168.56.2#53(192.168.56.2) >> ;; WHEN: lun feb 02 09:51:07 ART 2015 >> ;; MSG SIZE rcvd: 35 >> >> *********************************************** >> >> [root at pc01 ~]# nslookup server >> Server: 192.168.56.2 >> Address: 192.168.56.2#53 >> >> Name: server.estudio.local >> Address: 192.168.56.2 >> >> *********************************************** >> >> Here I disable chronyd so I can run the script without NTP sync errors: >> >> [root at pc01 ~]# systemctl disable chronyd >> Removed symlink >> /etc/systemd/system/multi-user.target.wants/chronyd.service. >> [root at pc01 ~]# service chronyd stop >> Redirecting to /bin/systemctl stop chronyd.service >> >> *********************************************** >> >> Without having "server.estudio.local" on /etc/hosts file: >> >> [root at pc01 ~]# ipa-client-install --enable-dns-updates --mkhomedir >> --ssh-trust-dns >> Skip server.estudio.local: cannot verify if this is an IPA server >> Provide your IPA server name (ex: ipa.example.com >> ): >> Skip server.estudio.local: cannot verify if this is an IPA server >> Failed to verify that server.estudio.local is an IPA Server. >> This may mean that the remote server is not up or is not reachable >> due to network or firewall settings. >> 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. >> IPA client is not configured on this system. >> >> >> *********************************************** >> >> Here I added hostname and IP address to /etc/hosts file (don't know >> why it doesn't work without it): >> >> [root at pc01 ~]# ipa-client-install --enable-dns-updates --mkhomedir >> --ssh-trust-dns >> Discovery was successful! >> Hostname: pc01.estudio.local >> Realm: ESTUDIO.LOCAL >> DNS Domain: estudio.local >> IPA Server: server.estudio.local >> BaseDN: dc=estudio,dc=local >> >> Continue to configure the system with these values? [no]: yes >> Synchronizing time with KDC... >> User authorized to enroll computers: admin >> Password for admin at ESTUDIO.LOCAL: >> Successfully retrieved CA cert >> Subject: CN=Certificate Authority,O=ESTUDIO.LOCAL >> Issuer: CN=Certificate Authority,O=ESTUDIO.LOCAL >> Valid From: Fri Jan 30 12:02:01 2015 UTC >> Valid Until: Tue Jan 30 12:02:01 2035 UTC >> >> Enrolled in IPA realm ESTUDIO.LOCAL >> Created /etc/ipa/default.conf >> New SSSD config will be created >> Configured sudoers in /etc/nsswitch.conf >> Configured /etc/sssd/sssd.conf >> Configured /etc/krb5.conf for IPA realm ESTUDIO.LOCAL >> trying https://server.estudio.local/ipa/json >> Forwarding 'ping' to json server 'https://server.estudio.local/ipa/json' >> Cannot connect to the server due to Kerberos error: Kerberos error: >> ('Unspecified GSS failure. Minor code may provide more information', >> 851968)/("Cannot contact any KDC for realm 'ESTUDIO.LOCAL'", >> -1765328228). Trying with delegate=True >> trying https://server.estudio.local/ipa/json >> Forwarding 'ping' to json server 'https://server.estudio.local/ipa/json' >> Second connect with delegate=True also failed: Kerberos error: >> ('Unspecified GSS failure. Minor code may provide more information', >> 851968)/("Cannot contact any KDC for realm 'ESTUDIO.LOCAL'", -1765328228) >> Cannot connect to the IPA server RPC interface: Kerberos error: >> ('Unspecified GSS failure. Minor code may provide more information', >> 851968)/("Cannot contact any KDC for realm 'ESTUDIO.LOCAL'", -1765328228) >> Installation failed. Rolling back changes. >> Failed to list certificates in /etc/ipa/nssdb: Command >> ''/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L'' returned non-zero >> exit status 255 >> Failed to remove /etc/ipa/nssdb/cert8.db: [Errno 2] No existe el >> fichero o el directorio: '/etc/ipa/nssdb/cert8.db' >> Failed to remove /etc/ipa/nssdb/key3.db: [Errno 2] No existe el >> fichero o el directorio: '/etc/ipa/nssdb/key3.db' >> Failed to remove /etc/ipa/nssdb/secmod.db: [Errno 2] No existe el >> fichero o el directorio: '/etc/ipa/nssdb/secmod.db' >> Failed to remove /etc/ipa/nssdb/pwdfile.txt: [Errno 2] No existe el >> fichero o el directorio: '/etc/ipa/nssdb/pwdfile.txt' >> Unenrolling client from IPA server >> Unenrolling host failed: Error getting default Kerberos realm: >> host/domain name not found. >> >> Removing Kerberos service principals from /etc/krb5.keytab >> 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 >> nscd daemon is not installed, skip configuration >> nslcd daemon is not installed, skip configuration >> Client uninstall complete. >> >> *********************************************** >> >> >> > Hello > > dig returns servfail, it may be issue. You used dig with wrong name, please use dig server.estudio.local and send result? > > Can you check please /etc/named.conf on server, if there is > dnssec-validation true ? > If yes, please set the dnssec-validation to no, because you use domain > name .local. it may cause troubles. > > If troubles persist, please send journalctl -u named-pkcs11 log. > > Martin^2 > > -- > Martin Basti > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From gcuppari at gmail.com Mon Feb 2 16:04:57 2015 From: gcuppari at gmail.com (Gerardo Cuppari) Date: Mon, 2 Feb 2015 13:04:57 -0300 Subject: [Freeipa-users] JSON error enrolling host (Fedora 21 / IPA 4.1.2) Message-ID: Well, I just reinstalled everything without the ".local" in the domain and everything worked at first. Sorry for the troubles... Odd is that with ipa 3 on Centos 7 everything worked with domain "estudio.local" Thanks again! -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Feb 2 19:33:18 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Feb 2015 21:33:18 +0200 Subject: [Freeipa-users] JSON error enrolling host (Fedora 21 / IPA 4.1.2) In-Reply-To: References: Message-ID: <20150202193318.GC6592@redhat.com> On Mon, 02 Feb 2015, Gerardo Cuppari wrote: >Well, I just reinstalled everything without the ".local" in the domain and >everything worked at first. Sorry for the troubles... > >Odd is that with ipa 3 on Centos 7 everything worked with domain >"estudio.local" Do you have avahi activated and 'hosts: files mdns4_minimal [notfound=RETURN] ...' in your /etc/nsswitch.conf? Avahi overtakes .local domain because RFC 6762 reserves .local for multicast DNS name resolution protocol. http://en.wikipedia.org/wiki/.local#Multicast_DNS_standard "Any DNS query for a name ending with .local MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB)?" Fedora chose to follow this policy and force use of mDNS resolver through [notfound=RETURN] option (i.e., get .local names resolved via /etc/hosts and mDNS only). -- / Alexander Bokovoy From genadipost at gmail.com Mon Feb 2 21:35:44 2015 From: genadipost at gmail.com (Genadi Postrilko) Date: Mon, 2 Feb 2015 23:35:44 +0200 Subject: [Freeipa-users] sssd compatibility with older RHEL 6 minor releases. In-Reply-To: <54CD6EB5.3090105@redhat.com> References: <54CD6EB5.3090105@redhat.com> Message-ID: Thank you for your reply. I think ill go with the first option, it about time to upgrade :). Genadi. 2015-02-01 2:09 GMT+02:00 Dmitri Pal : > On 01/31/2015 01:37 PM, Genadi Postrilko wrote: > > Hello all. > > The environment i'm currently working to migrate under IPA identity > management contains mostly RHEL 6.2 servers. > I'm planing to use Active Directory Cross Forest Trust for Identities, IPA > as sudo provider, and all the other goodies that IPA provides. > > If i want to enjoy all the new features (at least most of them), i know > that clients have to be sssd version > 1.9. And if i want IPA to be auto > configured as sudo provider it has to be sssd > 1.11. > > When reading the mailing list i noticed that sssd 1.11 is mentioned as > feature of rhel 6.6. > What i would like and understand is what could go wrong if i will install > sssd 1.11 on rhel 6.2 servers.And what is is your general recommendations > for older RHEL 6 (minor) releases? > > > It will pull a lot of dependencies and most of your system will look like > 6.6 system > Also the upgrade like this might reveal some issues as the upgrades are > expected to be gradual. 1-2 versions is ok but 4 is quit a big leap. > > Overall it is a bit risky to do it. > You have three options: > - upgrade properly but probably in two steps 6.2 -> 6.4 -> 6.6 > - use SSSD from 6.2 as is for now. It will have limited functionality but > can leverage AD users from the trust. You would need to configure SSSD to > use LDAP for authentication and point to compat tree of IPA to take > advantage of the trust. See details here: > http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf > - take your chances and try a hybrid you propose but it is not a formally > supported configuration. > > > Thanks in advance, > Genadi. > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Mon Feb 2 22:05:36 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 2 Feb 2015 22:05:36 +0000 Subject: [Freeipa-users] sssd compatibility with older RHEL 6 minor releases. In-Reply-To: References: <54CD6EB5.3090105@redhat.com>, Message-ID: <1422914620759.84954@vuw.ac.nz> Hi, Not knowing your specific circumstance but my experience over the last decade plus would be keep the RHEL, Debian/Ubuntu and Solaris servers up to date all the time, or at least 1~2 months behind max. eg we clone off RHEL channels into testing channels and patch then clone production from test and patch. (playing catch now is now a risk for you) If there is an issue with a rpm then you will find it and we then for instance freeze patching until it is resolved. If you dont have a test group of servers run 1~2months behind the latest and import specific rpms if a nasty bug appears eg the recent bash one. regards Steven ________________________________ From: freeipa-users-bounces at redhat.com on behalf of Genadi Postrilko Sent: Tuesday, 3 February 2015 10:35 a.m. To: Identity Managment; freeipa-users at redhat.com Subject: Re: [Freeipa-users] sssd compatibility with older RHEL 6 minor releases. Thank you for your reply. I think ill go with the first option, it about time to upgrade :). Genadi. 2015-02-01 2:09 GMT+02:00 Dmitri Pal >: On 01/31/2015 01:37 PM, Genadi Postrilko wrote: Hello all. The environment i'm currently working to migrate under IPA identity management contains mostly RHEL 6.2 servers. I'm planing to use Active Directory Cross Forest Trust for Identities, IPA as sudo provider, and all the other goodies that IPA provides. If i want to enjoy all the new features (at least most of them), i know that clients have to be sssd version > 1.9. And if i want IPA to be auto configured as sudo provider it has to be sssd > 1.11. When reading the mailing list i noticed that sssd 1.11 is mentioned as feature of rhel 6.6. What i would like and understand is what could go wrong if i will install sssd 1.11 on rhel 6.2 servers.And what is is your general recommendations for older RHEL 6 (minor) releases? It will pull a lot of dependencies and most of your system will look like 6.6 system Also the upgrade like this might reveal some issues as the upgrades are expected to be gradual. 1-2 versions is ok but 4 is quit a big leap. Overall it is a bit risky to do it. You have three options: - upgrade properly but probably in two steps 6.2 -> 6.4 -> 6.6 - use SSSD from 6.2 as is for now. It will have limited functionality but can leverage AD users from the trust. You would need to configure SSSD to use LDAP for authentication and point to compat tree of IPA to take advantage of the trust. See details here: http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf - take your chances and try a hybrid you propose but it is not a formally supported configuration. Thanks in advance, Genadi. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: From william at firstyear.id.au Tue Feb 3 02:58:09 2015 From: william at firstyear.id.au (William) Date: Tue, 03 Feb 2015 13:28:09 +1030 Subject: [Freeipa-users] IPA-adtrust and addition of replicas In-Reply-To: <20150202080244.GA6592@redhat.com> References: <1422765524.4790.3.camel@firstyear.id.au> <20150201154935.GZ6592@redhat.com> <1422831403.3928.8.camel@firstyear.id.au> <20150202080244.GA6592@redhat.com> Message-ID: <1422932289.2744.4.camel@firstyear.id.au> > >Wow! From all this it really sounds like adding a replica in to an IPA > >domain where adtrust has been run could have a few edge cases. For > >example, what would happen if I create a new account on a replica > >without adtrust? Would sidgen run on the adtrust machine when it get's > >the record replicated to it? > I think it might work. sidgen is a post operation and replication > protocol uses normal ldap_*_ext() API to send new objects. > Maybe something to test? > >> What I realized now is that with FreeIPA 3.3+ we moved ID resolution > >> fully to SSSD and we technically don't need to run full 'domain > >> controller' stack (e.g. Samba) on a master that only wants to resolve > >> IDs rather than participating in a balancing of the domain controller > >> duties. > > > >What are the domain controller duties separate from the ID resolution > >tasks? What components carry out the id resolution? > In discussing with Simo yesterday, we came to conclusion that we would > call a 'full' master that provides features for trust as a 'trust > controller'. Let's call the other configuration a 'trust agent'. > > A trust controller is a FreeIPA master which hosts: > - LDAP server with sigden, extdom, and cldap plugins > - KDC with IPA driver > - Samba configured with ipasam PASSDB module > - SSSD with ipa_server_mode=True > - Global Catalog instance (a separate LDAP instance with an > AD-compatible schema) > > A trust agent is a FreeIPA master which hosts > - LDAP server with sigden and extdom > - KDC with IPA driver > - SSSD with ipa_server_mode=True > > As you can see, trus agent is a master that relies on SSSD to do > resolution of IDs. Trust controller is used for managing trust: add > trust agreements, enable/disable separate domains from a trusted forest > to access FreeIPA resources, etc. Trust controller is also what Active > Directory's domain controllers contact when validating the trust by > means of SMB protocol using LSA calls which implies running a Samba server. This seems like a clean and logical separation. > > > >This should be configured on replicas added to the network if adtrust > >has been run already. Perhaps this is something to consider also? > >Consistency through out the domain is a good thing. > Exactly. Good suggestion. One thing we need to solve here is that > enabling sidgen and other components will require installing Samba > libraries. This is something to consider -- do we want these libraries > (not daemons) installed on every master? Well, ipa-adtrust is a seperate package already isn't it? If you were in the position to be setting up an adtrust on freeipa, you would document that it should be installed on all hosts anyway, so then the adtrust package would pull in the adtrust libs. Once the adtrust is installed, be it trust controller or agent, perhaps this should be added into the domain services tree under cn=etc. That way, after the adtrust is run, you can see a list of hosts that do not yet have it installed, so that the trust agent can be configured on all other replicas. Additionally, adding a new replica could be hinted that if this exists to configure itself as a trust agent automatically as part of ipa-replica-install. Does that sound like a reasonable suggestion? From abokovoy at redhat.com Tue Feb 3 05:48:28 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 3 Feb 2015 07:48:28 +0200 Subject: [Freeipa-users] IPA-adtrust and addition of replicas In-Reply-To: <1422932289.2744.4.camel@firstyear.id.au> References: <1422765524.4790.3.camel@firstyear.id.au> <20150201154935.GZ6592@redhat.com> <1422831403.3928.8.camel@firstyear.id.au> <20150202080244.GA6592@redhat.com> <1422932289.2744.4.camel@firstyear.id.au> Message-ID: <20150203054828.GD6592@redhat.com> On Tue, 03 Feb 2015, William wrote: > >> >Wow! From all this it really sounds like adding a replica in to an IPA >> >domain where adtrust has been run could have a few edge cases. For >> >example, what would happen if I create a new account on a replica >> >without adtrust? Would sidgen run on the adtrust machine when it get's >> >the record replicated to it? >> I think it might work. sidgen is a post operation and replication >> protocol uses normal ldap_*_ext() API to send new objects. >> > >Maybe something to test? You can create a user on the replica without ipa-adtrust-install and watch after replication on whether ipaNTSecurityIdentifier appeared in the user's object in LDAP. >> >This should be configured on replicas added to the network if adtrust >> >has been run already. Perhaps this is something to consider also? >> >Consistency through out the domain is a good thing. >> Exactly. Good suggestion. One thing we need to solve here is that >> enabling sidgen and other components will require installing Samba >> libraries. This is something to consider -- do we want these libraries >> (not daemons) installed on every master? > >Well, ipa-adtrust is a seperate package already isn't it? If you were in >the position to be setting up an adtrust on freeipa, you would document >that it should be installed on all hosts anyway, so then the adtrust >package would pull in the adtrust libs. > >Once the adtrust is installed, be it trust controller or agent, perhaps >this should be added into the domain services tree under cn=etc. That >way, after the adtrust is run, you can see a list of hosts that do not >yet have it installed, so that the trust agent can be configured on all >other replicas. Additionally, adding a new replica could be hinted that >if this exists to configure itself as a trust agent automatically as >part of ipa-replica-install. > >Does that sound like a reasonable suggestion? Yes, this is what ipa-adtrust-install implements right now. My issue with this approach is the fact that we don't want to run smbd/winbindd/etc for trust agent case. Yet, ipa-adtrust-install forces packages to be installed and services to be active. We can start with disabling ADTRUST and EXTID services on trust agents (these are smb and winbind in ipactl speak) and, maybe, rename them to something less confusing. Then we can decide whether not installing samba server packages would really be needed. -- / Alexander Bokovoy From roberto.cornacchia at gmail.com Tue Feb 3 12:20:21 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Tue, 3 Feb 2015 13:20:21 +0100 Subject: [Freeipa-users] basic question on DNS configuration Message-ID: Hi guys, I can't wait to get freeIPA installed in our small enterprise, but I'd first like to get a couple of basic things straight. My first doubt is about the DNS configuration. Currently, we use a setting that I guess is rather common for small enterprises: We own an example.com domain which is managed by the DNS of an external provider. A couple of subdomains point to public IP addresses outside our local network (e.g. www.example.com is hosted at our internet provider, server1.example.com points at a server hosted in a datacenter, etc). All the remaining subdomain (*.example.com) point at one IP which corresponds to our local router. Then we use some simple forwarding rules to forward on to machines that are behind the router (service1.example.com, desktop1.example.com, desktop2.example.com, etc). Internally, because the enterprise is rather small, we are not using a DNS, but simply /etc/hosts files on each machine. When they can't resolve whatever.example.com, then the request goes to the external DNS. (sorry about the long-ish background information, probably this configuration is commonly named somehow, but I don't know how) Now, a first simple question for you guys would be: When installing freeIPA, with DNS, is the network configuration above still advisable? Can there be any problem? Or should I rather use a different domain for the internal network (I would really NOT like this option, but I'm very interested to know why I should, if that is the case). A second basic question is: Would you see any potential problem in installing freeIPA on a FC21 Server which currently hosts Atlassian Jira + Atlassian Stash (therefore git repositories) + the required mysql databases? My guess would be that they would not interfere, as: - httpd (and related ports) is currently unused) - Both Jira and Stash use thier own tomcat installation on custom ports - mysql shouldn't be a problem? - The machine isn't overloaded at all (4-5 developers use those services) Am I overlooking something? Obviously I'd rather have a dedicated freeIPA server, but if the above mentioned coexistence isn't a problem, then this would be more cost-effective. Thank you very much for your help, I'm looking forward to this upgrade. Roberto -------------- next part -------------- An HTML attachment was scrubbed... URL: From gcuppari at gmail.com Tue Feb 3 12:48:35 2015 From: gcuppari at gmail.com (Gerardo Cuppari) Date: Tue, 3 Feb 2015 09:48:35 -0300 Subject: [Freeipa-users] JSON error enrolling host (Fedora 21 / IPA 4.1.2) In-Reply-To: <20150202193318.GC6592@redhat.com> References: <20150202193318.GC6592@redhat.com> Message-ID: Well, that explains why I had a lot of mDNS traffic flowing... Finally I just removed the ".local" from the domain and everything works as intended. Now I am fighting with autofs and kerberized NFS... Is there any up-to-date guide that you can point me to? Thanks! 2015-02-02 16:33 GMT-03:00 Alexander Bokovoy : > On Mon, 02 Feb 2015, Gerardo Cuppari wrote: > >> Well, I just reinstalled everything without the ".local" in the domain and >> everything worked at first. Sorry for the troubles... >> >> Odd is that with ipa 3 on Centos 7 everything worked with domain >> "estudio.local" >> > Do you have avahi activated and 'hosts: files mdns4_minimal > [notfound=RETURN] ...' > in your /etc/nsswitch.conf? > > Avahi overtakes .local domain because RFC 6762 reserves .local for > multicast DNS name resolution protocol. > > http://en.wikipedia.org/wiki/.local#Multicast_DNS_standard > > "Any DNS query for a name ending with .local MUST be sent to the mDNS > IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent > FF02::FB)?" > > Fedora chose to follow this policy and force use of mDNS resolver > through [notfound=RETURN] option (i.e., get .local names resolved via > /etc/hosts and mDNS only). > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gcuppari at gmail.com Mon Feb 2 15:34:43 2015 From: gcuppari at gmail.com (Gerardo Cuppari) Date: Mon, 2 Feb 2015 12:34:43 -0300 Subject: [Freeipa-users] JSON error enrolling host (Fedora 21 / IPA 4.1.2) In-Reply-To: <54CF951D.4090203@redhat.com> References: <54CF929F.5050905@redhat.com> <54CF951D.4090203@redhat.com> Message-ID: Hi Martin, thanks for your replies! Please, don't tell me I am getting all these errors because of the ".local" domain! If so, I will surelly kill someone haha I checked /etc/named.conf and changed to "no" dnssec-validation and here is what you requested: [root at pc01 ~]# dig server.estudio.local ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> server.estudio.local ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31554 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;server.estudio.local. IN A ;; ANSWER SECTION: server.estudio.local. 1200 IN A 192.168.56.2 ;; AUTHORITY SECTION: estudio.local. 86400 IN NS server.estudio.local. ;; Query time: 0 msec ;; SERVER: 192.168.56.2#53(192.168.56.2) ;; WHEN: lun feb 02 12:29:17 ART 2015 ;; MSG SIZE rcvd: 79 ****************************************** [root at pc01 ~]# dig -t ptr 2.56.168.192.in-addr.arpa ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> -t ptr 2.56.168.192.in-addr.arpa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36167 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;2.56.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 2.56.168.192.in-addr.arpa. 86400 IN PTR server.estudio.local. ;; AUTHORITY SECTION: 56.168.192.in-addr.arpa. 86400 IN NS server.estudio.local. ;; ADDITIONAL SECTION: server.estudio.local. 1200 IN A 192.168.56.2 ;; Query time: 0 msec ;; SERVER: 192.168.56.2#53(192.168.56.2) ;; WHEN: lun feb 02 12:34:27 ART 2015 ;; MSG SIZE rcvd: 118 2015-02-02 12:17 GMT-03:00 Martin Basti : > On 02/02/15 16:07, Martin Basti wrote: > > On 02/02/15 14:13, Gerardo Cuppari wrote: > > Hello! I am trying to enroll one host to my IPA server (4.1.2) and I am > having one problem: the ipa-client-install script keeps giving me errors at > the "forwarding ping to json server" step. > > My configuration is: > - server.estudio.local 192.168.56.2 Fedora Server 21 ipa 4.1.2 > - pc01.estudio.local 192.168.56.106 Fedora Works. 21 > > Both have firewalld down (just to test) and can reach each other. I've > been trying to get this working without success (solved other minor issues) > and so I'm asking for your help. > The only way I can make it work is by adding the --force switch to > ipa-client-install script but, that way, it just disregards errors. > > Thanks in advance!!! > > Here are my tests: > > SERVER > ====== > [root at server ~]# ipa ping > ------------------------------------------- > IPA server version 4.1.2. API version 2.109 > ------------------------------------------- > > CLIENT > ====== > [root at pc01 ~]# dig server > > ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> server > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29286 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;server. IN A > > ;; Query time: 10 msec > ;; SERVER: 192.168.56.2#53(192.168.56.2) > ;; WHEN: lun feb 02 09:51:07 ART 2015 > ;; MSG SIZE rcvd: 35 > > *********************************************** > > [root at pc01 ~]# nslookup server > Server: 192.168.56.2 > Address: 192.168.56.2#53 > > Name: server.estudio.local > Address: 192.168.56.2 > > *********************************************** > > Here I disable chronyd so I can run the script without NTP sync errors: > > [root at pc01 ~]# systemctl disable chronyd > Removed symlink > /etc/systemd/system/multi-user.target.wants/chronyd.service. > [root at pc01 ~]# service chronyd stop > Redirecting to /bin/systemctl stop chronyd.service > > *********************************************** > > Without having "server.estudio.local" on /etc/hosts file: > > [root at pc01 ~]# ipa-client-install --enable-dns-updates --mkhomedir > --ssh-trust-dns > Skip server.estudio.local: cannot verify if this is an IPA server > Provide your IPA server name (ex: ipa.example.com): > Skip server.estudio.local: cannot verify if this is an IPA server > Failed to verify that server.estudio.local is an IPA Server. > This may mean that the remote server is not up or is not reachable due to > network or firewall settings. > 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. > IPA client is not configured on this system. > > > *********************************************** > > Here I added hostname and IP address to /etc/hosts file (don't know why > it doesn't work without it): > > [root at pc01 ~]# ipa-client-install --enable-dns-updates --mkhomedir > --ssh-trust-dns > Discovery was successful! > Hostname: pc01.estudio.local > Realm: ESTUDIO.LOCAL > DNS Domain: estudio.local > IPA Server: server.estudio.local > BaseDN: dc=estudio,dc=local > > Continue to configure the system with these values? [no]: yes > Synchronizing time with KDC... > User authorized to enroll computers: admin > Password for admin at ESTUDIO.LOCAL: > Successfully retrieved CA cert > Subject: CN=Certificate Authority,O=ESTUDIO.LOCAL > Issuer: CN=Certificate Authority,O=ESTUDIO.LOCAL > Valid From: Fri Jan 30 12:02:01 2015 UTC > Valid Until: Tue Jan 30 12:02:01 2035 UTC > > Enrolled in IPA realm ESTUDIO.LOCAL > Created /etc/ipa/default.conf > New SSSD config will be created > Configured sudoers in /etc/nsswitch.conf > Configured /etc/sssd/sssd.conf > Configured /etc/krb5.conf for IPA realm ESTUDIO.LOCAL > trying https://server.estudio.local/ipa/json > Forwarding 'ping' to json server 'https://server.estudio.local/ipa/json' > Cannot connect to the server due to Kerberos error: Kerberos error: > ('Unspecified GSS failure. Minor code may provide more information', > 851968)/("Cannot contact any KDC for realm 'ESTUDIO.LOCAL'", -1765328228). > Trying with delegate=True > trying https://server.estudio.local/ipa/json > Forwarding 'ping' to json server 'https://server.estudio.local/ipa/json' > Second connect with delegate=True also failed: Kerberos error: > ('Unspecified GSS failure. Minor code may provide more information', > 851968)/("Cannot contact any KDC for realm 'ESTUDIO.LOCAL'", -1765328228) > Cannot connect to the IPA server RPC interface: Kerberos error: > ('Unspecified GSS failure. Minor code may provide more information', > 851968)/("Cannot contact any KDC for realm 'ESTUDIO.LOCAL'", -1765328228) > Installation failed. Rolling back changes. > Failed to list certificates in /etc/ipa/nssdb: Command > ''/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L'' returned non-zero exit > status 255 > Failed to remove /etc/ipa/nssdb/cert8.db: [Errno 2] No existe el fichero o > el directorio: '/etc/ipa/nssdb/cert8.db' > Failed to remove /etc/ipa/nssdb/key3.db: [Errno 2] No existe el fichero o > el directorio: '/etc/ipa/nssdb/key3.db' > Failed to remove /etc/ipa/nssdb/secmod.db: [Errno 2] No existe el fichero > o el directorio: '/etc/ipa/nssdb/secmod.db' > Failed to remove /etc/ipa/nssdb/pwdfile.txt: [Errno 2] No existe el > fichero o el directorio: '/etc/ipa/nssdb/pwdfile.txt' > Unenrolling client from IPA server > Unenrolling host failed: Error getting default Kerberos realm: host/domain > name not found. > > Removing Kerberos service principals from /etc/krb5.keytab > 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 > nscd daemon is not installed, skip configuration > nslcd daemon is not installed, skip configuration > Client uninstall complete. > > *********************************************** > > > > Hello > > dig returns servfail, it may be issue. > > > You used dig with wrong name, please use dig server.estudio.local and > send result? > > > Can you check please /etc/named.conf on server, if there is > dnssec-validation true ? > If yes, please set the dnssec-validation to no, because you use domain > name .local. it may cause troubles. > > If troubles persist, please send journalctl -u named-pkcs11 log. > > Martin^2 > > -- > Martin Basti > > > > > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From CWhite at skytouchtechnology.com Tue Feb 3 15:52:34 2015 From: CWhite at skytouchtechnology.com (Craig White) Date: Tue, 3 Feb 2015 15:52:34 +0000 Subject: [Freeipa-users] basic question on DNS configuration In-Reply-To: References: Message-ID: From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Roberto Cornacchia Sent: Tuesday, February 03, 2015 5:20 AM To: freeipa-users at redhat.com Subject: [Freeipa-users] basic question on DNS configuration Hi guys, I can't wait to get freeIPA installed in our small enterprise, but I'd first like to get a couple of basic things straight. My first doubt is about the DNS configuration. Currently, we use a setting that I guess is rather common for small enterprises: We own an example.com domain which is managed by the DNS of an external provider. A couple of subdomains point to public IP addresses outside our local network (e.g. www.example.com is hosted at our internet provider, server1.example.com points at a server hosted in a datacenter, etc). All the remaining subdomain (*.example.com) point at one IP which corresponds to our local router. Then we use some simple forwarding rules to forward on to machines that are behind the router (service1.example.com, desktop1.example.com, desktop2.example.com, etc). Internally, because the enterprise is rather small, we are not using a DNS, but simply /etc/hosts files on each machine. When they can't resolve whatever.example.com, then the request goes to the external DNS. (sorry about the long-ish background information, probably this configuration is commonly named somehow, but I don't know how) Now, a first simple question for you guys would be: When installing freeIPA, with DNS, is the network configuration above still advisable? Can there be any problem? Or should I rather use a different domain for the internal network (I would really NOT like this option, but I'm very interested to know why I should, if that is the case). A second basic question is: Would you see any potential problem in installing freeIPA on a FC21 Server which currently hosts Atlassian Jira + Atlassian Stash (therefore git repositories) + the required mysql databases? My guess would be that they would not interfere, as: - httpd (and related ports) is currently unused) - Both Jira and Stash use thier own tomcat installation on custom ports - mysql shouldn't be a problem? - The machine isn't overloaded at all (4-5 developers use those services) Am I overlooking something? Obviously I'd rather have a dedicated freeIPA server, but if the above mentioned coexistence isn't a problem, then this would be more cost-effective. Thank you very much for your help, I'm looking forward to this upgrade. Roberto I would recommend that you create a ?local? domain for your internal LAN though you certainly can use your domain name for both the internal LAN and the external world. Obviously you would have to create ?manual? entries in DNS for the external servers (like www.example.com) so your internal LAN systems can resolve it. If you have a ?local? domain for your internal LAN, there aren?t name collisions, no need to manually maintain DNS entries for off-LAN servers and no confusion of essentially faking your LAN systems into believing that the IPA server is authoritative for example.com domain when the rest of the world thinks otherwise. The choice is yours. As for using F21 ? you get the latest version of FreeIPA which is something I wish I had here. Git / Stash / Jira represent a fairly hefty memory footprint even if there isn?t that much CPU load. If you have the RAM and cpu cores to handle tossing FreeIPA onto the stack, go for it. You probably will want a replica too as the replica keeps your LAN running if the primary server is unavailable for whatever reason and it minimizes backup needs substantially. Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Feb 3 16:24:26 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 03 Feb 2015 17:24:26 +0100 Subject: [Freeipa-users] sssd compatibility with older RHEL 6 minor releases. In-Reply-To: References: <54CD6EB5.3090105@redhat.com> Message-ID: <54D0F63A.5050808@redhat.com> Also, when upgrading, please make sure to upgrade to the 6.6.z version of SSSD - there were couple important fixes. AFAIK, the version should be sssd-1.11.6-30.el6_6.3 Martin On 02/02/2015 10:35 PM, Genadi Postrilko wrote: > Thank you for your reply. > I think ill go with the first option, it about time to upgrade :). > > Genadi. > > 2015-02-01 2:09 GMT+02:00 Dmitri Pal : > >> On 01/31/2015 01:37 PM, Genadi Postrilko wrote: >> >> Hello all. >> >> The environment i'm currently working to migrate under IPA identity >> management contains mostly RHEL 6.2 servers. >> I'm planing to use Active Directory Cross Forest Trust for Identities, IPA >> as sudo provider, and all the other goodies that IPA provides. >> >> If i want to enjoy all the new features (at least most of them), i know >> that clients have to be sssd version > 1.9. And if i want IPA to be auto >> configured as sudo provider it has to be sssd > 1.11. >> >> When reading the mailing list i noticed that sssd 1.11 is mentioned as >> feature of rhel 6.6. >> What i would like and understand is what could go wrong if i will install >> sssd 1.11 on rhel 6.2 servers.And what is is your general recommendations >> for older RHEL 6 (minor) releases? >> >> >> It will pull a lot of dependencies and most of your system will look like >> 6.6 system >> Also the upgrade like this might reveal some issues as the upgrades are >> expected to be gradual. 1-2 versions is ok but 4 is quit a big leap. >> >> Overall it is a bit risky to do it. >> You have three options: >> - upgrade properly but probably in two steps 6.2 -> 6.4 -> 6.6 >> - use SSSD from 6.2 as is for now. It will have limited functionality but >> can leverage AD users from the trust. You would need to configure SSSD to >> use LDAP for authentication and point to compat tree of IPA to take >> advantage of the trust. See details here: >> http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf >> - take your chances and try a hybrid you propose but it is not a formally >> supported configuration. >> >> >> Thanks in advance, >> Genadi. >> >> >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > > > From gcuppari at gmail.com Tue Feb 3 16:43:18 2015 From: gcuppari at gmail.com (Gerardo Cuppari) Date: Tue, 3 Feb 2015 13:43:18 -0300 Subject: [Freeipa-users] autofs - nfsnobody Message-ID: Hello there again! I'm bothering you again because I am having some problems with autofs/NFS and IPA. All files created from a regular user (enrolled client) gets the nfsnobody user and group. Folder gets auto mounted. Thanks in advance! Here is what I did to configure it at server (server.estudio) and client (pc01.estudio): SERVER ===== ipa service-add nfs/server.estudio ipa-getkeytab -s server.estudio -p nfs/server.estudio -k /etc/krb5.keytab ipa-client-automount mkdir /export chmod 777 /export echo /export *(rw,sync,sec=sys:krb5:krb5i:krb5p) >> /etc/exports reboot ************************** CLIENT ==== ipa-getkeytab -s server.estudio -p host/server.estudio at ESTUDIO -k /etc/krb5.keytab ipa-client-automount reboot echo aaa >> /export/aaa [user at pc01 /]$ ls -la /export total 12 drwxrwxrwx. 2 root root 4096 feb 3 13:36 . dr-xr-xr-x. 21 root root 4096 feb 3 13:36 .. -rw-rw-r--. 1 nfsnobody nfsnobody 4 feb 3 13:36 aaa -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Feb 3 16:45:50 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 03 Feb 2015 11:45:50 -0500 Subject: [Freeipa-users] JSON error enrolling host (Fedora 21 / IPA 4.1.2) In-Reply-To: References: <20150202193318.GC6592@redhat.com> Message-ID: <54D0FB3E.4040502@redhat.com> On 02/03/2015 07:48 AM, Gerardo Cuppari wrote: > Well, that explains why I had a lot of mDNS traffic flowing... > > Finally I just removed the ".local" from the domain and everything > works as intended. Now I am fighting with autofs and kerberized NFS... http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA > > Is there any up-to-date guide that you can point me to? > Thanks! > > 2015-02-02 16:33 GMT-03:00 Alexander Bokovoy >: > > On Mon, 02 Feb 2015, Gerardo Cuppari wrote: > > Well, I just reinstalled everything without the ".local" in > the domain and > everything worked at first. Sorry for the troubles... > > Odd is that with ipa 3 on Centos 7 everything worked with domain > "estudio.local" > > Do you have avahi activated and 'hosts: files mdns4_minimal > [notfound=RETURN] ...' > in your /etc/nsswitch.conf? > > Avahi overtakes .local domain because RFC 6762 reserves .local for > multicast DNS name resolution protocol. > > http://en.wikipedia.org/wiki/.local#Multicast_DNS_standard > > "Any DNS query for a name ending with .local MUST be sent to the mDNS > IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent > FF02::FB)..." > > Fedora chose to follow this policy and force use of mDNS resolver > through [notfound=RETURN] option (i.e., get .local names resolved via > /etc/hosts and mDNS only). > > -- > / Alexander Bokovoy > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Tue Feb 3 21:33:55 2015 From: Less at imagine-sw.com (Les Stott) Date: Tue, 3 Feb 2015 21:33:55 +0000 Subject: [Freeipa-users] CA Replication Installation Failing In-Reply-To: <4ED173A868981548967B4FCA27072226280A6EA9@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA270722262803F3C5@AACMBXP04.exchserver.com> <4ED173A868981548967B4FCA2707222628048DF6@AACMBXP04.exchserver.com> , <54867F51.1030603@redhat.com> <4ED173A868981548967B4FCA2707222628049113@AACMBXP04.exchserver.com> <1418148291.27499.20.camel@aleeredhat.laptop> <4ED173A868981548967B4FCA270722262804A449@AACMBXP04.exchserver.com> <4ED173A868981548967B4FCA27072226280A6EA9@AACMBXP04.exchserver.com> Message-ID: <4ED173A868981548967B4FCA27072226280AC187@AACMBXP04.exchserver.com> Has anyone got any ideas on this? I am stuck with not being able to deploy a CA Replica and this is halting rollout of the project. Help please... Regards, Les > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Les Stott > Sent: Friday, 30 January 2015 4:48 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] CA Replication Installation Failing > > > > > -----Original Message----- > > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > > bounces at redhat.com] On Behalf Of Les Stott > > Sent: Wednesday, 10 December 2014 6:22 PM > > To: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] CA Replication Installation Failing > > > > > > > > > -----Original Message----- > > > From: Ade Lee [mailto:alee at redhat.com] > > > Sent: Wednesday, 10 December 2014 5:05 AM > > > To: Les Stott > > > Cc: freeipa-users at redhat.com > > > Subject: Re: [Freeipa-users] CA Replication Installation Failing > > > > > > On Tue, 2014-12-09 at 07:48 +0000, Les Stott wrote: > > > > > > > > > > > > > > > > > __________________________________________________________ > > > ____________ > > > > From: freeipa-users-bounces at redhat.com > > > > [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal > > > > [dpal at redhat.com] > > > > Sent: Tuesday, December 09, 2014 3:49 PM > > > > To: freeipa-users at redhat.com > > > > Subject: Re: [Freeipa-users] CA Replication Installation Failing > > > > > > > > > > > > > > > > On 12/08/2014 11:04 PM, Les Stott wrote: > > > > > > > > > Does anyone have any ideas on the below errors when trying to > > > > > add CA replication to an existing replica? > > > > > > > > > > > > > > > > > > > People who might be able to help are or PTO right now. > > > > > > > > > > Is your installation older than 2 years? > > > > > > > > No, December 2013 was when it was originally built. > > > > > > > > > Did you generate a new replica package or use the original one? > > > > > > > > I used the original replica file for serverb, based on > > > > instructions i came across. I can try regenerating the replica file. > > > > > > > > Interestingly, now that you mention it, servera had to be restored > > > > a couple of months back. Perhaps this is an issue and regenerating > > > > the replica file for serverb will be required. > > > > > > > > I will try this. > > > > > > > > > > I think that this is a safe bet to be the problem. > > > > > > The error in the log snippet you posted says: > > > > > > The pkcs12 file is not correct. > > > > > > This indicates that the clone CA was unable to decode the pkcs12 > > > file in the replica. Perhaps the certs changed -- or the DM password > changed? > > > > > > Ade > > > > I regenerated the replica file and retired the CA replica setup, but > > it failed at the same point with the same error. > > > > I am thinking that the next step is to uninstall the ipa replica to > > cleanup, remove all traces and re-add as a replica on serverb. > > > > I wonder if the cert that its having an issue with is the one on > > serverB under /etc/ipa/ca.crt which is from Dec 2013. > > > > I will try that in a couple of days as I have to schedule this work in > > as its in production. > > > > Regards, > > > > Les > > > > > > > > > May be the problem is that the cert that is in that package > > > > > already > > > > expired? > > > > > > > > original replica file was created on Dec 16 2013. Cert is not set > > > > to expire until 2015-12-17. > > > > > > > > > Just a thought... > > > > > > > > > > The simplest workaround IMO would be to prepare Server C, > > > > > install it > > > > with CA and then decommission replica B. > > > > > Do not forget to clean replication agreements on master. > > > > > > > > > > But that would be work around, would not solve this specific > > > > problem, it will kill it. > > > > > > > > I actually do have serverc and serverd. I planned to have CA > > > > replication on at least 2 other servers, but held off on trying on > > > > serverc due to issues with serverb. > > > > > > > > I'll report back what i find after regenerating the replica file > > > > and re-trying to setup CA replication. > > > > > > After a bit of a hiatus I have revisited this issue and I still have it. > > Just to re-iterate the problem... > > Trying to setup a ca replica on an already installed replica fails in rhel 6.6, > ipa-3.0.0.42, pki 9.0.3-38. > > /usr/sbin/ipa-ca-install -p xxxxxx -w xxxxxx -U /var/lib/ipa/replica-info- > myhost.mydomain.com.gpg > > It fails showing.... "CRITICAL failed to configure ca instance" > Configuring certificate server (pki-cad): Estimated time 3 minutes 30 > seconds > [1/16]: creating certificate server user > [2/16]: creating pki-ca instance > [3/16]: configuring certificate server instance > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > It doesn't matter if I run it interactively or unattended. > > I have done this on similar servers that were rhel 6.5, pki-9.0.3-32, ipa 3.0.0- > 37 without any issue. > > The /var/log/ipareplica-ca-install.log shows the following error about White > Spaces: > > ############################################# > Attempting to connect to: mymaster.mydomain.com:9445 Connected. > Posting Query = https:// > mymaster.mydomain.com:9445//ca/admin/console/config/wizard?sdomain > URL=https%3A%2F%2Fmymaster.mydomain.com%3A443&sdomainName=& > choice=existingdomain&p=3&op=next&xml=true > RESPONSE STATUS: HTTP/1.1 200 OK > RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: > Content-Type: application/xml;charset=UTF-8 RESPONSE HEADER: Date: Fri, > 30 Jan 2015 05:05:04 GMT RESPONSE HEADER: Connection: close version="1.0" encoding="UTF-8"?> > admin/console/config/securitydomainpanel.vm > 443 > mymaster.mydomain.com > > CA > /sbin/service pki-cad > <security_domain_instance_name> > https:// myhost.mydomain.com:9445 > > 80 > org.xml.sax.SAXParseException; lineNumber: 1; > columnNumber: 50; White spaces are required between publicId and > systemId. > > The /var/log/pki-ca/debug also shows.... > > [30/Jan/2015:00:05:04][http-9445-1]: SecurityDomainPanel: validating SSL > Admin HTTPS . . . > [30/Jan/2015:00:05:04][http-9445-1]: WizardPanelBase pingCS: started > [30/Jan/2015:00:05:04][http-9445-1]: WizardPanelBase: pingCS: parser > failedorg.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; > White spaces are required between publicId and systemId. > [30/Jan/2015:00:05:04][http-9445-1]: SecurityDomainPanel: pingAdminCS no > successful response for SSL Admin HTTPS > [30/Jan/2015:00:05:05][http-9445-1]: WizardPanelBase > getCertChainUsingSecureAdminPort start > [30/Jan/2015:00:05:05][http-9445-1]: > WizardPanelBase::getCertChainUsingSecureAdminPort() - > Exception=org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: > 50; White spaces are required between publicId and systemId. > [30/Jan/2015:00:05:05][http-9445-1]: WizardPanelBase: > getCertChainUsingSecureAdminPort: java.io.IOException: > org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White > spaces are required between publicId and systemId. > > When I compare those logs to the logs from the server I installed a ca- > replica on successfully, the above is the point where the logs differ and it > must be the source of the error. > > In the log of the server that was successful it shows what should have > happened... > > [25/Nov/2014:00:09:54][http-9445-2]: SecurityDomainPanel: validating SSL > Admin HTTPS . . . > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase pingCS: started > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase pingCS: got XML > parsed > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase pingCS: state=1 > [25/Nov/2014:00:09:54][http-9445-2]: SecurityDomainPanel: pingAdminCS > returns: 1 > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase > getCertChainUsingSecureAdminPort start > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase > getCertChainUsingSecureAdminPort: status=0 > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase > getCertChainUsingSecureAdminPort: certchain= > > I have tried rolling back pki rpms to 9.0.3-32 but this hasn't helped. > > Note, also, I am trying this on new servers, not the same ones used in > December. > > I have searched high and low on google to try and find a resolution for the > White Space issue but haven't found anything that worked. > > This seems like a bug to me. > > Can anyone help with this please? > > Thanks in advance, > > Regards, > > Les > > > > > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From danofsatx at gmail.com Wed Feb 4 01:03:36 2015 From: danofsatx at gmail.com (Dan Mossor) Date: Tue, 03 Feb 2015 19:03:36 -0600 Subject: [Freeipa-users] Minimum Disk Size Message-ID: <54D16FE8.8090804@fedoraproject.org> What would be the minimum recommended disk size for a virtual FreeIPA server on a network consisting of less than 30 users and 100 hosts? Regards, Dan -- Dan Mossor Systems Engineer at Large Fedora KDE WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure Apprentice FAS: dmossor IRC: danofsatx San Antonio, Texas, USA From Steven.Jones at vuw.ac.nz Wed Feb 4 02:31:29 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 4 Feb 2015 02:31:29 +0000 Subject: [Freeipa-users] Minimum Disk Size In-Reply-To: <54D16FE8.8090804@fedoraproject.org> References: <54D16FE8.8090804@fedoraproject.org> Message-ID: <1423016971563.63864@vuw.ac.nz> I would suggest, 1 x 3ghz CPU, 2gb of ram and around 80gb disk space. To give you an idea of a small IPA server to see what is used, Though note the recommendation is for root and /usr to now be one partition and /boot should probably be a bit bigger, say 400mb. ======= -bash-4.1$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroupboot-LogVolroot 8.7G 945M 7.3G 12% / /dev/sda1 194M 95M 90M 52% /boot /dev/mapper/VolGroupdata1-LogVoldata01 16G 44M 15G 1% /data01 /dev/mapper/VolGroupboot-LogVolhome 22G 118M 21G 1% /home /dev/mapper/VolGroupboot-LogVolopt 2.0G 3.0M 1.9G 1% /opt /dev/mapper/VolGroupboot-LogVoltmp 7.6G 131M 7.1G 2% /tmp /dev/mapper/VolGroupboot-LogVolusr 9.6G 2.9G 6.2G 32% /usr /dev/mapper/VolGroupboot-LogVolvar 9.6G 1.3G 7.8G 14% /var /dev/mapper/VolGroupdata2-LogVolvarlib 17G 1.7G 15G 11% /var/lib /dev/mapper/VolGroupboot-LogVolvarlog 9.6G 2.4G 6.7G 27% /var/log /dev/mapper/VolGroupboot-LogVolaudit 7.6G 18M 7.2G 1% /var/log/audit ====== regards Steven From pspacek at redhat.com Wed Feb 4 07:49:58 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 04 Feb 2015 08:49:58 +0100 Subject: [Freeipa-users] Minimum Disk Size In-Reply-To: <54D16FE8.8090804@fedoraproject.org> References: <54D16FE8.8090804@fedoraproject.org> Message-ID: <54D1CF26.3010600@redhat.com> On 4.2.2015 02:03, Dan Mossor wrote: > What would be the minimum recommended disk size for a virtual FreeIPA server > on a network consisting of less than 30 users and 100 hosts? This is effectively few megabytes of data in the database. We are often testing FreeIPA on machine with 10 GB of storage and it works fine as long as logs are rotated properly (and you do not fill disk with something else :-). -- Petr^2 Spacek From mbasti at redhat.com Wed Feb 4 08:52:09 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 04 Feb 2015 09:52:09 +0100 Subject: [Freeipa-users] JSON error enrolling host (Fedora 21 / IPA 4.1.2) In-Reply-To: References: <54CF929F.5050905@redhat.com> <54CF951D.4090203@redhat.com> Message-ID: <54D1DDB9.5030502@redhat.com> Hello, well it depends what exactly you did and what helped. I see Alexander gave you some hints about mDNS. If it was DNSSEC error you should see validation error messages in journalctl -u named-pkcs11 before you disabled DNSSEC validation. Martin^2 On 02/02/15 16:34, Gerardo Cuppari wrote: > Hi Martin, thanks for your replies! > > Please, don't tell me I am getting all these errors because of the > ".local" domain! If so, I will surelly kill someone haha > > I checked /etc/named.conf and changed to "no" dnssec-validation and > here is what you requested: > > [root at pc01 ~]# dig server.estudio.local > > ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> server.estudio.local > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31554 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;server.estudio.local. IN A > > ;; ANSWER SECTION: > server.estudio.local. 1200 IN A 192.168.56.2 > > ;; AUTHORITY SECTION: > estudio.local. 86400 IN NS server.estudio.local. > > ;; Query time: 0 msec > ;; SERVER: 192.168.56.2#53(192.168.56.2) > ;; WHEN: lun feb 02 12:29:17 ART 2015 > ;; MSG SIZE rcvd: 79 > > ****************************************** > > [root at pc01 ~]# dig -t ptr 2.56.168.192.in-addr.arpa > > ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> -t ptr > 2.56.168.192.in-addr.arpa > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36167 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;2.56.168.192.in-addr.arpa. IN PTR > > ;; ANSWER SECTION: > 2.56.168.192.in-addr.arpa. 86400 IN PTR server.estudio.local. > > ;; AUTHORITY SECTION: > 56.168.192.in-addr.arpa. 86400 IN NS server.estudio.local. > > ;; ADDITIONAL SECTION: > server.estudio.local. 1200 IN A 192.168.56.2 > > ;; Query time: 0 msec > ;; SERVER: 192.168.56.2#53(192.168.56.2) > ;; WHEN: lun feb 02 12:34:27 ART 2015 > ;; MSG SIZE rcvd: 118 > > > 2015-02-02 12:17 GMT-03:00 Martin Basti >: > > On 02/02/15 16:07, Martin Basti wrote: >> On 02/02/15 14:13, Gerardo Cuppari wrote: >>> Hello! I am trying to enroll one host to my IPA server (4.1.2) >>> and I am having one problem: the ipa-client-install script keeps >>> giving me errors at the "forwarding ping to json server" step. >>> >>> My configuration is: >>> - server.estudio.local192.168.56.2Fedora Server 21ipa 4.1.2 >>> - pc01.estudio.local192.168.56.106Fedora Works. 21 >>> >>> Both have firewalld down (just to test) and can reach each >>> other. I've been trying to get this working without success >>> (solved other minor issues) and so I'm asking for your help. >>> The only way I can make it work is by adding the --force switch >>> to ipa-client-install script but, that way, it just disregards >>> errors. >>> >>> Thanks in advance!!! >>> >>> Here are my tests: >>> >>> SERVER >>> ====== >>> [root at server ~]# ipa ping >>> ------------------------------------------- >>> IPA server version 4.1.2. API version 2.109 >>> ------------------------------------------- >>> >>> CLIENT >>> ====== >>> [root at pc01 ~]# dig server >>> >>> ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> server >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29286 >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags:; udp: 4096 >>> ;; QUESTION SECTION: >>> ;server. IN A >>> >>> ;; Query time: 10 msec >>> ;; SERVER: 192.168.56.2#53(192.168.56.2) >>> ;; WHEN: lun feb 02 09:51:07 ART 2015 >>> ;; MSG SIZE rcvd: 35 >>> >>> *********************************************** >>> >>> [root at pc01 ~]# nslookup server >>> Server: 192.168.56.2 >>> Address: 192.168.56.2#53 >>> >>> Name: server.estudio.local >>> Address: 192.168.56.2 >>> >>> *********************************************** >>> >>> Here I disable chronyd so I can run the script without NTP sync >>> errors: >>> >>> [root at pc01 ~]# systemctl disable chronyd >>> Removed symlink >>> /etc/systemd/system/multi-user.target.wants/chronyd.service. >>> [root at pc01 ~]# service chronyd stop >>> Redirecting to /bin/systemctl stop chronyd.service >>> >>> *********************************************** >>> >>> Without having "server.estudio.local" on /etc/hosts file: >>> >>> [root at pc01 ~]# ipa-client-install --enable-dns-updates >>> --mkhomedir --ssh-trust-dns >>> Skip server.estudio.local: cannot verify if this is an IPA server >>> Provide your IPA server name (ex: ipa.example.com >>> ): >>> Skip server.estudio.local: cannot verify if this is an IPA server >>> Failed to verify that server.estudio.local is an IPA Server. >>> This may mean that the remote server is not up or is not >>> reachable due to network or firewall settings. >>> 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. >>> IPA client is not configured on this system. >>> >>> >>> *********************************************** >>> >>> Here I added hostname and IP address to /etc/hosts file (don't >>> know why it doesn't work without it): >>> >>> [root at pc01 ~]# ipa-client-install --enable-dns-updates >>> --mkhomedir --ssh-trust-dns >>> Discovery was successful! >>> Hostname: pc01.estudio.local >>> Realm: ESTUDIO.LOCAL >>> DNS Domain: estudio.local >>> IPA Server: server.estudio.local >>> BaseDN: dc=estudio,dc=local >>> >>> Continue to configure the system with these values? [no]: yes >>> Synchronizing time with KDC... >>> User authorized to enroll computers: admin >>> Password for admin at ESTUDIO.LOCAL : >>> Successfully retrieved CA cert >>> Subject: CN=Certificate Authority,O=ESTUDIO.LOCAL >>> Issuer: CN=Certificate Authority,O=ESTUDIO.LOCAL >>> Valid From: Fri Jan 30 12:02:01 2015 UTC >>> Valid Until: Tue Jan 30 12:02:01 2035 UTC >>> >>> Enrolled in IPA realm ESTUDIO.LOCAL >>> Created /etc/ipa/default.conf >>> New SSSD config will be created >>> Configured sudoers in /etc/nsswitch.conf >>> Configured /etc/sssd/sssd.conf >>> Configured /etc/krb5.conf for IPA realm ESTUDIO.LOCAL >>> trying https://server.estudio.local/ipa/json >>> Forwarding 'ping' to json server >>> 'https://server.estudio.local/ipa/json' >>> Cannot connect to the server due to Kerberos error: Kerberos >>> error: ('Unspecified GSS failure. Minor code may provide more >>> information', 851968)/("Cannot contact any KDC for realm >>> 'ESTUDIO.LOCAL'", -1765328228). Trying with delegate=True >>> trying https://server.estudio.local/ipa/json >>> Forwarding 'ping' to json server >>> 'https://server.estudio.local/ipa/json' >>> Second connect with delegate=True also failed: Kerberos error: >>> ('Unspecified GSS failure. Minor code may provide more >>> information', 851968)/("Cannot contact any KDC for realm >>> 'ESTUDIO.LOCAL'", -1765328228) >>> Cannot connect to the IPA server RPC interface: Kerberos error: >>> ('Unspecified GSS failure. Minor code may provide more >>> information', 851968)/("Cannot contact any KDC for realm >>> 'ESTUDIO.LOCAL'", -1765328228) >>> Installation failed. Rolling back changes. >>> Failed to list certificates in /etc/ipa/nssdb: Command >>> ''/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L'' returned >>> non-zero exit status 255 >>> Failed to remove /etc/ipa/nssdb/cert8.db: [Errno 2] No existe el >>> fichero o el directorio: '/etc/ipa/nssdb/cert8.db' >>> Failed to remove /etc/ipa/nssdb/key3.db: [Errno 2] No existe el >>> fichero o el directorio: '/etc/ipa/nssdb/key3.db' >>> Failed to remove /etc/ipa/nssdb/secmod.db: [Errno 2] No existe >>> el fichero o el directorio: '/etc/ipa/nssdb/secmod.db' >>> Failed to remove /etc/ipa/nssdb/pwdfile.txt: [Errno 2] No existe >>> el fichero o el directorio: '/etc/ipa/nssdb/pwdfile.txt' >>> Unenrolling client from IPA server >>> Unenrolling host failed: Error getting default Kerberos realm: >>> host/domain name not found. >>> >>> Removing Kerberos service principals from /etc/krb5.keytab >>> 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 >>> nscd daemon is not installed, skip configuration >>> nslcd daemon is not installed, skip configuration >>> Client uninstall complete. >>> >>> *********************************************** >>> >>> >>> >> Hello >> >> dig returns servfail, it may be issue. > > You used dig with wrong name, please use dig server.estudio.local > and send result? > >> >> Can you check please /etc/named.conf on server, if there is >> dnssec-validation true ? >> If yes, please set the dnssec-validation to no, because you use >> domain name .local. it may cause troubles. >> >> If troubles persist, please send journalctl -u named-pkcs11 log. >> >> Martin^2 >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti > > > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbischof at hrz.uni-kassel.de Wed Feb 4 09:05:57 2015 From: dbischof at hrz.uni-kassel.de (dbischof at hrz.uni-kassel.de) Date: Wed, 4 Feb 2015 10:05:57 +0100 (CET) Subject: [Freeipa-users] autofs - nfsnobody In-Reply-To: References: Message-ID: Hi Gerardo, On Tue, 3 Feb 2015, Gerardo Cuppari wrote: > Hello there again! I'm bothering you again because I am having some > problems with autofs/NFS and IPA. All files created from a regular user > (enrolled client) gets the nfsnobody user and group. Folder gets auto > mounted. just a guess: I had this symptom with a non-Redhat, self-configured client. It turned out, that it was required to set --- Domain = my.domain.de --- in /etc/idmapd.conf Maybe worth a try. > Thanks in advance! > > Here is what I did to configure it at server (server.estudio) and client > (pc01.estudio): > > SERVER > ===== > > ipa service-add nfs/server.estudio > ipa-getkeytab -s server.estudio -p nfs/server.estudio -k /etc/krb5.keytab > ipa-client-automount > > mkdir /export > chmod 777 /export > echo /export *(rw,sync,sec=sys:krb5:krb5i:krb5p) >> /etc/exports > > reboot > > ************************** > > CLIENT > ==== > > ipa-getkeytab -s server.estudio -p host/server.estudio at ESTUDIO -k > /etc/krb5.keytab > ipa-client-automount > > reboot > > echo aaa >> /export/aaa > > [user at pc01 /]$ ls -la /export > total 12 > drwxrwxrwx. 2 root root 4096 feb 3 13:36 . > dr-xr-xr-x. 21 root root 4096 feb 3 13:36 .. > -rw-rw-r--. 1 nfsnobody nfsnobody 4 feb 3 13:36 aaa > Mit freundlichen Gruessen/With best regards, --Daniel. From abokovoy at redhat.com Wed Feb 4 09:24:04 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 4 Feb 2015 11:24:04 +0200 Subject: [Freeipa-users] IPA-adtrust and addition of replicas In-Reply-To: <1422947143.2657.6.camel@firstyear.id.au> References: <1422765524.4790.3.camel@firstyear.id.au> <20150201154935.GZ6592@redhat.com> <1422831403.3928.8.camel@firstyear.id.au> <20150202080244.GA6592@redhat.com> <1422932289.2744.4.camel@firstyear.id.au> <20150203054828.GD6592@redhat.com> <1422947143.2657.6.camel@firstyear.id.au> Message-ID: <20150204092404.GB9247@redhat.com> On Tue, 03 Feb 2015, William wrote: > >> > >> >Maybe something to test? >> You can create a user on the replica without ipa-adtrust-install and >> watch after replication on whether ipaNTSecurityIdentifier appeared in >> the user's object in LDAP. >> > >I was thinking more unit test or beaker test actually, but I'm sure I >could do a setup by hand and test it later. Having a beaker test would be good. I was just thinking about proving that the flow is indeed what we are discussing. ;) > >> >> >This should be configured on replicas added to the network if adtrust >> >> >has been run already. Perhaps this is something to consider also? >> >> >Consistency through out the domain is a good thing. >> >> Exactly. Good suggestion. One thing we need to solve here is that >> >> enabling sidgen and other components will require installing Samba >> >> libraries. This is something to consider -- do we want these libraries >> >> (not daemons) installed on every master? >> > >> >Well, ipa-adtrust is a seperate package already isn't it? If you were in >> >the position to be setting up an adtrust on freeipa, you would document >> >that it should be installed on all hosts anyway, so then the adtrust >> >package would pull in the adtrust libs. >> > >> >Once the adtrust is installed, be it trust controller or agent, perhaps >> >this should be added into the domain services tree under cn=etc. That >> >way, after the adtrust is run, you can see a list of hosts that do not >> >yet have it installed, so that the trust agent can be configured on all >> >other replicas. Additionally, adding a new replica could be hinted that >> >if this exists to configure itself as a trust agent automatically as >> >part of ipa-replica-install. >> > >> >Does that sound like a reasonable suggestion? >> Yes, this is what ipa-adtrust-install implements right now. My issue >> with this approach is the fact that we don't want to run >> smbd/winbindd/etc for trust agent case. Yet, ipa-adtrust-install forces >> packages to be installed and services to be active. > >Kind of what I meant but kind of not. I meant a more generic "some >adtrust agent or controller" flag, rather than the services. The per >host flag is to enable the detection of masters that lack adtrust agent >or controller, rather than to detect if the domain has had adtrust run >at all. > >My thought was more like: > >If I have three ipa masters, A B C. I have trust controller on A, and I >am installing trust agent on B, I should post install receive a message: > >ipa-adtrust-install --agent: >... Install happens here ... >The following masters are not agents or controllers. These should be >promoted. >* C > >To of course, prompt me to run adtrust-install on C. > >Then I add some host D, it should as part of ipa-replica-install be >configured as a trust agent. > >This way the domain stays consistent and I am informed of the state of >the network. > >This also means there should be a strategy for promotion of the agent to >a controller, and also in the decommissioning code to remove both agent >and installers correctly (If not already implemented) Makes sense. This will need to be added into a design page -- I'll work on that next week. There will be series of RFE tickets to correspond to work outlined in those design pages and this is a perfect example of an RFE. > >> >> We can start with disabling ADTRUST and EXTID services on trust agents >> (these are smb and winbind in ipactl speak) and, maybe, rename them to >> something less confusing. Then we can decide whether not installing >> samba server packages would really be needed. > >Sounds like a good plan. Would this become a special case of >ipa-adtrust-install? Or an option that is prompted for similar to the >slapi-nis question. For most cases like this we have CLI option and ask for an answer interactively in case option wasn't provided explicitly and we are not running in unattended mode. In case of a slapi-nis it is driven by --enable-compat option of ipa-adtrust-install. The general calling pattern in ipa-adtrust-install is something like this: if not options.unattended and not options.enable_compat: options.enable_compat = enable_compat_tree() where enable_compat_tree() does ask user for a confirmation. -- / Alexander Bokovoy From Duncan.Innes at virginmoney.com Wed Feb 4 09:31:12 2015 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Wed, 4 Feb 2015 09:31:12 -0000 Subject: [Freeipa-users] Minimum Disk Size In-Reply-To: <54D16FE8.8090804@fedoraproject.org> References: <54D16FE8.8090804@fedoraproject.org> Message-ID: <56343345B145C043AE990701E3D193950478E3D6@EXVS2.nrplc.localnet> Our standard RHEL6 OS install worked perfectly well for testing IPA with larger user/host numbers: part /boot --fstype=ext4 --size=256 --ondisk=sda --fsoptions noatime part pv.01 --size=1000 --grow --ondisk=sda volgroup vg_root pv.01 logvol / --vgname=vg_root --name=lv_root --size=3072 --fstype=ext4 --fsoptions noatime logvol swap --vgname=vg_root --name=lv_swap --size=1024 --fstype=swap logvol /opt --vgname=vg_root --name=lv_opt --size=1024 --fstype=ext4 --fsoptions noatime logvol /var --vgname=vg_root --name=lv_var --size=1024 --fstype=ext4 --fsoptions noatime logvol /var/log --vgname=vg_root --name=lv_vlog --size=1024 --fstype=ext4 --fsoptions noatime logvol /var/log/audit --vgname=vg_root --name=lv_vaudit --size=512 --fstype=ext4 --fsoptions noatime logvol /tmp --vgname=vg_root --name=lv_tmp --size=1024 --fstype=ext4 --fsoptions noatime,nodev,nosuid,noexec logvol /home --vgname=vg_root --name=lv_home --size=1024 --fstype=ext4 --fsoptions noatime,nodev Then to load test and move into production, we simply added an extra partition for /var/lib/dirsrv: logvol /var/lib/dirsrv --vgname=vg_root --name=lv_ldap --size=4096 --fstype=ext4 --fsoptions noatime Which still uses less than 1Gb with nearly 1500 users and around 700 hosts: # df -P Filesystem 1024-blocks Used Available Capacity Mounted on /dev/mapper/vg_root-lv_root 3030800 1478012 1395504 52% / tmpfs 1962324 4 1962320 1% /dev/shm /dev/sda1 245679 69576 162996 30% /boot /dev/mapper/vg_root-lv_home 999320 29724 917168 4% /home /dev/mapper/vg_root-lv_opt 999320 1328 945564 1% /opt /dev/mapper/vg_root-lv_tmp 999320 44312 902580 5% /tmp /dev/mapper/vg_root-lv_var 999320 296952 649940 32% /var /dev/mapper/vg_root-lv_ldap 3997376 640084 3147580 17% /var/lib/dirsrv /dev/mapper/vg_root-lv_vlog 1515376 514128 922612 36% /var/log /dev/mapper/vg_root-lv_vaudit 499656 29608 443836 7% /var/log/audit # HTH D -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dan Mossor Sent: 04 February 2015 01:04 To: FreeIPA List Subject: [Freeipa-users] Minimum Disk Size What would be the minimum recommended disk size for a virtual FreeIPA server on a network consisting of less than 30 users and 100 hosts? Regards, Dan -- Dan Mossor Systems Engineer at Large Fedora KDE WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure Apprentice FAS: dmossor IRC: danofsatx San Antonio, Texas, USA -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com From mbasti at redhat.com Wed Feb 4 09:34:48 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 04 Feb 2015 10:34:48 +0100 Subject: [Freeipa-users] basic question on DNS configuration In-Reply-To: References: Message-ID: <54D1E7B8.3020008@redhat.com> On 03/02/15 16:52, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Roberto > Cornacchia > *Sent:* Tuesday, February 03, 2015 5:20 AM > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] basic question on DNS configuration > > Hi guys, > > I can't wait to get freeIPA installed in our small enterprise, but I'd > first like to get a couple of basic things straight. > > My first doubt is about the DNS configuration. Currently, we use a > setting that I guess is rather common for small enterprises: > > We own an example.com domain which is managed by > the DNS of an external provider. > > A couple of subdomains point to public IP addresses outside our local > network (e.g. www.example.com is hosted at > our internet provider, server1.example.com > points at a server hosted in a > datacenter, etc). > > All the remaining subdomain (*.example.com ) point > at one IP which corresponds to our local router. > > Then we use some simple forwarding rules to forward on to machines > that are behind the router (service1.example.com > , desktop1.example.com > , desktop2.example.com > , etc). > > Internally, because the enterprise is rather small, we are not using a > DNS, but simply /etc/hosts files on each machine. When they can't > resolve whatever.example.com , then the > request goes to the external DNS. > > (sorry about the long-ish background information, probably this > configuration is commonly named somehow, but I don't know how) > > Now, a first simple question for you guys would be: > > When installing freeIPA, with DNS, is the network configuration above > still advisable? Can there be any problem? Or should I rather use a > different domain for the internal network (I would really NOT like > this option, but I'm very interested to know why I should, if that is > the case). > > A second basic question is: > > Would you see any potential problem in installing freeIPA on a FC21 > Server which currently hosts Atlassian Jira + Atlassian Stash > (therefore git repositories) + the required mysql databases? > > My guess would be that they would not interfere, as: > > - httpd (and related ports) is currently unused) > > - Both Jira and Stash use thier own tomcat installation on custom ports > > - mysql shouldn't be a problem? > > - The machine isn't overloaded at all (4-5 developers use those services) > > Am I overlooking something? Obviously I'd rather have a dedicated > freeIPA server, but if the above mentioned coexistence isn't a > problem, then this would be more cost-effective. > > Thank you very much for your help, I'm looking forward to this upgrade. > > Roberto > > I would recommend that you create a ?local? domain for your internal > LAN though you certainly can use your domain name for both the > internal LAN and the external world. Obviously you would have to > create ?manual? entries in DNS for the external servers (like > www.example.com ) so your internal LAN systems > can resolve it. If you have a ?local? domain for your internal LAN, > there aren?t name collisions, no need to manually maintain DNS entries > for off-LAN servers and no confusion of essentially faking your LAN > systems into believing that the IPA server is authoritative for > example.com domain when the rest of the world thinks otherwise. The > choice is yours. > > As for using F21 ? you get the latest version of FreeIPA which is > something I wish I had here. > > Git / Stash / Jira represent a fairly hefty memory footprint even if > there isn?t that much CPU load. If you have the RAM and cpu cores to > handle tossing FreeIPA onto the stack, go for it. You probably will > want a replica too as the replica keeps your LAN running if the > primary server is unavailable for whatever reason and it minimizes > backup needs substantially. > > Craig > > > Hello, For using 'local.' domain please read following message, to avoid issues on Fedora: https://www.redhat.com/archives/freeipa-users/2015-February/msg00010.html You cant use 'example.com' zone for internal IPA DNS. You can create your internal sub zone, like 'internal.example.com', 'corp.example.com', where IPA managed hosts will be added. It is preferred solution instead of creating '.local' hostnames. Then you can set up global forwarder on IPA DNS to your external DNS, where other names than 'internal.example.com' will be resolved. If I understand correctly, it is internal network, so you do not need public resolvable domain names. -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.cornacchia at gmail.com Wed Feb 4 10:39:30 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Wed, 4 Feb 2015 11:39:30 +0100 Subject: [Freeipa-users] basic question on DNS configuration In-Reply-To: <54D1E7B8.3020008@redhat.com> References: <54D1E7B8.3020008@redhat.com> Message-ID: Thank you Craig and Martin for your useful input. You both definitely recommend not to use example.com for the internal IPA DNS. I was in any case going to avoid .local suffix and any invented top-level domain, after some reading on this topic. Using a subdomain like internal.example.com seems reasonable. I was under the impression that the freeIPA domain needed to be a top-level one, but maybe I was wrong here? Can I still keep example.com outside and have freeIPA manage internal.example.com? On 4 February 2015 at 10:34, Martin Basti wrote: > On 03/02/15 16:52, Craig White wrote: > > *From:* freeipa-users-bounces at redhat.com [ > mailto:freeipa-users-bounces at redhat.com ] > *On Behalf Of *Roberto Cornacchia > *Sent:* Tuesday, February 03, 2015 5:20 AM > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] basic question on DNS configuration > > > > Hi guys, > > > > I can't wait to get freeIPA installed in our small enterprise, but I'd > first like to get a couple of basic things straight. > > > > My first doubt is about the DNS configuration. Currently, we use a setting > that I guess is rather common for small enterprises: > > > > We own an example.com domain which is managed by the DNS of an external > provider. > > > > A couple of subdomains point to public IP addresses outside our local > network (e.g. www.example.com is hosted at our internet provider, > server1.example.com points at a server hosted in a datacenter, etc). > > > > All the remaining subdomain (*.example.com) point at one IP which > corresponds to our local router. > > Then we use some simple forwarding rules to forward on to machines that > are behind the router (service1.example.com, desktop1.example.com, > desktop2.example.com, etc). > > > > Internally, because the enterprise is rather small, we are not using a > DNS, but simply /etc/hosts files on each machine. When they can't resolve > whatever.example.com, then the request goes to the external DNS. > > > > (sorry about the long-ish background information, probably this > configuration is commonly named somehow, but I don't know how) > > > > Now, a first simple question for you guys would be: > > When installing freeIPA, with DNS, is the network configuration above > still advisable? Can there be any problem? Or should I rather use a > different domain for the internal network (I would really NOT like this > option, but I'm very interested to know why I should, if that is the case). > > > > > > A second basic question is: > > Would you see any potential problem in installing freeIPA on a FC21 Server > which currently hosts Atlassian Jira + Atlassian Stash (therefore git > repositories) + the required mysql databases? > > My guess would be that they would not interfere, as: > > - httpd (and related ports) is currently unused) > > - Both Jira and Stash use thier own tomcat installation on custom ports > > - mysql shouldn't be a problem? > > - The machine isn't overloaded at all (4-5 developers use those services) > > > > Am I overlooking something? Obviously I'd rather have a dedicated freeIPA > server, but if the above mentioned coexistence isn't a problem, then this > would be more cost-effective. > > > > Thank you very much for your help, I'm looking forward to this upgrade. > > Roberto > > I would recommend that you create a ?local? domain for your internal LAN > though you certainly can use your domain name for both the internal LAN and > the external world. Obviously you would have to create ?manual? entries in > DNS for the external servers (like www.example.com) so your internal LAN > systems can resolve it. If you have a ?local? domain for your internal LAN, > there aren?t name collisions, no need to manually maintain DNS entries for > off-LAN servers and no confusion of essentially faking your LAN systems > into believing that the IPA server is authoritative for example.com > domain when the rest of the world thinks otherwise. The choice is yours. > > > > As for using F21 ? you get the latest version of FreeIPA which is > something I wish I had here. > > > > Git / Stash / Jira represent a fairly hefty memory footprint even if there > isn?t that much CPU load. If you have the RAM and cpu cores to handle > tossing FreeIPA onto the stack, go for it. You probably will want a replica > too as the replica keeps your LAN running if the primary server is > unavailable for whatever reason and it minimizes backup needs substantially. > > > > Craig > > > > > Hello, > > For using 'local.' domain please read following message, to avoid issues > on Fedora: > https://www.redhat.com/archives/freeipa-users/2015-February/msg00010.html > > You cant use 'example.com' zone for internal IPA DNS. > > You can create your internal sub zone, like 'internal.example.com', ' > corp.example.com', where IPA managed hosts will be added. It is preferred > solution instead of creating '.local' hostnames. Then you can set up > global forwarder on IPA DNS to your external DNS, where other names than ' > internal.example.com' will be resolved. > > If I understand correctly, it is internal network, so you do not need > public resolvable domain names. > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Feb 4 10:46:35 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 04 Feb 2015 11:46:35 +0100 Subject: [Freeipa-users] basic question on DNS configuration In-Reply-To: References: <54D1E7B8.3020008@redhat.com> Message-ID: <54D1F88B.8010800@redhat.com> On 04/02/15 11:39, Roberto Cornacchia wrote: > Thank you Craig and Martin for your useful input. > > You both definitely recommend not to use example.com > for the internal IPA DNS. > > I was in any case going to avoid .local suffix and any invented > top-level domain, after some reading on this topic. > > Using a subdomain like internal.example.com > seems reasonable. > I was under the impression that the freeIPA domain needed to be a > top-level one, but maybe I was wrong here? Can I still keep > example.com outside and have freeIPA manage > internal.example.com ? IPA DNS is designed only for internal network, so having an internal subdomain is good use case. You can keep example.com outside of IPA DNS, you just need to configure proper forwarder address pointing to external DNS. Martin^2 > > > > On 4 February 2015 at 10:34, Martin Basti > wrote: > > On 03/02/15 16:52, Craig White wrote: >> >> *From:*freeipa-users-bounces at redhat.com >> >> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Roberto >> Cornacchia >> *Sent:* Tuesday, February 03, 2015 5:20 AM >> *To:* freeipa-users at redhat.com >> *Subject:* [Freeipa-users] basic question on DNS configuration >> >> Hi guys, >> >> I can't wait to get freeIPA installed in our small enterprise, >> but I'd first like to get a couple of basic things straight. >> >> My first doubt is about the DNS configuration. Currently, we use >> a setting that I guess is rather common for small enterprises: >> >> We own an example.com domain which is >> managed by the DNS of an external provider. >> >> A couple of subdomains point to public IP addresses outside our >> local network (e.g. www.example.com is >> hosted at our internet provider, server1.example.com >> points at a server hosted in a >> datacenter, etc). >> >> All the remaining subdomain (*.example.com ) >> point at one IP which corresponds to our local router. >> >> Then we use some simple forwarding rules to forward on to >> machines that are behind the router (service1.example.com >> , desktop1.example.com >> , desktop2.example.com >> , etc). >> >> Internally, because the enterprise is rather small, we are not >> using a DNS, but simply /etc/hosts files on each machine. When >> they can't resolve whatever.example.com >> , then the request goes to the >> external DNS. >> >> (sorry about the long-ish background information, probably this >> configuration is commonly named somehow, but I don't know how) >> >> Now, a first simple question for you guys would be: >> >> When installing freeIPA, with DNS, is the network configuration >> above still advisable? Can there be any problem? Or should I >> rather use a different domain for the internal network (I would >> really NOT like this option, but I'm very interested to know why >> I should, if that is the case). >> >> A second basic question is: >> >> Would you see any potential problem in installing freeIPA on a >> FC21 Server which currently hosts Atlassian Jira + Atlassian >> Stash (therefore git repositories) + the required mysql databases? >> >> My guess would be that they would not interfere, as: >> >> - httpd (and related ports) is currently unused) >> >> - Both Jira and Stash use thier own tomcat installation on custom >> ports >> >> - mysql shouldn't be a problem? >> >> - The machine isn't overloaded at all (4-5 developers use those >> services) >> >> Am I overlooking something? Obviously I'd rather have a dedicated >> freeIPA server, but if the above mentioned coexistence isn't a >> problem, then this would be more cost-effective. >> >> Thank you very much for your help, I'm looking forward to this >> upgrade. >> >> Roberto >> >> I would recommend that you create a ?local? domain for your >> internal LAN though you certainly can use your domain name for >> both the internal LAN and the external world. Obviously you would >> have to create ?manual? entries in DNS for the external servers >> (like www.example.com ) so your internal >> LAN systems can resolve it. If you have a ?local? domain for your >> internal LAN, there aren?t name collisions, no need to manually >> maintain DNS entries for off-LAN servers and no confusion of >> essentially faking your LAN systems into believing that the IPA >> server is authoritative for example.com >> domain when the rest of the world thinks otherwise. The choice is >> yours. >> >> As for using F21 ? you get the latest version of FreeIPA which is >> something I wish I had here. >> >> Git / Stash / Jira represent a fairly hefty memory footprint even >> if there isn?t that much CPU load. If you have the RAM and cpu >> cores to handle tossing FreeIPA onto the stack, go for it. You >> probably will want a replica too as the replica keeps your LAN >> running if the primary server is unavailable for whatever reason >> and it minimizes backup needs substantially. >> >> Craig >> >> >> > Hello, > > For using 'local.' domain please read following message, to avoid > issues on Fedora: > https://www.redhat.com/archives/freeipa-users/2015-February/msg00010.html > > You cant use 'example.com ' zone for internal > IPA DNS. > > You can create your internal sub zone, like 'internal.example.com > ', 'corp.example.com > ', where IPA managed hosts will be added. > It is preferred solution instead of creating '.local' hostnames. > Then you can set up global forwarder on IPA DNS to your external > DNS, where other names than 'internal.example.com > ' will be resolved. > > If I understand correctly, it is internal network, so you do not > need public resolvable domain names. > > -- > Martin Basti > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Wed Feb 4 14:19:43 2015 From: alee at redhat.com (Ade Lee) Date: Wed, 04 Feb 2015 09:19:43 -0500 Subject: [Freeipa-users] CA Replication Installation Failing In-Reply-To: <4ED173A868981548967B4FCA27072226280A6EA9@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA270722262803F3C5@AACMBXP04.exchserver.com> <4ED173A868981548967B4FCA2707222628048DF6@AACMBXP04.exchserver.com> , <54867F51.1030603@redhat.com> <4ED173A868981548967B4FCA2707222628049113@AACMBXP04.exchserver.com> <1418148291.27499.20.camel@aleeredhat.laptop> <4ED173A868981548967B4FCA270722262804A449@AACMBXP04.exchserver.com> <4ED173A868981548967B4FCA27072226280A6EA9@AACMBXP04.exchserver.com> Message-ID: <1423059583.19504.10.camel@alee-redhat.laptop> >From the snippet of log below, it looks like the replica CA is trying to contact the master CA to obtain the security domain information and is failing to get a valid response. The message about "spaces and parsing" is basically the replica saying that it cannot understand the response -- or lack of one from the master CA. As this is an old version of IPA and Dogtag, it is trying to contact the master CA on port 9443. Things to look into: 1) Is the CA on the master up? Is port 9443 open on the master (firewalls on master or replica)? You could test this by using a browser/curl on the replica to go to https://:9443/ca/admin/ca/getDomainXML 2) Is selinux preventing the access? You might want to set it in permissive mode on either master or replica. 3) Do you see activity in the master's debug log? This looks to me like a different error from what was described before. Its failing much earlier now. Ade On Fri, 2015-01-30 at 05:48 +0000, Les Stott wrote: > > > -----Original Message----- > > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > > bounces at redhat.com] On Behalf Of Les Stott > > Sent: Wednesday, 10 December 2014 6:22 PM > > To: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] CA Replication Installation Failing > > > > > > > > > -----Original Message----- > > > From: Ade Lee [mailto:alee at redhat.com] > > > Sent: Wednesday, 10 December 2014 5:05 AM > > > To: Les Stott > > > Cc: freeipa-users at redhat.com > > > Subject: Re: [Freeipa-users] CA Replication Installation Failing > > > > > > On Tue, 2014-12-09 at 07:48 +0000, Les Stott wrote: > > > > > > > > > > > > > > > > > __________________________________________________________ > > > ____________ > > > > From: freeipa-users-bounces at redhat.com > > > > [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal > > > > [dpal at redhat.com] > > > > Sent: Tuesday, December 09, 2014 3:49 PM > > > > To: freeipa-users at redhat.com > > > > Subject: Re: [Freeipa-users] CA Replication Installation Failing > > > > > > > > > > > > > > > > On 12/08/2014 11:04 PM, Les Stott wrote: > > > > > > > > > Does anyone have any ideas on the below errors when trying to add > > > > > CA replication to an existing replica? > > > > > > > > > > > > > > > > > > > People who might be able to help are or PTO right now. > > > > > > > > > > Is your installation older than 2 years? > > > > > > > > No, December 2013 was when it was originally built. > > > > > > > > > Did you generate a new replica package or use the original one? > > > > > > > > I used the original replica file for serverb, based on instructions > > > > i came across. I can try regenerating the replica file. > > > > > > > > Interestingly, now that you mention it, servera had to be restored a > > > > couple of months back. Perhaps this is an issue and regenerating the > > > > replica file for serverb will be required. > > > > > > > > I will try this. > > > > > > > > > > I think that this is a safe bet to be the problem. > > > > > > The error in the log snippet you posted says: > > > > > > The pkcs12 file is not correct. > > > > > > This indicates that the clone CA was unable to decode the pkcs12 file > > > in the replica. Perhaps the certs changed -- or the DM password changed? > > > > > > Ade > > > > I regenerated the replica file and retired the CA replica setup, but it failed at > > the same point with the same error. > > > > I am thinking that the next step is to uninstall the ipa replica to cleanup, > > remove all traces and re-add as a replica on serverb. > > > > I wonder if the cert that its having an issue with is the one on serverB under > > /etc/ipa/ca.crt which is from Dec 2013. > > > > I will try that in a couple of days as I have to schedule this work in as its in > > production. > > > > Regards, > > > > Les > > > > > > > > > May be the problem is that the cert that is in that package > > > > > already > > > > expired? > > > > > > > > original replica file was created on Dec 16 2013. Cert is not set to > > > > expire until 2015-12-17. > > > > > > > > > Just a thought... > > > > > > > > > > The simplest workaround IMO would be to prepare Server C, install > > > > > it > > > > with CA and then decommission replica B. > > > > > Do not forget to clean replication agreements on master. > > > > > > > > > > But that would be work around, would not solve this specific > > > > problem, it will kill it. > > > > > > > > I actually do have serverc and serverd. I planned to have CA > > > > replication on at least 2 other servers, but held off on trying on > > > > serverc due to issues with serverb. > > > > > > > > I'll report back what i find after regenerating the replica file and > > > > re-trying to setup CA replication. > > > > > > After a bit of a hiatus I have revisited this issue and I still have it. > > Just to re-iterate the problem... > > Trying to setup a ca replica on an already installed replica fails in rhel 6.6, ipa-3.0.0.42, pki 9.0.3-38. > > /usr/sbin/ipa-ca-install -p xxxxxx -w xxxxxx -U /var/lib/ipa/replica-info-myhost.mydomain.com.gpg > > It fails showing.... "CRITICAL failed to configure ca instance" > Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds > [1/16]: creating certificate server user > [2/16]: creating pki-ca instance > [3/16]: configuring certificate server instance > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > It doesn't matter if I run it interactively or unattended. > > I have done this on similar servers that were rhel 6.5, pki-9.0.3-32, ipa 3.0.0-37 without any issue. > > The /var/log/ipareplica-ca-install.log shows the following error about White Spaces: > > ############################################# > Attempting to connect to: mymaster.mydomain.com:9445 > Connected. > Posting Query = https:// mymaster.mydomain.com:9445//ca/admin/console/config/wizard?sdomainURL=https%3A%2F%2Fmymaster.mydomain.com%3A443&sdomainName=&choice=existingdomain&p=3&op=next&xml=true > RESPONSE STATUS: HTTP/1.1 200 OK > RESPONSE HEADER: Server: Apache-Coyote/1.1 > RESPONSE HEADER: Content-Type: application/xml;charset=UTF-8 > RESPONSE HEADER: Date: Fri, 30 Jan 2015 05:05:04 GMT > RESPONSE HEADER: Connection: close > > > admin/console/config/securitydomainpanel.vm > 443 > mymaster.mydomain.com > > CA > /sbin/service pki-cad > <security_domain_instance_name> > https:// myhost.mydomain.com:9445 > > 80 > org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId. > > The /var/log/pki-ca/debug also shows.... > > [30/Jan/2015:00:05:04][http-9445-1]: SecurityDomainPanel: validating SSL Admin HTTPS . . . > [30/Jan/2015:00:05:04][http-9445-1]: WizardPanelBase pingCS: started > [30/Jan/2015:00:05:04][http-9445-1]: WizardPanelBase: pingCS: parser failedorg.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId. > [30/Jan/2015:00:05:04][http-9445-1]: SecurityDomainPanel: pingAdminCS no successful response for SSL Admin HTTPS > [30/Jan/2015:00:05:05][http-9445-1]: WizardPanelBase getCertChainUsingSecureAdminPort start > [30/Jan/2015:00:05:05][http-9445-1]: WizardPanelBase::getCertChainUsingSecureAdminPort() - Exception=org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId. > [30/Jan/2015:00:05:05][http-9445-1]: WizardPanelBase: getCertChainUsingSecureAdminPort: java.io.IOException: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId. > > When I compare those logs to the logs from the server I installed a ca-replica on successfully, the above is the point where the logs differ and it must be the source of the error. > > In the log of the server that was successful it shows what should have happened... > > [25/Nov/2014:00:09:54][http-9445-2]: SecurityDomainPanel: validating SSL Admin HTTPS . . . > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase pingCS: started > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase pingCS: got XML parsed > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase pingCS: state=1 > [25/Nov/2014:00:09:54][http-9445-2]: SecurityDomainPanel: pingAdminCS returns: 1 > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase getCertChainUsingSecureAdminPort start > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase getCertChainUsingSecureAdminPort: status=0 > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase getCertChainUsingSecureAdminPort: certchain= > > I have tried rolling back pki rpms to 9.0.3-32 but this hasn't helped. > > Note, also, I am trying this on new servers, not the same ones used in December. > > I have searched high and low on google to try and find a resolution for the White Space issue but haven't found anything that worked. > > This seems like a bug to me. > > Can anyone help with this please? > > Thanks in advance, > > Regards, > > Les > > > > > > From rcritten at redhat.com Wed Feb 4 15:24:06 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Feb 2015 10:24:06 -0500 Subject: [Freeipa-users] CA Replication Installation Failing In-Reply-To: <4ED173A868981548967B4FCA27072226280AC187@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA270722262803F3C5@AACMBXP04.exchserver.com> <4ED173A868981548967B4FCA2707222628048DF6@AACMBXP04.exchserver.com> , <54867F51.1030603@redhat.com> <4ED173A868981548967B4FCA2707222628049113@AACMBXP04.exchserver.com> <1418148291.27499.20.camel@aleeredhat.laptop> <4ED173A868981548967B4FCA270722262804A449@AACMBXP04.exchserver.com> <4ED173A868981548967B4FCA27072226280A6EA9@AACMBXP04.exchserver.com> <4ED173A868981548967B4FCA27072226280AC187@AACMBXP04.exchserver.com> Message-ID: <54D23996.2080201@redhat.com> Les Stott wrote: > Has anyone got any ideas on this? > > I am stuck with not being able to deploy a CA Replica and this is halting rollout of the project. > > Help please... > > Regards, What is the version of IPA on the master you are connecting to? Can you confirm on the existing master that /etc/httpd/conf.d/ipa-pki-proxy.conf has /ca/ee/ca/profileSubmit in it: # matches for ee port rob > > Les > >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >> bounces at redhat.com] On Behalf Of Les Stott >> Sent: Friday, 30 January 2015 4:48 PM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] CA Replication Installation Failing >> >> >> >>> -----Original Message----- >>> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >>> bounces at redhat.com] On Behalf Of Les Stott >>> Sent: Wednesday, 10 December 2014 6:22 PM >>> To: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] CA Replication Installation Failing >>> >>> >>> >>>> -----Original Message----- >>>> From: Ade Lee [mailto:alee at redhat.com] >>>> Sent: Wednesday, 10 December 2014 5:05 AM >>>> To: Les Stott >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] CA Replication Installation Failing >>>> >>>> On Tue, 2014-12-09 at 07:48 +0000, Les Stott wrote: >>>>> >>>>> >>>>> >>>> >>> __________________________________________________________ >>>> ____________ >>>>> From: freeipa-users-bounces at redhat.com >>>>> [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal >>>>> [dpal at redhat.com] >>>>> Sent: Tuesday, December 09, 2014 3:49 PM >>>>> To: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] CA Replication Installation Failing >>>>> >>>>> >>>>> >>>>> On 12/08/2014 11:04 PM, Les Stott wrote: >>>>> >>>>>> Does anyone have any ideas on the below errors when trying to >>>>>> add CA replication to an existing replica? >>>>>> >>>>>> >>>>> >>>>>> People who might be able to help are or PTO right now. >>>>>> >>>>>> Is your installation older than 2 years? >>>>> >>>>> No, December 2013 was when it was originally built. >>>>> >>>>>> Did you generate a new replica package or use the original one? >>>>> >>>>> I used the original replica file for serverb, based on >>>>> instructions i came across. I can try regenerating the replica file. >>>>> >>>>> Interestingly, now that you mention it, servera had to be restored >>>>> a couple of months back. Perhaps this is an issue and regenerating >>>>> the replica file for serverb will be required. >>>>> >>>>> I will try this. >>>>> >>>> >>>> I think that this is a safe bet to be the problem. >>>> >>>> The error in the log snippet you posted says: >>>> >>>> The pkcs12 file is not correct. >>>> >>>> This indicates that the clone CA was unable to decode the pkcs12 >>>> file in the replica. Perhaps the certs changed -- or the DM password >> changed? >>>> >>>> Ade >>> >>> I regenerated the replica file and retired the CA replica setup, but >>> it failed at the same point with the same error. >>> >>> I am thinking that the next step is to uninstall the ipa replica to >>> cleanup, remove all traces and re-add as a replica on serverb. >>> >>> I wonder if the cert that its having an issue with is the one on >>> serverB under /etc/ipa/ca.crt which is from Dec 2013. >>> >>> I will try that in a couple of days as I have to schedule this work in >>> as its in production. >>> >>> Regards, >>> >>> Les >>> >>> >>>>>> May be the problem is that the cert that is in that package >>>>>> already >>>>> expired? >>>>> >>>>> original replica file was created on Dec 16 2013. Cert is not set >>>>> to expire until 2015-12-17. >>>>> >>>>>> Just a thought... >>>>>> >>>>>> The simplest workaround IMO would be to prepare Server C, >>>>>> install it >>>>> with CA and then decommission replica B. >>>>>> Do not forget to clean replication agreements on master. >>>>>> >>>>>> But that would be work around, would not solve this specific >>>>> problem, it will kill it. >>>>> >>>>> I actually do have serverc and serverd. I planned to have CA >>>>> replication on at least 2 other servers, but held off on trying on >>>>> serverc due to issues with serverb. >>>>> >>>>> I'll report back what i find after regenerating the replica file >>>>> and re-trying to setup CA replication. >>>>> >> >> After a bit of a hiatus I have revisited this issue and I still have it. >> >> Just to re-iterate the problem... >> >> Trying to setup a ca replica on an already installed replica fails in rhel 6.6, >> ipa-3.0.0.42, pki 9.0.3-38. >> >> /usr/sbin/ipa-ca-install -p xxxxxx -w xxxxxx -U /var/lib/ipa/replica-info- >> myhost.mydomain.com.gpg >> >> It fails showing.... "CRITICAL failed to configure ca instance" >> Configuring certificate server (pki-cad): Estimated time 3 minutes 30 >> seconds >> [1/16]: creating certificate server user >> [2/16]: creating pki-ca instance >> [3/16]: configuring certificate server instance >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> It doesn't matter if I run it interactively or unattended. >> >> I have done this on similar servers that were rhel 6.5, pki-9.0.3-32, ipa 3.0.0- >> 37 without any issue. >> >> The /var/log/ipareplica-ca-install.log shows the following error about White >> Spaces: >> >> ############################################# >> Attempting to connect to: mymaster.mydomain.com:9445 Connected. >> Posting Query = https:// >> mymaster.mydomain.com:9445//ca/admin/console/config/wizard?sdomain >> URL=https%3A%2F%2Fmymaster.mydomain.com%3A443&sdomainName=& >> choice=existingdomain&p=3&op=next&xml=true >> RESPONSE STATUS: HTTP/1.1 200 OK >> RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: >> Content-Type: application/xml;charset=UTF-8 RESPONSE HEADER: Date: Fri, >> 30 Jan 2015 05:05:04 GMT RESPONSE HEADER: Connection: close > version="1.0" encoding="UTF-8"?> >> admin/console/config/securitydomainpanel.vm >> 443 >> mymaster.mydomain.com >> >> CA >> /sbin/service pki-cad >> <security_domain_instance_name> >> https:// myhost.mydomain.com:9445 >> >> 80 >> org.xml.sax.SAXParseException; lineNumber: 1; >> columnNumber: 50; White spaces are required between publicId and >> systemId. >> >> The /var/log/pki-ca/debug also shows.... >> >> [30/Jan/2015:00:05:04][http-9445-1]: SecurityDomainPanel: validating SSL >> Admin HTTPS . . . >> [30/Jan/2015:00:05:04][http-9445-1]: WizardPanelBase pingCS: started >> [30/Jan/2015:00:05:04][http-9445-1]: WizardPanelBase: pingCS: parser >> failedorg.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; >> White spaces are required between publicId and systemId. >> [30/Jan/2015:00:05:04][http-9445-1]: SecurityDomainPanel: pingAdminCS no >> successful response for SSL Admin HTTPS >> [30/Jan/2015:00:05:05][http-9445-1]: WizardPanelBase >> getCertChainUsingSecureAdminPort start >> [30/Jan/2015:00:05:05][http-9445-1]: >> WizardPanelBase::getCertChainUsingSecureAdminPort() - >> Exception=org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: >> 50; White spaces are required between publicId and systemId. >> [30/Jan/2015:00:05:05][http-9445-1]: WizardPanelBase: >> getCertChainUsingSecureAdminPort: java.io.IOException: >> org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White >> spaces are required between publicId and systemId. >> >> When I compare those logs to the logs from the server I installed a ca- >> replica on successfully, the above is the point where the logs differ and it >> must be the source of the error. >> >> In the log of the server that was successful it shows what should have >> happened... >> >> [25/Nov/2014:00:09:54][http-9445-2]: SecurityDomainPanel: validating SSL >> Admin HTTPS . . . >> [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase pingCS: started >> [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase pingCS: got XML >> parsed >> [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase pingCS: state=1 >> [25/Nov/2014:00:09:54][http-9445-2]: SecurityDomainPanel: pingAdminCS >> returns: 1 >> [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase >> getCertChainUsingSecureAdminPort start >> [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase >> getCertChainUsingSecureAdminPort: status=0 >> [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase >> getCertChainUsingSecureAdminPort: certchain= >> >> I have tried rolling back pki rpms to 9.0.3-32 but this hasn't helped. >> >> Note, also, I am trying this on new servers, not the same ones used in >> December. >> >> I have searched high and low on google to try and find a resolution for the >> White Space issue but haven't found anything that worked. >> >> This seems like a bug to me. >> >> Can anyone help with this please? >> >> Thanks in advance, >> >> Regards, >> >> Les >> >> >> >> >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project > From alee at redhat.com Wed Feb 4 17:33:09 2015 From: alee at redhat.com (Ade Lee) Date: Wed, 04 Feb 2015 12:33:09 -0500 Subject: [Freeipa-users] CA Replication Installation Failing In-Reply-To: <1423059583.19504.10.camel@alee-redhat.laptop> References: <4ED173A868981548967B4FCA270722262803F3C5@AACMBXP04.exchserver.com> <4ED173A868981548967B4FCA2707222628048DF6@AACMBXP04.exchserver.com> , <54867F51.1030603@redhat.com> <4ED173A868981548967B4FCA2707222628049113@AACMBXP04.exchserver.com> <1418148291.27499.20.camel@aleeredhat.laptop> <4ED173A868981548967B4FCA270722262804A449@AACMBXP04.exchserver.com> <4ED173A868981548967B4FCA27072226280A6EA9@AACMBXP04.exchserver.com> <1423059583.19504.10.camel@alee-redhat.laptop> Message-ID: <1423071189.20584.10.camel@alee-redhat.laptop> Actually, it looks like it fails even earlier than getting the domain info - that is, when the replica contacts the master and tries to get its cert chain. I think that you have modified the logs slightly? There are a couple of things that don't make sense. See annotated log below -- On Wed, 2015-02-04 at 09:19 -0500, Ade Lee wrote: > >From the snippet of log below, it looks like the replica CA is trying to > contact the master CA to obtain the security domain information and is > failing to get a valid response. > > The message about "spaces and parsing" is basically the replica saying > that it cannot understand the response -- or lack of one from the master > CA. As this is an old version of IPA and Dogtag, it is trying to > contact the master CA on port 9443. > > Things to look into: > 1) Is the CA on the master up? Is port 9443 open on the master > (firewalls on master or replica)? You could test this by using a > browser/curl on the replica to go to > https://:9443/ca/admin/ca/getDomainXML > > 2) Is selinux preventing the access? You might want to set it in > permissive mode on either master or replica. > > 3) Do you see activity in the master's debug log? > > This looks to me like a different error from what was described before. > Its failing much earlier now. > > Ade > > On Fri, 2015-01-30 at 05:48 +0000, Les Stott wrote: > > > > > -----Original Message----- > > > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > > > bounces at redhat.com] On Behalf Of Les Stott > > > Sent: Wednesday, 10 December 2014 6:22 PM > > > To: freeipa-users at redhat.com > > > Subject: Re: [Freeipa-users] CA Replication Installation Failing > > > > > > > > > > > > > -----Original Message----- > > > > From: Ade Lee [mailto:alee at redhat.com] > > > > Sent: Wednesday, 10 December 2014 5:05 AM > > > > To: Les Stott > > > > Cc: freeipa-users at redhat.com > > > > Subject: Re: [Freeipa-users] CA Replication Installation Failing > > > > > > > > On Tue, 2014-12-09 at 07:48 +0000, Les Stott wrote: > > > > > > > > > > > > > > > > > > > > > > __________________________________________________________ > > > > ____________ > > > > > From: freeipa-users-bounces at redhat.com > > > > > [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal > > > > > [dpal at redhat.com] > > > > > Sent: Tuesday, December 09, 2014 3:49 PM > > > > > To: freeipa-users at redhat.com > > > > > Subject: Re: [Freeipa-users] CA Replication Installation Failing > > > > > > > > > > > > > > > > > > > > On 12/08/2014 11:04 PM, Les Stott wrote: > > > > > > > > > > > Does anyone have any ideas on the below errors when trying to add > > > > > > CA replication to an existing replica? > > > > > > > > > > > > > > > > > > > > > > > People who might be able to help are or PTO right now. > > > > > > > > > > > > Is your installation older than 2 years? > > > > > > > > > > No, December 2013 was when it was originally built. > > > > > > > > > > > Did you generate a new replica package or use the original one? > > > > > > > > > > I used the original replica file for serverb, based on instructions > > > > > i came across. I can try regenerating the replica file. > > > > > > > > > > Interestingly, now that you mention it, servera had to be restored a > > > > > couple of months back. Perhaps this is an issue and regenerating the > > > > > replica file for serverb will be required. > > > > > > > > > > I will try this. > > > > > > > > > > > > > I think that this is a safe bet to be the problem. > > > > > > > > The error in the log snippet you posted says: > > > > > > > > The pkcs12 file is not correct. > > > > > > > > This indicates that the clone CA was unable to decode the pkcs12 file > > > > in the replica. Perhaps the certs changed -- or the DM password changed? > > > > > > > > Ade > > > > > > I regenerated the replica file and retired the CA replica setup, but it failed at > > > the same point with the same error. > > > > > > I am thinking that the next step is to uninstall the ipa replica to cleanup, > > > remove all traces and re-add as a replica on serverb. > > > > > > I wonder if the cert that its having an issue with is the one on serverB under > > > /etc/ipa/ca.crt which is from Dec 2013. > > > > > > I will try that in a couple of days as I have to schedule this work in as its in > > > production. > > > > > > Regards, > > > > > > Les > > > > > > > > > > > > May be the problem is that the cert that is in that package > > > > > > already > > > > > expired? > > > > > > > > > > original replica file was created on Dec 16 2013. Cert is not set to > > > > > expire until 2015-12-17. > > > > > > > > > > > Just a thought... > > > > > > > > > > > > The simplest workaround IMO would be to prepare Server C, install > > > > > > it > > > > > with CA and then decommission replica B. > > > > > > Do not forget to clean replication agreements on master. > > > > > > > > > > > > But that would be work around, would not solve this specific > > > > > problem, it will kill it. > > > > > > > > > > I actually do have serverc and serverd. I planned to have CA > > > > > replication on at least 2 other servers, but held off on trying on > > > > > serverc due to issues with serverb. > > > > > > > > > > I'll report back what i find after regenerating the replica file and > > > > > re-trying to setup CA replication. > > > > > > > > > After a bit of a hiatus I have revisited this issue and I still have it. > > > > Just to re-iterate the problem... > > > > Trying to setup a ca replica on an already installed replica fails in rhel 6.6, ipa-3.0.0.42, pki 9.0.3-38. > > > > /usr/sbin/ipa-ca-install -p xxxxxx -w xxxxxx -U /var/lib/ipa/replica-info-myhost.mydomain.com.gpg > > > > It fails showing.... "CRITICAL failed to configure ca instance" > > Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds > > [1/16]: creating certificate server user > > [2/16]: creating pki-ca instance > > [3/16]: configuring certificate server instance > > > > Your system may be partly configured. > > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > > > It doesn't matter if I run it interactively or unattended. > > > > I have done this on similar servers that were rhel 6.5, pki-9.0.3-32, ipa 3.0.0-37 without any issue. > > > > The /var/log/ipareplica-ca-install.log shows the following error about White Spaces: > > > > ############################################# > > Attempting to connect to: mymaster.mydomain.com:9445 ^^ I assume mymaster.mydomain.com is the replica > > Connected. > > Posting Query = https:// mymaster.mydomain.com:9445//ca/admin/console/config/wizard?sdomainURL=https%3A%2F%2Fmymaster.mydomain.com%3A443&sdomainName=&choice=existingdomain&p=3&op=next&xml=true ^^ sdomainURL is myhost.mydomain.com:9445 ? This is supposed to be the URL for the original master. > > RESPONSE STATUS: HTTP/1.1 200 OK > > RESPONSE HEADER: Server: Apache-Coyote/1.1 > > RESPONSE HEADER: Content-Type: application/xml;charset=UTF-8 > > RESPONSE HEADER: Date: Fri, 30 Jan 2015 05:05:04 GMT > > RESPONSE HEADER: Connection: close > > > > > > admin/console/config/securitydomainpanel.vm > > 443 > > mymaster.mydomain.com > > > > CA > > /sbin/service pki-cad > > <security_domain_instance_name> > > https:// myhost.mydomain.com:9445 ^^ as above - I assume this is the original master URL? > > > > 80 > > org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId. > > > > The /var/log/pki-ca/debug also shows.... > > > > [30/Jan/2015:00:05:04][http-9445-1]: SecurityDomainPanel: validating SSL Admin HTTPS . . . > > [30/Jan/2015:00:05:04][http-9445-1]: WizardPanelBase pingCS: started > > [30/Jan/2015:00:05:04][http-9445-1]: WizardPanelBase: pingCS: parser failedorg.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId. > > [30/Jan/2015:00:05:04][http-9445-1]: SecurityDomainPanel: pingAdminCS no successful response for SSL Admin HTTPS > > [30/Jan/2015:00:05:05][http-9445-1]: WizardPanelBase getCertChainUsingSecureAdminPort start > > [30/Jan/2015:00:05:05][http-9445-1]: WizardPanelBase::getCertChainUsingSecureAdminPort() - Exception=org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId. > > [30/Jan/2015:00:05:05][http-9445-1]: WizardPanelBase: getCertChainUsingSecureAdminPort: java.io.IOException: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId. its calling https://:9445/ca/admin/ca/getCertChain and not getting a good response. OR it might be calling https://:443/ca/admin/ca/getCertChain It would be whatever is indicated in the log for sdomainURL. If its going to port 443, then you should check that the httpd server is running on the master - and check the access log. > > > > When I compare those logs to the logs from the server I installed a ca-replica on successfully, the above is the point where the logs differ and it must be the source of the error. > > > > In the log of the server that was successful it shows what should have happened... > > > > [25/Nov/2014:00:09:54][http-9445-2]: SecurityDomainPanel: validating SSL Admin HTTPS . . . > > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase pingCS: started > > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase pingCS: got XML parsed > > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase pingCS: state=1 > > [25/Nov/2014:00:09:54][http-9445-2]: SecurityDomainPanel: pingAdminCS returns: 1 > > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase getCertChainUsingSecureAdminPort start > > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase getCertChainUsingSecureAdminPort: status=0 > > [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase getCertChainUsingSecureAdminPort: certchain= > > > > I have tried rolling back pki rpms to 9.0.3-32 but this hasn't helped. > > > > Note, also, I am trying this on new servers, not the same ones used in December. > > > > I have searched high and low on google to try and find a resolution for the White Space issue but haven't found anything that worked. > > > > This seems like a bug to me. > > > > Can anyone help with this please? > > > > Thanks in advance, > > > > Regards, > > > > Les > > > > > > > > > > > > > > From mesman at stata.com Wed Feb 4 20:47:28 2015 From: mesman at stata.com (Mark Esman) Date: Wed, 04 Feb 2015 14:47:28 -0600 Subject: [Freeipa-users] Automember enrolledby Message-ID: <54D28560.70807@stata.com> Hello all, I'm having a little trouble with the automember function using "enrolledby" attribute. I have tried a number of different regex's to define the username and automagically enroll the host into the specified host group: .*ipainstaller.* ".*ipainstaller.*" '.*ipainstaller.*' etc. After client install, the server command: server#> ipa host-find machine.example.com --all shows: enrolledby_user: ipainstaller but the machine is not enrolled in the assigned host group. My server is Centos 7 with ipa-server.x86_64 3.3.3-28.0.1.el7.centos.3 from the updates repo. I found this link, but it doesn't look like any work has been done on this issue. https://fedorahosted.org/freeipa/ticket/3598 Has anyone seen this issue and/or have a workaround? Thanks, Mark From hugh at psychopig.com Wed Feb 4 20:01:34 2015 From: hugh at psychopig.com (Hugh) Date: Wed, 04 Feb 2015 14:01:34 -0600 Subject: [Freeipa-users] AD/IPA login compatibility In-Reply-To: <54CAB395.6040704@redhat.com> References: <54CAB395.6040704@redhat.com> Message-ID: <54D27A9E.2060904@psychopig.com> On 1/29/2015 4:26 PM, Dmitri Pal wrote: > How are the domains connected? Do you use trust or sync? Trust. We wanted to have just one account and not need to install additional software on the AD servers if possible. >> 1) Is it possible to log into a workstation that's been joined to a >> domain with IPA credentials? >> > > You mean can I access a Windows workstation joined to AD domain by user > from IPA domain? > No it is not implemented. It will require Global Catalog support in IPA. Out of curiosity, then why can we do this with the regular Kerberos? > If you just want to use IPA for windows you for now have to use the same > Kerberos setup on Windows workstations as you have in the old domain. Do you mean use regular MIT Kerberos instead of FreeIPA, or configure the Kerberos portion of FreeIPA like we had it in our old domain? On a semi-related note, is there a way to be able to log into a Linux workstation with an AD account without having to specify the AD domain? In other words, ssh to a server with instead of . Thanks again in advance, Hugh From rcritten at redhat.com Wed Feb 4 23:21:44 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Feb 2015 18:21:44 -0500 Subject: [Freeipa-users] Automember enrolledby In-Reply-To: <54D28560.70807@stata.com> References: <54D28560.70807@stata.com> Message-ID: <54D2A988.9040906@redhat.com> Mark Esman wrote: > Hello all, > > I'm having a little trouble with the automember function using > "enrolledby" attribute. I have tried a number of different regex's > to define the username and automagically enroll the host into the > specified host group: > > .*ipainstaller.* > ".*ipainstaller.*" > '.*ipainstaller.*' > etc. > > After client install, the server command: > > server#> ipa host-find machine.example.com --all > > shows: enrolledby_user: ipainstaller > but the machine is not enrolled in the assigned host group. > > My server is Centos 7 with ipa-server.x86_64 3.3.3-28.0.1.el7.centos.3 > from the updates repo. > > I found this link, but it doesn't look like any work has been > done on this issue. https://fedorahosted.org/freeipa/ticket/3598 > > Has anyone seen this issue and/or have a workaround? > automember is executed when new entries are added. The enrolled_by isn't set at the same time the host is added so it isn't triggering the rule. IPA 4.0 added an automember-rebuild which would pick this up but you'd need to run this periodically. I updated the ticket with this information as well. rob From mesman at stata.com Thu Feb 5 04:03:10 2015 From: mesman at stata.com (Mark Esman) Date: Wed, 04 Feb 2015 22:03:10 -0600 Subject: [Freeipa-users] Automember enrolledby In-Reply-To: <54D2A988.9040906@redhat.com> References: <54D28560.70807@stata.com> <54D2A988.9040906@redhat.com> Message-ID: <54D2EB7E.3020909@stata.com> Thanks for the info Rob, Well, that's a big bummer. I am trying to write kickstart scripts with different IPA usernames such that they will automatically enroll machines into specific hostgroups (with associated permissions/roles/etc). Thanks for updating the ticket... I don't know if there's going to be a port/update for Centos 7 for freeipa 4, but even the "automember-rebuild" feature wouldn't really be a viable option for my situation. Anyone else run into similar situations and have any ideas? Mark On 2/4/2015 5:21 PM, Rob Crittenden wrote: > Mark Esman wrote: >> Hello all, >> >> I'm having a little trouble with the automember function using >> "enrolledby" attribute. I have tried a number of different regex's >> to define the username and automagically enroll the host into the >> specified host group: >> >> .*ipainstaller.* >> ".*ipainstaller.*" >> '.*ipainstaller.*' >> etc. >> >> After client install, the server command: >> >> server#> ipa host-find machine.example.com --all >> >> shows: enrolledby_user: ipainstaller >> but the machine is not enrolled in the assigned host group. >> >> My server is Centos 7 with ipa-server.x86_64 3.3.3-28.0.1.el7.centos.3 >> from the updates repo. >> >> I found this link, but it doesn't look like any work has been >> done on this issue. https://fedorahosted.org/freeipa/ticket/3598 >> >> Has anyone seen this issue and/or have a workaround? >> > > automember is executed when new entries are added. The enrolled_by isn't > set at the same time the host is added so it isn't triggering the rule. > > IPA 4.0 added an automember-rebuild which would pick this up but you'd > need to run this periodically. > > I updated the ticket with this information as well. > > rob > From baghery.jone at gmail.com Thu Feb 5 05:23:06 2015 From: baghery.jone at gmail.com (alireza baghery) Date: Thu, 5 Feb 2015 08:53:06 +0330 Subject: [Freeipa-users] ipa replica (centos 6.5) integrate with AD 2008 Message-ID: hi i integrated ipa (centos 6.5) with AD windows server 2008 and anything do work i install replica server as follow: #(ipaserve ipa): replica- prepare ipareplica. example. com - - ip- address 192. 168. 1. 2 scp /var/lib/ipa/replica- info- ipareplica. example. com. gpg root at ipareplica: /var/lib/ipa/ ipa- replica- install --setup- dns - -forwarder=IP-AD /var/lib/ipa/replica- info- ipareplica. example. com. gpg but ipareplica do not work i turn off ipa sserver (master) but clients do not work with replica. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Thu Feb 5 06:59:55 2015 From: Less at imagine-sw.com (Les Stott) Date: Thu, 5 Feb 2015 06:59:55 +0000 Subject: [Freeipa-users] CA Replication Installation Failing - SOLVED! Message-ID: <4ED173A868981548967B4FCA27072226280ADB1C@AACMBXP04.exchserver.com> Guys, Thanks for your help. You pointed me in the right direction (checking the apache logs). In the end, it was missing modules in httpd.conf on the Master. I saw this error in /var/log/httpd/error_log [Wed Feb 04 21:26:00 2015] [warn] proxy: No protocol handler was valid for the URL /ca/admin/ca/getStatus. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule. [Wed Feb 04 21:26:00 2015] [warn] proxy: No protocol handler was valid for the URL /ca/admin/ca/getCertChain. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule. These modules were not being loaded... LoadModule proxy_ftp_module modules/mod_proxy_ftp.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule proxy_ajp_module modules/mod_proxy_ajp.so LoadModule proxy_connect_module modules/mod_proxy_connect.so Now it works. (well I have a different issue now with setting up a second replica ca, but that's another story and better in a new thread) Thanks, Les > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Thursday, 5 February 2015 2:24 AM > To: Les Stott; freeipa-users at redhat.com > Cc: Ade Lee > Subject: Re: [Freeipa-users] CA Replication Installation Failing > > Les Stott wrote: > > Has anyone got any ideas on this? > > > > I am stuck with not being able to deploy a CA Replica and this is halting > rollout of the project. > > > > Help please... > > > > Regards, > > What is the version of IPA on the master you are connecting to? > > Can you confirm on the existing master that /etc/httpd/conf.d/ipa-pki- > proxy.conf has /ca/ee/ca/profileSubmit in it: > > # matches for ee port > ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/ > updateNumberRange|^/ca/ee/ca/getCRL|^/ca/ee/ca/profileSubmit"> > > rob > > > > > Les > > > >> -----Original Message----- > >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > >> bounces at redhat.com] On Behalf Of Les Stott > >> Sent: Friday, 30 January 2015 4:48 PM > >> To: freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] CA Replication Installation Failing > >> > >> > >> > >>> -----Original Message----- > >>> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > >>> bounces at redhat.com] On Behalf Of Les Stott > >>> Sent: Wednesday, 10 December 2014 6:22 PM > >>> To: freeipa-users at redhat.com > >>> Subject: Re: [Freeipa-users] CA Replication Installation Failing > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Ade Lee [mailto:alee at redhat.com] > >>>> Sent: Wednesday, 10 December 2014 5:05 AM > >>>> To: Les Stott > >>>> Cc: freeipa-users at redhat.com > >>>> Subject: Re: [Freeipa-users] CA Replication Installation Failing > >>>> > >>>> On Tue, 2014-12-09 at 07:48 +0000, Les Stott wrote: > >>>>> > >>>>> > >>>>> > >>>> > >>> > __________________________________________________________ > >>>> ____________ > >>>>> From: freeipa-users-bounces at redhat.com > >>>>> [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal > >>>>> [dpal at redhat.com] > >>>>> Sent: Tuesday, December 09, 2014 3:49 PM > >>>>> To: freeipa-users at redhat.com > >>>>> Subject: Re: [Freeipa-users] CA Replication Installation Failing > >>>>> > >>>>> > >>>>> > >>>>> On 12/08/2014 11:04 PM, Les Stott wrote: > >>>>> > >>>>>> Does anyone have any ideas on the below errors when trying to add > >>>>>> CA replication to an existing replica? > >>>>>> > >>>>>> > >>>>> > >>>>>> People who might be able to help are or PTO right now. > >>>>>> > >>>>>> Is your installation older than 2 years? > >>>>> > >>>>> No, December 2013 was when it was originally built. > >>>>> > >>>>>> Did you generate a new replica package or use the original one? > >>>>> > >>>>> I used the original replica file for serverb, based on > >>>>> instructions i came across. I can try regenerating the replica file. > >>>>> > >>>>> Interestingly, now that you mention it, servera had to be restored > >>>>> a couple of months back. Perhaps this is an issue and regenerating > >>>>> the replica file for serverb will be required. > >>>>> > >>>>> I will try this. > >>>>> > >>>> > >>>> I think that this is a safe bet to be the problem. > >>>> > >>>> The error in the log snippet you posted says: > >>>> > >>>> The pkcs12 file is not correct. > >>>> > >>>> This indicates that the clone CA was unable to decode the pkcs12 > >>>> file in the replica. Perhaps the certs changed -- or the DM > >>>> password > >> changed? > >>>> > >>>> Ade > >>> > >>> I regenerated the replica file and retired the CA replica setup, but > >>> it failed at the same point with the same error. > >>> > >>> I am thinking that the next step is to uninstall the ipa replica to > >>> cleanup, remove all traces and re-add as a replica on serverb. > >>> > >>> I wonder if the cert that its having an issue with is the one on > >>> serverB under /etc/ipa/ca.crt which is from Dec 2013. > >>> > >>> I will try that in a couple of days as I have to schedule this work > >>> in as its in production. > >>> > >>> Regards, > >>> > >>> Les > >>> > >>> > >>>>>> May be the problem is that the cert that is in that package > >>>>>> already > >>>>> expired? > >>>>> > >>>>> original replica file was created on Dec 16 2013. Cert is not set > >>>>> to expire until 2015-12-17. > >>>>> > >>>>>> Just a thought... > >>>>>> > >>>>>> The simplest workaround IMO would be to prepare Server C, install > >>>>>> it > >>>>> with CA and then decommission replica B. > >>>>>> Do not forget to clean replication agreements on master. > >>>>>> > >>>>>> But that would be work around, would not solve this specific > >>>>> problem, it will kill it. > >>>>> > >>>>> I actually do have serverc and serverd. I planned to have CA > >>>>> replication on at least 2 other servers, but held off on trying on > >>>>> serverc due to issues with serverb. > >>>>> > >>>>> I'll report back what i find after regenerating the replica file > >>>>> and re-trying to setup CA replication. > >>>>> > >> > >> After a bit of a hiatus I have revisited this issue and I still have it. > >> > >> Just to re-iterate the problem... > >> > >> Trying to setup a ca replica on an already installed replica fails in > >> rhel 6.6, ipa-3.0.0.42, pki 9.0.3-38. > >> > >> /usr/sbin/ipa-ca-install -p xxxxxx -w xxxxxx -U > >> /var/lib/ipa/replica-info- myhost.mydomain.com.gpg > >> > >> It fails showing.... "CRITICAL failed to configure ca instance" > >> Configuring certificate server (pki-cad): Estimated time 3 minutes 30 > >> seconds > >> [1/16]: creating certificate server user > >> [2/16]: creating pki-ca instance > >> [3/16]: configuring certificate server instance > >> > >> Your system may be partly configured. > >> Run /usr/sbin/ipa-server-install --uninstall to clean up. > >> > >> It doesn't matter if I run it interactively or unattended. > >> > >> I have done this on similar servers that were rhel 6.5, pki-9.0.3-32, > >> ipa 3.0.0- > >> 37 without any issue. > >> > >> The /var/log/ipareplica-ca-install.log shows the following error > >> about White > >> Spaces: > >> > >> ############################################# > >> Attempting to connect to: mymaster.mydomain.com:9445 Connected. > >> Posting Query = https:// > >> > mymaster.mydomain.com:9445//ca/admin/console/config/wizard?sdomain > >> > URL=https%3A%2F%2Fmymaster.mydomain.com%3A443&sdomainName=& > >> choice=existingdomain&p=3&op=next&xml=true > >> RESPONSE STATUS: HTTP/1.1 200 OK > >> RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: > >> Content-Type: application/xml;charset=UTF-8 RESPONSE HEADER: Date: > >> Fri, > >> 30 Jan 2015 05:05:04 GMT RESPONSE HEADER: Connection: close >> version="1.0" encoding="UTF-8"?> > >> admin/console/config/securitydomainpanel.vm > >> 443 > >> mymaster.mydomain.com > >> > >> CA > >> /sbin/service pki-cad > >> <security_domain_instance_name> > >> https:// myhost.mydomain.com:9445 > >> > >> 80 > >> org.xml.sax.SAXParseException; lineNumber: 1; > >> columnNumber: 50; White spaces are required between publicId and > >> systemId. > >> > >> The /var/log/pki-ca/debug also shows.... > >> > >> [30/Jan/2015:00:05:04][http-9445-1]: SecurityDomainPanel: validating > >> SSL Admin HTTPS . . . > >> [30/Jan/2015:00:05:04][http-9445-1]: WizardPanelBase pingCS: started > >> [30/Jan/2015:00:05:04][http-9445-1]: WizardPanelBase: pingCS: parser > >> failedorg.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; > >> White spaces are required between publicId and systemId. > >> [30/Jan/2015:00:05:04][http-9445-1]: SecurityDomainPanel: pingAdminCS > >> no successful response for SSL Admin HTTPS > >> [30/Jan/2015:00:05:05][http-9445-1]: WizardPanelBase > >> getCertChainUsingSecureAdminPort start > >> [30/Jan/2015:00:05:05][http-9445-1]: > >> WizardPanelBase::getCertChainUsingSecureAdminPort() - > >> Exception=org.xml.sax.SAXParseException; lineNumber: 1; > columnNumber: > >> 50; White spaces are required between publicId and systemId. > >> [30/Jan/2015:00:05:05][http-9445-1]: WizardPanelBase: > >> getCertChainUsingSecureAdminPort: java.io.IOException: > >> org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; > White > >> spaces are required between publicId and systemId. > >> > >> When I compare those logs to the logs from the server I installed a > >> ca- replica on successfully, the above is the point where the logs > >> differ and it must be the source of the error. > >> > >> In the log of the server that was successful it shows what should > >> have happened... > >> > >> [25/Nov/2014:00:09:54][http-9445-2]: SecurityDomainPanel: validating > >> SSL Admin HTTPS . . . > >> [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase pingCS: started > >> [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase pingCS: got XML > >> parsed > >> [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase pingCS: state=1 > >> [25/Nov/2014:00:09:54][http-9445-2]: SecurityDomainPanel: pingAdminCS > >> returns: 1 > >> [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase > >> getCertChainUsingSecureAdminPort start > >> [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase > >> getCertChainUsingSecureAdminPort: status=0 > >> [25/Nov/2014:00:09:54][http-9445-2]: WizardPanelBase > >> getCertChainUsingSecureAdminPort: certchain= > >> > >> I have tried rolling back pki rpms to 9.0.3-32 but this hasn't helped. > >> > >> Note, also, I am trying this on new servers, not the same ones used > >> in December. > >> > >> I have searched high and low on google to try and find a resolution > >> for the White Space issue but haven't found anything that worked. > >> > >> This seems like a bug to me. > >> > >> Can anyone help with this please? > >> > >> Thanks in advance, > >> > >> Regards, > >> > >> Les > >> > >> > >> > >> > >> > >> > >> -- > >> Manage your subscription for the Freeipa-users mailing list: > >> https://www.redhat.com/mailman/listinfo/freeipa-users > >> Go To http://freeipa.org for more info on the project > > From dpal at redhat.com Thu Feb 5 07:25:17 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Feb 2015 02:25:17 -0500 Subject: [Freeipa-users] AD/IPA login compatibility In-Reply-To: <54D27A9E.2060904@psychopig.com> References: <54CAB395.6040704@redhat.com> <54D27A9E.2060904@psychopig.com> Message-ID: <54D31ADD.3000700@redhat.com> On 02/04/2015 03:01 PM, Hugh wrote: > On 1/29/2015 4:26 PM, Dmitri Pal wrote: >> How are the domains connected? Do you use trust or sync? > Trust. We wanted to have just one account and not need to install > additional software on the AD servers if possible. > >>> 1) Is it possible to log into a workstation that's been joined to a >>> domain with IPA credentials? >>> >> You mean can I access a Windows workstation joined to AD domain by user >> from IPA domain? >> No it is not implemented. It will require Global Catalog support in IPA. > Out of curiosity, then why can we do this with the regular Kerberos? With pure Kerberos the system is not "joined". Also the user ticket acquired from IPA does not have authorization data - PAC to be of any meaning in the realm. You need global catalog for this. So you can take your Windows system, put MIT Kerberos for Windows on it and a user from IPA will be able to authenticate to IPA. I am not sure you will be able to use trusts and authenticate AD users too, but I am not aware whether anyone tried. Kerberos libraries for Windows might be too old for this to work properly. But I am not sure. > >> If you just want to use IPA for windows you for now have to use the same >> Kerberos setup on Windows workstations as you have in the old domain. > Do you mean use regular MIT Kerberos instead of FreeIPA, or configure > the Kerberos portion of FreeIPA like we had it in our old domain? I mean configure MIT Kerberos for Windows on the Windows client. > > On a semi-related note, is there a way to be able to log into a Linux > workstation with an AD account without having to specify the AD domain? > In other words, ssh to a server with instead of > . You can set default domain in sssd and then when you use a short name it will append it. But for other domains you would have to spell names out. > > Thanks again in advance, > > Hugh > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Feb 5 07:29:26 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Feb 2015 02:29:26 -0500 Subject: [Freeipa-users] ipa replica (centos 6.5) integrate with AD 2008 In-Reply-To: References: Message-ID: <54D31BD6.60005@redhat.com> On 02/05/2015 12:23 AM, alireza baghery wrote: > hi > i integrated ipa (centos 6.5) with AD windows server 2008 and anything > do work > i install replica server as follow: > #(ipaserve ipa): replica- prepare ipareplica. example. com - - > ip- address 192. 168. 1. 2 > scp /var/lib/ipa/replica- info- ipareplica. example. com. > gpgroot at ipareplica: /var/lib/ipa/ > ipa- replica- install --setup- dns - -forwarder=IP-AD > /var/lib/ipa/replica- info- ipareplica. example. com. gpg > but ipareplica do not work > i turn off ipa sserver (master) but clients do not work with replica. > > Does it start? Can you authenticate or execute commands on the Replica? If you can it is probably a firewall issue, if you can't then replica might not have started or installed correctly. We would need logs for the install then and see the output of the sample ipa command. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Feb 5 09:44:39 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Feb 2015 11:44:39 +0200 Subject: [Freeipa-users] AD/IPA login compatibility In-Reply-To: <54D31ADD.3000700@redhat.com> References: <54CAB395.6040704@redhat.com> <54D27A9E.2060904@psychopig.com> <54D31ADD.3000700@redhat.com> Message-ID: <20150205094439.GD9247@redhat.com> On Thu, 05 Feb 2015, Dmitri Pal wrote: >On 02/04/2015 03:01 PM, Hugh wrote: >>On 1/29/2015 4:26 PM, Dmitri Pal wrote: >>>How are the domains connected? Do you use trust or sync? >>Trust. We wanted to have just one account and not need to install >>additional software on the AD servers if possible. >> >>>>1) Is it possible to log into a workstation that's been joined to a >>>>domain with IPA credentials? >>>> >>>You mean can I access a Windows workstation joined to AD domain by user >>>from IPA domain? >>>No it is not implemented. It will require Global Catalog support in IPA. >>Out of curiosity, then why can we do this with the regular Kerberos? > >With pure Kerberos the system is not "joined". >Also the user ticket acquired from IPA does not have authorization >data - PAC to be of any meaning in the realm. >You need global catalog for this. > >So you can take your Windows system, put MIT Kerberos for Windows on >it and a user from IPA will be able to authenticate to IPA. >I am not sure you will be able to use trusts and authenticate AD users >too, but I am not aware whether anyone tried. >Kerberos libraries for Windows might be too old for this to work >properly. But I am not sure. No, it will not work. Active Directory has a global list of trusted domains/forests and they are keyed by name. If you do trust to IPA as MIT Kerberos trust, it will not allow you to create trust to IPA as cross-forest trust because both will be set with the same name. >You can set default domain in sssd and then when you use a short name >it will append it. >But for other domains you would have to spell names out. This is unsupported for legacy clients and for IPA masters. On IPA masters we rely to have AD users fully qualified as this is what triggers name resolution for AD users in the compat tree. -- / Alexander Bokovoy From yamakasi.014 at gmail.com Thu Feb 5 10:54:05 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 5 Feb 2015 11:54:05 +0100 Subject: [Freeipa-users] Remove password exiration after useradd Message-ID: In the past we have done some testsetups with password expiring after we added a user, at the moment I have difficulties with this on 4.1.2 What I need is the following: - We add a user using json/kinit - The user is added in the right way - tThe user should be able to use his set password by the admin (at least ldap) At the moment the password is expired directly and I tried adding the user with min/max lifetime to 0/0 which didn't work out. Als 0/500 doesn't seem to fix my issue. I thought we had to do a little but more to accomplish this, but I'm not able to find this (anymore) Does someone have a clue how to fix this ? I'm quite sure this is possible. Thanks, Matt From dpal at redhat.com Thu Feb 5 12:18:39 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Feb 2015 07:18:39 -0500 Subject: [Freeipa-users] AD/IPA login compatibility In-Reply-To: <20150205094439.GD9247@redhat.com> References: <54CAB395.6040704@redhat.com> <54D27A9E.2060904@psychopig.com> <54D31ADD.3000700@redhat.com> <20150205094439.GD9247@redhat.com> Message-ID: <54D35F9F.3010705@redhat.com> On 02/05/2015 04:44 AM, Alexander Bokovoy wrote: > On Thu, 05 Feb 2015, Dmitri Pal wrote: >> On 02/04/2015 03:01 PM, Hugh wrote: >>> On 1/29/2015 4:26 PM, Dmitri Pal wrote: >>>> How are the domains connected? Do you use trust or sync? >>> Trust. We wanted to have just one account and not need to install >>> additional software on the AD servers if possible. >>> >>>>> 1) Is it possible to log into a workstation that's been joined to a >>>>> domain with IPA credentials? >>>>> >>>> You mean can I access a Windows workstation joined to AD domain by >>>> user >>>> from IPA domain? >>>> No it is not implemented. It will require Global Catalog support in >>>> IPA. >>> Out of curiosity, then why can we do this with the regular Kerberos? >> >> With pure Kerberos the system is not "joined". >> Also the user ticket acquired from IPA does not have authorization >> data - PAC to be of any meaning in the realm. >> You need global catalog for this. >> >> So you can take your Windows system, put MIT Kerberos for Windows on >> it and a user from IPA will be able to authenticate to IPA. >> I am not sure you will be able to use trusts and authenticate AD >> users too, but I am not aware whether anyone tried. >> Kerberos libraries for Windows might be too old for this to work >> properly. But I am not sure. > No, it will not work. Active Directory has a global list of trusted > domains/forests and they are keyed by name. If you do trust to IPA as > MIT Kerberos trust, it will not allow you to create trust to IPA as > cross-forest trust because both will be set with the same name. We are not talking about MIT kerberos server here. Just the Kerberos client libraries for Windows, so I think it might work. The comment you have applies to MIT KDC not to clients. > > >> You can set default domain in sssd and then when you use a short name >> it will append it. >> But for other domains you would have to spell names out. > This is unsupported for legacy clients and for IPA masters. On IPA > masters we rely to have AD users fully qualified as this is what > triggers name resolution for AD users in the compat tree. > Yes. But the question was about clients. On clients you can set a default domain. It is not recommended but if you do not have IPA users and only one AD domain that is the way to reduce typing of the whole fully qualified name. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Feb 5 12:21:24 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Feb 2015 07:21:24 -0500 Subject: [Freeipa-users] Remove password exiration after useradd In-Reply-To: References: Message-ID: <54D36044.4020601@redhat.com> On 02/05/2015 05:54 AM, Matt . wrote: > In the past we have done some testsetups with password expiring after > we added a user, at the moment I have difficulties with this on 4.1.2 > > What I need is the following: > > - We add a user using json/kinit > - The user is added in the right way > - tThe user should be able to use his set password by the admin (at least ldap) > > At the moment the password is expired directly and I tried adding the > user with min/max lifetime to 0/0 which didn't work out. Als 0/500 > doesn't seem to fix my issue. > > I thought we had to do a little but more to accomplish this, but I'm > not able to find this (anymore) > > Does someone have a clue how to fix this ? I'm quite sure this is possible. > > Thanks, > > Matt > It was always the feature of IPA to require password change on the first login after it was created. If you do not want it to be expired you need to change the expiration attribute of the account not min max life. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From abokovoy at redhat.com Thu Feb 5 12:25:55 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Feb 2015 14:25:55 +0200 Subject: [Freeipa-users] AD/IPA login compatibility In-Reply-To: <54D35F9F.3010705@redhat.com> References: <54CAB395.6040704@redhat.com> <54D27A9E.2060904@psychopig.com> <54D31ADD.3000700@redhat.com> <20150205094439.GD9247@redhat.com> <54D35F9F.3010705@redhat.com> Message-ID: <20150205122555.GE9247@redhat.com> On Thu, 05 Feb 2015, Dmitri Pal wrote: >On 02/05/2015 04:44 AM, Alexander Bokovoy wrote: >>On Thu, 05 Feb 2015, Dmitri Pal wrote: >>>On 02/04/2015 03:01 PM, Hugh wrote: >>>>On 1/29/2015 4:26 PM, Dmitri Pal wrote: >>>>>How are the domains connected? Do you use trust or sync? >>>>Trust. We wanted to have just one account and not need to install >>>>additional software on the AD servers if possible. >>>> >>>>>>1) Is it possible to log into a workstation that's been joined to a >>>>>>domain with IPA credentials? >>>>>> >>>>>You mean can I access a Windows workstation joined to AD >>>>>domain by user >>>>>from IPA domain? >>>>>No it is not implemented. It will require Global Catalog >>>>>support in IPA. >>>>Out of curiosity, then why can we do this with the regular Kerberos? >>> >>>With pure Kerberos the system is not "joined". >>>Also the user ticket acquired from IPA does not have authorization >>>data - PAC to be of any meaning in the realm. >>>You need global catalog for this. >>> >>>So you can take your Windows system, put MIT Kerberos for Windows >>>on it and a user from IPA will be able to authenticate to IPA. >>>I am not sure you will be able to use trusts and authenticate AD >>>users too, but I am not aware whether anyone tried. >>>Kerberos libraries for Windows might be too old for this to work >>>properly. But I am not sure. >>No, it will not work. Active Directory has a global list of trusted >>domains/forests and they are keyed by name. If you do trust to IPA as >>MIT Kerberos trust, it will not allow you to create trust to IPA as >>cross-forest trust because both will be set with the same name. > >We are not talking about MIT kerberos server here. >Just the Kerberos client libraries for Windows, so I think it might work. >The comment you have applies to MIT KDC not to clients. > >> >> >>>You can set default domain in sssd and then when you use a short >>>name it will append it. >>>But for other domains you would have to spell names out. >>This is unsupported for legacy clients and for IPA masters. On IPA >>masters we rely to have AD users fully qualified as this is what >>triggers name resolution for AD users in the compat tree. >> >Yes. But the question was about clients. >On clients you can set a default domain. It is not recommended but if >you do not have IPA users and only one AD domain that is the way to >reduce typing of the whole fully qualified name. Yep. Just DO NOT DO it on IPA masters or life of your legacy clients will be miserable. -- / Alexander Bokovoy From yamakasi.014 at gmail.com Thu Feb 5 12:59:37 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 5 Feb 2015 13:59:37 +0100 Subject: [Freeipa-users] Remove password exiration after useradd In-Reply-To: <54D36044.4020601@redhat.com> References: <54D36044.4020601@redhat.com> Message-ID: Hi, OK, but as far as I understand we made some change, using a commandline command which I cannot remember or find, which goes around the password policy, or the attribute you talk about, when you add a user. Can I change that globally? As we did it seems... but we were testing so much back those days that it seems to be lost or so. Thanks, Matt 2015-02-05 13:21 GMT+01:00 Dmitri Pal : > On 02/05/2015 05:54 AM, Matt . wrote: >> >> In the past we have done some testsetups with password expiring after >> we added a user, at the moment I have difficulties with this on 4.1.2 >> >> What I need is the following: >> >> - We add a user using json/kinit >> - The user is added in the right way >> - tThe user should be able to use his set password by the admin (at least >> ldap) >> >> At the moment the password is expired directly and I tried adding the >> user with min/max lifetime to 0/0 which didn't work out. Als 0/500 >> doesn't seem to fix my issue. >> >> I thought we had to do a little but more to accomplish this, but I'm >> not able to find this (anymore) >> >> Does someone have a clue how to fix this ? I'm quite sure this is >> possible. >> >> Thanks, >> >> Matt >> > It was always the feature of IPA to require password change on the first > login after it was created. > If you do not want it to be expired you need to change the expiration > attribute of the account not min max life. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From dpal at redhat.com Thu Feb 5 13:26:18 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Feb 2015 08:26:18 -0500 Subject: [Freeipa-users] Remove password exiration after useradd In-Reply-To: References: <54D36044.4020601@redhat.com> Message-ID: <54D36F7A.2040704@redhat.com> On 02/05/2015 07:59 AM, Matt . wrote: > Hi, > > OK, but as far as I understand we made some change, using a > commandline command which I cannot remember or find, which goes around > the password policy, or the attribute you talk about, when you add a > user. > > Can I change that globally? As we did it seems... but we were testing > so much back those days that it seems to be lost or so. I do not remember the detils from top of my head. You can probably try to search the mail archives. > > > Thanks, > > Matt > > 2015-02-05 13:21 GMT+01:00 Dmitri Pal : >> On 02/05/2015 05:54 AM, Matt . wrote: >>> In the past we have done some testsetups with password expiring after >>> we added a user, at the moment I have difficulties with this on 4.1.2 >>> >>> What I need is the following: >>> >>> - We add a user using json/kinit >>> - The user is added in the right way >>> - tThe user should be able to use his set password by the admin (at least >>> ldap) >>> >>> At the moment the password is expired directly and I tried adding the >>> user with min/max lifetime to 0/0 which didn't work out. Als 0/500 >>> doesn't seem to fix my issue. >>> >>> I thought we had to do a little but more to accomplish this, but I'm >>> not able to find this (anymore) >>> >>> Does someone have a clue how to fix this ? I'm quite sure this is >>> possible. >>> >>> Thanks, >>> >>> Matt >>> >> It was always the feature of IPA to require password change on the first >> login after it was created. >> If you do not want it to be expired you need to change the expiration >> attribute of the account not min max life. >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From yamakasi.014 at gmail.com Thu Feb 5 13:32:54 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 5 Feb 2015 14:32:54 +0100 Subject: [Freeipa-users] Remove password exiration after useradd In-Reply-To: <54D36F7A.2040704@redhat.com> References: <54D36044.4020601@redhat.com> <54D36F7A.2040704@redhat.com> Message-ID: HI, I'm already doing so without any luck. If you remember something, would be nice to know! So it should be possible to do still ? 2015-02-05 14:26 GMT+01:00 Dmitri Pal : > On 02/05/2015 07:59 AM, Matt . wrote: >> >> Hi, >> >> OK, but as far as I understand we made some change, using a >> commandline command which I cannot remember or find, which goes around >> the password policy, or the attribute you talk about, when you add a >> user. >> >> Can I change that globally? As we did it seems... but we were testing >> so much back those days that it seems to be lost or so. > > > I do not remember the detils from top of my head. You can probably try to > search the mail archives. > >> >> >> Thanks, >> >> Matt >> >> 2015-02-05 13:21 GMT+01:00 Dmitri Pal : >>> >>> On 02/05/2015 05:54 AM, Matt . wrote: >>>> >>>> In the past we have done some testsetups with password expiring after >>>> we added a user, at the moment I have difficulties with this on 4.1.2 >>>> >>>> What I need is the following: >>>> >>>> - We add a user using json/kinit >>>> - The user is added in the right way >>>> - tThe user should be able to use his set password by the admin (at >>>> least >>>> ldap) >>>> >>>> At the moment the password is expired directly and I tried adding the >>>> user with min/max lifetime to 0/0 which didn't work out. Als 0/500 >>>> doesn't seem to fix my issue. >>>> >>>> I thought we had to do a little but more to accomplish this, but I'm >>>> not able to find this (anymore) >>>> >>>> Does someone have a clue how to fix this ? I'm quite sure this is >>>> possible. >>>> >>>> Thanks, >>>> >>>> Matt >>>> >>> It was always the feature of IPA to require password change on the first >>> login after it was created. >>> If you do not want it to be expired you need to change the expiration >>> attribute of the account not min max life. >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > From jbaird at follett.com Thu Feb 5 13:41:34 2015 From: jbaird at follett.com (Baird, Josh) Date: Thu, 5 Feb 2015 13:41:34 +0000 Subject: [Freeipa-users] Real-time replication status (RFE)? Message-ID: Hi, I'm looking for an easy way to validate that all replication agreements are functioning correctly between all of my IPA masters and replicas. I am aware that I can run 'ipa-replica-manage list -v' from each IPA master, but I was looking for something more centralized that could give me a replication health report for all masters/replicas. Ideally, this type of feature would be exposed in the UI and would also include information or insight into the status of any IPA <-> AD trust relationships. Am I missing a feature that already exists? If not, is there something like this on the IPA roadmap? Cheers, Josh From dpal at redhat.com Thu Feb 5 13:55:08 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Feb 2015 08:55:08 -0500 Subject: [Freeipa-users] Remove password exiration after useradd In-Reply-To: References: <54D36044.4020601@redhat.com> <54D36F7A.2040704@redhat.com> Message-ID: <54D3763C.9090908@redhat.com> On 02/05/2015 08:32 AM, Matt . wrote: > HI, > > I'm already doing so without any luck. If you remember something, > would be nice to know! > > So it should be possible to do still ? Do the ipa user-show --raw, there will be a time stamp. It is krbPasswordExpiration attribute. It will be set to the user creation time (or something like, i.e. in the past). I think you can use ipa user-mod --setaddr... to set it to a value into the future. > > 2015-02-05 14:26 GMT+01:00 Dmitri Pal : >> On 02/05/2015 07:59 AM, Matt . wrote: >>> Hi, >>> >>> OK, but as far as I understand we made some change, using a >>> commandline command which I cannot remember or find, which goes around >>> the password policy, or the attribute you talk about, when you add a >>> user. >>> >>> Can I change that globally? As we did it seems... but we were testing >>> so much back those days that it seems to be lost or so. >> >> I do not remember the detils from top of my head. You can probably try to >> search the mail archives. >> >>> >>> Thanks, >>> >>> Matt >>> >>> 2015-02-05 13:21 GMT+01:00 Dmitri Pal : >>>> On 02/05/2015 05:54 AM, Matt . wrote: >>>>> In the past we have done some testsetups with password expiring after >>>>> we added a user, at the moment I have difficulties with this on 4.1.2 >>>>> >>>>> What I need is the following: >>>>> >>>>> - We add a user using json/kinit >>>>> - The user is added in the right way >>>>> - tThe user should be able to use his set password by the admin (at >>>>> least >>>>> ldap) >>>>> >>>>> At the moment the password is expired directly and I tried adding the >>>>> user with min/max lifetime to 0/0 which didn't work out. Als 0/500 >>>>> doesn't seem to fix my issue. >>>>> >>>>> I thought we had to do a little but more to accomplish this, but I'm >>>>> not able to find this (anymore) >>>>> >>>>> Does someone have a clue how to fix this ? I'm quite sure this is >>>>> possible. >>>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>> It was always the feature of IPA to require password change on the first >>>> login after it was created. >>>> If you do not want it to be expired you need to change the expiration >>>> attribute of the account not min max life. >>>> >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager IdM portfolio >>>> Red Hat, Inc. >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go To http://freeipa.org for more info on the project >> >> >> -- >> 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 mkosek at redhat.com Thu Feb 5 14:01:26 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 05 Feb 2015 15:01:26 +0100 Subject: [Freeipa-users] Remove password exiration after useradd In-Reply-To: <54D36044.4020601@redhat.com> References: <54D36044.4020601@redhat.com> Message-ID: <54D377B6.1030503@redhat.com> On 02/05/2015 01:21 PM, Dmitri Pal wrote: > On 02/05/2015 05:54 AM, Matt . wrote: >> In the past we have done some testsetups with password expiring after >> we added a user, at the moment I have difficulties with this on 4.1.2 >> >> What I need is the following: >> >> - We add a user using json/kinit >> - The user is added in the right way >> - tThe user should be able to use his set password by the admin (at least ldap) >> >> At the moment the password is expired directly and I tried adding the >> user with min/max lifetime to 0/0 which didn't work out. Als 0/500 >> doesn't seem to fix my issue. >> >> I thought we had to do a little but more to accomplish this, but I'm >> not able to find this (anymore) >> >> Does someone have a clue how to fix this ? I'm quite sure this is possible. >> >> Thanks, >> >> Matt >> > It was always the feature of IPA to require password change on the first login > after it was created. Yup. You can do some more reading here: http://www.freeipa.org/page/New_Passwords_Expired > If you do not want it to be expired you need to change the expiration attribute > of the account not min max life. Not sure what you mean now. But the administratively set passwords are always expired from the beginning, so the user has to change it. Then, the password policy applies. When you want to have non-expired passwords when added via some 3rd password management service, you would need to set it's principal as password synchronization agent (see the referred wiki page). Martin From rcritten at redhat.com Thu Feb 5 14:03:12 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Feb 2015 09:03:12 -0500 Subject: [Freeipa-users] Remove password exiration after useradd In-Reply-To: References: <54D36044.4020601@redhat.com> <54D36F7A.2040704@redhat.com> Message-ID: <54D37820.1070507@redhat.com> Matt . wrote: > HI, > > I'm already doing so without any luck. If you remember something, > would be nice to know! > > So it should be possible to do still ? If the DN of the entry adding the password is in passSyncManagersDNs in the entry dn: cn=ipa_pwd_extop,cn=plugins,cn=config then the password will not be marked as expired (password policy is not applied at all IIRC). rob > > 2015-02-05 14:26 GMT+01:00 Dmitri Pal : >> On 02/05/2015 07:59 AM, Matt . wrote: >>> >>> Hi, >>> >>> OK, but as far as I understand we made some change, using a >>> commandline command which I cannot remember or find, which goes around >>> the password policy, or the attribute you talk about, when you add a >>> user. >>> >>> Can I change that globally? As we did it seems... but we were testing >>> so much back those days that it seems to be lost or so. >> >> >> I do not remember the detils from top of my head. You can probably try to >> search the mail archives. >> >>> >>> >>> Thanks, >>> >>> Matt >>> >>> 2015-02-05 13:21 GMT+01:00 Dmitri Pal : >>>> >>>> On 02/05/2015 05:54 AM, Matt . wrote: >>>>> >>>>> In the past we have done some testsetups with password expiring after >>>>> we added a user, at the moment I have difficulties with this on 4.1.2 >>>>> >>>>> What I need is the following: >>>>> >>>>> - We add a user using json/kinit >>>>> - The user is added in the right way >>>>> - tThe user should be able to use his set password by the admin (at >>>>> least >>>>> ldap) >>>>> >>>>> At the moment the password is expired directly and I tried adding the >>>>> user with min/max lifetime to 0/0 which didn't work out. Als 0/500 >>>>> doesn't seem to fix my issue. >>>>> >>>>> I thought we had to do a little but more to accomplish this, but I'm >>>>> not able to find this (anymore) >>>>> >>>>> Does someone have a clue how to fix this ? I'm quite sure this is >>>>> possible. >>>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>> It was always the feature of IPA to require password change on the first >>>> login after it was created. >>>> If you do not want it to be expired you need to change the expiration >>>> attribute of the account not min max life. >>>> >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager IdM portfolio >>>> Red Hat, Inc. >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go To http://freeipa.org for more info on the project >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> > From rcritten at redhat.com Thu Feb 5 14:04:18 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Feb 2015 09:04:18 -0500 Subject: [Freeipa-users] ipa replica (centos 6.5) integrate with AD 2008 In-Reply-To: References: Message-ID: <54D37862.4080706@redhat.com> alireza baghery wrote: > hi > i integrated ipa (centos 6.5) with AD windows server 2008 and anything > do work > i install replica server as follow: > #(ipaserve ipa): replica- prepare ipareplica. example. com - - > ip- address 192. 168. 1. 2 > scp /var/lib/ipa/replica- info- ipareplica. example. com. > gpgroot at ipareplica: /var/lib/ipa/ > ipa- replica- install --setup- dns - -forwarder=IP-AD > /var/lib/ipa/replica- info- ipareplica. example. com. gpg > but ipareplica do not work > i turn off ipa sserver (master) but clients do not work with replica. What on the client is not working? rob From rcritten at redhat.com Thu Feb 5 14:18:57 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Feb 2015 09:18:57 -0500 Subject: [Freeipa-users] Real-time replication status (RFE)? In-Reply-To: References: Message-ID: <54D37BD1.2060508@redhat.com> Baird, Josh wrote: > Hi, > > I'm looking for an easy way to validate that all replication agreements are functioning correctly between all of my IPA masters and replicas. I am aware that I can run 'ipa-replica-manage list -v' from each IPA master, but I was looking for something more centralized that could give me a replication health report for all masters/replicas. Ideally, this type of feature would be exposed in the UI and would also include information or insight into the status of any IPA <-> AD trust relationships. > > Am I missing a feature that already exists? If not, is there something like this on the IPA roadmap? This is being tracked in https://fedorahosted.org/freeipa/ticket/4390 It depends on some other work being done first. rob From yamakasi.014 at gmail.com Thu Feb 5 14:57:36 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 5 Feb 2015 15:57:36 +0100 Subject: [Freeipa-users] Remove password exiration after useradd In-Reply-To: <54D3763C.9090908@redhat.com> References: <54D36044.4020601@redhat.com> <54D36F7A.2040704@redhat.com> <54D3763C.9090908@redhat.com> Message-ID: Hi, Thank, this brought me further. I don't see that attribute while kinit as admin. When I use an ldap editor and login ad DM on my full cn domain I can get into kerberos => My DN => cn=global policy. When when I set the krbMaxPwdLife very high this doesn't matter, I need to higher up the first calcuation... I need the global kerberos calculation time for that, but where is it located ? That would solve my issue for sure! > On 02/05/2015 08:32 AM, Matt . wrote: >> >> HI, >> >> I'm already doing so without any luck. If you remember something, >> would be nice to know! >> >> So it should be possible to do still ? > > > Do the > ipa user-show --raw, there will be a time stamp. It is krbPasswordExpiration > attribute. It will be set to the user creation time (or something like, i.e. > in the past). > I think you can use ipa user-mod --setaddr... to set it to a value into the > future. > > >> >> 2015-02-05 14:26 GMT+01:00 Dmitri Pal : >>> >>> On 02/05/2015 07:59 AM, Matt . wrote: >>>> >>>> Hi, >>>> >>>> OK, but as far as I understand we made some change, using a >>>> commandline command which I cannot remember or find, which goes around >>>> the password policy, or the attribute you talk about, when you add a >>>> user. >>>> >>>> Can I change that globally? As we did it seems... but we were testing >>>> so much back those days that it seems to be lost or so. >>> >>> >>> I do not remember the detils from top of my head. You can probably try to >>> search the mail archives. >>> >>>> >>>> Thanks, >>>> >>>> Matt >>>> >>>> 2015-02-05 13:21 GMT+01:00 Dmitri Pal : >>>>> >>>>> On 02/05/2015 05:54 AM, Matt . wrote: >>>>>> >>>>>> In the past we have done some testsetups with password expiring after >>>>>> we added a user, at the moment I have difficulties with this on 4.1.2 >>>>>> >>>>>> What I need is the following: >>>>>> >>>>>> - We add a user using json/kinit >>>>>> - The user is added in the right way >>>>>> - tThe user should be able to use his set password by the admin (at >>>>>> least >>>>>> ldap) >>>>>> >>>>>> At the moment the password is expired directly and I tried adding the >>>>>> user with min/max lifetime to 0/0 which didn't work out. Als 0/500 >>>>>> doesn't seem to fix my issue. >>>>>> >>>>>> I thought we had to do a little but more to accomplish this, but I'm >>>>>> not able to find this (anymore) >>>>>> >>>>>> Does someone have a clue how to fix this ? I'm quite sure this is >>>>>> possible. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Matt >>>>>> >>>>> It was always the feature of IPA to require password change on the >>>>> first >>>>> login after it was created. >>>>> If you do not want it to be expired you need to change the expiration >>>>> attribute of the account not min max life. >>>>> >>>>> -- >>>>> Thank you, >>>>> Dmitri Pal >>>>> >>>>> Sr. Engineering Manager IdM portfolio >>>>> Red Hat, Inc. >>>>> >>>>> -- >>>>> Manage your subscription for the Freeipa-users mailing list: >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> Go To http://freeipa.org for more info on the project >>> >>> >>> >>> -- >>> 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 nicolas.zin at savoirfairelinux.com Thu Feb 5 16:00:50 2015 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Thu, 5 Feb 2015 11:00:50 -0500 (EST) Subject: [Freeipa-users] one way AD trust relationship In-Reply-To: <543821355.97203.1423151898278.JavaMail.root@mail> Message-ID: <1061078355.97496.1423152050650.JavaMail.root@mail> Hi, is it possible to create a one way AD trust relationship with FreeIPA/IDM 3.3? - From Windows I created an incoming one-way trust relationship, with a trust-secret - on Linux I use the trust-secret with ipa: ipa trust-add --type=ad ipawindows.mtl.sfl --trust-secret everything seems to be fine, but when I try kinit Administrator at ipawindows.mtl.sfl kinit: KDC reply did not match expectations while getting initial credentials I tried others ways, but I wonder if it is possible to have a one-way trust relationship? Thanks for your help! Nicolas Zin nicolas.zin at savoirfairelinux.com Ligne directe: 514-276-5468 poste 135 Fax : 514-276-5465 7275 Saint Urbain Bureau 200 Montr?al, QC, H2R 2Y5 From yamakasi.014 at gmail.com Thu Feb 5 16:13:26 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 5 Feb 2015 17:13:26 +0100 Subject: [Freeipa-users] Remove password exiration after useradd In-Reply-To: <54D37820.1070507@redhat.com> References: <54D36044.4020601@redhat.com> <54D36F7A.2040704@redhat.com> <54D37820.1070507@redhat.com> Message-ID: Yes, when receiving your email I found that indeed. My ldapEditor doesn't allow me to add that value, so this need to be done using the commandline ? 2015-02-05 15:03 GMT+01:00 Rob Crittenden : > Matt . wrote: >> HI, >> >> I'm already doing so without any luck. If you remember something, >> would be nice to know! >> >> So it should be possible to do still ? > > If the DN of the entry adding the password is in passSyncManagersDNs in > the entry dn: cn=ipa_pwd_extop,cn=plugins,cn=config then the password > will not be marked as expired (password policy is not applied at all IIRC). > > rob > >> >> 2015-02-05 14:26 GMT+01:00 Dmitri Pal : >>> On 02/05/2015 07:59 AM, Matt . wrote: >>>> >>>> Hi, >>>> >>>> OK, but as far as I understand we made some change, using a >>>> commandline command which I cannot remember or find, which goes around >>>> the password policy, or the attribute you talk about, when you add a >>>> user. >>>> >>>> Can I change that globally? As we did it seems... but we were testing >>>> so much back those days that it seems to be lost or so. >>> >>> >>> I do not remember the detils from top of my head. You can probably try to >>> search the mail archives. >>> >>>> >>>> >>>> Thanks, >>>> >>>> Matt >>>> >>>> 2015-02-05 13:21 GMT+01:00 Dmitri Pal : >>>>> >>>>> On 02/05/2015 05:54 AM, Matt . wrote: >>>>>> >>>>>> In the past we have done some testsetups with password expiring after >>>>>> we added a user, at the moment I have difficulties with this on 4.1.2 >>>>>> >>>>>> What I need is the following: >>>>>> >>>>>> - We add a user using json/kinit >>>>>> - The user is added in the right way >>>>>> - tThe user should be able to use his set password by the admin (at >>>>>> least >>>>>> ldap) >>>>>> >>>>>> At the moment the password is expired directly and I tried adding the >>>>>> user with min/max lifetime to 0/0 which didn't work out. Als 0/500 >>>>>> doesn't seem to fix my issue. >>>>>> >>>>>> I thought we had to do a little but more to accomplish this, but I'm >>>>>> not able to find this (anymore) >>>>>> >>>>>> Does someone have a clue how to fix this ? I'm quite sure this is >>>>>> possible. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Matt >>>>>> >>>>> It was always the feature of IPA to require password change on the first >>>>> login after it was created. >>>>> If you do not want it to be expired you need to change the expiration >>>>> attribute of the account not min max life. >>>>> >>>>> -- >>>>> Thank you, >>>>> Dmitri Pal >>>>> >>>>> Sr. Engineering Manager IdM portfolio >>>>> Red Hat, Inc. >>>>> >>>>> -- >>>>> Manage your subscription for the Freeipa-users mailing list: >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> Go To http://freeipa.org for more info on the project >>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >> > From Duncan.Innes at virginmoney.com Thu Feb 5 16:33:38 2015 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Thu, 5 Feb 2015 16:33:38 -0000 Subject: [Freeipa-users] Real-time replication status (RFE)? In-Reply-To: <54D37BD1.2060508@redhat.com> References: <54D37BD1.2060508@redhat.com> Message-ID: <56343345B145C043AE990701E3D193950478E3E4@EXVS2.nrplc.localnet> The screen mockup in that ticket is based on a Perl script that I stuck in cgi-bin to pull just those stats off each IPA server I have and display them. Can share the code if you're interested. D -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rob Crittenden Sent: 05 February 2015 14:19 To: Baird, Josh; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Real-time replication status (RFE)? Baird, Josh wrote: > Hi, > > I'm looking for an easy way to validate that all replication agreements are functioning correctly between all of my IPA masters and replicas. I am aware that I can run 'ipa-replica-manage list -v' from each IPA master, but I was looking for something more centralized that could give me a replication health report for all masters/replicas. Ideally, this type of feature would be exposed in the UI and would also include information or insight into the status of any IPA <-> AD trust relationships. > > Am I missing a feature that already exists? If not, is there something like this on the IPA roadmap? This is being tracked in https://fedorahosted.org/freeipa/ticket/4390 It depends on some other work being done first. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com From jbaird at follett.com Thu Feb 5 17:07:37 2015 From: jbaird at follett.com (Baird, Josh) Date: Thu, 5 Feb 2015 17:07:37 +0000 Subject: [Freeipa-users] Real-time replication status (RFE)? In-Reply-To: <56343345B145C043AE990701E3D193950478E3E4@EXVS2.nrplc.localnet> References: <54D37BD1.2060508@redhat.com> <56343345B145C043AE990701E3D193950478E3E4@EXVS2.nrplc.localnet> Message-ID: That would be great, thanks! Josh > -----Original Message----- > From: Innes, Duncan [mailto:Duncan.Innes at virginmoney.com] > Sent: Thursday, February 05, 2015 11:34 AM > To: Rob Crittenden; Baird, Josh; freeipa-users at redhat.com > Subject: RE: [Freeipa-users] Real-time replication status (RFE)? > > The screen mockup in that ticket is based on a Perl script that I stuck in cgi-bin > to pull just those stats off each IPA server I have and display them. Can share > the code if you're interested. > > D > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rob Crittenden > Sent: 05 February 2015 14:19 > To: Baird, Josh; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Real-time replication status (RFE)? > > Baird, Josh wrote: > > Hi, > > > > I'm looking for an easy way to validate that all replication > agreements are functioning correctly between all of my IPA masters and > replicas. I am aware that I can run 'ipa-replica-manage list -v' from each IPA > master, but I was looking for something more centralized that could give me > a replication health report for all masters/replicas. > Ideally, this type of feature would be exposed in the UI and would also > include information or insight into the status of any IPA <-> AD trust > relationships. > > > > Am I missing a feature that already exists? If not, is there > something like this on the IPA roadmap? > > This is being tracked in https://fedorahosted.org/freeipa/ticket/4390 > > It depends on some other work being done first. > > rob > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > This message has been checked for viruses and spam by the Virgin Money > email scanning system powered by Messagelabs. > > This message has been checked for viruses and spam by the Virgin Money > email scanning system powered by Messagelabs. > > This e-mail is intended to be confidential to the recipient. If you receive a > copy in error, please inform the sender and then delete this message. > > Virgin Money plc - Registered in England and Wales (Company no. 6952311). > Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. > Virgin Money plc is authorised by the Prudential Regulation Authority and > regulated by the Financial Conduct Authority and the Prudential Regulation > Authority. > > The following companies also trade as Virgin Money. They are both > authorised and regulated by the Financial Conduct Authority, are registered > in England and Wales and have their registered office at Jubilee House, > Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial > Service Limited (Company no. 3072766) and Virgin Money Unit Trust > Managers Limited (Company no. 3000482). > > For further details of Virgin Money group companies please visit our website > at virginmoney.com From mexigabacho at gmail.com Thu Feb 5 17:17:22 2015 From: mexigabacho at gmail.com (Christopher Young) Date: Thu, 5 Feb 2015 12:17:22 -0500 Subject: [Freeipa-users] User certificates with FreeIPA and another question. Message-ID: Some of this might be rudimentary, so I apologize if this is answered somewhere, though I've tried to search and have not had much luck... Basically, I would like to be able to issue user certificates (Subject: email=sblblabla at blabla.local) in order to use client SSL security on some things. I'm very new to FreeIPA, but have worked with external CAs in the past for similar requests, however this is my first entry into creating/running a localized CA within an organization. I was wondering if this is possible via the command line, and if so, how to go about submitting the request and receiving the certificate. Any guidance or assistance would be greatly appreciated! Additionally, just as a matter of cleanliness, is there any way possible to just completely wipe out the existence of a certificate/request from FreeIPA. I have done some trial-and-error and obviously have made mistakes that I'd prefer to clean up after. I've revoked those certs, however the perfectionist in me hates seeing them there. I'm quite certain the answer is 'no', but I thought I would ask anyway. Thanks for any assistance, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmj at ast.cam.ac.uk Thu Feb 5 18:52:18 2015 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Thu, 05 Feb 2015 18:52:18 +0000 Subject: [Freeipa-users] netgroups not working for exports in freeipa - SOLVED In-Reply-To: <54CAA96C.1080001@ast.cam.ac.uk> References: <54C80B39.1000406@ast.cam.ac.uk> <20150128105755.GQ11150@hendrix.brq.redhat.com> <54C8EAC8.8030800@ast.cam.ac.uk> <20150129173243.GC20632@hendrix.lan> <54CAA96C.1080001@ast.cam.ac.uk> Message-ID: <54D3BBE2.1050508@ast.cam.ac.uk> On 29/01/15 21:43, Roderick Johnstone wrote: > On 29/01/2015 17:32, Jakub Hrozek wrote: >> On Wed, Jan 28, 2015 at 01:57:28PM +0000, Roderick Johnstone wrote: >>> On 28/01/15 10:57, Jakub Hrozek wrote: >>>> On Tue, Jan 27, 2015 at 10:03:37PM +0000, Roderick Johnstone wrote: >>>>> Hi >>>>> >>>>> I'm migrating from a legacy NIS setup to ipa. I have a number of NIS >>>>> netgroups (of hosts) that are being used to export (non-kerberos) >>>>> nfs shares >>>>> to which I would like to migrate to ipa. >>>>> >>>>> I've create a new netgroup in ipa (for testing) and added some >>>>> hosts to it >>>>> (using ipa netgroup-add and ipa netgroup-add-member). I'm hoping >>>>> that when >>>>> exporting an nfs share using the @netgroup syntax in /etc/exports >>>>> that the >>>>> netgroup will be looked up in ipa and the share will be exported to >>>>> the >>>>> hosts in the netgroup. >>>>> >>>>> /etc/nsswitch.conf has a line: >>>>> netgroup: files nis sss >>>>> >>>>> /etc/exports has a line: >>>>> /var/tmp/testexport @rmjnetgroup1(ro) >>>>> >>>>> I haven't, so far, been able to mount the exported share on a >>>>> client so I'm >>>>> wondering if this setup would be expected to work? >>>>> >>>>> What is confusing to me is that the section in the Redhat 6 Identity >>>>> Management guide on netgroups also has information on running the NIS >>>>> listener plugin so I'm wondering if perhaps this only works when >>>>> running the >>>>> nis listener. I'm trying to avoid that. >>>>> >>>>> I'd welcome any clarification on how to do non-kerberised nfs >>>>> exports to >>>>> groups of hosts. >>>> >>>> Does getent netgroup rmjnetgroup1 show the hosts you'd expect? >>>> >>> >>> Indeed it does. >>> >>> The individual triples listed for the netgroup contain entries like: >>> (host,-,domain) >>> where host is a fully qualified hostname which is dns resolvable. >>> >>> (For info if I do ypcat on one of my NIS netgroups I get a triple >>> like this: >>> (host,,) >>> where host is the fully qualified host name, and nothing in the domain >>> field. >>> >>> I've actually tried two netgroups with different domains set. The >>> first one >>> (rmjnetgroup) I made without specifying the --nisdomain option to ipa >>> netgroup-add and domain in the output above shows as my dns domain >>> (which is >>> a lower case version of my kerberos realm). >>> >>> I couldn't mount nfs shares when exporting to @rmjnetgroup. I checked >>> that I >>> could mount the shares when I exported explicitly to the fully qualified >>> host name, and that worked ok. >>> >>> So, thinking that the problem was with the domain name I made a new >>> netgroup >>> (rmjnetgroup1) with the option --nisdomain=xxx where xxx is the >>> proper name >>> for our nis domain as shown with the domainname command. >>> >>> I couldn't mount nfs shares when exporting to @rmjnetgroup1 either. >>> >>> Roderick >> >> Thank you for your reply, then we know the SSSD's netgroup handling is >> correct. To be honest, we're getting a bit out of my comfort zone into >> the NFS area. >> >> Maybe Roland (CC) knows how to debug the issue further? >> > > Thanks for your interest Jakub. > Just to round this thread out I did get the exporting to netgroups defined in ipa working. My problems were, I think, related to reverse name lookups resolving to short hostnames coming from /etc/hosts rather than FQDN names that were being used in /etc/exports (as well as some other things). Interestingly, the setting of the nis domain name by the domainname command on the nfs server doesn't seem to have to match the nisdomain setting for the netgroup for the export to work. In further testing using a netgroup in /etc/hosts.allow to control ssh access like this: sshd : @rmjnetgroup : ALLOW ALL : ALL : DENY it seems that the nis domain name set with the domainname command must match the nis domain set in the netgroup in IdM or else access is not allowed. Hoping this might be of use to someone else one day. Roderick From Steven.Auerbach at flbog.edu Thu Feb 5 19:30:05 2015 From: Steven.Auerbach at flbog.edu (Auerbach, Steven) Date: Thu, 5 Feb 2015 19:30:05 +0000 Subject: [Freeipa-users] Replication not happening for user password changes even after increasing the nsslapd-sasl-max-buffers to 2M Message-ID: A user contacted me today for a password reset. I made the reset on the ipa-primary. The user opened a terminal session on an SSH Client to a server in the realm and logged in. They received the required immediate password change requirement and did so. They can log off and log back on that same server with their new password. They attempted to open a terminal shell to another server in the realm. Their new password is not accepted. Both servers the user is attempting to connect to have the nameserver resolution in the same order (resolv.conf). On the ipa-primary their password expiration is 90 days from today. On the ipa-replicant the password expiration is about 60 days out (I did this with them Jan 13th also but they lost their password.....). It has been an hour since the user logged on to the server and made their required change. 2 questions arise: How to safely update replicant with the password change without changing the primary/replicant replationship order? How to force the other server to refer to the ipa-primary to validate the password? Thanks Steven Auerbach Systems Administrator State University System of Florida Board of Governors 325 West Gaines Street Tallahassee, Florida 32399 (850) 245-9592 | Fax (850) 245-0419 steven.auerbach at flbog.edu | www.flbog.edu [BOG-wordmark-wideFOR EMAIL-color] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 4047 bytes Desc: image003.jpg URL: From yamakasi.014 at gmail.com Thu Feb 5 19:48:08 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 5 Feb 2015 20:48:08 +0100 Subject: [Freeipa-users] Remove password exiration after useradd In-Reply-To: References: <54D36044.4020601@redhat.com> <54D36F7A.2040704@redhat.com> <54D37820.1070507@redhat.com> Message-ID: OK this works out good, I can login without changing my password directly. But my expire is still on a day which should be set higer. min is on 0 everywhere, max is 90 days. How to accomplish that ? 2015-02-05 17:13 GMT+01:00 Matt . : > Yes, when receiving your email I found that indeed. My ldapEditor > doesn't allow me to add that value, so this need to be done using the > commandline ? > > > > 2015-02-05 15:03 GMT+01:00 Rob Crittenden : >> Matt . wrote: >>> HI, >>> >>> I'm already doing so without any luck. If you remember something, >>> would be nice to know! >>> >>> So it should be possible to do still ? >> >> If the DN of the entry adding the password is in passSyncManagersDNs in >> the entry dn: cn=ipa_pwd_extop,cn=plugins,cn=config then the password >> will not be marked as expired (password policy is not applied at all IIRC). >> >> rob >> >>> >>> 2015-02-05 14:26 GMT+01:00 Dmitri Pal : >>>> On 02/05/2015 07:59 AM, Matt . wrote: >>>>> >>>>> Hi, >>>>> >>>>> OK, but as far as I understand we made some change, using a >>>>> commandline command which I cannot remember or find, which goes around >>>>> the password policy, or the attribute you talk about, when you add a >>>>> user. >>>>> >>>>> Can I change that globally? As we did it seems... but we were testing >>>>> so much back those days that it seems to be lost or so. >>>> >>>> >>>> I do not remember the detils from top of my head. You can probably try to >>>> search the mail archives. >>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>>> 2015-02-05 13:21 GMT+01:00 Dmitri Pal : >>>>>> >>>>>> On 02/05/2015 05:54 AM, Matt . wrote: >>>>>>> >>>>>>> In the past we have done some testsetups with password expiring after >>>>>>> we added a user, at the moment I have difficulties with this on 4.1.2 >>>>>>> >>>>>>> What I need is the following: >>>>>>> >>>>>>> - We add a user using json/kinit >>>>>>> - The user is added in the right way >>>>>>> - tThe user should be able to use his set password by the admin (at >>>>>>> least >>>>>>> ldap) >>>>>>> >>>>>>> At the moment the password is expired directly and I tried adding the >>>>>>> user with min/max lifetime to 0/0 which didn't work out. Als 0/500 >>>>>>> doesn't seem to fix my issue. >>>>>>> >>>>>>> I thought we had to do a little but more to accomplish this, but I'm >>>>>>> not able to find this (anymore) >>>>>>> >>>>>>> Does someone have a clue how to fix this ? I'm quite sure this is >>>>>>> possible. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Matt >>>>>>> >>>>>> It was always the feature of IPA to require password change on the first >>>>>> login after it was created. >>>>>> If you do not want it to be expired you need to change the expiration >>>>>> attribute of the account not min max life. >>>>>> >>>>>> -- >>>>>> Thank you, >>>>>> Dmitri Pal >>>>>> >>>>>> Sr. Engineering Manager IdM portfolio >>>>>> Red Hat, Inc. >>>>>> >>>>>> -- >>>>>> Manage your subscription for the Freeipa-users mailing list: >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> Go To http://freeipa.org for more info on the project >>>> >>>> >>>> >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager IdM portfolio >>>> Red Hat, Inc. >>>> >>> >> From mexigabacho at gmail.com Thu Feb 5 20:12:17 2015 From: mexigabacho at gmail.com (Christopher Young) Date: Thu, 5 Feb 2015 15:12:17 -0500 Subject: [Freeipa-users] User certificates with FreeIPA and management Message-ID: Some of this might be rudimentary, so I apologize if this is answered somewhere, though I've tried to search and have not had much luck... Basically, I would like to be able to issue user certificates (Subject: email=sblblabla at blabla.local) in order to use client SSL security on some things. I'm very new to FreeIPA, but have worked with external CAs in the past for similar requests, however this is my first entry into creating/running a localized CA within an organization. I was wondering if this is possible via the command line, and if so, how to go about submitting the request and receiving the certificate. Any guidance or assistance would be greatly appreciated! Additionally, just as a matter of cleanliness, is there any way possible to just completely wipe out the existence of a certificate/request from FreeIPA. I have done some trial-and-error and obviously have made mistakes that I'd prefer to clean up after. I've revoked those certs, however the perfectionist in me hates seeing them there. I'm quite certain the answer is 'no', but I thought I would ask anyway. Thanks for any assistance, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Feb 5 21:04:32 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Feb 2015 16:04:32 -0500 Subject: [Freeipa-users] Remove password exiration after useradd In-Reply-To: References: <54D36044.4020601@redhat.com> <54D36F7A.2040704@redhat.com> <54D37820.1070507@redhat.com> Message-ID: <54D3DAE0.7060303@redhat.com> Matt . wrote: > OK this works out good, I can login without changing my password directly. > > But my expire is still on a day which should be set higer. > > min is on 0 everywhere, max is 90 days. > > How to accomplish that ? I can't think of a way without modifying code. Changing the password model has consequences. rob > > > > 2015-02-05 17:13 GMT+01:00 Matt . : >> Yes, when receiving your email I found that indeed. My ldapEditor >> doesn't allow me to add that value, so this need to be done using the >> commandline ? >> >> >> >> 2015-02-05 15:03 GMT+01:00 Rob Crittenden : >>> Matt . wrote: >>>> HI, >>>> >>>> I'm already doing so without any luck. If you remember something, >>>> would be nice to know! >>>> >>>> So it should be possible to do still ? >>> >>> If the DN of the entry adding the password is in passSyncManagersDNs in >>> the entry dn: cn=ipa_pwd_extop,cn=plugins,cn=config then the password >>> will not be marked as expired (password policy is not applied at all IIRC). >>> >>> rob >>> >>>> >>>> 2015-02-05 14:26 GMT+01:00 Dmitri Pal : >>>>> On 02/05/2015 07:59 AM, Matt . wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> OK, but as far as I understand we made some change, using a >>>>>> commandline command which I cannot remember or find, which goes around >>>>>> the password policy, or the attribute you talk about, when you add a >>>>>> user. >>>>>> >>>>>> Can I change that globally? As we did it seems... but we were testing >>>>>> so much back those days that it seems to be lost or so. >>>>> >>>>> >>>>> I do not remember the detils from top of my head. You can probably try to >>>>> search the mail archives. >>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Matt >>>>>> >>>>>> 2015-02-05 13:21 GMT+01:00 Dmitri Pal : >>>>>>> >>>>>>> On 02/05/2015 05:54 AM, Matt . wrote: >>>>>>>> >>>>>>>> In the past we have done some testsetups with password expiring after >>>>>>>> we added a user, at the moment I have difficulties with this on 4.1.2 >>>>>>>> >>>>>>>> What I need is the following: >>>>>>>> >>>>>>>> - We add a user using json/kinit >>>>>>>> - The user is added in the right way >>>>>>>> - tThe user should be able to use his set password by the admin (at >>>>>>>> least >>>>>>>> ldap) >>>>>>>> >>>>>>>> At the moment the password is expired directly and I tried adding the >>>>>>>> user with min/max lifetime to 0/0 which didn't work out. Als 0/500 >>>>>>>> doesn't seem to fix my issue. >>>>>>>> >>>>>>>> I thought we had to do a little but more to accomplish this, but I'm >>>>>>>> not able to find this (anymore) >>>>>>>> >>>>>>>> Does someone have a clue how to fix this ? I'm quite sure this is >>>>>>>> possible. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Matt >>>>>>>> >>>>>>> It was always the feature of IPA to require password change on the first >>>>>>> login after it was created. >>>>>>> If you do not want it to be expired you need to change the expiration >>>>>>> attribute of the account not min max life. >>>>>>> >>>>>>> -- >>>>>>> Thank you, >>>>>>> Dmitri Pal >>>>>>> >>>>>>> Sr. Engineering Manager IdM portfolio >>>>>>> Red Hat, Inc. >>>>>>> >>>>>>> -- >>>>>>> Manage your subscription for the Freeipa-users mailing list: >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>> Go To http://freeipa.org for more info on the project >>>>> >>>>> >>>>> >>>>> -- >>>>> Thank you, >>>>> Dmitri Pal >>>>> >>>>> Sr. Engineering Manager IdM portfolio >>>>> Red Hat, Inc. >>>>> >>>> >>> From rcritten at redhat.com Thu Feb 5 21:09:17 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Feb 2015 16:09:17 -0500 Subject: [Freeipa-users] User certificates with FreeIPA and another question. In-Reply-To: References: Message-ID: <54D3DBFD.5000703@redhat.com> Christopher Young wrote: > Some of this might be rudimentary, so I apologize if this is answered > somewhere, though I've tried to search and have not had much luck... > > Basically, I would like to be able to issue user certificates (Subject: > email=sblblabla at blabla.local) in order to use client SSL security on > some things. I'm very new to FreeIPA, but have worked with external CAs > in the past for similar requests, however this is my first entry into > creating/running a localized CA within an organization. IPA doesn't issue user certificates yet, only server certificates. > I was wondering if this is possible via the command line, and if so, how > to go about submitting the request and receiving the certificate. Any > guidance or assistance would be greatly appreciated! > > > Additionally, just as a matter of cleanliness, is there any way possible > to just completely wipe out the existence of a certificate/request from > FreeIPA. I have done some trial-and-error and obviously have made > mistakes that I'd prefer to clean up after. I've revoked those certs, > however the perfectionist in me hates seeing them there. I'm quite > certain the answer is 'no', but I thought I would ask anyway. Right, the answer is no. In fact it is a good thing that all certificates are accounted for. rob From rcritten at redhat.com Thu Feb 5 21:10:20 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Feb 2015 16:10:20 -0500 Subject: [Freeipa-users] Replication not happening for user password changes even after increasing the nsslapd-sasl-max-buffers to 2M In-Reply-To: References: Message-ID: <54D3DC3C.6070709@redhat.com> Auerbach, Steven wrote: > A user contacted me today for a password reset. I made the reset on the > ipa-primary. The user opened a terminal session on an SSH Client to a > server in the realm and logged in. They received the required immediate > password change requirement and did so. They can log off and log back on > that same server with their new password. They attempted to open a > terminal shell to another server in the realm. Their new password is not > accepted. > > > > Both servers the user is attempting to connect to have the nameserver > resolution in the same order (resolv.conf). > > > > On the ipa-primary their password expiration is 90 days from today. On > the ipa-replicant the password expiration is about 60 days out (I did > this with them Jan 13^th also but they lost their password ..). It has > been an hour since the user logged on to the server and made their > required change. > > > > 2 questions arise: > > How to safely update replicant with the password change without changing > the primary/replicant replationship order? > > How to force the other server to refer to the ipa-primary to validate > the password? It sounds like replication isn't working. On each master do this: $ ipa-replica-manage list -v `hostname` That will give you the replication status on both sides. rob From yamakasi.014 at gmail.com Thu Feb 5 21:47:43 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 5 Feb 2015 22:47:43 +0100 Subject: [Freeipa-users] Remove password exiration after useradd In-Reply-To: <54D3DAE0.7060303@redhat.com> References: <54D36044.4020601@redhat.com> <54D36F7A.2040704@redhat.com> <54D37820.1070507@redhat.com> <54D3DAE0.7060303@redhat.com> Message-ID: I'm quite sure you can without changing code, I need to find out where it's set again... it's doable. 2015-02-05 22:04 GMT+01:00 Rob Crittenden : > Matt . wrote: >> OK this works out good, I can login without changing my password directly. >> >> But my expire is still on a day which should be set higer. >> >> min is on 0 everywhere, max is 90 days. >> >> How to accomplish that ? > > I can't think of a way without modifying code. > > Changing the password model has consequences. > > rob > >> >> >> >> 2015-02-05 17:13 GMT+01:00 Matt . : >>> Yes, when receiving your email I found that indeed. My ldapEditor >>> doesn't allow me to add that value, so this need to be done using the >>> commandline ? >>> >>> >>> >>> 2015-02-05 15:03 GMT+01:00 Rob Crittenden : >>>> Matt . wrote: >>>>> HI, >>>>> >>>>> I'm already doing so without any luck. If you remember something, >>>>> would be nice to know! >>>>> >>>>> So it should be possible to do still ? >>>> >>>> If the DN of the entry adding the password is in passSyncManagersDNs in >>>> the entry dn: cn=ipa_pwd_extop,cn=plugins,cn=config then the password >>>> will not be marked as expired (password policy is not applied at all IIRC). >>>> >>>> rob >>>> >>>>> >>>>> 2015-02-05 14:26 GMT+01:00 Dmitri Pal : >>>>>> On 02/05/2015 07:59 AM, Matt . wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> OK, but as far as I understand we made some change, using a >>>>>>> commandline command which I cannot remember or find, which goes around >>>>>>> the password policy, or the attribute you talk about, when you add a >>>>>>> user. >>>>>>> >>>>>>> Can I change that globally? As we did it seems... but we were testing >>>>>>> so much back those days that it seems to be lost or so. >>>>>> >>>>>> >>>>>> I do not remember the detils from top of my head. You can probably try to >>>>>> search the mail archives. >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> 2015-02-05 13:21 GMT+01:00 Dmitri Pal : >>>>>>>> >>>>>>>> On 02/05/2015 05:54 AM, Matt . wrote: >>>>>>>>> >>>>>>>>> In the past we have done some testsetups with password expiring after >>>>>>>>> we added a user, at the moment I have difficulties with this on 4.1.2 >>>>>>>>> >>>>>>>>> What I need is the following: >>>>>>>>> >>>>>>>>> - We add a user using json/kinit >>>>>>>>> - The user is added in the right way >>>>>>>>> - tThe user should be able to use his set password by the admin (at >>>>>>>>> least >>>>>>>>> ldap) >>>>>>>>> >>>>>>>>> At the moment the password is expired directly and I tried adding the >>>>>>>>> user with min/max lifetime to 0/0 which didn't work out. Als 0/500 >>>>>>>>> doesn't seem to fix my issue. >>>>>>>>> >>>>>>>>> I thought we had to do a little but more to accomplish this, but I'm >>>>>>>>> not able to find this (anymore) >>>>>>>>> >>>>>>>>> Does someone have a clue how to fix this ? I'm quite sure this is >>>>>>>>> possible. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Matt >>>>>>>>> >>>>>>>> It was always the feature of IPA to require password change on the first >>>>>>>> login after it was created. >>>>>>>> If you do not want it to be expired you need to change the expiration >>>>>>>> attribute of the account not min max life. >>>>>>>> >>>>>>>> -- >>>>>>>> Thank you, >>>>>>>> Dmitri Pal >>>>>>>> >>>>>>>> Sr. Engineering Manager IdM portfolio >>>>>>>> Red Hat, Inc. >>>>>>>> >>>>>>>> -- >>>>>>>> Manage your subscription for the Freeipa-users mailing list: >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>> Go To http://freeipa.org for more info on the project >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thank you, >>>>>> Dmitri Pal >>>>>> >>>>>> Sr. Engineering Manager IdM portfolio >>>>>> Red Hat, Inc. >>>>>> >>>>> >>>> > From rcritten at redhat.com Thu Feb 5 21:55:26 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Feb 2015 16:55:26 -0500 Subject: [Freeipa-users] netgroups not working for exports in freeipa - SOLVED In-Reply-To: <54D3BBE2.1050508@ast.cam.ac.uk> References: <54C80B39.1000406@ast.cam.ac.uk> <20150128105755.GQ11150@hendrix.brq.redhat.com> <54C8EAC8.8030800@ast.cam.ac.uk> <20150129173243.GC20632@hendrix.lan> <54CAA96C.1080001@ast.cam.ac.uk> <54D3BBE2.1050508@ast.cam.ac.uk> Message-ID: <54D3E6CE.400@redhat.com> Roderick Johnstone wrote: > On 29/01/15 21:43, Roderick Johnstone wrote: >> On 29/01/2015 17:32, Jakub Hrozek wrote: >>> On Wed, Jan 28, 2015 at 01:57:28PM +0000, Roderick Johnstone wrote: >>>> On 28/01/15 10:57, Jakub Hrozek wrote: >>>>> On Tue, Jan 27, 2015 at 10:03:37PM +0000, Roderick Johnstone wrote: >>>>>> Hi >>>>>> >>>>>> I'm migrating from a legacy NIS setup to ipa. I have a number of NIS >>>>>> netgroups (of hosts) that are being used to export (non-kerberos) >>>>>> nfs shares >>>>>> to which I would like to migrate to ipa. >>>>>> >>>>>> I've create a new netgroup in ipa (for testing) and added some >>>>>> hosts to it >>>>>> (using ipa netgroup-add and ipa netgroup-add-member). I'm hoping >>>>>> that when >>>>>> exporting an nfs share using the @netgroup syntax in /etc/exports >>>>>> that the >>>>>> netgroup will be looked up in ipa and the share will be exported to >>>>>> the >>>>>> hosts in the netgroup. >>>>>> >>>>>> /etc/nsswitch.conf has a line: >>>>>> netgroup: files nis sss >>>>>> >>>>>> /etc/exports has a line: >>>>>> /var/tmp/testexport @rmjnetgroup1(ro) >>>>>> >>>>>> I haven't, so far, been able to mount the exported share on a >>>>>> client so I'm >>>>>> wondering if this setup would be expected to work? >>>>>> >>>>>> What is confusing to me is that the section in the Redhat 6 Identity >>>>>> Management guide on netgroups also has information on running the NIS >>>>>> listener plugin so I'm wondering if perhaps this only works when >>>>>> running the >>>>>> nis listener. I'm trying to avoid that. >>>>>> >>>>>> I'd welcome any clarification on how to do non-kerberised nfs >>>>>> exports to >>>>>> groups of hosts. >>>>> >>>>> Does getent netgroup rmjnetgroup1 show the hosts you'd expect? >>>>> >>>> >>>> Indeed it does. >>>> >>>> The individual triples listed for the netgroup contain entries like: >>>> (host,-,domain) >>>> where host is a fully qualified hostname which is dns resolvable. >>>> >>>> (For info if I do ypcat on one of my NIS netgroups I get a triple >>>> like this: >>>> (host,,) >>>> where host is the fully qualified host name, and nothing in the domain >>>> field. >>>> >>>> I've actually tried two netgroups with different domains set. The >>>> first one >>>> (rmjnetgroup) I made without specifying the --nisdomain option to ipa >>>> netgroup-add and domain in the output above shows as my dns domain >>>> (which is >>>> a lower case version of my kerberos realm). >>>> >>>> I couldn't mount nfs shares when exporting to @rmjnetgroup. I checked >>>> that I >>>> could mount the shares when I exported explicitly to the fully >>>> qualified >>>> host name, and that worked ok. >>>> >>>> So, thinking that the problem was with the domain name I made a new >>>> netgroup >>>> (rmjnetgroup1) with the option --nisdomain=xxx where xxx is the >>>> proper name >>>> for our nis domain as shown with the domainname command. >>>> >>>> I couldn't mount nfs shares when exporting to @rmjnetgroup1 either. >>>> >>>> Roderick >>> >>> Thank you for your reply, then we know the SSSD's netgroup handling is >>> correct. To be honest, we're getting a bit out of my comfort zone into >>> the NFS area. >>> >>> Maybe Roland (CC) knows how to debug the issue further? >>> >> >> Thanks for your interest Jakub. >> > > Just to round this thread out I did get the exporting to netgroups > defined in ipa working. My problems were, I think, related to reverse > name lookups resolving to short hostnames coming from /etc/hosts rather > than FQDN names that were being used in /etc/exports (as well as some > other things). > > Interestingly, the setting of the nis domain name by the domainname > command on the nfs server doesn't seem to have to match the nisdomain > setting for the netgroup for the export to work. > > In further testing using a netgroup in /etc/hosts.allow to control ssh > access like this: > sshd : @rmjnetgroup : ALLOW > ALL : ALL : DENY > > it seems that the nis domain name set with the domainname command must > match the nis domain set in the netgroup in IdM or else access is not > allowed. > > Hoping this might be of use to someone else one day. > > Roderick > Great news, thanks for the follow-up. Note that our preferred way of managing access to services is using HBAC. You get a centralized solution rather than having to modify each system (if they're running sssd of course). rob From guertin at middlebury.edu Thu Feb 5 22:01:00 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Thu, 5 Feb 2015 22:01:00 +0000 Subject: [Freeipa-users] Trust with Active Directory fails Message-ID: <581f5e73e3e44f3598421161683d8166@greyhound.middlebury.edu> I'm trying to set up a trust between IPA and Active Directory, and it keeps failing. The problem is the same as this one (https://www.redhat.com/archives/freeipa-users/2014-April/msg00039.html), but the solution is not. In that case, it was solved by enabling IPv6 in the kernel, and in this case IPv6 is already enabled. Here's what happens: # ipa trust-add --type=ad example.com ipa: ERROR: Cannot find specified domain or server name It looks like a DNS problem, and all the suggestions I've seen point to DNS, but from everything I can see, DNS appears to be working. I have the IPA domain set up as a subdomain (csns.example.com) of the AD domain (example.com). Our AD domain controllers are NOT set up as DNS servers -- we have external, independent DNS servers for that. (Could that be part of the problem?) I am running bind on the IPA server (which is running RHEL6), because all the documentation was written that way. It is set up as a delegation subdomain of our main domain. >From the IPA server, dig finds the AD domain controllers: # dig SRV _ldap._tcp.example.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.1 <<>> SRV _ldap._tcp.example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8858 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;_ldap._tcp.example.com. IN SRV ;; ANSWER SECTION: _ldap._tcp.example.com. 600 IN SRV 0 100 389 dc1.example.com. _ldap._tcp.example.com. 600 IN SRV 0 100 389 dc2.example.com. _ldap._tcp.example.com. 600 IN SRV 0 100 389 dc3.example.com. _ldap._tcp.example.com. 600 IN SRV 0 100 389 dc4.example.com. _ldap._tcp.example.com. 600 IN SRV 0 100 389 dc5.example.com. _ldap._tcp.example.com. 600 IN SRV 0 100 389 dc6.example.com. ;; AUTHORITY SECTION: . 407417 IN NS b.root-servers.net. . 407417 IN NS a.root-servers.net. . 407417 IN NS h.root-servers.net. . 407417 IN NS f.root-servers.net. . 407417 IN NS m.root-servers.net. . 407417 IN NS k.root-servers.net. . 407417 IN NS l.root-servers.net. . 407417 IN NS g.root-servers.net. . 407417 IN NS e.root-servers.net. . 407417 IN NS j.root-servers.net. . 407417 IN NS i.root-servers.net. . 407417 IN NS d.root-servers.net. . 407417 IN NS c.root-servers.net. ;; Query time: 2 msec ;; SERVER: 140.233.1.7#53(140.233.1.7) ;; WHEN: Thu Feb 5 16:38:22 2015 ;; MSG SIZE rcvd: 503 And, with nslookup, I can do name lookups on the domain controllers and the DNS servers, and they all find the appropriate IP address. It all works the other way, too. From the domain controllers I can do nslookup on the IPA server. In fact, every nslookup or ping command I do on any hostname from anyway all works -- it's only the ipa trust-add command that's failing. I've set log level to 100 in /usr/share/ipa/smb.conf.empty, and here's the output in /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:civet.csns.example.com[,] tevent: Added timed event "dcerpc_connect_timeout_handler": 0x7f22f41eeb60 tevent: Added timed event "composite_trigger": 0x7f22f403d270 tevent: Added timed event "composite_trigger": 0x7f22f41efdc0 tevent: Running timer event 0x7f22f403d270 "composite_trigger" tevent: Destroying timer event 0x7f22f41efdc0 "composite_trigger" Mapped to DCERPC endpoint \pipe\lsarpc added interface eth0 ip=140.233.1.7 bcast=140.233.1.255 netmask=255.255.255.0 added interface eth0 ip=140.233.1.7 bcast=140.233.1.255 netmask=255.255.255.0 tevent: Ending timer event 0x7f22f403d270 "composite_trigger" tevent: Added timed event "connect_multi_timer": 0x7f22f4136d60 tevent: Schedule immediate event "tevent_req_trigger": 0x7f22f4137690 tevent: Run immediate event "tevent_req_trigger": 0x7f22f4137690 tevent: Destroying timer event 0x7f22f4136d60 "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 = 660150 SO_RCVBUF = 174758 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": 0x7f22f403f580 tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f22f425aee0 tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f22f425aee0 tevent: Destroying timer event 0x7f22f403f580 "tevent_req_timedout" Starting GENSEC mechanism spnego Starting GENSEC submechanism gssapi_krb5 Ticket in credentials cache for admin at CSNS.EXAMPLE.COM will expire in 86371 secs tevent: Added timed event "tevent_req_timedout": 0x7f22f42c2dd0 tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f22f425aee0 tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f22f425aee0 tevent: Destroying timer event 0x7f22f42c2dd0 "tevent_req_timedout" gensec_gssapi: NO credentials were delegated GSSAPI Connection will be cryptographically sealed tevent: Added timed event "tevent_req_timedout": 0x7f22f4041110 tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f22f425aee0 tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f22f425aee0 tevent: Destroying timer event 0x7f22f4041110 "tevent_req_timedout" tevent: Added timed event "tevent_req_timedout": 0x7f22f431dbd0 tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f22f425aee0 tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f22f425aee0 tevent: Destroying timer event 0x7f22f431dbd0 "tevent_req_timedout" tevent: Destroying timer event 0x7f22f41eeb60 "dcerpc_connect_timeout_handler" [Thu Feb 05 16:50:18 2015] [error] ipa: INFO: admin at CSNS.EXAMPLE.COM: trust_add(u'example.com', trust_type=u'ad', range_size=200000, all=False, raw=False, version=u'2.49'): NotFound What am I missing? Thanks, David Guertin Information Technology Services Middlebury College Middlebury, VT 05753 USA -------------- next part -------------- An HTML attachment was scrubbed... URL: From mexigabacho at gmail.com Thu Feb 5 23:53:14 2015 From: mexigabacho at gmail.com (Christopher Young) Date: Thu, 5 Feb 2015 18:53:14 -0500 Subject: [Freeipa-users] User certificates with FreeIPA and another question. In-Reply-To: <54D3DBFD.5000703@redhat.com> References: <54D3DBFD.5000703@redhat.com> Message-ID: Obvious next question: Any plans to implement that functionality or advice on how one might get some level of functionality for this? Would it be possible to create another command-line based openssl CA that could issue these but using IPA as the root CA for those? I'm just trying to provide a solution for situations where we would like to utilize client/user cert authentication for situations like secure apache directory access as well as user VPN certificates. Any advise or ideas are great appreciated. Thanks again! On Thu, Feb 5, 2015 at 4:09 PM, Rob Crittenden wrote: > Christopher Young wrote: > > Some of this might be rudimentary, so I apologize if this is answered > > somewhere, though I've tried to search and have not had much luck... > > > > Basically, I would like to be able to issue user certificates (Subject: > > email=sblblabla at blabla.local) in order to use client SSL security on > > some things. I'm very new to FreeIPA, but have worked with external CAs > > in the past for similar requests, however this is my first entry into > > creating/running a localized CA within an organization. > > IPA doesn't issue user certificates yet, only server certificates. > > > I was wondering if this is possible via the command line, and if so, how > > to go about submitting the request and receiving the certificate. Any > > guidance or assistance would be greatly appreciated! > > > > > > Additionally, just as a matter of cleanliness, is there any way possible > > to just completely wipe out the existence of a certificate/request from > > FreeIPA. I have done some trial-and-error and obviously have made > > mistakes that I'd prefer to clean up after. I've revoked those certs, > > however the perfectionist in me hates seeing them there. I'm quite > > certain the answer is 'no', but I thought I would ask anyway. > > Right, the answer is no. In fact it is a good thing that all > certificates are accounted for. > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Fri Feb 6 05:59:22 2015 From: Less at imagine-sw.com (Les Stott) Date: Fri, 6 Feb 2015 05:59:22 +0000 Subject: [Freeipa-users] bug in pki during install of CA replica and workaround/solution Message-ID: <4ED173A868981548967B4FCA27072226280AEAB2@AACMBXP04.exchserver.com> Hi, I found a bug in the pki packages and CA replica installation. Environment: Rhel 6.6 IPA Server 3.0.0-42 Pki components: pki-symkey-9.0.3-38.el6_6.x86_64 pki-common-9.0.3-38.el6_6.noarch pki-setup-9.0.3-38.el6_6.noarch pki-selinux-9.0.3-38.el6_6.noarch pki-java-tools-9.0.3-38.el6_6.noarch pki-ca-9.0.3-38.el6_6.noarch ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-pki-ca-theme-9.0.3-7.el6.noarch pki-native-tools-9.0.3-38.el6_6.x86_64 pki-util-9.0.3-38.el6_6.noarch pki-silent-9.0.3-38.el6_6.noarch Selinux: Permissive when running a CA replica installation it fails because pki-cad cannot start due to selinux context issues. Samples from the ipareplica-ca-install.log... ========= 2015-02-05T08:20:04Z DEBUG stderr=[error] FAILED run_comman[ OK ]/service pki-cad restart pki-ca"), exit status=1 output="Stopping pki-ca: /usr/bin/runcon: invalid context: unconfined_u:system_r:pki_ca_script_t:s0: Invalid argument" 2015-02-05T08:20:04Z DEBUG duration: 6 seconds 2015-02-05T08:20:04Z DEBUG [3/16]: configuring certificate server instance ############################################# Attempting to connect to: sb1sys02.mydomain.com:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ####################################################################### 2015-02-05T08:20:04Z DEBUG stderr=Exception: Unable to Send Request:java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused ========== In short pki-cad fails to start and stops the installer. Reinstalling the pki-selinux rpm (found references in some other forum posts) via yum reinstall pki-selinux is not enough to help. The solution is as follows: yum downgrade pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools which takes components back to 9.0.3-32 then yum -y update pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools then (after cleaning up half installed pki components) ipa-ca-install /var/lib/ipa/replica-info-sb1sys02.mydomain.gpg Then, the CA replication completes successfully. Regards, Les -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Fri Feb 6 06:09:40 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 6 Feb 2015 07:09:40 +0100 Subject: [Freeipa-users] User certificates with FreeIPA and management In-Reply-To: References: Message-ID: <20150206060940.GK7799@dhcp-40-8.bne.redhat.com> On Thu, Feb 05, 2015 at 03:12:17PM -0500, Christopher Young wrote: > Some of this might be rudimentary, so I apologize if this is answered > somewhere, though I've tried to search and have not had much luck... > > Basically, I would like to be able to issue user certificates (Subject: > email=sblblabla at blabla.local) in order to use client SSL security on some > things. I'm very new to FreeIPA, but have worked with external CAs in the > past for similar requests, however this is my first entry into > creating/running a localized CA within an organization. > > I was wondering if this is possible via the command line, and if so, how to > go about submitting the request and receiving the certificate. Any > guidance or assistance would be greatly appreciated! > Hi Christopher, I am working on features of Dogtag necessary for this and it will be integrated in a future release of FreeIPA. For now, you could use the Dogtag CA directly to issue user certificates. > > Additionally, just as a matter of cleanliness, is there any way possible to > just completely wipe out the existence of a certificate/request from > FreeIPA. I have done some trial-and-error and obviously have made mistakes > that I'd prefer to clean up after. I've revoked those certs, however the > perfectionist in me hates seeing them there. I'm quite certain the answer > is 'no', but I thought I would ask anyway. > The answer is "no". Dogtag remembers all the certificates it issues. Regards, Fraser > Thanks for any assistance, > > Chris > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From abokovoy at redhat.com Fri Feb 6 08:16:37 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 6 Feb 2015 10:16:37 +0200 Subject: [Freeipa-users] one way AD trust relationship In-Reply-To: <1061078355.97496.1423152050650.JavaMail.root@mail> References: <543821355.97203.1423151898278.JavaMail.root@mail> <1061078355.97496.1423152050650.JavaMail.root@mail> Message-ID: <20150206081637.GF9247@redhat.com> On Thu, 05 Feb 2015, Nicolas Zin wrote: >Hi, > >is it possible to create a one way AD trust relationship with FreeIPA/IDM 3.3? No. >- From Windows I created an incoming one-way trust relationship, with a trust-secret >- on Linux I use the trust-secret with ipa: ipa trust-add --type=ad ipawindows.mtl.sfl --trust-secret > >everything seems to be fine, but when I try >kinit Administrator at ipawindows.mtl.sfl >kinit: KDC reply did not match expectations while getting initial credentials > >I tried others ways, but I wonder if it is possible to have a one-way trust relationship? One-way trust is not supported yet. I'm in the process of writing a set of design documents and opening tickets for various missing parts. We hope to get it done within the scope of FreeIPA 4.2. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Feb 6 08:27:36 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 6 Feb 2015 10:27:36 +0200 Subject: [Freeipa-users] Trust with Active Directory fails In-Reply-To: <581f5e73e3e44f3598421161683d8166@greyhound.middlebury.edu> References: <581f5e73e3e44f3598421161683d8166@greyhound.middlebury.edu> Message-ID: <20150206082735.GG9247@redhat.com> On Thu, 05 Feb 2015, Guertin, David S. wrote: >I'm trying to set up a trust between IPA and Active Directory, and it >keeps failing. The problem is the same as this one >(https://www.redhat.com/archives/freeipa-users/2014-April/msg00039.html), >but the solution is not. In that case, it was solved by enabling IPv6 >in the kernel, and in this case IPv6 is already enabled. > >Here's what happens: > ># ipa trust-add --type=ad example.com >ipa: ERROR: Cannot find specified domain or server name > >It looks like a DNS problem, and all the suggestions I've seen point to >DNS, but from everything I can see, DNS appears to be working. I have >the IPA domain set up as a subdomain (csns.example.com) of the AD >domain (example.com). Our AD domain controllers are NOT set up as DNS >servers -- we have external, independent DNS servers for that. (Could >that be part of the problem?) I am running bind on the IPA server >(which is running RHEL6), because all the documentation was written >that way. It is set up as a delegation subdomain of our main domain. We don't require DNS to be tied to any specific party (IPA or AD), all we require is that all proper service records (SRV) are in place. For Active Directory cross-forest trusts to work, we need following records to be in place: _ldap._tcp. _kerberos._udp. _kerberos._tcp. _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs. _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs. _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs. _ldap._tcp.dc._msdcs. _kerberos._udp.dc._msdcs. _kerberos._tcp.dc._msdcs. When you run ipa-adtrust-install, it will generate these records for IPA domain but when we perform trust, Samba libraries resolve these in AD domain too. Make sure they are properly configured. > >>From the IPA server, dig finds the AD domain controllers: > ># dig SRV _ldap._tcp.example.com > >; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.1 <<>> SRV _ldap._tcp.example.com >;; global options: +cmd >;; Got answer: >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8858 >;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 13, ADDITIONAL: 0 > >;; QUESTION SECTION: >;_ldap._tcp.example.com. IN SRV > >;; ANSWER SECTION: >_ldap._tcp.example.com. 600 IN SRV 0 100 389 dc1.example.com. >_ldap._tcp.example.com. 600 IN SRV 0 100 389 dc2.example.com. >_ldap._tcp.example.com. 600 IN SRV 0 100 389 dc3.example.com. >_ldap._tcp.example.com. 600 IN SRV 0 100 389 dc4.example.com. >_ldap._tcp.example.com. 600 IN SRV 0 100 389 dc5.example.com. >_ldap._tcp.example.com. 600 IN SRV 0 100 389 dc6.example.com. > >;; AUTHORITY SECTION: >. 407417 IN NS b.root-servers.net. >. 407417 IN NS a.root-servers.net. >. 407417 IN NS h.root-servers.net. >. 407417 IN NS f.root-servers.net. >. 407417 IN NS m.root-servers.net. >. 407417 IN NS k.root-servers.net. >. 407417 IN NS l.root-servers.net. >. 407417 IN NS g.root-servers.net. >. 407417 IN NS e.root-servers.net. >. 407417 IN NS j.root-servers.net. >. 407417 IN NS i.root-servers.net. >. 407417 IN NS d.root-servers.net. >. 407417 IN NS c.root-servers.net. > >;; Query time: 2 msec >;; SERVER: 140.233.1.7#53(140.233.1.7) >;; WHEN: Thu Feb 5 16:38:22 2015 >;; MSG SIZE rcvd: 503 > >And, with nslookup, I can do name lookups on the domain controllers and >the DNS servers, and they all find the appropriate IP address. It all >works the other way, too. From the domain controllers I can do nslookup >on the IPA server. In fact, every nslookup or ping command I do on any >hostname from anyway all works -- it's only the ipa trust-add command >that's failing. > >I've set log level to 100 in /usr/share/ipa/smb.conf.empty, and here's the output in /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:civet.csns.example.com[,] >tevent: Added timed event "dcerpc_connect_timeout_handler": 0x7f22f41eeb60 >tevent: Added timed event "composite_trigger": 0x7f22f403d270 >tevent: Added timed event "composite_trigger": 0x7f22f41efdc0 >tevent: Running timer event 0x7f22f403d270 "composite_trigger" >tevent: Destroying timer event 0x7f22f41efdc0 "composite_trigger" >Mapped to DCERPC endpoint \pipe\lsarpc >added interface eth0 ip=140.233.1.7 bcast=140.233.1.255 netmask=255.255.255.0 >added interface eth0 ip=140.233.1.7 bcast=140.233.1.255 netmask=255.255.255.0 >tevent: Ending timer event 0x7f22f403d270 "composite_trigger" >tevent: Added timed event "connect_multi_timer": 0x7f22f4136d60 >tevent: Schedule immediate event "tevent_req_trigger": 0x7f22f4137690 >tevent: Run immediate event "tevent_req_trigger": 0x7f22f4137690 >tevent: Destroying timer event 0x7f22f4136d60 "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 = 660150 > SO_RCVBUF = 174758 > 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": 0x7f22f403f580 >tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f22f425aee0 >tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f22f425aee0 >tevent: Destroying timer event 0x7f22f403f580 "tevent_req_timedout" >Starting GENSEC mechanism spnego >Starting GENSEC submechanism gssapi_krb5 >Ticket in credentials cache for admin at CSNS.EXAMPLE.COM will expire in 86371 secs >tevent: Added timed event "tevent_req_timedout": 0x7f22f42c2dd0 >tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f22f425aee0 >tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f22f425aee0 >tevent: Destroying timer event 0x7f22f42c2dd0 "tevent_req_timedout" >gensec_gssapi: NO credentials were delegated >GSSAPI Connection will be cryptographically sealed >tevent: Added timed event "tevent_req_timedout": 0x7f22f4041110 >tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f22f425aee0 >tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f22f425aee0 >tevent: Destroying timer event 0x7f22f4041110 "tevent_req_timedout" >tevent: Added timed event "tevent_req_timedout": 0x7f22f431dbd0 >tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f22f425aee0 >tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f22f425aee0 >tevent: Destroying timer event 0x7f22f431dbd0 "tevent_req_timedout" >tevent: Destroying timer event 0x7f22f41eeb60 "dcerpc_connect_timeout_handler" >[Thu Feb 05 16:50:18 2015] [error] ipa: INFO: admin at CSNS.EXAMPLE.COM: trust_add(u'example.com', trust_type=u'ad', range_size=200000, all=False, raw=False, version=u'2.49'): NotFound I can see that we initialized the connection to local Samba (civet.csns.example.com). The next step is to initialize connection to AD side and that one fails -- exactly because it is unable to pick up a domain controller from the mcdcs-specific SRV records. -- / Alexander Bokovoy From Duncan.Innes at virginmoney.com Fri Feb 6 11:14:59 2015 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Fri, 6 Feb 2015 11:14:59 -0000 Subject: [Freeipa-users] Real-time replication status (RFE)? In-Reply-To: References: <54D37BD1.2060508@redhat.com> <56343345B145C043AE990701E3D193950478E3E4@EXVS2.nrplc.localnet> Message-ID: <56343345B145C043AE990701E3D193950478E3E5@EXVS2.nrplc.localnet> Check: https://gist.github.com/duncaninnes/c91985822be9782df581 which contains 2 scripts based on: http://directory.fedoraproject.org/docs/389ds/howto/howto-replicationmon itoring.html I just expanded it to cope with a list of servers, then version 2 sorts by last end, last start, hostname. This version allows me to see more clearly if a certain replication is out of date. Could have done a sort by column and added a refresh button, or automatic refresh, but that wasn't the immediate aim. Since then it's just stuck, so could do with some love from any suitably minded persons. It also doesn't gracefully handle situations where one server in the list is offline, or taking too long to respond. Both scripts are put in /var/www/cgi-bin on one of my IPA servers, and accessed via: https://ipa01.example.com/cgi-bin/monitor2.pl for example. Not sure if I modified the httpd configs - it's a while ago that I sorted it out. HTH Duncan -----Original Message----- From: Baird, Josh [mailto:jbaird at follett.com] Sent: 05 February 2015 17:08 To: Innes, Duncan; Rob Crittenden; freeipa-users at redhat.com Subject: RE: [Freeipa-users] Real-time replication status (RFE)? That would be great, thanks! Josh > -----Original Message----- > From: Innes, Duncan [mailto:Duncan.Innes at virginmoney.com] > Sent: Thursday, February 05, 2015 11:34 AM > To: Rob Crittenden; Baird, Josh; freeipa-users at redhat.com > Subject: RE: [Freeipa-users] Real-time replication status (RFE)? > > The screen mockup in that ticket is based on a Perl script that I > stuck in cgi-bin to pull just those stats off each IPA server I have > and display them. Can share the code if you're interested. > > D > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rob Crittenden > Sent: 05 February 2015 14:19 > To: Baird, Josh; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Real-time replication status (RFE)? > > Baird, Josh wrote: > > Hi, > > > > I'm looking for an easy way to validate that all replication > agreements are functioning correctly between all of my IPA masters and > replicas. I am aware that I can run 'ipa-replica-manage list -v' from > each IPA master, but I was looking for something more centralized that > could give me a replication health report for all masters/replicas. > Ideally, this type of feature would be exposed in the UI and would > also include information or insight into the status of any IPA <-> AD > trust relationships. > > > > Am I missing a feature that already exists? If not, is there > something like this on the IPA roadmap? > > This is being tracked in https://fedorahosted.org/freeipa/ticket/4390 > > It depends on some other work being done first. > > rob > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > This message has been checked for viruses and spam by the Virgin Money > email scanning system powered by Messagelabs. > > This message has been checked for viruses and spam by the Virgin Money > email scanning system powered by Messagelabs. > > This e-mail is intended to be confidential to the recipient. If you > receive a copy in error, please inform the sender and then delete this message. > > Virgin Money plc - Registered in England and Wales (Company no. 6952311). > Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. > Virgin Money plc is authorised by the Prudential Regulation Authority > and regulated by the Financial Conduct Authority and the Prudential > Regulation Authority. > > The following companies also trade as Virgin Money. They are both > authorised and regulated by the Financial Conduct Authority, are > registered in England and Wales and have their registered office at > Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money > Personal Financial Service Limited (Company no. 3072766) and Virgin > Money Unit Trust Managers Limited (Company no. 3000482). > > For further details of Virgin Money group companies please visit our > website at virginmoney.com This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com From sbose at redhat.com Fri Feb 6 11:39:43 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 6 Feb 2015 12:39:43 +0100 Subject: [Freeipa-users] one way AD trust relationship In-Reply-To: <20150206081637.GF9247@redhat.com> References: <543821355.97203.1423151898278.JavaMail.root@mail> <1061078355.97496.1423152050650.JavaMail.root@mail> <20150206081637.GF9247@redhat.com> Message-ID: <20150206113943.GA3512@p.redhat.com> On Fri, Feb 06, 2015 at 10:16:37AM +0200, Alexander Bokovoy wrote: > On Thu, 05 Feb 2015, Nicolas Zin wrote: > >Hi, > > > >is it possible to create a one way AD trust relationship with FreeIPA/IDM 3.3? > No. > > >- From Windows I created an incoming one-way trust relationship, with a trust-secret > >- on Linux I use the trust-secret with ipa: ipa trust-add --type=ad ipawindows.mtl.sfl --trust-secret > > > >everything seems to be fine, but when I try > >kinit Administrator at ipawindows.mtl.sfl > >kinit: KDC reply did not match expectations while getting initial credentials Nevertheless the error you see is not related to trust in the first place. kinit on Linux clients expects a Kerberos principal as argument which in general is case sensitive. I would expect that either kinit -C Administrator at ipawindows.mtl.sfl or kinit Administrator at IPAWINDOWS.MTL.SFL will work for you. But please note that this is not an indication that the trust is working in general. For this you should try to get a Kerberos service ticket for a service from your IPA domain e.g. with kvno. bye, Sumit > > > >I tried others ways, but I wonder if it is possible to have a one-way trust relationship? > One-way trust is not supported yet. I'm in the process of writing a > set of design documents and opening tickets for various missing parts. > We hope to get it done within the scope of FreeIPA 4.2. > > -- > / Alexander Bokovoy > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From rcritten at redhat.com Fri Feb 6 14:06:04 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Feb 2015 09:06:04 -0500 Subject: [Freeipa-users] Real-time replication status (RFE)? In-Reply-To: <56343345B145C043AE990701E3D193950478E3E5@EXVS2.nrplc.localnet> References: <54D37BD1.2060508@redhat.com> <56343345B145C043AE990701E3D193950478E3E4@EXVS2.nrplc.localnet> <56343345B145C043AE990701E3D193950478E3E5@EXVS2.nrplc.localnet> Message-ID: <54D4CA4C.9020702@redhat.com> Innes, Duncan wrote: > Check: > > https://gist.github.com/duncaninnes/c91985822be9782df581 > > which contains 2 scripts based on: > > http://directory.fedoraproject.org/docs/389ds/howto/howto-replicationmon > itoring.html > > I just expanded it to cope with a list of servers, then version 2 sorts > by last end, last start, hostname. This version allows me to see more > clearly if a certain replication is out of date. Could have done a sort > by column and added a refresh button, or automatic refresh, but that > wasn't the immediate aim. Since then it's just stuck, so could do with > some love from any suitably minded persons. It also doesn't gracefully > handle situations where one server in the list is offline, or taking too > long to respond. > > Both scripts are put in /var/www/cgi-bin on one of my IPA servers, and > accessed via: > > https://ipa01.example.com/cgi-bin/monitor2.pl > > for example. Not sure if I modified the httpd configs - it's a while > ago that I sorted it out. > > HTH > > Duncan We try to avoid using Directory Manager as much as possible which is one of the reasons we haven't done something like this already. I'd definitely recommend using startTLS for your bind, at a minimum. The issue starts with the fact that we don't have a hostgroup consisting of all IPA masters maintained automatically so there is no easy way to do delegation. You could do this manually if you wanted though, something like: # ipa hostgroup-add ipamasters --desc='Manual list of IPA masters' # ipa hostgroup-add-member --hosts=ipa1.example.com ipamasters # ipa hostgroup-add-member --hosts=ipa2.example.com ipamasters Now create a role that with a privilege to be able to read replication agreements (and add and delete them too, so be aware). # ipa role-add ipamasters --desc='IPA Masters' # ipa role-add-privilege --privileges='Replication Administrators' ipamasters # ipa role-add-member --hostgroup=ipamasters ipamasters You can test this with: # kinit -kt /etc/krb5.keytab # ldapsearch -Y GSSAPI -b 'cn=mapping tree,cn=config' '(objectclass=nsDS5ReplicationAgreement)' You'd just need to the ipamasters hostgroup up-to-date, and considering that this list probably stabilizes over time, shouldn't be a ton of effort. rob > -----Original Message----- > From: Baird, Josh [mailto:jbaird at follett.com] > Sent: 05 February 2015 17:08 > To: Innes, Duncan; Rob Crittenden; freeipa-users at redhat.com > Subject: RE: [Freeipa-users] Real-time replication status (RFE)? > > That would be great, thanks! > > Josh > >> -----Original Message----- >> From: Innes, Duncan [mailto:Duncan.Innes at virginmoney.com] >> Sent: Thursday, February 05, 2015 11:34 AM >> To: Rob Crittenden; Baird, Josh; freeipa-users at redhat.com >> Subject: RE: [Freeipa-users] Real-time replication status (RFE)? >> >> The screen mockup in that ticket is based on a Perl script that I >> stuck in cgi-bin to pull just those stats off each IPA server I have >> and display them. Can share the code if you're interested. >> >> D >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rob Crittenden >> Sent: 05 February 2015 14:19 >> To: Baird, Josh; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Real-time replication status (RFE)? >> >> Baird, Josh wrote: >>> Hi, >>> >>> I'm looking for an easy way to validate that all replication >> agreements are functioning correctly between all of my IPA masters and > >> replicas. I am aware that I can run 'ipa-replica-manage list -v' from > >> each IPA master, but I was looking for something more centralized that > >> could give me a replication health report for all masters/replicas. >> Ideally, this type of feature would be exposed in the UI and would >> also include information or insight into the status of any IPA <-> AD >> trust relationships. >>> >>> Am I missing a feature that already exists? If not, is there >> something like this on the IPA roadmap? >> >> This is being tracked in https://fedorahosted.org/freeipa/ticket/4390 >> >> It depends on some other work being done first. >> >> rob >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> >> This message has been checked for viruses and spam by the Virgin Money > >> email scanning system powered by Messagelabs. >> >> This message has been checked for viruses and spam by the Virgin Money > >> email scanning system powered by Messagelabs. >> >> This e-mail is intended to be confidential to the recipient. If you >> receive a copy in error, please inform the sender and then delete this > message. >> >> Virgin Money plc - Registered in England and Wales (Company no. > 6952311). >> Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 > 4PL. >> Virgin Money plc is authorised by the Prudential Regulation Authority >> and regulated by the Financial Conduct Authority and the Prudential >> Regulation Authority. >> >> The following companies also trade as Virgin Money. They are both >> authorised and regulated by the Financial Conduct Authority, are >> registered in England and Wales and have their registered office at >> Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money >> Personal Financial Service Limited (Company no. 3072766) and Virgin >> Money Unit Trust Managers Limited (Company no. 3000482). >> >> For further details of Virgin Money group companies please visit our >> website at virginmoney.com > > This message has been checked for viruses and spam by the Virgin Money > email scanning system powered by Messagelabs. > > This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. > > This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. > > Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. > > The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). > > For further details of Virgin Money group companies please visit our website at virginmoney.com > From mkosek at redhat.com Fri Feb 6 14:30:34 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Feb 2015 15:30:34 +0100 Subject: [Freeipa-users] User certificates with FreeIPA and another question. In-Reply-To: References: <54D3DBFD.5000703@redhat.com> Message-ID: <54D4D00A.7050402@redhat.com> On 02/06/2015 12:53 AM, Christopher Young wrote: > Obvious next question: Any plans to implement that functionality or advice > on how one might get some level of functionality for this? Would it be > possible to create another command-line based openssl CA that could issue > these but using IPA as the root CA for those? As for FreeIPA plans, we plan to vastly improve our flexibility to process certificates in next upstream version - FreeIPA 4.2. In next version, one should be able to create other certificate profiles (from FreeIPA default service cert profile) or even subCAs to do what you want. As for current workarounds, you would have to issue and sign a for example NSS or openssl based subCA and then sign user certs there. But I would leave Fraser or Jan to tell if this would be really possible. > I'm just trying to provide a solution for situations where we would like to > utilize client/user cert authentication for situations like secure apache > directory access as well as user VPN certificates. Any advise or ideas are > great appreciated. > > Thanks again! > > On Thu, Feb 5, 2015 at 4:09 PM, Rob Crittenden wrote: > >> Christopher Young wrote: >>> Some of this might be rudimentary, so I apologize if this is answered >>> somewhere, though I've tried to search and have not had much luck... >>> >>> Basically, I would like to be able to issue user certificates (Subject: >>> email=sblblabla at blabla.local) in order to use client SSL security on >>> some things. I'm very new to FreeIPA, but have worked with external CAs >>> in the past for similar requests, however this is my first entry into >>> creating/running a localized CA within an organization. >> >> IPA doesn't issue user certificates yet, only server certificates. >> >>> I was wondering if this is possible via the command line, and if so, how >>> to go about submitting the request and receiving the certificate. Any >>> guidance or assistance would be greatly appreciated! >>> >>> >>> Additionally, just as a matter of cleanliness, is there any way possible >>> to just completely wipe out the existence of a certificate/request from >>> FreeIPA. I have done some trial-and-error and obviously have made >>> mistakes that I'd prefer to clean up after. I've revoked those certs, >>> however the perfectionist in me hates seeing them there. I'm quite >>> certain the answer is 'no', but I thought I would ask anyway. >> >> Right, the answer is no. In fact it is a good thing that all >> certificates are accounted for. >> >> rob >> >> > > > From mkosek at redhat.com Fri Feb 6 14:39:54 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Feb 2015 15:39:54 +0100 Subject: [Freeipa-users] bug in pki during install of CA replica and workaround/solution In-Reply-To: <4ED173A868981548967B4FCA27072226280AEAB2@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA27072226280AEAB2@AACMBXP04.exchserver.com> Message-ID: <54D4D23A.5070305@redhat.com> On 02/06/2015 06:59 AM, Les Stott wrote: > Hi, > > I found a bug in the pki packages and CA replica installation. > > Environment: > Rhel 6.6 > IPA Server 3.0.0-42 > Pki components: > pki-symkey-9.0.3-38.el6_6.x86_64 > pki-common-9.0.3-38.el6_6.noarch > pki-setup-9.0.3-38.el6_6.noarch > pki-selinux-9.0.3-38.el6_6.noarch > pki-java-tools-9.0.3-38.el6_6.noarch > pki-ca-9.0.3-38.el6_6.noarch > ipa-pki-common-theme-9.0.3-7.el6.noarch > ipa-pki-ca-theme-9.0.3-7.el6.noarch > pki-native-tools-9.0.3-38.el6_6.x86_64 > pki-util-9.0.3-38.el6_6.noarch > pki-silent-9.0.3-38.el6_6.noarch > Selinux: > Permissive > > when running a CA replica installation it fails because pki-cad cannot start due to selinux context issues. > > Samples from the ipareplica-ca-install.log... > > ========= > 2015-02-05T08:20:04Z DEBUG stderr=[error] FAILED run_comman[ OK ]/service pki-cad restart pki-ca"), exit status=1 output="Stopping pki-ca: > /usr/bin/runcon: invalid context: unconfined_u:system_r:pki_ca_script_t:s0: Invalid argument" > > 2015-02-05T08:20:04Z DEBUG duration: 6 seconds > 2015-02-05T08:20:04Z DEBUG [3/16]: configuring certificate server instance > ############################################# > Attempting to connect to: sb1sys02.mydomain.com:9445 > Exception in LoginPanel(): java.lang.NullPointerException > ERROR: ConfigureCA: LoginPanel() failure > ERROR: unable to create CA > > ####################################################################### > > 2015-02-05T08:20:04Z DEBUG stderr=Exception: Unable to Send Request:java.net.ConnectException: Connection refused > java.net.ConnectException: Connection refused > > ========== > > In short pki-cad fails to start and stops the installer. > > Reinstalling the pki-selinux rpm (found references in some other forum posts) via yum reinstall pki-selinux is not enough to help. > > The solution is as follows: > > yum downgrade pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools > which takes components back to 9.0.3-32 > then > yum -y update pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools > then (after cleaning up half installed pki components) > ipa-ca-install /var/lib/ipa/replica-info-sb1sys02.mydomain.gpg > > Then, the CA replication completes successfully. > > Regards, > > Les I saw this one around, e.g. in: http://www.redhat.com/archives/freeipa-devel/2014-May/msg00507.html Did you try reinstalling pki-selinux before ipa-server-install? Endi/Matthew, do we have a bug/fix for this? Thanks, Martin From edewata at redhat.com Fri Feb 6 14:53:06 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 06 Feb 2015 08:53:06 -0600 Subject: [Freeipa-users] bug in pki during install of CA replica and workaround/solution In-Reply-To: <54D4D23A.5070305@redhat.com> References: <4ED173A868981548967B4FCA27072226280AEAB2@AACMBXP04.exchserver.com> <54D4D23A.5070305@redhat.com> Message-ID: <54D4D552.8000805@redhat.com> On 2/6/2015 8:39 AM, Martin Kosek wrote: >> Reinstalling the pki-selinux rpm (found references in some other forum posts) via yum reinstall pki-selinux is not enough to help. >> >> The solution is as follows: >> >> yum downgrade pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools >> which takes components back to 9.0.3-32 >> then >> yum -y update pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools >> then (after cleaning up half installed pki components) >> ipa-ca-install /var/lib/ipa/replica-info-sb1sys02.mydomain.gpg >> >> Then, the CA replication completes successfully. >> >> Regards, >> >> Les > > I saw this one around, e.g. in: > > http://www.redhat.com/archives/freeipa-devel/2014-May/msg00507.html > > Did you try reinstalling pki-selinux before ipa-server-install? > > Endi/Matthew, do we have a bug/fix for this? > > Thanks, > Martin > Yes, we have a ticket for this: https://fedorahosted.org/pki/ticket/1243 The default selinux-policy is version 3.7.19-231. It needs to be updated to at least version 3.7.19-260. -- Endi S. Dewata From natxo.asenjo at gmail.com Fri Feb 6 15:38:02 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 6 Feb 2015 16:38:02 +0100 Subject: [Freeipa-users] User certificates with FreeIPA and another question. In-Reply-To: <54D4D00A.7050402@redhat.com> References: <54D3DBFD.5000703@redhat.com> <54D4D00A.7050402@redhat.com> Message-ID: On Fri, Feb 6, 2015 at 3:30 PM, Martin Kosek wrote: > On 02/06/2015 12:53 AM, Christopher Young wrote: > > Obvious next question: Any plans to implement that functionality or > advice > > on how one might get some level of functionality for this? Would it be > > possible to create another command-line based openssl CA that could issue > > these but using IPA as the root CA for those? > > As for FreeIPA plans, we plan to vastly improve our flexibility to process > certificates in next upstream version - FreeIPA 4.2. In next version, one > should be able to create other certificate profiles (from FreeIPA default > service cert profile) or even subCAs to do what you want. > > nice. When do all these things land in RHEL? > As for current workarounds, you would have to issue and sign a for example > NSS > or openssl based subCA and then sign user certs there. But I would leave > Fraser > or Jan to tell if this would be really possible. some examples on how to do that would be very helpful. I would love to authenticate users to mysql using our CA, for instance. -- regards, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Auerbach at flbog.edu Fri Feb 6 15:53:39 2015 From: Steven.Auerbach at flbog.edu (Auerbach, Steven) Date: Fri, 6 Feb 2015 15:53:39 +0000 Subject: [Freeipa-users] Replication not happening for user password changes even after increasing the nsslapd-sasl-max-buffers to 2M In-Reply-To: <54D3DC3C.6070709@redhat.com> References: <54D3DC3C.6070709@redhat.com> Message-ID: Ran the suggested command from the primary (master) IPA: [root at ipaN1 ~]# ipa-replica-manage list -v ipaN1.xxxx.local ipa-N2.xxxx.local: replica last init status: None last init ended: None last update status: -1 - LDAP error: Can't contact LDAP server last update ended: None Then ran it from the replicant IPA: [root at ipa-N2 ~]# ipa-replica-manage list -v ipa-N2.xxxx.local Directory Manager password: <> ipaN1.xxxx.local: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2015-02-06 14:10:43+00:00 Not sure if the "last update status" is current state or last line of a log when an update was attempted, but double checked this morning that the user in question from yesterday still showed up with an unmatched password expiration date in the GUI of the replicant IPA. So we stopped all IPA-related services on the master (# service ipa stop) waited a few, then restarted them (# service ipa start). Re-ran the query and the last update status message had not changed. We ran an ldapsearch on each IPA server querying for nsds5ReplConflict and each responded the same: # search result search: 2 result: 0 Success # numResponses: 1 Now we looked at the /etc/resolv.conf on the primary IP and found: search localdomain nameserver 8.8.8.8 so we manually edited the file (IPA primary is .206 and IPA replicant is .207): search xxxx.local nameserver 10.200.23.206 nameserver 10.200.23.207 and rebooted the server. When it came back up we checked the /etc/resolv.conf and it had changed back to the values as before the manual edit. I have never seen this resolver configuration file self-change behavior before on any Linux server and it confuses me. We edited the file again and rebooted again and it changed again. Interestingly after the third reboot, where the /etc/resolv.conf ultimately looked like this: [root at ipaN1 ~]# cat /etc/resolv.conf search localdomain nameserver 127.0.0.1 8.8.8.8 I was unable to ping an outside name: [root at ipaN1 ~]# ping yahoo.com ping: unknown host yahoo.com But I was able to ping the IPA replicant: [root at ipaN1 ~]# ping ipa-N2.xxxx.local PING ipa-N2.xxxx.local (10.200.23.207) 56(84) bytes of data. 64 bytes from ipaN2.xxxx.local (10.200.23.207): icmp_seq=1 ttl=64 time=0.136 ms 64 bytes from ipaN2.xxxx.local (10.200.23.207): icmp_seq=2 ttl=64 time=0.206 ms 64 bytes from ipaN2.xxxx.local (10.200.23.207): icmp_seq=3 ttl=64 time=0.182 ms Just for chance I ran the query again and voila: [root at ipaN1 ~]# ipa-replica-manage list -v ipaN1.xxxx.local ipa-N2.xxxx.local: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update started last update ended: None Replication took place. I checked the user in question through GUI on the IPA replicant and the password expiration now matches the IPA primary. What made the update finally happen? Why if the /etc/resolv.conf rewriting? Should it point to outside interfaces of localhost / localdomain? Will replication continue across future changes or will I have to massage this every time? This is so strange. Steven Auerbach Systems Administrator State University System of Florida Board of Governors 325 West Gaines Street Tallahassee, Florida 32399 (850) 245-9592 | Fax (850) 245-0419 steven.auerbach at flbog.edu | www.flbog.edu -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Thursday, February 05, 2015 4:10 PM To: Auerbach, Steven; IPA User Maillist (freeipa-users at redhat.com) Cc: Ouellet, Dan Subject: Re: [Freeipa-users] Replication not happening for user password changes even after increasing the nsslapd-sasl-max-buffers to 2M Auerbach, Steven wrote: > A user contacted me today for a password reset. I made the reset on > the ipa-primary. The user opened a terminal session on an SSH Client > to a server in the realm and logged in. They received the required > immediate password change requirement and did so. They can log off and > log back on that same server with their new password. They attempted > to open a terminal shell to another server in the realm. Their new > password is not accepted. > > > > Both servers the user is attempting to connect to have the nameserver > resolution in the same order (resolv.conf). > > > > On the ipa-primary their password expiration is 90 days from today. > On the ipa-replicant the password expiration is about 60 days out (I > did this with them Jan 13^th also but they lost their password.....). It > has been an hour since the user logged on to the server and made their > required change. > > > > 2 questions arise: > > How to safely update replicant with the password change without > changing the primary/replicant replationship order? > > How to force the other server to refer to the ipa-primary to validate > the password? It sounds like replication isn't working. On each master do this: $ ipa-replica-manage list -v `hostname` That will give you the replication status on both sides. rob From matt.wells at mosaic451.com Fri Feb 6 17:34:50 2015 From: matt.wells at mosaic451.com (Matt Wells) Date: Fri, 6 Feb 2015 09:34:50 -0800 Subject: [Freeipa-users] Full migration from 3.X to 4.X Message-ID: I've seen many links and conversations about migrating from 3.X to 4.X; some with migrate-ds but nothing that said "I did it and it worked". Perhaps my Google-Fu is failing me. So I thought I'd ask here, has anyone fully migrated? Systems, SSL certs, sudo and everything? What resources did you use? I'm moving to all new systems so this isn't an in-place upgrade. Right now I have two systems (at 3.X) and two more (at 4.X) waiting in the wings to take over. I see where I could get users and groups but what about the rest? Thanks to anyone who can point in the right direction. I'll keep poking on Google and if I find anything I'll be sure to respond to my own query. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Feb 6 22:14:57 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Feb 2015 17:14:57 -0500 Subject: [Freeipa-users] Full migration from 3.X to 4.X In-Reply-To: References: Message-ID: <54D53CE1.2000002@redhat.com> Matt Wells wrote: > I've seen many links and conversations about migrating from 3.X to 4.X; > some with migrate-ds but nothing that said "I did it and it worked". > Perhaps my Google-Fu is failing me. > > So I thought I'd ask here, has anyone fully migrated? Systems, SSL > certs, sudo and everything? What resources did you use? > I'm moving to all new systems so this isn't an in-place upgrade. Right > now I have two systems (at 3.X) and two more (at 4.X) waiting in the > wings to take over. > I see where I could get users and groups but what about the rest? > > Thanks to anyone who can point in the right direction. I'll keep poking > on Google and if I find anything I'll be sure to respond to my own query. Migration is for moving from an LDAP system to IPA. To move between major versions the recommended path is to create a new master on the upgraded platform. Run them in tandem until you're satisfied that things are working and then retire the older version masters. Be sure to include a CA on one or more of the 4.x masters as well. rob From Less at imagine-sw.com Fri Feb 6 22:34:43 2015 From: Less at imagine-sw.com (Les Stott) Date: Fri, 6 Feb 2015 22:34:43 +0000 Subject: [Freeipa-users] bug in pki during install of CA replica and workaround/solution In-Reply-To: <54D4D23A.5070305@redhat.com> References: <4ED173A868981548967B4FCA27072226280AEAB2@AACMBXP04.exchserver.com> <54D4D23A.5070305@redhat.com> Message-ID: <4ED173A868981548967B4FCA27072226280AF9D3@AACMBXP04.exchserver.com> > -----Original Message----- > From: Martin Kosek [mailto:mkosek at redhat.com] > Sent: Saturday, 7 February 2015 1:40 AM > To: Les Stott; freeipa-users at redhat.com; Matthew Harmsen; Endi Dewata > Subject: Re: [Freeipa-users] bug in pki during install of CA replica and > workaround/solution > > On 02/06/2015 06:59 AM, Les Stott wrote: > > Hi, > > > > I found a bug in the pki packages and CA replica installation. > > > > Environment: > > Rhel 6.6 > > IPA Server 3.0.0-42 > > Pki components: > > pki-symkey-9.0.3-38.el6_6.x86_64 > > pki-common-9.0.3-38.el6_6.noarch > > pki-setup-9.0.3-38.el6_6.noarch > > pki-selinux-9.0.3-38.el6_6.noarch > > pki-java-tools-9.0.3-38.el6_6.noarch > > pki-ca-9.0.3-38.el6_6.noarch > > ipa-pki-common-theme-9.0.3-7.el6.noarch > > ipa-pki-ca-theme-9.0.3-7.el6.noarch > > pki-native-tools-9.0.3-38.el6_6.x86_64 > > pki-util-9.0.3-38.el6_6.noarch > > pki-silent-9.0.3-38.el6_6.noarch > > Selinux: > > Permissive > > > > when running a CA replica installation it fails because pki-cad cannot start > due to selinux context issues. > > > > Samples from the ipareplica-ca-install.log... > > > > ========= > > 2015-02-05T08:20:04Z DEBUG stderr=[error] FAILED run_comman[ OK > ]/service pki-cad restart pki-ca"), exit status=1 output="Stopping pki-ca: > > /usr/bin/runcon: invalid context: > unconfined_u:system_r:pki_ca_script_t:s0: Invalid argument" > > > > 2015-02-05T08:20:04Z DEBUG duration: 6 seconds > > 2015-02-05T08:20:04Z DEBUG [3/16]: configuring certificate server > instance > > ############################################# > > Attempting to connect to: sb1sys02.mydomain.com:9445 Exception in > > LoginPanel(): java.lang.NullPointerException > > ERROR: ConfigureCA: LoginPanel() failure > > ERROR: unable to create CA > > > > > ################################################################### > ### > > # > > > > 2015-02-05T08:20:04Z DEBUG stderr=Exception: Unable to Send > > Request:java.net.ConnectException: Connection refused > > java.net.ConnectException: Connection refused > > > > ========== > > > > In short pki-cad fails to start and stops the installer. > > > > Reinstalling the pki-selinux rpm (found references in some other forum > posts) via yum reinstall pki-selinux is not enough to help. > > > > The solution is as follows: > > > > yum downgrade pki-selinux pki-ca pki-common pki-setup pki-silent > > pki-java-tools pki-symkey pki-util pki-native-tools which takes > > components back to 9.0.3-32 then yum -y update pki-selinux pki-ca > > pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util > > pki-native-tools then (after cleaning up half installed pki > > components) ipa-ca-install > > /var/lib/ipa/replica-info-sb1sys02.mydomain.gpg > > > > Then, the CA replication completes successfully. > > > > Regards, > > > > Les > > I saw this one around, e.g. in: > > http://www.redhat.com/archives/freeipa-devel/2014-May/msg00507.html > > Did you try reinstalling pki-selinux before ipa-server-install? > Yes, tried this. But it was not enough. > Endi/Matthew, do we have a bug/fix for this? > > Thanks, > Martin From Less at imagine-sw.com Fri Feb 6 22:38:44 2015 From: Less at imagine-sw.com (Les Stott) Date: Fri, 6 Feb 2015 22:38:44 +0000 Subject: [Freeipa-users] bug in pki during install of CA replica and workaround/solution In-Reply-To: <54D4D552.8000805@redhat.com> References: <4ED173A868981548967B4FCA27072226280AEAB2@AACMBXP04.exchserver.com> <54D4D23A.5070305@redhat.com> <54D4D552.8000805@redhat.com> Message-ID: <4ED173A868981548967B4FCA27072226280AFA9F@AACMBXP04.exchserver.com> > -----Original Message----- > From: Endi Sukma Dewata [mailto:edewata at redhat.com] > Sent: Saturday, 7 February 2015 1:53 AM > To: Martin Kosek; Les Stott; freeipa-users at redhat.com; Matthew Harmsen > Subject: Re: [Freeipa-users] bug in pki during install of CA replica and > workaround/solution > > On 2/6/2015 8:39 AM, Martin Kosek wrote: > >> Reinstalling the pki-selinux rpm (found references in some other forum > posts) via yum reinstall pki-selinux is not enough to help. > >> > >> The solution is as follows: > >> > >> yum downgrade pki-selinux pki-ca pki-common pki-setup pki-silent > >> pki-java-tools pki-symkey pki-util pki-native-tools which takes > >> components back to 9.0.3-32 then yum -y update pki-selinux pki-ca > >> pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util > >> pki-native-tools then (after cleaning up half installed pki > >> components) ipa-ca-install > >> /var/lib/ipa/replica-info-sb1sys02.mydomain.gpg > >> > >> Then, the CA replication completes successfully. > >> > >> Regards, > >> > >> Les > > > > I saw this one around, e.g. in: > > > > http://www.redhat.com/archives/freeipa-devel/2014- > May/msg00507.html > > > > Did you try reinstalling pki-selinux before ipa-server-install? > > > > Endi/Matthew, do we have a bug/fix for this? > > > > Thanks, > > Martin > > > > Yes, we have a ticket for this: > https://fedorahosted.org/pki/ticket/1243 > The default selinux-policy is version 3.7.19-231. It needs to be updated to at > least version 3.7.19-260. > > -- > Endi S. Dewata I will test this out (update to 3.7.19-260) next week as I've got a few more CA replicas to setup. Thanks, Les From amessina at messinet.com Sat Feb 7 01:50:47 2015 From: amessina at messinet.com (Anthony Messina) Date: Fri, 06 Feb 2015 19:50:47 -0600 Subject: [Freeipa-users] Full migration from 3.X to 4.X In-Reply-To: <54D53CE1.2000002@redhat.com> References: <54D53CE1.2000002@redhat.com> Message-ID: <2775428.Sxydmf6GPU@linux-ws1.messinet.com> On Friday, February 06, 2015 05:14:57 PM Rob Crittenden wrote: > Matt Wells wrote: > > I've seen many links and conversations about migrating from 3.X to 4.X; > > some with migrate-ds but nothing that said "I did it and it worked". > > Perhaps my Google-Fu is failing me. > > > > > > > > So I thought I'd ask here, has anyone fully migrated? Systems, SSL > > certs, sudo and everything? What resources did you use? > > I'm moving to all new systems so this isn't an in-place upgrade. Right > > now I have two systems (at 3.X) and two more (at 4.X) waiting in the > > wings to take over. > > I see where I could get users and groups but what about the rest? > > > > > > > > Thanks to anyone who can point in the right direction. I'll keep poking > > on Google and if I find anything I'll be sure to respond to my own > > query. > > Migration is for moving from an LDAP system to IPA. > > To move between major versions the recommended path is to create a new > master on the upgraded platform. Run them in tandem until you're > satisfied that things are working and then retire the older version masters. > > Be sure to include a CA on one or more of the 4.x masters as well. Watch for this issue that I ran into: https://fedorahosted.org/pki/ticket/1235 -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From bwp.pearson at gmail.com Sat Feb 7 03:11:49 2015 From: bwp.pearson at gmail.com (Bryan Pearson) Date: Fri, 6 Feb 2015 22:11:49 -0500 Subject: [Freeipa-users] SASL(-13) authentication failure Message-ID: Hello, My IPA servers are currently saying: "Failed to get data from 'hostname.lan': Invalid credentials SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context" tail -f /var/log/dirsrv/slapd-HOSTNAME-LAN/errors [06/Feb/2015:21:42:41 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [06/Feb/2015:21:42:41 -0500] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) We have 3 master replicas in operation. ipa2, ipa3, ipa4 and ipa1 we are decommissioning. After losing the CA on 2 nodes, we promoted ipa3 to master, and created a replica file, scped it to ipa4, installed it, and on ipa4 created ipa2. Because of design, 3 and 2 cant communicate with each other. I just stopped dirsrv and pki-ca on ipa1, so its possible it is creating issues. I cant determine where the credentials or how to get them changed as all the nodes are now having similar issues replicating. Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwp.pearson at gmail.com Sat Feb 7 05:17:43 2015 From: bwp.pearson at gmail.com (Bryan Pearson) Date: Sat, 7 Feb 2015 00:17:43 -0500 Subject: [Freeipa-users] SASL(-13) authentication failure In-Reply-To: References: Message-ID: I did a bit more digging into the issue, and realized that the ruv-id of ipa2 is different on only one of the servers of the 3. I am imaging I will need to run clean-ruv on inconsistent node. Bryan On Fri, Feb 6, 2015 at 10:11 PM, Bryan Pearson wrote: > Hello, > > My IPA servers are currently saying: > > "Failed to get data from 'hostname.lan': Invalid credentials SASL(-13): > authentication failure: GSSAPI Failure: gss_accept_sec_context" > > tail -f /var/log/dirsrv/slapd-HOSTNAME-LAN/errors > > [06/Feb/2015:21:42:41 -0500] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 > (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: > gss_accept_sec_context) errno 0 (Success) > [06/Feb/2015:21:42:41 -0500] slapi_ldap_bind - Error: could not perform > interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) > > We have 3 master replicas in operation. ipa2, ipa3, ipa4 and ipa1 we are > decommissioning. After losing the CA on 2 nodes, we promoted ipa3 to > master, and created a replica file, scped it to ipa4, installed it, and on > ipa4 created ipa2. Because of design, 3 and 2 cant communicate with each > other. > > I just stopped dirsrv and pki-ca on ipa1, so its possible it is creating > issues. > > I cant determine where the credentials or how to get them changed as all > the nodes are now having similar issues replicating. > > Bryan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Sat Feb 7 05:53:32 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Sat, 7 Feb 2015 06:53:32 +0100 Subject: [Freeipa-users] User certificates with FreeIPA and another question. In-Reply-To: <54D4D00A.7050402@redhat.com> References: <54D3DBFD.5000703@redhat.com> <54D4D00A.7050402@redhat.com> Message-ID: <20150207055332.GL7799@dhcp-40-8.bne.redhat.com> On Fri, Feb 06, 2015 at 03:30:34PM +0100, Martin Kosek wrote: > On 02/06/2015 12:53 AM, Christopher Young wrote: > > Obvious next question: Any plans to implement that functionality or advice > > on how one might get some level of functionality for this? Would it be > > possible to create another command-line based openssl CA that could issue > > these but using IPA as the root CA for those? > > As for FreeIPA plans, we plan to vastly improve our flexibility to process > certificates in next upstream version - FreeIPA 4.2. In next version, one > should be able to create other certificate profiles (from FreeIPA default > service cert profile) or even subCAs to do what you want. > > As for current workarounds, you would have to issue and sign a for example NSS > or openssl based subCA and then sign user certs there. But I would leave Fraser > or Jan to tell if this would be really possible. > Christopher, until profiles and subCAs are available in FreeIPA your options are: - Issue client certificates from the existing Dogtag CA, by using an appropriate profile and including the relevant information in the certificate request. Client certificates would be issued from the same CA as service certificates (but would have different keyUsage attributes, etc). - Same as above, but spawn a subordinate Dogtag CA instance for issuing the client certificates. - (Martin's suggestion:) Issue a subordinate signing certificate from the Dogtag CA and use OpenSSL or other CA software to issue client certificates. The first option is the easiest but would not be considered good practice because certificates intended for different client uses (e.g. web, VPN) should be issued from different CAs. But the latter options are "heavyweight". Hope that helps, Fraser > > I'm just trying to provide a solution for situations where we would like to > > utilize client/user cert authentication for situations like secure apache > > directory access as well as user VPN certificates. Any advise or ideas are > > great appreciated. > > > > Thanks again! > > > > On Thu, Feb 5, 2015 at 4:09 PM, Rob Crittenden wrote: > > > >> Christopher Young wrote: > >>> Some of this might be rudimentary, so I apologize if this is answered > >>> somewhere, though I've tried to search and have not had much luck... > >>> > >>> Basically, I would like to be able to issue user certificates (Subject: > >>> email=sblblabla at blabla.local) in order to use client SSL security on > >>> some things. I'm very new to FreeIPA, but have worked with external CAs > >>> in the past for similar requests, however this is my first entry into > >>> creating/running a localized CA within an organization. > >> > >> IPA doesn't issue user certificates yet, only server certificates. > >> > >>> I was wondering if this is possible via the command line, and if so, how > >>> to go about submitting the request and receiving the certificate. Any > >>> guidance or assistance would be greatly appreciated! > >>> > >>> > >>> Additionally, just as a matter of cleanliness, is there any way possible > >>> to just completely wipe out the existence of a certificate/request from > >>> FreeIPA. I have done some trial-and-error and obviously have made > >>> mistakes that I'd prefer to clean up after. I've revoked those certs, > >>> however the perfectionist in me hates seeing them there. I'm quite > >>> certain the answer is 'no', but I thought I would ask anyway. > >> > >> Right, the answer is no. In fact it is a good thing that all > >> certificates are accounted for. > >> > >> rob > >> > >> > > > > > > > From bwp.pearson at gmail.com Sat Feb 7 07:22:29 2015 From: bwp.pearson at gmail.com (Bryan Pearson) Date: Sat, 7 Feb 2015 02:22:29 -0500 Subject: [Freeipa-users] SASL(-13) authentication failure In-Reply-To: References: Message-ID: Okay, sorry for the messages. The original issue has been resolved, one of the servers time was off. I am now having a problem similar to this: https://bugzilla.redhat.com/show_bug.cgi?id=953653. My logs indicate all the same issues. With IPA 3.0.0 and Centos 6.6 is this still a viable solution to the problem? Bryan On Sat, Feb 7, 2015 at 12:17 AM, Bryan Pearson wrote: > I did a bit more digging into the issue, and realized that the ruv-id of > ipa2 is different on only one of the servers of the 3. I am imaging I will > need to run clean-ruv on inconsistent node. > > Bryan > > On Fri, Feb 6, 2015 at 10:11 PM, Bryan Pearson > wrote: > >> Hello, >> >> My IPA servers are currently saying: >> >> "Failed to get data from 'hostname.lan': Invalid credentials SASL(-13): >> authentication failure: GSSAPI Failure: gss_accept_sec_context" >> >> tail -f /var/log/dirsrv/slapd-HOSTNAME-LAN/errors >> >> [06/Feb/2015:21:42:41 -0500] slapd_ldap_sasl_interactive_bind - Error: >> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 >> (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: >> gss_accept_sec_context) errno 0 (Success) >> [06/Feb/2015:21:42:41 -0500] slapi_ldap_bind - Error: could not perform >> interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) >> >> We have 3 master replicas in operation. ipa2, ipa3, ipa4 and ipa1 we are >> decommissioning. After losing the CA on 2 nodes, we promoted ipa3 to >> master, and created a replica file, scped it to ipa4, installed it, and on >> ipa4 created ipa2. Because of design, 3 and 2 cant communicate with each >> other. >> >> I just stopped dirsrv and pki-ca on ipa1, so its possible it is creating >> issues. >> >> I cant determine where the credentials or how to get them changed as all >> the nodes are now having similar issues replicating. >> >> Bryan >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sat Feb 7 14:59:05 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 07 Feb 2015 09:59:05 -0500 Subject: [Freeipa-users] User certificates with FreeIPA and another question. In-Reply-To: References: <54D3DBFD.5000703@redhat.com> <54D4D00A.7050402@redhat.com> Message-ID: <54D62839.9040708@redhat.com> On 02/06/2015 10:38 AM, Natxo Asenjo wrote: > On Fri, Feb 6, 2015 at 3:30 PM, Martin Kosek > wrote: > > On 02/06/2015 12:53 AM, Christopher Young wrote: > > Obvious next question: Any plans to implement that > functionality or advice > > on how one might get some level of functionality for this? > Would it be > > possible to create another command-line based openssl CA that > could issue > > these but using IPA as the root CA for those? > > As for FreeIPA plans, we plan to vastly improve our flexibility to > process > certificates in next upstream version - FreeIPA 4.2. In next > version, one > should be able to create other certificate profiles (from FreeIPA > default > service cert profile) or even subCAs to do what you want. > > > nice. When do all these things land in RHEL? It we manage to land 4.2 in RHEL 7.2 then it will be there. Time will show how successful we will be with this plan so no promises so far. > As for current workarounds, you would have to issue and sign a for > example NSS > or openssl based subCA and then sign user certs there. But I would > leave Fraser > or Jan to tell if this would be really possible. > > > some examples on how to do that would be very helpful. I would love to > authenticate users to mysql using our CA, for instance. > > -- > regards, > natxo > > > > -- 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 Feb 7 15:06:17 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 07 Feb 2015 10:06:17 -0500 Subject: [Freeipa-users] SASL(-13) authentication failure In-Reply-To: References: Message-ID: <54D629E9.2070008@redhat.com> On 02/07/2015 02:22 AM, Bryan Pearson wrote: > Okay, sorry for the messages. The original issue has been resolved, > one of the servers time was off. > > I am now having a problem similar to this: > https://bugzilla.redhat.com/show_bug.cgi?id=953653. My logs indicate > all the same issues. > With IPA 3.0.0 and Centos 6.6 is this still a viable solution to the > problem? Please start a new thread for a different question. It seems that we were not able to reproduce it so it might be that the issue still there. One of the problems can be the mismatch of the buffer sizes. See the bug. > > Bryan > > On Sat, Feb 7, 2015 at 12:17 AM, Bryan Pearson > wrote: > > I did a bit more digging into the issue, and realized that the > ruv-id of ipa2 is different on only one of the servers of the 3. I > am imaging I will need to run clean-ruv on inconsistent node. > > Bryan > > On Fri, Feb 6, 2015 at 10:11 PM, Bryan Pearson > > wrote: > > Hello, > > My IPA servers are currently saying: > > "Failed to get data from 'hostname.lan': Invalid credentials > SASL(-13): authentication failure: GSSAPI Failure: > gss_accept_sec_context" > > tail -f /var/log/dirsrv/slapd-HOSTNAME-LAN/errors > > [06/Feb/2015:21:42:41 -0500] slapd_ldap_sasl_interactive_bind > - Error: could not perform interactive bind for id [] mech > [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): > authentication failure: GSSAPI Failure: > gss_accept_sec_context) errno 0 (Success) > [06/Feb/2015:21:42:41 -0500] slapi_ldap_bind - Error: could > not perform interactive bind for id [] mech [GSSAPI]: error 49 > (Invalid credentials) > > We have 3 master replicas in operation. ipa2, ipa3, ipa4 and > ipa1 we are decommissioning. After losing the CA on 2 nodes, > we promoted ipa3 to master, and created a replica file, scped > it to ipa4, installed it, and on ipa4 created ipa2. Because of > design, 3 and 2 cant communicate with each other. > > I just stopped dirsrv and pki-ca on ipa1, so its possible it > is creating issues. > > I cant determine where the credentials or how to get them > changed as all the nodes are now having similar issues > replicating. > > Bryan > > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmohler at oberlin.edu Sat Feb 7 18:25:45 2015 From: cmohler at oberlin.edu (Chris Mohler) Date: Sat, 7 Feb 2015 13:25:45 -0500 Subject: [Freeipa-users] How do I modify the entry cache size? Message-ID: Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to increase the entry cache size I'm trying to follow the directions here /usr/lib/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389 dn: cn=*database_name*, cn=ldbm database, cn=plugins, cn=config changetype: modify replace: nsslapd-cachememsize nsslapd-cachememsize: 20971520 Is this the correct way to do this? How do I find out what the " cn= *database_name" is supposed to be?* *Thanks,* *-Chris* -------------- next part -------------- An HTML attachment was scrubbed... URL: From baghery.jone at gmail.com Sun Feb 8 08:10:44 2015 From: baghery.jone at gmail.com (alireza baghery) Date: Sun, 8 Feb 2015 11:40:44 +0330 Subject: [Freeipa-users] error install replication Message-ID: hi i install ipa on centos 6.5 and want install replica for purpose i do the following task: ipa-install-prepare --ip-address (replica) replica.... (replica) namserver ipa (replica) ipa-replica-install but in Connetcon Check get ERROR =======message stdout replica======= Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master admin@********* password: Execute check on remote master Remote master check failed with following error message(s): Connection check failed! Please fix your network settings according to error messages above. If the check results are not valid it can be skipped with --skip-conncheck parameter. =========message log in /var/log/ipa-replication-connection-check ===================== 2015-02-08T07:41:30Z DEBUG args=/usr/bin/kinit admin at IPA***** 2015-02-08T07:41:30Z DEBUG stdout=Password for admin at IPA*****: 2015-02-08T07:41:30Z DEBUG stderr= 2015-02-08T07:41:30Z DEBUG args=/usr/bin/kvno host/ipa******** 2015-02-08T07:41:30Z DEBUG stdout=host/ipa*****@IPA******: kvno = 2 2015-02-08T07:41:30Z DEBUG stderr= 2015-02-08T07:41:30Z DEBUG args=/usr/bin/ssh -q -o StrictHostKeychecking=no -o UserKnownHostsFile=/dev/null admin at ipa**** /usr/sbin/ipa-replica-conncheck --replica replica******* 2015-02-08T07:41:30Z DEBUG stdout= 2015-02-08T07:41:30Z DEBUG stderr= ================================= tnx -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sun Feb 8 12:28:15 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 08 Feb 2015 07:28:15 -0500 Subject: [Freeipa-users] error install replication In-Reply-To: References: Message-ID: <54D7565F.2030203@redhat.com> On 02/08/2015 03:10 AM, alireza baghery wrote: > hi > i install ipa on centos 6.5 > and want install replica > for purpose i do the following task: > ipa-install-prepare --ip-address (replica) replica.... > (replica) namserver ipa > (replica) ipa-replica-install > but in Connetcon Check get ERROR > =======message stdout replica======= > Connection from replica to master is OK. > Start listening on required ports for remote master check > Get credentials to log in to remote master > admin@********* password: > > Execute check on remote master > > Remote master check failed with following error message(s): > > Connection check failed! > Please fix your network settings according to error messages above. > If the check results are not valid it can be skipped with > --skip-conncheck parameter. > =========message log in /var/log/ipa-replication-connection-check > ===================== > 2015-02-08T07:41:30Z DEBUG args=/usr/bin/kinit admin at IPA***** > 2015-02-08T07:41:30Z DEBUG stdout=Password for admin at IPA*****: > > 2015-02-08T07:41:30Z DEBUG stderr= > 2015-02-08T07:41:30Z DEBUG args=/usr/bin/kvno host/ipa******** > 2015-02-08T07:41:30Z DEBUG stdout=host/ipa*****@IPA******: kvno = 2 > > 2015-02-08T07:41:30Z DEBUG stderr= > 2015-02-08T07:41:30Z DEBUG args=/usr/bin/ssh -q -o > StrictHostKeychecking=no -o UserKnownHostsFile=/dev/null admin at ipa**** > /usr/sbin/ipa-replica-conncheck --replica replica******* > 2015-02-08T07:41:30Z DEBUG stdout= > 2015-02-08T07:41:30Z DEBUG stderr= > ================================= > tnx > > Check your firewall and DNS settings. One problem can be that replica incorrectly resolves master. Another that FW blocks access from replica to master. -- 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 Feb 8 13:46:36 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 08 Feb 2015 08:46:36 -0500 Subject: [Freeipa-users] error install replication In-Reply-To: References: <54D7565F.2030203@redhat.com> Message-ID: <54D768BC.7050602@redhat.com> On 02/08/2015 08:35 AM, alireza baghery wrote: > iptables and firewalls stop > and on both server execute nslookup ipasrv and nslookup replica > output successfully > Please reply on the list. Next thing I would check if the SSH command actually makes it from replica to master by monitoring SSH logs. If it does not (which I think the case) then it is still a DNS problem. Can you please check that both servers actually resolve each other's name to the same IP address? > On Sun, Feb 8, 2015 at 3:58 PM, Dmitri Pal > wrote: > > On 02/08/2015 03:10 AM, alireza baghery wrote: >> hi >> i install ipa on centos 6.5 >> and want install replica >> for purpose i do the following task: >> ipa-install-prepare --ip-address (replica) replica.... >> (replica) namserver ipa >> (replica) ipa-replica-install >> but in Connetcon Check get ERROR >> =======message stdout replica======= >> Connection from replica to master is OK. >> Start listening on required ports for remote master check >> Get credentials to log in to remote master >> admin@********* password: >> >> Execute check on remote master >> >> Remote master check failed with following error message(s): >> >> Connection check failed! >> Please fix your network settings according to error messages above. >> If the check results are not valid it can be skipped with >> --skip-conncheck parameter. >> =========message log in /var/log/ipa-replication-connection-check >> ===================== >> 2015-02-08T07:41:30Z DEBUG args=/usr/bin/kinit admin at IPA***** >> 2015-02-08T07:41:30Z DEBUG stdout=Password for admin at IPA*****: >> >> 2015-02-08T07:41:30Z DEBUG stderr= >> 2015-02-08T07:41:30Z DEBUG args=/usr/bin/kvno host/ipa******** >> 2015-02-08T07:41:30Z DEBUG stdout=host/ipa*****@IPA******: kvno = 2 >> >> 2015-02-08T07:41:30Z DEBUG stderr= >> 2015-02-08T07:41:30Z DEBUG args=/usr/bin/ssh -q -o >> StrictHostKeychecking=no -o UserKnownHostsFile=/dev/null >> admin at ipa**** /usr/sbin/ipa-replica-conncheck --replica >> replica******* >> 2015-02-08T07:41:30Z DEBUG stdout= >> 2015-02-08T07:41:30Z DEBUG stderr= >> ================================= >> tnx >> >> > Check your firewall and DNS settings. > One problem can be that replica incorrectly resolves master. > Another that FW blocks access from replica to master. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > -- 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 Sun Feb 8 22:58:39 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Sun, 08 Feb 2015 15:58:39 -0700 Subject: [Freeipa-users] How do I modify the entry cache size? In-Reply-To: References: Message-ID: <54D7EA1F.5030209@redhat.com> On 02/07/2015 11:25 AM, Chris Mohler wrote: > Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to increase the entry cache size > I'm trying to follow the directions here > /usr/lib/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389 > > dn: cn=/|database_name|/, cn=ldbm database, cn=plugins, cn=config > changetype: modify > replace: nsslapd-cachememsize > nsslapd-cachememsize: 20971520 > > Is this the correct way to do this? How do I find out what the " > cn=/|database_name" is supposed to be? > |/ |/see /|https://github.com/richm/scripts/wiki/dbmon.sh - the script will tell you what the names of your databases are. > /| > |/ > /|Thanks, > |/ > /|-Chris > |/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmohler at oberlin.edu Mon Feb 9 03:23:45 2015 From: cmohler at oberlin.edu (Chris Mohler) Date: Sun, 8 Feb 2015 22:23:45 -0500 Subject: [Freeipa-users] How do I modify the entry cache size? In-Reply-To: <54D7EA1F.5030209@redhat.com> References: <54D7EA1F.5030209@redhat.com> Message-ID: Thanks for the reply and the link Rich! dbmon.sh is a handy tool indeed. I read the instructions and upped my entry cache size to 2gb because I have enough ram. Everything went well until service dirsrv restart I Got the following errors: [06/Feb/2015:10:07:35 -0500] - slapd stopped. [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching rule [caseIgnoreIA5Match] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] [06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up [06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port 7389 for LDAP requests [06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS requests Oddly enough everything appears to be working. Are these messages safe to ignore? Another run of dbmon.sh shows that my entry cache was increased. Thanks, -Chris On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson wrote: > On 02/07/2015 11:25 AM, Chris Mohler wrote: > > Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to increase the entry cache size > > I'm trying to follow the directions here > > /usr/lib/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389 > > dn: cn=*database_name*, cn=ldbm database, cn=plugins, cn=config > changetype: modify > replace: nsslapd-cachememsize > nsslapd-cachememsize: 20971520 > > > Is this the correct way to do this? How do I find out what the " > cn=*database_name" is supposed to be? > * > > > *see *https://github.com/richm/scripts/wiki/dbmon.sh - the script will > tell you what the names of your databases are. > > *Thanks, > * > > *-Chris > * > > > > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baghery.jone at gmail.com Mon Feb 9 06:42:00 2015 From: baghery.jone at gmail.com (alireza baghery) Date: Mon, 9 Feb 2015 10:12:00 +0330 Subject: [Freeipa-users] error install replication In-Reply-To: <54D768BC.7050602@redhat.com> References: <54D7565F.2030203@redhat.com> <54D768BC.7050602@redhat.com> Message-ID: i check on both server ssh each other's name and ssh successful and resolve name was also correct on each server but i can not login with user admin from ipareplica via ssh (root at ipareplica]# ssh admin at ipasrv ===> failed) [root at ipareplica ~]# ssh ipasrv root at ipasrv's password: Last login: Mon Feb 9 09:49:54 2015 from 10.30.160.20 =====log /var/secure==== Feb 9 09:50:29 ipasrv sshd[12076]: Accepted password for root from 10.30.160.20 port 52110 ssh2 Feb 9 09:50:29 ipasrv sshd[12076]: pam_unix(sshd:session): session opened for user root by (uid=0) ===== [root at ipasrv ~]# ssh ipareplica root at ipareplica's password: Last login: Mon Feb 9 09:50:20 2015 from 10.30.160.19 ====== [root at ipareplica ~]# nslookup ipasrv Server: 10.30.160.19 Address: 10.30.160.19#53 Name: ipasrv Address: 10.30.160.19 ======== [root at ipasrv ~]# nslookup ipareplica Server: 127.0.0.1 Address: 127.0.0.1#53 Name: ipareplica Address: 10.30.160.20 ========= -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Feb 9 07:49:25 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Feb 2015 08:49:25 +0100 Subject: [Freeipa-users] error install replication In-Reply-To: References: <54D7565F.2030203@redhat.com> <54D768BC.7050602@redhat.com> Message-ID: <54D86685.8010106@redhat.com> On 02/09/2015 07:42 AM, alireza baghery wrote: > i check on both server ssh each other's name and ssh successful and resolve > name was also correct on each server > but i can not login with user admin from ipareplica via ssh (root at ipareplica]# > ssh admin at ipasrv ===> failed) > > [root at ipareplica ~]# ssh ipasrv > root at ipasrv's password: > Last login: Mon Feb 9 09:49:54 2015 from 10.30.160.20 > =====log /var/secure==== > Feb 9 09:50:29 ipasrv sshd[12076]: Accepted password for root from > 10.30.160.20 port 52110 ssh2 > Feb 9 09:50:29 ipasrv sshd[12076]: pam_unix(sshd:session): session opened > for user root by (uid=0) > ===== > [root at ipasrv ~]# ssh ipareplica > root at ipareplica's password: > Last login: Mon Feb 9 09:50:20 2015 from 10.30.160.19 > > ====== > [root at ipareplica ~]# nslookup ipasrv > Server: 10.30.160.19 > Address: 10.30.160.19#53 > > Name: ipasrv > Address: 10.30.160.19 > > ======== > [root at ipasrv ~]# nslookup ipareplica > Server: 127.0.0.1 > Address: 127.0.0.1#53 > > Name: ipareplica > Address: 10.30.160.20 > ========= Ok, so ssh is running, you can log in with root. I think that by 99% chance, your SSSD service is not running on the IPA server. Please check if this is the case and if yes, please try to (re)start it. If that helped, it would be also useful to see *why* the SSSD is not running (crash, misconfiguration, ...) Martin From baghery.jone at gmail.com Mon Feb 9 08:29:57 2015 From: baghery.jone at gmail.com (alireza baghery) Date: Mon, 9 Feb 2015 11:59:57 +0330 Subject: [Freeipa-users] error install replication In-Reply-To: <54D86685.8010106@redhat.com> References: <54D7565F.2030203@redhat.com> <54D768BC.7050602@redhat.com> <54D86685.8010106@redhat.com> Message-ID: ipasrv# Service SSSD status sssd is runing nevertheless i restart service sssd but problem do not solved On Mon, Feb 9, 2015 at 11:19 AM, Martin Kosek wrote: > On 02/09/2015 07:42 AM, alireza baghery wrote: > > i check on both server ssh each other's name and ssh successful and > resolve > > name was also correct on each server > > but i can not login with user admin from ipareplica via ssh > (root at ipareplica]# > > ssh admin at ipasrv ===> failed) > > > > [root at ipareplica ~]# ssh ipasrv > > root at ipasrv's password: > > Last login: Mon Feb 9 09:49:54 2015 from 10.30.160.20 > > =====log /var/secure==== > > Feb 9 09:50:29 ipasrv sshd[12076]: Accepted password for root from > > 10.30.160.20 port 52110 ssh2 > > Feb 9 09:50:29 ipasrv sshd[12076]: pam_unix(sshd:session): session > opened > > for user root by (uid=0) > > ===== > > [root at ipasrv ~]# ssh ipareplica > > root at ipareplica's password: > > Last login: Mon Feb 9 09:50:20 2015 from 10.30.160.19 > > > > ====== > > [root at ipareplica ~]# nslookup ipasrv > > Server: 10.30.160.19 > > Address: 10.30.160.19#53 > > > > Name: ipasrv > > Address: 10.30.160.19 > > > > ======== > > [root at ipasrv ~]# nslookup ipareplica > > Server: 127.0.0.1 > > Address: 127.0.0.1#53 > > > > Name: ipareplica > > Address: 10.30.160.20 > > ========= > > Ok, so ssh is running, you can log in with root. I think that by 99% > chance, > your SSSD service is not running on the IPA server. Please check if this > is the > case and if yes, please try to (re)start it. If that helped, it would be > also > useful to see *why* the SSSD is not running (crash, misconfiguration, ...) > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Feb 9 10:12:38 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Feb 2015 11:12:38 +0100 Subject: [Freeipa-users] error install replication In-Reply-To: References: <54D7565F.2030203@redhat.com> <54D768BC.7050602@redhat.com> <54D86685.8010106@redhat.com> Message-ID: <54D88816.9060904@redhat.com> Ok. When on the server, does # id admin or "ssh admin@`hostname`" work? Maybe it does not recognize the admin user. On 02/09/2015 09:29 AM, alireza baghery wrote: > ipasrv# Service SSSD status > sssd is runing > nevertheless i restart service sssd > but problem do not solved > > On Mon, Feb 9, 2015 at 11:19 AM, Martin Kosek wrote: > >> On 02/09/2015 07:42 AM, alireza baghery wrote: >>> i check on both server ssh each other's name and ssh successful and >> resolve >>> name was also correct on each server >>> but i can not login with user admin from ipareplica via ssh >> (root at ipareplica]# >>> ssh admin at ipasrv ===> failed) >>> >>> [root at ipareplica ~]# ssh ipasrv >>> root at ipasrv's password: >>> Last login: Mon Feb 9 09:49:54 2015 from 10.30.160.20 >>> =====log /var/secure==== >>> Feb 9 09:50:29 ipasrv sshd[12076]: Accepted password for root from >>> 10.30.160.20 port 52110 ssh2 >>> Feb 9 09:50:29 ipasrv sshd[12076]: pam_unix(sshd:session): session >> opened >>> for user root by (uid=0) >>> ===== >>> [root at ipasrv ~]# ssh ipareplica >>> root at ipareplica's password: >>> Last login: Mon Feb 9 09:50:20 2015 from 10.30.160.19 >>> >>> ====== >>> [root at ipareplica ~]# nslookup ipasrv >>> Server: 10.30.160.19 >>> Address: 10.30.160.19#53 >>> >>> Name: ipasrv >>> Address: 10.30.160.19 >>> >>> ======== >>> [root at ipasrv ~]# nslookup ipareplica >>> Server: 127.0.0.1 >>> Address: 127.0.0.1#53 >>> >>> Name: ipareplica >>> Address: 10.30.160.20 >>> ========= >> >> Ok, so ssh is running, you can log in with root. I think that by 99% >> chance, >> your SSSD service is not running on the IPA server. Please check if this >> is the >> case and if yes, please try to (re)start it. If that helped, it would be >> also >> useful to see *why* the SSSD is not running (crash, misconfiguration, ...) >> >> Martin >> > > > From baghery.jone at gmail.com Mon Feb 9 10:18:10 2015 From: baghery.jone at gmail.com (alireza baghery) Date: Mon, 9 Feb 2015 13:48:10 +0330 Subject: [Freeipa-users] error install replication In-Reply-To: <54D88816.9060904@redhat.com> References: <54D7565F.2030203@redhat.com> <54D768BC.7050602@redhat.com> <54D86685.8010106@redhat.com> <54D88816.9060904@redhat.com> Message-ID: account admin recognize and show uid gid and groups On Feb 9, 2015 1:42 PM, "Martin Kosek" wrote: > Ok. When on the server, does > > # id admin > > or "ssh admin@`hostname`" work? Maybe it does not recognize the admin > user. > > On 02/09/2015 09:29 AM, alireza baghery wrote: > > ipasrv# Service SSSD status > > sssd is runing > > nevertheless i restart service sssd > > but problem do not solved > > > > On Mon, Feb 9, 2015 at 11:19 AM, Martin Kosek wrote: > > > >> On 02/09/2015 07:42 AM, alireza baghery wrote: > >>> i check on both server ssh each other's name and ssh successful and > >> resolve > >>> name was also correct on each server > >>> but i can not login with user admin from ipareplica via ssh > >> (root at ipareplica]# > >>> ssh admin at ipasrv ===> failed) > >>> > >>> [root at ipareplica ~]# ssh ipasrv > >>> root at ipasrv's password: > >>> Last login: Mon Feb 9 09:49:54 2015 from 10.30.160.20 > >>> =====log /var/secure==== > >>> Feb 9 09:50:29 ipasrv sshd[12076]: Accepted password for root from > >>> 10.30.160.20 port 52110 ssh2 > >>> Feb 9 09:50:29 ipasrv sshd[12076]: pam_unix(sshd:session): session > >> opened > >>> for user root by (uid=0) > >>> ===== > >>> [root at ipasrv ~]# ssh ipareplica > >>> root at ipareplica's password: > >>> Last login: Mon Feb 9 09:50:20 2015 from 10.30.160.19 > >>> > >>> ====== > >>> [root at ipareplica ~]# nslookup ipasrv > >>> Server: 10.30.160.19 > >>> Address: 10.30.160.19#53 > >>> > >>> Name: ipasrv > >>> Address: 10.30.160.19 > >>> > >>> ======== > >>> [root at ipasrv ~]# nslookup ipareplica > >>> Server: 127.0.0.1 > >>> Address: 127.0.0.1#53 > >>> > >>> Name: ipareplica > >>> Address: 10.30.160.20 > >>> ========= > >> > >> Ok, so ssh is running, you can log in with root. I think that by 99% > >> chance, > >> your SSSD service is not running on the IPA server. Please check if this > >> is the > >> case and if yes, please try to (re)start it. If that helped, it would be > >> also > >> useful to see *why* the SSSD is not running (crash, misconfiguration, > ...) > >> > >> Martin > >> > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Duncan.Innes at virginmoney.com Mon Feb 9 11:30:11 2015 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Mon, 9 Feb 2015 11:30:11 -0000 Subject: [Freeipa-users] Real-time replication status (RFE)? In-Reply-To: <54D4CA4C.9020702@redhat.com> References: <54D37BD1.2060508@redhat.com> <56343345B145C043AE990701E3D193950478E3E4@EXVS2.nrplc.localnet> <56343345B145C043AE990701E3D193950478E3E5@EXVS2.nrplc.localnet> <54D4CA4C.9020702@redhat.com> Message-ID: <56343345B145C043AE990701E3D193950478E3EB@EXVS2.nrplc.localnet> For sure Rob. It's a dirty hack to get the information that we desperately needed at one point. We had a pretty severe issue with our IPA servers a while back which was eventually solved by reinstalling all but the initial IPA server, deleting the old replication agreements and building the new ones back up. This page was of high value at that time. It's still useful for an occasional check of the status. D -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: 06 February 2015 14:06 To: Innes, Duncan; Baird, Josh; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Real-time replication status (RFE)? Innes, Duncan wrote: > Check: > > https://gist.github.com/duncaninnes/c91985822be9782df581 > > which contains 2 scripts based on: > > http://directory.fedoraproject.org/docs/389ds/howto/howto-replicationm > on > itoring.html > > I just expanded it to cope with a list of servers, then version 2 > sorts by last end, last start, hostname. This version allows me to > see more clearly if a certain replication is out of date. Could have > done a sort by column and added a refresh button, or automatic > refresh, but that wasn't the immediate aim. Since then it's just > stuck, so could do with some love from any suitably minded persons. > It also doesn't gracefully handle situations where one server in the > list is offline, or taking too long to respond. > > Both scripts are put in /var/www/cgi-bin on one of my IPA servers, and > accessed via: > > https://ipa01.example.com/cgi-bin/monitor2.pl > > for example. Not sure if I modified the httpd configs - it's a while > ago that I sorted it out. > > HTH > > Duncan We try to avoid using Directory Manager as much as possible which is one of the reasons we haven't done something like this already. I'd definitely recommend using startTLS for your bind, at a minimum. The issue starts with the fact that we don't have a hostgroup consisting of all IPA masters maintained automatically so there is no easy way to do delegation. You could do this manually if you wanted though, something like: # ipa hostgroup-add ipamasters --desc='Manual list of IPA masters' # ipa hostgroup-add-member --hosts=ipa1.example.com ipamasters # ipa hostgroup-add-member --hosts=ipa2.example.com ipamasters Now create a role that with a privilege to be able to read replication agreements (and add and delete them too, so be aware). # ipa role-add ipamasters --desc='IPA Masters' # ipa role-add-privilege --privileges='Replication Administrators' ipamasters # ipa role-add-member --hostgroup=ipamasters ipamasters You can test this with: # kinit -kt /etc/krb5.keytab # ldapsearch -Y GSSAPI -b 'cn=mapping tree,cn=config' '(objectclass=nsDS5ReplicationAgreement)' You'd just need to the ipamasters hostgroup up-to-date, and considering that this list probably stabilizes over time, shouldn't be a ton of effort. rob > -----Original Message----- > From: Baird, Josh [mailto:jbaird at follett.com] > Sent: 05 February 2015 17:08 > To: Innes, Duncan; Rob Crittenden; freeipa-users at redhat.com > Subject: RE: [Freeipa-users] Real-time replication status (RFE)? > > That would be great, thanks! > > Josh > >> -----Original Message----- >> From: Innes, Duncan [mailto:Duncan.Innes at virginmoney.com] >> Sent: Thursday, February 05, 2015 11:34 AM >> To: Rob Crittenden; Baird, Josh; freeipa-users at redhat.com >> Subject: RE: [Freeipa-users] Real-time replication status (RFE)? >> >> The screen mockup in that ticket is based on a Perl script that I >> stuck in cgi-bin to pull just those stats off each IPA server I have >> and display them. Can share the code if you're interested. >> >> D >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rob Crittenden >> Sent: 05 February 2015 14:19 >> To: Baird, Josh; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Real-time replication status (RFE)? >> >> Baird, Josh wrote: >>> Hi, >>> >>> I'm looking for an easy way to validate that all replication >> agreements are functioning correctly between all of my IPA masters >> and > >> replicas. I am aware that I can run 'ipa-replica-manage list -v' >> from > >> each IPA master, but I was looking for something more centralized >> that > >> could give me a replication health report for all masters/replicas. >> Ideally, this type of feature would be exposed in the UI and would >> also include information or insight into the status of any IPA <-> AD >> trust relationships. >>> >>> Am I missing a feature that already exists? If not, is there >> something like this on the IPA roadmap? >> >> This is being tracked in https://fedorahosted.org/freeipa/ticket/4390 >> >> It depends on some other work being done first. >> >> rob >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> >> This message has been checked for viruses and spam by the Virgin >> Money > >> email scanning system powered by Messagelabs. >> >> This message has been checked for viruses and spam by the Virgin >> Money > >> email scanning system powered by Messagelabs. >> >> This e-mail is intended to be confidential to the recipient. If you >> receive a copy in error, please inform the sender and then delete >> this > message. >> >> Virgin Money plc - Registered in England and Wales (Company no. > 6952311). >> Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 > 4PL. >> Virgin Money plc is authorised by the Prudential Regulation Authority >> and regulated by the Financial Conduct Authority and the Prudential >> Regulation Authority. >> >> The following companies also trade as Virgin Money. They are both >> authorised and regulated by the Financial Conduct Authority, are >> registered in England and Wales and have their registered office at >> Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money >> Personal Financial Service Limited (Company no. 3072766) and Virgin >> Money Unit Trust Managers Limited (Company no. 3000482). >> >> For further details of Virgin Money group companies please visit our >> website at virginmoney.com > > This message has been checked for viruses and spam by the Virgin Money > email scanning system powered by Messagelabs. > > This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. > > This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. > > Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. > > The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). > > For further details of Virgin Money group companies please visit our > website at virginmoney.com > This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com From mkosek at redhat.com Mon Feb 9 11:50:09 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Feb 2015 12:50:09 +0100 Subject: [Freeipa-users] error install replication In-Reply-To: References: <54D7565F.2030203@redhat.com> <54D768BC.7050602@redhat.com> <54D86685.8010106@redhat.com> <54D88816.9060904@redhat.com> Message-ID: <54D89EF1.3030401@redhat.com> Did you try the "ssh admin@`hostname`" command? It should show if ssh to admin via SSSD&FreeIPA really works. On 02/09/2015 11:18 AM, alireza baghery wrote: > account admin recognize and show uid gid and groups > On Feb 9, 2015 1:42 PM, "Martin Kosek" wrote: > >> Ok. When on the server, does >> >> # id admin >> >> or "ssh admin@`hostname`" work? Maybe it does not recognize the admin >> user. >> >> On 02/09/2015 09:29 AM, alireza baghery wrote: >>> ipasrv# Service SSSD status >>> sssd is runing >>> nevertheless i restart service sssd >>> but problem do not solved >>> >>> On Mon, Feb 9, 2015 at 11:19 AM, Martin Kosek wrote: >>> >>>> On 02/09/2015 07:42 AM, alireza baghery wrote: >>>>> i check on both server ssh each other's name and ssh successful and >>>> resolve >>>>> name was also correct on each server >>>>> but i can not login with user admin from ipareplica via ssh >>>> (root at ipareplica]# >>>>> ssh admin at ipasrv ===> failed) >>>>> >>>>> [root at ipareplica ~]# ssh ipasrv >>>>> root at ipasrv's password: >>>>> Last login: Mon Feb 9 09:49:54 2015 from 10.30.160.20 >>>>> =====log /var/secure==== >>>>> Feb 9 09:50:29 ipasrv sshd[12076]: Accepted password for root from >>>>> 10.30.160.20 port 52110 ssh2 >>>>> Feb 9 09:50:29 ipasrv sshd[12076]: pam_unix(sshd:session): session >>>> opened >>>>> for user root by (uid=0) >>>>> ===== >>>>> [root at ipasrv ~]# ssh ipareplica >>>>> root at ipareplica's password: >>>>> Last login: Mon Feb 9 09:50:20 2015 from 10.30.160.19 >>>>> >>>>> ====== >>>>> [root at ipareplica ~]# nslookup ipasrv >>>>> Server: 10.30.160.19 >>>>> Address: 10.30.160.19#53 >>>>> >>>>> Name: ipasrv >>>>> Address: 10.30.160.19 >>>>> >>>>> ======== >>>>> [root at ipasrv ~]# nslookup ipareplica >>>>> Server: 127.0.0.1 >>>>> Address: 127.0.0.1#53 >>>>> >>>>> Name: ipareplica >>>>> Address: 10.30.160.20 >>>>> ========= >>>> >>>> Ok, so ssh is running, you can log in with root. I think that by 99% >>>> chance, >>>> your SSSD service is not running on the IPA server. Please check if this >>>> is the >>>> case and if yes, please try to (re)start it. If that helped, it would be >>>> also >>>> useful to see *why* the SSSD is not running (crash, misconfiguration, >> ...) >>>> >>>> Martin >>>> >>> >>> >>> >> >> > From baghery.jone at gmail.com Mon Feb 9 13:34:52 2015 From: baghery.jone at gmail.com (alireza baghery) Date: Mon, 9 Feb 2015 17:04:52 +0330 Subject: [Freeipa-users] error install replication In-Reply-To: <54D89EF1.3030401@redhat.com> References: <54D7565F.2030203@redhat.com> <54D768BC.7050602@redhat.com> <54D86685.8010106@redhat.com> <54D88816.9060904@redhat.com> <54D89EF1.3030401@redhat.com> Message-ID: yes try "ssh admin at hostname" but do not work ====log secure-==== Feb 9 15:42:20 ipasrv sshd[13414]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.30.160.20 user=admin Feb 9 15:42:20 ipasrv sshd[13414]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.30.160.20 user=admin Feb 9 15:42:20 ipasrv sshd[13414]: pam_sss(sshd:account): Access denied for user admin: 6 (Permission denied) Feb 9 15:42:20 ipasrv sshd[13414]: Failed password for admin from 10.30.160.20 port 52123 ssh2 Feb 9 15:42:20 ipasrv sshd[13415]: fatal: Access denied for user admin by PAM account configuration On Mon, Feb 9, 2015 at 3:20 PM, Martin Kosek wrote: > Did you try the "ssh admin@`hostname`" command? It should show if ssh to > admin > via SSSD&FreeIPA really works. > > On 02/09/2015 11:18 AM, alireza baghery wrote: > > account admin recognize and show uid gid and groups > > On Feb 9, 2015 1:42 PM, "Martin Kosek" wrote: > > > >> Ok. When on the server, does > >> > >> # id admin > >> > >> or "ssh admin@`hostname`" work? Maybe it does not recognize the admin > >> user. > >> > >> On 02/09/2015 09:29 AM, alireza baghery wrote: > >>> ipasrv# Service SSSD status > >>> sssd is runing > >>> nevertheless i restart service sssd > >>> but problem do not solved > >>> > >>> On Mon, Feb 9, 2015 at 11:19 AM, Martin Kosek > wrote: > >>> > >>>> On 02/09/2015 07:42 AM, alireza baghery wrote: > >>>>> i check on both server ssh each other's name and ssh successful and > >>>> resolve > >>>>> name was also correct on each server > >>>>> but i can not login with user admin from ipareplica via ssh > >>>> (root at ipareplica]# > >>>>> ssh admin at ipasrv ===> failed) > >>>>> > >>>>> [root at ipareplica ~]# ssh ipasrv > >>>>> root at ipasrv's password: > >>>>> Last login: Mon Feb 9 09:49:54 2015 from 10.30.160.20 > >>>>> =====log /var/secure==== > >>>>> Feb 9 09:50:29 ipasrv sshd[12076]: Accepted password for root from > >>>>> 10.30.160.20 port 52110 ssh2 > >>>>> Feb 9 09:50:29 ipasrv sshd[12076]: pam_unix(sshd:session): session > >>>> opened > >>>>> for user root by (uid=0) > >>>>> ===== > >>>>> [root at ipasrv ~]# ssh ipareplica > >>>>> root at ipareplica's password: > >>>>> Last login: Mon Feb 9 09:50:20 2015 from 10.30.160.19 > >>>>> > >>>>> ====== > >>>>> [root at ipareplica ~]# nslookup ipasrv > >>>>> Server: 10.30.160.19 > >>>>> Address: 10.30.160.19#53 > >>>>> > >>>>> Name: ipasrv > >>>>> Address: 10.30.160.19 > >>>>> > >>>>> ======== > >>>>> [root at ipasrv ~]# nslookup ipareplica > >>>>> Server: 127.0.0.1 > >>>>> Address: 127.0.0.1#53 > >>>>> > >>>>> Name: ipareplica > >>>>> Address: 10.30.160.20 > >>>>> ========= > >>>> > >>>> Ok, so ssh is running, you can log in with root. I think that by 99% > >>>> chance, > >>>> your SSSD service is not running on the IPA server. Please check if > this > >>>> is the > >>>> case and if yes, please try to (re)start it. If that helped, it would > be > >>>> also > >>>> useful to see *why* the SSSD is not running (crash, misconfiguration, > >> ...) > >>>> > >>>> Martin > >>>> > >>> > >>> > >>> > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmohler at oberlin.edu Fri Feb 6 23:27:26 2015 From: cmohler at oberlin.edu (Chris Mohler) Date: Fri, 06 Feb 2015 18:27:26 -0500 Subject: [Freeipa-users] Upgrade from 3x to 4x cant create first replica. Message-ID: <54D54DDE.5040902@oberlin.edu> I'm having some troubles. I have an older IPA install Version 3.0.0. on Centos 6.6. It's currently the only master for my domain. I have about 4k user accounts on here and it's a live system called "idm" I'm trying to upgrade to V4.x as I am hoping to fix some issues I am having. (clients can't auth unless service sssd is restarted multiple times "10 (User not known to the underlying authentication module") I think this is possibly unrelated and the topic for another thread. I created a new VM and installed Fedora Server 21 and FreeIPA 4.1.2 it's called "ipa" on the master "idm" I ran "ipa-replica-prepare" and transfered the file to the future replica "ipa" Then I ran the install replica script ipa-replica-install --setup-ca /home/svradm/replica-info-ipa.cs.oberlin.edu.gpg Things went well until it failed [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 133 seconds elapsed Update in progress yet not in progress Update in progress yet not in progress Update in progress yet not in progress [idm.cs.oberlin.edu] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Please help I'm getting nowhere by myself. Thanks, -Chris Attached and below are some relevant logs I hope. ipareplica-install.log - is the replica install log errors is the dirsrv error log -IPA replica install log- > 2015-02-06T22:08:28Z DEBUG /sbin/ipa-replica-install was invoked with > argument "/home/svradm/replica-info-ipa.cs.oberlin.edu.gpg" and > options: {'no_forwarders': False, 'conf_ssh': True, > 'skip_schema_check': False, 'ui_redirect': True, 'trust_sshfp': False, > 'unattended': False, 'ip_addresses': [], 'setup_pkinit': True, > 'no_host_dns': False, 'mkhomedir': False, 'no_reverse': False, > 'setup_dns': False, 'no_dnssec_validation': False, 'conf_sshd': True, > 'forwarders': None, 'debug': False, 'conf_ntp': True, 'setup_ca': > True, 'reverse_zones': [], 'skip_conncheck': False, 'create_sshfp': True} > 2015-02-06T22:08:28Z DEBUG IPA version 4.1.2-1.fc21 > 2015-02-06T22:08:28Z DEBUG Loading Index file from > '/var/lib/ipa-client/sysrestore/sysrestore.index' > 2015-02-06T22:08:28Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-02-06T22:08:28Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-02-06T22:08:28Z DEBUG Starting external process > 2015-02-06T22:08:28Z DEBUG args='/usr/sbin/httpd' '-t' '-D' 'DUMP_VHOSTS' > 2015-02-06T22:08:28Z DEBUG Process finished, return code=0 > 2015-02-06T22:08:28Z DEBUG stdout=VirtualHost configuration: > *:8443 ipa.cs.oberlin.edu (/etc/httpd/conf.d/nss.conf:83) > > 2015-02-06T22:08:28Z DEBUG stderr= > 2015-02-06T22:08:28Z DEBUG Starting external process > 2015-02-06T22:08:28Z DEBUG args='/bin/systemctl' 'is-enabled' > 'chronyd.service' > 2015-02-06T22:08:28Z DEBUG Process finished, return code=1 > 2015-02-06T22:08:28Z DEBUG stdout= > 2015-02-06T22:08:28Z DEBUG stderr=Failed to get unit file state for > chronyd.service: No such file or directory > > 2015-02-06T22:08:28Z DEBUG Starting external process > 2015-02-06T22:08:28Z DEBUG args='/bin/systemctl' 'is-active' > 'chronyd.service' > 2015-02-06T22:08:29Z DEBUG Process finished, return code=3 > 2015-02-06T22:08:29Z DEBUG stdout=unknown > > 2015-02-06T22:08:29Z DEBUG stderr= > 2015-02-06T22:08:37Z DEBUG Starting external process > 2015-02-06T22:08:37Z DEBUG args='/usr/bin/gpg-agent' '--batch' > '--homedir' '/tmp/tmpzmYHXxipa/ipa-sy2uJe/.gnupg' '--daemon' > '/usr/bin/gpg' '--batch' '--homedir' > '/tmp/tmpzmYHXxipa/ipa-sy2uJe/.gnupg' '--passphrase-fd' '0' '--yes' > '--no-tty' '-o' '/tmp/tmpzmYHXxipa/files.tar' '-d' > '/home/svradm/replica-info-ipa.cs.oberlin.edu.gpg' > 2015-02-06T22:08:38Z DEBUG Process finished, return code=0 > 2015-02-06T22:08:38Z DEBUG Starting external process > 2015-02-06T22:08:38Z DEBUG args='tar' 'xf' > '/tmp/tmpzmYHXxipa/files.tar' '-C' '/tmp/tmpzmYHXxipa' > 2015-02-06T22:08:38Z DEBUG Process finished, return code=0 > 2015-02-06T22:08:38Z DEBUG stdout= > 2015-02-06T22:08:38Z DEBUG stderr= > 2015-02-06T22:08:38Z DEBUG Installing replica file with version 300 (0 > means no version in prepared file). > 2015-02-06T22:08:38Z DEBUG Check if ipa.cs.oberlin.edu is a primary > hostname for localhost > 2015-02-06T22:08:38Z DEBUG Primary hostname for localhost: > ipa.cs.oberlin.edu > 2015-02-06T22:08:38Z DEBUG Search DNS for ipa.cs.oberlin.edu > 2015-02-06T22:08:38Z DEBUG Check if ipa.cs.oberlin.edu is not a CNAME > 2015-02-06T22:08:38Z DEBUG Check reverse address of 132.162.201.65 > 2015-02-06T22:08:38Z DEBUG Found reverse name: ipa.cs.oberlin.edu > 2015-02-06T22:08:38Z DEBUG Check if idm.cs.oberlin.edu is a primary > hostname for localhost > 2015-02-06T22:08:38Z DEBUG Primary hostname for localhost: > idm.cs.oberlin.edu > 2015-02-06T22:08:38Z DEBUG Search DNS for idm.cs.oberlin.edu > 2015-02-06T22:08:38Z DEBUG Check if idm.cs.oberlin.edu is not a CNAME > 2015-02-06T22:08:38Z DEBUG Check reverse address of 132.162.201.73 > 2015-02-06T22:08:38Z DEBUG Found reverse name: idm.cs.oberlin.edu > 2015-02-06T22:08:38Z DEBUG Starting external process > 2015-02-06T22:08:38Z DEBUG args='/usr/sbin/ipa-replica-conncheck' > '--master' 'idm.cs.oberlin.edu' '--auto-master-check' '--realm' > 'CS.OBERLIN.EDU' '--principal' 'admin' '--hostname' > 'ipa.cs.oberlin.edu' '--check-ca' > 2015-02-06T22:09:03Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:03Z DEBUG Starting external process > 2015-02-06T22:09:03Z DEBUG args='/sbin/ip' '-family' 'inet' '-oneline' > 'address' 'show' > 2015-02-06T22:09:03Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:03Z DEBUG stdout=1: lo inet 127.0.0.1/8 scope host > lo\ valid_lft forever preferred_lft forever > 2: eth0 inet 132.162.201.65/24 brd 132.162.201.255 scope global > dynamic eth0\ valid_lft 842351sec preferred_lft 842351sec > > 2015-02-06T22:09:03Z DEBUG stderr= > 2015-02-06T22:09:03Z DEBUG importing all plugin modules in > '/usr/lib/python2.7/site-packages/ipalib/plugins'... > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/config.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/group.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/host.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hostgroup.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/idrange.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/idviews.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/krbtpolicy.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/misc.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/netgroup.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken_yubikey.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py' > 2015-02-06T22:09:03Z DEBUG Starting external process > 2015-02-06T22:09:03Z DEBUG args='klist' '-V' > 2015-02-06T22:09:03Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:03Z DEBUG stdout=Kerberos 5 version 1.12.2 > > 2015-02-06T22:09:03Z DEBUG stderr= > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/radiusproxy.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/role.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/rpcclient.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/service.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/user.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py' > 2015-02-06T22:09:03Z DEBUG importing all plugin modules in > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins'... > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/adtrust.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/baseupdate.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/ca_renewal_master.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/fix_replica_agreements.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/rename_managed.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_idranges.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_pacs.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_referint.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_services.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_uniqueness.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' > 2015-02-06T22:09:03Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' > 2015-02-06T22:09:04Z DEBUG group dirsrv exists > 2015-02-06T22:09:04Z DEBUG user dirsrv exists > 2015-02-06T22:09:04Z DEBUG Created connection > context.ldap2_140649775824016 > 2015-02-06T22:09:04Z DEBUG flushing ldaps://idm.cs.oberlin.edu from > SchemaCache > 2015-02-06T22:09:04Z DEBUG retrieving schema for SchemaCache > url=ldaps://idm.cs.oberlin.edu conn= instance at 0x7feb93ece830> > 2015-02-06T22:09:04Z DEBUG Created connection context.ldap2 > 2015-02-06T22:09:04Z DEBUG flushing ldaps://idm.cs.oberlin.edu from > SchemaCache > 2015-02-06T22:09:04Z DEBUG retrieving schema for SchemaCache > url=ldaps://idm.cs.oberlin.edu conn= instance at 0x7feb937a7368> > 2015-02-06T22:09:04Z DEBUG Destroyed connection context.ldap2 > 2015-02-06T22:09:04Z DEBUG No IPA DNS servers, skipping > forward/reverse resolution check > 2015-02-06T22:09:04Z DEBUG Destroyed connection > context.ldap2_140649775824016 > 2015-02-06T22:09:04Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-02-06T22:09:04Z DEBUG Checking if IPA schema is present in > ldap://idm.cs.oberlin.edu:7389 > 2015-02-06T22:09:04Z DEBUG retrieving schema for SchemaCache > url=ldap://idm.cs.oberlin.edu:7389 > conn= > 2015-02-06T22:09:05Z DEBUG Check OK > 2015-02-06T22:09:05Z DEBUG Starting external process > 2015-02-06T22:09:05Z DEBUG args='/bin/systemctl' 'is-enabled' > 'chronyd.service' > 2015-02-06T22:09:05Z DEBUG Process finished, return code=1 > 2015-02-06T22:09:05Z DEBUG stdout= > 2015-02-06T22:09:05Z DEBUG stderr=Failed to get unit file state for > chronyd.service: No such file or directory > > 2015-02-06T22:09:05Z DEBUG Starting external process > 2015-02-06T22:09:05Z DEBUG args='/bin/systemctl' 'is-active' > 'chronyd.service' > 2015-02-06T22:09:05Z DEBUG Process finished, return code=3 > 2015-02-06T22:09:05Z DEBUG stdout=unknown > > 2015-02-06T22:09:05Z DEBUG stderr= > 2015-02-06T22:09:05Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-02-06T22:09:05Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-02-06T22:09:05Z DEBUG Configuring NTP daemon (ntpd) > 2015-02-06T22:09:05Z DEBUG [1/4]: stopping ntpd > 2015-02-06T22:09:05Z DEBUG Starting external process > 2015-02-06T22:09:05Z DEBUG args='/bin/systemctl' 'is-active' > 'ntpd.service' > 2015-02-06T22:09:05Z DEBUG Process finished, return code=3 > 2015-02-06T22:09:05Z DEBUG stdout=unknown > > 2015-02-06T22:09:05Z DEBUG stderr= > 2015-02-06T22:09:05Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-02-06T22:09:05Z DEBUG Starting external process > 2015-02-06T22:09:05Z DEBUG args='/bin/systemctl' 'stop' 'ntpd.service' > 2015-02-06T22:09:05Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:05Z DEBUG stdout= > 2015-02-06T22:09:05Z DEBUG stderr= > 2015-02-06T22:09:05Z DEBUG duration: 0 seconds > 2015-02-06T22:09:05Z DEBUG [2/4]: writing configuration > 2015-02-06T22:09:05Z DEBUG Backing up system configuration file > '/etc/ntp.conf' > 2015-02-06T22:09:05Z DEBUG Saving Index File to > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-02-06T22:09:05Z DEBUG Backing up system configuration file > '/etc/sysconfig/ntpd' > 2015-02-06T22:09:05Z DEBUG Saving Index File to > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-02-06T22:09:05Z DEBUG duration: 0 seconds > 2015-02-06T22:09:05Z DEBUG [3/4]: configuring ntpd to start on boot > 2015-02-06T22:09:05Z DEBUG Starting external process > 2015-02-06T22:09:05Z DEBUG args='/bin/systemctl' 'is-enabled' > 'ntpd.service' > 2015-02-06T22:09:05Z DEBUG Process finished, return code=1 > 2015-02-06T22:09:05Z DEBUG stdout=disabled > > 2015-02-06T22:09:05Z DEBUG stderr= > 2015-02-06T22:09:05Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-02-06T22:09:05Z DEBUG Starting external process > 2015-02-06T22:09:05Z DEBUG args='/bin/systemctl' 'enable' 'ntpd.service' > 2015-02-06T22:09:05Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:05Z DEBUG stdout= > 2015-02-06T22:09:05Z DEBUG stderr=Created symlink from > /etc/systemd/system/multi-user.target.wants/ntpd.service to > /usr/lib/systemd/system/ntpd.service. > > 2015-02-06T22:09:05Z DEBUG duration: 0 seconds > 2015-02-06T22:09:05Z DEBUG [4/4]: starting ntpd > 2015-02-06T22:09:05Z DEBUG Starting external process > 2015-02-06T22:09:05Z DEBUG args='/bin/systemctl' 'start' 'ntpd.service' > 2015-02-06T22:09:05Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:05Z DEBUG stdout= > 2015-02-06T22:09:05Z DEBUG stderr= > 2015-02-06T22:09:05Z DEBUG Starting external process > 2015-02-06T22:09:05Z DEBUG args='/bin/systemctl' 'is-active' > 'ntpd.service' > 2015-02-06T22:09:05Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:05Z DEBUG stdout=active > > 2015-02-06T22:09:05Z DEBUG stderr= > 2015-02-06T22:09:05Z DEBUG duration: 0 seconds > 2015-02-06T22:09:05Z DEBUG Done configuring NTP daemon (ntpd). > 2015-02-06T22:09:05Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-02-06T22:09:05Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-02-06T22:09:05Z DEBUG Configuring directory server (dirsrv): > Estimated time 1 minute > 2015-02-06T22:09:05Z DEBUG [1/35]: creating directory server user > 2015-02-06T22:09:05Z DEBUG group dirsrv exists > 2015-02-06T22:09:05Z DEBUG user dirsrv exists > 2015-02-06T22:09:05Z DEBUG duration: 0 seconds > 2015-02-06T22:09:05Z DEBUG [2/35]: creating directory server instance > 2015-02-06T22:09:05Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-02-06T22:09:05Z DEBUG Backing up system configuration file > '/etc/sysconfig/dirsrv' > 2015-02-06T22:09:05Z DEBUG Saving Index File to > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-02-06T22:09:05Z DEBUG > dn: dc=cs,dc=oberlin,dc=edu > objectClass: top > objectClass: domain > objectClass: pilotObject > dc: cs > info: IPA V2.0 > > 2015-02-06T22:09:05Z DEBUG writing inf template > 2015-02-06T22:09:05Z DEBUG > [General] > FullMachineName= ipa.cs.oberlin.edu > SuiteSpotUserID= dirsrv > SuiteSpotGroup= dirsrv > ServerRoot= /usr/lib64/dirsrv > [slapd] > ServerPort= 389 > ServerIdentifier= CS-OBERLIN-EDU > Suffix= dc=cs,dc=oberlin,dc=edu > RootDN= cn=Directory Manager > InstallLdifFile= /var/lib/dirsrv/boot.ldif > inst_dir= /var/lib/dirsrv/scripts-CS-OBERLIN-EDU > > 2015-02-06T22:09:05Z DEBUG calling setup-ds.pl > 2015-02-06T22:09:05Z DEBUG Starting external process > 2015-02-06T22:09:05Z DEBUG args='/usr/sbin/setup-ds.pl' '--silent' > '--logfile' '-' '-f' '/tmp/tmpGMb2Tk' > 2015-02-06T22:09:09Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:09Z DEBUG stdout=[15/02/06:17:09:09] - [Setup] Info > Your new DS instance 'CS-OBERLIN-EDU' was successfully created. > Your new DS instance 'CS-OBERLIN-EDU' was successfully created. > [15/02/06:17:09:09] - [Setup] Success Exiting . . . > Log file is '-' > > Exiting . . . > Log file is '-' > > > 2015-02-06T22:09:09Z DEBUG stderr= > 2015-02-06T22:09:09Z DEBUG completed creating ds instance > 2015-02-06T22:09:09Z DEBUG restarting ds instance > 2015-02-06T22:09:09Z DEBUG Starting external process > 2015-02-06T22:09:09Z DEBUG args='/bin/systemctl' '--system' > 'daemon-reload' > 2015-02-06T22:09:09Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:09Z DEBUG stdout= > 2015-02-06T22:09:09Z DEBUG stderr= > 2015-02-06T22:09:09Z DEBUG Starting external process > 2015-02-06T22:09:09Z DEBUG args='/bin/systemctl' 'restart' > 'dirsrv at CS-OBERLIN-EDU.service' > 2015-02-06T22:09:09Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:09Z DEBUG stdout= > 2015-02-06T22:09:09Z DEBUG stderr= > 2015-02-06T22:09:09Z DEBUG Starting external process > 2015-02-06T22:09:09Z DEBUG args='/bin/systemctl' 'is-active' > 'dirsrv at CS-OBERLIN-EDU.service' > 2015-02-06T22:09:09Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:09Z DEBUG stdout=active > > 2015-02-06T22:09:09Z DEBUG stderr= > 2015-02-06T22:09:09Z DEBUG wait_for_open_ports: localhost [389] > timeout 300 > 2015-02-06T22:09:11Z DEBUG Starting external process > 2015-02-06T22:09:11Z DEBUG args='/bin/systemctl' 'is-active' > 'dirsrv at CS-OBERLIN-EDU.service' > 2015-02-06T22:09:11Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:11Z DEBUG stdout=active > > 2015-02-06T22:09:11Z DEBUG stderr= > 2015-02-06T22:09:11Z DEBUG done restarting ds instance > 2015-02-06T22:09:11Z DEBUG duration: 6 seconds > 2015-02-06T22:09:11Z DEBUG [3/35]: adding default schema > 2015-02-06T22:09:11Z DEBUG duration: 0 seconds > 2015-02-06T22:09:11Z DEBUG [4/35]: enabling memberof plugin > 2015-02-06T22:09:11Z DEBUG Starting external process > 2015-02-06T22:09:11Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/usr/share/ipa/memberof-conf.ldif' '-H' > 'ldap://ipa.cs.oberlin.edu:389' '-x' '-D' 'cn=Directory Manager' '-y' > '/tmp/tmpyB3DDP' > 2015-02-06T22:09:11Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:11Z DEBUG stdout=replace nsslapd-pluginenabled: > on > add memberofgroupattr: > memberUser > add memberofgroupattr: > memberHost > modifying entry "cn=MemberOf Plugin,cn=plugins,cn=config" > modify complete > > > 2015-02-06T22:09:11Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:11Z DEBUG duration: 0 seconds > 2015-02-06T22:09:11Z DEBUG [5/35]: enabling winsync plugin > 2015-02-06T22:09:11Z DEBUG Starting external process > 2015-02-06T22:09:11Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/usr/share/ipa/ipa-winsync-conf.ldif' '-H' > 'ldap://ipa.cs.oberlin.edu:389' '-x' '-D' 'cn=Directory Manager' '-y' > '/tmp/tmpvjCszA' > 2015-02-06T22:09:11Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:11Z DEBUG stdout=add objectclass: > top > nsSlapdPlugin > extensibleObject > add cn: > ipa-winsync > add nsslapd-pluginpath: > libipa_winsync > add nsslapd-plugininitfunc: > ipa_winsync_plugin_init > add nsslapd-pluginDescription: > Allows IPA to work with the DS windows sync feature > add nsslapd-pluginid: > ipa-winsync > add nsslapd-pluginversion: > 1.0 > add nsslapd-pluginvendor: > Red Hat > add nsslapd-plugintype: > preoperation > add nsslapd-pluginenabled: > on > add nsslapd-plugin-depends-on-type: > database > add ipaWinSyncRealmFilter: > (objectclass=krbRealmContainer) > add ipaWinSyncRealmAttr: > cn > add ipaWinSyncNewEntryFilter: > (cn=ipaConfig) > add ipaWinSyncNewUserOCAttr: > ipauserobjectclasses > add ipaWinSyncUserFlatten: > true > add ipaWinsyncHomeDirAttr: > ipaHomesRootDir > add ipaWinsyncLoginShellAttr: > ipaDefaultLoginShell > add ipaWinSyncDefaultGroupAttr: > ipaDefaultPrimaryGroup > add ipaWinSyncDefaultGroupFilter: > (gidNumber=*)(objectclass=posixGroup)(objectclass=groupOfNames) > add ipaWinSyncAcctDisable: > both > add ipaWinSyncForceSync: > true > add ipaWinSyncUserAttr: > uidNumber -1 > gidNumber -1 > adding new entry "cn=ipa-winsync,cn=plugins,cn=config" > modify complete > > > 2015-02-06T22:09:11Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:11Z DEBUG duration: 0 seconds > 2015-02-06T22:09:11Z DEBUG [6/35]: configuring replication version > plugin > 2015-02-06T22:09:11Z DEBUG Starting external process > 2015-02-06T22:09:11Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/usr/share/ipa/version-conf.ldif' '-H' > 'ldap://ipa.cs.oberlin.edu:389' '-x' '-D' 'cn=Directory Manager' '-y' > '/tmp/tmp9q4t0H' > 2015-02-06T22:09:11Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:11Z DEBUG stdout=add objectclass: > top > nsSlapdPlugin > extensibleObject > add cn: > IPA Version Replication > add nsslapd-pluginpath: > libipa_repl_version > add nsslapd-plugininitfunc: > repl_version_plugin_init > add nsslapd-plugintype: > preoperation > add nsslapd-pluginenabled: > off > add nsslapd-pluginid: > ipa_repl_version > add nsslapd-pluginversion: > 1.0 > add nsslapd-pluginvendor: > Red Hat, Inc. > add nsslapd-plugindescription: > IPA Replication version plugin > add nsslapd-plugin-depends-on-type: > database > add nsslapd-plugin-depends-on-named: > Multimaster Replication Plugin > adding new entry "cn=IPA Version Replication,cn=plugins,cn=config" > modify complete > > > 2015-02-06T22:09:11Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:11Z DEBUG duration: 0 seconds > 2015-02-06T22:09:11Z DEBUG [7/35]: enabling IPA enrollment plugin > 2015-02-06T22:09:11Z DEBUG Starting external process > 2015-02-06T22:09:11Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/tmp/tmplWOYWQ' '-H' 'ldap://ipa.cs.oberlin.edu:389' '-x' '-D' > 'cn=Directory Manager' '-y' '/tmp/tmplhf7bh' > 2015-02-06T22:09:11Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:11Z DEBUG stdout=add objectclass: > top > nsSlapdPlugin > extensibleObject > add cn: > ipa_enrollment_extop > add nsslapd-pluginpath: > libipa_enrollment_extop > add nsslapd-plugininitfunc: > ipaenrollment_init > add nsslapd-plugintype: > extendedop > add nsslapd-pluginenabled: > on > add nsslapd-pluginid: > ipa_enrollment_extop > add nsslapd-pluginversion: > 1.0 > add nsslapd-pluginvendor: > RedHat > add nsslapd-plugindescription: > Enroll hosts into the IPA domain > add nsslapd-plugin-depends-on-type: > database > add nsslapd-realmTree: > dc=cs,dc=oberlin,dc=edu > adding new entry "cn=ipa_enrollment_extop,cn=plugins,cn=config" > modify complete > > > 2015-02-06T22:09:11Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:11Z DEBUG duration: 0 seconds > 2015-02-06T22:09:11Z DEBUG [8/35]: enabling ldapi > 2015-02-06T22:09:11Z DEBUG Starting external process > 2015-02-06T22:09:11Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/tmp/tmpUre1PI' '-H' 'ldap://ipa.cs.oberlin.edu:389' '-x' '-D' > 'cn=Directory Manager' '-y' '/tmp/tmpQasEep' > 2015-02-06T22:09:11Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:11Z DEBUG stdout=replace nsslapd-ldapilisten: > on > modifying entry "cn=config" > modify complete > > > 2015-02-06T22:09:11Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:11Z DEBUG duration: 0 seconds > 2015-02-06T22:09:11Z DEBUG [9/35]: configuring uniqueness plugin > 2015-02-06T22:09:11Z DEBUG Starting external process > 2015-02-06T22:09:11Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/tmp/tmps9ltjb' '-H' 'ldap://ipa.cs.oberlin.edu:389' '-x' '-D' > 'cn=Directory Manager' '-y' '/tmp/tmpkT9Aql' > 2015-02-06T22:09:11Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:11Z DEBUG stdout=add objectClass: > top > nsSlapdPlugin > extensibleObject > add cn: > krbPrincipalName uniqueness > add nsslapd-pluginPath: > libattr-unique-plugin > add nsslapd-pluginInitfunc: > NSUniqueAttr_Init > add nsslapd-pluginType: > preoperation > add nsslapd-pluginEnabled: > on > add nsslapd-pluginarg0: > krbPrincipalName > add nsslapd-pluginarg1: > dc=cs,dc=oberlin,dc=edu > add nsslapd-plugin-depends-on-type: > database > add nsslapd-pluginId: > NSUniqueAttr > add nsslapd-pluginVersion: > 1.1.0 > add nsslapd-pluginVendor: > Fedora Project > add nsslapd-pluginDescription: > Enforce unique attribute values > adding new entry "cn=krbPrincipalName uniqueness,cn=plugins,cn=config" > modify complete > > add objectClass: > top > nsSlapdPlugin > extensibleObject > add cn: > krbCanonicalName uniqueness > add nsslapd-pluginPath: > libattr-unique-plugin > add nsslapd-pluginInitfunc: > NSUniqueAttr_Init > add nsslapd-pluginType: > preoperation > add nsslapd-pluginEnabled: > on > add nsslapd-pluginarg0: > krbCanonicalName > add nsslapd-pluginarg1: > dc=cs,dc=oberlin,dc=edu > add nsslapd-plugin-depends-on-type: > database > add nsslapd-pluginId: > NSUniqueAttr > add nsslapd-pluginVersion: > 1.1.0 > add nsslapd-pluginVendor: > Fedora Project > add nsslapd-pluginDescription: > Enforce unique attribute values > adding new entry "cn=krbCanonicalName uniqueness,cn=plugins,cn=config" > modify complete > > add objectClass: > top > nsSlapdPlugin > extensibleObject > add cn: > netgroup uniqueness > add nsslapd-pluginPath: > libattr-unique-plugin > add nsslapd-pluginInitfunc: > NSUniqueAttr_Init > add nsslapd-pluginType: > preoperation > add nsslapd-pluginEnabled: > on > add nsslapd-pluginarg0: > cn > add nsslapd-pluginarg1: > cn=ng,cn=alt,dc=cs,dc=oberlin,dc=edu > add nsslapd-plugin-depends-on-type: > database > add nsslapd-pluginId: > NSUniqueAttr > add nsslapd-pluginVersion: > 1.1.0 > add nsslapd-pluginVendor: > Fedora Project > add nsslapd-pluginDescription: > Enforce unique attribute values > adding new entry "cn=netgroup uniqueness,cn=plugins,cn=config" > modify complete > > add objectClass: > top > nsSlapdPlugin > extensibleObject > add cn: > ipaUniqueID uniqueness > add nsslapd-pluginPath: > libattr-unique-plugin > add nsslapd-pluginInitfunc: > NSUniqueAttr_Init > add nsslapd-pluginType: > preoperation > add nsslapd-pluginEnabled: > on > add nsslapd-pluginarg0: > ipaUniqueID > add nsslapd-pluginarg1: > dc=cs,dc=oberlin,dc=edu > add nsslapd-plugin-depends-on-type: > database > add nsslapd-pluginId: > NSUniqueAttr > add nsslapd-pluginVersion: > 1.1.0 > add nsslapd-pluginVendor: > Fedora Project > add nsslapd-pluginDescription: > Enforce unique attribute values > adding new entry "cn=ipaUniqueID uniqueness,cn=plugins,cn=config" > modify complete > > add objectClass: > top > nsSlapdPlugin > extensibleObject > add cn: > sudorule name uniqueness > add nsslapd-pluginDescription: > Enforce unique attribute values > add nsslapd-pluginPath: > libattr-unique-plugin > add nsslapd-pluginInitfunc: > NSUniqueAttr_Init > add nsslapd-pluginType: > preoperation > add nsslapd-pluginEnabled: > on > add nsslapd-pluginarg0: > cn > add nsslapd-pluginarg1: > cn=sudorules,cn=sudo,dc=cs,dc=oberlin,dc=edu > add nsslapd-plugin-depends-on-type: > database > add nsslapd-pluginId: > NSUniqueAttr > add nsslapd-pluginVersion: > 1.1.0 > add nsslapd-pluginVendor: > Fedora Project > adding new entry "cn=sudorule name uniqueness,cn=plugins,cn=config" > modify complete > > > 2015-02-06T22:09:11Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:11Z DEBUG duration: 0 seconds > 2015-02-06T22:09:11Z DEBUG [10/35]: configuring uuid plugin > 2015-02-06T22:09:11Z DEBUG Starting external process > 2015-02-06T22:09:11Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/usr/share/ipa/uuid-conf.ldif' '-H' 'ldap://ipa.cs.oberlin.edu:389' > '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpp9Iniz' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout=add objectclass: > top > nsSlapdPlugin > extensibleObject > add cn: > IPA UUID > add nsslapd-pluginpath: > libipa_uuid > add nsslapd-plugininitfunc: > ipauuid_init > add nsslapd-plugintype: > preoperation > add nsslapd-pluginenabled: > on > add nsslapd-pluginid: > ipauuid_version > add nsslapd-pluginversion: > 1.0 > add nsslapd-pluginvendor: > Red Hat, Inc. > add nsslapd-plugindescription: > IPA UUID plugin > add nsslapd-plugin-depends-on-type: > database > adding new entry "cn=IPA UUID,cn=plugins,cn=config" > modify complete > > > 2015-02-06T22:09:12Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/tmp/tmpNODjOh' '-H' 'ldap://ipa.cs.oberlin.edu:389' '-x' '-D' > 'cn=Directory Manager' '-y' '/tmp/tmpVdYknN' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout=add objectclass: > top > extensibleObject > add cn: > IPA Unique IDs > add ipaUuidAttr: > ipaUniqueID > add ipaUuidMagicRegen: > autogenerate > add ipaUuidFilter: > (|(objectclass=ipaObject)(objectclass=ipaAssociation)) > add ipaUuidScope: > dc=cs,dc=oberlin,dc=edu > add ipaUuidEnforce: > TRUE > adding new entry "cn=IPA Unique IDs,cn=IPA UUID,cn=plugins,cn=config" > modify complete > > add objectclass: > top > extensibleObject > add cn: > IPK11 Unique IDs > add ipaUuidAttr: > ipk11UniqueID > add ipaUuidMagicRegen: > autogenerate > add ipaUuidFilter: > (objectclass=ipk11Object) > add ipaUuidScope: > dc=cs,dc=oberlin,dc=edu > add ipaUuidEnforce: > FALSE > adding new entry "cn=IPK11 Unique IDs,cn=IPA UUID,cn=plugins,cn=config" > modify complete > > > 2015-02-06T22:09:12Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:12Z DEBUG duration: 0 seconds > 2015-02-06T22:09:12Z DEBUG [11/35]: configuring modrdn plugin > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/usr/share/ipa/modrdn-conf.ldif' '-H' 'ldap://ipa.cs.oberlin.edu:389' > '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpBmZRfj' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout=add objectclass: > top > nsSlapdPlugin > extensibleObject > add cn: > IPA MODRDN > add nsslapd-pluginpath: > libipa_modrdn > add nsslapd-plugininitfunc: > ipamodrdn_init > add nsslapd-plugintype: > betxnpostoperation > add nsslapd-pluginenabled: > on > add nsslapd-pluginid: > ipamodrdn_version > add nsslapd-pluginversion: > 1.0 > add nsslapd-pluginvendor: > Red Hat, Inc. > add nsslapd-plugindescription: > IPA MODRDN plugin > add nsslapd-plugin-depends-on-type: > database > add nsslapd-pluginPrecedence: > 60 > adding new entry "cn=IPA MODRDN,cn=plugins,cn=config" > modify complete > > > 2015-02-06T22:09:12Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/tmp/tmphvemrG' '-H' 'ldap://ipa.cs.oberlin.edu:389' '-x' '-D' > 'cn=Directory Manager' '-y' '/tmp/tmp_waPJ6' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout=add objectclass: > top > extensibleObject > add cn: > Kerberos Principal Name > add ipaModRDNsourceAttr: > uid > add ipaModRDNtargetAttr: > krbPrincipalName > add ipaModRDNsuffix: > @CS.OBERLIN.EDU > add ipaModRDNfilter: > (&(objectclass=posixaccount)(objectclass=krbPrincipalAux)) > add ipaModRDNscope: > dc=cs,dc=oberlin,dc=edu > adding new entry "cn=Kerberos Principal Name,cn=IPA > MODRDN,cn=plugins,cn=config" > modify complete > > > 2015-02-06T22:09:12Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:12Z DEBUG duration: 0 seconds > 2015-02-06T22:09:12Z DEBUG [12/35]: configuring DNS plugin > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/usr/share/ipa/ipa-dns-conf.ldif' '-H' > 'ldap://ipa.cs.oberlin.edu:389' '-x' '-D' 'cn=Directory Manager' '-y' > '/tmp/tmpmaaDmQ' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout=add objectclass: > top > nsslapdPlugin > extensibleObject > add cn: > IPA DNS > add nsslapd-plugindescription: > IPA DNS support plugin > add nsslapd-pluginenabled: > on > add nsslapd-pluginid: > ipa_dns > add nsslapd-plugininitfunc: > ipadns_init > add nsslapd-pluginpath: > libipa_dns.so > add nsslapd-plugintype: > preoperation > add nsslapd-pluginvendor: > Red Hat, Inc. > add nsslapd-pluginversion: > 1.0 > add nsslapd-plugin-depends-on-type: > database > adding new entry "cn=IPA DNS,cn=plugins,cn=config" > modify complete > > > 2015-02-06T22:09:12Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:12Z DEBUG duration: 0 seconds > 2015-02-06T22:09:12Z DEBUG [13/35]: enabling entryUSN plugin > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/usr/share/ipa/entryusn.ldif' '-H' 'ldap://ipa.cs.oberlin.edu:389' > '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmp5pjssE' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout=replace nsslapd-entryusn-global: > on > modifying entry "cn=config" > modify complete > > replace nsslapd-entryusn-import-initval: > next > modifying entry "cn=config" > modify complete > > replace nsslapd-pluginenabled: > on > modifying entry "cn=USN,cn=plugins,cn=config" > modify complete > > > 2015-02-06T22:09:12Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:12Z DEBUG duration: 0 seconds > 2015-02-06T22:09:12Z DEBUG [14/35]: configuring lockout plugin > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/usr/share/ipa/lockout-conf.ldif' '-H' > 'ldap://ipa.cs.oberlin.edu:389' '-x' '-D' 'cn=Directory Manager' '-y' > '/tmp/tmpt91sUQ' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout=add objectclass: > top > nsSlapdPlugin > extensibleObject > add cn: > IPA Lockout > add nsslapd-pluginpath: > libipa_lockout > add nsslapd-plugininitfunc: > ipalockout_init > add nsslapd-plugintype: > object > add nsslapd-pluginenabled: > on > add nsslapd-pluginid: > ipalockout_version > add nsslapd-pluginversion: > 1.0 > add nsslapd-pluginvendor: > Red Hat, Inc. > add nsslapd-plugindescription: > IPA Lockout plugin > add nsslapd-plugin-depends-on-type: > database > adding new entry "cn=IPA Lockout,cn=plugins,cn=config" > modify complete > > > 2015-02-06T22:09:12Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:12Z DEBUG duration: 0 seconds > 2015-02-06T22:09:12Z DEBUG [15/35]: creating indices > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/usr/share/ipa/indices.ldif' '-H' 'ldap://ipa.cs.oberlin.edu:389' > '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpHAiHnm' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout=add objectClass: > top > nsIndex > add cn: > krbPrincipalName > add nsSystemIndex: > false > add nsIndexType: > eq > sub > adding new entry "cn=krbPrincipalName,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add objectClass: > top > nsIndex > add cn: > ou > add nsSystemIndex: > false > add nsIndexType: > eq > sub > adding new entry "cn=ou,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add objectClass: > top > nsIndex > add cn: > carLicense > add nsSystemIndex: > false > add nsIndexType: > eq > sub > adding new entry "cn=carLicense,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add objectClass: > top > nsIndex > add cn: > title > add nsSystemIndex: > false > add nsIndexType: > eq > sub > adding new entry "cn=title,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add objectClass: > top > nsIndex > add cn: > manager > add nsSystemIndex: > false > add nsIndexType: > eq > pres > sub > adding new entry "cn=manager,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add objectClass: > top > nsIndex > add cn: > secretary > add nsSystemIndex: > false > add nsIndexType: > eq > pres > sub > adding new entry "cn=secretary,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add objectClass: > top > nsIndex > add cn: > displayname > add nsSystemIndex: > false > add nsIndexType: > eq > sub > adding new entry "cn=displayname,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add nsIndexType: > sub > modifying entry "cn=uid,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add objectClass: > top > nsIndex > add cn: > uidnumber > add nsSystemIndex: > false > add nsIndexType: > eq > add nsMatchingRule: > integerOrderingMatch > adding new entry "cn=uidnumber,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add objectClass: > top > nsIndex > add cn: > gidnumber > add nsSystemIndex: > false > add nsIndexType: > eq > add nsMatchingRule: > integerOrderingMatch > adding new entry "cn=gidnumber,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > replace nsIndexType: > eq,pres > modifying entry "cn=ntUniqueId,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > replace nsIndexType: > eq,pres > modifying entry "cn=ntUserDomainId,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add ObjectClass: > top > nsIndex > add cn: > fqdn > add nsSystemIndex: > false > add nsIndexType: > eq > pres > adding new entry "cn=fqdn,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add ObjectClass: > top > nsIndex > add cn: > macAddress > add nsSystemIndex: > false > add nsIndexType: > eq > pres > adding new entry "cn=macAddress,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add cn: > memberHost > add ObjectClass: > top > nsIndex > add nsSystemIndex: > false > add nsIndexType: > eq > pres > sub > adding new entry "cn=memberHost,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add cn: > memberUser > add ObjectClass: > top > nsIndex > add nsSystemIndex: > false > add nsIndexType: > eq > pres > sub > adding new entry "cn=memberUser,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add cn: > sourcehost > add ObjectClass: > top > nsIndex > add nsSystemIndex: > false > add nsIndexType: > eq > pres > sub > adding new entry "cn=sourcehost,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add cn: > memberservice > add ObjectClass: > top > nsIndex > add nsSystemIndex: > false > add nsIndexType: > eq > pres > sub > adding new entry "cn=memberservice,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add cn: > managedby > add ObjectClass: > top > nsIndex > add nsSystemIndex: > false > add nsIndexType: > eq > pres > sub > adding new entry "cn=managedby,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add cn: > memberallowcmd > add ObjectClass: > top > nsIndex > add nsSystemIndex: > false > add nsIndexType: > eq > pres > sub > adding new entry "cn=memberallowcmd,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add cn: > memberdenycmd > add ObjectClass: > top > nsIndex > add nsSystemIndex: > false > add nsIndexType: > eq > pres > sub > adding new entry "cn=memberdenycmd,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add cn: > ipasudorunas > add ObjectClass: > top > nsIndex > add nsSystemIndex: > false > add nsIndexType: > eq > pres > sub > adding new entry "cn=ipasudorunas,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add cn: > ipasudorunasgroup > add ObjectClass: > top > nsIndex > add nsSystemIndex: > false > add nsIndexType: > eq > pres > sub > adding new entry "cn=ipasudorunasgroup,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add cn: > automountkey > add ObjectClass: > top > nsIndex > add nsSystemIndex: > false > add nsIndexType: > eq > adding new entry "cn=automountkey,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add cn: > ipakrbprincipalalias > add ObjectClass: > top > nsIndex > add nsSystemIndex: > false > add nsIndexType: > eq > adding new entry "cn=ipakrbprincipalalias,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > add cn: > ipauniqueid > add ObjectClass: > top > nsIndex > add nsSystemIndex: > false > add nsIndexType: > eq > adding new entry "cn=ipauniqueid,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config" > modify complete > > > 2015-02-06T22:09:12Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:12Z DEBUG duration: 0 seconds > 2015-02-06T22:09:12Z DEBUG [16/35]: enabling referential integrity > plugin > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/usr/share/ipa/referint-conf.ldif' '-H' > 'ldap://ipa.cs.oberlin.edu:389' '-x' '-D' 'cn=Directory Manager' '-y' > '/tmp/tmp5G8YDP' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout=replace nsslapd-pluginenabled: > on > modifying entry "cn=referential integrity > postoperation,cn=plugins,cn=config" > modify complete > > > 2015-02-06T22:09:12Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:12Z DEBUG duration: 0 seconds > 2015-02-06T22:09:12Z DEBUG [17/35]: configuring ssl for ds instance > 2015-02-06T22:09:12Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/certutil' '-d' > '/etc/dirsrv/slapd-CS-OBERLIN-EDU/' '-N' '-f' > '/etc/dirsrv/slapd-CS-OBERLIN-EDU//pwdfile.txt' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout= > 2015-02-06T22:09:12Z DEBUG stderr= > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/pk12util' '-d' > '/etc/dirsrv/slapd-CS-OBERLIN-EDU/' '-i' > '/tmp/tmpzmYHXxipa/realm_info/dscert.p12' '-k' > '/etc/dirsrv/slapd-CS-OBERLIN-EDU//pwdfile.txt' '-v' '-w' '/dev/stdin' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout=pk12util: PKCS12 IMPORT SUCCESSFUL > > 2015-02-06T22:09:12Z DEBUG stderr= > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/certutil' '-d' > '/etc/dirsrv/slapd-CS-OBERLIN-EDU/' '-L' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout= > Certificate Nickname Trust > Attributes > SSL,S/MIME,JAR/XPI > > Server-Cert u,u,u > CS.OBERLIN.EDU IPA CA ,, > > 2015-02-06T22:09:12Z DEBUG stderr= > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/certutil' '-d' > '/etc/dirsrv/slapd-CS-OBERLIN-EDU/' '-A' '-n' 'CA 1' '-t' ',,' '-a' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout= > 2015-02-06T22:09:12Z DEBUG stderr= > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/certutil' '-d' > '/etc/dirsrv/slapd-CS-OBERLIN-EDU/' '-O' '-n' 'Server-Cert' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout="CS.OBERLIN.EDU IPA CA" > [CN=Certificate Authority,O=CS.OBERLIN.EDU] > > "Server-Cert" [CN=ipa.cs.oberlin.edu,O=CS.OBERLIN.EDU] > > > 2015-02-06T22:09:12Z DEBUG stderr= > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/certutil' '-d' > '/etc/dirsrv/slapd-CS-OBERLIN-EDU/' '-M' '-n' 'CS.OBERLIN.EDU IPA CA' > '-t' 'CT,C,C' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout= > 2015-02-06T22:09:12Z DEBUG stderr= > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/certutil' '-d' > '/etc/dirsrv/slapd-CS-OBERLIN-EDU/' '-O' '-n' 'Server-Cert' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout="CS.OBERLIN.EDU IPA CA" > [CN=Certificate Authority,O=CS.OBERLIN.EDU] > > "Server-Cert" [CN=ipa.cs.oberlin.edu,O=CS.OBERLIN.EDU] > > > 2015-02-06T22:09:12Z DEBUG stderr= > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/certutil' '-d' > '/etc/dirsrv/slapd-CS-OBERLIN-EDU/' '-L' '-n' 'CS.OBERLIN.EDU IPA CA' '-a' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout=-----BEGIN CERTIFICATE----- > MIIDlDCCAnygAwIBAgIBATANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKEw5DUy5P > QkVSTElOLkVEVTEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE0 > MDMyMTA5MzAyOFoXDTM0MDMyMTA5MzAyOFowOTEXMBUGA1UEChMOQ1MuT0JFUkxJ > Ti5FRFUxHjAcBgNVBAMTFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZI > hvcNAQEBBQADggEPADCCAQoCggEBAKb+vPeISgGklCdSOnDeUwdfO85yIpR4jYjR > ye5wDxFzYbHPtO9VGDtV5odKodeCfKIkvVldJzGW3Y8R7G5Fg00M627kJ74RgHCD > bI8vW9XNxeuTJ4q7oW6a9SPXEUDp7kJF8Qyb9ci9/5Ki7Xgc7+lQ4tzIGF05NIAp > fHNriUZm7RVFp1TunVYKuzMw8XbiwwayqOk/DfEZLHZX1mwN317uaNEILR4dE+YU > owThGl0lVlF8UJbRkudQ+139ne7XwFTPkGln1q4A9p6pr9oc2HQYDIEI589NRFVV > 8fQDHnfYaku1aAj9WyRB3i7+AjilLEX/TDSh0P0p81dUETrx9wcCAwEAAaOBpjCB > ozAfBgNVHSMEGDAWgBSMRQizFrNQL2a/Cr7qKvmGk7vfCDAPBgNVHRMBAf8EBTAD > AQH/MA4GA1UdDwEB/wQEAwIBxjAdBgNVHQ4EFgQUjEUIsxazUC9mvwq+6ir5hpO7 > 3wgwQAYIKwYBBQUHAQEENDAyMDAGCCsGAQUFBzABhiRodHRwOi8vaWRtLmNzLm9i > ZXJsaW4uZWR1OjgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAFDGFQnwYeOy > 6qqLMcMM50+957Ejwta1oVFZ7XUXR9nznlc2RZz0gbjDbH2B0+CNflbkRHge3uB9 > 9ud2CHVKqsHzWsmbCiEjqwo0W+tSPtpp29G16ar8YHdmj79xFIpN6UQG5PuHL9wr > MsFTFDGx5UkkHHzveCVnlMZ2TGp9imsQ17ZbzIGwddTZ5rVLPpwcIvtmqtYNkBMO > PUzQwdyNw3o0GoKD60os24j2SjCsQxn4L0hc6/srjkm+CHoMA2/iUR8SueZt9Kft > 9vKpuS7w86lu0X5heqpUBfAJ4uiv7Bu2qWRXv+rA4wInCTBnGx8SP53ENIFM7WIa > 5pOh4NxH5Jc= > -----END CERTIFICATE----- > > 2015-02-06T22:09:12Z DEBUG stderr= > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/certutil' '-d' > '/etc/dirsrv/slapd-CS-OBERLIN-EDU/' '-L' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout= > Certificate Nickname Trust > Attributes > SSL,S/MIME,JAR/XPI > > Server-Cert u,u,u > CS.OBERLIN.EDU IPA CA CT,C,C > > 2015-02-06T22:09:12Z DEBUG stderr= > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/certutil' '-d' > '/etc/dirsrv/slapd-CS-OBERLIN-EDU/' '-L' '-n' 'Server-Cert' '-a' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout=-----BEGIN CERTIFICATE----- > MIIDnzCCAoegAwIBAgIBdTANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKEw5DUy5P > QkVSTElOLkVEVTEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE1 > MDIwNjE0MDEzM1oXDTE3MDIwNjE0MDEzM1owNjEXMBUGA1UEChMOQ1MuT0JFUkxJ > Ti5FRFUxGzAZBgNVBAMTEmlwYS5jcy5vYmVybGluLmVkdTCCASIwDQYJKoZIhvcN > AQEBBQADggEPADCCAQoCggEBAOig6uDWVeG7W/642c0vsSK6Zf3U4uyIl1AZJ4VK > LsT2I/e1zdcORJJ2w6iZ5VQ/YZe89zeiDCrzWc8rkfztjZdouzUP/xd6uyx54kBs > hB6QOtbpxxWakJsN2jdyR/rCk9mTOQ2SW5mY8kTeKecReDcd7snYw5SgbySI2Pn/ > IJwMjLuflxkleJzadaTJTqGlrp3hj1/H07j+q+dDfxeWHbDK/XAwruWshEtrOAEW > ziZOFGcdXNoDNS3e2A20/gAEvVUb1VPuKlZifh621AqqNhOeF8LPNrMgYjoQ7IlD > sF5ZWZ1dRu0ShKxkKpdTiiaOLxaMRdfoywlt03aHiTw1JekCAwEAAaOBtDCBsTAf > BgNVHSMEGDAWgBSMRQizFrNQL2a/Cr7qKvmGk7vfCDBABggrBgEFBQcBAQQ0MDIw > MAYIKwYBBQUHMAGGJGh0dHA6Ly9pZG0uY3Mub2Jlcmxpbi5lZHU6ODAvY2Evb2Nz > cDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC > MB0GA1UdDgQWBBRqFfQJ2o3ZEeyPDfOFAQA553TVWDANBgkqhkiG9w0BAQsFAAOC > AQEADMD/VdR6j5RvcyZwrhAqYtdSSL4yvyTVwkYuRgbHw86gwTqm6tBbVe2Vwdok > IIWu+/EXolIzq/5XyDJ1dxoW9e6zEyDWtupLOKDRSoHrw7z2+DejVdzIRizU1h48 > zBTVF+cWXja6Q+AqmEkCby76X5+UfeYcyc2vEBfxhAQySU/mrrhaGA0qG+xsdewh > F8FF/XWpDxyscwAhJL6DKNyZKuDyQM6EOkxQ3OYRqRs21mVis1ONt6fvzIC1fSIy > GYJ6shm5O6cPijjKwaZo8XsW0ZlF6SRybCuGEJSGmbZYdlP0A1ZR9/YMVim1ghR2 > KvAXCSL+tYpWmbNLgsxnZswr0A== > -----END CERTIFICATE----- > > 2015-02-06T22:09:12Z DEBUG stderr= > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/bin/systemctl' 'is-active' > 'certmonger.service' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout=active > > 2015-02-06T22:09:12Z DEBUG stderr= > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/usr/bin/certutil' '-d' > '/etc/dirsrv/slapd-CS-OBERLIN-EDU/' '-L' '-n' 'Server-Cert' '-a' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout=-----BEGIN CERTIFICATE----- > MIIDnzCCAoegAwIBAgIBdTANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKEw5DUy5P > QkVSTElOLkVEVTEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE1 > MDIwNjE0MDEzM1oXDTE3MDIwNjE0MDEzM1owNjEXMBUGA1UEChMOQ1MuT0JFUkxJ > Ti5FRFUxGzAZBgNVBAMTEmlwYS5jcy5vYmVybGluLmVkdTCCASIwDQYJKoZIhvcN > AQEBBQADggEPADCCAQoCggEBAOig6uDWVeG7W/642c0vsSK6Zf3U4uyIl1AZJ4VK > LsT2I/e1zdcORJJ2w6iZ5VQ/YZe89zeiDCrzWc8rkfztjZdouzUP/xd6uyx54kBs > hB6QOtbpxxWakJsN2jdyR/rCk9mTOQ2SW5mY8kTeKecReDcd7snYw5SgbySI2Pn/ > IJwMjLuflxkleJzadaTJTqGlrp3hj1/H07j+q+dDfxeWHbDK/XAwruWshEtrOAEW > ziZOFGcdXNoDNS3e2A20/gAEvVUb1VPuKlZifh621AqqNhOeF8LPNrMgYjoQ7IlD > sF5ZWZ1dRu0ShKxkKpdTiiaOLxaMRdfoywlt03aHiTw1JekCAwEAAaOBtDCBsTAf > BgNVHSMEGDAWgBSMRQizFrNQL2a/Cr7qKvmGk7vfCDBABggrBgEFBQcBAQQ0MDIw > MAYIKwYBBQUHMAGGJGh0dHA6Ly9pZG0uY3Mub2Jlcmxpbi5lZHU6ODAvY2Evb2Nz > cDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC > MB0GA1UdDgQWBBRqFfQJ2o3ZEeyPDfOFAQA553TVWDANBgkqhkiG9w0BAQsFAAOC > AQEADMD/VdR6j5RvcyZwrhAqYtdSSL4yvyTVwkYuRgbHw86gwTqm6tBbVe2Vwdok > IIWu+/EXolIzq/5XyDJ1dxoW9e6zEyDWtupLOKDRSoHrw7z2+DejVdzIRizU1h48 > zBTVF+cWXja6Q+AqmEkCby76X5+UfeYcyc2vEBfxhAQySU/mrrhaGA0qG+xsdewh > F8FF/XWpDxyscwAhJL6DKNyZKuDyQM6EOkxQ3OYRqRs21mVis1ONt6fvzIC1fSIy > GYJ6shm5O6cPijjKwaZo8XsW0ZlF6SRybCuGEJSGmbZYdlP0A1ZR9/YMVim1ghR2 > KvAXCSL+tYpWmbNLgsxnZswr0A== > -----END CERTIFICATE----- > > 2015-02-06T22:09:12Z DEBUG stderr= > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/bin/systemctl' 'is-active' > 'certmonger.service' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout=active > > 2015-02-06T22:09:12Z DEBUG stderr= > 2015-02-06T22:09:12Z DEBUG Starting external process > 2015-02-06T22:09:12Z DEBUG args='/bin/systemctl' 'is-active' > 'certmonger.service' > 2015-02-06T22:09:12Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:12Z DEBUG stdout=active > > 2015-02-06T22:09:12Z DEBUG stderr= > 2015-02-06T22:09:12Z DEBUG flushing ldap://ipa.cs.oberlin.edu:389 from > SchemaCache > 2015-02-06T22:09:12Z DEBUG retrieving schema for SchemaCache > url=ldap://ipa.cs.oberlin.edu:389 > conn= > 2015-02-06T22:09:12Z DEBUG duration: 0 seconds > 2015-02-06T22:09:12Z DEBUG [18/35]: configuring certmap.conf > 2015-02-06T22:09:13Z DEBUG Loading StateFile from > '/var/lib/ipa/sysupgrade/sysupgrade.state' > 2015-02-06T22:09:13Z DEBUG Saving StateFile to > '/var/lib/ipa/sysupgrade/sysupgrade.state' > 2015-02-06T22:09:13Z DEBUG duration: 0 seconds > 2015-02-06T22:09:13Z DEBUG [19/35]: configure autobind for root > 2015-02-06T22:09:13Z DEBUG Starting external process > 2015-02-06T22:09:13Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/usr/share/ipa/root-autobind.ldif' '-H' > 'ldap://ipa.cs.oberlin.edu:389' '-x' '-D' 'cn=Directory Manager' '-y' > '/tmp/tmpF6vyIt' > 2015-02-06T22:09:13Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:13Z DEBUG stdout=add objectClass: > extensibleObject > top > add cn: > root-autobind > add uidNumber: > 0 > add gidNumber: > 0 > adding new entry "cn=root-autobind,cn=config" > modify complete > > replace nsslapd-ldapiautobind: > on > modifying entry "cn=config" > modify complete > > replace nsslapd-ldapimaptoentries: > on > modifying entry "cn=config" > modify complete > > > 2015-02-06T22:09:13Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:13Z DEBUG duration: 0 seconds > 2015-02-06T22:09:13Z DEBUG [20/35]: configure new location for > managed entries > 2015-02-06T22:09:13Z DEBUG Starting external process > 2015-02-06T22:09:13Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/tmp/tmpiwedy2' '-H' 'ldap://ipa.cs.oberlin.edu:389' '-x' '-D' > 'cn=Directory Manager' '-y' '/tmp/tmpVbs2ru' > 2015-02-06T22:09:13Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:13Z DEBUG stdout=add nsslapd-pluginConfigArea: > cn=Definitions,cn=Managed Entries,cn=etc,dc=cs,dc=oberlin,dc=edu > modifying entry "cn=Managed Entries,cn=plugins,cn=config" > modify complete > > > 2015-02-06T22:09:13Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:13Z DEBUG duration: 0 seconds > 2015-02-06T22:09:13Z DEBUG [21/35]: configure dirsrv ccache > 2015-02-06T22:09:13Z DEBUG Backing up system configuration file > '/etc/sysconfig/dirsrv' > 2015-02-06T22:09:13Z DEBUG Saving Index File to > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-02-06T22:09:13Z DEBUG Starting external process > 2015-02-06T22:09:13Z DEBUG args='/usr/sbin/selinuxenabled' > 2015-02-06T22:09:13Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:13Z DEBUG stdout= > 2015-02-06T22:09:13Z DEBUG stderr= > 2015-02-06T22:09:13Z DEBUG Starting external process > 2015-02-06T22:09:13Z DEBUG args='/sbin/restorecon' '/etc/sysconfig/dirsrv' > 2015-02-06T22:09:13Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:13Z DEBUG stdout= > 2015-02-06T22:09:13Z DEBUG stderr= > 2015-02-06T22:09:13Z DEBUG duration: 0 seconds > 2015-02-06T22:09:13Z DEBUG [22/35]: enable SASL mapping fallback > 2015-02-06T22:09:13Z DEBUG Starting external process > 2015-02-06T22:09:13Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' > '/tmp/tmpMksQKm' '-H' 'ldap://ipa.cs.oberlin.edu:389' '-x' '-D' > 'cn=Directory Manager' '-y' '/tmp/tmpvbLong' > 2015-02-06T22:09:13Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:13Z DEBUG stdout=replace nsslapd-sasl-mapping-fallback: > on > modifying entry "cn=config" > modify complete > > > 2015-02-06T22:09:13Z DEBUG stderr=ldap_initialize( > ldap://ipa.cs.oberlin.edu:389/??base ) > > 2015-02-06T22:09:13Z DEBUG duration: 0 seconds > 2015-02-06T22:09:13Z DEBUG [23/35]: restarting directory server > 2015-02-06T22:09:13Z DEBUG Starting external process > 2015-02-06T22:09:13Z DEBUG args='/bin/systemctl' '--system' > 'daemon-reload' > 2015-02-06T22:09:13Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:13Z DEBUG stdout= > 2015-02-06T22:09:13Z DEBUG stderr= > 2015-02-06T22:09:13Z DEBUG Starting external process > 2015-02-06T22:09:13Z DEBUG args='/bin/systemctl' 'restart' > 'dirsrv at CS-OBERLIN-EDU.service' > 2015-02-06T22:09:14Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:14Z DEBUG stdout= > 2015-02-06T22:09:14Z DEBUG stderr= > 2015-02-06T22:09:14Z DEBUG Starting external process > 2015-02-06T22:09:14Z DEBUG args='/bin/systemctl' 'is-active' > 'dirsrv at CS-OBERLIN-EDU.service' > 2015-02-06T22:09:14Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:14Z DEBUG stdout=active > > 2015-02-06T22:09:14Z DEBUG stderr= > 2015-02-06T22:09:14Z DEBUG wait_for_open_ports: localhost [389] > timeout 300 > 2015-02-06T22:09:18Z DEBUG Starting external process > 2015-02-06T22:09:18Z DEBUG args='/bin/systemctl' 'is-active' > 'dirsrv at CS-OBERLIN-EDU.service' > 2015-02-06T22:09:18Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:18Z DEBUG stdout=active > > 2015-02-06T22:09:18Z DEBUG stderr= > 2015-02-06T22:09:18Z DEBUG duration: 5 seconds > 2015-02-06T22:09:18Z DEBUG [24/35]: setting up initial replication > 2015-02-06T22:09:18Z DEBUG flushing > ldapi://%2fvar%2frun%2fslapd-CS-OBERLIN-EDU.socket from SchemaCache > 2015-02-06T22:09:18Z DEBUG retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-CS-OBERLIN-EDU.socket > conn= > 2015-02-06T22:09:18Z DEBUG Starting external process > 2015-02-06T22:09:18Z DEBUG args='/bin/systemctl' '--system' > 'daemon-reload' > 2015-02-06T22:09:18Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:18Z DEBUG stdout= > 2015-02-06T22:09:18Z DEBUG stderr= > 2015-02-06T22:09:18Z DEBUG Starting external process > 2015-02-06T22:09:18Z DEBUG args='/bin/systemctl' 'restart' > 'dirsrv at CS-OBERLIN-EDU.service' > 2015-02-06T22:09:20Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:20Z DEBUG stdout= > 2015-02-06T22:09:20Z DEBUG stderr= > 2015-02-06T22:09:20Z DEBUG Starting external process > 2015-02-06T22:09:20Z DEBUG args='/bin/systemctl' 'is-active' > 'dirsrv at CS-OBERLIN-EDU.service' > 2015-02-06T22:09:20Z DEBUG Process finished, return code=0 > 2015-02-06T22:09:20Z DEBUG stdout=active > > 2015-02-06T22:09:20Z DEBUG stderr= > 2015-02-06T22:09:20Z DEBUG wait_for_open_ports: localhost [389] > timeout 300 > 2015-02-06T22:09:23Z DEBUG flushing ldap://idm.cs.oberlin.edu:389 from > SchemaCache > 2015-02-06T22:09:23Z DEBUG retrieving schema for SchemaCache > url=ldap://idm.cs.oberlin.edu:389 > conn= > 2015-02-06T22:09:23Z DEBUG flushing ldaps://ipa.cs.oberlin.edu:636 > from SchemaCache > 2015-02-06T22:09:23Z DEBUG retrieving schema for SchemaCache > url=ldaps://ipa.cs.oberlin.edu:636 > conn= > 2015-02-06T22:11:42Z DEBUG Traceback (most recent call last): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 382, in start_creation > run_step(full_msg, method) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 372, in run_step > method() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 368, in __setup_replica > r_bindpw=self.dm_password) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", > line 965, in setup_replication > raise RuntimeError("Failed to start replication") > RuntimeError: Failed to start replication > > 2015-02-06T22:11:42Z DEBUG [error] RuntimeError: Failed to start > replication > 2015-02-06T22:11:43Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 642, in run_script > return_value = main_function() > > File "/sbin/ipa-replica-install", line 700, in main > ds = install_replica_ds(config) > > File "/sbin/ipa-replica-install", line 195, in install_replica_ds > ca_file=config.dir + "/ca.crt", > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 355, in create_replica > self.start_creation(runtime=60) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 382, in start_creation > run_step(full_msg, method) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 372, in run_step > method() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 368, in __setup_replica > r_bindpw=self.dm_password) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", > line 965, in setup_replication > raise RuntimeError("Failed to start replication") > > 2015-02-06T22:11:43Z DEBUG The ipa-replica-install command failed, > exception: RuntimeError: Failed to start replication -dirsrv error log- > 389-Directory/1.3.3.5 B2014.289.1826 > ipa.cs.oberlin.edu:389 (/etc/dirsrv/slapd-CS-OBERLIN-EDU) > > [06/Feb/2015:11:11:58 -0500] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to > access the database > [06/Feb/2015:11:11:58 -0500] - check_and_set_import_cache: pagesize: > 4096, pages: 2043953, procpages: 55635 > [06/Feb/2015:11:11:58 -0500] - Import allocates 3270324KB import cache. > [06/Feb/2015:11:11:59 -0500] - import userRoot: Beginning import job... > [06/Feb/2015:11:11:59 -0500] - import userRoot: Index buffering > enabled with bucket size 100 > [06/Feb/2015:11:11:59 -0500] - import userRoot: Processing file > "/var/lib/dirsrv/boot.ldif" > [06/Feb/2015:11:11:59 -0500] - import userRoot: Finished scanning file > "/var/lib/dirsrv/boot.ldif" (1 entries) > [06/Feb/2015:11:12:01 -0500] - import userRoot: Workers finished; > cleaning up... > [06/Feb/2015:11:12:01 -0500] - import userRoot: Workers cleaned up. > [06/Feb/2015:11:12:01 -0500] - import userRoot: Cleaning up producer > thread... > [06/Feb/2015:11:12:01 -0500] - import userRoot: Indexing complete. > Post-processing... > [06/Feb/2015:11:12:01 -0500] - import userRoot: Generating > numsubordinates (this may take several minutes to complete)... > [06/Feb/2015:11:12:02 -0500] - import userRoot: Generating > numSubordinates complete. > [06/Feb/2015:11:12:02 -0500] - import userRoot: Gathering ancestorid > non-leaf IDs... > [06/Feb/2015:11:12:02 -0500] - import userRoot: Finished gathering > ancestorid non-leaf IDs. > [06/Feb/2015:11:12:02 -0500] - Nothing to do to build ancestorid index > [06/Feb/2015:11:12:02 -0500] - import userRoot: Created ancestorid > index (new idl). > [06/Feb/2015:11:12:02 -0500] - import userRoot: Flushing caches... > [06/Feb/2015:11:12:02 -0500] - import userRoot: Closing files... > [06/Feb/2015:11:12:02 -0500] - All database threads now stopped > [06/Feb/2015:11:12:02 -0500] - import userRoot: Import complete. > Processed 1 entries in 3 seconds. (0.33 entries/sec) > [06/Feb/2015:11:12:04 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 > starting up > [06/Feb/2015:11:12:04 -0500] - Db home directory is not set. Possibly > nsslapd-directory (optionally nsslapd-db-home-directory) is missing in > the config file. > [06/Feb/2015:11:12:04 -0500] - I'm resizing my cache now...cache was > 3348811776 and is now 6400000 > [06/Feb/2015:11:12:05 -0500] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [06/Feb/2015:11:12:05 -0500] - slapd shutting down - signaling > operation threads - op stack size 0 max work q size 0 max work q stack > size 0 > [06/Feb/2015:11:12:06 -0500] - slapd shutting down - closing down > internal subsystems and plugins > [06/Feb/2015:11:12:06 -0500] - Waiting for 4 database threads to stop > [06/Feb/2015:11:12:07 -0500] - All database threads now stopped > [06/Feb/2015:11:12:07 -0500] - slapd shutting down - freed 0 work q > stack objects - freed 0 op stack objects > [06/Feb/2015:11:12:07 -0500] - slapd stopped. > [06/Feb/2015:11:12:09 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 > starting up > [06/Feb/2015:11:12:09 -0500] - I'm resizing my cache now...cache was > 6400000 and is now 5120000 > [06/Feb/2015:11:12:09 -0500] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [06/Feb/2015:11:12:19 -0500] - The change of nsslapd-ldapilisten will > not take effect until the server is restarted > [06/Feb/2015:11:12:24 -0500] - Warning: Adding configuration attribute > "nsslapd-security" > [06/Feb/2015:11:12:25 -0500] - slapd shutting down - signaling > operation threads - op stack size 2 max work q size 1 max work q stack > size 1 > [06/Feb/2015:11:12:25 -0500] - slapd shutting down - waiting for 29 > threads to terminate > [06/Feb/2015:11:12:25 -0500] - slapd shutting down - closing down > internal subsystems and plugins > [06/Feb/2015:11:12:25 -0500] - Waiting for 4 database threads to stop > [06/Feb/2015:11:12:26 -0500] - All database threads now stopped > [06/Feb/2015:11:12:26 -0500] - slapd shutting down - freed 1 work q > stack objects - freed 2 op stack objects > [06/Feb/2015:11:12:26 -0500] - slapd stopped. > [06/Feb/2015:11:12:28 -0500] - SSL alert: Configured NSS Ciphers > [06/Feb/2015:11:12:28 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:11:12:28 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:11:12:28 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:12:28 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:12:28 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:12:28 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:11:12:28 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:11:12:28 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:12:28 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:11:12:28 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:12:28 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:12:28 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:11:12:28 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:11:12:29 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:11:12:29 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:12:29 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:12:29 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled > [06/Feb/2015:11:12:29 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:11:12:29 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:11:12:29 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:12:29 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:12:29 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:12:29 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:12:29 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:11:12:29 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:12:29 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:11:12:29 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:11:12:29 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:12:29 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA256: enabled > [06/Feb/2015:11:12:30 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:11:12:30 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: > enabled > [06/Feb/2015:11:12:30 -0500] SSL Initialization - SSL version range: > min: TLS1.0, max: TLS1.2 > [06/Feb/2015:11:12:30 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 > starting up > [06/Feb/2015:11:12:30 -0500] - I'm resizing my cache now...cache was > 5120000 and is now 4096000 > [06/Feb/2015:11:12:30 -0500] attrcrypt - No symmetric key found for > cipher AES in backend userRoot, attempting to create one... > [06/Feb/2015:11:12:31 -0500] attrcrypt - Key for cipher AES > successfully generated and stored > [06/Feb/2015:11:12:31 -0500] attrcrypt - No symmetric key found for > cipher 3DES in backend userRoot, attempting to create one... > [06/Feb/2015:11:12:31 -0500] attrcrypt - Key for cipher 3DES > successfully generated and stored > [06/Feb/2015:11:12:31 -0500] ipalockout_get_global_config - [file > ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) > [06/Feb/2015:11:12:32 -0500] ipaenrollment_start - [file > ipa_enrollment.c, line 393]: Failed to get default realm?! > [06/Feb/2015:11:12:32 -0500] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [06/Feb/2015:11:12:32 -0500] - Listening on All Interfaces port 636 > for LDAPS requests > [06/Feb/2015:11:12:32 -0500] - Listening on > /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests > [06/Feb/2015:11:12:33 -0500] - slapd shutting down - signaling > operation threads - op stack size 1 max work q size 1 max work q stack > size 1 > [06/Feb/2015:11:12:33 -0500] - slapd shutting down - waiting for 2 > threads to terminate > [06/Feb/2015:11:12:33 -0500] - slapd shutting down - closing down > internal subsystems and plugins > [06/Feb/2015:11:12:33 -0500] - Waiting for 4 database threads to stop > [06/Feb/2015:11:12:34 -0500] - All database threads now stopped > [06/Feb/2015:11:12:34 -0500] - slapd shutting down - freed 1 work q > stack objects - freed 1 op stack objects > [06/Feb/2015:11:12:34 -0500] - slapd stopped. > [06/Feb/2015:11:12:35 -0500] - SSL alert: Configured NSS Ciphers > [06/Feb/2015:11:12:35 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:11:12:35 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:11:12:35 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:12:35 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:12:36 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:12:36 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:11:12:36 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:11:12:36 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:12:36 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:11:12:36 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:12:36 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:12:36 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:11:12:36 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:11:12:36 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:11:12:36 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:12:36 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:12:36 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled > [06/Feb/2015:11:12:37 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:11:12:37 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:11:12:37 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:12:37 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:12:37 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:12:37 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:12:37 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:11:12:37 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:12:37 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:11:12:37 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:11:12:37 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:12:37 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA256: enabled > [06/Feb/2015:11:12:37 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:11:12:38 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: > enabled > [06/Feb/2015:11:12:38 -0500] SSL Initialization - SSL version range: > min: TLS1.0, max: TLS1.2 > [06/Feb/2015:11:12:38 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 > starting up > [06/Feb/2015:11:12:38 -0500] - I'm resizing my cache now...cache was > 4096000 and is now 3276800 > [06/Feb/2015:11:12:38 -0500] ipalockout_get_global_config - [file > ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) > [06/Feb/2015:11:12:38 -0500] ipaenrollment_start - [file > ipa_enrollment.c, line 393]: Failed to get default realm?! > [06/Feb/2015:11:12:39 -0500] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [06/Feb/2015:11:12:39 -0500] - Listening on All Interfaces port 636 > for LDAPS requests > [06/Feb/2015:11:12:39 -0500] - Listening on > /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests > [06/Feb/2015:11:12:40 -0500] NSMMReplicationPlugin - > agmt="cn=meToidm.cs.oberlin.edu" (idm: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. > [06/Feb/2015:11:12:40 -0500] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=cs,dc=oberlin,dc=edu is going > offline; disabling replication > [06/Feb/2015:11:12:41 -0500] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to > access the database > [06/Feb/2015:11:12:43 -0500] schema - [C] Local objectClasses must not > be overwritten (set replication log for additional info) > [06/Feb/2015:11:13:01 -0500] - import userRoot: Processed 1828 entries > -- average rate 91.4/sec, recent rate 91.3/sec, hit ratio 0% > [06/Feb/2015:11:13:21 -0500] - import userRoot: Processed 1828 entries > -- average rate 45.7/sec, recent rate 45.7/sec, hit ratio 0% > [06/Feb/2015:11:13:41 -0500] - import userRoot: Processed 1828 entries > -- average rate 30.5/sec, recent rate 0.0/sec, hit ratio 0% > [06/Feb/2015:11:14:01 -0500] - import userRoot: Processed 1828 entries > -- average rate 22.9/sec, recent rate 0.0/sec, hit ratio 0% > [06/Feb/2015:11:14:21 -0500] - import userRoot: Processed 1828 entries > -- average rate 18.3/sec, recent rate 0.0/sec, hit ratio 0% > [06/Feb/2015:11:14:41 -0500] - import userRoot: Processed 1828 entries > -- average rate 15.2/sec, recent rate 0.0/sec, hit ratio 0% > [06/Feb/2015:11:14:51 -0500] - import userRoot: Workers finished; > cleaning up... > [06/Feb/2015:11:14:52 -0500] - import userRoot: Workers cleaned up. > [06/Feb/2015:11:14:52 -0500] - import userRoot: Indexing complete. > Post-processing... > [06/Feb/2015:11:14:52 -0500] - import userRoot: Generating > numsubordinates (this may take several minutes to complete)... > [06/Feb/2015:11:14:52 -0500] - import userRoot: Generating > numSubordinates complete. > [06/Feb/2015:11:14:52 -0500] - import userRoot: Gathering ancestorid > non-leaf IDs... > [06/Feb/2015:11:14:52 -0500] - import userRoot: Finished gathering > ancestorid non-leaf IDs. > [06/Feb/2015:11:14:53 -0500] - import userRoot: Creating ancestorid > index (new idl)... > [06/Feb/2015:11:14:53 -0500] - import userRoot: Created ancestorid > index (new idl). > [06/Feb/2015:11:14:53 -0500] - import userRoot: Flushing caches... > [06/Feb/2015:11:14:53 -0500] - import userRoot: Closing files... > [06/Feb/2015:11:14:55 -0500] - import userRoot: Import complete. > Processed 2088 entries in 135 seconds. (15.47 entries/sec) > [06/Feb/2015:11:14:55 -0500] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=cs,dc=oberlin,dc=edu is coming > online; enabling replication > [06/Feb/2015:11:14:56 -0500] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=cs,dc=oberlin,dc=edu--no CoS Templates found, > which should be added before the CoS Definition. > [06/Feb/2015:11:43:39 -0500] - slapd shutting down - signaling > operation threads - op stack size 2 max work q size 1 max work q stack > size 1 > [06/Feb/2015:11:43:39 -0500] - slapd shutting down - closing down > internal subsystems and plugins > [06/Feb/2015:11:43:40 -0500] - Waiting for 4 database threads to stop > [06/Feb/2015:11:43:40 -0500] - All database threads now stopped > [06/Feb/2015:11:43:40 -0500] - slapd shutting down - freed 1 work q > stack objects - freed 2 op stack objects > [06/Feb/2015:11:43:40 -0500] - slapd stopped. > [06/Feb/2015:11:45:30 -0500] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to > access the database > [06/Feb/2015:11:45:31 -0500] - check_and_set_import_cache: pagesize: > 4096, pages: 2043953, procpages: 55634 > [06/Feb/2015:11:45:31 -0500] - Import allocates 3270324KB import cache. > [06/Feb/2015:11:45:31 -0500] - import userRoot: Beginning import job... > [06/Feb/2015:11:45:31 -0500] - import userRoot: Index buffering > enabled with bucket size 100 > [06/Feb/2015:11:45:31 -0500] - import userRoot: Processing file > "/var/lib/dirsrv/boot.ldif" > [06/Feb/2015:11:45:31 -0500] - import userRoot: Finished scanning file > "/var/lib/dirsrv/boot.ldif" (1 entries) > [06/Feb/2015:11:45:32 -0500] - import userRoot: Workers finished; > cleaning up... > [06/Feb/2015:11:45:32 -0500] - import userRoot: Workers cleaned up. > [06/Feb/2015:11:45:32 -0500] - import userRoot: Cleaning up producer > thread... > [06/Feb/2015:11:45:32 -0500] - import userRoot: Indexing complete. > Post-processing... > [06/Feb/2015:11:45:32 -0500] - import userRoot: Generating > numsubordinates (this may take several minutes to complete)... > [06/Feb/2015:11:45:32 -0500] - import userRoot: Generating > numSubordinates complete. > [06/Feb/2015:11:45:33 -0500] - import userRoot: Gathering ancestorid > non-leaf IDs... > [06/Feb/2015:11:45:33 -0500] - import userRoot: Finished gathering > ancestorid non-leaf IDs. > [06/Feb/2015:11:45:33 -0500] - Nothing to do to build ancestorid index > [06/Feb/2015:11:45:33 -0500] - import userRoot: Created ancestorid > index (new idl). > [06/Feb/2015:11:45:33 -0500] - import userRoot: Flushing caches... > [06/Feb/2015:11:45:33 -0500] - import userRoot: Closing files... > [06/Feb/2015:11:45:33 -0500] - All database threads now stopped > [06/Feb/2015:11:45:33 -0500] - import userRoot: Import complete. > Processed 1 entries in 2 seconds. (0.50 entries/sec) > [06/Feb/2015:11:45:34 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 > starting up > [06/Feb/2015:11:45:34 -0500] - Db home directory is not set. Possibly > nsslapd-directory (optionally nsslapd-db-home-directory) is missing in > the config file. > [06/Feb/2015:11:45:34 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 > starting up > [06/Feb/2015:11:45:34 -0500] - Db home directory is not set. Possibly > nsslapd-directory (optionally nsslapd-db-home-directory) is missing in > the config file. > [06/Feb/2015:11:45:34 -0500] - I'm resizing my cache now...cache was > 3348811776 and is now 6400000 > [06/Feb/2015:11:45:35 -0500] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [06/Feb/2015:11:45:35 -0500] - The change of nsslapd-ldapilisten will > not take effect until the server is restarted > [06/Feb/2015:11:45:52 -0500] - Warning: Adding configuration attribute > "nsslapd-security" > [06/Feb/2015:11:45:52 -0500] - slapd shutting down - signaling > operation threads - op stack size 2 max work q size 1 max work q stack > size 1 > [06/Feb/2015:11:45:52 -0500] - slapd shutting down - waiting for 29 > threads to terminate > [06/Feb/2015:11:45:53 -0500] - slapd shutting down - closing down > internal subsystems and plugins > [06/Feb/2015:11:45:53 -0500] - Waiting for 4 database threads to stop > [06/Feb/2015:11:45:54 -0500] - All database threads now stopped > [06/Feb/2015:11:45:54 -0500] - slapd shutting down - freed 1 work q > stack objects - freed 2 op stack objects > [06/Feb/2015:11:45:54 -0500] - slapd stopped. > [06/Feb/2015:11:45:56 -0500] - SSL alert: Configured NSS Ciphers > [06/Feb/2015:11:45:56 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:11:45:56 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:11:45:56 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:45:56 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:45:56 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:45:56 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:11:45:56 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:11:45:56 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:45:56 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:11:45:56 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:45:56 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:45:56 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:11:45:56 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:11:45:57 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:11:45:57 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:45:57 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:45:57 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled > [06/Feb/2015:11:45:57 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:11:45:57 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:11:45:57 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:45:57 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:45:58 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:45:58 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:45:58 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:11:45:58 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:45:58 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:11:45:58 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:11:45:58 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:45:58 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA256: enabled > [06/Feb/2015:11:45:58 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:11:45:58 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: > enabled > [06/Feb/2015:11:45:58 -0500] SSL Initialization - SSL version range: > min: TLS1.0, max: TLS1.2 > [06/Feb/2015:11:45:58 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 > starting up > [06/Feb/2015:11:45:58 -0500] - I'm resizing my cache now...cache was > 6400000 and is now 5120000 > [06/Feb/2015:11:45:59 -0500] attrcrypt - No symmetric key found for > cipher AES in backend userRoot, attempting to create one... > [06/Feb/2015:11:45:59 -0500] attrcrypt - Key for cipher AES > successfully generated and stored > [06/Feb/2015:11:45:59 -0500] attrcrypt - No symmetric key found for > cipher 3DES in backend userRoot, attempting to create one... > [06/Feb/2015:11:45:59 -0500] attrcrypt - Key for cipher 3DES > successfully generated and stored > [06/Feb/2015:11:45:59 -0500] ipalockout_get_global_config - [file > ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) > [06/Feb/2015:11:46:00 -0500] ipaenrollment_start - [file > ipa_enrollment.c, line 393]: Failed to get default realm?! > [06/Feb/2015:11:46:00 -0500] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [06/Feb/2015:11:46:00 -0500] - Listening on All Interfaces port 636 > for LDAPS requests > [06/Feb/2015:11:46:00 -0500] - Listening on > /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests > [06/Feb/2015:11:46:00 -0500] - slapd shutting down - signaling > operation threads - op stack size 1 max work q size 1 max work q stack > size 1 > [06/Feb/2015:11:46:00 -0500] - slapd shutting down - waiting for 27 > threads to terminate > [06/Feb/2015:11:46:00 -0500] - slapd shutting down - closing down > internal subsystems and plugins > [06/Feb/2015:11:46:00 -0500] - Waiting for 4 database threads to stop > [06/Feb/2015:11:46:00 -0500] - All database threads now stopped > [06/Feb/2015:11:46:01 -0500] - slapd shutting down - freed 1 work q > stack objects - freed 1 op stack objects > [06/Feb/2015:11:46:01 -0500] - slapd stopped. > [06/Feb/2015:11:46:02 -0500] - SSL alert: Configured NSS Ciphers > [06/Feb/2015:11:46:02 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:11:46:02 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:11:46:02 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:46:02 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:46:02 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:46:02 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:11:46:02 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:11:46:02 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:11:46:03 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:11:46:04 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:11:46:04 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA256: enabled > [06/Feb/2015:11:46:04 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:11:46:04 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: > enabled > [06/Feb/2015:11:46:04 -0500] SSL Initialization - SSL version range: > min: TLS1.0, max: TLS1.2 > [06/Feb/2015:11:46:04 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 > starting up > [06/Feb/2015:11:46:04 -0500] - I'm resizing my cache now...cache was > 5120000 and is now 4096000 > [06/Feb/2015:11:46:05 -0500] ipalockout_get_global_config - [file > ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) > [06/Feb/2015:11:46:05 -0500] ipaenrollment_start - [file > ipa_enrollment.c, line 393]: Failed to get default realm?! > [06/Feb/2015:11:46:05 -0500] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [06/Feb/2015:11:46:05 -0500] - Listening on All Interfaces port 636 > for LDAPS requests > [06/Feb/2015:11:46:05 -0500] - Listening on > /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests > [06/Feb/2015:11:46:06 -0500] NSMMReplicationPlugin - > agmt="cn=meToidm.cs.oberlin.edu" (idm: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. > [06/Feb/2015:11:46:06 -0500] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=cs,dc=oberlin,dc=edu is going > offline; disabling replication > [06/Feb/2015:11:46:07 -0500] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to > access the database > [06/Feb/2015:11:46:09 -0500] schema - [C] Local objectClasses must not > be overwritten (set replication log for additional info) > [06/Feb/2015:11:46:27 -0500] - import userRoot: Processed 1917 entries > -- average rate 95.8/sec, recent rate 95.8/sec, hit ratio 0% > [06/Feb/2015:11:46:47 -0500] - import userRoot: Processed 1917 entries > -- average rate 47.9/sec, recent rate 47.9/sec, hit ratio 0% > [06/Feb/2015:11:47:07 -0500] - import userRoot: Processed 1917 entries > -- average rate 31.9/sec, recent rate 0.0/sec, hit ratio 0% > [06/Feb/2015:11:47:27 -0500] - import userRoot: Processed 1917 entries > -- average rate 24.0/sec, recent rate 0.0/sec, hit ratio 0% > [06/Feb/2015:11:47:47 -0500] - import userRoot: Processed 1917 entries > -- average rate 19.2/sec, recent rate 0.0/sec, hit ratio 0% > [06/Feb/2015:11:48:07 -0500] - import userRoot: Processed 1917 entries > -- average rate 16.0/sec, recent rate 0.0/sec, hit ratio 0% > [06/Feb/2015:11:48:17 -0500] - import userRoot: Workers finished; > cleaning up... > [06/Feb/2015:11:48:18 -0500] - import userRoot: Workers cleaned up. > [06/Feb/2015:11:48:18 -0500] - import userRoot: Indexing complete. > Post-processing... > [06/Feb/2015:11:48:18 -0500] - import userRoot: Generating > numsubordinates (this may take several minutes to complete)... > [06/Feb/2015:11:48:18 -0500] - import userRoot: Generating > numSubordinates complete. > [06/Feb/2015:11:48:18 -0500] - import userRoot: Gathering ancestorid > non-leaf IDs... > [06/Feb/2015:11:48:18 -0500] - import userRoot: Finished gathering > ancestorid non-leaf IDs. > [06/Feb/2015:11:48:18 -0500] - import userRoot: Creating ancestorid > index (new idl)... > [06/Feb/2015:11:48:18 -0500] - import userRoot: Created ancestorid > index (new idl). > [06/Feb/2015:11:48:18 -0500] - import userRoot: Flushing caches... > [06/Feb/2015:11:48:18 -0500] - import userRoot: Closing files... > [06/Feb/2015:11:48:20 -0500] - import userRoot: Import complete. > Processed 2240 entries in 133 seconds. (16.84 entries/sec) > [06/Feb/2015:11:48:20 -0500] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=cs,dc=oberlin,dc=edu is coming > online; enabling replication > [06/Feb/2015:11:48:21 -0500] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=cs,dc=oberlin,dc=edu--no CoS Templates found, > which should be added before the CoS Definition. > [06/Feb/2015:12:12:59 -0500] - slapd shutting down - signaling > operation threads - op stack size 2 max work q size 1 max work q stack > size 1 > [06/Feb/2015:12:13:00 -0500] - slapd shutting down - waiting for 28 > threads to terminate > [06/Feb/2015:12:13:00 -0500] - slapd shutting down - closing down > internal subsystems and plugins > [06/Feb/2015:12:13:00 -0500] - Waiting for 4 database threads to stop > [06/Feb/2015:12:13:01 -0500] - All database threads now stopped > [06/Feb/2015:12:13:01 -0500] - slapd shutting down - freed 1 work q > stack objects - freed 2 op stack objects > [06/Feb/2015:12:13:01 -0500] - slapd stopped. > [06/Feb/2015:17:09:05 -0500] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to > access the database > [06/Feb/2015:17:09:06 -0500] - check_and_set_import_cache: pagesize: > 4096, pages: 2043953, procpages: 55634 > [06/Feb/2015:17:09:06 -0500] - Import allocates 3270324KB import cache. > [06/Feb/2015:17:09:06 -0500] - import userRoot: Beginning import job... > [06/Feb/2015:17:09:06 -0500] - import userRoot: Index buffering > enabled with bucket size 100 > [06/Feb/2015:17:09:06 -0500] - import userRoot: Processing file > "/var/lib/dirsrv/boot.ldif" > [06/Feb/2015:17:09:06 -0500] - import userRoot: Finished scanning file > "/var/lib/dirsrv/boot.ldif" (1 entries) > [06/Feb/2015:17:09:07 -0500] - import userRoot: Workers finished; > cleaning up... > [06/Feb/2015:17:09:07 -0500] - import userRoot: Workers cleaned up. > [06/Feb/2015:17:09:07 -0500] - import userRoot: Cleaning up producer > thread... > [06/Feb/2015:17:09:08 -0500] - import userRoot: Indexing complete. > Post-processing... > [06/Feb/2015:17:09:08 -0500] - import userRoot: Generating > numsubordinates (this may take several minutes to complete)... > [06/Feb/2015:17:09:08 -0500] - import userRoot: Generating > numSubordinates complete. > [06/Feb/2015:17:09:08 -0500] - import userRoot: Gathering ancestorid > non-leaf IDs... > [06/Feb/2015:17:09:08 -0500] - import userRoot: Finished gathering > ancestorid non-leaf IDs. > [06/Feb/2015:17:09:08 -0500] - Nothing to do to build ancestorid index > [06/Feb/2015:17:09:08 -0500] - import userRoot: Created ancestorid > index (new idl). > [06/Feb/2015:17:09:08 -0500] - import userRoot: Flushing caches... > [06/Feb/2015:17:09:08 -0500] - import userRoot: Closing files... > [06/Feb/2015:17:09:08 -0500] - All database threads now stopped > [06/Feb/2015:17:09:08 -0500] - import userRoot: Import complete. > Processed 1 entries in 2 seconds. (0.50 entries/sec) > [06/Feb/2015:17:09:09 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 > starting up > [06/Feb/2015:17:09:09 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 > starting up > [06/Feb/2015:17:09:09 -0500] - Db home directory is not set. Possibly > nsslapd-directory (optionally nsslapd-db-home-directory) is missing in > the config file. > [06/Feb/2015:17:09:10 -0500] - I'm resizing my cache now...cache was > 3348811776 and is now 6400000 > [06/Feb/2015:17:09:11 -0500] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [06/Feb/2015:17:09:11 -0500] - The change of nsslapd-ldapilisten will > not take effect until the server is restarted > [06/Feb/2015:17:09:12 -0500] - Warning: Adding configuration attribute > "nsslapd-security" > [06/Feb/2015:17:09:13 -0500] - slapd shutting down - signaling > operation threads - op stack size 2 max work q size 1 max work q stack > size 1 > [06/Feb/2015:17:09:13 -0500] - slapd shutting down - closing down > internal subsystems and plugins > [06/Feb/2015:17:09:13 -0500] - Waiting for 4 database threads to stop > [06/Feb/2015:17:09:13 -0500] - All database threads now stopped > [06/Feb/2015:17:09:13 -0500] - slapd shutting down - freed 1 work q > stack objects - freed 2 op stack objects > [06/Feb/2015:17:09:13 -0500] - slapd stopped. > [06/Feb/2015:17:09:14 -0500] - SSL alert: Configured NSS Ciphers > [06/Feb/2015:17:09:14 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:17:09:15 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:17:09:15 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:17:09:15 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:17:09:15 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:17:09:15 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:17:09:15 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:17:09:15 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:17:09:15 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:17:09:15 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:17:09:15 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:17:09:15 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:17:09:15 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:17:09:15 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:17:09:15 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:17:09:15 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:17:09:16 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled > [06/Feb/2015:17:09:16 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:17:09:16 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:17:09:16 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:17:09:16 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:17:09:16 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:17:09:16 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:17:09:16 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:17:09:16 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:17:09:16 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:17:09:16 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:17:09:16 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:17:09:16 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA256: enabled > [06/Feb/2015:17:09:17 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:17:09:17 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: > enabled > [06/Feb/2015:17:09:17 -0500] SSL Initialization - SSL version range: > min: TLS1.0, max: TLS1.2 > [06/Feb/2015:17:09:17 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 > starting up > [06/Feb/2015:17:09:17 -0500] - I'm resizing my cache now...cache was > 6400000 and is now 5120000 > [06/Feb/2015:17:09:17 -0500] attrcrypt - No symmetric key found for > cipher AES in backend userRoot, attempting to create one... > [06/Feb/2015:17:09:17 -0500] attrcrypt - Key for cipher AES > successfully generated and stored > [06/Feb/2015:17:09:17 -0500] attrcrypt - No symmetric key found for > cipher 3DES in backend userRoot, attempting to create one... > [06/Feb/2015:17:09:17 -0500] attrcrypt - Key for cipher 3DES > successfully generated and stored > [06/Feb/2015:17:09:18 -0500] ipalockout_get_global_config - [file > ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) > [06/Feb/2015:17:09:18 -0500] ipaenrollment_start - [file > ipa_enrollment.c, line 393]: Failed to get default realm?! > [06/Feb/2015:17:09:18 -0500] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [06/Feb/2015:17:09:18 -0500] - Listening on All Interfaces port 636 > for LDAPS requests > [06/Feb/2015:17:09:18 -0500] - Listening on > /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests > [06/Feb/2015:17:09:18 -0500] - slapd shutting down - signaling > operation threads - op stack size 1 max work q size 1 max work q stack > size 1 > [06/Feb/2015:17:09:18 -0500] - slapd shutting down - waiting for 17 > threads to terminate > [06/Feb/2015:17:09:18 -0500] - slapd shutting down - closing down > internal subsystems and plugins > [06/Feb/2015:17:09:19 -0500] - Waiting for 4 database threads to stop > [06/Feb/2015:17:09:19 -0500] - All database threads now stopped > [06/Feb/2015:17:09:19 -0500] - slapd shutting down - freed 1 work q > stack objects - freed 1 op stack objects > [06/Feb/2015:17:09:19 -0500] - slapd stopped. > [06/Feb/2015:17:09:20 -0500] - SSL alert: Configured NSS Ciphers > [06/Feb/2015:17:09:20 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:17:09:20 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:17:09:20 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:17:09:20 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:17:09:20 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:17:09:20 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_GCM_SHA256: enabled > [06/Feb/2015:17:09:21 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA: enabled > [06/Feb/2015:17:09:22 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA256: enabled > [06/Feb/2015:17:09:22 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [06/Feb/2015:17:09:22 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA: enabled > [06/Feb/2015:17:09:22 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA256: enabled > [06/Feb/2015:17:09:22 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [06/Feb/2015:17:09:22 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: > enabled > [06/Feb/2015:17:09:22 -0500] SSL Initialization - SSL version range: > min: TLS1.0, max: TLS1.2 > [06/Feb/2015:17:09:22 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 > starting up > [06/Feb/2015:17:09:22 -0500] - I'm resizing my cache now...cache was > 5120000 and is now 4096000 > [06/Feb/2015:17:09:23 -0500] ipalockout_get_global_config - [file > ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) > [06/Feb/2015:17:09:23 -0500] ipaenrollment_start - [file > ipa_enrollment.c, line 393]: Failed to get default realm?! > [06/Feb/2015:17:09:23 -0500] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [06/Feb/2015:17:09:23 -0500] - Listening on All Interfaces port 636 > for LDAPS requests > [06/Feb/2015:17:09:23 -0500] - Listening on > /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests > [06/Feb/2015:17:09:23 -0500] NSMMReplicationPlugin - > agmt="cn=meToidm.cs.oberlin.edu" (idm: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. > [06/Feb/2015:17:09:24 -0500] schema - [C] Local objectClasses must not > be overwritten (set replication log for additional info) > [06/Feb/2015:17:09:25 -0500] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=cs,dc=oberlin,dc=edu is going > offline; disabling replication > [06/Feb/2015:17:09:25 -0500] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to > access the database > [06/Feb/2015:17:09:45 -0500] - import userRoot: Processed 2000 entries > -- average rate 100.0/sec, recent rate 100.0/sec, hit ratio 0% > [06/Feb/2015:17:10:05 -0500] - import userRoot: Processed 2000 entries > -- average rate 48.8/sec, recent rate 48.8/sec, hit ratio 0% > [06/Feb/2015:17:10:25 -0500] - import userRoot: Processed 2000 entries > -- average rate 32.8/sec, recent rate 0.0/sec, hit ratio 0% > [06/Feb/2015:17:10:45 -0500] - import userRoot: Processed 2000 entries > -- average rate 24.7/sec, recent rate 0.0/sec, hit ratio 0% > [06/Feb/2015:17:11:05 -0500] - import userRoot: Processed 2000 entries > -- average rate 19.8/sec, recent rate 0.0/sec, hit ratio 0% > [06/Feb/2015:17:11:26 -0500] - import userRoot: Processed 2000 entries > -- average rate 16.5/sec, recent rate 0.0/sec, hit ratio 0% > [06/Feb/2015:17:11:33 -0500] - import userRoot: Workers finished; > cleaning up... > [06/Feb/2015:17:11:33 -0500] - import userRoot: Workers cleaned up. > [06/Feb/2015:17:11:33 -0500] - import userRoot: Indexing complete. > Post-processing... > [06/Feb/2015:17:11:33 -0500] - import userRoot: Generating > numsubordinates (this may take several minutes to complete)... > [06/Feb/2015:17:11:34 -0500] - import userRoot: Generating > numSubordinates complete. > [06/Feb/2015:17:11:34 -0500] - import userRoot: Gathering ancestorid > non-leaf IDs... > [06/Feb/2015:17:11:34 -0500] - import userRoot: Finished gathering > ancestorid non-leaf IDs. > [06/Feb/2015:17:11:34 -0500] - import userRoot: Creating ancestorid > index (new idl)... > [06/Feb/2015:17:11:34 -0500] - import userRoot: Created ancestorid > index (new idl). > [06/Feb/2015:17:11:34 -0500] - import userRoot: Flushing caches... > [06/Feb/2015:17:11:34 -0500] - import userRoot: Closing files... > [06/Feb/2015:17:11:36 -0500] - import userRoot: Import complete. > Processed 2264 entries in 131 seconds. (17.28 entries/sec) > [06/Feb/2015:17:11:36 -0500] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=cs,dc=oberlin,dc=edu is coming > online; enabling replication > [06/Feb/2015:17:11:36 -0500] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=cs,dc=oberlin,dc=edu--no CoS Templates found, > which should be added before the CoS Definition. -------------- next part -------------- 389-Directory/1.3.3.5 B2014.289.1826 ipa.cs.oberlin.edu:389 (/etc/dirsrv/slapd-CS-OBERLIN-EDU) [06/Feb/2015:11:11:58 -0500] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [06/Feb/2015:11:11:58 -0500] - check_and_set_import_cache: pagesize: 4096, pages: 2043953, procpages: 55635 [06/Feb/2015:11:11:58 -0500] - Import allocates 3270324KB import cache. [06/Feb/2015:11:11:59 -0500] - import userRoot: Beginning import job... [06/Feb/2015:11:11:59 -0500] - import userRoot: Index buffering enabled with bucket size 100 [06/Feb/2015:11:11:59 -0500] - import userRoot: Processing file "/var/lib/dirsrv/boot.ldif" [06/Feb/2015:11:11:59 -0500] - import userRoot: Finished scanning file "/var/lib/dirsrv/boot.ldif" (1 entries) [06/Feb/2015:11:12:01 -0500] - import userRoot: Workers finished; cleaning up... [06/Feb/2015:11:12:01 -0500] - import userRoot: Workers cleaned up. [06/Feb/2015:11:12:01 -0500] - import userRoot: Cleaning up producer thread... [06/Feb/2015:11:12:01 -0500] - import userRoot: Indexing complete. Post-processing... [06/Feb/2015:11:12:01 -0500] - import userRoot: Generating numsubordinates (this may take several minutes to complete)... [06/Feb/2015:11:12:02 -0500] - import userRoot: Generating numSubordinates complete. [06/Feb/2015:11:12:02 -0500] - import userRoot: Gathering ancestorid non-leaf IDs... [06/Feb/2015:11:12:02 -0500] - import userRoot: Finished gathering ancestorid non-leaf IDs. [06/Feb/2015:11:12:02 -0500] - Nothing to do to build ancestorid index [06/Feb/2015:11:12:02 -0500] - import userRoot: Created ancestorid index (new idl). [06/Feb/2015:11:12:02 -0500] - import userRoot: Flushing caches... [06/Feb/2015:11:12:02 -0500] - import userRoot: Closing files... [06/Feb/2015:11:12:02 -0500] - All database threads now stopped [06/Feb/2015:11:12:02 -0500] - import userRoot: Import complete. Processed 1 entries in 3 seconds. (0.33 entries/sec) [06/Feb/2015:11:12:04 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 starting up [06/Feb/2015:11:12:04 -0500] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. [06/Feb/2015:11:12:04 -0500] - I'm resizing my cache now...cache was 3348811776 and is now 6400000 [06/Feb/2015:11:12:05 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [06/Feb/2015:11:12:05 -0500] - slapd shutting down - signaling operation threads - op stack size 0 max work q size 0 max work q stack size 0 [06/Feb/2015:11:12:06 -0500] - slapd shutting down - closing down internal subsystems and plugins [06/Feb/2015:11:12:06 -0500] - Waiting for 4 database threads to stop [06/Feb/2015:11:12:07 -0500] - All database threads now stopped [06/Feb/2015:11:12:07 -0500] - slapd shutting down - freed 0 work q stack objects - freed 0 op stack objects [06/Feb/2015:11:12:07 -0500] - slapd stopped. [06/Feb/2015:11:12:09 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 starting up [06/Feb/2015:11:12:09 -0500] - I'm resizing my cache now...cache was 6400000 and is now 5120000 [06/Feb/2015:11:12:09 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [06/Feb/2015:11:12:19 -0500] - The change of nsslapd-ldapilisten will not take effect until the server is restarted [06/Feb/2015:11:12:24 -0500] - Warning: Adding configuration attribute "nsslapd-security" [06/Feb/2015:11:12:25 -0500] - slapd shutting down - signaling operation threads - op stack size 2 max work q size 1 max work q stack size 1 [06/Feb/2015:11:12:25 -0500] - slapd shutting down - waiting for 29 threads to terminate [06/Feb/2015:11:12:25 -0500] - slapd shutting down - closing down internal subsystems and plugins [06/Feb/2015:11:12:25 -0500] - Waiting for 4 database threads to stop [06/Feb/2015:11:12:26 -0500] - All database threads now stopped [06/Feb/2015:11:12:26 -0500] - slapd shutting down - freed 1 work q stack objects - freed 2 op stack objects [06/Feb/2015:11:12:26 -0500] - slapd stopped. [06/Feb/2015:11:12:28 -0500] - SSL alert: Configured NSS Ciphers [06/Feb/2015:11:12:28 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:11:12:28 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:11:12:28 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:12:28 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:12:28 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:12:28 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:11:12:28 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:11:12:28 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:12:28 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:11:12:28 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:12:28 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:12:28 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:11:12:28 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:11:12:29 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:11:12:29 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:12:29 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:12:29 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [06/Feb/2015:11:12:29 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:11:12:29 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:11:12:29 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:12:29 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:12:29 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:12:29 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:12:29 -0500] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:11:12:29 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:12:29 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:11:12:29 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:11:12:29 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:12:29 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [06/Feb/2015:11:12:30 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:11:12:30 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled [06/Feb/2015:11:12:30 -0500] SSL Initialization - SSL version range: min: TLS1.0, max: TLS1.2 [06/Feb/2015:11:12:30 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 starting up [06/Feb/2015:11:12:30 -0500] - I'm resizing my cache now...cache was 5120000 and is now 4096000 [06/Feb/2015:11:12:30 -0500] attrcrypt - No symmetric key found for cipher AES in backend userRoot, attempting to create one... [06/Feb/2015:11:12:31 -0500] attrcrypt - Key for cipher AES successfully generated and stored [06/Feb/2015:11:12:31 -0500] attrcrypt - No symmetric key found for cipher 3DES in backend userRoot, attempting to create one... [06/Feb/2015:11:12:31 -0500] attrcrypt - Key for cipher 3DES successfully generated and stored [06/Feb/2015:11:12:31 -0500] ipalockout_get_global_config - [file ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) [06/Feb/2015:11:12:32 -0500] ipaenrollment_start - [file ipa_enrollment.c, line 393]: Failed to get default realm?! [06/Feb/2015:11:12:32 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [06/Feb/2015:11:12:32 -0500] - Listening on All Interfaces port 636 for LDAPS requests [06/Feb/2015:11:12:32 -0500] - Listening on /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests [06/Feb/2015:11:12:33 -0500] - slapd shutting down - signaling operation threads - op stack size 1 max work q size 1 max work q stack size 1 [06/Feb/2015:11:12:33 -0500] - slapd shutting down - waiting for 2 threads to terminate [06/Feb/2015:11:12:33 -0500] - slapd shutting down - closing down internal subsystems and plugins [06/Feb/2015:11:12:33 -0500] - Waiting for 4 database threads to stop [06/Feb/2015:11:12:34 -0500] - All database threads now stopped [06/Feb/2015:11:12:34 -0500] - slapd shutting down - freed 1 work q stack objects - freed 1 op stack objects [06/Feb/2015:11:12:34 -0500] - slapd stopped. [06/Feb/2015:11:12:35 -0500] - SSL alert: Configured NSS Ciphers [06/Feb/2015:11:12:35 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:11:12:35 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:11:12:35 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:12:35 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:12:36 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:12:36 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:11:12:36 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:11:12:36 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:12:36 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:11:12:36 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:12:36 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:12:36 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:11:12:36 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:11:12:36 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:11:12:36 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:12:36 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:12:36 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [06/Feb/2015:11:12:37 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:11:12:37 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:11:12:37 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:12:37 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:12:37 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:12:37 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:12:37 -0500] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:11:12:37 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:12:37 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:11:12:37 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:11:12:37 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:12:37 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [06/Feb/2015:11:12:37 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:11:12:38 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled [06/Feb/2015:11:12:38 -0500] SSL Initialization - SSL version range: min: TLS1.0, max: TLS1.2 [06/Feb/2015:11:12:38 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 starting up [06/Feb/2015:11:12:38 -0500] - I'm resizing my cache now...cache was 4096000 and is now 3276800 [06/Feb/2015:11:12:38 -0500] ipalockout_get_global_config - [file ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) [06/Feb/2015:11:12:38 -0500] ipaenrollment_start - [file ipa_enrollment.c, line 393]: Failed to get default realm?! [06/Feb/2015:11:12:39 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [06/Feb/2015:11:12:39 -0500] - Listening on All Interfaces port 636 for LDAPS requests [06/Feb/2015:11:12:39 -0500] - Listening on /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests [06/Feb/2015:11:12:40 -0500] NSMMReplicationPlugin - agmt="cn=meToidm.cs.oberlin.edu" (idm: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. [06/Feb/2015:11:12:40 -0500] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=cs,dc=oberlin,dc=edu is going offline; disabling replication [06/Feb/2015:11:12:41 -0500] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [06/Feb/2015:11:12:43 -0500] schema - [C] Local objectClasses must not be overwritten (set replication log for additional info) [06/Feb/2015:11:13:01 -0500] - import userRoot: Processed 1828 entries -- average rate 91.4/sec, recent rate 91.3/sec, hit ratio 0% [06/Feb/2015:11:13:21 -0500] - import userRoot: Processed 1828 entries -- average rate 45.7/sec, recent rate 45.7/sec, hit ratio 0% [06/Feb/2015:11:13:41 -0500] - import userRoot: Processed 1828 entries -- average rate 30.5/sec, recent rate 0.0/sec, hit ratio 0% [06/Feb/2015:11:14:01 -0500] - import userRoot: Processed 1828 entries -- average rate 22.9/sec, recent rate 0.0/sec, hit ratio 0% [06/Feb/2015:11:14:21 -0500] - import userRoot: Processed 1828 entries -- average rate 18.3/sec, recent rate 0.0/sec, hit ratio 0% [06/Feb/2015:11:14:41 -0500] - import userRoot: Processed 1828 entries -- average rate 15.2/sec, recent rate 0.0/sec, hit ratio 0% [06/Feb/2015:11:14:51 -0500] - import userRoot: Workers finished; cleaning up... [06/Feb/2015:11:14:52 -0500] - import userRoot: Workers cleaned up. [06/Feb/2015:11:14:52 -0500] - import userRoot: Indexing complete. Post-processing... [06/Feb/2015:11:14:52 -0500] - import userRoot: Generating numsubordinates (this may take several minutes to complete)... [06/Feb/2015:11:14:52 -0500] - import userRoot: Generating numSubordinates complete. [06/Feb/2015:11:14:52 -0500] - import userRoot: Gathering ancestorid non-leaf IDs... [06/Feb/2015:11:14:52 -0500] - import userRoot: Finished gathering ancestorid non-leaf IDs. [06/Feb/2015:11:14:53 -0500] - import userRoot: Creating ancestorid index (new idl)... [06/Feb/2015:11:14:53 -0500] - import userRoot: Created ancestorid index (new idl). [06/Feb/2015:11:14:53 -0500] - import userRoot: Flushing caches... [06/Feb/2015:11:14:53 -0500] - import userRoot: Closing files... [06/Feb/2015:11:14:55 -0500] - import userRoot: Import complete. Processed 2088 entries in 135 seconds. (15.47 entries/sec) [06/Feb/2015:11:14:55 -0500] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=cs,dc=oberlin,dc=edu is coming online; enabling replication [06/Feb/2015:11:14:56 -0500] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=cs,dc=oberlin,dc=edu--no CoS Templates found, which should be added before the CoS Definition. [06/Feb/2015:11:43:39 -0500] - slapd shutting down - signaling operation threads - op stack size 2 max work q size 1 max work q stack size 1 [06/Feb/2015:11:43:39 -0500] - slapd shutting down - closing down internal subsystems and plugins [06/Feb/2015:11:43:40 -0500] - Waiting for 4 database threads to stop [06/Feb/2015:11:43:40 -0500] - All database threads now stopped [06/Feb/2015:11:43:40 -0500] - slapd shutting down - freed 1 work q stack objects - freed 2 op stack objects [06/Feb/2015:11:43:40 -0500] - slapd stopped. [06/Feb/2015:11:45:30 -0500] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [06/Feb/2015:11:45:31 -0500] - check_and_set_import_cache: pagesize: 4096, pages: 2043953, procpages: 55634 [06/Feb/2015:11:45:31 -0500] - Import allocates 3270324KB import cache. [06/Feb/2015:11:45:31 -0500] - import userRoot: Beginning import job... [06/Feb/2015:11:45:31 -0500] - import userRoot: Index buffering enabled with bucket size 100 [06/Feb/2015:11:45:31 -0500] - import userRoot: Processing file "/var/lib/dirsrv/boot.ldif" [06/Feb/2015:11:45:31 -0500] - import userRoot: Finished scanning file "/var/lib/dirsrv/boot.ldif" (1 entries) [06/Feb/2015:11:45:32 -0500] - import userRoot: Workers finished; cleaning up... [06/Feb/2015:11:45:32 -0500] - import userRoot: Workers cleaned up. [06/Feb/2015:11:45:32 -0500] - import userRoot: Cleaning up producer thread... [06/Feb/2015:11:45:32 -0500] - import userRoot: Indexing complete. Post-processing... [06/Feb/2015:11:45:32 -0500] - import userRoot: Generating numsubordinates (this may take several minutes to complete)... [06/Feb/2015:11:45:32 -0500] - import userRoot: Generating numSubordinates complete. [06/Feb/2015:11:45:33 -0500] - import userRoot: Gathering ancestorid non-leaf IDs... [06/Feb/2015:11:45:33 -0500] - import userRoot: Finished gathering ancestorid non-leaf IDs. [06/Feb/2015:11:45:33 -0500] - Nothing to do to build ancestorid index [06/Feb/2015:11:45:33 -0500] - import userRoot: Created ancestorid index (new idl). [06/Feb/2015:11:45:33 -0500] - import userRoot: Flushing caches... [06/Feb/2015:11:45:33 -0500] - import userRoot: Closing files... [06/Feb/2015:11:45:33 -0500] - All database threads now stopped [06/Feb/2015:11:45:33 -0500] - import userRoot: Import complete. Processed 1 entries in 2 seconds. (0.50 entries/sec) [06/Feb/2015:11:45:34 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 starting up [06/Feb/2015:11:45:34 -0500] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. [06/Feb/2015:11:45:34 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 starting up [06/Feb/2015:11:45:34 -0500] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. [06/Feb/2015:11:45:34 -0500] - I'm resizing my cache now...cache was 3348811776 and is now 6400000 [06/Feb/2015:11:45:35 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [06/Feb/2015:11:45:35 -0500] - The change of nsslapd-ldapilisten will not take effect until the server is restarted [06/Feb/2015:11:45:52 -0500] - Warning: Adding configuration attribute "nsslapd-security" [06/Feb/2015:11:45:52 -0500] - slapd shutting down - signaling operation threads - op stack size 2 max work q size 1 max work q stack size 1 [06/Feb/2015:11:45:52 -0500] - slapd shutting down - waiting for 29 threads to terminate [06/Feb/2015:11:45:53 -0500] - slapd shutting down - closing down internal subsystems and plugins [06/Feb/2015:11:45:53 -0500] - Waiting for 4 database threads to stop [06/Feb/2015:11:45:54 -0500] - All database threads now stopped [06/Feb/2015:11:45:54 -0500] - slapd shutting down - freed 1 work q stack objects - freed 2 op stack objects [06/Feb/2015:11:45:54 -0500] - slapd stopped. [06/Feb/2015:11:45:56 -0500] - SSL alert: Configured NSS Ciphers [06/Feb/2015:11:45:56 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:11:45:56 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:11:45:56 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:45:56 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:45:56 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:45:56 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:11:45:56 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:11:45:56 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:45:56 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:11:45:56 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:45:56 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:45:56 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:11:45:56 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:11:45:57 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:11:45:57 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:45:57 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:45:57 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [06/Feb/2015:11:45:57 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:11:45:57 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:11:45:57 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:45:57 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:45:58 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:45:58 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:45:58 -0500] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:11:45:58 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:45:58 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:11:45:58 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:11:45:58 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:45:58 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [06/Feb/2015:11:45:58 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:11:45:58 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled [06/Feb/2015:11:45:58 -0500] SSL Initialization - SSL version range: min: TLS1.0, max: TLS1.2 [06/Feb/2015:11:45:58 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 starting up [06/Feb/2015:11:45:58 -0500] - I'm resizing my cache now...cache was 6400000 and is now 5120000 [06/Feb/2015:11:45:59 -0500] attrcrypt - No symmetric key found for cipher AES in backend userRoot, attempting to create one... [06/Feb/2015:11:45:59 -0500] attrcrypt - Key for cipher AES successfully generated and stored [06/Feb/2015:11:45:59 -0500] attrcrypt - No symmetric key found for cipher 3DES in backend userRoot, attempting to create one... [06/Feb/2015:11:45:59 -0500] attrcrypt - Key for cipher 3DES successfully generated and stored [06/Feb/2015:11:45:59 -0500] ipalockout_get_global_config - [file ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) [06/Feb/2015:11:46:00 -0500] ipaenrollment_start - [file ipa_enrollment.c, line 393]: Failed to get default realm?! [06/Feb/2015:11:46:00 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [06/Feb/2015:11:46:00 -0500] - Listening on All Interfaces port 636 for LDAPS requests [06/Feb/2015:11:46:00 -0500] - Listening on /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests [06/Feb/2015:11:46:00 -0500] - slapd shutting down - signaling operation threads - op stack size 1 max work q size 1 max work q stack size 1 [06/Feb/2015:11:46:00 -0500] - slapd shutting down - waiting for 27 threads to terminate [06/Feb/2015:11:46:00 -0500] - slapd shutting down - closing down internal subsystems and plugins [06/Feb/2015:11:46:00 -0500] - Waiting for 4 database threads to stop [06/Feb/2015:11:46:00 -0500] - All database threads now stopped [06/Feb/2015:11:46:01 -0500] - slapd shutting down - freed 1 work q stack objects - freed 1 op stack objects [06/Feb/2015:11:46:01 -0500] - slapd stopped. [06/Feb/2015:11:46:02 -0500] - SSL alert: Configured NSS Ciphers [06/Feb/2015:11:46:02 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:11:46:02 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:11:46:02 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:46:02 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:46:02 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:46:02 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:11:46:02 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:11:46:02 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:11:46:03 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:11:46:04 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:11:46:04 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [06/Feb/2015:11:46:04 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:11:46:04 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled [06/Feb/2015:11:46:04 -0500] SSL Initialization - SSL version range: min: TLS1.0, max: TLS1.2 [06/Feb/2015:11:46:04 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 starting up [06/Feb/2015:11:46:04 -0500] - I'm resizing my cache now...cache was 5120000 and is now 4096000 [06/Feb/2015:11:46:05 -0500] ipalockout_get_global_config - [file ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) [06/Feb/2015:11:46:05 -0500] ipaenrollment_start - [file ipa_enrollment.c, line 393]: Failed to get default realm?! [06/Feb/2015:11:46:05 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [06/Feb/2015:11:46:05 -0500] - Listening on All Interfaces port 636 for LDAPS requests [06/Feb/2015:11:46:05 -0500] - Listening on /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests [06/Feb/2015:11:46:06 -0500] NSMMReplicationPlugin - agmt="cn=meToidm.cs.oberlin.edu" (idm: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. [06/Feb/2015:11:46:06 -0500] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=cs,dc=oberlin,dc=edu is going offline; disabling replication [06/Feb/2015:11:46:07 -0500] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [06/Feb/2015:11:46:09 -0500] schema - [C] Local objectClasses must not be overwritten (set replication log for additional info) [06/Feb/2015:11:46:27 -0500] - import userRoot: Processed 1917 entries -- average rate 95.8/sec, recent rate 95.8/sec, hit ratio 0% [06/Feb/2015:11:46:47 -0500] - import userRoot: Processed 1917 entries -- average rate 47.9/sec, recent rate 47.9/sec, hit ratio 0% [06/Feb/2015:11:47:07 -0500] - import userRoot: Processed 1917 entries -- average rate 31.9/sec, recent rate 0.0/sec, hit ratio 0% [06/Feb/2015:11:47:27 -0500] - import userRoot: Processed 1917 entries -- average rate 24.0/sec, recent rate 0.0/sec, hit ratio 0% [06/Feb/2015:11:47:47 -0500] - import userRoot: Processed 1917 entries -- average rate 19.2/sec, recent rate 0.0/sec, hit ratio 0% [06/Feb/2015:11:48:07 -0500] - import userRoot: Processed 1917 entries -- average rate 16.0/sec, recent rate 0.0/sec, hit ratio 0% [06/Feb/2015:11:48:17 -0500] - import userRoot: Workers finished; cleaning up... [06/Feb/2015:11:48:18 -0500] - import userRoot: Workers cleaned up. [06/Feb/2015:11:48:18 -0500] - import userRoot: Indexing complete. Post-processing... [06/Feb/2015:11:48:18 -0500] - import userRoot: Generating numsubordinates (this may take several minutes to complete)... [06/Feb/2015:11:48:18 -0500] - import userRoot: Generating numSubordinates complete. [06/Feb/2015:11:48:18 -0500] - import userRoot: Gathering ancestorid non-leaf IDs... [06/Feb/2015:11:48:18 -0500] - import userRoot: Finished gathering ancestorid non-leaf IDs. [06/Feb/2015:11:48:18 -0500] - import userRoot: Creating ancestorid index (new idl)... [06/Feb/2015:11:48:18 -0500] - import userRoot: Created ancestorid index (new idl). [06/Feb/2015:11:48:18 -0500] - import userRoot: Flushing caches... [06/Feb/2015:11:48:18 -0500] - import userRoot: Closing files... [06/Feb/2015:11:48:20 -0500] - import userRoot: Import complete. Processed 2240 entries in 133 seconds. (16.84 entries/sec) [06/Feb/2015:11:48:20 -0500] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=cs,dc=oberlin,dc=edu is coming online; enabling replication [06/Feb/2015:11:48:21 -0500] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=cs,dc=oberlin,dc=edu--no CoS Templates found, which should be added before the CoS Definition. [06/Feb/2015:12:12:59 -0500] - slapd shutting down - signaling operation threads - op stack size 2 max work q size 1 max work q stack size 1 [06/Feb/2015:12:13:00 -0500] - slapd shutting down - waiting for 28 threads to terminate [06/Feb/2015:12:13:00 -0500] - slapd shutting down - closing down internal subsystems and plugins [06/Feb/2015:12:13:00 -0500] - Waiting for 4 database threads to stop [06/Feb/2015:12:13:01 -0500] - All database threads now stopped [06/Feb/2015:12:13:01 -0500] - slapd shutting down - freed 1 work q stack objects - freed 2 op stack objects [06/Feb/2015:12:13:01 -0500] - slapd stopped. [06/Feb/2015:17:09:05 -0500] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [06/Feb/2015:17:09:06 -0500] - check_and_set_import_cache: pagesize: 4096, pages: 2043953, procpages: 55634 [06/Feb/2015:17:09:06 -0500] - Import allocates 3270324KB import cache. [06/Feb/2015:17:09:06 -0500] - import userRoot: Beginning import job... [06/Feb/2015:17:09:06 -0500] - import userRoot: Index buffering enabled with bucket size 100 [06/Feb/2015:17:09:06 -0500] - import userRoot: Processing file "/var/lib/dirsrv/boot.ldif" [06/Feb/2015:17:09:06 -0500] - import userRoot: Finished scanning file "/var/lib/dirsrv/boot.ldif" (1 entries) [06/Feb/2015:17:09:07 -0500] - import userRoot: Workers finished; cleaning up... [06/Feb/2015:17:09:07 -0500] - import userRoot: Workers cleaned up. [06/Feb/2015:17:09:07 -0500] - import userRoot: Cleaning up producer thread... [06/Feb/2015:17:09:08 -0500] - import userRoot: Indexing complete. Post-processing... [06/Feb/2015:17:09:08 -0500] - import userRoot: Generating numsubordinates (this may take several minutes to complete)... [06/Feb/2015:17:09:08 -0500] - import userRoot: Generating numSubordinates complete. [06/Feb/2015:17:09:08 -0500] - import userRoot: Gathering ancestorid non-leaf IDs... [06/Feb/2015:17:09:08 -0500] - import userRoot: Finished gathering ancestorid non-leaf IDs. [06/Feb/2015:17:09:08 -0500] - Nothing to do to build ancestorid index [06/Feb/2015:17:09:08 -0500] - import userRoot: Created ancestorid index (new idl). [06/Feb/2015:17:09:08 -0500] - import userRoot: Flushing caches... [06/Feb/2015:17:09:08 -0500] - import userRoot: Closing files... [06/Feb/2015:17:09:08 -0500] - All database threads now stopped [06/Feb/2015:17:09:08 -0500] - import userRoot: Import complete. Processed 1 entries in 2 seconds. (0.50 entries/sec) [06/Feb/2015:17:09:09 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 starting up [06/Feb/2015:17:09:09 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 starting up [06/Feb/2015:17:09:09 -0500] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. [06/Feb/2015:17:09:10 -0500] - I'm resizing my cache now...cache was 3348811776 and is now 6400000 [06/Feb/2015:17:09:11 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [06/Feb/2015:17:09:11 -0500] - The change of nsslapd-ldapilisten will not take effect until the server is restarted [06/Feb/2015:17:09:12 -0500] - Warning: Adding configuration attribute "nsslapd-security" [06/Feb/2015:17:09:13 -0500] - slapd shutting down - signaling operation threads - op stack size 2 max work q size 1 max work q stack size 1 [06/Feb/2015:17:09:13 -0500] - slapd shutting down - closing down internal subsystems and plugins [06/Feb/2015:17:09:13 -0500] - Waiting for 4 database threads to stop [06/Feb/2015:17:09:13 -0500] - All database threads now stopped [06/Feb/2015:17:09:13 -0500] - slapd shutting down - freed 1 work q stack objects - freed 2 op stack objects [06/Feb/2015:17:09:13 -0500] - slapd stopped. [06/Feb/2015:17:09:14 -0500] - SSL alert: Configured NSS Ciphers [06/Feb/2015:17:09:14 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:17:09:15 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:17:09:15 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:17:09:15 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:17:09:15 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:17:09:15 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:17:09:15 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:17:09:15 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:17:09:15 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:17:09:15 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:17:09:15 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:17:09:15 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:17:09:15 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:17:09:15 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:17:09:15 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:17:09:15 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:17:09:16 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [06/Feb/2015:17:09:16 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:17:09:16 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:17:09:16 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:17:09:16 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:17:09:16 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:17:09:16 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:17:09:16 -0500] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:17:09:16 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:17:09:16 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:17:09:16 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:17:09:16 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:17:09:16 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [06/Feb/2015:17:09:17 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:17:09:17 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled [06/Feb/2015:17:09:17 -0500] SSL Initialization - SSL version range: min: TLS1.0, max: TLS1.2 [06/Feb/2015:17:09:17 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 starting up [06/Feb/2015:17:09:17 -0500] - I'm resizing my cache now...cache was 6400000 and is now 5120000 [06/Feb/2015:17:09:17 -0500] attrcrypt - No symmetric key found for cipher AES in backend userRoot, attempting to create one... [06/Feb/2015:17:09:17 -0500] attrcrypt - Key for cipher AES successfully generated and stored [06/Feb/2015:17:09:17 -0500] attrcrypt - No symmetric key found for cipher 3DES in backend userRoot, attempting to create one... [06/Feb/2015:17:09:17 -0500] attrcrypt - Key for cipher 3DES successfully generated and stored [06/Feb/2015:17:09:18 -0500] ipalockout_get_global_config - [file ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) [06/Feb/2015:17:09:18 -0500] ipaenrollment_start - [file ipa_enrollment.c, line 393]: Failed to get default realm?! [06/Feb/2015:17:09:18 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [06/Feb/2015:17:09:18 -0500] - Listening on All Interfaces port 636 for LDAPS requests [06/Feb/2015:17:09:18 -0500] - Listening on /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests [06/Feb/2015:17:09:18 -0500] - slapd shutting down - signaling operation threads - op stack size 1 max work q size 1 max work q stack size 1 [06/Feb/2015:17:09:18 -0500] - slapd shutting down - waiting for 17 threads to terminate [06/Feb/2015:17:09:18 -0500] - slapd shutting down - closing down internal subsystems and plugins [06/Feb/2015:17:09:19 -0500] - Waiting for 4 database threads to stop [06/Feb/2015:17:09:19 -0500] - All database threads now stopped [06/Feb/2015:17:09:19 -0500] - slapd shutting down - freed 1 work q stack objects - freed 1 op stack objects [06/Feb/2015:17:09:19 -0500] - slapd stopped. [06/Feb/2015:17:09:20 -0500] - SSL alert: Configured NSS Ciphers [06/Feb/2015:17:09:20 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:17:09:20 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:17:09:20 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:17:09:20 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:17:09:20 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:17:09:20 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [06/Feb/2015:17:09:21 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [06/Feb/2015:17:09:22 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [06/Feb/2015:17:09:22 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [06/Feb/2015:17:09:22 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [06/Feb/2015:17:09:22 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [06/Feb/2015:17:09:22 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [06/Feb/2015:17:09:22 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled [06/Feb/2015:17:09:22 -0500] SSL Initialization - SSL version range: min: TLS1.0, max: TLS1.2 [06/Feb/2015:17:09:22 -0500] - 389-Directory/1.3.3.5 B2014.289.1826 starting up [06/Feb/2015:17:09:22 -0500] - I'm resizing my cache now...cache was 5120000 and is now 4096000 [06/Feb/2015:17:09:23 -0500] ipalockout_get_global_config - [file ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) [06/Feb/2015:17:09:23 -0500] ipaenrollment_start - [file ipa_enrollment.c, line 393]: Failed to get default realm?! [06/Feb/2015:17:09:23 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [06/Feb/2015:17:09:23 -0500] - Listening on All Interfaces port 636 for LDAPS requests [06/Feb/2015:17:09:23 -0500] - Listening on /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests [06/Feb/2015:17:09:23 -0500] NSMMReplicationPlugin - agmt="cn=meToidm.cs.oberlin.edu" (idm: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. [06/Feb/2015:17:09:24 -0500] schema - [C] Local objectClasses must not be overwritten (set replication log for additional info) [06/Feb/2015:17:09:25 -0500] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=cs,dc=oberlin,dc=edu is going offline; disabling replication [06/Feb/2015:17:09:25 -0500] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [06/Feb/2015:17:09:45 -0500] - import userRoot: Processed 2000 entries -- average rate 100.0/sec, recent rate 100.0/sec, hit ratio 0% [06/Feb/2015:17:10:05 -0500] - import userRoot: Processed 2000 entries -- average rate 48.8/sec, recent rate 48.8/sec, hit ratio 0% [06/Feb/2015:17:10:25 -0500] - import userRoot: Processed 2000 entries -- average rate 32.8/sec, recent rate 0.0/sec, hit ratio 0% [06/Feb/2015:17:10:45 -0500] - import userRoot: Processed 2000 entries -- average rate 24.7/sec, recent rate 0.0/sec, hit ratio 0% [06/Feb/2015:17:11:05 -0500] - import userRoot: Processed 2000 entries -- average rate 19.8/sec, recent rate 0.0/sec, hit ratio 0% [06/Feb/2015:17:11:26 -0500] - import userRoot: Processed 2000 entries -- average rate 16.5/sec, recent rate 0.0/sec, hit ratio 0% [06/Feb/2015:17:11:33 -0500] - import userRoot: Workers finished; cleaning up... [06/Feb/2015:17:11:33 -0500] - import userRoot: Workers cleaned up. [06/Feb/2015:17:11:33 -0500] - import userRoot: Indexing complete. Post-processing... [06/Feb/2015:17:11:33 -0500] - import userRoot: Generating numsubordinates (this may take several minutes to complete)... [06/Feb/2015:17:11:34 -0500] - import userRoot: Generating numSubordinates complete. [06/Feb/2015:17:11:34 -0500] - import userRoot: Gathering ancestorid non-leaf IDs... [06/Feb/2015:17:11:34 -0500] - import userRoot: Finished gathering ancestorid non-leaf IDs. [06/Feb/2015:17:11:34 -0500] - import userRoot: Creating ancestorid index (new idl)... [06/Feb/2015:17:11:34 -0500] - import userRoot: Created ancestorid index (new idl). [06/Feb/2015:17:11:34 -0500] - import userRoot: Flushing caches... [06/Feb/2015:17:11:34 -0500] - import userRoot: Closing files... [06/Feb/2015:17:11:36 -0500] - import userRoot: Import complete. Processed 2264 entries in 131 seconds. (17.28 entries/sec) [06/Feb/2015:17:11:36 -0500] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=cs,dc=oberlin,dc=edu is coming online; enabling replication [06/Feb/2015:17:11:36 -0500] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=cs,dc=oberlin,dc=edu--no CoS Templates found, which should be added before the CoS Definition. -------------- next part -------------- A non-text attachment was scrubbed... Name: ipareplica-install.log Type: text/x-log Size: 60578 bytes Desc: not available URL: From dpal at redhat.com Mon Feb 9 14:31:57 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 09 Feb 2015 09:31:57 -0500 Subject: [Freeipa-users] error install replication In-Reply-To: References: <54D7565F.2030203@redhat.com> <54D768BC.7050602@redhat.com> <54D86685.8010106@redhat.com> <54D88816.9060904@redhat.com> <54D89EF1.3030401@redhat.com> Message-ID: <54D8C4DD.80308@redhat.com> On 02/09/2015 08:34 AM, alireza baghery wrote: > yes try "ssh admin at hostname" but do not work > ====log secure-==== > > Feb 9 15:42:20 ipasrv sshd[13414]: pam_unix(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.30.160.20 user=admin > Feb 9 15:42:20 ipasrv sshd[13414]: pam_sss(sshd:auth): authentication > success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.30.160.20 > user=admin > Feb 9 15:42:20 ipasrv sshd[13414]: pam_sss(sshd:account): Access > denied for user admin: 6 (Permission denied) > Feb 9 15:42:20 ipasrv sshd[13414]: Failed password for admin from > 10.30.160.20 port 52123 ssh2 > Feb 9 15:42:20 ipasrv sshd[13415]: fatal: Access denied for user > admin by PAM account configuration > Do you have HBAC rules? Does admin have the rights to log via SSH? If you changed the default rules it might be that admin is not allowed to log via ssh. > > On Mon, Feb 9, 2015 at 3:20 PM, Martin Kosek > wrote: > > Did you try the "ssh admin@`hostname`" command? It should show if > ssh to admin > via SSSD&FreeIPA really works. > > On 02/09/2015 11:18 AM, alireza baghery wrote: > > account admin recognize and show uid gid and groups > > On Feb 9, 2015 1:42 PM, "Martin Kosek" > wrote: > > > >> Ok. When on the server, does > >> > >> # id admin > >> > >> or "ssh admin@`hostname`" work? Maybe it does not recognize the > admin > >> user. > >> > >> On 02/09/2015 09:29 AM, alireza baghery wrote: > >>> ipasrv# Service SSSD status > >>> sssd is runing > >>> nevertheless i restart service sssd > >>> but problem do not solved > >>> > >>> On Mon, Feb 9, 2015 at 11:19 AM, Martin Kosek > > wrote: > >>> > >>>> On 02/09/2015 07:42 AM, alireza baghery wrote: > >>>>> i check on both server ssh each other's name and ssh > successful and > >>>> resolve > >>>>> name was also correct on each server > >>>>> but i can not login with user admin from ipareplica via ssh > >>>> (root at ipareplica]# > >>>>> ssh admin at ipasrv ===> failed) > >>>>> > >>>>> [root at ipareplica ~]# ssh ipasrv > >>>>> root at ipasrv's password: > >>>>> Last login: Mon Feb 9 09:49:54 2015 from 10.30.160.20 > >>>>> =====log /var/secure==== > >>>>> Feb 9 09:50:29 ipasrv sshd[12076]: Accepted password for > root from > >>>>> 10.30.160.20 port 52110 ssh2 > >>>>> Feb 9 09:50:29 ipasrv sshd[12076]: pam_unix(sshd:session): > session > >>>> opened > >>>>> for user root by (uid=0) > >>>>> ===== > >>>>> [root at ipasrv ~]# ssh ipareplica > >>>>> root at ipareplica's password: > >>>>> Last login: Mon Feb 9 09:50:20 2015 from 10.30.160.19 > >>>>> > >>>>> ====== > >>>>> [root at ipareplica ~]# nslookup ipasrv > >>>>> Server: 10.30.160.19 > >>>>> Address: 10.30.160.19#53 > >>>>> > >>>>> Name: ipasrv > >>>>> Address: 10.30.160.19 > >>>>> > >>>>> ======== > >>>>> [root at ipasrv ~]# nslookup ipareplica > >>>>> Server: 127.0.0.1 > >>>>> Address: 127.0.0.1#53 > >>>>> > >>>>> Name: ipareplica > >>>>> Address: 10.30.160.20 > >>>>> ========= > >>>> > >>>> Ok, so ssh is running, you can log in with root. I think that > by 99% > >>>> chance, > >>>> your SSSD service is not running on the IPA server. Please > check if this > >>>> is the > >>>> case and if yes, please try to (re)start it. If that helped, > it would be > >>>> also > >>>> useful to see *why* the SSSD is not running (crash, > misconfiguration, > >> ...) > >>>> > >>>> Martin > >>>> > >>> > >>> > >>> > >> > >> > > > > > > -- 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 Mon Feb 9 14:48:21 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 09 Feb 2015 07:48:21 -0700 Subject: [Freeipa-users] How do I modify the entry cache size? In-Reply-To: References: <54D7EA1F.5030209@redhat.com> Message-ID: <54D8C8B5.2080102@redhat.com> On 02/08/2015 08:23 PM, Chris Mohler wrote: > Thanks for the reply and the link Rich! > > dbmon.sh is a handy tool indeed. > > I read the instructions and upped my entry cache size to 2gb because I > have enough ram. > Everything went well until > |service dirsrv restart > > | > |I Got the following errors: > [06/Feb/2015:10:07:35 -0500] - slapd stopped. > [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching rule [caseIgnoreIA5Match] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] > [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] > [06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up > [06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port 7389 for LDAP requests > [06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS requests > > | > |Oddly enough everything appears to be working. Are these messages safe to ignore? > | This is definitely not related to the cache size. |Not sure what the problem is - looks like something has done an override of the standard schema definition of dc. http://tools.ietf.org/html/rfc4519 defines it with syntax 1.3.6.1.4.1.1466.115.121.1.26. rpm -q 389-ds-base find /etc/dirsrv -name \*.ldif -exec grep 0.9.2342.19200300.100.1.25 {} /dev/null \; | > |Another run of dbmon.sh shows that my entry cache was increased. > > ||| > |Thanks, > | > |-Chris > | > | > | > > > On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson > wrote: > > On 02/07/2015 11:25 AM, Chris Mohler wrote: >> Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to increase the entry cache size >> I'm trying to follow the directions here >> /usr/lib/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389 >> >> dn: cn=/|database_name|/, cn=ldbm database, cn=plugins, cn=config >> changetype: modify >> replace: nsslapd-cachememsize >> nsslapd-cachememsize: 20971520 >> >> Is this the correct way to do this? How do I find out what the " >> cn=/|database_name" is supposed to be? >> |/ > > |/see /|https://github.com/richm/scripts/wiki/dbmon.sh - the > script will tell you what the names of your databases are. >> /| >> |/ >> /|Thanks, >> |/ >> /|-Chris >> |/ >> >> > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Feb 9 15:12:33 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Feb 2015 16:12:33 +0100 Subject: [Freeipa-users] error install replication In-Reply-To: <54D8C4DD.80308@redhat.com> References: <54D7565F.2030203@redhat.com> <54D768BC.7050602@redhat.com> <54D86685.8010106@redhat.com> <54D88816.9060904@redhat.com> <54D89EF1.3030401@redhat.com> <54D8C4DD.80308@redhat.com> Message-ID: <54D8CE61.5050702@redhat.com> On 02/09/2015 03:31 PM, Dmitri Pal wrote: > On 02/09/2015 08:34 AM, alireza baghery wrote: >> yes try "ssh admin at hostname" but do not work >> ====log secure-==== >> >> Feb 9 15:42:20 ipasrv sshd[13414]: pam_unix(sshd:auth): authentication >> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.30.160.20 user=admin >> Feb 9 15:42:20 ipasrv sshd[13414]: pam_sss(sshd:auth): authentication >> success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.30.160.20 user=admin >> Feb 9 15:42:20 ipasrv sshd[13414]: pam_sss(sshd:account): Access denied for >> user admin: 6 (Permission denied) >> Feb 9 15:42:20 ipasrv sshd[13414]: Failed password for admin from >> 10.30.160.20 port 52123 ssh2 >> Feb 9 15:42:20 ipasrv sshd[13415]: fatal: Access denied for user admin by >> PAM account configuration >> > > Do you have HBAC rules? Does admin have the rights to log via SSH? > If you changed the default rules it might be that admin is not allowed to log > via ssh. Good questions. Also note, that if for some special reasons, you do not want to make admins log in to your FreeIPA servers, you can always pass --skip-conncheck to the replica and go straight to the installation, skipping the firewall check. Of course, no guarantees that the installation won't get stuck or crash because of closed ports in that case. Martin From mkosek at redhat.com Mon Feb 9 15:18:49 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Feb 2015 16:18:49 +0100 Subject: [Freeipa-users] Upgrade from 3x to 4x cant create first replica. In-Reply-To: <54D54DDE.5040902@oberlin.edu> References: <54D54DDE.5040902@oberlin.edu> Message-ID: <54D8CFD9.1080602@redhat.com> On 02/07/2015 12:27 AM, Chris Mohler wrote: > I'm having some troubles. I have an older IPA install Version 3.0.0. on Centos > 6.6. It's currently the only master for my domain. I have about 4k user > accounts on here and it's a live system called "idm" > > I'm trying to upgrade to V4.x as I am hoping to fix some issues I am having. > (clients can't auth unless service sssd is restarted multiple times "10 (User > not known to the underlying authentication module") I think this is possibly > unrelated and the topic for another thread. > > I created a new VM and installed Fedora Server 21 and FreeIPA 4.1.2 it's called > "ipa" Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked in, so you can also use that platform if you are used to it. > > on the master "idm" I ran "ipa-replica-prepare" and transfered the file to the > future replica "ipa" Then I ran the install replica script ipa-replica-install > --setup-ca /home/svradm/replica-info-ipa.cs.oberlin.edu.gpg > Things went well until it failed > > [24/35]: setting up initial replication > Starting replication, please wait until this has completed. > Update in progress, 133 seconds elapsed > Update in progress yet not in progress > > Update in progress yet not in progress > > Update in progress yet not in progress > > [idm.cs.oberlin.edu] reports: Update failed! Status: [10 Total update > abortedLDAP error: Referral] > > [error] RuntimeError: Failed to start replication > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Please help I'm getting nowhere by myself. Can you please look on the master you are replicating from and look for errors in /var/log/messages or DS errors log? Maybe you will see messages like "ns-slapd: encoded packet size too big (xxxxxx > 65536)" that are know to pop up more with CentOS 6.6. From cmohler at oberlin.edu Mon Feb 9 15:26:22 2015 From: cmohler at oberlin.edu (Chris Mohler) Date: Mon, 09 Feb 2015 10:26:22 -0500 Subject: [Freeipa-users] How do I modify the entry cache size? In-Reply-To: <54D8C8B5.2080102@redhat.com> References: <54D7EA1F.5030209@redhat.com> <54D8C8B5.2080102@redhat.com> Message-ID: <54D8D19E.1080703@oberlin.edu> On 02/09/2015 09:48 AM, Rich Megginson wrote: > On 02/08/2015 08:23 PM, Chris Mohler wrote: >> Thanks for the reply and the link Rich! >> >> dbmon.sh is a handy tool indeed. >> >> I read the instructions and upped my entry cache size to 2gb because >> I have enough ram. >> Everything went well until >> |service dirsrv restart >> >> | >> |I Got the following errors: >> [06/Feb/2015:10:07:35 -0500] - slapd stopped. >> [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching rule [caseIgnoreIA5Match] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] >> [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] >> [06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up >> [06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port 7389 for LDAP requests >> [06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS requests >> >> | >> |Oddly enough everything appears to be working. Are these messages safe to ignore? >> | > > This is definitely not related to the cache size. > > |Not sure what the problem is - looks like something has done an > override of the standard schema definition of dc. > http://tools.ietf.org/html/rfc4519 defines it with syntax > 1.3.6.1.4.1.1466.115.121.1.26. > > rpm -q 389-ds-base > > find /etc/dirsrv -name \*.ldif -exec grep 0.9.2342.19200300.100.1.25 > {} /dev/null \; > > > | >> |Another run of dbmon.sh shows that my entry cache was increased. >> >> ||| >> |Thanks, >> | >> |-Chris >> | >> | >> | >> >> >> On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson > > wrote: >> >> On 02/07/2015 11:25 AM, Chris Mohler wrote: >>> Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to increase the entry cache size >>> I'm trying to follow the directions here >>> /usr/lib/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389 >>> >>> dn: cn=/|database_name|/, cn=ldbm database, cn=plugins, cn=config >>> changetype: modify >>> replace: nsslapd-cachememsize >>> nsslapd-cachememsize: 20971520 >>> >>> Is this the correct way to do this? How do I find out what the " >>> cn=/|database_name" is supposed to be? >>> |/ >> >> |/see /|https://github.com/richm/scripts/wiki/dbmon.sh - the >> script will tell you what the names of your databases are. >>> /| >>> |/ >>> /|Thanks, >>> |/ >>> /|-Chris >>> |/ >>> >>> >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> >> > > > Thanks again Rich, I have been having an abundance of issues with my FreeIPA server lately. I'm not surprised that error is not related. I was not sure as It has not surfaced in my logs before I changed the entry cache size. Possibly this will be the clue to get me on the road to recovery. > |Not sure what the problem is - looks like something has done an > override of the standard schema definition of dc. > http://tools.ietf.org/html/rfc4519 defines it with syntax > 1.3.6.1.4.1.1466.115.121.1.26.| I migrated from OpenLdap about a year ago. So my install is a migration. I also recently tried to add a replica. Which prompted me to update the schema on the master before it would replicate. > |rpm -q 389-ds-base| |389-ds-base-1.2.11.15-48.el6_6.x86_64 | > |find /etc/dirsrv -name \*.ldif -exec grep 0.9.2342.19200300.100.1.25 > {} /dev/null \;| | |/etc/dirsrv/slapd-PKI-IPA/schema.bak/00core.ldif:attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) /etc/dirsrv/slapd-PKI-IPA/schema/00core.ldif:attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) /etc/dirsrv/slapd-PKI-IPA/schema/05rfc2247.ldif:attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) DESC 'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'RFC 2247' ) /etc/dirsrv/schema/00core.ldif:attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) /etc/dirsrv/slapd-CS-OBERLIN-EDU/schema.bak/00core.ldif:attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) /etc/dirsrv/slapd-CS-OBERLIN-EDU/schema/00core.ldif:attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) Thanks again, -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmohler at oberlin.edu Mon Feb 9 16:16:22 2015 From: cmohler at oberlin.edu (Chris Mohler) Date: Mon, 09 Feb 2015 11:16:22 -0500 Subject: [Freeipa-users] Upgrade from 3x to 4x cant create first replica. In-Reply-To: <54D8CFD9.1080602@redhat.com> References: <54D54DDE.5040902@oberlin.edu> <54D8CFD9.1080602@redhat.com> Message-ID: <54D8DD56.2010903@oberlin.edu> On 02/09/2015 10:18 AM, Martin Kosek wrote: > On 02/07/2015 12:27 AM, Chris Mohler wrote: >> I'm having some troubles. I have an older IPA install Version 3.0.0. on Centos >> 6.6. It's currently the only master for my domain. I have about 4k user >> accounts on here and it's a live system called "idm" >> >> I'm trying to upgrade to V4.x as I am hoping to fix some issues I am having. >> (clients can't auth unless service sssd is restarted multiple times "10 (User >> not known to the underlying authentication module") I think this is possibly >> unrelated and the topic for another thread. >> >> I created a new VM and installed Fedora Server 21 and FreeIPA 4.1.2 it's called >> "ipa" > Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked > in, so you can also use that platform if you are used to it. > >> on the master "idm" I ran "ipa-replica-prepare" and transfered the file to the >> future replica "ipa" Then I ran the install replica script ipa-replica-install >> --setup-ca /home/svradm/replica-info-ipa.cs.oberlin.edu.gpg >> Things went well until it failed >> >> [24/35]: setting up initial replication >> Starting replication, please wait until this has completed. >> Update in progress, 133 seconds elapsed >> Update in progress yet not in progress >> >> Update in progress yet not in progress >> >> Update in progress yet not in progress >> >> [idm.cs.oberlin.edu] reports: Update failed! Status: [10 Total update >> abortedLDAP error: Referral] >> >> [error] RuntimeError: Failed to start replication >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> Please help I'm getting nowhere by myself. > Can you please look on the master you are replicating from and look for errors > in /var/log/messages or DS errors log? > > Maybe you will see messages like "ns-slapd: encoded packet size too big (xxxxxx >> 65536)" that are know to pop up more with CentOS 6.6. Hi Martin, Thanks for the reply and help I appreciate it. > Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked > in, so you can also use that platform if you are used to it. Good to know. I try to be distro agnostic. I've used Redhat 7.1 then went Solaris, then Ubuntu, Now I'm back for Centos and Fedora. I guess I'm equally uncomfortable with either version. That Said. Is there any reason that I could or should not have a replica on a Fedora 21 server and 2nd replica on a Centos 7.1 later? My understanding is the more the merrier. > Can you please look on the master you are replicating from and look for errors > in /var/log/messages or DS errors log? I tried to setup the replica again just now so I have some fresh logs. From the Dirserv error log [08/Feb/2015:22:14:48 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up [08/Feb/2015:22:14:48 -0500] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=cs,dc=oberlin,dc=edu [08/Feb/2015:22:14:50 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [08/Feb/2015:22:14:50 -0500] - Listening on All Interfaces port 636 for LDAPS requests [08/Feb/2015:22:14:50 -0500] - Listening on /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - agmt="cn=meToipa.cs.oberlin.edu" (ipa:389): Schema replication update failed: Server is unwilling to perform [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Warning: unable to replicate schema to host ipa.cs.oberlin.edu, port 389. Continuing with total update session. [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=meToipa.cs.oberlin.edu" (ipa:389)" To be fair and not duplicate efforts I have had the following error [08/Feb/2015:08:51:26 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 12115968B; We recommend to increase the entry cache size nsslapd-cachememsize. To which I have asked another question "how do I change the entry cache size" https://www.redhat.com/archives/freeipa-users/2015-February/msg00114.html I now get additional errors which I would guess are possibly related. > |[06/Feb/2015:10:07:35 -0500] - slapd stopped. > [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching rule [caseIgnoreIA5Match] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] > [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] > [06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up > [06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port 7389 for LDAP requests > [06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS requests| | Thanks again for having a look at my problem, -Chris | -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Feb 9 16:19:20 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 09 Feb 2015 09:19:20 -0700 Subject: [Freeipa-users] How do I modify the entry cache size? In-Reply-To: <54D8D19E.1080703@oberlin.edu> References: <54D7EA1F.5030209@redhat.com> <54D8C8B5.2080102@redhat.com> <54D8D19E.1080703@oberlin.edu> Message-ID: <54D8DE08.2010002@redhat.com> On 02/09/2015 08:26 AM, Chris Mohler wrote: > On 02/09/2015 09:48 AM, Rich Megginson wrote: >> On 02/08/2015 08:23 PM, Chris Mohler wrote: >>> Thanks for the reply and the link Rich! >>> >>> dbmon.sh is a handy tool indeed. >>> >>> I read the instructions and upped my entry cache size to 2gb because >>> I have enough ram. >>> Everything went well until >>> |service dirsrv restart >>> >>> | >>> |I Got the following errors: >>> [06/Feb/2015:10:07:35 -0500] - slapd stopped. >>> [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching rule [caseIgnoreIA5Match] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] >>> [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] >>> [06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up >>> [06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port 7389 for LDAP requests >>> [06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS requests >>> >>> | >>> |Oddly enough everything appears to be working. Are these messages safe to ignore? >>> | >> >> This is definitely not related to the cache size. >> >> |Not sure what the problem is - looks like something has done an >> override of the standard schema definition of dc. >> http://tools.ietf.org/html/rfc4519 defines it with syntax >> 1.3.6.1.4.1.1466.115.121.1.26. >> >> rpm -q 389-ds-base >> >> find /etc/dirsrv -name \*.ldif -exec grep 0.9.2342.19200300.100.1.25 >> {} /dev/null \; >> >> >> | >>> |Another run of dbmon.sh shows that my entry cache was increased. >>> >>> ||| >>> |Thanks, >>> | >>> |-Chris >>> | >>> | >>> | >>> >>> >>> On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson >> > wrote: >>> >>> On 02/07/2015 11:25 AM, Chris Mohler wrote: >>>> Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to increase the entry cache size >>>> I'm trying to follow the directions here >>>> /usr/lib/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389 >>>> >>>> dn: cn=/|database_name|/, cn=ldbm database, cn=plugins, cn=config >>>> changetype: modify >>>> replace: nsslapd-cachememsize >>>> nsslapd-cachememsize: 20971520 >>>> >>>> Is this the correct way to do this? How do I find out what the " >>>> cn=/|database_name" is supposed to be? >>>> |/ >>> >>> |/see /|https://github.com/richm/scripts/wiki/dbmon.sh - the >>> script will tell you what the names of your databases are. >>>> /| >>>> |/ >>>> /|Thanks, >>>> |/ >>>> /|-Chris >>>> |/ >>>> >>>> >>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project >>> >>> >> >> >> > Thanks again Rich, > I have been having an abundance of issues with my FreeIPA server > lately. I'm not surprised that error is not related. I was not sure as > It has not surfaced in my logs before I changed the entry cache size. > Possibly this will be the clue to get me on the road to recovery. >> |Not sure what the problem is - looks like something has done an >> override of the standard schema definition of dc. >> http://tools.ietf.org/html/rfc4519 defines it with syntax >> 1.3.6.1.4.1.1466.115.121.1.26.| > I migrated from OpenLdap about a year ago. So my install is a > migration. I also recently tried to add a replica. Which prompted me > to update the schema on the master before it would replicate. What exactly did you do? You should not have migrated the standard schema from openldap. Did you have to override the definition of 'dc' for some reason? > >> |rpm -q 389-ds-base| > |389-ds-base-1.2.11.15-48.el6_6.x86_64 > > | >> |find /etc/dirsrv -name \*.ldif -exec grep 0.9.2342.19200300.100.1.25 >> {} /dev/null \;| > | > |/etc/dirsrv/slapd-PKI-IPA/schema.bak/00core.ldif:attributeTypes: ( > 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) > /etc/dirsrv/slapd-PKI-IPA/schema/00core.ldif:attributeTypes: ( > 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) > /etc/dirsrv/slapd-PKI-IPA/schema/05rfc2247.ldif:attributeTypes: ( > 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) DESC > 'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR > caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 > SINGLE-VALUE X-ORIGIN 'RFC 2247' ) This definition is wrong. Both RFC 2247 and RFC 4519 define 'dc' as syntax 1.3.6.1.4.1.1466.115.121.1.26 - that is, 7-bit ASCII only. Do you have some application that requires 8-bit or unicode characters (syntax 1.3.6.1.4.1.1466.115.121.1.15) in domain component names? If it is absolutely required that dc accepts unicode, then you'll have to change the matching rules as well, to be unicode compatible: EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch - that is, just get rid of the IA5. > /etc/dirsrv/schema/00core.ldif:attributeTypes: ( > 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) > /etc/dirsrv/slapd-CS-OBERLIN-EDU/schema.bak/00core.ldif:attributeTypes: ( > 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) > /etc/dirsrv/slapd-CS-OBERLIN-EDU/schema/00core.ldif:attributeTypes: ( > 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) > > Thanks again, > -Chris > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Feb 9 16:36:31 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Feb 2015 17:36:31 +0100 Subject: [Freeipa-users] Upgrade from 3x to 4x cant create first replica. In-Reply-To: <54D8DD56.2010903@oberlin.edu> References: <54D54DDE.5040902@oberlin.edu> <54D8CFD9.1080602@redhat.com> <54D8DD56.2010903@oberlin.edu> Message-ID: <54D8E20F.5060908@redhat.com> On 02/09/2015 05:16 PM, Chris Mohler wrote: > On 02/09/2015 10:18 AM, Martin Kosek wrote: >> On 02/07/2015 12:27 AM, Chris Mohler wrote: >>> I'm having some troubles. I have an older IPA install Version 3.0.0. on Centos >>> 6.6. It's currently the only master for my domain. I have about 4k user >>> accounts on here and it's a live system called "idm" >>> >>> I'm trying to upgrade to V4.x as I am hoping to fix some issues I am having. >>> (clients can't auth unless service sssd is restarted multiple times "10 (User >>> not known to the underlying authentication module") I think this is possibly >>> unrelated and the topic for another thread. >>> >>> I created a new VM and installed Fedora Server 21 and FreeIPA 4.1.2 it's called >>> "ipa" >> Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked >> in, so you can also use that platform if you are used to it. >> >>> on the master "idm" I ran "ipa-replica-prepare" and transfered the file to the >>> future replica "ipa" Then I ran the install replica script ipa-replica-install >>> --setup-ca /home/svradm/replica-info-ipa.cs.oberlin.edu.gpg >>> Things went well until it failed >>> >>> [24/35]: setting up initial replication >>> Starting replication, please wait until this has completed. >>> Update in progress, 133 seconds elapsed >>> Update in progress yet not in progress >>> >>> Update in progress yet not in progress >>> >>> Update in progress yet not in progress >>> >>> [idm.cs.oberlin.edu] reports: Update failed! Status: [10 Total update >>> abortedLDAP error: Referral] >>> >>> [error] RuntimeError: Failed to start replication >>> >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> Please help I'm getting nowhere by myself. >> Can you please look on the master you are replicating from and look for errors >> in /var/log/messages or DS errors log? >> >> Maybe you will see messages like "ns-slapd: encoded packet size too big (xxxxxx >>> 65536)" that are know to pop up more with CentOS 6.6. > Hi Martin, > Thanks for the reply and help I appreciate it. > >> Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked >> in, so you can also use that platform if you are used to it. > Good to know. I try to be distro agnostic. I've used Redhat 7.1 then went > Solaris, then Ubuntu, Now I'm back for Centos and Fedora. I guess I'm equally > uncomfortable with either version. > > That Said. Is there any reason that I could or should not have a replica on a > Fedora 21 server and 2nd replica on a Centos 7.1 later? My understanding is the > more the merrier. It should just work. Just note that in case of Fedora Server, these are upstream/Fedora bits which are only tested upstream. So if you for example break something in Fedora 21 (not likely to happen though ;-) and then get the change *replicated* to RHEL production instance, I do not think Red Hat support would be happy with that. Also, if for example upstream releases FreeIPA 4.2, I would not just plug it in your production RHEL instance is it would upgrade all the data for 4.2 level - which should get more downstream testing before Red Hat can rubber stamp it. TLDR; if you are happy with the upstream level of support (this list/IRC/Trac), knock yourself out :-) >> Can you please look on the master you are replicating from and look for errors >> in /var/log/messages or DS errors log? > > I tried to setup the replica again just now so I have some fresh logs. > > From the Dirserv error log > [08/Feb/2015:22:14:48 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up > [08/Feb/2015:22:14:48 -0500] schema-compat-plugin - warning: no entries set up > under cn=computers, cn=compat,dc=cs,dc=oberlin,dc=edu > [08/Feb/2015:22:14:50 -0500] - slapd started. Listening on All Interfaces port > 389 for LDAP requests > [08/Feb/2015:22:14:50 -0500] - Listening on All Interfaces port 636 for LDAPS > requests > [08/Feb/2015:22:14:50 -0500] - Listening on > /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests > [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - > agmt="cn=meToipa.cs.oberlin.edu" (ipa:389): Schema replication update failed: > Server is unwilling to perform > [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Warning: unable to > replicate schema to host ipa.cs.oberlin.edu, port 389. Continuing with total > update session. > [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Beginning total update of > replica "agmt="cn=meToipa.cs.oberlin.edu" (ipa:389)" > > To be fair and not duplicate efforts I have had the following error > [08/Feb/2015:08:51:26 -0500] - WARNING: userRoot: entry cache size 10485760B is > less than db size 12115968B; We recommend to increase the > entry cache size nsslapd-cachememsize. > > To which I have asked another question "how do I change the entry cache size" > https://www.redhat.com/archives/freeipa-users/2015-February/msg00114.html > I now get additional errors which I would guess are possibly related. IMO, they this should not be related (should not break replication). I do not see anything useful in the error log though. Did you also check /var/log/messages for the errors log I sent? From guertin at middlebury.edu Mon Feb 9 16:40:17 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Mon, 9 Feb 2015 16:40:17 +0000 Subject: [Freeipa-users] Trust with Active Directory fails In-Reply-To: <20150206082735.GG9247@redhat.com> References: <581f5e73e3e44f3598421161683d8166@greyhound.middlebury.edu> <20150206082735.GG9247@redhat.com> Message-ID: <680b3e659a3649e79002e5d01ce4d7fd@greyhound.middlebury.edu> > For Active Directory cross-forest trusts to work, we need following records > to be in place: > > _ldap._tcp. > _kerberos._udp. > _kerberos._tcp. > _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs. > _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs. > _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs. > _ldap._tcp.dc._msdcs. > _kerberos._udp.dc._msdcs. > _kerberos._tcp.dc._msdcs. I've checked with nslookup, and for the IPA subdomain csns.example.com, all the records are in place. For the parent example.com domain, though, the following four records are not found: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.example.com _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.example.com _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.example.com _kerberos._udp.dc._msdcs.example.com Do these need to be manually added to our DNS records? I've never had to manually add an SRV record before. If it matters, we are not using our domain controllers as our DNS servers -- we have separate, dedicated DNS servers in our environment. Thanks, David Guertin From cmohler at oberlin.edu Mon Feb 9 17:12:28 2015 From: cmohler at oberlin.edu (Chris Mohler) Date: Mon, 09 Feb 2015 12:12:28 -0500 Subject: [Freeipa-users] Upgrade from 3x to 4x cant create first replica. In-Reply-To: <54D8E20F.5060908@redhat.com> References: <54D54DDE.5040902@oberlin.edu> <54D8CFD9.1080602@redhat.com> <54D8DD56.2010903@oberlin.edu> <54D8E20F.5060908@redhat.com> Message-ID: <54D8EA7C.8020608@oberlin.edu> On 02/09/2015 11:36 AM, Martin Kosek wrote: > On 02/09/2015 05:16 PM, Chris Mohler wrote: >> On 02/09/2015 10:18 AM, Martin Kosek wrote: >>> On 02/07/2015 12:27 AM, Chris Mohler wrote: >>>> I'm having some troubles. I have an older IPA install Version 3.0.0. on Centos >>>> 6.6. It's currently the only master for my domain. I have about 4k user >>>> accounts on here and it's a live system called "idm" >>>> >>>> I'm trying to upgrade to V4.x as I am hoping to fix some issues I am having. >>>> (clients can't auth unless service sssd is restarted multiple times "10 (User >>>> not known to the underlying authentication module") I think this is possibly >>>> unrelated and the topic for another thread. >>>> >>>> I created a new VM and installed Fedora Server 21 and FreeIPA 4.1.2 it's called >>>> "ipa" >>> Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked >>> in, so you can also use that platform if you are used to it. >>> >>>> on the master "idm" I ran "ipa-replica-prepare" and transfered the file to the >>>> future replica "ipa" Then I ran the install replica script ipa-replica-install >>>> --setup-ca /home/svradm/replica-info-ipa.cs.oberlin.edu.gpg >>>> Things went well until it failed >>>> >>>> [24/35]: setting up initial replication >>>> Starting replication, please wait until this has completed. >>>> Update in progress, 133 seconds elapsed >>>> Update in progress yet not in progress >>>> >>>> Update in progress yet not in progress >>>> >>>> Update in progress yet not in progress >>>> >>>> [idm.cs.oberlin.edu] reports: Update failed! Status: [10 Total update >>>> abortedLDAP error: Referral] >>>> >>>> [error] RuntimeError: Failed to start replication >>>> >>>> Your system may be partly configured. >>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>> >>>> Please help I'm getting nowhere by myself. >>> Can you please look on the master you are replicating from and look for errors >>> in /var/log/messages or DS errors log? >>> >>> Maybe you will see messages like "ns-slapd: encoded packet size too big (xxxxxx >>>> 65536)" that are know to pop up more with CentOS 6.6. >> Hi Martin, >> Thanks for the reply and help I appreciate it. >> >>> Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked >>> in, so you can also use that platform if you are used to it. >> Good to know. I try to be distro agnostic. I've used Redhat 7.1 then went >> Solaris, then Ubuntu, Now I'm back for Centos and Fedora. I guess I'm equally >> uncomfortable with either version. >> >> That Said. Is there any reason that I could or should not have a replica on a >> Fedora 21 server and 2nd replica on a Centos 7.1 later? My understanding is the >> more the merrier. > It should just work. Just note that in case of Fedora Server, these are > upstream/Fedora bits which are only tested upstream. So if you for example > break something in Fedora 21 (not likely to happen though ;-) and then get the > change *replicated* to RHEL production instance, I do not think Red Hat support > would be happy with that. > > Also, if for example upstream releases FreeIPA 4.2, I would not just plug it in > your production RHEL instance is it would upgrade all the data for 4.2 level - > which should get more downstream testing before Red Hat can rubber stamp it. > > TLDR; if you are happy with the upstream level of support (this list/IRC/Trac), > knock yourself out :-) > >>> Can you please look on the master you are replicating from and look for errors >>> in /var/log/messages or DS errors log? >> I tried to setup the replica again just now so I have some fresh logs. >> >> From the Dirserv error log >> [08/Feb/2015:22:14:48 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up >> [08/Feb/2015:22:14:48 -0500] schema-compat-plugin - warning: no entries set up >> under cn=computers, cn=compat,dc=cs,dc=oberlin,dc=edu >> [08/Feb/2015:22:14:50 -0500] - slapd started. Listening on All Interfaces port >> 389 for LDAP requests >> [08/Feb/2015:22:14:50 -0500] - Listening on All Interfaces port 636 for LDAPS >> requests >> [08/Feb/2015:22:14:50 -0500] - Listening on >> /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests >> [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - >> agmt="cn=meToipa.cs.oberlin.edu" (ipa:389): Schema replication update failed: >> Server is unwilling to perform >> [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Warning: unable to >> replicate schema to host ipa.cs.oberlin.edu, port 389. Continuing with total >> update session. >> [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Beginning total update of >> replica "agmt="cn=meToipa.cs.oberlin.edu" (ipa:389)" >> >> To be fair and not duplicate efforts I have had the following error >> [08/Feb/2015:08:51:26 -0500] - WARNING: userRoot: entry cache size 10485760B is >> less than db size 12115968B; We recommend to increase the >> entry cache size nsslapd-cachememsize. >> >> To which I have asked another question "how do I change the entry cache size" >> https://www.redhat.com/archives/freeipa-users/2015-February/msg00114.html >> I now get additional errors which I would guess are possibly related. > IMO, they this should not be related (should not break replication). I do not > see anything useful in the error log though. Did you also check > /var/log/messages for the errors log I sent? /var/log/messgaes on the Centos Master only has one entry from today. Feb 9 05:50:00 idm rngd: failed fips test (An error about the rngd package) Do I need to increase the verbosity over the default settings to get replication errors? Or is there a config file that needs a debug option in FreeIpa? /var/log/messages on the client Fedora system isn't much more interesting Feb 9 10:40:25 ipa ns-slapd: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled Feb 9 10:40:25 ipa ns-slapd: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled Feb 9 10:40:25 ipa ns-slapd: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled Feb 9 10:40:25 ipa ns-slapd: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled Feb 9 10:40:25 ipa ns-slapd: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled Feb 9 10:40:25 ipa ns-slapd: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled Feb 9 10:40:25 ipa ns-slapd: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled Feb 9 10:40:25 ipa ns-slapd: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled Feb 9 10:40:25 ipa ns-slapd: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled Feb 9 10:40:25 ipa ns-slapd: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled Feb 9 10:40:25 ipa ns-slapd: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled Feb 9 10:40:25 ipa ns-slapd: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled Feb 9 10:40:25 ipa ns-slapd: [09/Feb/2015:10:40:25 -0500] SSL Initialization - SSL version range: min: TLS1.0, max: TLS1.2 Feb 9 10:55:25 ipa ntpd[1011]: 0.0.0.0 c612 02 freq_set ntpd -5.531 PPM Feb 9 10:55:25 ipa ntpd[1011]: 0.0.0.0 c615 05 clock_sync Feb 9 11:01:02 ipa systemd: Starting Paths. Feb 9 11:01:02 ipa systemd: Reached target Paths. Feb 9 11:01:02 ipa systemd: Starting Timers. Feb 9 11:01:02 ipa systemd: Reached target Timers. Feb 9 11:01:02 ipa systemd: Starting Sockets. Feb 9 11:01:02 ipa systemd: Reached target Sockets. Feb 9 11:01:02 ipa systemd: Starting Basic System. Feb 9 11:01:02 ipa systemd: Reached target Basic System. Feb 9 11:01:02 ipa systemd: Starting Default. Feb 9 11:01:02 ipa systemd: Reached target Default. Feb 9 11:01:02 ipa systemd: Startup finished in 7ms. I searched /var/log/messages and the archived message logs on the master Centos server for "encoded packet size too big", "encoded packet", "slapd", and "encoded" and did not find any results. Thanks, -Chris From mexigabacho at gmail.com Mon Feb 9 17:18:36 2015 From: mexigabacho at gmail.com (Christopher Young) Date: Mon, 9 Feb 2015 12:18:36 -0500 Subject: [Freeipa-users] User certificates with FreeIPA and another question. In-Reply-To: <54D4D00A.7050402@redhat.com> References: <54D3DBFD.5000703@redhat.com> <54D4D00A.7050402@redhat.com> Message-ID: Would anyone happen to have any guides on how one could get through this process? I'm a one-man IT shop at the moment, so I'm building up a tremendous amount of infrastructure at once. I'm thinking that the option of creating a subCA with something simple like openssl would be the best option, but figuring out that process in a minimal amount of time is going to be tough. I'm going to try and give myself some reading assignments and push that forward, but if anyone happens to have a good handle on that process/commands/etc. and would be interesting in double a couple of hours of consulting to me, I would be very interested in listening provided we could come up with a reasonable rate/timeframe. If anyone is interested, please contact me directly off-list. Thanks again. These answers/ideas have been most helpful. On Fri, Feb 6, 2015 at 9:30 AM, Martin Kosek wrote: > On 02/06/2015 12:53 AM, Christopher Young wrote: > > Obvious next question: Any plans to implement that functionality or > advice > > on how one might get some level of functionality for this? Would it be > > possible to create another command-line based openssl CA that could issue > > these but using IPA as the root CA for those? > > As for FreeIPA plans, we plan to vastly improve our flexibility to process > certificates in next upstream version - FreeIPA 4.2. In next version, one > should be able to create other certificate profiles (from FreeIPA default > service cert profile) or even subCAs to do what you want. > > As for current workarounds, you would have to issue and sign a for example > NSS > or openssl based subCA and then sign user certs there. But I would leave > Fraser > or Jan to tell if this would be really possible. > > > I'm just trying to provide a solution for situations where we would like > to > > utilize client/user cert authentication for situations like secure apache > > directory access as well as user VPN certificates. Any advise or ideas > are > > great appreciated. > > > > Thanks again! > > > > On Thu, Feb 5, 2015 at 4:09 PM, Rob Crittenden > wrote: > > > >> Christopher Young wrote: > >>> Some of this might be rudimentary, so I apologize if this is answered > >>> somewhere, though I've tried to search and have not had much luck... > >>> > >>> Basically, I would like to be able to issue user certificates > (Subject: > >>> email=sblblabla at blabla.local) in order to use client SSL security on > >>> some things. I'm very new to FreeIPA, but have worked with external > CAs > >>> in the past for similar requests, however this is my first entry into > >>> creating/running a localized CA within an organization. > >> > >> IPA doesn't issue user certificates yet, only server certificates. > >> > >>> I was wondering if this is possible via the command line, and if so, > how > >>> to go about submitting the request and receiving the certificate. Any > >>> guidance or assistance would be greatly appreciated! > >>> > >>> > >>> Additionally, just as a matter of cleanliness, is there any way > possible > >>> to just completely wipe out the existence of a certificate/request from > >>> FreeIPA. I have done some trial-and-error and obviously have made > >>> mistakes that I'd prefer to clean up after. I've revoked those certs, > >>> however the perfectionist in me hates seeing them there. I'm quite > >>> certain the answer is 'no', but I thought I would ask anyway. > >> > >> Right, the answer is no. In fact it is a good thing that all > >> certificates are accounted for. > >> > >> rob > >> > >> > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Feb 9 17:50:11 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 9 Feb 2015 19:50:11 +0200 Subject: [Freeipa-users] Trust with Active Directory fails In-Reply-To: <680b3e659a3649e79002e5d01ce4d7fd@greyhound.middlebury.edu> References: <581f5e73e3e44f3598421161683d8166@greyhound.middlebury.edu> <20150206082735.GG9247@redhat.com> <680b3e659a3649e79002e5d01ce4d7fd@greyhound.middlebury.edu> Message-ID: <20150209175011.GH9247@redhat.com> On Mon, 09 Feb 2015, Guertin, David S. wrote: >> For Active Directory cross-forest trusts to work, we need following records >> to be in place: >> >> _ldap._tcp. >> _kerberos._udp. >> _kerberos._tcp. >> _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs. >> _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs. >> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs. >> _ldap._tcp.dc._msdcs. >> _kerberos._udp.dc._msdcs. >> _kerberos._tcp.dc._msdcs. > >I've checked with nslookup, and for the IPA subdomain csns.example.com, all the records are in place. For the parent example.com domain, though, the following four records are not found: > >_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.example.com >_kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.example.com >_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.example.com >_kerberos._udp.dc._msdcs.example.com > >Do these need to be manually added to our DNS records? I've never had >to manually add an SRV record before. If it matters, we are not using >our domain controllers as our DNS servers -- we have separate, >dedicated DNS servers in our environment. Can you send me (off-list) logs as described in http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust -- / Alexander Bokovoy From guertin at middlebury.edu Mon Feb 9 18:35:54 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Mon, 9 Feb 2015 18:35:54 +0000 Subject: [Freeipa-users] Trust with Active Directory fails In-Reply-To: <20150209175011.GH9247@redhat.com> References: <581f5e73e3e44f3598421161683d8166@greyhound.middlebury.edu> <20150206082735.GG9247@redhat.com> <680b3e659a3649e79002e5d01ce4d7fd@greyhound.middlebury.edu> <20150209175011.GH9247@redhat.com> Message-ID: <0ced1db9caba43f396165b05a502ea20@greyhound.middlebury.edu> > Can you send me (off-list) logs as described in > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_tr > ust Alexander, Here are the log files you requested. Thanks for looking. Regards, David Guertin -------------- next part -------------- A non-text attachment was scrubbed... Name: logs.tar.bz2 Type: application/octet-stream Size: 162417 bytes Desc: logs.tar.bz2 URL: From cmohler at oberlin.edu Mon Feb 9 19:13:43 2015 From: cmohler at oberlin.edu (Chris Mohler) Date: Mon, 09 Feb 2015 14:13:43 -0500 Subject: [Freeipa-users] How do I modify the entry cache size? In-Reply-To: <54D8DE08.2010002@redhat.com> References: <54D7EA1F.5030209@redhat.com> <54D8C8B5.2080102@redhat.com> <54D8D19E.1080703@oberlin.edu> <54D8DE08.2010002@redhat.com> Message-ID: <54D906E7.2080003@oberlin.edu> On 02/09/2015 11:19 AM, Rich Megginson wrote: > On 02/09/2015 08:26 AM, Chris Mohler wrote: >> On 02/09/2015 09:48 AM, Rich Megginson wrote: >>> On 02/08/2015 08:23 PM, Chris Mohler wrote: >>>> Thanks for the reply and the link Rich! >>>> >>>> dbmon.sh is a handy tool indeed. >>>> >>>> I read the instructions and upped my entry cache size to 2gb >>>> because I have enough ram. >>>> Everything went well until >>>> |service dirsrv restart >>>> >>>> | >>>> |I Got the following errors: >>>> [06/Feb/2015:10:07:35 -0500] - slapd stopped. >>>> [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching rule [caseIgnoreIA5Match] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] >>>> [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] >>>> [06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up >>>> [06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port 7389 for LDAP requests >>>> [06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS requests >>>> >>>> | >>>> |Oddly enough everything appears to be working. Are these messages safe to ignore? >>>> | >>> >>> This is definitely not related to the cache size. >>> >>> |Not sure what the problem is - looks like something has done an >>> override of the standard schema definition of dc. >>> http://tools.ietf.org/html/rfc4519 defines it with syntax >>> 1.3.6.1.4.1.1466.115.121.1.26. >>> >>> rpm -q 389-ds-base >>> >>> find /etc/dirsrv -name \*.ldif -exec grep 0.9.2342.19200300.100.1.25 >>> {} /dev/null \; >>> >>> >>> | >>>> |Another run of dbmon.sh shows that my entry cache was increased. >>>> >>>> ||| >>>> |Thanks, >>>> | >>>> |-Chris >>>> | >>>> | >>>> | >>>> >>>> >>>> On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson >>> > wrote: >>>> >>>> On 02/07/2015 11:25 AM, Chris Mohler wrote: >>>>> Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to increase the entry cache size >>>>> I'm trying to follow the directions here >>>>> /usr/lib/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389 >>>>> >>>>> dn: cn=/|database_name|/, cn=ldbm database, cn=plugins, cn=config >>>>> changetype: modify >>>>> replace: nsslapd-cachememsize >>>>> nsslapd-cachememsize: 20971520 >>>>> >>>>> Is this the correct way to do this? How do I find out what the " >>>>> cn=/|database_name" is supposed to be? >>>>> |/ >>>> >>>> |/see /|https://github.com/richm/scripts/wiki/dbmon.sh - the >>>> script will tell you what the names of your databases are. >>>>> /| >>>>> |/ >>>>> /|Thanks, >>>>> |/ >>>>> /|-Chris >>>>> |/ >>>>> >>>>> >>>> >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go To http://freeipa.org for more info on the project >>>> >>>> >>> >>> >>> >> Thanks again Rich, >> I have been having an abundance of issues with my FreeIPA server >> lately. I'm not surprised that error is not related. I was not sure >> as It has not surfaced in my logs before I changed the entry cache >> size. Possibly this will be the clue to get me on the road to recovery. >>> |Not sure what the problem is - looks like something has done an >>> override of the standard schema definition of dc. >>> http://tools.ietf.org/html/rfc4519 defines it with syntax >>> 1.3.6.1.4.1.1466.115.121.1.26.| >> I migrated from OpenLdap about a year ago. So my install is a >> migration. I also recently tried to add a replica. Which prompted me >> to update the schema on the master before it would replicate. > > What exactly did you do? You should not have migrated the standard > schema from openldap. Did you have to override the definition of 'dc' > for some reason? > >> >>> |rpm -q 389-ds-base| >> |389-ds-base-1.2.11.15-48.el6_6.x86_64 >> >> | >>> |find /etc/dirsrv -name \*.ldif -exec grep >>> 0.9.2342.19200300.100.1.25 {} /dev/null \;| >> | >> |/etc/dirsrv/slapd-PKI-IPA/schema.bak/00core.ldif:attributeTypes: ( >> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >> /etc/dirsrv/slapd-PKI-IPA/schema/00core.ldif:attributeTypes: ( >> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >> /etc/dirsrv/slapd-PKI-IPA/schema/05rfc2247.ldif:attributeTypes: ( >> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) DESC >> 'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR >> caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 >> SINGLE-VALUE X-ORIGIN 'RFC 2247' ) > > This definition is wrong. Both RFC 2247 and RFC 4519 define 'dc' as > syntax 1.3.6.1.4.1.1466.115.121.1.26 - that is, 7-bit ASCII only. Do > you have some application that requires 8-bit or unicode characters > (syntax 1.3.6.1.4.1.1466.115.121.1.15) in domain component names? If > it is absolutely required that dc accepts unicode, then you'll have to > change the matching rules as well, to be unicode compatible: EQUALITY > caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch - that is, just get > rid of the IA5. > > >> /etc/dirsrv/schema/00core.ldif:attributeTypes: ( >> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >> /etc/dirsrv/slapd-CS-OBERLIN-EDU/schema.bak/00core.ldif:attributeTypes: >> ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >> /etc/dirsrv/slapd-CS-OBERLIN-EDU/schema/00core.ldif:attributeTypes: ( >> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >> >> Thanks again, >> -Chris >> >> >> > > > > What exactly did you do? You should not have migrated the standard > schema from openldap. Did you have to override the definition of 'dc' > for some reason? "what did you do?" Made me smile. I dug up my notes from the install and migrate from openldap. After ipa-server-install was successful I had a messy migration. I did the following #Disable the compat plugin $ipa-compat-manage disable #Restart the dirservice $service dirsrv restart #Enable Migration $ipa config-mod --enable-migration=TRUE #Run the migration script $ipa migrate-ds --bind-dn="cn=linux,ou=LDAPauth,dc=cs,dc=oberlin,dc=edu" --base-dn="dc=cs,dc=oberlin,dc=edu" --group-container=ou=Group --user-container=ou=People --user-objectclass=\* --user-ignore-objectclass=inetLocalMailRecipient --user-ignore-attribute="mailHost" --user-ignore-attribute="mailRoutingAddress" --user-ignore-objectclass=organizationalPerson --user-ignore-objectclass=inetOrgPerson --user-ignore-attribute="givenName" --user-ignore-attribute="roomNumber" --user-ignore-attribute="displayName" --user-ignore-attribute="mail" --user-ignore-attribute="homePhone" ldap://cs.oberlin.edu:389 #You may find that the script exits after a while with an error stating that the LDAP server is down. This seems #to be an OpenLdap side thing. To work around this, do the following. |$getent ||passwd| || ||cut| |-d : -f 1 > ||passwd| #And copy this passwd file, which now contains a list of every user, to the IdM. #Then, run the following on the IdM to copy until compl$ cp passwd missing $ touch present $ ipa migrate-ds --bind-dn="cn=linux,ou=LDAPauth,dc=cs,dc=oberlin,dc=edu" --base-dn="dc=cs,dc=oberlin,dc=edu" --group-container=ou=Group --user-container=ou=People --user-objectclass=\* --exclude-users=`cat present | tr '\n' ','` --user-ignore-objectclass=inetLocalMailRecipient --user-ignore-attribute="mailHost" --user-ignore-attribute="mailRoutingAddress" --user-ignore-objectclass=organizationalPerson --user-ignore-objectclass=inetOrgPerson --user-ignore-attribute="givenName" --user-ignore-attribute="roomNumber" --user-ignore-attribute="displayName" --user-ignore-attribute="mail" ldap://cs.oberlin.edu:389 $ E=1; while [ $E -gt "0" ]; do for i in `cat missing`; do ipa user-find --login=$i; if [ $? = "0" ]; then echo $i >> present; else echo $i >> missing1; fi; done; mv missing1 missing; ipa migrate-ds --bind-dn="cn=linux,ou=LDAPauth,dc=cs,dc=oberlin,dc=edu" --base-dn="dc=cs,dc=oberlin,dc=edu" --group-container=ou=Group --user-container=ou=People --user-objectclass=\* --exclude-users=`cat present | tr '\n' ','` --user-ignore-objectclass=inetLocalMailRecipient --user-ignore-attribute="mailHost" --user-ignore-attribute="mailRoutingAddress" --user-ignore-objectclass=organizationalPerson --user-ignore-objectclass=inetOrgPerson --user-ignore-attribute="homePhone" --user-ignore-attribute="givenName" --user-ignore-attribute="roomNumber" --user-ignore-attribute="displayName" --user-ignore-attribute="mail" ldap://cs.oberlin.edu:389; E=$?; doneete: |Groups were processed a similar way. getent group > ||groups ||while| |read| |line; ||do| |ipa group-add-member `||echo| |$line | ||cut| |-d : -f 1` --||users||=`||echo| |$line | ||cut| |-d : -f 4`; ||done| |< ||groups Of course I am not the sys adm that did the migration I am working off some old notes. |Recently I tried to add a replica and the replica install asked me to run the following on the master. Which I did. copy-schema-to-ca.py #! /usr/bin/python2 """Copy the IPA schema to the CA directory server instance You need to run this script to prepare a 2.2 or 3.0 IPA master for installation of a 3.1 replica. Once a 3.1 replica is in the domain, every older CA master will emit schema replication errors until this script is run on it. """ import os import sys import pwd import shutil from ipapython import ipautil, dogtag from ipapython.ipa_log_manager import root_logger, standard_logging_setup from ipaserver.install.dsinstance import DS_USER, schema_dirname from ipaserver.install.cainstance import PKI_USER from ipalib import api try: from ipaplatform import services except ImportError: from ipapython import services # pylint: disable=no-name-in-module SERVERID = "PKI-IPA" SCHEMA_FILENAMES = ( "60kerberos.ldif", "60samba.ldif", "60ipaconfig.ldif", "60basev2.ldif", "60basev3.ldif", "60ipadns.ldif", "61kerberos-ipav3.ldif", "65ipacertstore.ldif", "65ipasudo.ldif", "70ipaotp.ldif", "05rfc2247.ldif", ) def add_ca_schema(): """Copy IPA schema files into the CA DS instance """ pki_pent = pwd.getpwnam(PKI_USER) ds_pent = pwd.getpwnam(DS_USER) for schema_fname in SCHEMA_FILENAMES: source_fname = os.path.join(ipautil.SHARE_DIR, schema_fname) target_fname = os.path.join(schema_dirname(SERVERID), schema_fname) if not os.path.exists(source_fname): root_logger.debug('File does not exist: %s', source_fname) continue if os.path.exists(target_fname): root_logger.info( 'Target exists, not overwriting: %s', target_fname) continue try: shutil.copyfile(source_fname, target_fname) except IOError, e: root_logger.warning('Could not install %s: %s', target_fname, e) else: root_logger.info('Installed %s', target_fname) os.chmod(target_fname, 0440) # read access for dirsrv user/group os.chown(target_fname, pki_pent.pw_uid, ds_pent.pw_gid) def restart_pki_ds(): """Restart the CA DS instance to pick up schema changes """ root_logger.info('Restarting CA DS') services.service('dirsrv').restart(SERVERID) def main(): if os.getegid() != 0: sys.exit("Must be root to run this script") standard_logging_setup(verbose=True) # In 3.0, restarting needs access to api.env (options, argv) = api.bootstrap_with_global_options(context='server') add_ca_schema() restart_pki_ds() root_logger.info('Schema updated successfully') main() > This definition is wrong. Both RFC 2247 and RFC 4519 define 'dc' as > syntax 1.3.6.1.4.1.1466.115.121.1.26 - that is, 7-bit ASCII only. Do > you have some application that requires 8-bit or unicode characters > (syntax 1.3.6.1.4.1.1466.115.121.1.15) in domain component names? If > it is absolutely required that dc accepts unicode, then you'll have to > change the matching rules as well, to be unicode compatible: EQUALITY > caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch - that is, just get > rid of the IA5. I am only using FreeIPA to authenticate linux clients for user login via SSSD. Using Pam. I don't have any applications that would require 8-bit or Unicode characters. Is it possible to return to a standard definition? -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From mexigabacho at gmail.com Mon Feb 9 19:24:12 2015 From: mexigabacho at gmail.com (Christopher Young) Date: Mon, 9 Feb 2015 14:24:12 -0500 Subject: [Freeipa-users] User certificates with FreeIPA and another question. In-Reply-To: References: <54D3DBFD.5000703@redhat.com> <54D4D00A.7050402@redhat.com> Message-ID: I actually think I can get this going at this time if I can just figure out how to submit a subca csr to dogtag, sign it, and acquire it. Documentation on that seems to be hard to come by, but I'm digging to avoid eating up this thread (and trying to RTFM where possible). I still stand by my request for consulting time if anyone has more intimate knowledge, however if someone can point me in the best direction for getting a openssl based subca's csr submitted, signed, acquired, I think I can get the rest going. Your help would be greatly, greatly appreciated. Chris On Mon, Feb 9, 2015 at 12:18 PM, Christopher Young wrote: > Would anyone happen to have any guides on how one could get through this > process? I'm a one-man IT shop at the moment, so I'm building up a > tremendous amount of infrastructure at once. I'm thinking that the option > of creating a subCA with something simple like openssl would be the best > option, but figuring out that process in a minimal amount of time is going > to be tough. > > I'm going to try and give myself some reading assignments and push that > forward, but if anyone happens to have a good handle on that > process/commands/etc. and would be interesting in double a couple of hours > of consulting to me, I would be very interested in listening provided we > could come up with a reasonable rate/timeframe. If anyone is interested, > please contact me directly off-list. > > Thanks again. These answers/ideas have been most helpful. > > On Fri, Feb 6, 2015 at 9:30 AM, Martin Kosek wrote: > >> On 02/06/2015 12:53 AM, Christopher Young wrote: >> > Obvious next question: Any plans to implement that functionality or >> advice >> > on how one might get some level of functionality for this? Would it be >> > possible to create another command-line based openssl CA that could >> issue >> > these but using IPA as the root CA for those? >> >> As for FreeIPA plans, we plan to vastly improve our flexibility to process >> certificates in next upstream version - FreeIPA 4.2. In next version, one >> should be able to create other certificate profiles (from FreeIPA default >> service cert profile) or even subCAs to do what you want. >> >> As for current workarounds, you would have to issue and sign a for >> example NSS >> or openssl based subCA and then sign user certs there. But I would leave >> Fraser >> or Jan to tell if this would be really possible. >> >> > I'm just trying to provide a solution for situations where we would >> like to >> > utilize client/user cert authentication for situations like secure >> apache >> > directory access as well as user VPN certificates. Any advise or ideas >> are >> > great appreciated. >> > >> > Thanks again! >> > >> > On Thu, Feb 5, 2015 at 4:09 PM, Rob Crittenden >> wrote: >> > >> >> Christopher Young wrote: >> >>> Some of this might be rudimentary, so I apologize if this is answered >> >>> somewhere, though I've tried to search and have not had much luck... >> >>> >> >>> Basically, I would like to be able to issue user certificates >> (Subject: >> >>> email=sblblabla at blabla.local) in order to use client SSL security on >> >>> some things. I'm very new to FreeIPA, but have worked with external >> CAs >> >>> in the past for similar requests, however this is my first entry into >> >>> creating/running a localized CA within an organization. >> >> >> >> IPA doesn't issue user certificates yet, only server certificates. >> >> >> >>> I was wondering if this is possible via the command line, and if so, >> how >> >>> to go about submitting the request and receiving the certificate. Any >> >>> guidance or assistance would be greatly appreciated! >> >>> >> >>> >> >>> Additionally, just as a matter of cleanliness, is there any way >> possible >> >>> to just completely wipe out the existence of a certificate/request >> from >> >>> FreeIPA. I have done some trial-and-error and obviously have made >> >>> mistakes that I'd prefer to clean up after. I've revoked those certs, >> >>> however the perfectionist in me hates seeing them there. I'm quite >> >>> certain the answer is 'no', but I thought I would ask anyway. >> >> >> >> Right, the answer is no. In fact it is a good thing that all >> >> certificates are accounted for. >> >> >> >> rob >> >> >> >> >> > >> > >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Feb 9 19:28:15 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 09 Feb 2015 12:28:15 -0700 Subject: [Freeipa-users] How do I modify the entry cache size? In-Reply-To: <54D906E7.2080003@oberlin.edu> References: <54D7EA1F.5030209@redhat.com> <54D8C8B5.2080102@redhat.com> <54D8D19E.1080703@oberlin.edu> <54D8DE08.2010002@redhat.com> <54D906E7.2080003@oberlin.edu> Message-ID: <54D90A4F.5080100@redhat.com> On 02/09/2015 12:13 PM, Chris Mohler wrote: > On 02/09/2015 11:19 AM, Rich Megginson wrote: >> On 02/09/2015 08:26 AM, Chris Mohler wrote: >>> On 02/09/2015 09:48 AM, Rich Megginson wrote: >>>> On 02/08/2015 08:23 PM, Chris Mohler wrote: >>>>> Thanks for the reply and the link Rich! >>>>> >>>>> dbmon.sh is a handy tool indeed. >>>>> >>>>> I read the instructions and upped my entry cache size to 2gb >>>>> because I have enough ram. >>>>> Everything went well until >>>>> |service dirsrv restart >>>>> >>>>> | >>>>> |I Got the following errors: >>>>> [06/Feb/2015:10:07:35 -0500] - slapd stopped. >>>>> [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching rule [caseIgnoreIA5Match] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] >>>>> [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] >>>>> [06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up >>>>> [06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port 7389 for LDAP requests >>>>> [06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS requests >>>>> >>>>> | >>>>> |Oddly enough everything appears to be working. Are these messages safe to ignore? >>>>> | >>>> >>>> This is definitely not related to the cache size. >>>> >>>> |Not sure what the problem is - looks like something has done an >>>> override of the standard schema definition of dc. >>>> http://tools.ietf.org/html/rfc4519 defines it with syntax >>>> 1.3.6.1.4.1.1466.115.121.1.26. >>>> >>>> rpm -q 389-ds-base >>>> >>>> find /etc/dirsrv -name \*.ldif -exec grep >>>> 0.9.2342.19200300.100.1.25 {} /dev/null \; >>>> >>>> >>>> | >>>>> |Another run of dbmon.sh shows that my entry cache was increased. >>>>> >>>>> ||| >>>>> |Thanks, >>>>> | >>>>> |-Chris >>>>> | >>>>> | >>>>> | >>>>> >>>>> >>>>> On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson >>>>> > wrote: >>>>> >>>>> On 02/07/2015 11:25 AM, Chris Mohler wrote: >>>>>> Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to increase the entry cache size >>>>>> I'm trying to follow the directions here >>>>>> /usr/lib/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389 >>>>>> >>>>>> dn: cn=/|database_name|/, cn=ldbm database, cn=plugins, cn=config >>>>>> changetype: modify >>>>>> replace: nsslapd-cachememsize >>>>>> nsslapd-cachememsize: 20971520 >>>>>> >>>>>> Is this the correct way to do this? How do I find out what the " >>>>>> cn=/|database_name" is supposed to be? >>>>>> |/ >>>>> >>>>> |/see /|https://github.com/richm/scripts/wiki/dbmon.sh - the >>>>> script will tell you what the names of your databases are. >>>>>> /| >>>>>> |/ >>>>>> /|Thanks, >>>>>> |/ >>>>>> /|-Chris >>>>>> |/ >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Manage your subscription for the Freeipa-users mailing list: >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> Go To http://freeipa.org for more info on the project >>>>> >>>>> >>>> >>>> >>>> >>> Thanks again Rich, >>> I have been having an abundance of issues with my FreeIPA server >>> lately. I'm not surprised that error is not related. I was not sure >>> as It has not surfaced in my logs before I changed the entry cache >>> size. Possibly this will be the clue to get me on the road to recovery. >>>> |Not sure what the problem is - looks like something has done an >>>> override of the standard schema definition of dc. >>>> http://tools.ietf.org/html/rfc4519 defines it with syntax >>>> 1.3.6.1.4.1.1466.115.121.1.26.| >>> I migrated from OpenLdap about a year ago. So my install is a >>> migration. I also recently tried to add a replica. Which prompted me >>> to update the schema on the master before it would replicate. >> >> What exactly did you do? You should not have migrated the standard >> schema from openldap. Did you have to override the definition of >> 'dc' for some reason? >> >>> >>>> |rpm -q 389-ds-base| >>> |389-ds-base-1.2.11.15-48.el6_6.x86_64 >>> >>> | >>>> |find /etc/dirsrv -name \*.ldif -exec grep >>>> 0.9.2342.19200300.100.1.25 {} /dev/null \;| >>> | >>> |/etc/dirsrv/slapd-PKI-IPA/schema.bak/00core.ldif:attributeTypes: ( >>> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >>> /etc/dirsrv/slapd-PKI-IPA/schema/00core.ldif:attributeTypes: ( >>> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >>> /etc/dirsrv/slapd-PKI-IPA/schema/05rfc2247.ldif:attributeTypes: ( >>> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) DESC >>> 'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR >>> caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 >>> SINGLE-VALUE X-ORIGIN 'RFC 2247' ) >> >> This definition is wrong. Both RFC 2247 and RFC 4519 define 'dc' as >> syntax 1.3.6.1.4.1.1466.115.121.1.26 - that is, 7-bit ASCII only. Do >> you have some application that requires 8-bit or unicode characters >> (syntax 1.3.6.1.4.1.1466.115.121.1.15) in domain component names? If >> it is absolutely required that dc accepts unicode, then you'll have >> to change the matching rules as well, to be unicode compatible: >> EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch - that is, >> just get rid of the IA5. >> >> >>> /etc/dirsrv/schema/00core.ldif:attributeTypes: ( >>> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >>> /etc/dirsrv/slapd-CS-OBERLIN-EDU/schema.bak/00core.ldif:attributeTypes: >>> ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >>> /etc/dirsrv/slapd-CS-OBERLIN-EDU/schema/00core.ldif:attributeTypes: >>> ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >>> >>> Thanks again, >>> -Chris >>> >>> >>> >> >> >> >> What exactly did you do? You should not have migrated the standard >> schema from openldap. Did you have to override the definition of >> 'dc' for some reason? > "what did you do?" Made me smile. > I dug up my notes from the install and migrate from openldap. After > ipa-server-install was successful I had a messy migration. I did the > following > > #Disable the compat plugin > $ipa-compat-manage disable > > #Restart the dirservice > $service dirsrv restart > > #Enable Migration > $ipa config-mod --enable-migration=TRUE Are you supposed to do --enable-migration=FALSE or --disable-migration after migration is complete? Perhaps during migration the schema is relaxed Can any IPA or DogTag developer comment about this schema issue? > > #Run the migration script > $ipa migrate-ds > --bind-dn="cn=linux,ou=LDAPauth,dc=cs,dc=oberlin,dc=edu" > --base-dn="dc=cs,dc=oberlin,dc=edu" --group-container=ou=Group > --user-container=ou=People --user-objectclass=\* > --user-ignore-objectclass=inetLocalMailRecipient > --user-ignore-attribute="mailHost" > --user-ignore-attribute="mailRoutingAddress" > --user-ignore-objectclass=organizationalPerson > --user-ignore-objectclass=inetOrgPerson > --user-ignore-attribute="givenName" > --user-ignore-attribute="roomNumber" > --user-ignore-attribute="displayName" --user-ignore-attribute="mail" > --user-ignore-attribute="homePhone" ldap://cs.oberlin.edu:389 > > #You may find that the script exits after a while with an error > stating that the LDAP server is down. This seems #to be an OpenLdap > side thing. To work around this, do the following. > |$getent ||passwd| || ||cut| |-d : -f 1 > ||passwd| > > #And copy this passwd file, which now contains a list of every user, > to the IdM. > #Then, run the following on the IdM to copy until compl$ cp passwd missing > $ touch present > $ ipa migrate-ds > --bind-dn="cn=linux,ou=LDAPauth,dc=cs,dc=oberlin,dc=edu" > --base-dn="dc=cs,dc=oberlin,dc=edu" --group-container=ou=Group > --user-container=ou=People --user-objectclass=\* --exclude-users=`cat > present | tr '\n' ','` > --user-ignore-objectclass=inetLocalMailRecipient > --user-ignore-attribute="mailHost" > --user-ignore-attribute="mailRoutingAddress" > --user-ignore-objectclass=organizationalPerson > --user-ignore-objectclass=inetOrgPerson > --user-ignore-attribute="givenName" > --user-ignore-attribute="roomNumber" > --user-ignore-attribute="displayName" --user-ignore-attribute="mail" > ldap://cs.oberlin.edu:389 > $ E=1; while [ $E -gt "0" ]; do for i in `cat missing`; do ipa > user-find --login=$i; if [ $? = "0" ]; then echo $i >> present; else > echo $i >> missing1; fi; done; mv missing1 missing; ipa migrate-ds > --bind-dn="cn=linux,ou=LDAPauth,dc=cs,dc=oberlin,dc=edu" > --base-dn="dc=cs,dc=oberlin,dc=edu" --group-container=ou=Group > --user-container=ou=People --user-objectclass=\* --exclude-users=`cat > present | tr '\n' ','` > --user-ignore-objectclass=inetLocalMailRecipient > --user-ignore-attribute="mailHost" > --user-ignore-attribute="mailRoutingAddress" > --user-ignore-objectclass=organizationalPerson > --user-ignore-objectclass=inetOrgPerson > --user-ignore-attribute="homePhone" > --user-ignore-attribute="givenName" > --user-ignore-attribute="roomNumber" > --user-ignore-attribute="displayName" --user-ignore-attribute="mail" > ldap://cs.oberlin.edu:389; E=$?; doneete: > > |Groups were processed a similar way. > > getent group > ||groups > > ||while| |read| |line; ||do| |ipa group-add-member `||echo| |$line | > ||cut| |-d : -f 1` --||users||=`||echo| |$line | ||cut| |-d : -f 4`; > ||done| |< ||groups > > Of course I am not the sys adm that did the migration I am working off > some old notes. > > |Recently I tried to add a replica and the replica install asked me to > run the following on the master. Which I did. > copy-schema-to-ca.py > #! /usr/bin/python2 > > """Copy the IPA schema to the CA directory server instance > > You need to run this script to prepare a 2.2 or 3.0 IPA master for > installation of a 3.1 replica. > > Once a 3.1 replica is in the domain, every older CA master will emit > schema > replication errors until this script is run on it. > > """ > > import os > import sys > import pwd > import shutil > > from ipapython import ipautil, dogtag > from ipapython.ipa_log_manager import root_logger, standard_logging_setup > from ipaserver.install.dsinstance import DS_USER, schema_dirname > from ipaserver.install.cainstance import PKI_USER > from ipalib import api > > try: > from ipaplatform import services > except ImportError: > from ipapython import services # pylint: disable=no-name-in-module > > SERVERID = "PKI-IPA" > SCHEMA_FILENAMES = ( > "60kerberos.ldif", > "60samba.ldif", > "60ipaconfig.ldif", > "60basev2.ldif", > "60basev3.ldif", > "60ipadns.ldif", > "61kerberos-ipav3.ldif", > "65ipacertstore.ldif", > "65ipasudo.ldif", > "70ipaotp.ldif", > "05rfc2247.ldif", This is the file. I guess DogTag needs the relaxed schema definition for some reason? > ) > > > def add_ca_schema(): > """Copy IPA schema files into the CA DS instance > """ > pki_pent = pwd.getpwnam(PKI_USER) > ds_pent = pwd.getpwnam(DS_USER) > for schema_fname in SCHEMA_FILENAMES: > source_fname = os.path.join(ipautil.SHARE_DIR, schema_fname) > target_fname = os.path.join(schema_dirname(SERVERID), > schema_fname) > if not os.path.exists(source_fname): > root_logger.debug('File does not exist: %s', source_fname) > continue > if os.path.exists(target_fname): > root_logger.info( > 'Target exists, not overwriting: %s', target_fname) > continue > try: > shutil.copyfile(source_fname, target_fname) > except IOError, e: > root_logger.warning('Could not install %s: %s', > target_fname, e) > else: > root_logger.info('Installed %s', target_fname) > os.chmod(target_fname, 0440) # read access for dirsrv > user/group > os.chown(target_fname, pki_pent.pw_uid, ds_pent.pw_gid) > > > def restart_pki_ds(): > """Restart the CA DS instance to pick up schema changes > """ > root_logger.info('Restarting CA DS') > services.service('dirsrv').restart(SERVERID) > > > def main(): > if os.getegid() != 0: > sys.exit("Must be root to run this script") > standard_logging_setup(verbose=True) > > # In 3.0, restarting needs access to api.env > (options, argv) = api.bootstrap_with_global_options(context='server') > > add_ca_schema() > restart_pki_ds() > > root_logger.info('Schema updated successfully') > > > main() > > >> This definition is wrong. Both RFC 2247 and RFC 4519 define 'dc' as >> syntax 1.3.6.1.4.1.1466.115.121.1.26 - that is, 7-bit ASCII only. Do >> you have some application that requires 8-bit or unicode characters >> (syntax 1.3.6.1.4.1.1466.115.121.1.15) in domain component names? If >> it is absolutely required that dc accepts unicode, then you'll have >> to change the matching rules as well, to be unicode compatible: >> EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch - that is, >> just get rid of the IA5. > I am only using FreeIPA to authenticate linux clients for user login > via SSSD. Using Pam. I don't have any applications that would require > 8-bit or Unicode characters. Is it possible to return to a standard > definition? > > -Chris > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Feb 9 20:50:43 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Feb 2015 15:50:43 -0500 Subject: [Freeipa-users] How do I modify the entry cache size? In-Reply-To: <54D90A4F.5080100@redhat.com> References: <54D7EA1F.5030209@redhat.com> <54D8C8B5.2080102@redhat.com> <54D8D19E.1080703@oberlin.edu> <54D8DE08.2010002@redhat.com> <54D906E7.2080003@oberlin.edu> <54D90A4F.5080100@redhat.com> Message-ID: <54D91DA3.3040205@redhat.com> Rich Megginson wrote: > On 02/09/2015 12:13 PM, Chris Mohler wrote: >> On 02/09/2015 11:19 AM, Rich Megginson wrote: >>> On 02/09/2015 08:26 AM, Chris Mohler wrote: >>>> On 02/09/2015 09:48 AM, Rich Megginson wrote: >>>>> On 02/08/2015 08:23 PM, Chris Mohler wrote: >>>>>> Thanks for the reply and the link Rich! >>>>>> >>>>>> dbmon.sh is a handy tool indeed. >>>>>> >>>>>> I read the instructions and upped my entry cache size to 2gb >>>>>> because I have enough ram. >>>>>> Everything went well until >>>>>> |service dirsrv restart >>>>>> >>>>>> | >>>>>> |I Got the following errors: >>>>>> [06/Feb/2015:10:07:35 -0500] - slapd stopped. >>>>>> [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching rule [caseIgnoreIA5Match] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] >>>>>> [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] >>>>>> [06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up >>>>>> [06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port 7389 for LDAP requests >>>>>> [06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS requests >>>>>> >>>>>> | >>>>>> |Oddly enough everything appears to be working. Are these messages safe to ignore? >>>>>> | >>>>> >>>>> This is definitely not related to the cache size. >>>>> >>>>> |Not sure what the problem is - looks like something has done an >>>>> override of the standard schema definition of dc. >>>>> http://tools.ietf.org/html/rfc4519 defines it with syntax >>>>> 1.3.6.1.4.1.1466.115.121.1.26. >>>>> >>>>> rpm -q 389-ds-base >>>>> >>>>> find /etc/dirsrv -name \*.ldif -exec grep >>>>> 0.9.2342.19200300.100.1.25 {} /dev/null \; >>>>> >>>>> >>>>> | >>>>>> |Another run of dbmon.sh shows that my entry cache was increased. >>>>>> >>>>>> ||| >>>>>> |Thanks, >>>>>> | >>>>>> |-Chris >>>>>> | >>>>>> | >>>>>> | >>>>>> >>>>>> >>>>>> On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson >>>>>> > wrote: >>>>>> >>>>>> On 02/07/2015 11:25 AM, Chris Mohler wrote: >>>>>>> Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to increase the entry cache size >>>>>>> I'm trying to follow the directions here >>>>>>> /usr/lib/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389 >>>>>>> >>>>>>> dn: cn=/|database_name|/, cn=ldbm database, cn=plugins, cn=config >>>>>>> changetype: modify >>>>>>> replace: nsslapd-cachememsize >>>>>>> nsslapd-cachememsize: 20971520 >>>>>>> >>>>>>> Is this the correct way to do this? How do I find out what the " >>>>>>> cn=/|database_name" is supposed to be? >>>>>>> |/ >>>>>> >>>>>> |/see /|https://github.com/richm/scripts/wiki/dbmon.sh - the >>>>>> script will tell you what the names of your databases are. >>>>>>> /| >>>>>>> |/ >>>>>>> /|Thanks, >>>>>>> |/ >>>>>>> /|-Chris >>>>>>> |/ >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Manage your subscription for the Freeipa-users mailing list: >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> Go To http://freeipa.org for more info on the project >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> Thanks again Rich, >>>> I have been having an abundance of issues with my FreeIPA server >>>> lately. I'm not surprised that error is not related. I was not sure >>>> as It has not surfaced in my logs before I changed the entry cache >>>> size. Possibly this will be the clue to get me on the road to recovery. >>>> >>>>> |Not sure what the problem is - looks like something has done an >>>>> override of the standard schema definition of dc. >>>>> http://tools.ietf.org/html/rfc4519 defines it with syntax >>>>> 1.3.6.1.4.1.1466.115.121.1.26.| >>>> I migrated from OpenLdap about a year ago. So my install is a >>>> migration. I also recently tried to add a replica. Which prompted me >>>> to update the schema on the master before it would replicate. >>> >>> What exactly did you do? You should not have migrated the standard >>> schema from openldap. Did you have to override the definition of >>> 'dc' for some reason? >>> >>>> >>>>> |rpm -q 389-ds-base| >>>> |389-ds-base-1.2.11.15-48.el6_6.x86_64 >>>> >>>> | >>>>> |find /etc/dirsrv -name \*.ldif -exec grep >>>>> 0.9.2342.19200300.100.1.25 {} /dev/null \;| >>>> | >>>> |/etc/dirsrv/slapd-PKI-IPA/schema.bak/00core.ldif:attributeTypes: ( >>>> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >>>> /etc/dirsrv/slapd-PKI-IPA/schema/00core.ldif:attributeTypes: ( >>>> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >>>> /etc/dirsrv/slapd-PKI-IPA/schema/05rfc2247.ldif:attributeTypes: ( >>>> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) DESC >>>> 'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR >>>> caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 >>>> SINGLE-VALUE X-ORIGIN 'RFC 2247' ) >>> >>> This definition is wrong. Both RFC 2247 and RFC 4519 define 'dc' as >>> syntax 1.3.6.1.4.1.1466.115.121.1.26 - that is, 7-bit ASCII only. Do >>> you have some application that requires 8-bit or unicode characters >>> (syntax 1.3.6.1.4.1.1466.115.121.1.15) in domain component names? If >>> it is absolutely required that dc accepts unicode, then you'll have >>> to change the matching rules as well, to be unicode compatible: >>> EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch - that is, >>> just get rid of the IA5. >>> >>> >>>> /etc/dirsrv/schema/00core.ldif:attributeTypes: ( >>>> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >>>> /etc/dirsrv/slapd-CS-OBERLIN-EDU/schema.bak/00core.ldif:attributeTypes: >>>> ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >>>> /etc/dirsrv/slapd-CS-OBERLIN-EDU/schema/00core.ldif:attributeTypes: >>>> ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >>>> >>>> Thanks again, >>>> -Chris >>>> >>>> >>>> >>> >>> >>> >>> What exactly did you do? You should not have migrated the standard >>> schema from openldap. Did you have to override the definition of >>> 'dc' for some reason? >> "what did you do?" Made me smile. >> I dug up my notes from the install and migrate from openldap. After >> ipa-server-install was successful I had a messy migration. I did the >> following >> >> #Disable the compat plugin >> $ipa-compat-manage disable >> >> #Restart the dirservice >> $service dirsrv restart >> >> #Enable Migration >> $ipa config-mod --enable-migration=TRUE > > Are you supposed to do --enable-migration=FALSE or --disable-migration > after migration is complete? Perhaps during migration the schema is relaxed Migration mode just relaxes the pre-hashed password requirement and is a trigger to SSSD to try to migrate the password. We recommend to disable the compat plugin prior to migration to avoid slowing things down considerably. It's ok to re-enable it post-migration. I don't know where the schema errors came from but AFAIR we don't touch the schema for dogtag. rob From rmj at ast.cam.ac.uk Mon Feb 9 22:35:05 2015 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Mon, 09 Feb 2015 22:35:05 +0000 Subject: [Freeipa-users] admin password is always expired Message-ID: <54D93619.9020606@ast.cam.ac.uk> Hi I seem to have locked myself out of my ipa admin account (on RHEL 6.6). This is an evaluation instance so not too big a deal, but a good learning experience. I suspect its some changes that I made to the password policy that caused this. The admin account has expired and I'm trying to reset the password like this: # kadmin.local Authenticating as principal root/admin at REALM with password. kadmin.local: change_password admin at REALM Enter password for principal "admin at REALM": Re-enter password for principal "admin at REALM": Password for "admin at REALM" changed. kadmin.local: q where REALM is my realm. Then when I try to authenticate as admin: # kinit admin Password for admin at REALM: Password expired. You must change it now. Enter new password: Enter it again: kinit: Password has expired while getting initial credentials and the password is not reset. This is what the password policy looks like at the moment: kadmin.local: get_policy global_policy Policy: global_policy Maximum password life: 864000000 Minimum password life: 0 Minimum password length: 8 Minimum number of password character classes: 0 Number of old keys kept: 0 Reference count: 0 Maximum password failures before lockout: 6 Password failure count reset interval: 0 days 00:01:00 Password lockout duration: 0 days 00:10:00 I'm trying to set this back to the defaults in the hope that this allows me to reset the admin password properly, but I'm getting eg: kadmin.local: modify_policy -maxlife "90 days" global_policy modify_policy: Plugin does not support the operation while modifying policy "global_policy". Am I on the right track to fixing the admin password problem? What am I doing wrong in trying to repair the password policy? Actually when I do the following it looks strange that Policy is set to none, but maybe this is a red herring: kadmin.local: get_principal admin Principal: admin at REALM Expiration date: [never] Last password change: Mon Feb 09 18:28:09 GMT 2015 Password expiration date: Tue May 22 11:59:53 GMT 1906 Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Mon Feb 09 18:28:09 GMT 2015 (kadmind at REALM) Last successful authentication: Mon Feb 09 18:27:00 GMT 2015 Last failed authentication: Mon Feb 09 18:25:24 GMT 2015 Failed password attempts: 0 Number of keys: 4 Key: vno 16, aes256-cts-hmac-sha1-96, Version 5 Key: vno 16, aes128-cts-hmac-sha1-96, Version 5 Key: vno 16, des3-cbc-sha1, Version 5 Key: vno 16, arcfour-hmac, Version 5 MKey: vno 1 Attributes: REQUIRES_PRE_AUTH Policy: [none] Thanks for any help in diagnosing this issue or fixing it. Roderick Johnstone From mlasevich at gmail.com Tue Feb 10 00:23:46 2015 From: mlasevich at gmail.com (Michael Lasevich) Date: Mon, 9 Feb 2015 16:23:46 -0800 Subject: [Freeipa-users] Heads up - FC20 softhsm -2.0.0b1-8 rpm from mkosek/freeipa copr appears to be broken Message-ID: To save a day of torture to those of you still on FC20 and using mkosek-freeipa copr repo - it appears that the package ( http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/fedora-20-x86_64/softhsm-2.0.0b1-8.fc20/softhsm-2.0.0b1-8.fc20.x86_64.rpm) is somehow broken. Once installed, you get "Error: Could not load the library." no matter what you do with softhsm2-utll. You will also not going to be able to start/restart the ipa service because DNS is not functional. I have rebuilt the rpm from the source rpm and things seem to be working. Hope this helps someone to not have a day of hair pulling. You have been warned :-) -M -------------- next part -------------- An HTML attachment was scrubbed... URL: From baghery.jone at gmail.com Tue Feb 10 05:42:58 2015 From: baghery.jone at gmail.com (alireza baghery) Date: Tue, 10 Feb 2015 09:12:58 +0330 Subject: [Freeipa-users] error install replication In-Reply-To: <54D8CE61.5050702@redhat.com> References: <54D7565F.2030203@redhat.com> <54D768BC.7050602@redhat.com> <54D86685.8010106@redhat.com> <54D88816.9060904@redhat.com> <54D89EF1.3030401@redhat.com> <54D8C4DD.80308@redhat.com> <54D8CE61.5050702@redhat.com> Message-ID: thanks On Mon, Feb 9, 2015 at 6:42 PM, Martin Kosek wrote: > On 02/09/2015 03:31 PM, Dmitri Pal wrote: > > On 02/09/2015 08:34 AM, alireza baghery wrote: > >> yes try "ssh admin at hostname" but do not work > >> ====log secure-==== > >> > >> Feb 9 15:42:20 ipasrv sshd[13414]: pam_unix(sshd:auth): authentication > >> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.30.160.20 > user=admin > >> Feb 9 15:42:20 ipasrv sshd[13414]: pam_sss(sshd:auth): authentication > >> success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.30.160.20 > user=admin > >> Feb 9 15:42:20 ipasrv sshd[13414]: pam_sss(sshd:account): Access > denied for > >> user admin: 6 (Permission denied) > >> Feb 9 15:42:20 ipasrv sshd[13414]: Failed password for admin from > >> 10.30.160.20 port 52123 ssh2 > >> Feb 9 15:42:20 ipasrv sshd[13415]: fatal: Access denied for user admin > by > >> PAM account configuration > >> > > > > Do you have HBAC rules? Does admin have the rights to log via SSH? > > If you changed the default rules it might be that admin is not allowed > to log > > via ssh. > > Good questions. Also note, that if for some special reasons, you do not > want to > make admins log in to your FreeIPA servers, you can always pass > --skip-conncheck to the replica and go straight to the installation, > skipping > the firewall check. > > Of course, no guarantees that the installation won't get stuck or crash > because > of closed ports in that case. > > Martin > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Feb 10 07:44:26 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 10 Feb 2015 02:44:26 -0500 Subject: [Freeipa-users] admin password is always expired In-Reply-To: <54D93619.9020606@ast.cam.ac.uk> References: <54D93619.9020606@ast.cam.ac.uk> Message-ID: <54D9B6DA.5040302@redhat.com> On 02/09/2015 05:35 PM, Roderick Johnstone wrote: > Hi > > I seem to have locked myself out of my ipa admin account (on RHEL > 6.6). This is an evaluation instance so not too big a deal, but a good > learning experience. I suspect its some changes that I made to the > password policy that caused this. > > The admin account has expired and I'm trying to reset the password > like this: > > # kadmin.local > Authenticating as principal root/admin at REALM with password. > kadmin.local: change_password admin at REALM > Enter password for principal "admin at REALM": > Re-enter password for principal "admin at REALM": > Password for "admin at REALM" changed. > kadmin.local: q > > where REALM is my realm. > > Then when I try to authenticate as admin: > > # kinit admin > Password for admin at REALM: > Password expired. You must change it now. > Enter new password: > Enter it again: > kinit: Password has expired while getting initial credentials > > and the password is not reset. > > This is what the password policy looks like at the moment: > > kadmin.local: get_policy global_policy > Policy: global_policy > Maximum password life: 864000000 > Minimum password life: 0 > Minimum password length: 8 > Minimum number of password character classes: 0 > Number of old keys kept: 0 > Reference count: 0 > Maximum password failures before lockout: 6 > Password failure count reset interval: 0 days 00:01:00 > Password lockout duration: 0 days 00:10:00 > > I'm trying to set this back to the defaults in the hope that this > allows me to reset the admin password properly, but I'm getting eg: > > kadmin.local: modify_policy -maxlife "90 days" global_policy > modify_policy: Plugin does not support the operation while modifying > policy "global_policy". > > Am I on the right track to fixing the admin password problem? > > What am I doing wrong in trying to repair the password policy? > > Actually when I do the following it looks strange that Policy is set > to none, but maybe this is a red herring: > > kadmin.local: get_principal admin > Principal: admin at REALM > Expiration date: [never] > Last password change: Mon Feb 09 18:28:09 GMT 2015 > Password expiration date: Tue May 22 11:59:53 GMT 1906 > Maximum ticket life: 1 day 00:00:00 > Maximum renewable life: 7 days 00:00:00 > Last modified: Mon Feb 09 18:28:09 GMT 2015 (kadmind at REALM) > Last successful authentication: Mon Feb 09 18:27:00 GMT 2015 > Last failed authentication: Mon Feb 09 18:25:24 GMT 2015 > Failed password attempts: 0 > Number of keys: 4 > Key: vno 16, aes256-cts-hmac-sha1-96, Version 5 > Key: vno 16, aes128-cts-hmac-sha1-96, Version 5 > Key: vno 16, des3-cbc-sha1, Version 5 > Key: vno 16, arcfour-hmac, Version 5 > MKey: vno 1 > Attributes: REQUIRES_PRE_AUTH > Policy: [none] > > > Thanks for any help in diagnosing this issue or fixing it. > > Roderick Johnstone > Did you set password expiration for admin manually? The attribute shows that it is 1906. This makes me think that you set your expiration to a big number. However the value rolls over in 2038. So you need to make sure what you set translates to a date before 2038. Why are you using kdamin.local? With IPA it is not supported. There is a bunch of IPA commands that do the same. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From abokovoy at redhat.com Tue Feb 10 07:51:04 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 10 Feb 2015 09:51:04 +0200 Subject: [Freeipa-users] Trust with Active Directory fails In-Reply-To: <0ced1db9caba43f396165b05a502ea20@greyhound.middlebury.edu> References: <581f5e73e3e44f3598421161683d8166@greyhound.middlebury.edu> <20150206082735.GG9247@redhat.com> <680b3e659a3649e79002e5d01ce4d7fd@greyhound.middlebury.edu> <20150209175011.GH9247@redhat.com> <0ced1db9caba43f396165b05a502ea20@greyhound.middlebury.edu> Message-ID: <20150210075104.GI9247@redhat.com> On Mon, 09 Feb 2015, Guertin, David S. wrote: >> Can you send me (off-list) logs as described in >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_tr >> ust > >Alexander, > >Here are the log files you requested. Thanks, you have IPv6 protocol family disabled in your kernel. Samba opens its sockets using IPv6-enabled functions because system library is recommending that (see man page for IPv6). [2015/02/09 13:29:59.577360, 0, pid=3012, effective(0, 0), real(0, 0)] ../source3/lib/util_sock.c:423(open_socket_in) open_socket_in(): socket() call failed: Address family not supported by protocol [2015/02/09 13:29:59.577485, 0, pid=3012, effective(0, 0), real(0, 0)] ../source3/rpc_server/rpc_server.c:636(create_tcpip_socket) Failed to create socket on port 135! [2015/02/09 13:29:59.577523, 0, pid=3012, effective(0, 0), real(0, 0)] ../source3/rpc_server/epmd.c:202(start_epmd) Failed to open epmd tcpip sockets! As result, we are unable to proceed with the connection to local portmapper and cannot operate on the IPA's half of the trust. See http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#IPv6_stack_usage for details. -- / Alexander Bokovoy From sanju.a at tcs.com Tue Feb 10 08:22:43 2015 From: sanju.a at tcs.com (Sanju A) Date: Tue, 10 Feb 2015 13:52:43 +0530 Subject: [Freeipa-users] Renaming Sudo rule name Message-ID: Hi All, Is there any way I can re-name the sudo rule name or copy the existing sudo rule to a new one. Regards Sanju Abraham =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 881 bytes Desc: not available URL: From pvoborni at redhat.com Tue Feb 10 08:53:39 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 10 Feb 2015 09:53:39 +0100 Subject: [Freeipa-users] Renaming Sudo rule name In-Reply-To: References: Message-ID: <54D9C713.3040008@redhat.com> On 02/10/2015 09:22 AM, Sanju A wrote: > Hi All, > > Is there any way I can re-name the sudo rule name or copy the existing > sudo rule to a new one. Hello, sorry, there is no support for that in FreeIPA API atm. But you can rename the rule directly using ldap modify. e.g.: dn: ipaUniqueID=a37f5faa-b0ff-11e4-a92e-001a4a22218e,cn=sudorules,cn=sudo,dc=example,dc=com changetype: modify replace: cn cn: newName Though, I'm not sure if it would cause some undesired side effects. https://fedorahosted.org/freeipa/ticket/2466 https://fedorahosted.org/freeipa/ticket/2911 HTH -- Petr Vobornik From nicolas.zin at savoirfairelinux.com Tue Feb 10 09:42:22 2015 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Tue, 10 Feb 2015 04:42:22 -0500 (EST) Subject: [Freeipa-users] bug with ipa-replica and external dns? In-Reply-To: <1976099190.91305.1423561247102.JavaMail.root@savoirfairelinux.com> Message-ID: <162981591.91457.1423561342950.JavaMail.root@savoirfairelinux.com> Hi. I tried to install IDM 3.3 (RHEL7) without integrated DNS. It works fine until I begin to create a replica: " root at srv-idm7-01 # ipa-replica-prepare srv-idm7-02.hq.company.com --ip-address 192.168.128.22 --no-reverse Directory Manager (existing master) password: You can't add a DNS record because DNS is not set up. " The message is pretty clear: the DNS is not set up: for sure, it is externally managed. Should I consider it as a bug? Or is there something I did wrong? Regards, Nicolas Zin nicolas.zin at savoirfairelinux.com Ligne directe: 514-276-5468 poste 135 Fax : 514-276-5465 7275 Saint Urbain Bureau 200 Montr?al, QC, H2R 2Y5 From mbasti at redhat.com Tue Feb 10 10:02:30 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 Feb 2015 11:02:30 +0100 Subject: [Freeipa-users] bug with ipa-replica and external dns? In-Reply-To: <162981591.91457.1423561342950.JavaMail.root@savoirfairelinux.com> References: <162981591.91457.1423561342950.JavaMail.root@savoirfairelinux.com> Message-ID: <54D9D736.6040708@redhat.com> On 10/02/15 10:42, Nicolas Zin wrote: > Hi. > > I tried to install IDM 3.3 (RHEL7) without integrated DNS. > It works fine until I begin to create a replica: > " > root at srv-idm7-01 # ipa-replica-prepare srv-idm7-02.hq.company.com --ip-address 192.168.128.22 --no-reverse > Directory Manager (existing master) password: > > You can't add a DNS record because DNS is not set up. > " > > The message is pretty clear: the DNS is not set up: for sure, it is externally managed. > Should I consider it as a bug? Or is there something I did wrong? > > > Regards, > > > > Nicolas Zin > nicolas.zin at savoirfairelinux.com > Ligne directe: 514-276-5468 poste 135 > > Fax : 514-276-5465 > 7275 Saint Urbain > Bureau 200 > Montr?al, QC, H2R 2Y5 > > > Hello, configure A/AAAA and reverse records for srv-idm7-02.hq.company.com on your external DNS Then run just ipa-replica-prepare srv-idm7-02.hq.company.com It should work. HTH -- Martin Basti From nicolas.zin at savoirfairelinux.com Tue Feb 10 10:14:13 2015 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Tue, 10 Feb 2015 05:14:13 -0500 (EST) Subject: [Freeipa-users] bug with ipa-replica and external dns? In-Reply-To: <54D9D736.6040708@redhat.com> References: <162981591.91457.1423561342950.JavaMail.root@savoirfairelinux.com> <54D9D736.6040708@redhat.com> Message-ID: <250903965.95999.1423563253022.JavaMail.root@savoirfairelinux.com> >----- Mail original ----- >De: "Martin Basti" >?: "Nicolas Zin" , freeipa-users at redhat.com >Envoy?: Mardi 10 F?vrier 2015 14:02:30 >Objet: Re: [Freeipa-users] bug with ipa-replica and external dns? > >On 10/02/15 10:42, Nicolas Zin wrote: >> Hi. >> >> I tried to install IDM 3.3 (RHEL7) without integrated DNS. >> It works fine until I begin to create a replica: >> " >> root at srv-idm7-01 # ipa-replica-prepare srv-idm7-02.hq.company.com --ip-address 192.168.128.22 --no-reverse >> Directory Manager (existing master) password: >> >> You can't add a DNS record because DNS is not set up. >> " >> >> The message is pretty clear: the DNS is not set up: for sure, it is externally managed. >> Should I consider it as a bug? Or is there something I did wrong? >> >> >> Regards, >> >> >> >> Nicolas Zin >> nicolas.zin at savoirfairelinux.com >> Ligne directe: 514-276-5468 poste 135 >> >> Fax : 514-276-5465 >> 7275 Saint Urbain >> Bureau 200 >> Montr?al, QC, H2R 2Y5 >> >> >> >Hello, > >configure A/AAAA and reverse records for > >srv-idm7-02.hq.company.com > >on your external DNS > > >Then run just > >ipa-replica-prepare srv-idm7-02.hq.company.com > > >It should work. >HTH I have to check again, but I'm pretty sure that A and reverse were already configured (but no AAAA), and I pointed to the correct external DNS server: I was tcpdumping it, and saw the requests. I will see if I remove the --ip-address it change something From rmj at ast.cam.ac.uk Tue Feb 10 11:00:44 2015 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Tue, 10 Feb 2015 11:00:44 +0000 Subject: [Freeipa-users] admin password is always expired In-Reply-To: <54D9B6DA.5040302@redhat.com> References: <54D93619.9020606@ast.cam.ac.uk> <54D9B6DA.5040302@redhat.com> Message-ID: <54D9E4DC.8010401@ast.cam.ac.uk> On 10/02/15 07:44, Dmitri Pal wrote: > On 02/09/2015 05:35 PM, Roderick Johnstone wrote: >> Hi >> >> I seem to have locked myself out of my ipa admin account (on RHEL >> 6.6). This is an evaluation instance so not too big a deal, but a good >> learning experience. I suspect its some changes that I made to the >> password policy that caused this. >> >> The admin account has expired and I'm trying to reset the password >> like this: >> >> # kadmin.local >> Authenticating as principal root/admin at REALM with password. >> kadmin.local: change_password admin at REALM >> Enter password for principal "admin at REALM": >> Re-enter password for principal "admin at REALM": >> Password for "admin at REALM" changed. >> kadmin.local: q >> >> where REALM is my realm. >> >> Then when I try to authenticate as admin: >> >> # kinit admin >> Password for admin at REALM: >> Password expired. You must change it now. >> Enter new password: >> Enter it again: >> kinit: Password has expired while getting initial credentials >> >> and the password is not reset. >> >> This is what the password policy looks like at the moment: >> >> kadmin.local: get_policy global_policy >> Policy: global_policy >> Maximum password life: 864000000 >> Minimum password life: 0 >> Minimum password length: 8 >> Minimum number of password character classes: 0 >> Number of old keys kept: 0 >> Reference count: 0 >> Maximum password failures before lockout: 6 >> Password failure count reset interval: 0 days 00:01:00 >> Password lockout duration: 0 days 00:10:00 >> >> I'm trying to set this back to the defaults in the hope that this >> allows me to reset the admin password properly, but I'm getting eg: >> >> kadmin.local: modify_policy -maxlife "90 days" global_policy >> modify_policy: Plugin does not support the operation while modifying >> policy "global_policy". >> >> Am I on the right track to fixing the admin password problem? >> >> What am I doing wrong in trying to repair the password policy? >> >> Actually when I do the following it looks strange that Policy is set >> to none, but maybe this is a red herring: >> >> kadmin.local: get_principal admin >> Principal: admin at REALM >> Expiration date: [never] >> Last password change: Mon Feb 09 18:28:09 GMT 2015 >> Password expiration date: Tue May 22 11:59:53 GMT 1906 >> Maximum ticket life: 1 day 00:00:00 >> Maximum renewable life: 7 days 00:00:00 >> Last modified: Mon Feb 09 18:28:09 GMT 2015 (kadmind at REALM) >> Last successful authentication: Mon Feb 09 18:27:00 GMT 2015 >> Last failed authentication: Mon Feb 09 18:25:24 GMT 2015 >> Failed password attempts: 0 >> Number of keys: 4 >> Key: vno 16, aes256-cts-hmac-sha1-96, Version 5 >> Key: vno 16, aes128-cts-hmac-sha1-96, Version 5 >> Key: vno 16, des3-cbc-sha1, Version 5 >> Key: vno 16, arcfour-hmac, Version 5 >> MKey: vno 1 >> Attributes: REQUIRES_PRE_AUTH >> Policy: [none] >> >> >> Thanks for any help in diagnosing this issue or fixing it. >> >> Roderick Johnstone >> > Did you set password expiration for admin manually? ok, as far as I remember, I originally changed the global_policy and then encountered the problem described above. ie I couldn't authenticate as admin using: kinit admin In trying to resolve this I found a thread that suggested to change the admin password with: ldappasswd -x -D 'cn=directory manager' -W -S uid=admin,cn=users,cn=accounts,dc=xxx,dc=xxx Maybe this was a bad move? > The attribute shows that it is 1906. This makes me think that you set > your expiration to a big number. However the value rolls over in 2038. > So you need to make sure what you set translates to a date before 2038. I suspect I did set the expiration to too big a number originally. After I was in the always expired loop I found a number of threads mentioning this wrap around issue and I have tried a number of things to fix it, so maybe I'm just making things worse. > > Why are you using kdamin.local? With IPA it is not supported. Out of ignorance I guess. I'm still finding my way into all this stuff! What is the recommended way to reset an admin password in ipa when you can't authenticate as admin? > There is a > bunch of IPA commands that do the same. But if kinit admin won't authenticate me, how can I use the IPA commands? How can I now reset the expiration date for admin when I can't authenticate as admin? Thanks. Roderick > From pspacek at redhat.com Tue Feb 10 11:17:33 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 Feb 2015 12:17:33 +0100 Subject: [Freeipa-users] Heads up - FC20 softhsm -2.0.0b1-8 rpm from mkosek/freeipa copr appears to be broken In-Reply-To: References: Message-ID: <54D9E8CD.6080507@redhat.com> On 10.2.2015 01:23, Michael Lasevich wrote: > To save a day of torture to those of you still on FC20 and using > mkosek-freeipa copr repo - it appears that the package ( > http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/fedora-20-x86_64/softhsm-2.0.0b1-8.fc20/softhsm-2.0.0b1-8.fc20.x86_64.rpm) > is somehow broken. > > Once installed, you get "Error: Could not load the library." no matter what > you do with softhsm2-utll. You will also not going to be able to > start/restart the ipa service because DNS is not functional. > > I have rebuilt the rpm from the source rpm and things seem to be working. > > Hope this helps someone to not have a day of hair pulling. You have been > warned :-) Thank you for heads up! The problem was actually caused by obsolete version of OpenSSL in the COPR repo. It should work now (until Fedora updates repo do not build newer OpenSSL version again :-). Generally - please migrate to Fedora 21 to avoid this kind of problems :-) -- Petr^2 Spacek From nicolas.zin at savoirfairelinux.com Tue Feb 10 11:22:22 2015 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Tue, 10 Feb 2015 06:22:22 -0500 (EST) Subject: [Freeipa-users] bug with ipa-replica and external dns? In-Reply-To: <250903965.95999.1423563253022.JavaMail.root@savoirfairelinux.com> References: <162981591.91457.1423561342950.JavaMail.root@savoirfairelinux.com> <54D9D736.6040708@redhat.com> <250903965.95999.1423563253022.JavaMail.root@savoirfairelinux.com> Message-ID: <1879105546.127504.1423567342221.JavaMail.root@savoirfairelinux.com> great! works if I don't add "--ip-address" thanks! ----- Mail original ----- De: "Nicolas Zin" ?: "Martin Basti" Cc: freeipa-users at redhat.com Envoy?: Mardi 10 F?vrier 2015 14:14:13 Objet: Re: [Freeipa-users] bug with ipa-replica and external dns? >----- Mail original ----- >De: "Martin Basti" >?: "Nicolas Zin" , freeipa-users at redhat.com >Envoy?: Mardi 10 F?vrier 2015 14:02:30 >Objet: Re: [Freeipa-users] bug with ipa-replica and external dns? > >On 10/02/15 10:42, Nicolas Zin wrote: >> Hi. >> >> I tried to install IDM 3.3 (RHEL7) without integrated DNS. >> It works fine until I begin to create a replica: >> " >> root at srv-idm7-01 # ipa-replica-prepare srv-idm7-02.hq.company.com --ip-address 192.168.128.22 --no-reverse >> Directory Manager (existing master) password: >> >> You can't add a DNS record because DNS is not set up. >> " >> >> The message is pretty clear: the DNS is not set up: for sure, it is externally managed. >> Should I consider it as a bug? Or is there something I did wrong? >> >> >> Regards, >> >> >> >> Nicolas Zin >> nicolas.zin at savoirfairelinux.com >> Ligne directe: 514-276-5468 poste 135 >> >> Fax : 514-276-5465 >> 7275 Saint Urbain >> Bureau 200 >> Montr?al, QC, H2R 2Y5 >> >> >> >Hello, > >configure A/AAAA and reverse records for > >srv-idm7-02.hq.company.com > >on your external DNS > > >Then run just > >ipa-replica-prepare srv-idm7-02.hq.company.com > > >It should work. >HTH I have to check again, but I'm pretty sure that A and reverse were already configured (but no AAAA), and I pointed to the correct external DNS server: I was tcpdumping it, and saw the requests. I will see if I remove the --ip-address it change something -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project From mbasti at redhat.com Tue Feb 10 11:29:18 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 Feb 2015 12:29:18 +0100 Subject: [Freeipa-users] bug with ipa-replica and external dns? [SOLVED] In-Reply-To: <1879105546.127504.1423567342221.JavaMail.root@savoirfairelinux.com> References: <162981591.91457.1423561342950.JavaMail.root@savoirfairelinux.com> <54D9D736.6040708@redhat.com> <250903965.95999.1423563253022.JavaMail.root@savoirfairelinux.com> <1879105546.127504.1423567342221.JavaMail.root@savoirfairelinux.com> Message-ID: <54D9EB8E.1000602@redhat.com> On 10/02/15 12:22, Nicolas Zin wrote: > great! > > works if I don't add "--ip-address" > > thanks! > option --ip-address adds the specified address (addresses IPA-4-1) into IPA DNS. IPA currently does not support updating external DNS servers, so that is reason why replica preparation did not work for you. > > ----- Mail original ----- > De: "Nicolas Zin" > ?: "Martin Basti" > Cc: freeipa-users at redhat.com > Envoy?: Mardi 10 F?vrier 2015 14:14:13 > Objet: Re: [Freeipa-users] bug with ipa-replica and external dns? > > > >> ----- Mail original ----- >> De: "Martin Basti" >> ?: "Nicolas Zin" , freeipa-users at redhat.com >> Envoy?: Mardi 10 F?vrier 2015 14:02:30 >> Objet: Re: [Freeipa-users] bug with ipa-replica and external dns? >> >> On 10/02/15 10:42, Nicolas Zin wrote: >>> Hi. >>> >>> I tried to install IDM 3.3 (RHEL7) without integrated DNS. >>> It works fine until I begin to create a replica: >>> " >>> root at srv-idm7-01 # ipa-replica-prepare srv-idm7-02.hq.company.com --ip-address 192.168.128.22 --no-reverse >>> Directory Manager (existing master) password: >>> >>> You can't add a DNS record because DNS is not set up. >>> " >>> >>> The message is pretty clear: the DNS is not set up: for sure, it is externally managed. >>> Should I consider it as a bug? Or is there something I did wrong? >>> >>> >>> Regards, >>> >>> >>> >>> Nicolas Zin >>> nicolas.zin at savoirfairelinux.com >>> Ligne directe: 514-276-5468 poste 135 >>> >>> Fax : 514-276-5465 >>> 7275 Saint Urbain >>> Bureau 200 >>> Montr?al, QC, H2R 2Y5 >>> >>> >>> >> Hello, >> >> configure A/AAAA and reverse records for >> >> srv-idm7-02.hq.company.com >> >> on your external DNS >> >> >> Then run just >> >> ipa-replica-prepare srv-idm7-02.hq.company.com >> >> >> It should work. >> HTH > > I have to check again, but I'm pretty sure that A and reverse were already configured (but no AAAA), and I pointed to the correct external DNS server: I was tcpdumping it, and saw the requests. > I will see if I remove the --ip-address it change something > > > -- Martin Basti From pvoborni at redhat.com Tue Feb 10 11:55:39 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 10 Feb 2015 12:55:39 +0100 Subject: [Freeipa-users] admin password is always expired In-Reply-To: <54D9E4DC.8010401@ast.cam.ac.uk> References: <54D93619.9020606@ast.cam.ac.uk> <54D9B6DA.5040302@redhat.com> <54D9E4DC.8010401@ast.cam.ac.uk> Message-ID: <54D9F1BB.1000108@redhat.com> On 02/10/2015 12:00 PM, Roderick Johnstone wrote: > On 10/02/15 07:44, Dmitri Pal wrote: >> On 02/09/2015 05:35 PM, Roderick Johnstone wrote: >>> Hi >>> >>> I seem to have locked myself out of my ipa admin account (on RHEL >>> 6.6). This is an evaluation instance so not too big a deal, but a good >>> learning experience. I suspect its some changes that I made to the >>> password policy that caused this. >>> >>> The admin account has expired and I'm trying to reset the password >>> like this: >>> >>> # kadmin.local >>> Authenticating as principal root/admin at REALM with password. >>> kadmin.local: change_password admin at REALM >>> Enter password for principal "admin at REALM": >>> Re-enter password for principal "admin at REALM": >>> Password for "admin at REALM" changed. >>> kadmin.local: q >>> >>> where REALM is my realm. >>> >>> Then when I try to authenticate as admin: >>> >>> # kinit admin >>> Password for admin at REALM: >>> Password expired. You must change it now. >>> Enter new password: >>> Enter it again: >>> kinit: Password has expired while getting initial credentials >>> >>> and the password is not reset. >>> >>> This is what the password policy looks like at the moment: >>> >>> kadmin.local: get_policy global_policy >>> Policy: global_policy >>> Maximum password life: 864000000 >>> Minimum password life: 0 >>> Minimum password length: 8 >>> Minimum number of password character classes: 0 >>> Number of old keys kept: 0 >>> Reference count: 0 >>> Maximum password failures before lockout: 6 >>> Password failure count reset interval: 0 days 00:01:00 >>> Password lockout duration: 0 days 00:10:00 >>> >>> I'm trying to set this back to the defaults in the hope that this >>> allows me to reset the admin password properly, but I'm getting eg: >>> >>> kadmin.local: modify_policy -maxlife "90 days" global_policy >>> modify_policy: Plugin does not support the operation while modifying >>> policy "global_policy". >>> >>> Am I on the right track to fixing the admin password problem? >>> >>> What am I doing wrong in trying to repair the password policy? >>> >>> Actually when I do the following it looks strange that Policy is set >>> to none, but maybe this is a red herring: >>> >>> kadmin.local: get_principal admin >>> Principal: admin at REALM >>> Expiration date: [never] >>> Last password change: Mon Feb 09 18:28:09 GMT 2015 >>> Password expiration date: Tue May 22 11:59:53 GMT 1906 >>> Maximum ticket life: 1 day 00:00:00 >>> Maximum renewable life: 7 days 00:00:00 >>> Last modified: Mon Feb 09 18:28:09 GMT 2015 (kadmind at REALM) >>> Last successful authentication: Mon Feb 09 18:27:00 GMT 2015 >>> Last failed authentication: Mon Feb 09 18:25:24 GMT 2015 >>> Failed password attempts: 0 >>> Number of keys: 4 >>> Key: vno 16, aes256-cts-hmac-sha1-96, Version 5 >>> Key: vno 16, aes128-cts-hmac-sha1-96, Version 5 >>> Key: vno 16, des3-cbc-sha1, Version 5 >>> Key: vno 16, arcfour-hmac, Version 5 >>> MKey: vno 1 >>> Attributes: REQUIRES_PRE_AUTH >>> Policy: [none] >>> >>> >>> Thanks for any help in diagnosing this issue or fixing it. >>> >>> Roderick Johnstone >>> > > >> Did you set password expiration for admin manually? > > > ok, as far as I remember, I originally changed the global_policy and > then encountered the problem described above. ie I couldn't authenticate > as admin using: > kinit admin > > In trying to resolve this I found a thread that suggested to change the > admin password with: > ldappasswd -x -D 'cn=directory manager' -W -S > uid=admin,cn=users,cn=accounts,dc=xxx,dc=xxx > > Maybe this was a bad move? > >> The attribute shows that it is 1906. This makes me think that you set >> your expiration to a big number. However the value rolls over in 2038. >> So you need to make sure what you set translates to a date before 2038. > > I suspect I did set the expiration to too big a number originally. After > I was in the always expired loop I found a number of threads mentioning > this wrap around issue and I have tried a number of things to fix it, so > maybe I'm just making things worse. > >> >> Why are you using kdamin.local? With IPA it is not supported. > > Out of ignorance I guess. I'm still finding my way into all this stuff! > > What is the recommended way to reset an admin password in ipa when you > can't authenticate as admin? > >> There is a >> bunch of IPA commands that do the same. > > But if kinit admin won't authenticate me, how can I use the IPA commands? > > How can I now reset the expiration date for admin when I can't > authenticate as admin? > > Thanks. > > Roderick > Resetting the password using ldappasswd won't help if the culprit is global or other IPA password policy. You can change the policy in LDAP as Directory Manager. It's located in: cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com then you can try to kinit and set the new password. -- Petr Vobornik From pspacek at redhat.com Tue Feb 10 11:57:21 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 Feb 2015 12:57:21 +0100 Subject: [Freeipa-users] bug with ipa-replica and external dns? [SOLVED] In-Reply-To: <54D9EB8E.1000602@redhat.com> References: <162981591.91457.1423561342950.JavaMail.root@savoirfairelinux.com> <54D9D736.6040708@redhat.com> <250903965.95999.1423563253022.JavaMail.root@savoirfairelinux.com> <1879105546.127504.1423567342221.JavaMail.root@savoirfairelinux.com> <54D9EB8E.1000602@redhat.com> Message-ID: <54D9F221.4010907@redhat.com> On 10.2.2015 12:29, Martin Basti wrote: > option --ip-address adds the specified address (addresses IPA-4-1) into IPA DNS. > IPA currently does not support updating external DNS servers, so that is > reason why replica preparation did not work for you. Let me add that newer versions of FreeIPA should print following message: """ It is not possible to add a DNS record automatically because DNS is not managed by IPA. Please create DNS record manually and then omit --ip-address option. """ I hope this will clarify it :-) -- Petr^2 Spacek From guertin at middlebury.edu Tue Feb 10 12:18:24 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Tue, 10 Feb 2015 12:18:24 +0000 Subject: [Freeipa-users] Trust with Active Directory fails In-Reply-To: <20150210075104.GI9247@redhat.com> References: <581f5e73e3e44f3598421161683d8166@greyhound.middlebury.edu> <20150206082735.GG9247@redhat.com> <680b3e659a3649e79002e5d01ce4d7fd@greyhound.middlebury.edu> <20150209175011.GH9247@redhat.com> <0ced1db9caba43f396165b05a502ea20@greyhound.middlebury.edu>, <20150210075104.GI9247@redhat.com> Message-ID: <1423570704734.83847@middlebury.edu> Well, that's a surprise! Since the ipv6 module is running, I had assumed that IPv6 is enabled: # lsmod | grep ipv6 ipv6 334932 0 I'll look into getting IPv6 enabled. (This is a RHEL6 server, which uses SysV init instead of systemd.) Thanks for your help. David Guertin Information Technology Services Middlebury College 700 Exchange St. Middlebury, VT 05753 (802)443-3143 ________________________________________ From: Alexander Bokovoy Sent: Tuesday, February 10, 2015 2:51 AM To: Guertin, David S. Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Trust with Active Directory fails On Mon, 09 Feb 2015, Guertin, David S. wrote: >> Can you send me (off-list) logs as described in >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_tr >> ust > >Alexander, > >Here are the log files you requested. Thanks, you have IPv6 protocol family disabled in your kernel. Samba opens its sockets using IPv6-enabled functions because system library is recommending that (see man page for IPv6). [2015/02/09 13:29:59.577360, 0, pid=3012, effective(0, 0), real(0, 0)] ../source3/lib/util_sock.c:423(open_socket_in) open_socket_in(): socket() call failed: Address family not supported by protocol [2015/02/09 13:29:59.577485, 0, pid=3012, effective(0, 0), real(0, 0)] ../source3/rpc_server/rpc_server.c:636(create_tcpip_socket) Failed to create socket on port 135! [2015/02/09 13:29:59.577523, 0, pid=3012, effective(0, 0), real(0, 0)] ../source3/rpc_server/epmd.c:202(start_epmd) Failed to open epmd tcpip sockets! As result, we are unable to proceed with the connection to local portmapper and cannot operate on the IPA's half of the trust. See http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#IPv6_stack_usage for details. -- / Alexander Bokovoy From guertin at middlebury.edu Tue Feb 10 12:53:00 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Tue, 10 Feb 2015 12:53:00 +0000 Subject: [Freeipa-users] Trust with Active Directory fails In-Reply-To: <1423570704734.83847@middlebury.edu> References: <581f5e73e3e44f3598421161683d8166@greyhound.middlebury.edu> <20150206082735.GG9247@redhat.com> <680b3e659a3649e79002e5d01ce4d7fd@greyhound.middlebury.edu> <20150209175011.GH9247@redhat.com> <0ced1db9caba43f396165b05a502ea20@greyhound.middlebury.edu>, <20150210075104.GI9247@redhat.com> <1423570704734.83847@middlebury.edu> Message-ID: <0bc23c4fbd0e486aa9d16805b0afdf09@greyhound.middlebury.edu> For the record, here's the solution I came up with for RHEL6 (and presumably other SysV init-based systems): Its Linux kernel is 2.6, which does have IPv6 enabled. The ipv6 module is loaded. I had looked at those and assumed that everything was OK, but these two are not enough. I needed to edit /etc/modprobe/ipv6.conf and change "ipv6 disable=1" to "ipv6 disable=0". Now it works. David Guertin From cmohler at oberlin.edu Tue Feb 10 13:38:32 2015 From: cmohler at oberlin.edu (Chris Mohler) Date: Tue, 10 Feb 2015 08:38:32 -0500 Subject: [Freeipa-users] Upgrade from 3x to 4x cant create first replica. In-Reply-To: <54D8E20F.5060908@redhat.com> References: <54D54DDE.5040902@oberlin.edu> <54D8CFD9.1080602@redhat.com> <54D8DD56.2010903@oberlin.edu> <54D8E20F.5060908@redhat.com> Message-ID: <54DA09D8.9090101@oberlin.edu> On 02/09/2015 11:36 AM, Martin Kosek wrote: > On 02/09/2015 05:16 PM, Chris Mohler wrote: >> On 02/09/2015 10:18 AM, Martin Kosek wrote: >>> On 02/07/2015 12:27 AM, Chris Mohler wrote: >>>> I'm having some troubles. I have an older IPA install Version 3.0.0. on Centos >>>> 6.6. It's currently the only master for my domain. I have about 4k user >>>> accounts on here and it's a live system called "idm" >>>> >>>> I'm trying to upgrade to V4.x as I am hoping to fix some issues I am having. >>>> (clients can't auth unless service sssd is restarted multiple times "10 (User >>>> not known to the underlying authentication module") I think this is possibly >>>> unrelated and the topic for another thread. >>>> >>>> I created a new VM and installed Fedora Server 21 and FreeIPA 4.1.2 it's called >>>> "ipa" >>> Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked >>> in, so you can also use that platform if you are used to it. >>> >>>> on the master "idm" I ran "ipa-replica-prepare" and transfered the file to the >>>> future replica "ipa" Then I ran the install replica script ipa-replica-install >>>> --setup-ca /home/svradm/replica-info-ipa.cs.oberlin.edu.gpg >>>> Things went well until it failed >>>> >>>> [24/35]: setting up initial replication >>>> Starting replication, please wait until this has completed. >>>> Update in progress, 133 seconds elapsed >>>> Update in progress yet not in progress >>>> >>>> Update in progress yet not in progress >>>> >>>> Update in progress yet not in progress >>>> >>>> [idm.cs.oberlin.edu] reports: Update failed! Status: [10 Total update >>>> abortedLDAP error: Referral] >>>> >>>> [error] RuntimeError: Failed to start replication >>>> >>>> Your system may be partly configured. >>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>> >>>> Please help I'm getting nowhere by myself. >>> Can you please look on the master you are replicating from and look for errors >>> in /var/log/messages or DS errors log? >>> >>> Maybe you will see messages like "ns-slapd: encoded packet size too big (xxxxxx >>>> 65536)" that are know to pop up more with CentOS 6.6. >> Hi Martin, >> Thanks for the reply and help I appreciate it. >> >>> Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked >>> in, so you can also use that platform if you are used to it. >> Good to know. I try to be distro agnostic. I've used Redhat 7.1 then went >> Solaris, then Ubuntu, Now I'm back for Centos and Fedora. I guess I'm equally >> uncomfortable with either version. >> >> That Said. Is there any reason that I could or should not have a replica on a >> Fedora 21 server and 2nd replica on a Centos 7.1 later? My understanding is the >> more the merrier. > It should just work. Just note that in case of Fedora Server, these are > upstream/Fedora bits which are only tested upstream. So if you for example > break something in Fedora 21 (not likely to happen though ;-) and then get the > change *replicated* to RHEL production instance, I do not think Red Hat support > would be happy with that. > > Also, if for example upstream releases FreeIPA 4.2, I would not just plug it in > your production RHEL instance is it would upgrade all the data for 4.2 level - > which should get more downstream testing before Red Hat can rubber stamp it. > > TLDR; if you are happy with the upstream level of support (this list/IRC/Trac), > knock yourself out :-) > >>> Can you please look on the master you are replicating from and look for errors >>> in /var/log/messages or DS errors log? >> I tried to setup the replica again just now so I have some fresh logs. >> >> From the Dirserv error log >> [08/Feb/2015:22:14:48 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up >> [08/Feb/2015:22:14:48 -0500] schema-compat-plugin - warning: no entries set up >> under cn=computers, cn=compat,dc=cs,dc=oberlin,dc=edu >> [08/Feb/2015:22:14:50 -0500] - slapd started. Listening on All Interfaces port >> 389 for LDAP requests >> [08/Feb/2015:22:14:50 -0500] - Listening on All Interfaces port 636 for LDAPS >> requests >> [08/Feb/2015:22:14:50 -0500] - Listening on >> /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests >> [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - >> agmt="cn=meToipa.cs.oberlin.edu" (ipa:389): Schema replication update failed: >> Server is unwilling to perform >> [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Warning: unable to >> replicate schema to host ipa.cs.oberlin.edu, port 389. Continuing with total >> update session. >> [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Beginning total update of >> replica "agmt="cn=meToipa.cs.oberlin.edu" (ipa:389)" >> >> To be fair and not duplicate efforts I have had the following error >> [08/Feb/2015:08:51:26 -0500] - WARNING: userRoot: entry cache size 10485760B is >> less than db size 12115968B; We recommend to increase the >> entry cache size nsslapd-cachememsize. >> >> To which I have asked another question "how do I change the entry cache size" >> https://www.redhat.com/archives/freeipa-users/2015-February/msg00114.html >> I now get additional errors which I would guess are possibly related. > IMO, they this should not be related (should not break replication). I do not > see anything useful in the error log though. Did you also check > /var/log/messages for the errors log I sent? I Did some homework yesterday and noticed starting in fedora 20 the /var/log/messages is no longer used the preferred method of checking logs is to use the "journalctl" command. The Journal actually has a few lined that reference slapd but I don't see any obvious lines in red that say error. Here is what I have Feb 09 10:40:15 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:15 -0500] - SSL alert: Configured NSS Ciphers Feb 09 10:40:16 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:16 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled Feb 09 10:40:16 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:16 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled Feb 09 10:40:16 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:16 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled Feb 09 10:40:16 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:16 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled Feb 09 10:40:16 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:16 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled Feb 09 10:40:16 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:16 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled Feb 09 10:40:16 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:16 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled Feb 09 10:40:17 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:17 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled Feb 09 10:40:17 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:17 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled Feb 09 10:40:17 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:17 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled Feb 09 10:40:17 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:17 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled Feb 09 10:40:17 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:17 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled Feb 09 10:40:18 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:18 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled Feb 09 10:40:18 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:18 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled Feb 09 10:40:18 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:18 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled Feb 09 10:40:18 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:18 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled Feb 09 10:40:18 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:18 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled Feb 09 10:40:18 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:18 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled Feb 09 10:40:18 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:18 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled Feb 09 10:40:18 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:18 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled Feb 09 10:40:18 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:18 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled Feb 09 10:40:18 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:18 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled Feb 09 10:40:18 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:18 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled Feb 09 10:40:18 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:18 -0500] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled Feb 09 10:40:18 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:18 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled Feb 09 10:40:18 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:18 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled Feb 09 10:40:19 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:19 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled Feb 09 10:40:19 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:19 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled Feb 09 10:40:19 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:19 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled Feb 09 10:40:19 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:19 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled Feb 09 10:40:19 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:19 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled Feb 09 10:40:19 ipa.cs.oberlin.edu ns-slapd[1322]: [09/Feb/2015:10:40:19 -0500] SSL Initialization - SSL version range: min: TLS1.0, max: TLS1.2 Feb 09 10:40:22 ipa.cs.oberlin.edu systemd[1]: Configuration file /usr/lib/systemd/system/auditd.service is marked world-inaccessible. This has no effect as configuration data is accessibl Feb 09 10:40:23 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:23 -0500] - SSL alert: Configured NSS Ciphers Feb 09 10:40:23 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:23 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled Feb 09 10:40:23 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:23 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled Feb 09 10:40:24 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:24 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled Feb 09 10:40:24 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:24 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled Feb 09 10:40:24 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:24 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled Feb 09 10:40:24 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:24 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled Feb 09 10:40:24 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:24 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled Feb 09 10:40:24 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:24 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled Feb 09 10:40:24 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:24 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled Feb 09 10:40:24 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:24 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled Feb 09 10:40:24 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:24 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled Feb 09 10:40:24 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:24 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled Feb 09 10:40:24 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:24 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled Feb 09 10:40:24 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:24 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled Feb 09 10:40:24 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:24 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled Feb 09 10:40:24 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:24 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled Feb 09 10:40:24 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:24 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled Feb 09 10:40:24 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:24 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled Feb 09 10:40:25 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled Feb 09 10:40:25 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled Feb 09 10:40:25 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled Feb 09 10:40:25 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled Feb 09 10:40:25 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled Feb 09 10:40:25 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled Feb 09 10:40:25 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled Feb 09 10:40:25 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled Feb 09 10:40:25 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled Feb 09 10:40:25 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled Feb 09 10:40:25 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled Feb 09 10:40:25 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled Feb 09 10:40:25 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:25 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled Feb 09 10:40:25 ipa.cs.oberlin.edu ns-slapd[1389]: [09/Feb/2015:10:40:25 -0500] SSL Initialization - SSL version range: min: TLS1.0, max: TLS1.2 I also took a look at the ipareplica-install.log and there was some odd stuff at the bottom. Is any of this relevant? 2015-02-09T15:42:44Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 372, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 368, in __setup_replica r_bindpw=self.dm_password) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 965, in setup_replication raise RuntimeError("Failed to start replication") RuntimeError: Failed to start replication 2015-02-09T15:42:44Z DEBUG [error] RuntimeError: Failed to start replication 2015-02-09T15:42:44Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 642, in run_script return_value = main_function() File "/sbin/ipa-replica-install", line 700, in main ds = install_replica_ds(config) File "/sbin/ipa-replica-install", line 195, in install_replica_ds ca_file=config.dir + "/ca.crt", File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 355, in create_replica self.start_creation(runtime=60) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 372, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 368, in __setup_replica r_bindpw=self.dm_password) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 965, in setup_replication raise RuntimeError("Failed to start replication") 2015-02-09T15:42:44Z DEBUG The ipa-replica-install command failed, exception: RuntimeError: Failed to start replication -Chris From david.dejaeghere at gmail.com Tue Feb 10 11:17:20 2015 From: david.dejaeghere at gmail.com (David Dejaeghere) Date: Tue, 10 Feb 2015 12:17:20 +0100 Subject: [Freeipa-users] ipa group-add mixed case? Message-ID: Hi, I recently deployed FreeIPA but I stumbled upon a problem with migrating my groups. The groups in our old system are mixed case. Such as MyGroup. The application that syncs these groups is case sensitive. The problem is that when i create these groups using the webgui or the ipa admin tool it gets created using lowercase. I was wondering if there is a way around this? Even perhaps changing a small part in the code. I tried looking into the code of the ipa admin tool but could not find the part that change the group name to lowercase. Any tips or help? Kind Regards, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Feb 10 14:36:37 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Feb 2015 09:36:37 -0500 Subject: [Freeipa-users] admin password is always expired In-Reply-To: <54D9E4DC.8010401@ast.cam.ac.uk> References: <54D93619.9020606@ast.cam.ac.uk> <54D9B6DA.5040302@redhat.com> <54D9E4DC.8010401@ast.cam.ac.uk> Message-ID: <54DA1775.8000809@redhat.com> Roderick Johnstone wrote: > On 10/02/15 07:44, Dmitri Pal wrote: >> On 02/09/2015 05:35 PM, Roderick Johnstone wrote: >>> Hi >>> >>> I seem to have locked myself out of my ipa admin account (on RHEL >>> 6.6). This is an evaluation instance so not too big a deal, but a good >>> learning experience. I suspect its some changes that I made to the >>> password policy that caused this. >>> >>> The admin account has expired and I'm trying to reset the password >>> like this: >>> >>> # kadmin.local >>> Authenticating as principal root/admin at REALM with password. >>> kadmin.local: change_password admin at REALM >>> Enter password for principal "admin at REALM": >>> Re-enter password for principal "admin at REALM": >>> Password for "admin at REALM" changed. >>> kadmin.local: q >>> >>> where REALM is my realm. >>> >>> Then when I try to authenticate as admin: >>> >>> # kinit admin >>> Password for admin at REALM: >>> Password expired. You must change it now. >>> Enter new password: >>> Enter it again: >>> kinit: Password has expired while getting initial credentials >>> >>> and the password is not reset. >>> >>> This is what the password policy looks like at the moment: >>> >>> kadmin.local: get_policy global_policy >>> Policy: global_policy >>> Maximum password life: 864000000 >>> Minimum password life: 0 >>> Minimum password length: 8 >>> Minimum number of password character classes: 0 >>> Number of old keys kept: 0 >>> Reference count: 0 >>> Maximum password failures before lockout: 6 >>> Password failure count reset interval: 0 days 00:01:00 >>> Password lockout duration: 0 days 00:10:00 >>> >>> I'm trying to set this back to the defaults in the hope that this >>> allows me to reset the admin password properly, but I'm getting eg: >>> >>> kadmin.local: modify_policy -maxlife "90 days" global_policy >>> modify_policy: Plugin does not support the operation while modifying >>> policy "global_policy". >>> >>> Am I on the right track to fixing the admin password problem? >>> >>> What am I doing wrong in trying to repair the password policy? >>> >>> Actually when I do the following it looks strange that Policy is set >>> to none, but maybe this is a red herring: >>> >>> kadmin.local: get_principal admin >>> Principal: admin at REALM >>> Expiration date: [never] >>> Last password change: Mon Feb 09 18:28:09 GMT 2015 >>> Password expiration date: Tue May 22 11:59:53 GMT 1906 >>> Maximum ticket life: 1 day 00:00:00 >>> Maximum renewable life: 7 days 00:00:00 >>> Last modified: Mon Feb 09 18:28:09 GMT 2015 (kadmind at REALM) >>> Last successful authentication: Mon Feb 09 18:27:00 GMT 2015 >>> Last failed authentication: Mon Feb 09 18:25:24 GMT 2015 >>> Failed password attempts: 0 >>> Number of keys: 4 >>> Key: vno 16, aes256-cts-hmac-sha1-96, Version 5 >>> Key: vno 16, aes128-cts-hmac-sha1-96, Version 5 >>> Key: vno 16, des3-cbc-sha1, Version 5 >>> Key: vno 16, arcfour-hmac, Version 5 >>> MKey: vno 1 >>> Attributes: REQUIRES_PRE_AUTH >>> Policy: [none] >>> >>> >>> Thanks for any help in diagnosing this issue or fixing it. >>> >>> Roderick Johnstone >>> > > >> Did you set password expiration for admin manually? > > > ok, as far as I remember, I originally changed the global_policy and > then encountered the problem described above. ie I couldn't authenticate > as admin using: > kinit admin > > In trying to resolve this I found a thread that suggested to change the > admin password with: > ldappasswd -x -D 'cn=directory manager' -W -S > uid=admin,cn=users,cn=accounts,dc=xxx,dc=xxx > > Maybe this was a bad move? > >> The attribute shows that it is 1906. This makes me think that you set >> your expiration to a big number. However the value rolls over in 2038. >> So you need to make sure what you set translates to a date before 2038. > > I suspect I did set the expiration to too big a number originally. After > I was in the always expired loop I found a number of threads mentioning > this wrap around issue and I have tried a number of things to fix it, so > maybe I'm just making things worse. > >> >> Why are you using kdamin.local? With IPA it is not supported. > > Out of ignorance I guess. I'm still finding my way into all this stuff! > > What is the recommended way to reset an admin password in ipa when you > can't authenticate as admin? > >> There is a >> bunch of IPA commands that do the same. > > But if kinit admin won't authenticate me, how can I use the IPA commands? > > How can I now reset the expiration date for admin when I can't > authenticate as admin? > The easiest path forward is to bind as Directory Manager and change the password expiration date for the admin user. Then you can use that user to more easily modify the password policy. You want to change krbPasswordExpiration. rob From pradyd at qinec.com Tue Feb 10 15:59:37 2015 From: pradyd at qinec.com (Prady Dash) Date: Tue, 10 Feb 2015 15:59:37 +0000 Subject: [Freeipa-users] LDAP Connection error while Integrating AD with FreeIPA Message-ID: Hi, I am trying to integrate AD with FreeIPA. I was following the below document. https://www.freeipa.org/images/2/2b/Installation_and_Deployment_Guide.pdf While configuring am facing the below error. [root at appserver2 ~]# ipa-replica-manage connect --winsync --binddn cn=Administrator,cn=users,dc=abc,dc=local --bindpw XXXXXXX --passsync XXXXXX --passsync XXXXXXX --cacert /etc/openldap/certs/abc.cer ad.abc.local -v Directory Manager password: Added CA certificate /etc/openldap/certs/ abc.cer to certificate database for appserver2.qinec.com ipa: INFO: AD Suffix is: DC=abc,DC=local The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=xyz,dc=com Windows PassSync entry exists, not resetting password ipa: INFO: Added new sync agreement, waiting for it to become ready . . . ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP error: Connect error: start: 0: end: 0 ipa: INFO: Agreement is ready, starting replication . . . Starting replication, please wait until this has completed. [appserver2.abc.com] reports: Update failed! Status: [-11 - LDAP error: Connect error] Failed to start replication Please suggest. Regards, /Prady -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Feb 10 16:07:11 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 10 Feb 2015 11:07:11 -0500 Subject: [Freeipa-users] LDAP Connection error while Integrating AD with FreeIPA In-Reply-To: References: Message-ID: <54DA2CAF.4080808@redhat.com> On 02/10/2015 10:59 AM, Prady Dash wrote: > > Hi, > > I am trying to integrate AD with FreeIPA. I was following the below > document. > > https://www.freeipa.org/images/2/2b/Installation_and_Deployment_Guide.pdf > > While configuring am facing the below error. > > /[root at appserver2 ~]# ipa-replica-manage connect --winsync --binddn > cn=Administrator,cn=users,dc=abc,dc=local --bindpw XXXXXXX --passsync > XXXXXX --passsync XXXXXXX --cacert /etc/openldap/certs/abc.cer > ad.abc.local -v/ > > /Directory Manager password:/ > > // > > /Added CA certificate /etc/openldap/certs/ abc.cer to certificate > database for appserver2.qinec.com/ > > /ipa: INFO: AD Suffix is: DC=abc,DC=local/ > > /The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=xyz,dc=com/ > > /Windows PassSync entry exists, not resetting password/ > > /ipa: INFO: Added new sync agreement, waiting for it to become ready . > . ./ > > /ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP > error: Connect error: start: 0: end: 0/ > > /ipa: INFO: Agreement is ready, starting replication . . ./ > > /Starting replication, please wait until this has completed./ > > /[appserver2.abc.com] reports: Update failed! Status: [-11 - LDAP > error: Connect error]/ > > /Failed to start replication/ > > // > > Please suggest.// > > Regards, > > /Prady > > > This is a very old documentation. Please use the latest documentation on the Red Hat portal. What IPA version and platform are you using? Do you really want to sync users? Have you considered a trust? Are you aware of that option which is preferred now? -- 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 Tue Feb 10 16:14:11 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Feb 2015 11:14:11 -0500 Subject: [Freeipa-users] LDAP Connection error while Integrating AD with FreeIPA In-Reply-To: References: Message-ID: <54DA2E53.4030802@redhat.com> Prady Dash wrote: > Hi, > > > > I am trying to integrate AD with FreeIPA. I was following the below > document. > > > > https://www.freeipa.org/images/2/2b/Installation_and_Deployment_Guide.pdf > > > > While configuring am facing the below error. > > > > /[root at appserver2 ~]# ipa-replica-manage connect --winsync --binddn > cn=Administrator,cn=users,dc=abc,dc=local --bindpw XXXXXXX --passsync > XXXXXX --passsync XXXXXXX --cacert /etc/openldap/certs/abc.cer > ad.abc.local -v/ > > /Directory Manager password:/ > > / / > > /Added CA certificate /etc/openldap/certs/ abc.cer to certificate > database for appserver2.qinec.com/ > > /ipa: INFO: AD Suffix is: DC=abc,DC=local/ > > /The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=xyz,dc=com/ > > /Windows PassSync entry exists, not resetting password/ > > /ipa: INFO: Added new sync agreement, waiting for it to become ready . . ./ > > /ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP > error: Connect error: start: 0: end: 0/ > > /ipa: INFO: Agreement is ready, starting replication . . ./ > > /Starting replication, please wait until this has completed./ > > /[appserver2.abc.com] reports: Update failed! Status: [-11 - LDAP > error: Connect error]/ > > /Failed to start replication/ > > / / > > Please suggest.// LDAP error -11 is LDAP_CONNECT_ERROR so normally I'd suggest checking firewalls and such. The thing is though, IPA made an LDAP connection to find the AD Suffix so both connectivity and the CA provided are exercised successfully. I'd check the 389-ds access and error logs in /var/log/dirsrv/slapd-REALM/ You probably want to consider using AD trust instead of winsync if you haven't looked into it yet. rob From pradyd at qinec.com Tue Feb 10 16:21:37 2015 From: pradyd at qinec.com (Prady Dash) Date: Tue, 10 Feb 2015 16:21:37 +0000 Subject: [Freeipa-users] LDAP Connection error while Integrating AD with FreeIPA In-Reply-To: <54DA2CAF.4080808@redhat.com> References: <54DA2CAF.4080808@redhat.com> Message-ID: Hi, I am using the below version : ipa-server-3.0.0-42.el6.x86_64 What I want is to integrate AD with FreeIPA so in case of AD failure FreeIPA should able to handle the requests( might be temporary such as cache or something like that ). Regards, /Prady From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: 10 February 2015 16:07 To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] LDAP Connection error while Integrating AD with FreeIPA On 02/10/2015 10:59 AM, Prady Dash wrote: Hi, I am trying to integrate AD with FreeIPA. I was following the below document. https://www.freeipa.org/images/2/2b/Installation_and_Deployment_Guide.pdf While configuring am facing the below error. [root at appserver2 ~]# ipa-replica-manage connect --winsync --binddn cn=Administrator,cn=users,dc=abc,dc=local --bindpw XXXXXXX --passsync XXXXXX --passsync XXXXXXX --cacert /etc/openldap/certs/abc.cer ad.abc.local -v Directory Manager password: Added CA certificate /etc/openldap/certs/ abc.cer to certificate database for appserver2.qinec.com ipa: INFO: AD Suffix is: DC=abc,DC=local The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=xyz,dc=com Windows PassSync entry exists, not resetting password ipa: INFO: Added new sync agreement, waiting for it to become ready . . . ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP error: Connect error: start: 0: end: 0 ipa: INFO: Agreement is ready, starting replication . . . Starting replication, please wait until this has completed. [appserver2.abc.com] reports: Update failed! Status: [-11 - LDAP error: Connect error] Failed to start replication Please suggest. Regards, /Prady This is a very old documentation. Please use the latest documentation on the Red Hat portal. What IPA version and platform are you using? Do you really want to sync users? Have you considered a trust? Are you aware of that option which is preferred now? -- 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 Tue Feb 10 17:08:33 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 10 Feb 2015 12:08:33 -0500 Subject: [Freeipa-users] LDAP Connection error while Integrating AD with FreeIPA In-Reply-To: References: <54DA2CAF.4080808@redhat.com> Message-ID: <54DA3B11.3020203@redhat.com> On 02/10/2015 11:21 AM, Prady Dash wrote: > > Hi, > > I am using the below version : > > ipa-server-3.0.0-42.el6.x86_64 > > What I want is to integrate AD with FreeIPA so in case of AD failure > FreeIPA should able to handle the requests( might be temporary such > as cache or something like that ). > This is not the use case that would be easy to make work. So are you planning to configure SSSD on clients to use AD and IPA domains in parallel? > Regards, > > /Prady > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* 10 February 2015 16:07 > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] LDAP Connection error while Integrating > AD with FreeIPA > > On 02/10/2015 10:59 AM, Prady Dash wrote: > > Hi, > > I am trying to integrate AD with FreeIPA. I was following the > below document. > > https://www.freeipa.org/images/2/2b/Installation_and_Deployment_Guide.pdf > > While configuring am facing the below error. > > /[root at appserver2 ~]# ipa-replica-manage connect --winsync > --binddn cn=Administrator,cn=users,dc=abc,dc=local --bindpw > XXXXXXX --passsync XXXXXX --passsync XXXXXXX --cacert > /etc/openldap/certs/abc.cer ad.abc.local -v/ > > /Directory Manager password:/ > > // > > /Added CA certificate /etc/openldap/certs/ abc.cer to certificate > database for appserver2.qinec.com/ > > /ipa: INFO: AD Suffix is: DC=abc,DC=local/ > > /The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=xyz,dc=com/ > > /Windows PassSync entry exists, not resetting password/ > > /ipa: INFO: Added new sync agreement, waiting for it to become > ready . . ./ > > /ipa: INFO: Replication Update in progress: FALSE: status: -11 - > LDAP error: Connect error: start: 0: end: 0/ > > /ipa: INFO: Agreement is ready, starting replication . . ./ > > /Starting replication, please wait until this has completed./ > > /[appserver2.abc.com] reports: Update failed! Status: [-11 - LDAP > error: Connect error]/ > > /Failed to start replication/ > > // > > Please suggest. > > Regards, > > /Prady > > > > This is a very old documentation. > Please use the latest documentation on the Red Hat portal. > What IPA version and platform are you using? > Do you really want to sync users? Have you considered a trust? Are you > aware of that option which is preferred now? > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pradyd at qinec.com Tue Feb 10 17:14:25 2015 From: pradyd at qinec.com (Prady Dash) Date: Tue, 10 Feb 2015 17:14:25 +0000 Subject: [Freeipa-users] LDAP Connection error while Integrating AD with FreeIPA In-Reply-To: <54DA3B11.3020203@redhat.com> References: <54DA2CAF.4080808@redhat.com> <54DA3B11.3020203@redhat.com> Message-ID: Hi, Use Case : We have a user group for VPN, So in a case of DR no one else would able to use VPN as AD is the SPOF, So what am trying to achieve if FreeIPA can help to hold the user data for this group might be temporary so that users could use VPN during AD failure. Is this possible ? Regards, /Prady From: Dmitri Pal [mailto:dpal at redhat.com] Sent: 10 February 2015 17:09 To: Prady Dash; freeipa-users at redhat.com Subject: Re: [Freeipa-users] LDAP Connection error while Integrating AD with FreeIPA On 02/10/2015 11:21 AM, Prady Dash wrote: Hi, I am using the below version : ipa-server-3.0.0-42.el6.x86_64 What I want is to integrate AD with FreeIPA so in case of AD failure FreeIPA should able to handle the requests( might be temporary such as cache or something like that ). This is not the use case that would be easy to make work. So are you planning to configure SSSD on clients to use AD and IPA domains in parallel? Regards, /Prady From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: 10 February 2015 16:07 To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] LDAP Connection error while Integrating AD with FreeIPA On 02/10/2015 10:59 AM, Prady Dash wrote: Hi, I am trying to integrate AD with FreeIPA. I was following the below document. https://www.freeipa.org/images/2/2b/Installation_and_Deployment_Guide.pdf While configuring am facing the below error. [root at appserver2 ~]# ipa-replica-manage connect --winsync --binddn cn=Administrator,cn=users,dc=abc,dc=local --bindpw XXXXXXX --passsync XXXXXX --passsync XXXXXXX --cacert /etc/openldap/certs/abc.cer ad.abc.local -v Directory Manager password: Added CA certificate /etc/openldap/certs/ abc.cer to certificate database for appserver2.qinec.com ipa: INFO: AD Suffix is: DC=abc,DC=local The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=xyz,dc=com Windows PassSync entry exists, not resetting password ipa: INFO: Added new sync agreement, waiting for it to become ready . . . ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP error: Connect error: start: 0: end: 0 ipa: INFO: Agreement is ready, starting replication . . . Starting replication, please wait until this has completed. [appserver2.abc.com] reports: Update failed! Status: [-11 - LDAP error: Connect error] Failed to start replication Please suggest. Regards, /Prady This is a very old documentation. Please use the latest documentation on the Red Hat portal. What IPA version and platform are you using? Do you really want to sync users? Have you considered a trust? Are you aware of that option which is preferred now? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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 Tue Feb 10 17:24:37 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 10 Feb 2015 12:24:37 -0500 Subject: [Freeipa-users] LDAP Connection error while Integrating AD with FreeIPA In-Reply-To: References: <54DA2CAF.4080808@redhat.com> <54DA3B11.3020203@redhat.com> Message-ID: <54DA3ED5.7080707@redhat.com> On 02/10/2015 12:14 PM, Prady Dash wrote: > > Hi, > > Use Case : > > We have a user group for VPN, So in a case of DR no one else would > able to use VPN as AD is the SPOF, So what am trying to achieve if > FreeIPA can help to hold the user data for this group might be > temporary so that users could use VPN during AD failure. > > Is this possible ? > This would be possible but would require reconfiguration of the VPN in case of problems with AD. It would also require for you to do a winsync of the user passwords keep passwords in sync. I am all for you using FreeIPA for this but seems like a much more work for you than to add another AD instance or use Samba 4 as a secondary DC. > Regards, > > /Prady > > *From:*Dmitri Pal [mailto:dpal at redhat.com] > *Sent:* 10 February 2015 17:09 > *To:* Prady Dash; freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] LDAP Connection error while Integrating > AD with FreeIPA > > On 02/10/2015 11:21 AM, Prady Dash wrote: > > Hi, > > I am using the below version : > > ipa-server-3.0.0-42.el6.x86_64 > > What I want is to integrate AD with FreeIPA so in case of AD > failure FreeIPA should able to handle the requests( might be > temporary such as cache or something like that ). > > > This is not the use case that would be easy to make work. > So are you planning to configure SSSD on clients to use AD and IPA > domains in parallel? > > > Regards, > > /Prady > > *From:*freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* 10 February 2015 16:07 > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] LDAP Connection error while > Integrating AD with FreeIPA > > On 02/10/2015 10:59 AM, Prady Dash wrote: > > Hi, > > I am trying to integrate AD with FreeIPA. I was following the > below document. > > https://www.freeipa.org/images/2/2b/Installation_and_Deployment_Guide.pdf > > While configuring am facing the below error. > > /[root at appserver2 ~]# ipa-replica-manage connect --winsync > --binddn cn=Administrator,cn=users,dc=abc,dc=local --bindpw > XXXXXXX --passsync XXXXXX --passsync XXXXXXX --cacert > /etc/openldap/certs/abc.cer ad.abc.local -v/ > > /Directory Manager password:/ > > // > > /Added CA certificate /etc/openldap/certs/ abc.cer to > certificate database for appserver2.qinec.com/ > > /ipa: INFO: AD Suffix is: DC=abc,DC=local/ > > /The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=xyz,dc=com/ > > /Windows PassSync entry exists, not resetting password/ > > /ipa: INFO: Added new sync agreement, waiting for it to become > ready . . ./ > > /ipa: INFO: Replication Update in progress: FALSE: status: > -11 - LDAP error: Connect error: start: 0: end: 0/ > > /ipa: INFO: Agreement is ready, starting replication . . ./ > > /Starting replication, please wait until this has completed./ > > /[appserver2.abc.com] reports: Update failed! Status: [-11 - > LDAP error: Connect error]/ > > /Failed to start replication/ > > // > > Please suggest. > > Regards, > > /Prady > > > > > This is a very old documentation. > Please use the latest documentation on the Red Hat portal. > What IPA version and platform are you using? > Do you really want to sync users? Have you considered a trust? Are > you aware of that option which is preferred now? > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager IdM portfolio > > Red Hat, Inc. > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yoshi314 at gmail.com Tue Feb 10 17:35:32 2015 From: yoshi314 at gmail.com (marcin kowalski) Date: Tue, 10 Feb 2015 18:35:32 +0100 Subject: [Freeipa-users] slight problem when integrating certmonger with dogtag on fedora 21 Message-ID: Hi all, i'm getting dogtag figured out slowly, and i noticed one odd thing. I've setup certmonger to request an arbitrary certificate through dogtag, and while the request seems to go into the dogtag system, certmonger acts as if communication with the CA failed. The certificate is considered in need of user attention because the process got stuck. Request ID ?20150210125814?: status: NEED_GUIDANCE stuck: yes key pair storage: type=FILE,location=?/etc/pki/testkey? certificate: type=FILE,location=?/etc/pki/testcert? CA: dogtag-ipa issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes [root at fedora pki]# systemctl status -l certmonger (?.) lut 10 13:57:04 fedora.box.net certmonger[7845]: Request for certificate to be stored in file ?/etc/pki/testcert? rejected by CA. The request is present in dogtag and is valid, can be accepted/rejected, etc. Even though certmonger never notices that. I wonder if there is some obvious mistake in my setup, or perhaps there is known bug in interaction of both components on F21 (i'm using only standard repositories). When i post the query from certmonger's agent defined in ca definition through curl, i get no errors. What would be the best way to debug this issue? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmj at ast.cam.ac.uk Tue Feb 10 17:35:39 2015 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Tue, 10 Feb 2015 17:35:39 +0000 Subject: [Freeipa-users] admin password is always expired In-Reply-To: <54DA1775.8000809@redhat.com> References: <54D93619.9020606@ast.cam.ac.uk> <54D9B6DA.5040302@redhat.com> <54D9E4DC.8010401@ast.cam.ac.uk> <54DA1775.8000809@redhat.com> Message-ID: <54DA416B.2060704@ast.cam.ac.uk> On 10/02/2015 14:36, Rob Crittenden wrote: > Roderick Johnstone wrote: >> On 10/02/15 07:44, Dmitri Pal wrote: >>> On 02/09/2015 05:35 PM, Roderick Johnstone wrote: >>>> Hi >>>> >>>> I seem to have locked myself out of my ipa admin account (on RHEL >>>> 6.6). This is an evaluation instance so not too big a deal, but a good >>>> learning experience. I suspect its some changes that I made to the >>>> password policy that caused this. >>>> >>>> The admin account has expired and I'm trying to reset the password >>>> like this: >>>> >>>> # kadmin.local >>>> Authenticating as principal root/admin at REALM with password. >>>> kadmin.local: change_password admin at REALM >>>> Enter password for principal "admin at REALM": >>>> Re-enter password for principal "admin at REALM": >>>> Password for "admin at REALM" changed. >>>> kadmin.local: q >>>> >>>> where REALM is my realm. >>>> >>>> Then when I try to authenticate as admin: >>>> >>>> # kinit admin >>>> Password for admin at REALM: >>>> Password expired. You must change it now. >>>> Enter new password: >>>> Enter it again: >>>> kinit: Password has expired while getting initial credentials >>>> >>>> and the password is not reset. >>>> >>>> This is what the password policy looks like at the moment: >>>> >>>> kadmin.local: get_policy global_policy >>>> Policy: global_policy >>>> Maximum password life: 864000000 >>>> Minimum password life: 0 >>>> Minimum password length: 8 >>>> Minimum number of password character classes: 0 >>>> Number of old keys kept: 0 >>>> Reference count: 0 >>>> Maximum password failures before lockout: 6 >>>> Password failure count reset interval: 0 days 00:01:00 >>>> Password lockout duration: 0 days 00:10:00 >>>> >>>> I'm trying to set this back to the defaults in the hope that this >>>> allows me to reset the admin password properly, but I'm getting eg: >>>> >>>> kadmin.local: modify_policy -maxlife "90 days" global_policy >>>> modify_policy: Plugin does not support the operation while modifying >>>> policy "global_policy". >>>> >>>> Am I on the right track to fixing the admin password problem? >>>> >>>> What am I doing wrong in trying to repair the password policy? >>>> >>>> Actually when I do the following it looks strange that Policy is set >>>> to none, but maybe this is a red herring: >>>> >>>> kadmin.local: get_principal admin >>>> Principal: admin at REALM >>>> Expiration date: [never] >>>> Last password change: Mon Feb 09 18:28:09 GMT 2015 >>>> Password expiration date: Tue May 22 11:59:53 GMT 1906 >>>> Maximum ticket life: 1 day 00:00:00 >>>> Maximum renewable life: 7 days 00:00:00 >>>> Last modified: Mon Feb 09 18:28:09 GMT 2015 (kadmind at REALM) >>>> Last successful authentication: Mon Feb 09 18:27:00 GMT 2015 >>>> Last failed authentication: Mon Feb 09 18:25:24 GMT 2015 >>>> Failed password attempts: 0 >>>> Number of keys: 4 >>>> Key: vno 16, aes256-cts-hmac-sha1-96, Version 5 >>>> Key: vno 16, aes128-cts-hmac-sha1-96, Version 5 >>>> Key: vno 16, des3-cbc-sha1, Version 5 >>>> Key: vno 16, arcfour-hmac, Version 5 >>>> MKey: vno 1 >>>> Attributes: REQUIRES_PRE_AUTH >>>> Policy: [none] >>>> >>>> >>>> Thanks for any help in diagnosing this issue or fixing it. >>>> >>>> Roderick Johnstone >>>> >> >> >>> Did you set password expiration for admin manually? >> >> >> ok, as far as I remember, I originally changed the global_policy and >> then encountered the problem described above. ie I couldn't authenticate >> as admin using: >> kinit admin >> >> In trying to resolve this I found a thread that suggested to change the >> admin password with: >> ldappasswd -x -D 'cn=directory manager' -W -S >> uid=admin,cn=users,cn=accounts,dc=xxx,dc=xxx >> >> Maybe this was a bad move? >> >>> The attribute shows that it is 1906. This makes me think that you set >>> your expiration to a big number. However the value rolls over in 2038. >>> So you need to make sure what you set translates to a date before 2038. >> >> I suspect I did set the expiration to too big a number originally. After >> I was in the always expired loop I found a number of threads mentioning >> this wrap around issue and I have tried a number of things to fix it, so >> maybe I'm just making things worse. >> >>> >>> Why are you using kdamin.local? With IPA it is not supported. >> >> Out of ignorance I guess. I'm still finding my way into all this stuff! >> >> What is the recommended way to reset an admin password in ipa when you >> can't authenticate as admin? >> >>> There is a >>> bunch of IPA commands that do the same. >> >> But if kinit admin won't authenticate me, how can I use the IPA commands? >> >> How can I now reset the expiration date for admin when I can't >> authenticate as admin? >> > > The easiest path forward is to bind as Directory Manager and change the > password expiration date for the admin user. Then you can use that user > to more easily modify the password policy. > > You want to change krbPasswordExpiration. > > rob > Rob Thanks for your reply. Your email came while I was working on this. I seem to have achieved the same result by doing: # ldapmodify -h localhost -x -W -D "cn=directory manager" -f krb.ldif where I used: # ldapsearch -x -b "dc=xxx,dc=xxx" to find the entry for dn: cn=global_policy,cn=XXX.XXX,cn=kerberos,dc=xxx,dc=xxx I then made krb.ldif that contains: dn: cn=global_policy,cn=XXX.XXX,cn=kerberos,dc=xxx,dc=xxx changetype: modify replace: krbMaxPwdLife krbMaxPwdLife: 864000 Then I was able to reset the password with kadmin.local as before. I see that your solution is much more direct. I'm still learning about all this. Thanks again. Roderick From dpal at redhat.com Tue Feb 10 17:40:08 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 10 Feb 2015 12:40:08 -0500 Subject: [Freeipa-users] slight problem when integrating certmonger with dogtag on fedora 21 In-Reply-To: References: Message-ID: <54DA4278.6000206@redhat.com> On 02/10/2015 12:35 PM, marcin kowalski wrote: > Hi all, i'm getting dogtag figured out slowly, and i noticed one odd > thing. > > I've setup certmonger to request an arbitrary certificate through > dogtag, and while the request seems to go into the dogtag system, > certmonger acts as if communication with the CA failed. The > certificate is considered in need of user attention because the > process got stuck. > > Request ID '20150210125814': > status: NEED_GUIDANCE > stuck: yes > key pair storage: type=FILE,location='/etc/pki/testkey' > certificate: type=FILE,location='/etc/pki/testcert' > CA: dogtag-ipa > issuer: > subject: > expires: unknown > pre-save command: > post-save command: > track: yes > auto-renew: yes > > > [root at fedora pki]# systemctl status -l certmonger > (....) > lut 10 13:57:04 fedora.box.net > certmonger[7845]: Request for certificate to be stored in file > "/etc/pki/testcert" rejected by CA. > > > The request is present in dogtag and is valid, can be > accepted/rejected, etc. Even though certmonger never notices that. I > wonder if there is some obvious mistake in my setup, or perhaps there > is known bug in interaction of both components on F21 (i'm using only > standard repositories). > > When i post the query from certmonger's agent defined in ca definition > through curl, i get no errors. > > What would be the best way to debug this issue? > > Can you post your certmonger get-cert command? -- 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 Tue Feb 10 19:42:35 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Feb 2015 14:42:35 -0500 Subject: [Freeipa-users] ipa group-add mixed case? In-Reply-To: References: Message-ID: <54DA5F2B.7010002@redhat.com> David Dejaeghere wrote: > Hi, > > I recently deployed FreeIPA but I stumbled upon a problem with migrating > my groups. The groups in our old system are mixed case. Such as MyGroup. > The application that syncs these groups is case sensitive. The problem > is that when i create these groups using the webgui or the ipa admin > tool it gets created using lowercase. I was wondering if there is a way > around this? Even perhaps changing a small part in the code. I tried > looking into the code of the ipa admin tool but could not find the part > that change the group name to lowercase. Any tips or help? IPA has always forced lower-case group names. The value is stored in the cn attribute in LDAP which is case insensitive so allowing mixed-case would just cause confusion (because you can't have myGroup and MYgroup). I really wouldn't recommend changing the IPA source as it is going to be difficult to remember making the same change across all masters with each update, beyond the fact that it has never been tested. Who knows how compatible this will be internally. But in any case, in ipalib/plugins/group.py you'll find where the parameters are defined in takes_params. In the Str('cn') definition there is a normalizer: normalizer=lambda value: value.lower(), Remove or comment out this line and restart httpd. Good luck. rob From programadorlinux at gmail.com Wed Feb 11 01:39:07 2015 From: programadorlinux at gmail.com (Israel Miranda) Date: Tue, 10 Feb 2015 23:39:07 -0200 Subject: [Freeipa-users] Integrating Freeipa with Samba server through ldapsam or ipasam ? How to compile ipasam separetely on Centos 7 ? Message-ID: I have a freeipa installation of v4 on Fedora 21. I have a separate fileserver with freeipa packages installed from mkosek-freeipa-epel-7.repo on centos 7. I have: * created sambaSAMAccount,sambaGroupMapping UserObjects * created an entry for DNA plugin to populate them cn=SambaGroupSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config * added a CoS template for sambaGroupType * added a CoS definition for sambaGroupType * used ipa-adtrust-install to create and populate ipaNTHash * checked with the creation of these attributes with an ldap browser all ok * put the fileserver machine on the domain * added necessary permission, previleges and roles * installed kerberos keytab on the fileserver * was able to retrieve ipaNTHash attribute with the keytab from samba server and now the only thing missing is to integrate the fileserver with the ipaserver. I don?t mind in using ipasam, but to install in on my centos7 fileserver, which only has samba installed and nothing else, it also pulls the whole freeipa-server package, and this is overkill just to get ipasam.so. So I'd like some help in compiling it separately. I am using standard samba server distributed with centos 7. So I tried to use passdb backend = ldapsam:ldap//ipaserver but samba tries to bind using admin user, and doesn't use keytab, even though I put dedicated keytab file = FILE:/etc/samba/samba.keytab kerberos method = dedicated keytab in smb.conf. So please help me in getting these two things done: 1. use samba with freeipa through ldap( I know it is worse than ipasam, but would be nice to know how to integrate freeipa with samba with ldap on systems where ipasam might not be available ) 2. compile an ipasam.so module so we can work on creating an rpm package in the future, since it is necessary to install ipasam.so separately. Kudos for the development team for this amazing software. Thanks in advance Free software philosophy : Information is for free. People are not. Contributors are priceless. Filosofia de software livre: Informa??o ? de gra?a. Pessoas n?o s?o. Contribuidores n?o tem pre?o. Israel Vin?cius Miranda From dpal at redhat.com Wed Feb 11 06:47:55 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Feb 2015 01:47:55 -0500 Subject: [Freeipa-users] Integrating Freeipa with Samba server through ldapsam or ipasam ? How to compile ipasam separetely on Centos 7 ? In-Reply-To: References: Message-ID: <54DAFB1B.5030906@redhat.com> On 02/10/2015 08:39 PM, Israel Miranda wrote: > I have a freeipa installation of v4 on Fedora 21. > I have a separate fileserver with freeipa packages installed from > mkosek-freeipa-epel-7.repo on centos 7. > > I have: > * created sambaSAMAccount,sambaGroupMapping UserObjects > * created an entry for DNA plugin to populate them > cn=SambaGroupSid,cn=Distributed Numeric Assignment > Plugin,cn=plugins,cn=config > * added a CoS template for sambaGroupType > * added a CoS definition for sambaGroupType > * used ipa-adtrust-install to create and populate ipaNTHash > * checked with the creation of these attributes with an ldap browser all ok > * put the fileserver machine on the domain > * added necessary permission, previleges and roles > * installed kerberos keytab on the fileserver > * was able to retrieve ipaNTHash attribute with the keytab from samba server > > and now the only thing missing is to integrate the fileserver with the > ipaserver. > I don?t mind in using ipasam, but to install in on my centos7 > fileserver, which only has samba installed and nothing else, it also > pulls the whole freeipa-server package, and this is overkill just to > get ipasam.so. So I'd like some help in compiling it separately. > I am using standard samba server distributed with centos 7. > > So I tried to use passdb backend = ldapsam:ldap//ipaserver > but samba tries to bind using admin user, and doesn't use keytab, even > though I put > dedicated keytab file = FILE:/etc/samba/samba.keytab > kerberos method = dedicated keytab > in smb.conf. > > So please help me in getting these two things done: > > 1. use samba with freeipa through ldap( I know it is worse than > ipasam, but would be nice to know how to integrate freeipa with samba > with ldap on systems where ipasam might not be available ) > > 2. compile an ipasam.so module so we can work on creating an rpm > package in the future, since it is necessary to install ipasam.so > separately. > > Kudos for the development team for this amazing software. > > Thanks in advance > > > Free software philosophy : > > Information is for free. > People are not. > Contributors are priceless. > > > Filosofia de software livre: > > Informa??o ? de gra?a. > Pessoas n?o s?o. > Contribuidores n?o tem pre?o. > > > Israel Vin?cius Miranda > Have you considered this: http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA ? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From nicolas.zin at savoirfairelinux.com Wed Feb 11 08:06:47 2015 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Wed, 11 Feb 2015 03:06:47 -0500 (EST) Subject: [Freeipa-users] ad relation with winsync In-Reply-To: <1452195666.130872.1423638593778.JavaMail.root@savoirfairelinux.com> Message-ID: <313055385.142650.1423642007008.JavaMail.root@savoirfairelinux.com> Hi, I now try to establish a winsync relation with a Windows 2008R2. I installed IDM 3.3 on RHEL7. When I try to create the replication: ipa-replica-manage connect --winsync --binddb cn=Administrator,cn=Users,dc=company,dc=com --bindpwd --passsync whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com Directory Manager password: ******** Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate database for srv7idm2.ipa.company.com ipa: INFO: Failed to connect to AD srever dc.company.com ipa: INFO: The error was: {'info': 'TLS error -8157:Certificate extension not found','desc': 'Connect error'} Failed to setup winsync replication Do you have an idea, what's wrong? Also is it possible to point to port 636 instead? Notes: - On the windows side, ssl has been activated (with pain) and ldp.exe manage to connect via ssl on the 636 port correctly (so the certificate is in place). I don't know how to check it is working properly on port 389, i.e. START_TLS works - I checked that the 2 box have the same time (ntp) - I nearly manage to make it working once, but I got another error during replication Nicolas Zin nicolas.zin at savoirfairelinux.com Ligne directe: 514-276-5468 poste 135 Fax : 514-276-5465 7275 Saint Urbain Bureau 200 Montr?al, QC, H2R 2Y5 From abokovoy at redhat.com Wed Feb 11 08:32:43 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 11 Feb 2015 10:32:43 +0200 Subject: [Freeipa-users] Integrating Freeipa with Samba server through ldapsam or ipasam ? How to compile ipasam separetely on Centos 7 ? In-Reply-To: References: Message-ID: <20150211083243.GN9247@redhat.com> On Tue, 10 Feb 2015, Israel Miranda wrote: >I have a freeipa installation of v4 on Fedora 21. >I have a separate fileserver with freeipa packages installed from >mkosek-freeipa-epel-7.repo on centos 7. > >I have: >* created sambaSAMAccount,sambaGroupMapping UserObjects >* created an entry for DNA plugin to populate them >cn=SambaGroupSid,cn=Distributed Numeric Assignment >Plugin,cn=plugins,cn=config >* added a CoS template for sambaGroupType >* added a CoS definition for sambaGroupType >* used ipa-adtrust-install to create and populate ipaNTHash >* checked with the creation of these attributes with an ldap browser all ok >* put the fileserver machine on the domain >* added necessary permission, previleges and roles >* installed kerberos keytab on the fileserver >* was able to retrieve ipaNTHash attribute with the keytab from samba server > >and now the only thing missing is to integrate the fileserver with the >ipaserver. >I don?t mind in using ipasam, but to install in on my centos7 >fileserver, which only has samba installed and nothing else, it also >pulls the whole freeipa-server package, and this is overkill just to >get ipasam.so. So I'd like some help in compiling it separately. >I am using standard samba server distributed with centos 7. > >So I tried to use passdb backend = ldapsam:ldap//ipaserver >but samba tries to bind using admin user, and doesn't use keytab, even >though I put > dedicated keytab file = FILE:/etc/samba/samba.keytab > kerberos method = dedicated keytab >in smb.conf. ldapsam currently does not yet support keytab use. With CentOS7/mkosek COPR repo you don't need to use any special passdb module anymore, just follow http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA > >So please help me in getting these two things done: > >1. use samba with freeipa through ldap( I know it is worse than >ipasam, but would be nice to know how to integrate freeipa with samba >with ldap on systems where ipasam might not be available ) Don't do that, use sssd-libwbclient integration. It requires pretty fresh sssd version (1.12.2+) but systems you mentioned (F21 and CentOS7 with mkosek COPR repo) have it. >2. compile an ipasam.so module so we can work on creating an rpm >package in the future, since it is necessary to install ipasam.so >separately. No need to that when using sssd-libwbclient integration. -- / Alexander Bokovoy From yoshi314 at gmail.com Wed Feb 11 09:00:47 2015 From: yoshi314 at gmail.com (marcin kowalski) Date: Wed, 11 Feb 2015 10:00:47 +0100 Subject: [Freeipa-users] slight problem when integrating certmonger with dogtag on fedora 21 In-Reply-To: <54DA4278.6000206@redhat.com> References: <54DA4278.6000206@redhat.com> Message-ID: Edit: i acceditanlly forgot to send copy to the list, so resubmitting. I tried this command : getcert request -c dogtag-ipa -f /etc/pki/testcert -k /etc/pki/testkey -N "cn=mywebserver" i've setup the 'dogtag-ipa' ca in certmonger like so : id=dogtag-ipa ca_aka=Dogtag (IPA,renew,agent) (certmonger 0.76.8) ca_is_default=0 ca_type=EXTERNAL ca_external_helper=/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit -E https://fedora.box.net:8443/ca/ee/ca -A https://fedora.box.net:8443/ca/agent/ca/ -n "CN=BOX.NET admin" -d /var/lib/pki/pki-tomcat/alias/ -i /etc/ipa/ca.crt -v Since i haven't fully figured out how to setup authentication for certmonger yet, i've temporarily reused one from the dogtag's pki instance. Hopefully it's not a fatal mistake on my end. >From the certmonger logs i get : lut 11 09:52:19 fedora.box.net dogtag-ipa-renew-agent-submit[2887]: GET https://fedora.box.net:8443/ca/ee/ca/profileSubmit?profileId=caServerCert&cert_request_type=pkcs10&cert_request=-----BEGIN+NEW+CERTIFICATE+REQUEST-----%0AMIICyTCCAbECAQAwFjEUMBIGA1UEAxMLbXl3ZWJzZXJ2ZXIwggEiMA0GCSqGSIb3%0ADQEBAQUAA4IBDwAwggEKAoIBAQDLZKK8dUqmiY2YAS2LrNE9DsB7QVhuATEcXkrc%0AB121jafN9BMyNSGQjWlpb15P4xqaXHrplQl60d4sSZA1d4GAxoywDUvoUA7R%2FrJ7%0AVcFyA7R5mRzK%2BfNUg%2FdLqTrnWM6GC1ecYwUwAmI%2FOFa5OomQczdGoV1ippguR2Un%0ArCCdXImZtni845FI1Wx745GP4mH2od7otSqGeLiQR9I6RLdrcs%2FC%2FWhWqPgUmyxp%0AEb%2BFS%2FAGPXG1nE2eT64z2OLQLJWfOT1uYRClsrQ9Bw96Cv20KPupEr4BPwfX%2BQzs%0AR7p9E%2BW1TuQhqX2NrWl4V%2F0tqc0omXGQZx62jCZM0m%2B2eoYJAgMBAAGgbjArBgkq%0AhkiG9w0BCRQxHh4cADIAMAAxADUAMAAyADEAMQAwADgANQAyADEAODA%2FBgkqhkiG%0A9w0BCQ4xMjAwMAwGA1UdEwEB%2FwQCMAAwIAYDVR0OAQEABBYEFEEoeB59tZYgOLSg%0AHV3fzBtlQCiaMA0GCSqGSIb3DQEBCwUAA4IBAQCpc3v8wp6csgKN3H8TfXe5Ay5h%0ATTqKyN2iLQKurTlTbwv%2FhZsE3ketuSfEOCJpE7Z58jlLB7VlMl6Uyl2MrOmC7Ro5%0Ai13LpVvVd%2FLsCedhM%2BTlYPtsk68DVcf1XKZARH6MIRmiDWSr0gajeP6bZK8znQK%2B%0A6O7LaHKv1HaVcjxTZ%2Fdep3OF7aYtsz5tnyoaP1D2CI2WRRGnwjX4bBmr%2FQIZe7ba%0AOQt1yznFPjonEwVaOg3wkx0uaxdkyMz3MZC8nJxYCvBnNgV72tbA6As93laQaTQ2%0A24HhzdEWnJ019W72qJdTDpPg4DtloU0W%2BJYiIIpCfQIn1%2FjJLOnJcWiGPDDd%0A-----END+NEW+CERTIFICATE+REQUEST-----%0A&xml=true lut 11 09:52:19 fedora.box.net dogtag-ipa-renew-agent-submit[2887]: 2Request Deferred - {0} 49 And the request #49 is placed in Dogtag's CA Agent services, and can be acknowledged/rejected correctly. It's just that certmonger is stuck and doesn't notice the successful delivery. Machine is in isolated network, so there is probably no issue wrt using box.net as test domain. 2015-02-10 18:40 GMT+01:00 Dmitri Pal : > On 02/10/2015 12:35 PM, marcin kowalski wrote: > > Hi all, i'm getting dogtag figured out slowly, and i noticed one odd > thing. > > I've setup certmonger to request an arbitrary certificate through dogtag, > and while the request seems to go into the dogtag system, certmonger acts > as if communication with the CA failed. The certificate is considered in > need of user attention because the process got stuck. > > Request ID ?20150210125814?: > status: NEED_GUIDANCE > stuck: yes > key pair storage: type=FILE,location=?/etc/pki/testkey? > certificate: type=FILE,location=?/etc/pki/testcert? > CA: dogtag-ipa > issuer: > subject: > expires: unknown > pre-save command: > post-save command: > track: yes > auto-renew: yes > > > [root at fedora pki]# systemctl status -l certmonger > (?.) > lut 10 13:57:04 fedora.box.net certmonger[7845]: Request for certificate > to be stored in file ?/etc/pki/testcert? rejected by CA. > > The request is present in dogtag and is valid, can be accepted/rejected, > etc. Even though certmonger never notices that. I wonder if there is some > obvious mistake in my setup, or perhaps there is known bug in interaction > of both components on F21 (i'm using only standard repositories). > > When i post the query from certmonger's agent defined in ca definition > through curl, i get no errors. > > What would be the best way to debug this issue? > > > Can you post your certmonger get-cert command? > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yoshi314 at gmail.com Wed Feb 11 09:04:42 2015 From: yoshi314 at gmail.com (marcin kowalski) Date: Wed, 11 Feb 2015 10:04:42 +0100 Subject: [Freeipa-users] slight problem when integrating certmonger with dogtag on fedora 21 In-Reply-To: References: <54DA4278.6000206@redhat.com> Message-ID: I forgot to add - usually removing the "-v" bit in ca external helper definition produces the aforementioned 'rejected by CA' message, instead of verbose output. 2015-02-11 10:00 GMT+01:00 marcin kowalski : > Edit: i acceditanlly forgot to send copy to the list, so resubmitting. > > > I tried this command : > > getcert request -c dogtag-ipa -f /etc/pki/testcert -k /etc/pki/testkey -N > "cn=mywebserver" > > i've setup the 'dogtag-ipa' ca in certmonger like so : > > id=dogtag-ipa > ca_aka=Dogtag (IPA,renew,agent) (certmonger 0.76.8) > ca_is_default=0 > ca_type=EXTERNAL > ca_external_helper=/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit > -E https://fedora.box.net:8443/ca/ee/ca -A > https://fedora.box.net:8443/ca/agent/ca/ -n "CN=BOX.NET admin" -d > /var/lib/pki/pki-tomcat/alias/ -i /etc/ipa/ca.crt -v > > > Since i haven't fully figured out how to setup authentication for > certmonger yet, i've temporarily reused one from the dogtag's pki instance. > Hopefully it's not a fatal mistake on my end. > > From the certmonger logs i get : > > lut 11 09:52:19 fedora.box.net dogtag-ipa-renew-agent-submit[2887]: GET > https://fedora.box.net:8443/ca/ee/ca/profileSubmit?profileId=caServerCert&cert_request_type=pkcs10&cert_request=-----BEGIN+NEW+CERTIFICATE+REQUEST-----%0AMIICyTCCAbECAQAwFjEUMBIGA1UEAxMLbXl3ZWJzZXJ2ZXIwggEiMA0GCSqGSIb3%0ADQEBAQUAA4IBDwAwggEKAoIBAQDLZKK8dUqmiY2YAS2LrNE9DsB7QVhuATEcXkrc%0AB121jafN9BMyNSGQjWlpb15P4xqaXHrplQl60d4sSZA1d4GAxoywDUvoUA7R%2FrJ7%0AVcFyA7R5mRzK%2BfNUg%2FdLqTrnWM6GC1ecYwUwAmI%2FOFa5OomQczdGoV1ippguR2Un%0ArCCdXImZtni845FI1Wx745GP4mH2od7otSqGeLiQR9I6RLdrcs%2FC%2FWhWqPgUmyxp%0AEb%2BFS%2FAGPXG1nE2eT64z2OLQLJWfOT1uYRClsrQ9Bw96Cv20KPupEr4BPwfX%2BQzs%0AR7p9E%2BW1TuQhqX2NrWl4V%2F0tqc0omXGQZx62jCZM0m%2B2eoYJAgMBAAGgbjArBgkq%0AhkiG9w0BCRQxHh4cADIAMAAxADUAMAAyADEAMQAwADgANQAyADEAODA%2FBgkqhkiG%0A9w0BCQ4xMjAwMAwGA1UdEwEB%2FwQCMAAwIAYDVR0OAQEABBYEFEEoeB59tZYgOLSg%0AHV3fzBtlQCiaMA0GCSqGSIb3DQEBCwUAA4IBAQCpc3v8wp6csgKN3H8TfXe5Ay5h%0ATTqKyN2iLQKurTlTbwv%2FhZsE3ketuSfEOCJpE7Z58jlLB7VlMl6Uyl2MrOmC7Ro5%0Ai13LpVvVd%2FLsCedhM%2BTlYPtsk68DVcf1XKZARH6MIRmiDWSr0gajeP6bZK8znQK%2B%0A6O7LaHKv1HaVcjxTZ%2Fdep3OF7aYtsz5tnyoaP1D2CI2WRRGnwjX4bBmr%2FQIZe7ba%0AOQt1yznFPjonEwVaOg3wkx0uaxdkyMz3MZC8nJxYCvBnNgV72tbA6As93laQaTQ2%0A24HhzdEWnJ019W72qJdTDpPg4DtloU0W%2BJYiIIpCfQIn1%2FjJLOnJcWiGPDDd%0A-----END+NEW+CERTIFICATE+REQUEST-----%0A&xml=true > lut 11 09:52:19 fedora.box.net dogtag-ipa-renew-agent-submit[2887]: version="1.0" encoding="UTF-8" > standalone="no"?>2Request Deferred - > {0} 49 > > > And the request #49 is placed in Dogtag's CA Agent services, and can be > acknowledged/rejected correctly. It's just that certmonger is stuck and > doesn't notice the successful delivery. > > Machine is in isolated network, so there is probably no issue wrt using > box.net as test domain. > > 2015-02-10 18:40 GMT+01:00 Dmitri Pal : > >> On 02/10/2015 12:35 PM, marcin kowalski wrote: >> >> Hi all, i'm getting dogtag figured out slowly, and i noticed one odd >> thing. >> >> I've setup certmonger to request an arbitrary certificate through dogtag, >> and while the request seems to go into the dogtag system, certmonger acts >> as if communication with the CA failed. The certificate is considered in >> need of user attention because the process got stuck. >> >> Request ID ?20150210125814?: >> status: NEED_GUIDANCE >> stuck: yes >> key pair storage: type=FILE,location=?/etc/pki/testkey? >> certificate: type=FILE,location=?/etc/pki/testcert? >> CA: dogtag-ipa >> issuer: >> subject: >> expires: unknown >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes >> >> >> [root at fedora pki]# systemctl status -l certmonger >> (?.) >> lut 10 13:57:04 fedora.box.net certmonger[7845]: Request for certificate >> to be stored in file ?/etc/pki/testcert? rejected by CA. >> >> The request is present in dogtag and is valid, can be accepted/rejected, >> etc. Even though certmonger never notices that. I wonder if there is some >> obvious mistake in my setup, or perhaps there is known bug in interaction >> of both components on F21 (i'm using only standard repositories). >> >> When i post the query from certmonger's agent defined in ca definition >> through curl, i get no errors. >> >> What would be the best way to debug this issue? >> >> >> Can you post your certmonger get-cert command? >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.zin at savoirfairelinux.com Wed Feb 11 11:18:16 2015 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Wed, 11 Feb 2015 06:18:16 -0500 (EST) Subject: [Freeipa-users] ad relation with winsync In-Reply-To: <313055385.142650.1423642007008.JavaMail.root@savoirfairelinux.com> References: <313055385.142650.1423642007008.JavaMail.root@savoirfairelinux.com> Message-ID: <599734995.147060.1423653496313.JavaMail.root@savoirfairelinux.com> I reply to myself. This was certainly a Windows configurarion issue. I went further: ipa-replica-manage connect --winsync --binddb cn=Administrator,cn=Users,dc=company,dc=com --bindpwd --passsync whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com -v Directory Manager password: ******** Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate database for srv7idm2.ipa.company.com ipa: INFO: AD Suffix is: DC=company,DC=com The user for Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=company,dc=com ipa: INFO: Added new sync agreement, waiting for it to become ready. . . ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP error: Connect error: start: 0 end: 0 ipa: INFO: Agreement is ready, starting replication . . . Starting replication, please wait until this has completed. [srv7idm2.ipa.company.com] reports: Update failed! Status: [-11 - LDAP error: Connect error] So apparently I manage to connect to AD but something went wrong after? How can I debug it? Regards, Nicolas Zin ----- Mail original ----- De: "Nicolas Zin" ?: freeipa-users at redhat.com Envoy?: Mercredi 11 F?vrier 2015 12:06:47 Objet: [Freeipa-users] ad relation with winsync Hi, I now try to establish a winsync relation with a Windows 2008R2. I installed IDM 3.3 on RHEL7. When I try to create the replication: ipa-replica-manage connect --winsync --binddb cn=Administrator,cn=Users,dc=company,dc=com --bindpwd --passsync whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com Directory Manager password: ******** Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate database for srv7idm2.ipa.company.com ipa: INFO: Failed to connect to AD srever dc.company.com ipa: INFO: The error was: {'info': 'TLS error -8157:Certificate extension not found','desc': 'Connect error'} Failed to setup winsync replication Do you have an idea, what's wrong? Also is it possible to point to port 636 instead? Notes: - On the windows side, ssl has been activated (with pain) and ldp.exe manage to connect via ssl on the 636 port correctly (so the certificate is in place). I don't know how to check it is working properly on port 389, i.e. START_TLS works - I checked that the 2 box have the same time (ntp) - I nearly manage to make it working once, but I got another error during replication Nicolas Zin nicolas.zin at savoirfairelinux.com Ligne directe: 514-276-5468 poste 135 Fax : 514-276-5465 7275 Saint Urbain Bureau 200 Montr?al, QC, H2R 2Y5 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project From rmeggins at redhat.com Wed Feb 11 14:57:43 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 11 Feb 2015 07:57:43 -0700 Subject: [Freeipa-users] ad relation with winsync In-Reply-To: <599734995.147060.1423653496313.JavaMail.root@savoirfairelinux.com> References: <313055385.142650.1423642007008.JavaMail.root@savoirfairelinux.com> <599734995.147060.1423653496313.JavaMail.root@savoirfairelinux.com> Message-ID: <54DB6DE7.6070007@redhat.com> On 02/11/2015 04:18 AM, Nicolas Zin wrote: > I reply to myself. > This was certainly a Windows configurarion issue. I went further: > ipa-replica-manage connect --winsync --binddb cn=Administrator,cn=Users,dc=company,dc=com --bindpwd --passsync whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com -v > Directory Manager password: ******** > > Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate database for srv7idm2.ipa.company.com > ipa: INFO: AD Suffix is: DC=company,DC=com > The user for Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=company,dc=com > ipa: INFO: Added new sync agreement, waiting for it to become ready. . . > ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP error: Connect error: start: 0 end: 0 > ipa: INFO: Agreement is ready, starting replication . . . > Starting replication, please wait until this has completed. > > [srv7idm2.ipa.company.com] reports: Update failed! Status: [-11 - LDAP error: Connect error] > > > > So apparently I manage to connect to AD but something went wrong after? > How can I debug it? You can test it like this: # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN ldapsearch -xLLLZZ -H ldap://fqdn.of.ad.host -s base -b "DC=company,DC=com" -D "cn=Administrator,cn=Users,dc=company,dc=com" -w "password" > > > > Regards, > > > > Nicolas Zin > > > > ----- Mail original ----- > De: "Nicolas Zin" > ?: freeipa-users at redhat.com > Envoy?: Mercredi 11 F?vrier 2015 12:06:47 > Objet: [Freeipa-users] ad relation with winsync > > Hi, > > I now try to establish a winsync relation with a Windows 2008R2. > I installed IDM 3.3 on RHEL7. > > When I try to create the replication: > ipa-replica-manage connect --winsync --binddb cn=Administrator,cn=Users,dc=company,dc=com --bindpwd --passsync whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com > Directory Manager password: ******** > > Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate database for srv7idm2.ipa.company.com > ipa: INFO: Failed to connect to AD srever dc.company.com > ipa: INFO: The error was: {'info': 'TLS error -8157:Certificate extension not found','desc': 'Connect error'} > Failed to setup winsync replication > > > Do you have an idea, what's wrong? > Also is it possible to point to port 636 instead? > > > Notes: > - On the windows side, ssl has been activated (with pain) and ldp.exe manage to connect via ssl on the 636 port correctly (so the certificate is in place). I don't know how to check it is working properly on port 389, i.e. START_TLS works > - I checked that the 2 box have the same time (ntp) > - I nearly manage to make it working once, but I got another error during replication > > > > Nicolas Zin > nicolas.zin at savoirfairelinux.com > Ligne directe: 514-276-5468 poste 135 > > Fax : 514-276-5465 > 7275 Saint Urbain > Bureau 200 > Montr?al, QC, H2R 2Y5 > > > From rcritten at redhat.com Wed Feb 11 18:14:57 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Feb 2015 13:14:57 -0500 Subject: [Freeipa-users] slight problem when integrating certmonger with dogtag on fedora 21 In-Reply-To: References: <54DA4278.6000206@redhat.com> Message-ID: <54DB9C21.9050800@redhat.com> marcin kowalski wrote: > |Edit: i acceditanlly forgot to send copy to the list, so resubmitting. > > > I tried this command : > > getcert request -c dogtag-ipa -f /etc/pki/testcert -k /etc/pki/testkey > -N "cn=mywebserver" > > i've setup the 'dogtag-ipa' ca in certmonger like so : > > id=dogtag-ipa > ca_aka=Dogtag (IPA,renew,agent) (certmonger 0.76.8) > ca_is_default=0 > ca_type=EXTERNAL > ca_external_helper=/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit > -E https://fedora.box.net:8443/ca/ee/ca -A > https://fedora.box.net:8443/ca/agent/ca/ -n "CN=BOX.NET > admin" -d /var/lib/pki/pki-tomcat/alias/ -i /etc/ipa/ca.crt -v > > > Since i haven't fully figured out how to setup authentication for > certmonger yet, i've temporarily reused one from the dogtag's pki > instance. Hopefully it's not a fatal mistake on my end. What is your reasoning for setting up your own CA configuration? Why not just use either ipa-getcert or getcert -c IPA? rob > > From the certmonger logs i get : > > lut 11 09:52:19 fedora.box.net > dogtag-ipa-renew-agent-submit[2887]: GET > https://fedora.box.net:8443/ca/ee/ca/profileSubmit?profileId=caServerCert&cert_request_type=pkcs10&cert_request=-----BEGIN+NEW+CERTIFICATE+REQUEST-----%0AMIICyTCCAbECAQAwFjEUMBIGA1UEAxMLbXl3ZWJzZXJ2ZXIwggEiMA0GCSqGSIb3%0ADQEBAQUAA4IBDwAwggEKAoIBAQDLZKK8dUqmiY2YAS2LrNE9DsB7QVhuATEcXkrc%0AB121jafN9BMyNSGQjWlpb15P4xqaXHrplQl60d4sSZA1d4GAxoywDUvoUA7R%2FrJ7%0AVcFyA7R5mRzK%2BfNUg%2FdLqTrnWM6GC1ecYwUwAmI%2FOFa5OomQczdGoV1ippguR2Un%0ArCCdXImZtni845FI1Wx745GP4mH2od7otSqGeLiQR9I6RLdrcs%2FC%2FWhWqPgUmyxp%0AEb%2BFS%2FAGPXG1nE2eT64z2OLQLJWfOT1uYRClsrQ9Bw96Cv20KPupEr4BPwfX%2BQzs%0AR7p9E%2BW1TuQhqX2NrWl4V%2F0tqc0omXGQZx62jCZM0m%2B2eoYJAgMBAAGgbjArBgkq%0AhkiG9w0BCRQxHh4cADIAMAAxADUAMAAyADEAMQAwADgANQAyADEAODA%2FBgkqhkiG%0A9w0BCQ4xMjAwMAwGA1UdEwEB%2FwQCMAAwIAYDVR0OAQEABBYEFEEoeB59tZYgOLSg%0AHV3fzBtlQCiaMA0GCSqGSIb3DQEBCwUAA4IBAQCpc3v8wp6csgKN3H8TfXe5Ay5h%0ATTqKyN2iLQKurTlTbwv%2FhZsE3ketuSfEOCJpE7Z58jlLB7VlMl6Uyl2MrOmC7Ro5%0Ai13LpVvVd%2FLsCedhM%2BTlYPtsk68DVcf1XKZARH6MIRmiDWSr0gajeP6bZK8znQ! K%2B%0A6O7 LaHKv1HaVcjxTZ%2Fdep3OF7aYtsz5tnyoaP1D2CI2WRRGnwjX4bBmr%2FQIZe7ba%0AOQt1yznFPjonEwVaOg3wkx0uaxdkyMz3MZC8nJxYCvBnNgV72tbA6As93laQaTQ2%0A24HhzdEWnJ019W72qJdTDpPg4DtloU0W%2BJYiIIpCfQIn1%2FjJLOnJcWiGPDDd%0A-----END+NEW+CERTIFICATE+REQUEST-----%0A&xml=true > lut 11 09:52:19 fedora.box.net > dogtag-ipa-renew-agent-submit[2887]: encoding="UTF-8" > standalone="no"?>2Request Deferred > - {0} 49 > > > And the request #49 is placed in Dogtag's CA Agent services, and can be > acknowledged/rejected correctly. It's just that certmonger is stuck and > doesn't notice the successful delivery. > > Machine is in isolated network, so there is probably no issue wrt using > box.net as test domain.| > > 2015-02-10 18:40 GMT+01:00 Dmitri Pal >: > > On 02/10/2015 12:35 PM, marcin kowalski wrote: >> Hi all, i'm getting dogtag figured out slowly, and i noticed one >> odd thing. >> >> I've setup certmonger to request an arbitrary certificate through >> dogtag, and while the request seems to go into the dogtag system, >> certmonger acts as if communication with the CA failed. The >> certificate is considered in need of user attention because the >> process got stuck. >> >> Request ID ?20150210125814?: >> status: NEED_GUIDANCE >> stuck: yes >> key pair storage: type=FILE,location=?/etc/pki/testkey? >> certificate: type=FILE,location=?/etc/pki/testcert? >> CA: dogtag-ipa >> issuer: >> subject: >> expires: unknown >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes >> >> >> [root at fedora pki]# systemctl status -l certmonger >> ( .) >> lut 10 13:57:04 fedora.box.net >> certmonger[7845]: Request for certificate to be stored in file >> ?/etc/pki/testcert? rejected by CA. >> >> >> The request is present in dogtag and is valid, can be >> accepted/rejected, etc. Even though certmonger never notices that. >> I wonder if there is some obvious mistake in my setup, or perhaps >> there is known bug in interaction of both components on F21 (i'm >> using only standard repositories). >> >> When i post the query from certmonger's agent defined in ca >> definition through curl, i get no errors. >> >> What would be the best way to debug this issue? >> >> > Can you post your certmonger get-cert command? > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > > > From nalin at redhat.com Wed Feb 11 18:15:04 2015 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 11 Feb 2015 13:15:04 -0500 Subject: [Freeipa-users] slight problem when integrating certmonger with dogtag on fedora 21 In-Reply-To: References: <54DA4278.6000206@redhat.com> Message-ID: <20150211181504.GB12342@redhat.com> On Wed, Feb 11, 2015 at 10:04:42AM +0100, marcin kowalski wrote: > I forgot to add - usually removing the "-v" bit in ca external helper > definition produces the aforementioned 'rejected by CA' message, instead of > verbose output. Ah. Yes, the verbose output goes to stdout, where it confuses the main daemon (it's expecting a very specific format from stdout), rather than stderr, which probably would have been a better idea. > > Since i haven't fully figured out how to setup authentication for > > certmonger yet, i've temporarily reused one from the dogtag's pki instance. > > Hopefully it's not a fatal mistake on my end. The agent authentication is set up using a combination of the -d, -n, and optionally the -P or -p flags. If you leave off all options, dogtag-ipa-renew-agent-submit more or less assumes: -d /etc/httpd/alias -n ipaCert -p /etc/httpd/alias/pwdfile.txt I tried this on my own box, and Dogtag threw a curve ball by putting a blank line in before the -----END CERTIFICATE----- line at the end of the issued certificate. It's something we can work around, but it's not something the current version knows that it needs to do. HTH, Nalin From programadorlinux at gmail.com Wed Feb 11 23:13:28 2015 From: programadorlinux at gmail.com (Israel Miranda) Date: Wed, 11 Feb 2015 21:13:28 -0200 Subject: [Freeipa-users] Integrating Freeipa with Samba server through ldapsam or ipasam ? How to compile ipasam separetely on Centos 7 ? In-Reply-To: <20150211083243.GN9247@redhat.com> References: <20150211083243.GN9247@redhat.com> Message-ID: I did follow http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA but first I was always getting NT_STATUS_UNSUCCESSFUL First I thought it was related to a bad parameter in my samba configuration, because http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA says it is about ipa v4 and I found this ticket https://fedorahosted.org/freeipa/ticket/3999 I thought the documentation was incomplete. I debugged kerberos log file and I realized I was using just username instead of username at REALM.COM in windows 8 machine. It showed REALM as a groupname and I thought samba would do the translation but even on windows share logon you have to use username at REALM.COM otherwise it doesn?t work. Also what about all those ldap objects I created earlier ? Are they worth or need for a kerberized CIFS server ? Because they are not mentioned in http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA It is working flawlessly now. Thanks a lot for the tip, now my smb.conf is just like in the example of the howto and it is working through sssd-libwbclient accessing the keytab. I have detailed the steps and commands to create the ldap objects, there is a typo many places on the internet because it was reproduced from http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/cifs.html on the creation of dn: cn=SambaCoS,cn=groups,cn=accounts,dc=example,dc=com objectclass: top objectclass: cosSuperDefinition objectclass: cosPointerDefinition cosTemplateDn: cn=SambaCoS,cn=ipaConfig,dc=etc,dc=example,dc=com cosAttribute: sambaGrouptType there is a typo on the cosAttribute: a double tT on sambaGrouptType and I wasn't being able to create the object because the template was not found. I was found this error on the log: Skipping CoS Definition cn=Password Policy,cn=accounts,dc=example,dc=com--no CoS Templates found, which should be added before the CoS Definition. I also think should be documented somewhere that ipa-adtrust-install creates/populates the ipaNTHash, I couldn't find it anywhere, someone told me this on freenode. And one more doubt. ipa config-mod --userobjectclasses=aaa,bbb,ccc or ipa config-mod --groupobjectclasses=aaa,bbb,ccc doesn't work on iPA 4. Is there a way of doing this on the command line on ipa 4 ? Thanks a lot, ipa 4 is excellent. 2015-02-11 6:32 GMT-02:00, Alexander Bokovoy : > On Tue, 10 Feb 2015, Israel Miranda wrote: >>I have a freeipa installation of v4 on Fedora 21. >>I have a separate fileserver with freeipa packages installed from >>mkosek-freeipa-epel-7.repo on centos 7. >> >>I have: >>* created sambaSAMAccount,sambaGroupMapping UserObjects >>* created an entry for DNA plugin to populate them >>cn=SambaGroupSid,cn=Distributed Numeric Assignment >>Plugin,cn=plugins,cn=config >>* added a CoS template for sambaGroupType >>* added a CoS definition for sambaGroupType >>* used ipa-adtrust-install to create and populate ipaNTHash >>* checked with the creation of these attributes with an ldap browser all >> ok >>* put the fileserver machine on the domain >>* added necessary permission, previleges and roles >>* installed kerberos keytab on the fileserver >>* was able to retrieve ipaNTHash attribute with the keytab from samba >> server >> >>and now the only thing missing is to integrate the fileserver with the >>ipaserver. >>I don?t mind in using ipasam, but to install in on my centos7 >>fileserver, which only has samba installed and nothing else, it also >>pulls the whole freeipa-server package, and this is overkill just to >>get ipasam.so. So I'd like some help in compiling it separately. >>I am using standard samba server distributed with centos 7. >> >>So I tried to use passdb backend = ldapsam:ldap//ipaserver >>but samba tries to bind using admin user, and doesn't use keytab, even >>though I put >> dedicated keytab file = FILE:/etc/samba/samba.keytab >> kerberos method = dedicated keytab >>in smb.conf. > ldapsam currently does not yet support keytab use. With CentOS7/mkosek > COPR repo you don't need to use any special passdb module anymore, just > follow > http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA > > >> >>So please help me in getting these two things done: >> >>1. use samba with freeipa through ldap( I know it is worse than >>ipasam, but would be nice to know how to integrate freeipa with samba >>with ldap on systems where ipasam might not be available ) > Don't do that, use sssd-libwbclient integration. It requires pretty > fresh sssd version (1.12.2+) but systems you mentioned (F21 and CentOS7 > with mkosek COPR repo) have it. > >>2. compile an ipasam.so module so we can work on creating an rpm >>package in the future, since it is necessary to install ipasam.so >>separately. > No need to that when using sssd-libwbclient integration. > > -- > / Alexander Bokovoy > -- Free software philosophy : Information is for free. People are not. Contributors are priceless. Filosofia de software livre: Informa??o ? de gra?a. Pessoas n?o s?o. Contribuidores n?o tem pre?o. Israel Vin?cius Miranda From nicolas.zin at savoirfairelinux.com Thu Feb 12 05:37:26 2015 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Thu, 12 Feb 2015 00:37:26 -0500 (EST) Subject: [Freeipa-users] ad relation with winsync In-Reply-To: <54DB6DE7.6070007@redhat.com> References: <313055385.142650.1423642007008.JavaMail.root@savoirfairelinux.com> <599734995.147060.1423653496313.JavaMail.root@savoirfairelinux.com> <54DB6DE7.6070007@redhat.com> Message-ID: <487613314.673165.1423719446965.JavaMail.root@savoirfairelinux.com> That was that: in the logs (/var/log/dirsrv/slapd-HQ-EMIRATES-COM/errors) I got: slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) And when i did "LDAPTLS_CACERTDIR=/etc/dirsrv/... ldapsearch ...", it began to be interesting: ldap_start_tls: Connect error (-11) additionnal info: TLS: hostname does not match CN in peer certificate So I correct my problem: put the correct hostname in the ipa-replica-manage ( and not the ip). And it connects! Next step: having the replication working. The customer dont want to give to my sync user "Replicating directory changes", "Account Operator" and "Enterprise Read-Only Domain Controller" attributs and just want a "oneway replication". For the one way replication, I followed the documentation But I don't see any imported users. Do you have an idea? Are some of the Windows attributs necessary even for a one way (windows to linux) synchronisation? Regards, Nicolas ----- Mail original ----- De: "Rich Megginson" ?: freeipa-users at redhat.com Envoy?: Mercredi 11 F?vrier 2015 18:57:43 Objet: Re: [Freeipa-users] ad relation with winsync On 02/11/2015 04:18 AM, Nicolas Zin wrote: > I reply to myself. > This was certainly a Windows configurarion issue. I went further: > ipa-replica-manage connect --winsync --binddb cn=Administrator,cn=Users,dc=company,dc=com --bindpwd --passsync whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com -v > Directory Manager password: ******** > > Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate database for srv7idm2.ipa.company.com > ipa: INFO: AD Suffix is: DC=company,DC=com > The user for Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=company,dc=com > ipa: INFO: Added new sync agreement, waiting for it to become ready. . . > ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP error: Connect error: start: 0 end: 0 > ipa: INFO: Agreement is ready, starting replication . . . > Starting replication, please wait until this has completed. > > [srv7idm2.ipa.company.com] reports: Update failed! Status: [-11 - LDAP error: Connect error] > > > > So apparently I manage to connect to AD but something went wrong after? > How can I debug it? You can test it like this: # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN ldapsearch -xLLLZZ -H ldap://fqdn.of.ad.host -s base -b "DC=company,DC=com" -D "cn=Administrator,cn=Users,dc=company,dc=com" -w "password" > > > > Regards, > > > > Nicolas Zin > > > > ----- Mail original ----- > De: "Nicolas Zin" > ?: freeipa-users at redhat.com > Envoy?: Mercredi 11 F?vrier 2015 12:06:47 > Objet: [Freeipa-users] ad relation with winsync > > Hi, > > I now try to establish a winsync relation with a Windows 2008R2. > I installed IDM 3.3 on RHEL7. > > When I try to create the replication: > ipa-replica-manage connect --winsync --binddb cn=Administrator,cn=Users,dc=company,dc=com --bindpwd --passsync whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com > Directory Manager password: ******** > > Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate database for srv7idm2.ipa.company.com > ipa: INFO: Failed to connect to AD srever dc.company.com > ipa: INFO: The error was: {'info': 'TLS error -8157:Certificate extension not found','desc': 'Connect error'} > Failed to setup winsync replication > > > Do you have an idea, what's wrong? > Also is it possible to point to port 636 instead? > > > Notes: > - On the windows side, ssl has been activated (with pain) and ldp.exe manage to connect via ssl on the 636 port correctly (so the certificate is in place). I don't know how to check it is working properly on port 389, i.e. START_TLS works > - I checked that the 2 box have the same time (ntp) > - I nearly manage to make it working once, but I got another error during replication > > > > Nicolas Zin > nicolas.zin at savoirfairelinux.com > Ligne directe: 514-276-5468 poste 135 > > Fax : 514-276-5465 > 7275 Saint Urbain > Bureau 200 > Montr?al, QC, H2R 2Y5 > > > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project From mlasevich at gmail.com Thu Feb 12 06:25:48 2015 From: mlasevich at gmail.com (Michael Lasevich) Date: Wed, 11 Feb 2015 22:25:48 -0800 Subject: [Freeipa-users] Where and how are passwords stored? Message-ID: Ok, after a few awkward questions from an auditor, I am starting to face the uncomfortable truth that my understanding about how FreeIPA works is a lot fuzzier than I would like. Specifically, the question I could not answer - where are the passwords stored and how are they encrypted? My understanding is that all authentication is handled by Kerberos server, which stores its data in LDAP - but where and how is a bit of a mystery to me. Any way to dump out the password hashes? Thanks, -M -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Feb 12 06:46:47 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 12 Feb 2015 08:46:47 +0200 Subject: [Freeipa-users] Integrating Freeipa with Samba server through ldapsam or ipasam ? How to compile ipasam separetely on Centos 7 ? In-Reply-To: References: <20150211083243.GN9247@redhat.com> Message-ID: <20150212064647.GB31649@redhat.com> On Wed, 11 Feb 2015, Israel Miranda wrote: >I did follow http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA >but first I was always getting NT_STATUS_UNSUCCESSFUL >First I thought it was related to a bad parameter in my samba >configuration, because >http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA >says it is about ipa v4 and I found this ticket >https://fedorahosted.org/freeipa/ticket/3999 I thought the >documentation was incomplete. Documentation regarding Samba integration is incomplete. We are working on improving it but nothing is ready for review yet. >I debugged kerberos log file and I realized I was using just username >instead of username at REALM.COM in windows 8 machine. It showed REALM as >a groupname and I thought samba would do the translation but even on >windows share logon you have to use username at REALM.COM otherwise it >doesn?t work. Yes. When you are using cross-forest trust to AD this will happen automatically. If you are not using cross-forest trust to AD, this use case is not yet officially supported so I glad that it works for you. >Also what about all those ldap objects I created earlier ? >Are they worth or need for a kerberized CIFS server ? >Because they are not mentioned in >http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA You don't need to create any additional LDAP objects. What you need is basically following: 1. Run ipa-adtrust-install on all masters that will be serving AD users. Right now this means effectively all masters but we are working on separating the heavy parts (runnning smbd/winbindd on each master) soon. 2. Use http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA to configure your Fedora 21+ or RHEL7.1beta or later servers to host Samba. >It is working flawlessly now. Thanks a lot for the tip, now my >smb.conf is just like in the example of the howto and it is working >through sssd-libwbclient accessing the keytab. > >I have detailed the steps and commands to create the ldap objects, >there is a typo many places on the internet because it was reproduced >from http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/cifs.html Notice that it is against Fedora 17 which is way old now and obsolete. >I also think should be documented somewhere that ipa-adtrust-install >creates/populates the ipaNTHash, I couldn't find it anywhere, someone >told me this on freenode. Given that you don't need to know about ipaNTHash to use http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA, all you need is documented there. I've added a note that IPA masters have to be configured with ipa-adtrust-install. >And one more doubt. >ipa config-mod --userobjectclasses=aaa,bbb,ccc >or ipa config-mod --groupobjectclasses=aaa,bbb,ccc >doesn't work on iPA 4. >Is there a way of doing this on the command line on ipa 4 ? Use shell expansion. ipa object-command --attribute={value1,value2,value3,...} -- / Alexander Bokovoy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From dpal at redhat.com Thu Feb 12 07:14:54 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 12 Feb 2015 02:14:54 -0500 Subject: [Freeipa-users] ad relation with winsync In-Reply-To: <487613314.673165.1423719446965.JavaMail.root@savoirfairelinux.com> References: <313055385.142650.1423642007008.JavaMail.root@savoirfairelinux.com> <599734995.147060.1423653496313.JavaMail.root@savoirfairelinux.com> <54DB6DE7.6070007@redhat.com> <487613314.673165.1423719446965.JavaMail.root@savoirfairelinux.com> Message-ID: <54DC52EE.40601@redhat.com> On 02/12/2015 12:37 AM, Nicolas Zin wrote: > That was that: > > in the logs (/var/log/dirsrv/slapd-HQ-EMIRATES-COM/errors) I got: > slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) > > > And when i did "LDAPTLS_CACERTDIR=/etc/dirsrv/... ldapsearch ...", it began to be interesting: > ldap_start_tls: Connect error (-11) > additionnal info: TLS: hostname does not match CN in peer certificate > > So I correct my problem: put the correct hostname in the ipa-replica-manage ( and not the ip). And it connects! > > > Next step: having the replication working. The customer dont want to give to my sync user "Replicating directory changes", "Account Operator" and "Enterprise Read-Only Domain Controller" attributs and just want a "oneway replication". > For the one way replication, I followed the documentation > > But I don't see any imported users. Do you have an idea? Are some of the Windows attributs necessary even for a one way (windows to linux) synchronisation? > > > Regards, > > > > Nicolas > > ----- Mail original ----- > De: "Rich Megginson" > ?: freeipa-users at redhat.com > Envoy?: Mercredi 11 F?vrier 2015 18:57:43 > Objet: Re: [Freeipa-users] ad relation with winsync > > On 02/11/2015 04:18 AM, Nicolas Zin wrote: >> I reply to myself. >> This was certainly a Windows configurarion issue. I went further: >> ipa-replica-manage connect --winsync --binddb cn=Administrator,cn=Users,dc=company,dc=com --bindpwd --passsync whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com -v >> Directory Manager password: ******** >> >> Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate database for srv7idm2.ipa.company.com >> ipa: INFO: AD Suffix is: DC=company,DC=com >> The user for Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=company,dc=com >> ipa: INFO: Added new sync agreement, waiting for it to become ready. . . >> ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP error: Connect error: start: 0 end: 0 >> ipa: INFO: Agreement is ready, starting replication . . . >> Starting replication, please wait until this has completed. >> >> [srv7idm2.ipa.company.com] reports: Update failed! Status: [-11 - LDAP error: Connect error] >> >> >> >> So apparently I manage to connect to AD but something went wrong after? >> How can I debug it? > You can test it like this: > > # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN ldapsearch -xLLLZZ -H > ldap://fqdn.of.ad.host -s base -b "DC=company,DC=com" -D > "cn=Administrator,cn=Users,dc=company,dc=com" -w "password" > >> >> >> Regards, >> >> >> >> Nicolas Zin >> >> >> >> ----- Mail original ----- >> De: "Nicolas Zin" >> ?: freeipa-users at redhat.com >> Envoy?: Mercredi 11 F?vrier 2015 12:06:47 >> Objet: [Freeipa-users] ad relation with winsync >> >> Hi, >> >> I now try to establish a winsync relation with a Windows 2008R2. >> I installed IDM 3.3 on RHEL7. >> >> When I try to create the replication: >> ipa-replica-manage connect --winsync --binddb cn=Administrator,cn=Users,dc=company,dc=com --bindpwd --passsync whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com >> Directory Manager password: ******** >> >> Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate database for srv7idm2.ipa.company.com >> ipa: INFO: Failed to connect to AD srever dc.company.com >> ipa: INFO: The error was: {'info': 'TLS error -8157:Certificate extension not found','desc': 'Connect error'} >> Failed to setup winsync replication >> >> >> Do you have an idea, what's wrong? >> Also is it possible to point to port 636 instead? >> >> >> Notes: >> - On the windows side, ssl has been activated (with pain) and ldp.exe manage to connect via ssl on the 636 port correctly (so the certificate is in place). I don't know how to check it is working properly on port 389, i.e. START_TLS works >> - I checked that the 2 box have the same time (ntp) >> - I nearly manage to make it working once, but I got another error during replication The is is treated as the ultimate source so adds should go only from AD to IPA but you need the modify to work both ways otherwise your account state will get out of sync. Whatever is required by docs is the minimal privilege you need to have to sync users. However did you consider trust? It us a two way trust but it acts as a one way trust. >> >> >> >> Nicolas Zin >> nicolas.zin at savoirfairelinux.com >> Ligne directe: 514-276-5468 poste 135 >> >> Fax : 514-276-5465 >> 7275 Saint Urbain >> Bureau 200 >> Montr?al, QC, H2R 2Y5 >> >> >> -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Feb 12 07:20:36 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 12 Feb 2015 02:20:36 -0500 Subject: [Freeipa-users] Where and how are passwords stored? In-Reply-To: References: Message-ID: <54DC5444.2080409@redhat.com> On 02/12/2015 01:25 AM, Michael Lasevich wrote: > Ok, after a few awkward questions from an auditor, I am starting to > face the uncomfortable truth that my understanding about how FreeIPA > works is a lot fuzzier than I would like. > > Specifically, the question I could not answer - where are the > passwords stored and how are they encrypted? My understanding is that > all authentication is handled by Kerberos server, which stores its > data in LDAP - but where and how is a bit of a mystery to me. Any way > to dump out the password hashes? Passwords are stored in LDAP in two different attributes per entry. One with LDAP password hash and another is Kerberos password hash allowing authentication either with Kerebros or LDAP. Both follow best practices in terms of using hash algorithms. The attributes themselves are protected by the access control instructions (ACI) so only a super priviledged admin or user himself can interact with this attribute. During normal operations it is not fetched and read. The core of the DS processes it behind the closed doors so it is possible to reset but not to read. This is how LDAP works and not different from any modern directory server. > > Thanks, > > -M > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Feb 12 08:10:51 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Feb 2015 09:10:51 +0100 Subject: [Freeipa-users] Where and how are passwords stored? In-Reply-To: <54DC5444.2080409@redhat.com> References: <54DC5444.2080409@redhat.com> Message-ID: <54DC600B.8020806@redhat.com> On 02/12/2015 08:20 AM, Dmitri Pal wrote: > On 02/12/2015 01:25 AM, Michael Lasevich wrote: >> Ok, after a few awkward questions from an auditor, I am starting to face the >> uncomfortable truth that my understanding about how FreeIPA works is a lot >> fuzzier than I would like. >> >> Specifically, the question I could not answer - where are the passwords >> stored and how are they encrypted? My understanding is that all >> authentication is handled by Kerberos server, which stores its data in LDAP - >> but where and how is a bit of a mystery to me. Any way to dump out the >> password hashes? > > Passwords are stored in LDAP in two different attributes per entry. One with > LDAP password hash and another is Kerberos password hash allowing > authentication either with Kerebros or LDAP. Both follow best practices in > terms of using hash algorithms. The attributes themselves are protected by the > access control instructions (ACI) so only a super priviledged admin or user > himself can interact with this attribute. During normal operations it is not > fetched and read. The core of the DS processes it behind the closed doors so it > is possible to reset but not to read. > This is how LDAP works and not different from any modern directory server. Right. To prove Dmitri's point, see the 2 LDAP searches for all user attributes containing key material (samba* are used when trusts are enabled). First search as FreeIPA admin user: # ldapsearch -Y GSSAPI -b 'uid=admin,cn=users,cn=accounts,dc=mkosek-f21,dc=test' uid userpassword krbprincipalkey sambalmpassword sambantpassword SASL/GSSAPI authentication started SASL username: admin at MKOSEK-F21.TEST SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: uid userpassword krbprincipalkey sambalmpassword sambantpassword # # admin, users, accounts, mkosek-f21.test dn: uid=admin,cn=users,cn=accounts,dc=mkosek-f21,dc=test uid: admin # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1 Second search with Directory Manager (god-like LDAP user): # ldapsearch -D "cn=Directory Manager" -x -w kokos123 -b 'uid=admin,cn=users,cn=accounts,dc=mkosek-f21,dc=test' uid userpassword krbprincipalkey sambalmpassword sambantpassword # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: uid userpassword krbprincipalkey sambalmpassword sambantpassword # # admin, users, accounts, mkosek-f21.test dn: uid=admin,cn=users,cn=accounts,dc=mkosek-f21,dc=test uid: admin userpassword:: e1NTSEF9dHZEaUZ4ejJTUkRBLzh1NUZSSGVIT2N4WkZMci9OYktQNHNLNWc9PQ= = krbprincipalkey:: MIIBnKADAgEBoQMCAQGiAwIBAaMDAgEBpIIBhDCCAYAwaKAbMBmgAwIBBKES BBA/WWlaNF0nOG80QDFaPWhYoUkwR6ADAgESoUAEPiAAxQsFjSPBOpCollrI8ex+lVnTg8GrZV6nl baP3pZYoBtGVeQ3cBtYbl3usq9o+RIZfnNX2P8YZNlVmnjXMFigGzAZoAMCAQShEgQQL21HRSB6Pn ZdQXpeYl5sQqE5MDegAwIBEaEwBC4QANB2xAVgnL2o3n3u+KkFHaEcije2vOdRcGmtZlhdsRHsCbn y4/tydusWjrRxMGCgGzAZoAMCAQShEgQQUkckOF1SayxramRTWnkwUqFBMD+gAwIBEKE4BDYYAEo3 1vjbSStevF5QcY7WDc1RwFZ6paLp3WTAFATJSej0r+M8fVeNDgKb4CZHRKsNu9cMmdUwWKAbMBmgA wIBBKESBBBCU1xDYmpxeHs6PGIkPi8voTkwN6ADAgEXoTAELhAATVwH6hkkO45W/Vmj0phXiDQe8j Eq11TRGiRHsYKUFtp/3lh89/gp5OuhIyo= # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 # echo 'e1NTSEF9dHZEaUZ4ejJTUkRBLzh1NUZSSGVIT2N4WkZMci9OYktQNHNLNWc9PQ==' | base64 --decode {SSHA}tvDiFxz2SRDA/8u5FRHeHOcxZFLr/NbKP4sK5g== Martin From yoshi314 at gmail.com Thu Feb 12 08:46:53 2015 From: yoshi314 at gmail.com (marcin kowalski) Date: Thu, 12 Feb 2015 09:46:53 +0100 Subject: [Freeipa-users] slight problem when integrating certmonger with dogtag on fedora 21 In-Reply-To: <54DB9C21.9050800@redhat.com> References: <54DA4278.6000206@redhat.com> <54DB9C21.9050800@redhat.com> Message-ID: > What is your reasoning for setting up your own CA configuration? Why not just use either ipa-getcert or getcert -c IPA? I am not yet familiar with the entire setup enough to give a good answer. I assume that requires full freeIPA setup, which i don't really need. I just wanted a simplistic dogtag ca instance + certmonger setup for watching certs on various machines and checking if the requests get filled in correctly, and then expanding on it once i get more familiar with other workings of it. And i got stuck on certmonger. 2015-02-11 19:14 GMT+01:00 Rob Crittenden : > marcin kowalski wrote: > > |Edit: i acceditanlly forgot to send copy to the list, so resubmitting. > > > > > > I tried this command : > > > > getcert request -c dogtag-ipa -f /etc/pki/testcert -k /etc/pki/testkey > > -N "cn=mywebserver" > > > > i've setup the 'dogtag-ipa' ca in certmonger like so : > > > > id=dogtag-ipa > > ca_aka=Dogtag (IPA,renew,agent) (certmonger 0.76.8) > > ca_is_default=0 > > ca_type=EXTERNAL > > ca_external_helper=/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit > > -E https://fedora.box.net:8443/ca/ee/ca -A > > https://fedora.box.net:8443/ca/agent/ca/ -n "CN=BOX.NET > > admin" -d /var/lib/pki/pki-tomcat/alias/ -i /etc/ipa/ca.crt -v > > > > > > Since i haven't fully figured out how to setup authentication for > > certmonger yet, i've temporarily reused one from the dogtag's pki > > instance. Hopefully it's not a fatal mistake on my end. > > What is your reasoning for setting up your own CA configuration? Why not > just use either ipa-getcert or getcert -c IPA? > > rob > > > > > From the certmonger logs i get : > > > > lut 11 09:52:19 fedora.box.net > > dogtag-ipa-renew-agent-submit[2887]: GET > > > https://fedora.box.net:8443/ca/ee/ca/profileSubmit?profileId=caServerCert&cert_request_type=pkcs10&cert_request=-----BEGIN+NEW+CERTIFICATE+REQUEST-----%0AMIICyTCCAbECAQAwFjEUMBIGA1UEAxMLbXl3ZWJzZXJ2ZXIwggEiMA0GCSqGSIb3%0ADQEBAQUAA4IBDwAwggEKAoIBAQDLZKK8dUqmiY2YAS2LrNE9DsB7QVhuATEcXkrc%0AB121jafN9BMyNSGQjWlpb15P4xqaXHrplQl60d4sSZA1d4GAxoywDUvoUA7R%2FrJ7%0AVcFyA7R5mRzK%2BfNUg%2FdLqTrnWM6GC1ecYwUwAmI%2FOFa5OomQczdGoV1ippguR2Un%0ArCCdXImZtni845FI1Wx745GP4mH2od7otSqGeLiQR9I6RLdrcs%2FC%2FWhWqPgUmyxp%0AEb%2BFS%2FAGPXG1nE2eT64z2OLQLJWfOT1uYRClsrQ9Bw96Cv20KPupEr4BPwfX%2BQzs%0AR7p9E%2BW1TuQhqX2NrWl4V%2F0tqc0omXGQZx62jCZM0m%2B2eoYJAgMBAAGgbjArBgkq%0AhkiG9w0BCRQxHh4cADIAMAAxADUAMAAyADEAMQAwADgANQAyADEAODA%2FBgkqhkiG%0A9w0BCQ4xMjAwMAwGA1UdEwEB%2FwQCMAAwIAYDVR0OAQEABBYEFEEoeB59tZYgOLSg%0AHV3fzBtlQCiaMA0GCSqGSIb3DQEBCwUAA4IBAQCpc3v8wp6csgKN3H8TfXe5Ay5h%0ATTqKyN2iLQKurTlTbwv%2FhZsE3ketuSfEOCJpE7Z58jlLB7VlMl6Uyl2MrOmC7Ro5%0Ai13LpVvVd%2FLsCedhM%2BTlYPtsk68DVcf1XKZARH6MIRmiDWSr0gajeP6bZK8znQ > ! > K%2B%0A6O7 > > LaHKv1HaVcjxTZ%2Fdep3OF7aYtsz5tnyoaP1D2CI2WRRGnwjX4bBmr%2FQIZe7ba%0AOQt1yznFPjonEwVaOg3wkx0uaxdkyMz3MZC8nJxYCvBnNgV72tbA6As93laQaTQ2%0A24HhzdEWnJ019W72qJdTDpPg4DtloU0W%2BJYiIIpCfQIn1%2FjJLOnJcWiGPDDd%0A-----END+NEW+CERTIFICATE+REQUEST-----%0A&xml=true > > lut 11 09:52:19 fedora.box.net > > dogtag-ipa-renew-agent-submit[2887]: > encoding="UTF-8" > > standalone="no"?>2Request Deferred > > - {0} 49 > > > > > > And the request #49 is placed in Dogtag's CA Agent services, and can be > > acknowledged/rejected correctly. It's just that certmonger is stuck and > > doesn't notice the successful delivery. > > > > Machine is in isolated network, so there is probably no issue wrt using > > box.net as test domain.| > > > > 2015-02-10 18:40 GMT+01:00 Dmitri Pal > >: > > > > On 02/10/2015 12:35 PM, marcin kowalski wrote: > >> Hi all, i'm getting dogtag figured out slowly, and i noticed one > >> odd thing. > >> > >> I've setup certmonger to request an arbitrary certificate through > >> dogtag, and while the request seems to go into the dogtag system, > >> certmonger acts as if communication with the CA failed. The > >> certificate is considered in need of user attention because the > >> process got stuck. > >> > >> Request ID ?20150210125814?: > >> status: NEED_GUIDANCE > >> stuck: yes > >> key pair storage: type=FILE,location=?/etc/pki/testkey? > >> certificate: type=FILE,location=?/etc/pki/testcert? > >> CA: dogtag-ipa > >> issuer: > >> subject: > >> expires: unknown > >> pre-save command: > >> post-save command: > >> track: yes > >> auto-renew: yes > >> > >> > >> [root at fedora pki]# systemctl status -l certmonger > >> (?.) > >> lut 10 13:57:04 fedora.box.net > >> certmonger[7845]: Request for certificate to be stored in file > >> ?/etc/pki/testcert? rejected by CA. > >> > >> > >> The request is present in dogtag and is valid, can be > >> accepted/rejected, etc. Even though certmonger never notices that. > >> I wonder if there is some obvious mistake in my setup, or perhaps > >> there is known bug in interaction of both components on F21 (i'm > >> using only standard repositories). > >> > >> When i post the query from certmonger's agent defined in ca > >> definition through curl, i get no errors. > >> > >> What would be the best way to debug this issue? > >> > >> > > Can you post your certmonger get-cert command? > > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager IdM portfolio > > Red Hat, Inc. > > > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go To http://freeipa.org for more info on the project > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.zin at savoirfairelinux.com Thu Feb 12 08:49:34 2015 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Thu, 12 Feb 2015 03:49:34 -0500 (EST) Subject: [Freeipa-users] ad relation with winsync In-Reply-To: <54DC52EE.40601@redhat.com> References: <313055385.142650.1423642007008.JavaMail.root@savoirfairelinux.com> <599734995.147060.1423653496313.JavaMail.root@savoirfairelinux.com> <54DB6DE7.6070007@redhat.com> <487613314.673165.1423719446965.JavaMail.root@savoirfairelinux.com> <54DC52EE.40601@redhat.com> Message-ID: <460221078.688828.1423730974249.JavaMail.root@savoirfairelinux.com> > The is is treated as the ultimate source so adds should go only from AD > to IPA but you need the modify to work both ways otherwise your account > state will get out of sync. > Whatever is required by docs is the minimal privilege you need to have > to sync users. > > However did you consider trust? > It us a two way trust but it acts as a one way trust. I know, but my customer don't want a two-way trust, whatever it means: - it fear some security concern with a two-way. - if he migrates its AD into new version or new topology, he fears to encounter some migration path issue So it has been decided to go the winsync way. btw, I manage to make my one way replication working, with less privileges, following http://directory.fedoraproject.org/docs/389ds/howto/howto-windowssync.html#creating-ad-user-with-replication-rights Thank you Nicolas From abokovoy at redhat.com Thu Feb 12 08:57:07 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 12 Feb 2015 10:57:07 +0200 Subject: [Freeipa-users] ad relation with winsync In-Reply-To: <460221078.688828.1423730974249.JavaMail.root@savoirfairelinux.com> References: <313055385.142650.1423642007008.JavaMail.root@savoirfairelinux.com> <599734995.147060.1423653496313.JavaMail.root@savoirfairelinux.com> <54DB6DE7.6070007@redhat.com> <487613314.673165.1423719446965.JavaMail.root@savoirfairelinux.com> <54DC52EE.40601@redhat.com> <460221078.688828.1423730974249.JavaMail.root@savoirfairelinux.com> Message-ID: <20150212085707.GB13663@redhat.com> On Thu, 12 Feb 2015, Nicolas Zin wrote: > > > >> The is is treated as the ultimate source so adds should go only from AD >> to IPA but you need the modify to work both ways otherwise your account >> state will get out of sync. >> Whatever is required by docs is the minimal privilege you need to have >> to sync users. >> >> However did you consider trust? >> It us a two way trust but it acts as a one way trust. > >I know, but my customer don't want a two-way trust, whatever it means: >- it fear some security concern with a two-way. We've been through this multiple times, check freeipa-users@ archives for arguments for and against. >- if he migrates its AD into new version or new topology, he fears to encounter some migration path issue Cross-forest trust is the standard feature of AD, we foresee no migration path issues and it works with everything from Windows Server 2003 to Windows Server 2012R2 (though Red Hat only supports cross-forest trust starting with Windows Server 2008 onwards but this is mostly because 2003 is already out of support by Microsoft). >So it has been decided to go the winsync way. > >btw, I manage to make my one way replication working, with less >privileges, following >http://directory.fedoraproject.org/docs/389ds/howto/howto-windowssync.html#creating-ad-user-with-replication-rights > -- / Alexander Bokovoy From nicolas.zin at savoirfairelinux.com Thu Feb 12 09:35:14 2015 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Thu, 12 Feb 2015 04:35:14 -0500 (EST) Subject: [Freeipa-users] ad relation with winsync In-Reply-To: <20150212085707.GB13663@redhat.com> References: <313055385.142650.1423642007008.JavaMail.root@savoirfairelinux.com> <599734995.147060.1423653496313.JavaMail.root@savoirfairelinux.com> <54DB6DE7.6070007@redhat.com> <487613314.673165.1423719446965.JavaMail.root@savoirfairelinux.com> <54DC52EE.40601@redhat.com> <460221078.688828.1423730974249.JavaMail.root@savoirfairelinux.com> <20150212085707.GB13663@redhat.com> Message-ID: <1287063218.694323.1423733714071.JavaMail.root@savoirfairelinux.com> the ----- Mail original ----- > De: "Alexander Bokovoy" > ?: "Nicolas Zin" > Cc: dpal at redhat.com, freeipa-users at redhat.com > Envoy?: Jeudi 12 F?vrier 2015 12:57:07 > Objet: Re: [Freeipa-users] ad relation with winsync > > On Thu, 12 Feb 2015, Nicolas Zin wrote: >> >> >> >>> The is is treated as the ultimate source so adds should go only from AD >>> to IPA but you need the modify to work both ways otherwise your account >>> state will get out of sync. >>> Whatever is required by docs is the minimal privilege you need to have >>> to sync users. >>> >>> However did you consider trust? >>> It us a two way trust but it acts as a one way trust. >> >>I know, but my customer don't want a two-way trust, whatever it means: >>- it fear some security concern with a two-way. > We've been through this multiple times, check freeipa-users@ archives > for arguments for and against. > >> - if he migrates its AD into new version or new topology, he fears to encounter some migration path issue > Cross-forest trust is the standard feature of AD, we foresee no > migration path issues and it works with everything from Windows Server > 2003 to Windows Server 2012R2 (though Red Hat only supports cross-forest trust > starting with Windows Server 2008 onwards but this is mostly because > 2003 is already out of support by Microsoft). > I guess the client will change from mind when he will see the deployment (and maintenance) cost to install the password sync agent on all DC, and the need to reboot their DC. This is why we are in an PoC for the moment :-) I will try to see their points, and clarify the situation. For the arguments From dpal at redhat.com Thu Feb 12 09:47:37 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 12 Feb 2015 04:47:37 -0500 Subject: [Freeipa-users] slight problem when integrating certmonger with dogtag on fedora 21 In-Reply-To: References: <54DA4278.6000206@redhat.com> <54DB9C21.9050800@redhat.com> Message-ID: <54DC76B9.8070608@redhat.com> On 02/12/2015 03:46 AM, marcin kowalski wrote: > > What is your reasoning for setting up your own CA configuration? Why not > just use either ipa-getcert or getcert -c IPA? > > I am not yet familiar with the entire setup enough to give a good > answer. I assume that requires full freeIPA setup, which i don't > really need. > > I just wanted a simplistic dogtag ca instance + certmonger setup for > watching certs on various machines and checking if the requests get > filled in correctly, and then expanding on it once i get more familiar > with other workings of it. And i got stuck on certmonger. I do not think certmonger is currently supported with pure Dogtag without the IPA. There are some parts of it present but it might not work end to end. IN case of IPA certmonger uses kerberos to authenticate to server and fetch the certs. Without IPA you have to deal with the pure cert base setup which we have not had a priority complete. > > 2015-02-11 19:14 GMT+01:00 Rob Crittenden >: > > marcin kowalski wrote: > > |Edit: i acceditanlly forgot to send copy to the list, so > resubmitting. > > > > > > I tried this command : > > > > getcert request -c dogtag-ipa -f /etc/pki/testcert -k > /etc/pki/testkey > > -N "cn=mywebserver" > > > > i've setup the 'dogtag-ipa' ca in certmonger like so : > > > > id=dogtag-ipa > > ca_aka=Dogtag (IPA,renew,agent) (certmonger 0.76.8) > > ca_is_default=0 > > ca_type=EXTERNAL > > > ca_external_helper=/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit > > -E https://fedora.box.net:8443/ca/ee/ca -A > > https://fedora.box.net:8443/ca/agent/ca/ -n "CN=BOX.NET > > > admin" -d /var/lib/pki/pki-tomcat/alias/ -i /etc/ipa/ca.crt -v > > > > > > Since i haven't fully figured out how to setup authentication for > > certmonger yet, i've temporarily reused one from the dogtag's pki > > instance. Hopefully it's not a fatal mistake on my end. > > What is your reasoning for setting up your own CA configuration? > Why not > just use either ipa-getcert or getcert -c IPA? > > rob > > > > > From the certmonger logs i get : > > > > lut 11 09:52:19 fedora.box.net > > > dogtag-ipa-renew-agent-submit[2887]: GET > > > https://fedora.box.net:8443/ca/ee/ca/profileSubmit?profileId=caServerCert&cert_request_type=pkcs10&cert_request=-----BEGIN+NEW+CERTIFICATE+REQUEST-----%0AMIICyTCCAbECAQAwFjEUMBIGA1UEAxMLbXl3ZWJzZXJ2ZXIwggEiMA0GCSqGSIb3%0ADQEBAQUAA4IBDwAwggEKAoIBAQDLZKK8dUqmiY2YAS2LrNE9DsB7QVhuATEcXkrc%0AB121jafN9BMyNSGQjWlpb15P4xqaXHrplQl60d4sSZA1d4GAxoywDUvoUA7R%2FrJ7%0AVcFyA7R5mRzK%2BfNUg%2FdLqTrnWM6GC1ecYwUwAmI%2FOFa5OomQczdGoV1ippguR2Un%0ArCCdXImZtni845FI1Wx745GP4mH2od7otSqGeLiQR9I6RLdrcs%2FC%2FWhWqPgUmyxp%0AEb%2BFS%2FAGPXG1nE2eT64z2OLQLJWfOT1uYRClsrQ9Bw96Cv20KPupEr4BPwfX%2BQzs%0AR7p9E%2BW1TuQhqX2NrWl4V%2F0tqc0omXGQZx62jCZM0m%2B2eoYJAgMBAAGgbjArBgkq%0AhkiG9w0BCRQxHh4cADIAMAAxADUAMAAyADEAMQAwADgANQAyADEAODA%2FBgkqhkiG%0A9w0BCQ4xMjAwMAwGA1UdEwEB%2FwQCMAAwIAYDVR0OAQEABBYEFEEoeB59tZYgOLSg%0AHV3fzBtlQCiaMA0GCSqGSIb3DQEBCwUAA4IBAQCpc3v8wp6csgKN3H8TfXe5Ay5h%0ATTqKyN2iLQKurTlTbwv%2FhZsE3ketuSfEOCJpE7Z58jlLB7VlMl6Uyl2MrOmC7Ro5%0Ai13LpVvVd%2FLsCedhM%2BTlYPtsk68DVcf1XKZARH6MIRmiDWSr0gajeP6bZK8znQ! > K%2B%0A6O7 > LaHKv1HaVcjxTZ%2Fdep3OF7aYtsz5tnyoaP1D2CI2WRRGnwjX4bBmr%2FQIZe7ba%0AOQt1yznFPjonEwVaOg3wkx0uaxdkyMz3MZC8nJxYCvBnNgV72tbA6As93laQaTQ2%0A24HhzdEWnJ019W72qJdTDpPg4DtloU0W%2BJYiIIpCfQIn1%2FjJLOnJcWiGPDDd%0A-----END+NEW+CERTIFICATE+REQUEST-----%0A&xml=true > > lut 11 09:52:19 fedora.box.net > > > dogtag-ipa-renew-agent-submit[2887]: > encoding="UTF-8" > > standalone="no"?>2Request > Deferred > > - {0} 49 > > > > > > And the request #49 is placed in Dogtag's CA Agent services, and > can be > > acknowledged/rejected correctly. It's just that certmonger is > stuck and > > doesn't notice the successful delivery. > > > > Machine is in isolated network, so there is probably no issue > wrt using > > box.net as test domain.| > > > > 2015-02-10 18:40 GMT+01:00 Dmitri Pal > > >>: > > > > On 02/10/2015 12:35 PM, marcin kowalski wrote: > >> Hi all, i'm getting dogtag figured out slowly, and i > noticed one > >> odd thing. > >> > >> I've setup certmonger to request an arbitrary certificate > through > >> dogtag, and while the request seems to go into the dogtag > system, > >> certmonger acts as if communication with the CA failed. The > >> certificate is considered in need of user attention because the > >> process got stuck. > >> > >> Request ID ?20150210125814?: > >> status: NEED_GUIDANCE > >> stuck: yes > >> key pair storage: type=FILE,location=?/etc/pki/testkey? > >> certificate: type=FILE,location=?/etc/pki/testcert? > >> CA: dogtag-ipa > >> issuer: > >> subject: > >> expires: unknown > >> pre-save command: > >> post-save command: > >> track: yes > >> auto-renew: yes > >> > >> > >> [root at fedora pki]# systemctl status -l certmonger > >> (?.) > >> lut 10 13:57:04 fedora.box.net > > >> certmonger[7845]: Request for certificate to be stored in file > >> ?/etc/pki/testcert? rejected by CA. > >> > >> > >> The request is present in dogtag and is valid, can be > >> accepted/rejected, etc. Even though certmonger never > notices that. > >> I wonder if there is some obvious mistake in my setup, or > perhaps > >> there is known bug in interaction of both components on > F21 (i'm > >> using only standard repositories). > >> > >> When i post the query from certmonger's agent defined in ca > >> definition through curl, i get no errors. > >> > >> What would be the best way to debug this issue? > >> > >> > > Can you post your certmonger get-cert command? > > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager IdM portfolio > > Red Hat, Inc. > > > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go To http://freeipa.org for more info on the project > > > > > > > > > > -- 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 Thu Feb 12 13:02:34 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Feb 2015 08:02:34 -0500 Subject: [Freeipa-users] Where and how are passwords stored? In-Reply-To: <54DC5444.2080409@redhat.com> References: <54DC5444.2080409@redhat.com> Message-ID: <1423746154.5770.14.camel@willson.usersys.redhat.com> On Thu, 2015-02-12 at 02:20 -0500, Dmitri Pal wrote: > On 02/12/2015 01:25 AM, Michael Lasevich wrote: > > Ok, after a few awkward questions from an auditor, I am starting to > > face the uncomfortable truth that my understanding about how FreeIPA > > works is a lot fuzzier than I would like. > > > > Specifically, the question I could not answer - where are the > > passwords stored and how are they encrypted? My understanding is that > > all authentication is handled by Kerberos server, which stores its > > data in LDAP - but where and how is a bit of a mystery to me. Any way > > to dump out the password hashes? > > Passwords are stored in LDAP in two different attributes per entry. One > with LDAP password hash and another is Kerberos password hash allowing > authentication either with Kerebros or LDAP. Both follow best practices > in terms of using hash algorithms. The attributes themselves are > protected by the access control instructions (ACI) so only a super > priviledged admin or user himself can interact with this attribute. > During normal operations it is not fetched and read. The core of the DS > processes it behind the closed doors so it is possible to reset but not > to read. > This is how LDAP works and not different from any modern directory server. Keep in mind that the Kerberos keys are additionally encrypted with a master password, so reading the attribute alone is useless. Simo. -- Simo Sorce * Red Hat, Inc * New York From mlasevich at gmail.com Thu Feb 12 15:38:08 2015 From: mlasevich at gmail.com (Michael Lasevich) Date: Thu, 12 Feb 2015 07:38:08 -0800 Subject: [Freeipa-users] Where and how are passwords stored? In-Reply-To: <1423746154.5770.14.camel@willson.usersys.redhat.com> References: <54DC5444.2080409@redhat.com> <1423746154.5770.14.camel@willson.usersys.redhat.com> Message-ID: Thank you, this is very helpful. I forgot about 'super admin', which is why I was not even seeing the values before. :-) How are the the values encrypted (or hashed?) It sounds like the password is stored in two fields(I am leaving samba out for now) - userpassword andkerberos principle key. Is userpassword a hash? Of so, what kind? KerberosPrincipleKey you mention is encrypted with Kerberos master key - is the plaintext of password encrypted or is it a hash that is encrypted? What encryption and or hashing used for that? Thank you, -M On Feb 12, 2015 5:04 AM, "Simo Sorce" wrote: > On Thu, 2015-02-12 at 02:20 -0500, Dmitri Pal wrote: > > On 02/12/2015 01:25 AM, Michael Lasevich wrote: > > > Ok, after a few awkward questions from an auditor, I am starting to > > > face the uncomfortable truth that my understanding about how FreeIPA > > > works is a lot fuzzier than I would like. > > > > > > Specifically, the question I could not answer - where are the > > > passwords stored and how are they encrypted? My understanding is that > > > all authentication is handled by Kerberos server, which stores its > > > data in LDAP - but where and how is a bit of a mystery to me. Any way > > > to dump out the password hashes? > > > > Passwords are stored in LDAP in two different attributes per entry. One > > with LDAP password hash and another is Kerberos password hash allowing > > authentication either with Kerebros or LDAP. Both follow best practices > > in terms of using hash algorithms. The attributes themselves are > > protected by the access control instructions (ACI) so only a super > > priviledged admin or user himself can interact with this attribute. > > During normal operations it is not fetched and read. The core of the DS > > processes it behind the closed doors so it is possible to reset but not > > to read. > > This is how LDAP works and not different from any modern directory > server. > > Keep in mind that the Kerberos keys are additionally encrypted with a > master password, so reading the attribute alone is useless. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Feb 12 15:48:07 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 12 Feb 2015 08:48:07 -0700 Subject: [Freeipa-users] Where and how are passwords stored? In-Reply-To: References: <54DC5444.2080409@redhat.com> <1423746154.5770.14.camel@willson.usersys.redhat.com> Message-ID: <54DCCB37.2050905@redhat.com> On 02/12/2015 08:38 AM, Michael Lasevich wrote: > > Thank you, this is very helpful. I forgot about 'super admin', which > is why I was not even seeing the values before. :-) > > How are the the values encrypted (or hashed?) > > It sounds like the password is stored in two fields(I am leaving samba > out for now) - userpassword andkerberos principle key. Is userpassword > a hash? Of so, what kind? > Salted SHA 140 by default. You can crank this all the way up to Salted SHA 512. > KerberosPrincipleKey you mention is encrypted with Kerberos master key > - is the plaintext of password encrypted or is it a hash that is > encrypted? What encryption and or hashing used for that? > > Thank you, > > -M > > On Feb 12, 2015 5:04 AM, "Simo Sorce" > wrote: > > On Thu, 2015-02-12 at 02:20 -0500, Dmitri Pal wrote: > > On 02/12/2015 01:25 AM, Michael Lasevich wrote: > > > Ok, after a few awkward questions from an auditor, I am > starting to > > > face the uncomfortable truth that my understanding about how > FreeIPA > > > works is a lot fuzzier than I would like. > > > > > > Specifically, the question I could not answer - where are the > > > passwords stored and how are they encrypted? My understanding > is that > > > all authentication is handled by Kerberos server, which stores its > > > data in LDAP - but where and how is a bit of a mystery to me. > Any way > > > to dump out the password hashes? > > > > Passwords are stored in LDAP in two different attributes per > entry. One > > with LDAP password hash and another is Kerberos password hash > allowing > > authentication either with Kerebros or LDAP. Both follow best > practices > > in terms of using hash algorithms. The attributes themselves are > > protected by the access control instructions (ACI) so only a super > > priviledged admin or user himself can interact with this attribute. > > During normal operations it is not fetched and read. The core of > the DS > > processes it behind the closed doors so it is possible to reset > but not > > to read. > > This is how LDAP works and not different from any modern > directory server. > > Keep in mind that the Kerberos keys are additionally encrypted with a > master password, so reading the attribute alone is useless. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Feb 12 15:48:42 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Feb 2015 10:48:42 -0500 Subject: [Freeipa-users] Where and how are passwords stored? In-Reply-To: References: <54DC5444.2080409@redhat.com> <1423746154.5770.14.camel@willson.usersys.redhat.com> Message-ID: <1423756122.5770.41.camel@willson.usersys.redhat.com> On Thu, 2015-02-12 at 07:38 -0800, Michael Lasevich wrote: > Thank you, this is very helpful. I forgot about 'super admin', which is why > I was not even seeing the values before. :-) > > How are the the values encrypted (or hashed?) > > It sounds like the password is stored in two fields(I am leaving samba out > for now) - userpassword andkerberos principle key. > Is userpassword a hash? Yes. > Of so, what kind? Configurable, by default salted sha256 IIRC. > KerberosPrincipleKey you mention is encrypted with > Kerberos master key - is the plaintext of password encrypted or is it a > hash that is encrypted? All keys are hashes, they are stored into a asn.1 encoded structure that is then encrypted with the master key. > What encryption and or hashing used for that? It depends on the supported keys. Simo. -- Simo Sorce * Red Hat, Inc * New York From janellenicole80 at gmail.com Thu Feb 12 15:51:25 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 12 Feb 2015 07:51:25 -0800 Subject: [Freeipa-users] Where and how are passwords stored? In-Reply-To: <54DCCB37.2050905@redhat.com> References: <54DC5444.2080409@redhat.com> <1423746154.5770.14.camel@willson.usersys.redhat.com> <54DCCB37.2050905@redhat.com> Message-ID: <54DCCBFD.5000202@gmail.com> On 2/12/15 7:48 AM, Rich Megginson wrote: > On 02/12/2015 08:38 AM, Michael Lasevich wrote: >> >> Thank you, this is very helpful. I forgot about 'super admin', which >> is why I was not even seeing the values before. :-) >> >> How are the the values encrypted (or hashed?) >> >> It sounds like the password is stored in two fields(I am leaving >> samba out for now) - userpassword andkerberos principle key. Is >> userpassword a hash? Of so, what kind? >> > > Salted SHA 140 by default. You can crank this all the way up to > Salted SHA 512. > Where would you change it to get sha512?? ~J -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at monetra.com Thu Feb 12 16:05:15 2015 From: brad at monetra.com (Brad House) Date: Thu, 12 Feb 2015 11:05:15 -0500 Subject: [Freeipa-users] Where and how are passwords stored? In-Reply-To: <1423756122.5770.41.camel@willson.usersys.redhat.com> References: <54DC5444.2080409@redhat.com> <1423746154.5770.14.camel@willson.usersys.redhat.com> <1423756122.5770.41.camel@willson.usersys.redhat.com> Message-ID: <54DCCF3B.9020702@monetra.com> On 02/12/2015 10:48 AM, Simo Sorce wrote: > On Thu, 2015-02-12 at 07:38 -0800, Michael Lasevich wrote: >> Thank you, this is very helpful. I forgot about 'super admin', which is why >> I was not even seeing the values before. :-) >> >> How are the the values encrypted (or hashed?) >> >> It sounds like the password is stored in two fields(I am leaving samba out >> for now) - userpassword andkerberos principle key. > >> Is userpassword a hash? > > Yes. > >> Of so, what kind? > > Configurable, by default salted sha256 IIRC. Out of curiousity, where is this configurable? Also, is it using it in conjunction with something like PBKDF2? I'd love to know more info on this as we might want to increase the defaults ourselves. Thanks! -Brad From rmeggins at redhat.com Thu Feb 12 16:17:06 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 12 Feb 2015 09:17:06 -0700 Subject: [Freeipa-users] Where and how are passwords stored? In-Reply-To: <54DCCF3B.9020702@monetra.com> References: <54DC5444.2080409@redhat.com> <1423746154.5770.14.camel@willson.usersys.redhat.com> <1423756122.5770.41.camel@willson.usersys.redhat.com> <54DCCF3B.9020702@monetra.com> Message-ID: <54DCD202.7080207@redhat.com> On 02/12/2015 09:05 AM, Brad House wrote: > On 02/12/2015 10:48 AM, Simo Sorce wrote: >> On Thu, 2015-02-12 at 07:38 -0800, Michael Lasevich wrote: >>> Thank you, this is very helpful. I forgot about 'super admin', which >>> is why >>> I was not even seeing the values before. :-) >>> >>> How are the the values encrypted (or hashed?) >>> >>> It sounds like the password is stored in two fields(I am leaving >>> samba out >>> for now) - userpassword andkerberos principle key. >> >>> Is userpassword a hash? >> >> Yes. >> >>> Of so, what kind? >> >> Configurable, by default salted sha256 IIRC. > > Out of curiousity, where is this configurable? https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/User_Account_Management.html#User_Account_Management-Managing_the_Password_Policy This is the passwordStorageScheme attribute. > Also, is it using it in > conjunction with something like PBKDF2? https://fedorahosted.org/389/ticket/397 > I'd love to know more info on this > as we might want to increase the defaults ourselves. > > > Thanks! > -Brad > From leszek.mis at gmail.com Thu Feb 12 18:06:59 2015 From: leszek.mis at gmail.com (crony) Date: Thu, 12 Feb 2015 19:06:59 +0100 Subject: [Freeipa-users] AD Cross Realm Trust + AIX Message-ID: Hi All, can I ask you for some advice? My setup is: - updated RHEL7 as IPA server (UX.EXAMPLE.COM) in trust with Active Directory 2008R2 domain (EXAMPLE.COM) - AIX 7 as IPA client I'm using compat tree for connecting AIX as client. A lot of things work correctly: # /usr/krb5/bin/kinit leszek Password for ad_user at EXAMPLE.COM: # /usr/krb5/bin/klist Ticket cache: FILE:/var/krb5/security/creds/krb5cc_0 Default principal: ad_user at EXAMPLE.COM Valid starting Expires Service principal 02/12/15 15:46:23 02/13/15 01:46:31 krbtgt/EXAMPLE.COM at EXAMPLE.COM Renew until 02/13/15 01:46:23 # lsldap -a passwd ad_user at EXAMPLE.COM dn: uid=ad_user at example.com,cn=users,cn=compat,dc=ux,dc=example,dc=com objectClass: posixAccount objectClass: extensibleObject objectClass: top gecos: ad_user cn: ad_user uidNumber: 1036620735 gidNumber: 1036620735 homeDirectory: /home/example.com/ad_user ipaNTSecurityIdentifier: S-1-5-21-XXXXXXXX-XXXXX-XXXXXX uid: ad_user at example.com # id ad_user at EXAMPLE.COM uid=1036620735(ad_user at example.com) gid=1036620735(ad_user at example.com) groups=1036620733(another_group at example.com) Here I found the first problem: # su - ad_user at EXAMPLE.COM 3004-614 Unable to change directory to "". You are in "/home/guest" instead. $ id uid=1036620735(ad_user at example.com) gid=1036620735(ad_user at example.com) groups=1036620733(another_group at example.com) The "3004-614 Unable to change directory to ""." appears after I added to /etc/methods.cfg: KRB5A: program = /usr/lib/security/KRB5A program_64 = /usr/lib/security/KRB5A_64 options = authonly LDAP: program = /usr/lib/security/LDAP program_64 =/usr/lib/security/LDAP64 Without these lines there is no error "about change to home directory", su from root works smoothly and entered the user to the homedirectory. But now I can't ssh to the system, because I have no correct registry. ----- I made another test: if I can log in by just IPA user, ex. admin. There is no such problem: # id admin uid=30000(admin) gid=30000(admins) # su - admin -bash-3.2$ pwd /export/home/admin -bash-3.2$ id uid=30000(admin) gid=30000(admins) # ssh admin at localhost admin at localhost's password: ******************************************************************************* * * * * * Welcome to AIX Version 7.1! * * * * * * Please see the README file in /usr/lpp/bos for information pertinent to * * this release of the AIX Operating System. * * * * * ******************************************************************************* -bash-3.2$ id uid=30000(admin) gid=30000(admins) Any idea what is wrong? I have already changed the AIX max_logname from 8 to 40 characters. Maybe the "@" character in login name is a problem? Thank you in advance. -- /lm -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Fri Feb 13 08:33:10 2015 From: Less at imagine-sw.com (Les Stott) Date: Fri, 13 Feb 2015 08:33:10 +0000 Subject: [Freeipa-users] bug in pki during install of CA replica and workaround/solution In-Reply-To: <4ED173A868981548967B4FCA27072226280AFA9F@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA27072226280AEAB2@AACMBXP04.exchserver.com> <54D4D23A.5070305@redhat.com> <54D4D552.8000805@redhat.com> <4ED173A868981548967B4FCA27072226280AFA9F@AACMBXP04.exchserver.com> Message-ID: <4ED173A868981548967B4FCA27072226280B8783@AACMBXP04.exchserver.com> > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Les Stott > Sent: Saturday, 7 February 2015 9:39 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] bug in pki during install of CA replica and > workaround/solution > > > > > -----Original Message----- > > From: Endi Sukma Dewata [mailto:edewata at redhat.com] > > Sent: Saturday, 7 February 2015 1:53 AM > > To: Martin Kosek; Les Stott; freeipa-users at redhat.com; Matthew Harmsen > > Subject: Re: [Freeipa-users] bug in pki during install of CA replica > > and workaround/solution > > > > On 2/6/2015 8:39 AM, Martin Kosek wrote: > > >> Reinstalling the pki-selinux rpm (found references in some other > > >> forum > > posts) via yum reinstall pki-selinux is not enough to help. > > >> > > >> The solution is as follows: > > >> > > >> yum downgrade pki-selinux pki-ca pki-common pki-setup pki-silent > > >> pki-java-tools pki-symkey pki-util pki-native-tools which takes > > >> components back to 9.0.3-32 then yum -y update pki-selinux pki-ca > > >> pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util > > >> pki-native-tools then (after cleaning up half installed pki > > >> components) ipa-ca-install > > >> /var/lib/ipa/replica-info-sb1sys02.mydomain.gpg > > >> > > >> Then, the CA replication completes successfully. > > >> > > >> Regards, > > >> > > >> Les > > > > > > I saw this one around, e.g. in: > > > > > > http://www.redhat.com/archives/freeipa-devel/2014- > > May/msg00507.html > > > > > > Did you try reinstalling pki-selinux before ipa-server-install? > > > > > > Endi/Matthew, do we have a bug/fix for this? > > > > > > Thanks, > > > Martin > > > > > > > Yes, we have a ticket for this: > > https://fedorahosted.org/pki/ticket/1243 > > The default selinux-policy is version 3.7.19-231. It needs to be > > updated to at least version 3.7.19-260. > > > > -- > > Endi S. Dewata > > I will test this out (update to 3.7.19-260) next week as I've got a few more CA > replicas to setup. > I'm still having issues. Different one this time. As I have previously worked around the install of CA replicas in my production Production environment as above, I went to setup CA replication in DR (both environments are completely separate). Make sure I did a yum update for all packages, including selinux-policy, and also making sure all needed modules were loaded in httpd.conf I proceeded to retry installation of CA replication. However, it failed with the following: Note: sb2sys01.domain.com is the replica I am trying to install.... (abbreviated below) ############################################# Attempting to connect to: sb2sys01.domain.com:9445 Connected. Posting Query = https://sb2sys01.domain.com:9445//ca/admin/console/config/wizard?p=7&op=next&xml=true&__password=XXXXXXXX&path=ca.p12 RESPONSE STATUS: HTTP/1.1 200 OK RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Content-Type: application/xml;charset=UTF-8 RESPONSE HEADER: Date: Fri, 13 Feb 2015 08:09:35 GMT RESPONSE HEADER: Connection: close admin/console/config/restorekeycertpanel.vm failure The pkcs12 file is not correct. 19 Error in RestoreKeyCertPanel(): updateStatus returns failure ERROR: ConfigureCA: RestoreKeyCertPanel() failure ERROR: unable to create CA ############################################ In /var/log/pki-ca/catalina.out I see... CMS Warning: FAILURE: Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate|FAILURE: authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value| Server is started. Nothing gets populated in /etc/pki-ca/CS.cfg (based on comparison with a working system). grep DirAclAuthz /etc/pki-ca/CS.cfg authz.impl.DirAclAuthz.class=com.netscape.cms.authorization.DirAclAuthz authz.instance.DirAclAuthz.ldap=internaldb authz.instance.DirAclAuthz.pluginName=DirAclAuthz authz.instance.DirAclAuthz.ldap._000=## authz.instance.DirAclAuthz.ldap._001=## Internal Database authz.instance.DirAclAuthz.ldap._002=## authz.instance.DirAclAuthz.ldap.basedn= authz.instance.DirAclAuthz.ldap.maxConns=15 authz.instance.DirAclAuthz.ldap.minConns=3 authz.instance.DirAclAuthz.ldap.ldapauth.authtype=BasicAuth authz.instance.DirAclAuthz.ldap.ldapauth.bindDN=cn=Directory Manager authz.instance.DirAclAuthz.ldap.ldapauth.bindPWPrompt=Internal LDAP Database authz.instance.DirAclAuthz.ldap.ldapauth.clientCertNickname= authz.instance.DirAclAuthz.ldap.ldapconn.host= authz.instance.DirAclAuthz.ldap.ldapconn.port= authz.instance.DirAclAuthz.ldap.ldapconn.secureConn=false authz.instance.DirAclAuthz.ldap.multipleSuffix.enable=false The CA cert looks ok to me on the master. It does get copied to the replica in /usr/share/ipa/html/ca.crt I don't see any errors in httpd error or access logs on the master or the intended replica. The ipa-pki-proxy.conf config has the profilesubmit section. # matches for ee port I can confirm that pki-cad does start (but is unconfigured) and that it does listen on port 9445. # netstat -apn |grep 9445 tcp 0 0 :::9445 :::* LISTEN 31264/java # service pki-cad status pki-ca (pid 31264) is running... [ OK ] 'pki-ca' must still be CONFIGURED! (see /var/log/pki-ca-install.log) I am not sure what to try next. Appreciate any help to get over this error. Thanks, Les From bwp.pearson at gmail.com Fri Feb 13 12:25:06 2015 From: bwp.pearson at gmail.com (Bryan Pearson) Date: Fri, 13 Feb 2015 07:25:06 -0500 Subject: [Freeipa-users] chrony support Message-ID: One of our IPA servers, is in a virtualized environment and is continuously losing time, resulting in invalid credentials and breaking replication. We are interested in using chrony instead of ntpd, while ipa start up and use chrony instead of ntp? Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Fri Feb 13 12:32:40 2015 From: dkupka at redhat.com (David Kupka) Date: Fri, 13 Feb 2015 13:32:40 +0100 Subject: [Freeipa-users] chrony support In-Reply-To: References: Message-ID: <54DDEEE8.40500@redhat.com> Hello Bryan, I'm currently working on this. This feature should be available in freeipa-4.2. -- David Kupka On 02/13/2015 01:25 PM, Bryan Pearson wrote: > One of our IPA servers, is in a virtualized environment and is continuously > losing time, resulting in invalid credentials and breaking replication. > > We are interested in using chrony instead of ntpd, while ipa start up and > use chrony instead of ntp? > > Bryan > > > From mkosek at redhat.com Fri Feb 13 14:01:01 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Feb 2015 15:01:01 +0100 Subject: [Freeipa-users] chrony support In-Reply-To: <54DDEEE8.40500@redhat.com> References: <54DDEEE8.40500@redhat.com> Message-ID: <54DE039D.6080007@redhat.com> On 02/13/2015 01:32 PM, David Kupka wrote: > Hello Bryan, > I'm currently working on this. This feature should be available in freeipa-4.2. Right. Until this is done, you should be anyway able to setup chrony yourself before running ipa-client-install. It would respect your choice (unless you pass --force-ntpd). Martin From bwp.pearson at gmail.com Fri Feb 13 14:18:37 2015 From: bwp.pearson at gmail.com (Bryan Pearson) Date: Fri, 13 Feb 2015 09:18:37 -0500 Subject: [Freeipa-users] chrony support In-Reply-To: <54DE039D.6080007@redhat.com> References: <54DDEEE8.40500@redhat.com> <54DE039D.6080007@redhat.com> Message-ID: Is installing chrony first a requirement or can it be installed after machine has been setup and is running ipa? Bryan On Fri, Feb 13, 2015 at 9:01 AM, Martin Kosek wrote: > On 02/13/2015 01:32 PM, David Kupka wrote: > > Hello Bryan, > > I'm currently working on this. This feature should be available in > freeipa-4.2. > > Right. Until this is done, you should be anyway able to setup chrony > yourself > before running ipa-client-install. It would respect your choice (unless you > pass --force-ntpd). > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Feb 13 14:21:53 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Feb 2015 15:21:53 +0100 Subject: [Freeipa-users] chrony support In-Reply-To: References: <54DDEEE8.40500@redhat.com> <54DE039D.6080007@redhat.com> Message-ID: <54DE0881.8020206@redhat.com> If is not a requirement, but you would need to stop and disable ntpd firs as those 2 services would conflict otherwise. Note that this is still only for clients, servers still require ntpd (subject to change). On 02/13/2015 03:18 PM, Bryan Pearson wrote: > Is installing chrony first a requirement or can it be installed after > machine has been setup and is running ipa? > > Bryan > > On Fri, Feb 13, 2015 at 9:01 AM, Martin Kosek wrote: > >> On 02/13/2015 01:32 PM, David Kupka wrote: >>> Hello Bryan, >>> I'm currently working on this. This feature should be available in >> freeipa-4.2. >> >> Right. Until this is done, you should be anyway able to setup chrony >> yourself >> before running ipa-client-install. It would respect your choice (unless you >> pass --force-ntpd). >> >> Martin >> > From aegelhofer at rubiconproject.com Sat Feb 14 20:52:10 2015 From: aegelhofer at rubiconproject.com (Andrew Egelhofer) Date: Sat, 14 Feb 2015 12:52:10 -0800 Subject: [Freeipa-users] Help with debugging HBACs Message-ID: Hi FreeIPA Users- I've deployed a FreeIPA instance in my Lab, and enrolled a single host, and a single user ('testuser'). The only HBAC rule I currently have is the stock allow_all. Yet, when I attempt to log into the host via ssh, it closes the connection. $ ssh testuser@ Warning: Permanently added ',' (RSA) to the list of known hosts. testuser@'s password: Connection closed by The host I'm attempting to login to can correctly look up the user using getent: # getent passwd testuser testuser:*:168400003:168400003:Test User:/home/testuser:/bin/bash Scanning /var/log/secure, I see these entries: Feb 14 12:01:50 sshd[6528]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.30.3.58 user=testuser Feb 14 12:01:51 sshd[6528]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.30.3.58 user=testuser Feb 14 12:01:51 sshd[6528]: pam_sss(sshd:account): Access denied for user testuser: 6 (Permission denied) That tells me (From reading online) the user / password was correctly authenticated, but failed authorization due to HBAC rules. I've tested the rule using the 'hbactest' utility and it passes [root@ ~]# ipa hbactest --user=testuser --host= --service=sshd -------------------- Access granted: True -------------------- Matched rules: allow_all I'm at a loss here, because If I comment out the line: account [default=bad success=ok user_unknown=ignore] pam_sss.so in /etc/pam.d/system-auth, the user is able to login. So what am I missing here? Is there a way I can debug HBAC rules? I've already set debug_level = 10 in /etc/sssd/sssd.conf, and I see its able to access the HBAC 'allow_all' rule in the log /var/log/sssd/sssd_. .log: (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [sdap_get_generic_done] (7): Total count [0] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_attrs_to_rule] (7): Processing rule [allow_all] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_user_attrs_to_rule] (7): Processing users for rule [allow_all] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_get_category] (5): Category is set to 'all'. (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_service_attrs_to_rule] (7): Processing PAM services for rule [allow_all] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_get_category] (5): Category is set to 'all'. (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_thost_attrs_to_rule] (7): Processing target hosts for rule [allow_all] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_get_category] (5): Category is set to 'all'. (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_shost_attrs_to_rule] (7): Processing source hosts for rule [allow_all] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_host_attrs_to_rule] (4): No host specified, rule will never apply. (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_eval_user_element] (7): [12] groups for [admin] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_eval_user_element] (7): Added group [admins] for user [admin] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=replication administrators,cn=privileges,cn=pbac,dc=,dc=] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=add replication agreements,cn=permissions,cn=pbac,dc=,dc=] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=modify replication agreements,cn=permissions,cn=pbac,dc=,dc=] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=remove replication agreements,cn=permissions,cn=pbac,dc=,dc=] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=host enrollment,cn=privileges,cn=pbac,dc=,dc=] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=manage host keytab,cn=permissions,cn=pbac,dc=,dc=] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=enroll a host,cn=permissions,cn=pbac,dc=,dc=] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=add krbprincipalname to a host,cn=permissions,cn=pbac,dc=,dc=] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=unlock user accounts,cn=permissions,cn=pbac,dc=,dc=] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=manage service keytab,cn=permissions,cn=pbac,dc=,dc=] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_eval_user_element] (7): Added group [trust admins] for user [admin] (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [ipa_hbac_evaluate_rules] (3): Access denied by HBAC rules IPA server: # rpm -q ipa-server sssd ipa-server-3.0.0-42.el6.centos.x86_64 sssd-1.11.6-30.el6_6.3.x86_64 # cat /etc/redhat-release CentOS release 6.5 (Final) Client: # cat /etc/redhat-release CentOS release 5.8 (Final) # rpm -q sssd sssd-1.5.1-49.el5_8.1 Any help is appreciated. Thanks, -Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.raehalme at codecenter.fi Sun Feb 15 20:02:09 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Sun, 15 Feb 2015 22:02:09 +0200 Subject: [Freeipa-users] dirsrv hangs, 0% CPU util Message-ID: Hi! Today we started having problems with dirsrv hanging. We have observed the following symptoms (using EXAMPLE.COM instead of the real domain): /var/log/dirsrv/slapd-EXAMPLE-COM/errors: [15/Feb/2015:21:48:50 +0200] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [15/Feb/2015:21:48:50 +0200] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP server) /var/log/messages: Feb 15 21:49:02 ipa named[5545]: LDAP query timed out. Try to adjust "timeout" parameter Feb 15 21:49:03 ipa named[5545]: LDAP query timed out. Try to adjust "timeout" parameter (repeated) Trying to access the DS also with ldapsearch just hangs: ldapsearch -h localhost -x "dc=example,dc=com" And Kerberos is unavailable as well: # KRB5_TRACE=/dev/stdout kinit admin [6421] 1424029967.466519: Getting initial credentials for admin at EXAMPLE.COM [6421] 1424029967.467202: Sending request (172 bytes) to EXAMPLE.COM [6421] 1424029967.467736: Sending initial UDP request to dgram 10.1.1.1:88 [6421] 1424029968.469031: Initiating TCP connection to stream 10.1.1.1:88 [6421] 1424029968.469205: Sending TCP request to stream 10.1.1.1:88 [6421] 1424029971.472024: Sending retry UDP request to dgram 10.1.1.1:88 [6421] 1424029976.477340: Sending retry UDP request to dgram 10.1.1.1:88 kinit: Cannot contact any KDC for realm 'EXAMPLE.COM' while getting initial credentials Strange thing is that there is hardly any CPU utilization when the problem is occurring. In addition we have started to see the following entries in /var/log/messages: Feb 15 21:37:27 ipa kernel: possible SYN flooding on port 88. Sending cookies. Feb 15 21:39:37 ipa kernel: possible SYN flooding on port 88. Sending cookies. I'm not sure if this is related, but it's something we haven't seen before. We are running CentOS release 6.6 (Final) with the latest available packages: 389-ds-base-libs-1.2.11.15-48.el6_6.x86_64 389-ds-base-1.2.11.15-48.el6_6.x86_64 ipa-client-3.0.0-42.el6.centos.x86_64 ipa-server-selinux-3.0.0-42.el6.centos.x86_64 libipa_hbac-1.11.6-30.el6_6.3.x86_64 sssd-ipa-1.11.6-30.el6_6.3.x86_64 ipa-admintools-3.0.0-42.el6.centos.x86_64 ipa-python-3.0.0-42.el6.centos.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-server-3.0.0-42.el6.centos.x86_64 libipa_hbac-python-1.11.6-30.el6_6.3.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch krb5-workstation-1.10.3-33.el6.x86_64 krb5-libs-1.10.3-33.el6.x86_64 sssd-krb5-common-1.11.6-30.el6_6.3.x86_64 python-krbV-1.0.90-3.el6.x86_64 krb5-server-1.10.3-33.el6.x86_64 sssd-krb5-1.11.6-30.el6_6.3.x86_64 pam_krb5-2.3.11-9.el6.x86_64 Killing the dirsrv processes and restarting them resolves the issue - until it happens again after about 15 minutes. Any idea what could have gone wrong? I can e-mail logs, if necessary. Thank you in advance! Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Sun Feb 15 21:37:50 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Sun, 15 Feb 2015 14:37:50 -0700 Subject: [Freeipa-users] dirsrv hangs, 0% CPU util In-Reply-To: References: Message-ID: <54E111AE.4090600@redhat.com> On 02/15/2015 01:02 PM, Thomas Raehalme wrote: > Hi! > > Today we started having problems with dirsrv hanging. We have observed > the following symptoms (using EXAMPLE.COM instead > of the real domain): > > /var/log/dirsrv/slapd-EXAMPLE-COM/errors: > > [15/Feb/2015:21:48:50 +0200] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint > is not connected) > [15/Feb/2015:21:48:50 +0200] slapi_ldap_bind - Error: could not > perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't > contact LDAP server) > > /var/log/messages: > > Feb 15 21:49:02 ipa named[5545]: LDAP query timed out. Try to adjust > "timeout" parameter > Feb 15 21:49:03 ipa named[5545]: LDAP query timed out. Try to adjust > "timeout" parameter > (repeated) > > Trying to access the DS also with ldapsearch just hangs: > > ldapsearch -h localhost -x "dc=example,dc=com" see http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs > > And Kerberos is unavailable as well: > > # KRB5_TRACE=/dev/stdout kinit admin > [6421] 1424029967.466519: Getting initial credentials for > admin at EXAMPLE.COM > [6421] 1424029967.467202: Sending request (172 bytes) to EXAMPLE.COM > > [6421] 1424029967.467736: Sending initial UDP request to dgram > 10.1.1.1:88 > [6421] 1424029968.469031: Initiating TCP connection to stream > 10.1.1.1:88 > [6421] 1424029968.469205: Sending TCP request to stream 10.1.1.1:88 > > [6421] 1424029971.472024: Sending retry UDP request to dgram > 10.1.1.1:88 > [6421] 1424029976.477340: Sending retry UDP request to dgram > 10.1.1.1:88 > kinit: Cannot contact any KDC for realm 'EXAMPLE.COM > ' while getting initial credentials > > Strange thing is that there is hardly any CPU utilization when the > problem is occurring. > > In addition we have started to see the following entries in > /var/log/messages: > > Feb 15 21:37:27 ipa kernel: possible SYN flooding on port 88. Sending > cookies. > Feb 15 21:39:37 ipa kernel: possible SYN flooding on port 88. Sending > cookies. > > I'm not sure if this is related, but it's something we haven't seen > before. > > We are running CentOS release 6.6 (Final) with the latest available > packages: > > 389-ds-base-libs-1.2.11.15-48.el6_6.x86_64 > 389-ds-base-1.2.11.15-48.el6_6.x86_64 > ipa-client-3.0.0-42.el6.centos.x86_64 > ipa-server-selinux-3.0.0-42.el6.centos.x86_64 > libipa_hbac-1.11.6-30.el6_6.3.x86_64 > sssd-ipa-1.11.6-30.el6_6.3.x86_64 > ipa-admintools-3.0.0-42.el6.centos.x86_64 > ipa-python-3.0.0-42.el6.centos.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-server-3.0.0-42.el6.centos.x86_64 > libipa_hbac-python-1.11.6-30.el6_6.3.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > krb5-workstation-1.10.3-33.el6.x86_64 > krb5-libs-1.10.3-33.el6.x86_64 > sssd-krb5-common-1.11.6-30.el6_6.3.x86_64 > python-krbV-1.0.90-3.el6.x86_64 > krb5-server-1.10.3-33.el6.x86_64 > sssd-krb5-1.11.6-30.el6_6.3.x86_64 > pam_krb5-2.3.11-9.el6.x86_64 > > Killing the dirsrv processes and restarting them resolves the issue - > until it happens again after about 15 minutes. > > Any idea what could have gone wrong? I can e-mail logs, if necessary. > > Thank you in advance! > > Best regards, > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.raehalme at codecenter.fi Sun Feb 15 22:41:11 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Mon, 16 Feb 2015 00:41:11 +0200 Subject: [Freeipa-users] dirsrv hangs, 0% CPU util In-Reply-To: <54E111AE.4090600@redhat.com> References: <54E111AE.4090600@redhat.com> Message-ID: Hi! On Sun, Feb 15, 2015 at 11:37 PM, Rich Megginson wrote: > > Today we started having problems with dirsrv hanging. We have observed > the following symptoms (using EXAMPLE.COM instead of the real domain): > > > see http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs > > Thanks! Please find the stacktrace attached. Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: stacktrace.1424039830.txt.gz Type: application/x-gzip Size: 40573 bytes Desc: not available URL: From rmeggins at redhat.com Sun Feb 15 22:57:08 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Sun, 15 Feb 2015 15:57:08 -0700 Subject: [Freeipa-users] dirsrv hangs, 0% CPU util In-Reply-To: References: <54E111AE.4090600@redhat.com> Message-ID: <54E12444.8090604@redhat.com> On 02/15/2015 03:41 PM, Thomas Raehalme wrote: > Hi! > > On Sun, Feb 15, 2015 at 11:37 PM, Rich Megginson > wrote: > >> >> Today we started having problems with dirsrv hanging. We have >> observed the following symptoms (using EXAMPLE.COM >> instead of the real domain): >> > > see http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs > > > Thanks! Please find the stacktrace attached. Some info missing. Since this is IPA, you'll need some additional debuginfo packages: debuginfo-install ipa-server slapi_nis (or maybe it's slapi-nis) Also looks as though the nspr debuginfo does not match the nspr version. rpm -q nspr nspr-debuginfo Finally, do some stacktraces every couple of seconds over a period of a minute. For example, is the server really hung at the poll() in thread 32, or will the poll() eventually return write ready and proceed? > > Best regards, > Thomas > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.raehalme at codecenter.fi Sun Feb 15 23:04:20 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Mon, 16 Feb 2015 01:04:20 +0200 Subject: [Freeipa-users] dirsrv hangs, 0% CPU util In-Reply-To: <54E12444.8090604@redhat.com> References: <54E111AE.4090600@redhat.com> <54E12444.8090604@redhat.com> Message-ID: On Mon, Feb 16, 2015 at 12:57 AM, Rich Megginson wrote: > Some info missing. Since this is IPA, you'll need some additional > debuginfo packages: debuginfo-install ipa-server slapi_nis (or maybe it's > slapi-nis) > > Also looks as though the nspr debuginfo does not match the nspr version. > rpm -q nspr nspr-debuginfo > I installed only the minimum debuginfo packages mentioned on the link (with yum). Now I have added the ones you mentioned here. > Finally, do some stacktraces every couple of seconds over a period of a > minute. For example, is the server really hung at the poll() in thread 32, > or will the poll() eventually return write ready and proceed? > > Will do. Unfortunately it'll probably not take too long until the next occurrence. Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.raehalme at codecenter.fi Sun Feb 15 23:11:26 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Mon, 16 Feb 2015 01:11:26 +0200 Subject: [Freeipa-users] dirsrv hangs, 0% CPU util In-Reply-To: References: <54E111AE.4090600@redhat.com> <54E12444.8090604@redhat.com> Message-ID: On Mon, Feb 16, 2015 at 1:04 AM, Thomas Raehalme < thomas.raehalme at codecenter.fi> wrote: > > >> Finally, do some stacktraces every couple of seconds over a period of a >> minute. For example, is the server really hung at the poll() in thread 32, >> or will the poll() eventually return write ready and proceed? >> >> > Will do. Unfortunately it'll probably not take too long until the next > occurrence. > Here's a new set of stacktraces from a period of approx 1 minute. I hope the attachment is not too large. Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: stacktrace.zip Type: application/zip Size: 1176363 bytes Desc: not available URL: From abokovoy at redhat.com Mon Feb 16 06:44:43 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 16 Feb 2015 08:44:43 +0200 Subject: [Freeipa-users] dirsrv hangs, 0% CPU util In-Reply-To: References: <54E111AE.4090600@redhat.com> <54E12444.8090604@redhat.com> Message-ID: <20150216064443.GG26748@redhat.com> On Mon, 16 Feb 2015, Thomas Raehalme wrote: >On Mon, Feb 16, 2015 at 1:04 AM, Thomas Raehalme < >thomas.raehalme at codecenter.fi> wrote: > >> >> >>> Finally, do some stacktraces every couple of seconds over a period of a >>> minute. For example, is the server really hung at the poll() in thread 32, >>> or will the poll() eventually return write ready and proceed? >>> >>> >> Will do. Unfortunately it'll probably not take too long until the next >> occurrence. >> > > >Here's a new set of stacktraces from a period of approx 1 minute. I hope >the attachment is not too large. I suspect you've triggered https://fedorahosted.org/freeipa/ticket/4586 and https://fedorahosted.org/freeipa/ticket/4635 -- slapi-nis plugin configuration does not limit itself to $SUFFIX and listens to changes in cn=changelog too so it may deadlock with a replication traffic. We fixed these partly by changing slapi-nis configuration, partly by fixing bugs in 389-ds. I wonder if amending your slapi-nis config to avoid triggering internal searches on cn=changelog would be enough. If you have RHEL subscription, please open a case with Red Hat's support. -- / Alexander Bokovoy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From thomas.raehalme at codecenter.fi Mon Feb 16 08:26:03 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Mon, 16 Feb 2015 10:26:03 +0200 Subject: [Freeipa-users] dirsrv hangs, 0% CPU util In-Reply-To: <20150216064443.GG26748@redhat.com> References: <54E111AE.4090600@redhat.com> <54E12444.8090604@redhat.com> <20150216064443.GG26748@redhat.com> Message-ID: On Mon, Feb 16, 2015 at 8:44 AM, Alexander Bokovoy wrote: > I wonder if amending your slapi-nis config to avoid triggering internal > searches on cn=changelog would be enough. > I can try, but would need some more details, if possible. > > If you have RHEL subscription, please open a case with Red Hat's > support. > Ahh, it's been on my todo list for quite some time now (performing fresh installs of all those CentOS servers isn't something I look forward to). But an order has now been sent, and we'll start with IPA :-) Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Mon Feb 16 08:40:59 2015 From: sbose at redhat.com (Sumit Bose) Date: Mon, 16 Feb 2015 09:40:59 +0100 Subject: [Freeipa-users] Help with debugging HBACs In-Reply-To: References: Message-ID: <20150216084059.GL9695@p.redhat.com> On Sat, Feb 14, 2015 at 12:52:10PM -0800, Andrew Egelhofer wrote: > Hi FreeIPA Users- > > I've deployed a FreeIPA instance in my Lab, and enrolled a single host, and > a single user ('testuser'). The only HBAC rule I currently have is the > stock allow_all. Yet, when I attempt to log into the host via ssh, it > closes the connection. > > $ ssh testuser@ > Warning: Permanently added ',' (RSA) to the list of known > hosts. > testuser@'s password: > Connection closed by > > The host I'm attempting to login to can correctly look up the user using > getent: > > # getent passwd testuser > testuser:*:168400003:168400003:Test User:/home/testuser:/bin/bash > > Scanning /var/log/secure, I see these entries: > > Feb 14 12:01:50 sshd[6528]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.30.3.58 > user=testuser > Feb 14 12:01:51 sshd[6528]: pam_sss(sshd:auth): authentication > success; logname= uid=0 euid=0 tty=ssh ruser= > rhost=172.30.3.58 user=testuser > Feb 14 12:01:51 sshd[6528]: pam_sss(sshd:account): Access denied for > user testuser: 6 (Permission denied) > > That tells me (From reading online) the user / password was correctly > authenticated, but failed authorization due to HBAC rules. I've tested the > rule using the 'hbactest' utility and it passes > > [root@ ~]# ipa hbactest --user=testuser --host= --service=sshd > -------------------- > Access granted: True > -------------------- > Matched rules: allow_all > > I'm at a loss here, because If I comment out the line: > > account [default=bad success=ok user_unknown=ignore] pam_sss.so > > in /etc/pam.d/system-auth, the user is able to login. > > So what am I missing here? Is there a way I can debug HBAC rules? I've > already set debug_level = 10 in /etc/sssd/sssd.conf, and I see its able to > access the HBAC 'allow_all' rule in the log /var/log/sssd/sssd_. > .log: > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [sdap_get_generic_done] (7): Total count [0] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_attrs_to_rule] > (7): Processing rule [allow_all] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_user_attrs_to_rule] (7): Processing users for rule [allow_all] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_get_category] > (5): Category is set to 'all'. > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_service_attrs_to_rule] (7): Processing PAM services for rule > [allow_all] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_get_category] > (5): Category is set to 'all'. > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_thost_attrs_to_rule] (7): Processing target hosts for rule [allow_all] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_get_category] > (5): Category is set to 'all'. > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_shost_attrs_to_rule] (7): Processing source hosts for rule [allow_all] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_host_attrs_to_rule] (4): No host specified, rule will never apply. > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_eval_user_element] (7): [12] groups for [admin] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_eval_user_element] (7): Added group [admins] for user [admin] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=replication > administrators,cn=privileges,cn=pbac,dc=,dc=] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=add > replication agreements,cn=permissions,cn=pbac,dc=,dc=] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=modify > replication agreements,cn=permissions,cn=pbac,dc=,dc=] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=remove > replication agreements,cn=permissions,cn=pbac,dc=,dc=] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=host > enrollment,cn=privileges,cn=pbac,dc=,dc=] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=manage host > keytab,cn=permissions,cn=pbac,dc=,dc=] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=enroll a > host,cn=permissions,cn=pbac,dc=,dc=] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=add > krbprincipalname to a host,cn=permissions,cn=pbac,dc=,dc=] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=unlock user > accounts,cn=permissions,cn=pbac,dc=,dc=] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=manage > service keytab,cn=permissions,cn=pbac,dc=,dc=] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_eval_user_element] (7): Added group [trust admins] for user [admin] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [ipa_hbac_evaluate_rules] (3): Access denied by HBAC rules > > IPA server: > # rpm -q ipa-server sssd > ipa-server-3.0.0-42.el6.centos.x86_64 > sssd-1.11.6-30.el6_6.3.x86_64 > # cat /etc/redhat-release > CentOS release 6.5 (Final) > > Client: > # cat /etc/redhat-release > CentOS release 5.8 (Final) > # rpm -q sssd > sssd-1.5.1-49.el5_8.1 This version is quite old and I guess > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_shost_attrs_to_rule] (7): Processing source hosts for rule [allow_all] > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > [hbac_host_attrs_to_rule] (4): No host specified, rule will never apply. is causing the issue. At that time it was possible to specific source hosts in HBAC rules. But since there is no reliable way to determine the source host (we have to rely on the data libpam is able to give us). we removed this in later versions. If you started with an old IPA server the related attributes are kept during updates, but newer versions like ipa v3 do not set them anymore. First I would recommend to update SSSD. If there is really no wy to update SSSD adding an attribute 'sourceHostCategory: all' to the LDAP object of the allow_all rule might help. HTH bye, Sumit > > Any help is appreciated. > > Thanks, > -Andrew > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From baghery.jone at gmail.com Mon Feb 16 09:29:47 2015 From: baghery.jone at gmail.com (alireza baghery) Date: Mon, 16 Feb 2015 12:59:47 +0330 Subject: [Freeipa-users] ipa replication not working Message-ID: i install IPA on CENTOS 6.5 with Replication when configure every role in IPA, role Copy to Replica but Conversely, it does not work (role from Replica DO not copy to IPA) i do the following: *on server IPA:* #ipa-replica-manage list ipa... master ipareplica...master #ipa-replica-manage list ipa ipareplica.....replica #ipa-replica-masnage list ipareplica ipa...replica *on server ipareplica* #ipa-replica-manage list ipa... master ipareplica...master #ipa-replica-manage list ipa Failed get data from ipa... Can not Contact LDAP Server -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.zin at savoirfairelinux.com Mon Feb 16 09:42:08 2015 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Mon, 16 Feb 2015 04:42:08 -0500 (EST) Subject: [Freeipa-users] resolving subdomain AD in a trust relationship In-Reply-To: <156317855.2628621.1424078970314.JavaMail.root@savoirfairelinux.com> Message-ID: <1308428136.2629541.1424079728427.JavaMail.root@savoirfairelinux.com> Hi, we created a trust relationship with an AD, and we get this result: # ipa trust-domainfind "company.com" Domain name: corp.company.com Domain NetBIOS name: COMPANY Domain Security Identifier: S-1-5-21-blabla-blabla-blabla Domain enabled: True Domain name: company.com Domain NetBIOS name: ROOT Domain Security Identifier: S-1-5-21-blabla2-blabla2-blabla2 Domain enabled: True We manage to see the user from the root domain: id auser at company.com But cannot see a user from the child: id anotheruser at corp.company.com In the logs we see: Could not convert objectSID S-1-5-21-blabla-blabla-blabla-496378] to a UNIX ID I have to add: - it is on a Windows 2008R2 - it is a functional Windows 2003 level AD Any idea? Nicolas Zin nicolas.zin at savoirfairelinux.com Ligne directe: 514-276-5468 poste 135 Fax : 514-276-5465 7275 Saint Urbain Bureau 200 Montr?al, QC, H2R 2Y5 From abokovoy at redhat.com Mon Feb 16 09:50:38 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 16 Feb 2015 11:50:38 +0200 Subject: [Freeipa-users] resolving subdomain AD in a trust relationship In-Reply-To: <1308428136.2629541.1424079728427.JavaMail.root@savoirfairelinux.com> References: <156317855.2628621.1424078970314.JavaMail.root@savoirfairelinux.com> <1308428136.2629541.1424079728427.JavaMail.root@savoirfairelinux.com> Message-ID: <20150216095038.GJ26748@redhat.com> On Mon, 16 Feb 2015, Nicolas Zin wrote: >Hi, > >we created a trust relationship with an AD, and we get this result: ># ipa trust-domainfind "company.com" > Domain name: corp.company.com > Domain NetBIOS name: COMPANY > Domain Security Identifier: S-1-5-21-blabla-blabla-blabla > Domain enabled: True > > Domain name: company.com > Domain NetBIOS name: ROOT > Domain Security Identifier: S-1-5-21-blabla2-blabla2-blabla2 > Domain enabled: True > >We manage to see the user from the root domain: >id auser at company.com > >But cannot see a user from the child: >id anotheruser at corp.company.com > > >In the logs we see: >Could not convert objectSID S-1-5-21-blabla-blabla-blabla-496378] to a UNIX ID RID (496378) is larger than the size of the idrange given for this domain (200000 ids by default). You need to extend idrange for corp.company.com. In Windows world RIDs grow monotonically -- if you delete user, its RID is not reused. When there is large churn of users created/removed, RIDs may go up quickly. For most mid-range companies defaults like IPA has (200000 ids) are fine but if your situation is different, increase the range. Note that idranges for trusted AD domains are not used by DNA plugin as nothing is allocating in this space on the LDAP server side, rather SSSD does allocation on its own, it just needs the idrange reserved. For example, 'ipa idrange-mod --size=1000000' to set the idrange size to one million. Range name for the trusted domain can be seen with 'ipa idrange-find'. -- / Alexander Bokovoy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From mohammadsereshki at yahoo.com Mon Feb 16 10:02:27 2015 From: mohammadsereshki at yahoo.com (mohammad sereshki) Date: Mon, 16 Feb 2015 02:02:27 -0800 Subject: [Freeipa-users] join error Message-ID: <1424080947.19867.YahooMailBasic@web161504.mail.bf1.yahoo.com> hi when I want to add a host to IPA I get below error, My server is centOS, is there anyone to help me? HTTP response code is 401, not 200 ================ stderr= trying to retrieve CA cert via LDAP from ldap://linux126.example.com Existing CA cert and Retrieved CA cert are identical args=/usr/sbin/ipa-join -s linux126.example.com -b dc=mtnirancell,dc=ir -d -h temsdp-smsc1.example.com stdout= stderr=XML-RPC CALL: \r\n \r\n join\r\n \r\n \r\n temsdp-smsc1.example.com\r\n \r\n \r\n nsosversion\r\n 2.6.32-358.el6.x86_64\r\n nshardwareplatform\r\n x86_64\r\n \r\n \r\n \r\n * About to connect() to linux126.example.com port 443 (#0) * Trying 192.168.65.187... * Connected to linux126.example.com (192.168.65.187) port 443 (#0) * Connected to linux126.example.com (192.168.65.187) port 443 (#0) * successfully set certificate verify locations: * CAfile: /etc/ipa/ca.crt CApath: none * SSL connection using AES256-SHA * Server certificate: * subject: O=example.com; CN=linux126.example.com * start date: 2014-12-10 12:38:10 GMT * expire date: 2016-12-10 12:38:10 GMT * common name: linux126.example.com (matched) * issuer: O=example.com; CN=Certificate Authority * SSL certificate verify ok. * Server auth using Basic with user '' > POST /ipa/xml HTTP/1.1 Authorization: Basic Ojo= Host: linux126.example.com Accept: */* Content-Type: text/xml User-Agent: ipa-join/3.0.0 Referer: https://linux126.example.com/ipa/xml X-Original-User-Agent: Xmlrpc-c/1.16.24 Curl/1.1.1 Content-Length: 483 * upload completely sent off: 483 out of 483 bytes < HTTP/1.1 401 Authorization Required < Date: Sun, 15 Feb 2015 12:54:54 GMT < Server: Apache/2.2.15< Last-Modified: Wed, 30 Jan 2013 15:34:41 GMT < ETag: "e24d7-55a-4d4833fadc640" < Accept-Ranges: bytes < Content-Length: 1370 < Connection: close < Content-Type: text/html; charset=UTF-8 < * Closing connection #0 HTTP response code is 401, not 200 Joining realm failed: XML-RPC CALL: \r\n \r\n join\r\n \r\n \r\n temsdp-smsc1.example.com\r\n \r\n \r\n nsosversion\r\n 2.6.32-358.el6.x86_64\r\n nshardwareplatform\r\n x86_64\r\n \r\n \r\n \r\n * About to connect() to linux126.example.com port 443 (#0) * Trying 192.168.65.187... * Connected to linux126.example.com (192.168.65.187) port 443 (#0) * Connected to linux126.example.com (192.168.65.187) port 443 (#0) * successfully set certificate verify locations: * CAfile: /etc/ipa/ca.crt CApath: none * SSL connection using AES256-SHA * Server certificate: * subject: O=example.com; CN=linux126.example.com * start date: 2014-12-10 12:38:10 GMT * expire date: 2016-12-10 12:38:10 GMT * common name: linux126.example.com (matched) * issuer: O=example.com; CN=Certificate Authority * SSL certificate verify ok. * Server auth using Basic with user '' > POST /ipa/xml HTTP/1.1 Authorization: Basic Ojo= Host: linux126.example.com Accept: */* Content-Type: text/xml User-Agent: ipa-join/3.0.0 Referer: https://linux126.example.com/ipa/xml X-Original-User-Agent: Xmlrpc-c/1.16.24 Curl/1.1.1 Content-Length: 483 * upload completely sent off: 483 out of 483 bytes < HTTP/1.1 401 Authorization Required < Date: Sun, 15 Feb 2015 12:54:54 GMT < Server: Apache/2.2.15 < Last-Modified: Wed, 30 Jan 2013 15:34:41 GMT < ETag: "e24d7-55a-4d4833fadc640" < Accept-Ranges: bytes < Content-Length: 1370 < Connection: close < Content-Type: text/html; charset=UTF-8 < * Closing connection #0 HTTP response code is 401, not 200 Installation failed. Rolling back changes. Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' args=ipa-client-automount --uninstall --debug stdout=Restoring configuration From nicolas.zin at savoirfairelinux.com Mon Feb 16 10:37:36 2015 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Mon, 16 Feb 2015 05:37:36 -0500 (EST) Subject: [Freeipa-users] resolving subdomain AD in a trust relationship In-Reply-To: <20150216095038.GJ26748@redhat.com> References: <156317855.2628621.1424078970314.JavaMail.root@savoirfairelinux.com> <1308428136.2629541.1424079728427.JavaMail.root@savoirfairelinux.com> <20150216095038.GJ26748@redhat.com> Message-ID: <1746325772.2636258.1424083056821.JavaMail.root@savoirfairelinux.com> OK seems promising but it stills fail. I used ipa idrange-mod COMPANY.COM_id_range --range-size=10000000 ipa idrange-mod CORP.COMPANY.COM_id_range --range-size=10000000 restarted sssd (and IPA in case of) but still get the same error. Isn't it in sssd.conf that I should set ldap_idmap_range_size? and if yes, in which section? :-( thank you ----- Mail original ----- De: "Alexander Bokovoy" ?: "Nicolas Zin" Cc: freeipa-users at redhat.com, "Francois Cami" Envoy?: Lundi 16 F?vrier 2015 13:50:38 Objet: Re: [Freeipa-users] resolving subdomain AD in a trust relationship On Mon, 16 Feb 2015, Nicolas Zin wrote: >Hi, > >we created a trust relationship with an AD, and we get this result: ># ipa trust-domainfind "company.com" > Domain name: corp.company.com > Domain NetBIOS name: COMPANY > Domain Security Identifier: S-1-5-21-blabla-blabla-blabla > Domain enabled: True > > Domain name: company.com > Domain NetBIOS name: ROOT > Domain Security Identifier: S-1-5-21-blabla2-blabla2-blabla2 > Domain enabled: True > >We manage to see the user from the root domain: >id auser at company.com > >But cannot see a user from the child: >id anotheruser at corp.company.com > > >In the logs we see: >Could not convert objectSID S-1-5-21-blabla-blabla-blabla-496378] to a UNIX ID RID (496378) is larger than the size of the idrange given for this domain (200000 ids by default). You need to extend idrange for corp.company.com. In Windows world RIDs grow monotonically -- if you delete user, its RID is not reused. When there is large churn of users created/removed, RIDs may go up quickly. For most mid-range companies defaults like IPA has (200000 ids) are fine but if your situation is different, increase the range. Note that idranges for trusted AD domains are not used by DNA plugin as nothing is allocating in this space on the LDAP server side, rather SSSD does allocation on its own, it just needs the idrange reserved. For example, 'ipa idrange-mod --size=1000000' to set the idrange size to one million. Range name for the trusted domain can be seen with 'ipa idrange-find'. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Feb 16 10:48:37 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 16 Feb 2015 12:48:37 +0200 Subject: [Freeipa-users] resolving subdomain AD in a trust relationship In-Reply-To: <1746325772.2636258.1424083056821.JavaMail.root@savoirfairelinux.com> References: <156317855.2628621.1424078970314.JavaMail.root@savoirfairelinux.com> <1308428136.2629541.1424079728427.JavaMail.root@savoirfairelinux.com> <20150216095038.GJ26748@redhat.com> <1746325772.2636258.1424083056821.JavaMail.root@savoirfairelinux.com> Message-ID: <20150216104837.GK26748@redhat.com> On Mon, 16 Feb 2015, Nicolas Zin wrote: >OK > >seems promising but it stills fail. >I used >ipa idrange-mod COMPANY.COM_id_range --range-size=10000000 >ipa idrange-mod CORP.COMPANY.COM_id_range --range-size=10000000 > >restarted sssd (and IPA in case of) but still get the same error. SSSD logs would be more helpful (debug_level = 9). >Isn't it in sssd.conf that I should set ldap_idmap_range_size? and if yes, in which section? :-( These options should not be touched at all. -- / Alexander Bokovoy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From mbasti at redhat.com Mon Feb 16 11:05:07 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 16 Feb 2015 12:05:07 +0100 Subject: [Freeipa-users] join error In-Reply-To: <1424080947.19867.YahooMailBasic@web161504.mail.bf1.yahoo.com> References: <1424080947.19867.YahooMailBasic@web161504.mail.bf1.yahoo.com> Message-ID: <54E1CEE3.5070601@redhat.com> On 16/02/15 11:02, mohammad sereshki wrote: > * Server auth using Basic with user '' Hello, It looks like anonymous user. Which version of IPA do you use? Did you specified right user with ability to enroll client? Martin^2 From mkosek at redhat.com Mon Feb 16 12:21:19 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Feb 2015 13:21:19 +0100 Subject: [Freeipa-users] ipa replication not working In-Reply-To: References: Message-ID: <54E1E0BF.1080504@redhat.com> On 02/16/2015 10:29 AM, alireza baghery wrote: > i install IPA on CENTOS 6.5 with Replication > when configure every role in IPA, role Copy to Replica > but Conversely, it does not work (role from Replica DO not copy to IPA) > i do the following: > > *on server IPA:* > #ipa-replica-manage list > ipa... master > ipareplica...master > > #ipa-replica-manage list ipa > ipareplica.....replica > > #ipa-replica-masnage list ipareplica > ipa...replica > > *on server ipareplica* > #ipa-replica-manage list > ipa... master > ipareplica...master > > #ipa-replica-manage list ipa > Failed get data from ipa... Can not Contact LDAP Server > > > Would pointers in this section http://www.freeipa.org/page/Troubleshooting#Replication_issues help? (I updated this section right now) Thanks, Martin From mohammadsereshki at yahoo.com Mon Feb 16 12:51:56 2015 From: mohammadsereshki at yahoo.com (mohammad sereshki) Date: Mon, 16 Feb 2015 12:51:56 +0000 (UTC) Subject: [Freeipa-users] join error In-Reply-To: <54E1CEE3.5070601@redhat.com> References: <54E1CEE3.5070601@redhat.com> Message-ID: <1990224284.2874397.1424091116733.JavaMail.yahoo@mail.yahoo.com> dear I? use ipa-client-3.0.0-42 and I added with ipa-client-install so it asks to enter admin user and password. From: Martin Basti To: mohammad sereshki ; "freeipa-users at redhat.com" Sent: Monday, February 16, 2015 2:35 PM Subject: Re: [Freeipa-users] join error On 16/02/15 11:02, mohammad sereshki wrote: > * Server auth using Basic with user '' Hello, It looks like anonymous user. Which version of IPA do you use? Did you specified right user with ability to enroll client? Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Feb 16 13:10:45 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 16 Feb 2015 08:10:45 -0500 Subject: [Freeipa-users] join error In-Reply-To: <1990224284.2874397.1424091116733.JavaMail.yahoo@mail.yahoo.com> References: <54E1CEE3.5070601@redhat.com> <1990224284.2874397.1424091116733.JavaMail.yahoo@mail.yahoo.com> Message-ID: <54E1EC55.2080804@redhat.com> On 02/16/2015 07:51 AM, mohammad sereshki wrote: > dear > I use ipa-client-3.0.0-42 and I added with ipa-client-install so it > asks to enter admin user and password. Did you change admin user privileges inside IPA? Are you using admin user from IPA or some other local admin account? > > ------------------------------------------------------------------------ > *From:* Martin Basti > *To:* mohammad sereshki ; > "freeipa-users at redhat.com" > *Sent:* Monday, February 16, 2015 2:35 PM > *Subject:* Re: [Freeipa-users] join error > > On 16/02/15 11:02, mohammad sereshki wrote: > > > > > * Server auth using Basic with user '' > > Hello, It looks like anonymous user. > > Which version of IPA do you use? Did you specified right user with > ability to enroll client? > > Martin^2 > > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohammadsereshki at yahoo.com Mon Feb 16 13:19:15 2015 From: mohammadsereshki at yahoo.com (mohammad sereshki) Date: Mon, 16 Feb 2015 13:19:15 +0000 (UTC) Subject: [Freeipa-users] join error In-Reply-To: <54E1CEE3.5070601@redhat.com> References: <54E1CEE3.5070601@redhat.com> Message-ID: <1449457135.7070349.1424092755652.JavaMail.yahoo@mail.yahoo.com> dear I use the admin user, at the same time? I added another server with this permission. From: Martin Basti To: mohammad sereshki ; "freeipa-users at redhat.com" Sent: Monday, February 16, 2015 2:35 PM Subject: Re: [Freeipa-users] join error On 16/02/15 11:02, mohammad sereshki wrote: > * Server auth using Basic with user '' Hello, It looks like anonymous user. Which version of IPA do you use? Did you specified right user with ability to enroll client? Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Feb 16 13:56:48 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 16 Feb 2015 08:56:48 -0500 Subject: [Freeipa-users] join error In-Reply-To: <1449457135.7070349.1424092755652.JavaMail.yahoo@mail.yahoo.com> References: <54E1CEE3.5070601@redhat.com> <1449457135.7070349.1424092755652.JavaMail.yahoo@mail.yahoo.com> Message-ID: <54E1F720.9030502@redhat.com> On 02/16/2015 08:19 AM, mohammad sereshki wrote: > dear > I use the admin user, at the same time I added another server with > this permission. Then the problem is probably with this client. Is everything fine with its host name and DNS lookups? > > ------------------------------------------------------------------------ > *From:* Martin Basti > *To:* mohammad sereshki ; > "freeipa-users at redhat.com" > *Sent:* Monday, February 16, 2015 2:35 PM > *Subject:* Re: [Freeipa-users] join error > > On 16/02/15 11:02, mohammad sereshki wrote: > > > > > * Server auth using Basic with user '' > > Hello, It looks like anonymous user. > > Which version of IPA do you use? Did you specified right user with > ability to enroll client? > > Martin^2 > > > > > -- 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 Feb 16 14:51:00 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Feb 2015 09:51:00 -0500 Subject: [Freeipa-users] join error In-Reply-To: <54E1F720.9030502@redhat.com> References: <54E1CEE3.5070601@redhat.com> <1449457135.7070349.1424092755652.JavaMail.yahoo@mail.yahoo.com> <54E1F720.9030502@redhat.com> Message-ID: <54E203D4.4050908@redhat.com> Dmitri Pal wrote: > On 02/16/2015 08:19 AM, mohammad sereshki wrote: >> dear >> I use the admin user, at the same time I added another server with >> this permission. > > > Then the problem is probably with this client. > Is everything fine with its host name and DNS lookups? I don't think this has anything to do with DNS, the hostname or enrollment privileges. As Martin pointed out, it's odd that Basic auth is being used in this case. The empty value isn't so surprising since with negotiate auth in curl we purposely set it to ":". I think we need to see the full ipaclient-install.log. rob > >> >> ------------------------------------------------------------------------ >> *From:* Martin Basti >> *To:* mohammad sereshki ; >> "freeipa-users at redhat.com" >> *Sent:* Monday, February 16, 2015 2:35 PM >> *Subject:* Re: [Freeipa-users] join error >> >> On 16/02/15 11:02, mohammad sereshki wrote: >> >> >> >> > * Server auth using Basic with user '' >> >> Hello, It looks like anonymous user. >> >> Which version of IPA do you use? Did you specified right user with >> ability to enroll client? >> >> Martin^2 >> >> >> >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > From mohammadsereshki at yahoo.com Mon Feb 16 16:08:31 2015 From: mohammadsereshki at yahoo.com (mohammad sereshki) Date: Mon, 16 Feb 2015 16:08:31 +0000 (UTC) Subject: [Freeipa-users] Freeipa-users Digest, Vol 79, Issue 57 In-Reply-To: References: Message-ID: <1689763168.7316112.1424102911153.JavaMail.yahoo@mail.yahoo.com> hiI found my issue , it was related to "curl" which we complied it and replaced it, now after putting the original one , issue fixed. From: "freeipa-users-request at redhat.com" To: freeipa-users at redhat.com Sent: Monday, February 16, 2015 4:40 PM Subject: Freeipa-users Digest, Vol 79, Issue 57 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. join error (mohammad sereshki) ? 2. Re: resolving subdomain AD in a trust relationship (Nicolas Zin) ? 3. Re: resolving subdomain AD in a trust relationship ? ? ? (Alexander Bokovoy) ? 4. Re: join error (Martin Basti) ? 5. Re: ipa replication not working (Martin Kosek) ? 6. Re: join error (mohammad sereshki) ? 7. Re: join error (Dmitri Pal) ---------------------------------------------------------------------- Message: 1 Date: Mon, 16 Feb 2015 02:02:27 -0800 From: mohammad sereshki To: "freeipa-users at redhat.com" Subject: [Freeipa-users] join error Message-ID: ??? <1424080947.19867.YahooMailBasic at web161504.mail.bf1.yahoo.com> Content-Type: text/plain; charset=us-ascii hi when I want to add a host to IPA I get below error, My server is centOS, is there anyone to help me? HTTP response code is 401, not 200 ================ stderr= trying to retrieve CA cert via LDAP from ldap://linux126.example.com Existing CA cert and Retrieved CA cert are identical args=/usr/sbin/ipa-join -s linux126.example.com -b dc=mtnirancell,dc=ir -d -h temsdp-smsc1.example.com stdout= stderr=XML-RPC CALL: \r\n \r\n join\r\n \r\n \r\n temsdp-smsc1.example.com\r\n \r\n \r\n nsosversion\r\n 2.6.32-358.el6.x86_64\r\n nshardwareplatform\r\n x86_64\r\n \r\n \r\n \r\n * About to connect() to linux126.example.com port 443 (#0) *? Trying 192.168.65.187... * Connected to linux126.example.com (192.168.65.187) port 443 (#0) * Connected to linux126.example.com (192.168.65.187) port 443 (#0) * successfully set certificate verify locations: *? CAfile: /etc/ipa/ca.crt ? CApath: none * SSL connection using AES256-SHA * Server certificate: *? subject: O=example.com; CN=linux126.example.com *? start date: 2014-12-10 12:38:10 GMT *? expire date: 2016-12-10 12:38:10 GMT *? common name: linux126.example.com (matched) *? issuer: O=example.com; CN=Certificate Authority *? SSL certificate verify ok. * Server auth using Basic with user '' > POST /ipa/xml HTTP/1.1 Authorization: Basic Ojo= Host: linux126.example.com Accept: */* Content-Type: text/xml User-Agent: ipa-join/3.0.0 Referer: https://linux126.example.com/ipa/xml X-Original-User-Agent: Xmlrpc-c/1.16.24 Curl/1.1.1 Content-Length: 483? * upload completely sent off: 483 out of 483 bytes < HTTP/1.1 401 Authorization Required < Date: Sun, 15 Feb 2015 12:54:54 GMT < Server: Apache/2.2.15< Last-Modified: Wed, 30 Jan 2013 15:34:41 GMT < ETag: "e24d7-55a-4d4833fadc640" < Accept-Ranges: bytes < Content-Length: 1370 < Connection: close < Content-Type: text/html; charset=UTF-8 \r\n \r\n join\r\n \r\n \r\n temsdp-smsc1.example.com\r\n \r\n \r\n nsosversion\r\n 2.6.32-358.el6.x86_64\r\n nshardwareplatform\r\n x86_64\r\n \r\n \r\n \r\n * About to connect() to linux126.example.com port 443 (#0) *? Trying 192.168.65.187... * Connected to linux126.example.com (192.168.65.187) port 443 (#0) * Connected to linux126.example.com (192.168.65.187) port 443 (#0) * successfully set certificate verify locations: *? CAfile: /etc/ipa/ca.crt ? CApath: none * SSL connection using AES256-SHA * Server certificate: *? subject: O=example.com; CN=linux126.example.com *? start date: 2014-12-10 12:38:10 GMT *? expire date: 2016-12-10 12:38:10 GMT *? common name: linux126.example.com (matched) *? issuer: O=example.com; CN=Certificate Authority *? SSL certificate verify ok. * Server auth using Basic with user '' > POST /ipa/xml HTTP/1.1 Authorization: Basic Ojo= Host: linux126.example.com Accept: */* Content-Type: text/xml User-Agent: ipa-join/3.0.0 Referer: https://linux126.example.com/ipa/xml X-Original-User-Agent: Xmlrpc-c/1.16.24 Curl/1.1.1 Content-Length: 483? * upload completely sent off: 483 out of 483 bytes < HTTP/1.1 401 Authorization Required < Date: Sun, 15 Feb 2015 12:54:54 GMT < Server: Apache/2.2.15? < Last-Modified: Wed, 30 Jan 2013 15:34:41 GMT < ETag: "e24d7-55a-4d4833fadc640" < Accept-Ranges: bytes < Content-Length: 1370 < Connection: close < Content-Type: text/html; charset=UTF-8 To: Alexander Bokovoy Cc: Francois Cami , freeipa-users at redhat.com Subject: Re: [Freeipa-users] resolving subdomain AD in a trust ??? relationship Message-ID: ??? <1746325772.2636258.1424083056821.JavaMail.root at savoirfairelinux.com> Content-Type: text/plain; charset=utf-8 OK seems promising but it stills fail. I used ipa idrange-mod COMPANY.COM_id_range --range-size=10000000 ipa idrange-mod CORP.COMPANY.COM_id_range --range-size=10000000 restarted sssd (and IPA in case of) but still get the same error. Isn't it in sssd.conf that I should set ldap_idmap_range_size? and if yes, in which section? :-( thank you ----- Mail original ----- De: "Alexander Bokovoy" ?: "Nicolas Zin" Cc: freeipa-users at redhat.com, "Francois Cami" Envoy?: Lundi 16 F?vrier 2015 13:50:38 Objet: Re: [Freeipa-users] resolving subdomain AD in a trust relationship On Mon, 16 Feb 2015, Nicolas Zin wrote: >Hi, > >we created a trust relationship with an AD, and we get this result: ># ipa trust-domainfind "company.com" >? Domain name: corp.company.com >? Domain NetBIOS name: COMPANY >? Domain Security Identifier: S-1-5-21-blabla-blabla-blabla >? Domain enabled: True > >? Domain name: company.com >? Domain NetBIOS name: ROOT >? Domain Security Identifier: S-1-5-21-blabla2-blabla2-blabla2 >? Domain enabled: True > >We manage to see the user from the root domain: >id auser at company.com > >But cannot see a user from the child: >id anotheruser at corp.company.com > > >In the logs we see: >Could not convert objectSID S-1-5-21-blabla-blabla-blabla-496378] to a UNIX ID RID (496378) is larger than the size of the idrange given for this domain (200000 ids by default). You need to extend idrange for corp.company.com. In Windows world RIDs grow monotonically -- if you delete user, its RID is not reused. When there is large churn of users created/removed, RIDs may go up quickly. For most mid-range companies defaults like IPA has (200000 ids) are fine but if your situation is different, increase the range. Note that idranges for trusted AD domains are not used by DNA plugin as nothing is allocating in this space on the LDAP server side, rather SSSD does allocation on its own, it just needs the idrange reserved. For example,? 'ipa idrange-mod --size=1000000' to set the idrange size to one million.? Range name for the trusted domain can be seen with 'ipa idrange-find'. -- / Alexander Bokovoy ------------------------------ Message: 3 Date: Mon, 16 Feb 2015 12:48:37 +0200 From: Alexander Bokovoy To: Nicolas Zin Cc: Francois Cami , freeipa-users at redhat.com Subject: Re: [Freeipa-users] resolving subdomain AD in a trust ??? relationship Message-ID: <20150216104837.GK26748 at redhat.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" On Mon, 16 Feb 2015, Nicolas Zin wrote: >OK > >seems promising but it stills fail. >I used >ipa idrange-mod COMPANY.COM_id_range --range-size=10000000 >ipa idrange-mod CORP.COMPANY.COM_id_range --range-size=10000000 > >restarted sssd (and IPA in case of) but still get the same error. SSSD logs would be more helpful (debug_level = 9). >Isn't it in sssd.conf that I should set ldap_idmap_range_size? and if yes, in which section? :-( These options should not be touched at all. -- / Alexander Bokovoy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: not available URL: ------------------------------ Message: 4 Date: Mon, 16 Feb 2015 12:05:07 +0100 From: Martin Basti To: mohammad sereshki , ??? "freeipa-users at redhat.com" Subject: Re: [Freeipa-users] join error Message-ID: <54E1CEE3.5070601 at redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed On 16/02/15 11:02, mohammad sereshki wrote: > * Server auth using Basic with user '' Hello, It looks like anonymous user. Which version of IPA do you use? Did you specified right user with ability to enroll client? Martin^2 ------------------------------ Message: 5 Date: Mon, 16 Feb 2015 13:21:19 +0100 From: Martin Kosek To: alireza baghery , ??? "freeipa-users at redhat.com" Subject: Re: [Freeipa-users] ipa replication not working Message-ID: <54E1E0BF.1080504 at redhat.com> Content-Type: text/plain; charset=windows-1252 On 02/16/2015 10:29 AM, alireza baghery wrote: > i install IPA on CENTOS 6.5 with Replication > when configure every role in IPA, role Copy to Replica > but Conversely, it does not work (role from Replica DO not copy to IPA) > i do the following: > > *on server IPA:* >? #ipa-replica-manage list >? ipa... master >? ipareplica...master > > #ipa-replica-manage list ipa > ipareplica.....replica > > #ipa-replica-masnage list ipareplica > ipa...replica > > *on server ipareplica* > #ipa-replica-manage list > ipa... master >? ipareplica...master > > #ipa-replica-manage list ipa > Failed get data from ipa... Can not Contact LDAP Server > > > Would pointers in this section http://www.freeipa.org/page/Troubleshooting#Replication_issues help? (I updated this section right now) Thanks, Martin ------------------------------ Message: 6 Date: Mon, 16 Feb 2015 12:51:56 +0000 (UTC) From: mohammad sereshki To: Martin Basti ,??? "freeipa-users at redhat.com" ??? Subject: Re: [Freeipa-users] join error Message-ID: ??? <1990224284.2874397.1424091116733.JavaMail.yahoo at mail.yahoo.com> Content-Type: text/plain; charset="utf-8" dear I? use ipa-client-3.0.0-42 and I added with ipa-client-install so it asks to enter admin user and password. ? ? ? From: Martin Basti To: mohammad sereshki ; "freeipa-users at redhat.com" Sent: Monday, February 16, 2015 2:35 PM Subject: Re: [Freeipa-users] join error ? On 16/02/15 11:02, mohammad sereshki wrote: > * Server auth using Basic with user '' Hello, It looks like anonymous user. Which version of IPA do you use? Did you specified right user with ability to enroll client? Martin^2 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 7 Date: Mon, 16 Feb 2015 08:10:45 -0500 From: Dmitri Pal To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] join error Message-ID: <54E1EC55.2080804 at redhat.com> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" On 02/16/2015 07:51 AM, mohammad sereshki wrote: > dear > I? use ipa-client-3.0.0-42 and I added with ipa-client-install so it > asks to enter admin user and password. Did you change admin user privileges inside IPA? Are you using admin user from IPA or some other local admin account? > > ------------------------------------------------------------------------ > *From:* Martin Basti > *To:* mohammad sereshki ; > "freeipa-users at redhat.com" > *Sent:* Monday, February 16, 2015 2:35 PM > *Subject:* Re: [Freeipa-users] join error > > On 16/02/15 11:02, mohammad sereshki wrote: > > > > > * Server auth using Basic with user '' > > Hello, It looks like anonymous user. > > Which version of IPA do you use? Did you specified right user with > ability to enroll client? > > Martin^2 > > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users End of Freeipa-users Digest, Vol 79, Issue 57 ********************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Feb 16 16:40:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 16 Feb 2015 17:40:21 +0100 Subject: [Freeipa-users] join error [solved] In-Reply-To: <54E203D4.4050908@redhat.com> References: <54E1CEE3.5070601@redhat.com> <1449457135.7070349.1424092755652.JavaMail.yahoo@mail.yahoo.com> <54E1F720.9030502@redhat.com> <54E203D4.4050908@redhat.com> Message-ID: <54E21D75.9020708@redhat.com> On 16/02/15 15:51, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 02/16/2015 08:19 AM, mohammad sereshki wrote: >>> dear >>> I use the admin user, at the same time I added another server with >>> this permission. >> >> Then the problem is probably with this client. >> Is everything fine with its host name and DNS lookups? > I don't think this has anything to do with DNS, the hostname or > enrollment privileges. As Martin pointed out, it's odd that Basic auth > is being used in this case. The empty value isn't so surprising since > with negotiate auth in curl we purposely set it to ":". > > I think we need to see the full ipaclient-install.log. > > rob For record: Mohammad had his own compiled curl, which doesn't work with IPA. It works with the original one. Martin^2 >>> ------------------------------------------------------------------------ >>> *From:* Martin Basti >>> *To:* mohammad sereshki ; >>> "freeipa-users at redhat.com" >>> *Sent:* Monday, February 16, 2015 2:35 PM >>> *Subject:* Re: [Freeipa-users] join error >>> >>> On 16/02/15 11:02, mohammad sereshki wrote: >>> >>> >>> >>>> * Server auth using Basic with user '' >>> Hello, It looks like anonymous user. >>> >>> Which version of IPA do you use? Did you specified right user with >>> ability to enroll client? >>> >>> Martin^2 >>> >>> >>> >>> >>> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> -- Martin Basti From david.little2 at gmail.com Mon Feb 16 16:32:19 2015 From: david.little2 at gmail.com (David Little) Date: Mon, 16 Feb 2015 11:32:19 -0500 Subject: [Freeipa-users] Typo on Troubleshooting page Message-ID: Hi there, There's a typo here -> http://www.freeipa.org/page/Troubleshooting The word "error" is spell incorrectly in this sentence: "If changes done on one FreeIPA master are not replicated to another master, always verify errros log on both master and replica." Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Feb 16 18:28:22 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 16 Feb 2015 19:28:22 +0100 Subject: [Freeipa-users] Typo on Troubleshooting page In-Reply-To: References: Message-ID: <54E236C6.4020508@redhat.com> On 16/02/15 17:32, David Little wrote: > Hi there, > > There's a typo here -> http://www.freeipa.org/page/Troubleshooting > > The word "error" is spell incorrectly in this sentence: > > "If changes done on one FreeIPA master are not replicated to another > master, always verify errros log on both master and replica." > > > Thanks, > Dave > > Thank you, fixed. -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From aegelhofer at rubiconproject.com Mon Feb 16 20:32:34 2015 From: aegelhofer at rubiconproject.com (Andrew Egelhofer) Date: Mon, 16 Feb 2015 12:32:34 -0800 Subject: [Freeipa-users] Help with debugging HBACs In-Reply-To: <20150216084059.GL9695@p.redhat.com> References: <20150216084059.GL9695@p.redhat.com> Message-ID: ?Thank you for the reply Sumit - I will look into updating the version of sssd. If that doesn't work, I will also try adding the ?'sourceHostCategory' attribute to rules. Though, I would imagine I would have to do this for *all* rules if I want them to work as intended. I'll report back my findings tomorrow. Thanks, -Andrew On Mon, Feb 16, 2015 at 12:40 AM, Sumit Bose wrote: > On Sat, Feb 14, 2015 at 12:52:10PM -0800, Andrew Egelhofer wrote: > > Hi FreeIPA Users- > > > > I've deployed a FreeIPA instance in my Lab, and enrolled a single host, > and > > a single user ('testuser'). The only HBAC rule I currently have is the > > stock allow_all. Yet, when I attempt to log into the host via ssh, it > > closes the connection. > > > > $ ssh testuser@ > > Warning: Permanently added ',' (RSA) to the list of known > > hosts. > > testuser@'s password: > > Connection closed by > > > > The host I'm attempting to login to can correctly look up the user using > > getent: > > > > # getent passwd testuser > > testuser:*:168400003:168400003:Test User:/home/testuser:/bin/bash > > > > Scanning /var/log/secure, I see these entries: > > > > Feb 14 12:01:50 sshd[6528]: pam_unix(sshd:auth): authentication > > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.30.3.58 > > user=testuser > > Feb 14 12:01:51 sshd[6528]: pam_sss(sshd:auth): authentication > > success; logname= uid=0 euid=0 tty=ssh ruser= > > rhost=172.30.3.58 user=testuser > > Feb 14 12:01:51 sshd[6528]: pam_sss(sshd:account): Access denied > for > > user testuser: 6 (Permission denied) > > > > That tells me (From reading online) the user / password was correctly > > authenticated, but failed authorization due to HBAC rules. I've tested > the > > rule using the 'hbactest' utility and it passes > > > > [root@ ~]# ipa hbactest --user=testuser --host= > --service=sshd > > -------------------- > > Access granted: True > > -------------------- > > Matched rules: allow_all > > > > I'm at a loss here, because If I comment out the line: > > > > account [default=bad success=ok user_unknown=ignore] pam_sss.so > > > > in /etc/pam.d/system-auth, the user is able to login. > > > > So what am I missing here? Is there a way I can debug HBAC rules? I've > > already set debug_level = 10 in /etc/sssd/sssd.conf, and I see its able > to > > access the HBAC 'allow_all' rule in the log > /var/log/sssd/sssd_. > > .log: > > > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [sdap_get_generic_done] (7): Total count [0] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_attrs_to_rule] > > (7): Processing rule [allow_all] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_user_attrs_to_rule] (7): Processing users for rule [allow_all] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_get_category] > > (5): Category is set to 'all'. > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_service_attrs_to_rule] (7): Processing PAM services for rule > > [allow_all] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_get_category] > > (5): Category is set to 'all'. > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_thost_attrs_to_rule] (7): Processing target hosts for rule > [allow_all] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_get_category] > > (5): Category is set to 'all'. > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_shost_attrs_to_rule] (7): Processing source hosts for rule > [allow_all] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_host_attrs_to_rule] (4): No host specified, rule will never apply. > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_eval_user_element] (7): [12] groups for [admin] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_eval_user_element] (7): Added group [admins] for user [admin] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=replication > > administrators,cn=privileges,cn=pbac,dc=,dc=] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=add > > replication agreements,cn=permissions,cn=pbac,dc=,dc=] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=modify > > replication agreements,cn=permissions,cn=pbac,dc=,dc=] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=remove > > replication agreements,cn=permissions,cn=pbac,dc=,dc=] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=host > > enrollment,cn=privileges,cn=pbac,dc=,dc=] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=manage host > > keytab,cn=permissions,cn=pbac,dc=,dc=] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=enroll a > > host,cn=permissions,cn=pbac,dc=,dc=] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=add > > krbprincipalname to a host,cn=permissions,cn=pbac,dc=,dc=] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=unlock user > > accounts,cn=permissions,cn=pbac,dc=,dc=] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=manage > > service keytab,cn=permissions,cn=pbac,dc=,dc=] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_eval_user_element] (7): Added group [trust admins] for user [admin] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [ipa_hbac_evaluate_rules] (3): Access denied by HBAC rules > > > > IPA server: > > # rpm -q ipa-server sssd > > ipa-server-3.0.0-42.el6.centos.x86_64 > > sssd-1.11.6-30.el6_6.3.x86_64 > > # cat /etc/redhat-release > > CentOS release 6.5 (Final) > > > > Client: > > # cat /etc/redhat-release > > CentOS release 5.8 (Final) > > # rpm -q sssd > > sssd-1.5.1-49.el5_8.1 > > This version is quite old and I guess > > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_shost_attrs_to_rule] (7): Processing source hosts for rule [allow_all] > > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > [hbac_host_attrs_to_rule] (4): No host specified, rule will never apply. > > is causing the issue. At that time it was possible to specific source > hosts in HBAC rules. But since there is no reliable way to determine > the source host (we have to rely on the data libpam is able to give us). > we removed this in later versions. If you started with an old IPA server > the related attributes are kept during updates, but newer versions like > ipa v3 do not set them anymore. > > First I would recommend to update SSSD. If there is really no wy to > update SSSD adding an attribute 'sourceHostCategory: all' to the LDAP > object of the allow_all rule might help. > > HTH > > bye, > Sumit > > > > Any help is appreciated. > > > > Thanks, > > -Andrew > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go To http://freeipa.org for more info on the project > > -- Andrew "Ego" Egelhofer Infrastructure Systems Engineer | Rubicon Project aegelhofer at rubiconproject.com | 831-331-7915 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Mon Feb 16 21:24:13 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 16 Feb 2015 21:24:13 +0000 Subject: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. In-Reply-To: References: <20150216084059.GL9695@p.redhat.com>, Message-ID: <1424121712790.33539@vuw.ac.nz> While attempting to initialise the new server I am getting, [root at xx replica-files]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 --no-reverse replica-info-xxx.gpg --skip-conncheck --debug =====8><---- packages/ipaserver/install/plugins/update_uniqueness.py' ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' ipa.ipaserver.install.installutils: DEBUG group dirsrv exists ipa.ipaserver.install.installutils: DEBUG user dirsrv exists ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Created connection context.ldap2_59928528 ipa.ipapython.ipaldap.SchemaCache: DEBUG flushing ldaps://vuwunicoipam002.ods.vuw.ac.nz from SchemaCache ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldaps://vuwunicoipam002.ods.vuw.ac.nz conn= error copying files: failed to decode certificate: (SEC_ERROR_LIBRARY_FAILURE) security library failure. ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Destroyed connection context.ldap2_59928528 ipa : DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script return_value = main_function() File "/sbin/ipa-replica-install", line 658, in main install_ca_cert(conn, api.env.basedn, api.env.realm, cafile) File "/sbin/ipa-replica-install", line 227, in install_ca_cert sys.exit(1) ipa : DEBUG The ipa-replica-install command failed, exception: SystemExit: 1 ======== Any idea what is wrong please? regards Steven J -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Feb 16 21:40:50 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Feb 2015 16:40:50 -0500 Subject: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. In-Reply-To: <1424121712790.33539@vuw.ac.nz> References: <20150216084059.GL9695@p.redhat.com>, <1424121712790.33539@vuw.ac.nz> Message-ID: <54E263E2.4000307@redhat.com> Steven Jones wrote: > While attempting to initialise the new server I am getting, > > > [root at xx replica-files]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 --no-reverse replica-info-xxx.gpg --skip-conncheck --debug > > > =====8><---- > packages/ipaserver/install/plugins/update_uniqueness.py' > ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' > ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' > ipa.ipaserver.install.installutils: DEBUG group dirsrv exists > ipa.ipaserver.install.installutils: DEBUG user dirsrv exists > ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Created connection context.ldap2_59928528 > ipa.ipapython.ipaldap.SchemaCache: DEBUG flushing ldaps://vuwunicoipam002.ods.vuw.ac.nz from SchemaCache > ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldaps://vuwunicoipam002.ods.vuw.ac.nz conn= > error copying files: failed to decode certificate: (SEC_ERROR_LIBRARY_FAILURE) security library failure. > ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Destroyed connection context.ldap2_59928528 > ipa : DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script > return_value = main_function() > > File "/sbin/ipa-replica-install", line 658, in main > install_ca_cert(conn, api.env.basedn, api.env.realm, cafile) > > File "/sbin/ipa-replica-install", line 227, in install_ca_cert > sys.exit(1) > > ipa : DEBUG The ipa-replica-install command failed, exception: SystemExit: 1 > > ======== > > > Any idea what is wrong please? What a strange error. My initial thought was that it couldn't read or parse the CA cert from the 3.0 master, but this security library error is unexpected. I might be sending you on a wild goose chase but take a look at the CA cert in cn=CAcert,cn=ipa,cn=etc,$SUFFIX There was a bug quite a while back where the cert value was double-base64-encoded. I wouldn't expect this error from this problem but who knows. rob From Steven.Jones at vuw.ac.nz Mon Feb 16 21:43:06 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 16 Feb 2015 21:43:06 +0000 Subject: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. In-Reply-To: <54E263E2.4000307@redhat.com> References: <20150216084059.GL9695@p.redhat.com>, <1424121712790.33539@vuw.ac.nz>,<54E263E2.4000307@redhat.com> Message-ID: <1424122845959.41100@vuw.ac.nz> Hi, I have no idea how. regards Steven ________________________________________ From: Rob Crittenden Sent: Tuesday, 17 February 2015 10:40 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. Steven Jones wrote: > While attempting to initialise the new server I am getting, > > > [root at xx replica-files]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 --no-reverse replica-info-xxx.gpg --skip-conncheck --debug > > > =====8><---- > packages/ipaserver/install/plugins/update_uniqueness.py' > ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' > ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' > ipa.ipaserver.install.installutils: DEBUG group dirsrv exists > ipa.ipaserver.install.installutils: DEBUG user dirsrv exists > ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Created connection context.ldap2_59928528 > ipa.ipapython.ipaldap.SchemaCache: DEBUG flushing ldaps://vuwunicoipam002.ods.vuw.ac.nz from SchemaCache > ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldaps://vuwunicoipam002.ods.vuw.ac.nz conn= > error copying files: failed to decode certificate: (SEC_ERROR_LIBRARY_FAILURE) security library failure. > ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Destroyed connection context.ldap2_59928528 > ipa : DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script > return_value = main_function() > > File "/sbin/ipa-replica-install", line 658, in main > install_ca_cert(conn, api.env.basedn, api.env.realm, cafile) > > File "/sbin/ipa-replica-install", line 227, in install_ca_cert > sys.exit(1) > > ipa : DEBUG The ipa-replica-install command failed, exception: SystemExit: 1 > > ======== > > > Any idea what is wrong please? What a strange error. My initial thought was that it couldn't read or parse the CA cert from the 3.0 master, but this security library error is unexpected. I might be sending you on a wild goose chase but take a look at the CA cert in cn=CAcert,cn=ipa,cn=etc,$SUFFIX There was a bug quite a while back where the cert value was double-base64-encoded. I wouldn't expect this error from this problem but who knows. rob From rcritten at redhat.com Mon Feb 16 21:59:03 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Feb 2015 16:59:03 -0500 Subject: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. In-Reply-To: <1424122845959.41100@vuw.ac.nz> References: <20150216084059.GL9695@p.redhat.com>, <1424121712790.33539@vuw.ac.nz>, <54E263E2.4000307@redhat.com> <1424122845959.41100@vuw.ac.nz> Message-ID: <54E26827.70902@redhat.com> Steven Jones wrote: > Hi, > > I have no idea how. $ kinit admin $ ldapsearch -Y GSSAPI -b cn=CAcert,cn=ipa,cn=etc,$SUFFIX It should have an attribuete cACertificate;binary likely beginning with MII. If it begins with TU then it is likely double-encoded. And remember, this may be a red herring. rob > > regards > > Steven > ________________________________________ > From: Rob Crittenden > Sent: Tuesday, 17 February 2015 10:40 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. > > Steven Jones wrote: >> While attempting to initialise the new server I am getting, >> >> >> [root at xx replica-files]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 --no-reverse replica-info-xxx.gpg --skip-conncheck --debug >> >> >> =====8><---- >> packages/ipaserver/install/plugins/update_uniqueness.py' >> ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' >> ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' >> ipa.ipaserver.install.installutils: DEBUG group dirsrv exists >> ipa.ipaserver.install.installutils: DEBUG user dirsrv exists >> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Created connection context.ldap2_59928528 >> ipa.ipapython.ipaldap.SchemaCache: DEBUG flushing ldaps://vuwunicoipam002.ods.vuw.ac.nz from SchemaCache >> ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldaps://vuwunicoipam002.ods.vuw.ac.nz conn= >> error copying files: failed to decode certificate: (SEC_ERROR_LIBRARY_FAILURE) security library failure. >> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Destroyed connection context.ldap2_59928528 >> ipa : DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script >> return_value = main_function() >> >> File "/sbin/ipa-replica-install", line 658, in main >> install_ca_cert(conn, api.env.basedn, api.env.realm, cafile) >> >> File "/sbin/ipa-replica-install", line 227, in install_ca_cert >> sys.exit(1) >> >> ipa : DEBUG The ipa-replica-install command failed, exception: SystemExit: 1 >> >> ======== >> >> >> Any idea what is wrong please? > > What a strange error. My initial thought was that it couldn't read or > parse the CA cert from the 3.0 master, but this security library error > is unexpected. > > I might be sending you on a wild goose chase but take a look at the CA > cert in cn=CAcert,cn=ipa,cn=etc,$SUFFIX > > There was a bug quite a while back where the cert value was > double-base64-encoded. I wouldn't expect this error from this problem > but who knows. > > rob > From Steven.Jones at vuw.ac.nz Mon Feb 16 22:46:14 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 16 Feb 2015 22:46:14 +0000 Subject: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. In-Reply-To: <54E26827.70902@redhat.com> References: <20150216084059.GL9695@p.redhat.com>, <1424121712790.33539@vuw.ac.nz>,<54E263E2.4000307@redhat.com> <1424122845959.41100@vuw.ac.nz>,<54E26827.70902@redhat.com> Message-ID: <1424126634379.52393@vuw.ac.nz> ? ==== [root at xx ipa]# ldapsearch -Y GSSAPI -b cn=CAcert,cn=ipa,cn=etc,$SUFFIX SASL/GSSAPI authentication started SASL username: xxxx SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 4 result: 32 No such object # numResponses: 1 ==== regards Steven ________________________________________ From: Rob Crittenden Sent: Tuesday, 17 February 2015 10:59 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. Steven Jones wrote: > Hi, > > I have no idea how. $ kinit admin $ ldapsearch -Y GSSAPI -b cn=CAcert,cn=ipa,cn=etc,$SUFFIX It should have an attribuete cACertificate;binary likely beginning with MII. If it begins with TU then it is likely double-encoded. And remember, this may be a red herring. rob > > regards > > Steven > ________________________________________ > From: Rob Crittenden > Sent: Tuesday, 17 February 2015 10:40 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. > > Steven Jones wrote: >> While attempting to initialise the new server I am getting, >> >> >> [root at xx replica-files]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 --no-reverse replica-info-xxx.gpg --skip-conncheck --debug >> >> >> =====8><---- >> packages/ipaserver/install/plugins/update_uniqueness.py' >> ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' >> ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' >> ipa.ipaserver.install.installutils: DEBUG group dirsrv exists >> ipa.ipaserver.install.installutils: DEBUG user dirsrv exists >> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Created connection context.ldap2_59928528 >> ipa.ipapython.ipaldap.SchemaCache: DEBUG flushing ldaps://vuwunicoipam002.ods.vuw.ac.nz from SchemaCache >> ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldaps://vuwunicoipam002.ods.vuw.ac.nz conn= >> error copying files: failed to decode certificate: (SEC_ERROR_LIBRARY_FAILURE) security library failure. >> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Destroyed connection context.ldap2_59928528 >> ipa : DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script >> return_value = main_function() >> >> File "/sbin/ipa-replica-install", line 658, in main >> install_ca_cert(conn, api.env.basedn, api.env.realm, cafile) >> >> File "/sbin/ipa-replica-install", line 227, in install_ca_cert >> sys.exit(1) >> >> ipa : DEBUG The ipa-replica-install command failed, exception: SystemExit: 1 >> >> ======== >> >> >> Any idea what is wrong please? > > What a strange error. My initial thought was that it couldn't read or > parse the CA cert from the 3.0 master, but this security library error > is unexpected. > > I might be sending you on a wild goose chase but take a look at the CA > cert in cn=CAcert,cn=ipa,cn=etc,$SUFFIX > > There was a bug quite a while back where the cert value was > double-base64-encoded. I wouldn't expect this error from this problem > but who knows. > > rob > From rcritten at redhat.com Mon Feb 16 23:08:54 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Feb 2015 18:08:54 -0500 Subject: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. In-Reply-To: <1424126634379.52393@vuw.ac.nz> References: <20150216084059.GL9695@p.redhat.com>, <1424121712790.33539@vuw.ac.nz>, <54E263E2.4000307@redhat.com> <1424122845959.41100@vuw.ac.nz>, <54E26827.70902@redhat.com> <1424126634379.52393@vuw.ac.nz> Message-ID: <54E27886.9080902@redhat.com> Steven Jones wrote: > ? > > ==== > [root at xx ipa]# ldapsearch -Y GSSAPI -b cn=CAcert,cn=ipa,cn=etc,$SUFFIX > SASL/GSSAPI authentication started > SASL username: xxxx > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # search result > search: 4 > result: 32 No such object > > # numResponses: 1 Did you literally use $SUFFIX? You need to use dc=example,dc=com, whatever is appropriate for your install. rob > > ==== > > regards > > Steven > ________________________________________ > From: Rob Crittenden > Sent: Tuesday, 17 February 2015 10:59 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. > > Steven Jones wrote: >> Hi, >> >> I have no idea how. > > $ kinit admin > $ ldapsearch -Y GSSAPI -b cn=CAcert,cn=ipa,cn=etc,$SUFFIX > > It should have an attribuete cACertificate;binary likely beginning with > MII. If it begins with TU then it is likely double-encoded. > > And remember, this may be a red herring. > > rob > >> >> regards >> >> Steven >> ________________________________________ >> From: Rob Crittenden >> Sent: Tuesday, 17 February 2015 10:40 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. >> >> Steven Jones wrote: >>> While attempting to initialise the new server I am getting, >>> >>> >>> [root at xx replica-files]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 --no-reverse replica-info-xxx.gpg --skip-conncheck --debug >>> >>> >>> =====8><---- >>> packages/ipaserver/install/plugins/update_uniqueness.py' >>> ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' >>> ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' >>> ipa.ipaserver.install.installutils: DEBUG group dirsrv exists >>> ipa.ipaserver.install.installutils: DEBUG user dirsrv exists >>> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Created connection context.ldap2_59928528 >>> ipa.ipapython.ipaldap.SchemaCache: DEBUG flushing ldaps://vuwunicoipam002.ods.vuw.ac.nz from SchemaCache >>> ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldaps://vuwunicoipam002.ods.vuw.ac.nz conn= >>> error copying files: failed to decode certificate: (SEC_ERROR_LIBRARY_FAILURE) security library failure. >>> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Destroyed connection context.ldap2_59928528 >>> ipa : DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script >>> return_value = main_function() >>> >>> File "/sbin/ipa-replica-install", line 658, in main >>> install_ca_cert(conn, api.env.basedn, api.env.realm, cafile) >>> >>> File "/sbin/ipa-replica-install", line 227, in install_ca_cert >>> sys.exit(1) >>> >>> ipa : DEBUG The ipa-replica-install command failed, exception: SystemExit: 1 >>> >>> ======== >>> >>> >>> Any idea what is wrong please? >> >> What a strange error. My initial thought was that it couldn't read or >> parse the CA cert from the 3.0 master, but this security library error >> is unexpected. >> >> I might be sending you on a wild goose chase but take a look at the CA >> cert in cn=CAcert,cn=ipa,cn=etc,$SUFFIX >> >> There was a bug quite a while back where the cert value was >> double-base64-encoded. I wouldn't expect this error from this problem >> but who knows. >> >> rob >> > > From Steven.Jones at vuw.ac.nz Mon Feb 16 23:31:03 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 16 Feb 2015 23:31:03 +0000 Subject: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. In-Reply-To: <54E27886.9080902@redhat.com> References: <20150216084059.GL9695@p.redhat.com>, <1424121712790.33539@vuw.ac.nz>,<54E263E2.4000307@redhat.com> <1424122845959.41100@vuw.ac.nz>,<54E26827.70902@redhat.com> <1424126634379.52393@vuw.ac.nz>,<54E27886.9080902@redhat.com> Message-ID: <1424129323162.87323@vuw.ac.nz> yep this is all double dutch to me. regards Steven ________________________________________ From: Rob Crittenden Sent: Tuesday, 17 February 2015 12:08 p.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. Steven Jones wrote: > ? > > ==== > [root at xx ipa]# ldapsearch -Y GSSAPI -b cn=CAcert,cn=ipa,cn=etc,$SUFFIX > SASL/GSSAPI authentication started > SASL username: xxxx > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # search result > search: 4 > result: 32 No such object > > # numResponses: 1 Did you literally use $SUFFIX? You need to use dc=example,dc=com, whatever is appropriate for your install. rob > > ==== > > regards > > Steven > ________________________________________ > From: Rob Crittenden > Sent: Tuesday, 17 February 2015 10:59 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. > > Steven Jones wrote: >> Hi, >> >> I have no idea how. > > $ kinit admin > $ ldapsearch -Y GSSAPI -b cn=CAcert,cn=ipa,cn=etc,$SUFFIX > > It should have an attribuete cACertificate;binary likely beginning with > MII. If it begins with TU then it is likely double-encoded. > > And remember, this may be a red herring. > > rob > >> >> regards >> >> Steven >> ________________________________________ >> From: Rob Crittenden >> Sent: Tuesday, 17 February 2015 10:40 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. >> >> Steven Jones wrote: >>> While attempting to initialise the new server I am getting, >>> >>> >>> [root at xx replica-files]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 --no-reverse replica-info-xxx.gpg --skip-conncheck --debug >>> >>> >>> =====8><---- >>> packages/ipaserver/install/plugins/update_uniqueness.py' >>> ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' >>> ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' >>> ipa.ipaserver.install.installutils: DEBUG group dirsrv exists >>> ipa.ipaserver.install.installutils: DEBUG user dirsrv exists >>> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Created connection context.ldap2_59928528 >>> ipa.ipapython.ipaldap.SchemaCache: DEBUG flushing ldaps://vuwunicoipam002.ods.vuw.ac.nz from SchemaCache >>> ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldaps://vuwunicoipam002.ods.vuw.ac.nz conn= >>> error copying files: failed to decode certificate: (SEC_ERROR_LIBRARY_FAILURE) security library failure. >>> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Destroyed connection context.ldap2_59928528 >>> ipa : DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script >>> return_value = main_function() >>> >>> File "/sbin/ipa-replica-install", line 658, in main >>> install_ca_cert(conn, api.env.basedn, api.env.realm, cafile) >>> >>> File "/sbin/ipa-replica-install", line 227, in install_ca_cert >>> sys.exit(1) >>> >>> ipa : DEBUG The ipa-replica-install command failed, exception: SystemExit: 1 >>> >>> ======== >>> >>> >>> Any idea what is wrong please? >> >> What a strange error. My initial thought was that it couldn't read or >> parse the CA cert from the 3.0 master, but this security library error >> is unexpected. >> >> I might be sending you on a wild goose chase but take a look at the CA >> cert in cn=CAcert,cn=ipa,cn=etc,$SUFFIX >> >> There was a bug quite a while back where the cert value was >> double-base64-encoded. I wouldn't expect this error from this problem >> but who knows. >> >> rob >> > > From Steven.Jones at vuw.ac.nz Mon Feb 16 23:36:50 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 16 Feb 2015 23:36:50 +0000 Subject: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. In-Reply-To: <54E27886.9080902@redhat.com> References: <20150216084059.GL9695@p.redhat.com>, <1424121712790.33539@vuw.ac.nz>,<54E263E2.4000307@redhat.com> <1424122845959.41100@vuw.ac.nz>,<54E26827.70902@redhat.com> <1424126634379.52393@vuw.ac.nz>,<54E27886.9080902@redhat.com> Message-ID: <1424129670344.72629@vuw.ac.nz> ===== cACertificate;binary:: TUlJQ0NUQ0NBWEtnQX........8><--- ===== :( So now what? regards Steven ________________________________________ From: Rob Crittenden Sent: Tuesday, 17 February 2015 12:08 p.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. Steven Jones wrote: > ? > > ==== > [root at xx ipa]# ldapsearch -Y GSSAPI -b cn=CAcert,cn=ipa,cn=etc,$SUFFIX > SASL/GSSAPI authentication started > SASL username: xxxx > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # search result > search: 4 > result: 32 No such object > > # numResponses: 1 Did you literally use $SUFFIX? You need to use dc=example,dc=com, whatever is appropriate for your install. rob > > ==== > > regards > > Steven > ________________________________________ > From: Rob Crittenden > Sent: Tuesday, 17 February 2015 10:59 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. > > Steven Jones wrote: >> Hi, >> >> I have no idea how. > > $ kinit admin > $ ldapsearch -Y GSSAPI -b cn=CAcert,cn=ipa,cn=etc,$SUFFIX > > It should have an attribuete cACertificate;binary likely beginning with > MII. If it begins with TU then it is likely double-encoded. > > And remember, this may be a red herring. > > rob > >> >> regards >> >> Steven >> ________________________________________ >> From: Rob Crittenden >> Sent: Tuesday, 17 February 2015 10:40 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. >> >> Steven Jones wrote: >>> While attempting to initialise the new server I am getting, >>> >>> >>> [root at xx replica-files]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 --no-reverse replica-info-xxx.gpg --skip-conncheck --debug >>> >>> >>> =====8><---- >>> packages/ipaserver/install/plugins/update_uniqueness.py' >>> ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' >>> ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' >>> ipa.ipaserver.install.installutils: DEBUG group dirsrv exists >>> ipa.ipaserver.install.installutils: DEBUG user dirsrv exists >>> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Created connection context.ldap2_59928528 >>> ipa.ipapython.ipaldap.SchemaCache: DEBUG flushing ldaps://vuwunicoipam002.ods.vuw.ac.nz from SchemaCache >>> ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldaps://vuwunicoipam002.ods.vuw.ac.nz conn= >>> error copying files: failed to decode certificate: (SEC_ERROR_LIBRARY_FAILURE) security library failure. >>> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Destroyed connection context.ldap2_59928528 >>> ipa : DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script >>> return_value = main_function() >>> >>> File "/sbin/ipa-replica-install", line 658, in main >>> install_ca_cert(conn, api.env.basedn, api.env.realm, cafile) >>> >>> File "/sbin/ipa-replica-install", line 227, in install_ca_cert >>> sys.exit(1) >>> >>> ipa : DEBUG The ipa-replica-install command failed, exception: SystemExit: 1 >>> >>> ======== >>> >>> >>> Any idea what is wrong please? >> >> What a strange error. My initial thought was that it couldn't read or >> parse the CA cert from the 3.0 master, but this security library error >> is unexpected. >> >> I might be sending you on a wild goose chase but take a look at the CA >> cert in cn=CAcert,cn=ipa,cn=etc,$SUFFIX >> >> There was a bug quite a while back where the cert value was >> double-base64-encoded. I wouldn't expect this error from this problem >> but who knows. >> >> rob >> > > From rcritten at redhat.com Tue Feb 17 01:18:06 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Feb 2015 20:18:06 -0500 Subject: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. In-Reply-To: <1424129670344.72629@vuw.ac.nz> References: <20150216084059.GL9695@p.redhat.com>, <1424121712790.33539@vuw.ac.nz>, <54E263E2.4000307@redhat.com> <1424122845959.41100@vuw.ac.nz>, <54E26827.70902@redhat.com> <1424126634379.52393@vuw.ac.nz>, <54E27886.9080902@redhat.com> <1424129670344.72629@vuw.ac.nz> Message-ID: <54E296CE.7070501@redhat.com> Steven Jones wrote: > ===== > cACertificate;binary:: TUlJQ0NUQ0NBWEtnQX........8><--- Now you need to replace the contents of this double-encoded value with an actual binary value. First create the necessary file: $ openssl x509 -inform pem -outform der -in /etc/ipa/ca.crt -out /tmp/ca.der Now replace what is there with the contents of the file, replacing dc=example,dc=com with your basedn: $ kinit admin $ ldapmodify -Y GSSAPI dn: cn=CACert,cn=ipa,cn=etc,dc=example,dc=com changetype: modify replace: cacertificate;binary cacertificate;binary:< file:///tmp/ca.der modifying entry "cn=CACert,cn=ipa,cn=etc,dc=example,dc=com" ctrl-D to quit This is assuming that you have a single CA certificate in /etc/ipa/ca.crt. This is *not* the best assumption to make. Be careful. rob > ===== > > :( > > So now what? > > regards > > Steven > ________________________________________ > From: Rob Crittenden > Sent: Tuesday, 17 February 2015 12:08 p.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. > > Steven Jones wrote: >> ? >> >> ==== >> [root at xx ipa]# ldapsearch -Y GSSAPI -b cn=CAcert,cn=ipa,cn=etc,$SUFFIX >> SASL/GSSAPI authentication started >> SASL username: xxxx >> SASL SSF: 56 >> SASL data security layer installed. >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (objectclass=*) >> # requesting: ALL >> # >> >> # search result >> search: 4 >> result: 32 No such object >> >> # numResponses: 1 > > Did you literally use $SUFFIX? You need to use dc=example,dc=com, > whatever is appropriate for your install. > > rob > >> >> ==== >> >> regards >> >> Steven >> ________________________________________ >> From: Rob Crittenden >> Sent: Tuesday, 17 February 2015 10:59 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. >> >> Steven Jones wrote: >>> Hi, >>> >>> I have no idea how. >> >> $ kinit admin >> $ ldapsearch -Y GSSAPI -b cn=CAcert,cn=ipa,cn=etc,$SUFFIX >> >> It should have an attribuete cACertificate;binary likely beginning with >> MII. If it begins with TU then it is likely double-encoded. >> >> And remember, this may be a red herring. >> >> rob >> >>> >>> regards >>> >>> Steven >>> ________________________________________ >>> From: Rob Crittenden >>> Sent: Tuesday, 17 February 2015 10:40 a.m. >>> To: Steven Jones >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. >>> >>> Steven Jones wrote: >>>> While attempting to initialise the new server I am getting, >>>> >>>> >>>> [root at xx replica-files]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 --no-reverse replica-info-xxx.gpg --skip-conncheck --debug >>>> >>>> >>>> =====8><---- >>>> packages/ipaserver/install/plugins/update_uniqueness.py' >>>> ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' >>>> ipa : DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' >>>> ipa.ipaserver.install.installutils: DEBUG group dirsrv exists >>>> ipa.ipaserver.install.installutils: DEBUG user dirsrv exists >>>> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Created connection context.ldap2_59928528 >>>> ipa.ipapython.ipaldap.SchemaCache: DEBUG flushing ldaps://vuwunicoipam002.ods.vuw.ac.nz from SchemaCache >>>> ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldaps://vuwunicoipam002.ods.vuw.ac.nz conn= >>>> error copying files: failed to decode certificate: (SEC_ERROR_LIBRARY_FAILURE) security library failure. >>>> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Destroyed connection context.ldap2_59928528 >>>> ipa : DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script >>>> return_value = main_function() >>>> >>>> File "/sbin/ipa-replica-install", line 658, in main >>>> install_ca_cert(conn, api.env.basedn, api.env.realm, cafile) >>>> >>>> File "/sbin/ipa-replica-install", line 227, in install_ca_cert >>>> sys.exit(1) >>>> >>>> ipa : DEBUG The ipa-replica-install command failed, exception: SystemExit: 1 >>>> >>>> ======== >>>> >>>> >>>> Any idea what is wrong please? >>> >>> What a strange error. My initial thought was that it couldn't read or >>> parse the CA cert from the 3.0 master, but this security library error >>> is unexpected. >>> >>> I might be sending you on a wild goose chase but take a look at the CA >>> cert in cn=CAcert,cn=ipa,cn=etc,$SUFFIX >>> >>> There was a bug quite a while back where the cert value was >>> double-base64-encoded. I wouldn't expect this error from this problem >>> but who knows. >>> >>> rob >>> >> >> > > From nicolas.zin at savoirfairelinux.com Tue Feb 17 08:52:31 2015 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Tue, 17 Feb 2015 03:52:31 -0500 (EST) Subject: [Freeipa-users] issues with sudo on RHEL5.8 In-Reply-To: <1334528534.3318986.1424163102517.JavaMail.root@savoirfairelinux.com> Message-ID: <1772774127.3318987.1424163151041.JavaMail.root@savoirfairelinux.com> Hi, With a RHEL7 IDM installation, I try to make sudo working. On RHEL6 no problem (via sssd) On RHEL5.8 I don't manage to make it working (credential are good, I manage to request the schema, see below) Where can I found more logs? What did I forget? [root at srv-rhel58-01 ~]# cat /etc/nss_ldap.conf bindn uid=sudo,cn=sysaccounts,cn=etc,dc=company,dc=com binpw redhat5Sudo ssl start_tls tls_cacertfile /etc/openldap/cacerts/ipa.crt #tls_cacert /etc/openldap/cacerts/ipa.crt tls_checkpeer yes #uri ldap://srv-idm7-01.company.com, ldap://srv-idm7-02.company.com uri ldap://srv-idm7-01.company.com sudoers_base ou=SUDOers,dc=company,dc=com sudoers_debug: 2 [root at srv-rhel58-01 ~]# ldapsearch -x -ZZ -D "uid=sudo,cn=sysaccounts,cn=etc,dc=company,dc=com" -b "ou=SUDOers,dc=company,dc=com" -h srv-idm7-01.company.com -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # sudoers, company.com dn: ou=sudoers,dc=company,dc=com objectClass: extensibleObject ou: sudoers # sudo4admin, sudoers, company.com dn: cn=sudo4admin,ou=sudoers,dc=company,dc=com objectClass: sudoRole sudoUser: nzin sudoHost: ALL sudoCommand: ALL cn: sudo4admin # search result search: 3 result: 0 Success # numResponses: 3 # numEntries: 2 In /var/log/secure: Feb 17 04:35:59 srv-rhel58-01 sudo: pam_unix(sudo-i:auth): authentication failure; logname=nzin uid=0 euid=0 tty=/dev/pts/3 ruser= rhost= user=nzin Feb 17 04:35:59 srv-rhel58-01 sudo: pam_sss(sudo-i:auth): authentication success; logname=nzin uid=0 euid=0 tty=/dev/pts/3 ruser= rhost= user=nzin Feb 17 04:35:59 srv-rhel58-01 sudo: nzin : user NOT in sudoers ; TTY=pts/3 ; PWD=/home/nzin ; USER=root ; COMMAND=/bin/bash Regards, Nicolas Zin nicolas.zin at savoirfairelinux.com Ligne directe: 514-276-5468 poste 135 Fax : 514-276-5465 7275 Saint Urbain Bureau 200 Montr?al, QC, H2R 2Y5 From jhrozek at redhat.com Tue Feb 17 10:09:50 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 17 Feb 2015 11:09:50 +0100 Subject: [Freeipa-users] issues with sudo on RHEL5.8 In-Reply-To: <1772774127.3318987.1424163151041.JavaMail.root@savoirfairelinux.com> References: <1334528534.3318986.1424163102517.JavaMail.root@savoirfairelinux.com> <1772774127.3318987.1424163151041.JavaMail.root@savoirfairelinux.com> Message-ID: <20150217100950.GR2917@hendrix.brq.redhat.com> On Tue, Feb 17, 2015 at 03:52:31AM -0500, Nicolas Zin wrote: > Hi, > > With a RHEL7 IDM installation, I try to make sudo working. > On RHEL6 no problem (via sssd) > On RHEL5.8 I don't manage to make it working (credential are good, I manage to request the schema, see below) > Where can I found more logs? > What did I forget? > > > [root at srv-rhel58-01 ~]# cat /etc/nss_ldap.conf > bindn uid=sudo,cn=sysaccounts,cn=etc,dc=company,dc=com > binpw redhat5Sudo > ssl start_tls > tls_cacertfile /etc/openldap/cacerts/ipa.crt > #tls_cacert /etc/openldap/cacerts/ipa.crt > tls_checkpeer yes > #uri ldap://srv-idm7-01.company.com, ldap://srv-idm7-02.company.com > uri ldap://srv-idm7-01.company.com > sudoers_base ou=SUDOers,dc=company,dc=com > sudoers_debug: 2 > > > > > > [root at srv-rhel58-01 ~]# ldapsearch -x -ZZ -D "uid=sudo,cn=sysaccounts,cn=etc,dc=company,dc=com" -b "ou=SUDOers,dc=company,dc=com" -h srv-idm7-01.company.com -W > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # sudoers, company.com > dn: ou=sudoers,dc=company,dc=com > objectClass: extensibleObject > ou: sudoers > > # sudo4admin, sudoers, company.com > dn: cn=sudo4admin,ou=sudoers,dc=company,dc=com > objectClass: sudoRole > sudoUser: nzin > sudoHost: ALL > sudoCommand: ALL > cn: sudo4admin > > # search result > search: 3 > result: 0 Success > > # numResponses: 3 > # numEntries: 2 > > > > > > In /var/log/secure: > Feb 17 04:35:59 srv-rhel58-01 sudo: pam_unix(sudo-i:auth): authentication failure; logname=nzin uid=0 euid=0 tty=/dev/pts/3 ruser= rhost= user=nzin > Feb 17 04:35:59 srv-rhel58-01 sudo: pam_sss(sudo-i:auth): authentication success; logname=nzin uid=0 euid=0 tty=/dev/pts/3 ruser= rhost= user=nzin > Feb 17 04:35:59 srv-rhel58-01 sudo: nzin : user NOT in sudoers ; TTY=pts/3 ; PWD=/home/nzin ; USER=root ; COMMAND=/bin/bash > > > > > Regards, I don't have a 5.8 machine around, but I would suggest to enable debugging from sudo itself. In newer versions, there is a Debug directive in sudo.conf, IIRC in earlier versions there was a '-D' option. From nicolas.zin at savoirfairelinux.com Tue Feb 17 10:18:18 2015 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Tue, 17 Feb 2015 05:18:18 -0500 (EST) Subject: [Freeipa-users] issues with sudo on RHEL5.8 In-Reply-To: <068660BA-2349-4D8D-A8FC-F03F0D61B819@allegrogroup.com> References: <1772774127.3318987.1424163151041.JavaMail.root@savoirfairelinux.com> <068660BA-2349-4D8D-A8FC-F03F0D61B819@allegrogroup.com> Message-ID: <2052617552.3341912.1424168298665.JavaMail.root@savoirfairelinux.com> Thanks, that helps! I mistyped binddn and bindpw ----- Mail original ----- De: "Lukasz Jaworski" ?: "Nicolas Zin" Cc: freeipa-users at redhat.com Envoy?: Mardi 17 F?vrier 2015 13:31:20 Objet: Re: [Freeipa-users] issues with sudo on RHEL5.8 > > With a RHEL7 IDM installation, I try to make sudo working. > On RHEL6 no problem (via sssd) > On RHEL5.8 I don't manage to make it working (credential are good, I manage to request the schema, see below) > Where can I found more logs? > What did I forget? > [root at srv-rhel58-01 ~]# cat /etc/nss_ldap.conf > bindn uid=sudo,cn=sysaccounts,cn=etc,dc=company,dc=com > binpw redhat5Sudo > ssl start_tls > tls_cacertfile /etc/openldap/cacerts/ipa.crt > #tls_cacert /etc/openldap/cacerts/ipa.crt > tls_checkpeer yes > #uri ldap://srv-idm7-01.company.com, ldap://srv-idm7-02.company.com > uri ldap://srv-idm7-01.company.com > sudoers_base ou=SUDOers,dc=company,dc=com > sudoers_debug: 2 change last line (remove ":") to: sudoers_debug 2 And then try sudo. Check: /etc/nsswitch.conf should be: sudoers: files ldap Best regards, Ender -- ?ukasz Jaworski From mkosek at redhat.com Tue Feb 17 10:56:01 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 17 Feb 2015 11:56:01 +0100 Subject: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade. In-Reply-To: <54E27886.9080902@redhat.com> References: <20150216084059.GL9695@p.redhat.com>, <1424121712790.33539@vuw.ac.nz>, <54E263E2.4000307@redhat.com> <1424122845959.41100@vuw.ac.nz>, <54E26827.70902@redhat.com> <1424126634379.52393@vuw.ac.nz> <54E27886.9080902@redhat.com> Message-ID: <54E31E41.4000300@redhat.com> On 02/17/2015 12:08 AM, Rob Crittenden wrote: > Steven Jones wrote: >> ? >> >> ==== >> [root at xx ipa]# ldapsearch -Y GSSAPI -b cn=CAcert,cn=ipa,cn=etc,$SUFFIX >> SASL/GSSAPI authentication started >> SASL username: xxxx >> SASL SSF: 56 >> SASL data security layer installed. >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (objectclass=*) >> # requesting: ALL >> # >> >> # search result >> search: 4 >> result: 32 No such object >> >> # numResponses: 1 > > Did you literally use $SUFFIX? You need to use dc=example,dc=com, > whatever is appropriate for your install. > > rob Right. Or even easier is to simply delete cn=CAcert,cn=ipa,cn=etc,SUFFIX and then running # ipa-ldap-updater --upgrade again. upload_cacrt.py plugin should simply re-upload the properly encoded certificate. From thomas.raehalme at codecenter.fi Tue Feb 17 11:12:11 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Tue, 17 Feb 2015 13:12:11 +0200 Subject: [Freeipa-users] dirsrv hangs, 0% CPU util In-Reply-To: <20150216064443.GG26748@redhat.com> References: <54E111AE.4090600@redhat.com> <54E12444.8090604@redhat.com> <20150216064443.GG26748@redhat.com> Message-ID: On Mon, Feb 16, 2015 at 8:44 AM, Alexander Bokovoy wrote: > I suspect you've triggered https://fedorahosted.org/freeipa/ticket/4586 > and https://fedorahosted.org/freeipa/ticket/4635 -- slapi-nis plugin > configuration does not limit itself to $SUFFIX and listens to changes in > cn=changelog too so it may deadlock with a replication traffic. > > We fixed these partly by changing slapi-nis configuration, partly by > fixing bugs in 389-ds. > > I wonder if amending your slapi-nis config to avoid triggering internal > searches on cn=changelog would be enough. > > If you have RHEL subscription, please open a case with Red Hat's > support. > > I opened a support case, but unfortunately the IPA server is running on CentOS so no help from the support. Any chance you could share the configuration changes you referred to above? At the moment we cannot even access ipa-replica-manage because it "Can' contact LDAP server". I doubt it has something to do with Kerberos based authentication, as kinit is also really unstable at the moment. Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Feb 17 15:39:40 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 17 Feb 2015 10:39:40 -0500 Subject: [Freeipa-users] issues with sudo on RHEL5.8 In-Reply-To: <2052617552.3341912.1424168298665.JavaMail.root@savoirfairelinux.com> References: <1772774127.3318987.1424163151041.JavaMail.root@savoirfairelinux.com> <068660BA-2349-4D8D-A8FC-F03F0D61B819@allegrogroup.com> <2052617552.3341912.1424168298665.JavaMail.root@savoirfairelinux.com> Message-ID: <54E360BC.2040309@redhat.com> On 02/17/2015 05:18 AM, Nicolas Zin wrote: > Thanks, > > that helps! > I mistyped binddn and bindpw > > ----- Mail original ----- > De: "Lukasz Jaworski" > ?: "Nicolas Zin" > Cc: freeipa-users at redhat.com > Envoy?: Mardi 17 F?vrier 2015 13:31:20 > Objet: Re: [Freeipa-users] issues with sudo on RHEL5.8 > >> With a RHEL7 IDM installation, I try to make sudo working. >> On RHEL6 no problem (via sssd) >> On RHEL5.8 I don't manage to make it working (credential are good, I manage to request the schema, see below) >> Where can I found more logs? >> What did I forget? >> [root at srv-rhel58-01 ~]# cat /etc/nss_ldap.conf >> bindn uid=sudo,cn=sysaccounts,cn=etc,dc=company,dc=com >> binpw redhat5Sudo >> ssl start_tls >> tls_cacertfile /etc/openldap/cacerts/ipa.crt >> #tls_cacert /etc/openldap/cacerts/ipa.crt >> tls_checkpeer yes >> #uri ldap://srv-idm7-01.company.com, ldap://srv-idm7-02.company.com >> uri ldap://srv-idm7-01.company.com >> sudoers_base ou=SUDOers,dc=company,dc=com >> sudoers_debug: 2 > change last line (remove ":") to: > sudoers_debug 2 > > And then try sudo. > > Check: > /etc/nsswitch.conf > should be: > sudoers: files ldap > > Best regards, > Ender > We quite frequently get questions about how to configure SUDO with IPA from RHEL5.x clients. Would you mind sharing this configuration as a howto solution? http://www.freeipa.org/page/HowTos -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From thomas.raehalme at codecenter.fi Tue Feb 17 16:26:39 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Tue, 17 Feb 2015 18:26:39 +0200 Subject: [Freeipa-users] No LDAPS for dirsrv Message-ID: Hi! As I wrote earlier we are having some serious problems with IPA right now. dirsrv seems to hang every 15 minutes or so, but that's another post. It seems that slapd/dirsrv is now only listening on port 389 for LDAP and socket for LDAPI requests. Any idea what could have caused previously available LDAPS port 636 to disappear? Looking at the logs before this whole ordeal started port 636 was also in use. After the latest upgrade I have re-enabled port 389 manually because it's used by some apps, but disabling it also doesn't bring back port 636. Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Feb 17 16:34:33 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Feb 2015 11:34:33 -0500 Subject: [Freeipa-users] No LDAPS for dirsrv In-Reply-To: References: Message-ID: <54E36D99.8090207@redhat.com> Thomas Raehalme wrote: > Hi! > > As I wrote earlier we are having some serious problems with IPA right > now. dirsrv seems to hang every 15 minutes or so, but that's another post. > > It seems that slapd/dirsrv is now only listening on port 389 for LDAP > and socket for LDAPI requests. Any idea what could have caused > previously available LDAPS port 636 to disappear? > > Looking at the logs before this whole ordeal started port 636 was also > in use. > > After the latest upgrade I have re-enabled port 389 manually because > it's used by some apps, but disabling it also doesn't bring back port 636. > > Best regards, > Thomas > > If after an upgrade you had no listeners that means that the upgrade failed and wasn't able to restore the previous state. Look in /etc/dirsrv/slapd-YOURREALM for dse.ldif.ipa.#######. This is the copy saved prior to the upgrade attempt. I'd diff it to dse.ldif to see what has changed. To enable port 636 just set nsslapd-security to on. If you do this via dse.ldif you'll need to stop the service before editing the file. Check /var/log/ipaupgrade.log for information on the upgrade. rob From cmohler at oberlin.edu Tue Feb 17 16:35:57 2015 From: cmohler at oberlin.edu (Chris Mohler) Date: Tue, 17 Feb 2015 11:35:57 -0500 Subject: [Freeipa-users] No LDAPS for dirsrv In-Reply-To: References: Message-ID: <54E36DED.5060808@oberlin.edu> On 02/17/2015 11:26 AM, Thomas Raehalme wrote: > Hi! > > As I wrote earlier we are having some serious problems with IPA right > now. dirsrv seems to hang every 15 minutes or so, but that's another post. > > It seems that slapd/dirsrv is now only listening on port 389 for LDAP > and socket for LDAPI requests. Any idea what could have caused > previously available LDAPS port 636 to disappear? > > Looking at the logs before this whole ordeal started port 636 was also > in use. > > After the latest upgrade I have re-enabled port 389 manually because > it's used by some apps, but disabling it also doesn't bring back port 636. > > Best regards, > Thomas > > Hi Thomas, I'm not an expert but just throwing out a few ideas for you. > As I wrote earlier we are having some serious problems with IPA right > now. dirsrv seems to hang every 15 minutes or so, but that's another post. Are you running in a VM? If so check your entropy. cat /proc/sys/kernel/random/entropy_avail It should be ~1k less than 50 is not great and caused me some issues in the past. > It seems that slapd/dirsrv is now only listening on port 389 for LDAP > and socket for LDAPI requests. Any idea what could have caused > previously available LDAPS port 636 to disappear? Did your certificates expire? I usually check the web interface and look at the SSL Cert in the browser to see when it expires. I bet there is a better way to check but I don't know it off hand. It might help to know what OS/version you are using? and what version of FreeIPA you are using. Cheers, and Good luck, -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.raehalme at codecenter.fi Tue Feb 17 17:08:33 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Tue, 17 Feb 2015 19:08:33 +0200 Subject: [Freeipa-users] No LDAPS for dirsrv In-Reply-To: <54E36D99.8090207@redhat.com> References: <54E36D99.8090207@redhat.com> Message-ID: Hi! On Tue, Feb 17, 2015 at 6:34 PM, Rob Crittenden wrote: > > If after an upgrade you had no listeners that means that the upgrade > failed and wasn't able to restore the previous state. Look in > /etc/dirsrv/slapd-YOURREALM for dse.ldif.ipa.#######. This is the copy > saved prior to the upgrade attempt. I'd diff it to dse.ldif to see what > has changed. > > To enable port 636 just set nsslapd-security to on. If you do this via > dse.ldif you'll need to stop the service before editing the file. > Thanks! For some reason the value of nsslapd-security is 'off' for the current version although previous dse.ldif.ipa.## files have it enabled. Changing the value back to 'on' re-enabled port 636. Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.raehalme at codecenter.fi Tue Feb 17 17:20:29 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Tue, 17 Feb 2015 19:20:29 +0200 Subject: [Freeipa-users] No LDAPS for dirsrv In-Reply-To: <54E36DED.5060808@oberlin.edu> References: <54E36DED.5060808@oberlin.edu> Message-ID: Hi Chris! On Tue, Feb 17, 2015 at 6:35 PM, Chris Mohler wrote: > > As I wrote earlier we are having some serious problems with IPA right now. > dirsrv seems to hang every 15 minutes or so, but that's another post. > > Are you running in a VM? If so check your entropy. > cat /proc/sys/kernel/random/entropy_avail > It should be ~1k less than 50 is not great and caused me some issues in > the past. > Yes, the server is a VM. Entropy value is 135 at the moment. Do you know how to increase the value? It seems that slapd/dirsrv is now only listening on port 389 for LDAP and > socket for LDAPI requests. Any idea what could have caused previously > available LDAPS port 636 to disappear? > > Did your certificates expire? I usually check the web interface and look > at the SSL Cert in the browser to see when it expires. I bet there is a > better way to check but I don't know it off hand. > No, at least for the web interface certificates expire in August. It turned out the nsslapd-security was 'off' when it should have been 'on'. I really don't know what had changed the value. Now I only wish we could resolve what's causing the dirsrv process to hang (wrote about that in another message last Sunday) about 10 minutes after IPA services were started. Thanks for your help! Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Feb 17 17:38:43 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Feb 2015 12:38:43 -0500 Subject: [Freeipa-users] No LDAPS for dirsrv In-Reply-To: References: <54E36DED.5060808@oberlin.edu> Message-ID: <54E37CA3.7090002@redhat.com> Thomas Raehalme wrote: > Hi Chris! > > On Tue, Feb 17, 2015 at 6:35 PM, Chris Mohler > wrote: > > >> As I wrote earlier we are having some serious problems with IPA >> right now. dirsrv seems to hang every 15 minutes or so, but that's >> another post. > Are you running in a VM? If so check your entropy. > cat /proc/sys/kernel/random/entropy_avail > It should be ~1k less than 50 is not great and caused me some issues > in the past. > > > Yes, the server is a VM. Entropy value is 135 at the moment. Do you know > how to increase the value? I don't think that's an issue. It is more a problem during initial installation than during operation AFAIK. >> It seems that slapd/dirsrv is now only listening on port 389 for >> LDAP and socket for LDAPI requests. Any idea what could have >> caused previously available LDAPS port 636 to disappear? > Did your certificates expire? I usually check the web interface and > look at the SSL Cert in the browser to see when it expires. I bet > there is a better way to check but I don't know it off hand. > > > No, at least for the web interface certificates expire in August. > > It turned out the nsslapd-security was 'off' when it should have been > 'on'. I really don't know what had changed the value. > > Now I only wish we could resolve what's causing the dirsrv process to > hang (wrote about that in another message last Sunday) about 10 minutes > after IPA services were started. Evidence suggests that the last upgrade failed so I'd start there. It is possible some plugins aren't configured properly, for example. You can try to re-run the upgrade manually. Note that the updater will disable all listeners while it is running. This is where things went sideways before. # /usr/sbin/ipa-ldap-updater --upgrade If that succeeds: # /usr/sbin/ipa-upgradeconfig Then # ipactl restart rob From cmohler at oberlin.edu Tue Feb 17 18:13:16 2015 From: cmohler at oberlin.edu (Chris Mohler) Date: Tue, 17 Feb 2015 13:13:16 -0500 Subject: [Freeipa-users] No LDAPS for dirsrv In-Reply-To: <54E37CA3.7090002@redhat.com> References: <54E36DED.5060808@oberlin.edu> <54E37CA3.7090002@redhat.com> Message-ID: <54E384BC.9070702@oberlin.edu> I would agree with Rob, entropy is likely not one of your root issues. It may still do you good to have a bit more as it can cause system slowdown during SSL generation loads. It's really up to you how you go about generating entropy. Here is a link with some suggestions http://log.amitshah.net/2013/01/about-random-numbers-and-virtual-machines/ I would suggest you just yum install haveged It's worked good for me so far. Good luck, -Chris On 02/17/2015 12:38 PM, Rob Crittenden wrote: > Thomas Raehalme wrote: >> Hi Chris! >> >> On Tue, Feb 17, 2015 at 6:35 PM, Chris Mohler > > wrote: >> >> >>> As I wrote earlier we are having some serious problems with IPA >>> right now. dirsrv seems to hang every 15 minutes or so, but that's >>> another post. >> Are you running in a VM? If so check your entropy. >> cat /proc/sys/kernel/random/entropy_avail >> It should be ~1k less than 50 is not great and caused me some issues >> in the past. >> >> >> Yes, the server is a VM. Entropy value is 135 at the moment. Do you know >> how to increase the value? > I don't think that's an issue. It is more a problem during initial > installation than during operation AFAIK. > >>> It seems that slapd/dirsrv is now only listening on port 389 for >>> LDAP and socket for LDAPI requests. Any idea what could have >>> caused previously available LDAPS port 636 to disappear? >> Did your certificates expire? I usually check the web interface and >> look at the SSL Cert in the browser to see when it expires. I bet >> there is a better way to check but I don't know it off hand. >> >> >> No, at least for the web interface certificates expire in August. >> >> It turned out the nsslapd-security was 'off' when it should have been >> 'on'. I really don't know what had changed the value. >> >> Now I only wish we could resolve what's causing the dirsrv process to >> hang (wrote about that in another message last Sunday) about 10 minutes >> after IPA services were started. > Evidence suggests that the last upgrade failed so I'd start there. It is > possible some plugins aren't configured properly, for example. > > You can try to re-run the upgrade manually. Note that the updater will > disable all listeners while it is running. This is where things went > sideways before. > > # /usr/sbin/ipa-ldap-updater --upgrade > > If that succeeds: > > # /usr/sbin/ipa-upgradeconfig > > Then > > # ipactl restart > > rob > From thomas.raehalme at codecenter.fi Tue Feb 17 18:43:32 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Tue, 17 Feb 2015 20:43:32 +0200 Subject: [Freeipa-users] No LDAPS for dirsrv In-Reply-To: <54E37CA3.7090002@redhat.com> References: <54E36DED.5060808@oberlin.edu> <54E37CA3.7090002@redhat.com> Message-ID: Hi! On Tue, Feb 17, 2015 at 7:38 PM, Rob Crittenden wrote: > > Now I only wish we could resolve what's causing the dirsrv process to > > hang (wrote about that in another message last Sunday) about 10 minutes > > after IPA services were started. > > Evidence suggests that the last upgrade failed so I'd start there. It is > possible some plugins aren't configured properly, for example. > > Looking at 'yum history' I performed an update after the problems had started an hour or two before. According to /var/log/ipaupgrade.log everything before ipa-ldap-updater ran smoothly. But when it got to 'service dirsrv stop', it took 562 seconds to shutdown dirsrv for EXAMPLE-COM and restarting dirsrv afterwards failed with: 2015-02-15T12:29:58Z DEBUG [4/8]: starting directory server 2015-02-15T12:30:09Z DEBUG args=/sbin/service dirsrv start 2015-02-15T12:30:09Z DEBUG stdout=Starting dirsrv: PKI-IPA... already running[ OK ]^M PVNET-CC...[FAILED]^M *** Error: 1 instance(s) failed to start 2015-02-15T12:30:09Z DEBUG stderr=[15/Feb/2015:14:29:58 +0200] - Information: Non-Secure Port Disabled 2015-02-15T12:30:09Z INFO File "/usr/lib/python2.6/site-packages/ipapython/admintool.py", line 152, in execute return_value = self.run() File "/usr/lib/python2.6/site-packages/ipaserver/install/ipa_ldap_updater.py", line 139, in run upgrade.create_instance() File "/usr/lib/python2.6/site-packages/ipaserver/install/upgradeinstance.py", line 84, in create_instance show_service_name=False) File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", line 358, in start_creation method() File "/usr/lib/python2.6/site-packages/ipaserver/install/upgradeinstance.py", line 67, in __start_nowait super(IPAUpgrade, self).start(wait=False) File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", line 265, in start self.service.start(instance_name, capture_output=capture_output, wait=wait) File "/usr/lib/python2.6/site-packages/ipapython/platform/redhat.py", line 80, in start ipautil.run(["/sbin/service", self.service_name, "start", instance_name], capture_output=capture_output) File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line 316, in run raise CalledProcessError(p.returncode, args) 2015-02-15T12:30:09Z INFO The ipa-ldap-updater command failed, exception: CalledProcessError: Command '/sbin/service dirsrv start ' returned non-zero exit status 1 2015-02-15T12:30:09Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: CalledProcessError: Command '/sbin/service dirsrv start ' returned non-zero exit status 1 Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.raehalme at codecenter.fi Tue Feb 17 19:05:31 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Tue, 17 Feb 2015 21:05:31 +0200 Subject: [Freeipa-users] No LDAPS for dirsrv In-Reply-To: References: <54E36DED.5060808@oberlin.edu> <54E37CA3.7090002@redhat.com> Message-ID: Hi! On Tue, Feb 17, 2015 at 8:43 PM, Thomas Raehalme < thomas.raehalme at codecenter.fi> wrote: > Hi! > > On Tue, Feb 17, 2015 at 7:38 PM, Rob Crittenden > wrote: > >> > Now I only wish we could resolve what's causing the dirsrv process to >> > hang (wrote about that in another message last Sunday) about 10 minutes >> > after IPA services were started. >> >> Evidence suggests that the last upgrade failed so I'd start there. It is >> possible some plugins aren't configured properly, for example. >> >> After having restart ipa service, the upgrade command was completed successfully: # ipa-ldap-updater --upgrade Upgrading IPA: [1/8]: stopping directory server [2/8]: saving configuration [3/8]: disabling listeners [4/8]: starting directory server [5/8]: upgrading server [6/8]: stopping directory server [7/8]: restoring configuration [8/8]: starting directory server Done. Now dirsrv was stopped in 2 second when the previous time was over 500 seconds. Unfortunately this still didn't resolve the issue. After the system has been online for about 10 minutes, named starts complaining: Feb 17 21:04:14 ipa named[31117]: LDAP query timed out. Try to adjust "timeout" parameter Also ldapsearch just hangs if you try to perform any queries. Any ideas what could go wrong here? Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From api at psychopig.com Tue Feb 17 19:55:52 2015 From: api at psychopig.com (Hugh) Date: Tue, 17 Feb 2015 13:55:52 -0600 Subject: [Freeipa-users] Passsync fails to connect to LDAP Message-ID: All, After my education on what IPA/AD trusts can and can't do, I decided to give the IPA-AD sync option a try. After finally finding what I think is the proper software to install on the AD DC (389-PassSync-1.1.6-x86_64.exe from the Fedora site), I believe I have the settings correct, but the Password Synchronization software refuses to connect. After changing the Log Level option to 1, I get the below in the log file, which doesn't really tell me much of anything. 02/17/15 13:18:20: Backoff time expired. Attempting sync 02/17/15 13:18:20: Password list has 1 entries 02/17/15 13:18:20: Ldap bind error in Connect 81: Can't contact LDAP server 02/17/15 13:18:20: Attempting to sync password for ADSERVER$ 02/17/15 13:18:20: Searching for (ntuserdomainid=ADSERVER$) 02/17/15 13:18:20: Ldap error in QueryUsername 81: Can't contact LDAP server 02/17/15 13:18:20: Deferring password change for ADSERVER$ 02/17/15 13:18:20: Backing off for 256000ms The credentials are definitely correct and IPA is set up to do LDAPS as, on the same AD server, I can connect and bind using ldp.exe with the same settings/credentials and I'm able to browse the LDAP tree. I've done a wireshark capture and it looks like it's failing in the TLS negotiation. I can see this entry in the capture: TLSv1 Record Layer: Alert (Level: Fatal, Description: Protocol Version) Content Type: Alert (21) Version: TLS 1.2 (0x0303) Length: 2 Alert Message Level: Fatal (2) Description: Protocol Version (70) I added the IPA CA cert to the cert files in the 389 passsynch directory and I can confirm that as below. C:\Program Files\389 Directory Password Synchronization>certutil -d . -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI IPA CA cert CT,, When I list that specific certificate, I can see the below in the output. Certificate Trust Flags: SSL Flags: Valid CA Trusted CA Trusted Client CA Email Flags: Object Signing Flags: Any pointers/ideas? Thanks in advance, Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Feb 17 20:16:28 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 17 Feb 2015 13:16:28 -0700 Subject: [Freeipa-users] Passsync fails to connect to LDAP In-Reply-To: References: Message-ID: <54E3A19C.9070007@redhat.com> On 02/17/2015 12:55 PM, Hugh wrote: > All, > After my education on what IPA/AD trusts can and can't do, I decided > to give the IPA-AD sync option a try. After finally finding what I > think is the proper software to install on the AD DC > (389-PassSync-1.1.6-x86_64.exe from the Fedora site), I believe I have > the settings correct, but the Password Synchronization software > refuses to connect. After changing the Log Level option to 1, I get > the below in the log file, which doesn't really tell me much of anything. > 02/17/15 13:18:20: Backoff time expired. Attempting sync > 02/17/15 13:18:20: Password list has 1 entries > 02/17/15 13:18:20: Ldap bind error in Connect > 81: Can't contact LDAP server > 02/17/15 13:18:20: Attempting to sync password for ADSERVER$ > 02/17/15 13:18:20: Searching for (ntuserdomainid=ADSERVER$) > 02/17/15 13:18:20: Ldap error in QueryUsername > 81: Can't contact LDAP server > 02/17/15 13:18:20: Deferring password change for ADSERVER$ > 02/17/15 13:18:20: Backing off for 256000ms > The credentials are definitely correct and IPA is set up to do LDAPS > as, on the same AD server, I can connect and bind using ldp.exe with > the same settings/credentials and I'm able to browse the LDAP tree. > I've done a wireshark capture and it looks like it's failing in the > TLS negotiation. I can see this entry in the capture: > TLSv1 Record Layer: Alert (Level: Fatal, Description: Protocol Version) > Content Type: Alert (21) > Version: TLS 1.2 (0x0303) > Length: 2 > Alert Message > Level: Fatal (2) > Description: Protocol Version (70) What version of 389-ds-base are you using? # rpm -q 389-ds-base > I added the IPA CA cert to the cert files in the 389 passsynch > directory and I can confirm that as below. > C:\Program Files\389 Directory Password Synchronization>certutil -d . -L > Certificate Nickname Trust > Attributes > SSL,S/MIME,JAR/XPI > IPA CA cert CT,, > When I list that specific certificate, I can see the below in the output. > Certificate Trust Flags: > SSL Flags: > Valid CA > Trusted CA > Trusted Client CA > Email Flags: > Object Signing Flags: > Any pointers/ideas? > Thanks in advance, > Hugh > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From api at psychopig.com Tue Feb 17 20:33:12 2015 From: api at psychopig.com (Hugh) Date: Tue, 17 Feb 2015 14:33:12 -0600 Subject: [Freeipa-users] Passsync fails to connect to LDAP In-Reply-To: <54E3A19C.9070007@redhat.com> References: <54E3A19C.9070007@redhat.com> Message-ID: > > > What version of 389-ds-base are you using? > > # rpm -q 389-ds-base > > > Sorry for not specifying. I'm running FreeIPA on CentOS 6.5. Installed via yum - ipa-server-3.0.0-42.el6.centos.x86_64 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Feb 17 20:46:35 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 17 Feb 2015 13:46:35 -0700 Subject: [Freeipa-users] Passsync fails to connect to LDAP In-Reply-To: References: <54E3A19C.9070007@redhat.com> Message-ID: <54E3A8AB.1010305@redhat.com> On 02/17/2015 01:33 PM, Hugh wrote: > > > What version of 389-ds-base are you using? > > # rpm -q 389-ds-base > > Sorry for not specifying. I'm running FreeIPA on CentOS 6.5. > Installed via yum - ipa-server-3.0.0-42.el6.centos.x86_64 Ok, so I'm assuming 389-ds-base is 1.2.11.15-48 or later? I think we may need a new version of passsync. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From api at psychopig.com Tue Feb 17 21:03:41 2015 From: api at psychopig.com (Hugh) Date: Tue, 17 Feb 2015 15:03:41 -0600 Subject: [Freeipa-users] Passsync fails to connect to LDAP In-Reply-To: <54E3A8AB.1010305@redhat.com> References: <54E3A19C.9070007@redhat.com> <54E3A8AB.1010305@redhat.com> Message-ID: On Tue, Feb 17, 2015 at 2:46 PM, Rich Megginson wrote: > > Ok, so I'm assuming 389-ds-base is 1.2.11.15-48 or later? I think we may > need a new version of passsync. > I didn't even know those were installed, but you're spot on. Here are the versions of *389*: 389-ds-base-1.2.11.15-48.el6_6.x86_64 389-ds-base-libs-1.2.11.15-48.el6_6.x86_64 >From what I can tell in the passsync installer, it was packaged just last month, so I wouldn't think it would be too far out of date. Certainly more recent than my version of IPA. Were there changes to TLS support in passync or the 389-ds-base? Thanks, Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Fitzgerald at millersville.edu Tue Feb 17 21:05:02 2015 From: David.Fitzgerald at millersville.edu (David Fitzgerald) Date: Tue, 17 Feb 2015 21:05:02 +0000 Subject: [Freeipa-users] question about Active Directory authentication Message-ID: <958EF916EB06874283F9B8F820726DD3B9FFA10B@FSMB1.muad.local> Hello, I am currently running an IPA 3.3 server on Centos 7. I have 70 IPA client machines running Scientific Linux 6.6 and 150 users. User directories are auto-mounted from a Centos 7 file server. I have been informed that all computer users on our campus must now authenticate off of the University's Active Directory server, including all Linux machines. I have been looking through the IPA documentation and am getting myself confused and not completely understanding what needs to be done, thus I have some questions. 1. The docs talk about setting up a trust between the IPA server and the AD server. Will I need to change all of the IPA clients as well as the IPA server, or do I only need change the server and not have to touch the clients? 2. Do I even need to set up a full trust relationship just to authenticate my users with AD? 3. Since I already have 150 users, will I have to delete their IPA accounts before setting up the trust? W Sorry if my questions are a bit basic, but I need some guidance to get me started. Thanks! Dave ++++++++++++++++++++++++++++++ David Fitzgerald Department of Earth Sciences Millersville University Millersville, PA 17551 Phone: 717-871-2394 E-Mail: david.fitzgerald at millersville.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Feb 17 21:18:58 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 17 Feb 2015 16:18:58 -0500 Subject: [Freeipa-users] question about Active Directory authentication In-Reply-To: <958EF916EB06874283F9B8F820726DD3B9FFA10B@FSMB1.muad.local> References: <958EF916EB06874283F9B8F820726DD3B9FFA10B@FSMB1.muad.local> Message-ID: <54E3B042.2010108@redhat.com> On 02/17/2015 04:05 PM, David Fitzgerald wrote: > > Hello, > > I am currently running an IPA 3.3 server on Centos 7. I have 70 IPA > client machines running Scientific Linux 6.6 and 150 users. User > directories are auto-mounted from a Centos 7 file server. > > I have been informed that all computer users on our campus must now > authenticate off of the University's Active Directory server, > including all Linux machines. I have been looking through the IPA > documentation and am getting myself confused and not completely > understanding what needs to be done, thus I have some questions. > > 1.The docs talk about setting up a trust between the IPA server and > the AD server. Will I need to change all of the IPA clients as well > as the IPA server, or do I only need change the server and not have to > touch the clients? > With IPA on Centos 7 you can establish trust and you 6.6 machines should be capable of picking the trust automatically. > > 2.Do I even need to set up a full trust relationship just to > authenticate my users with AD? > You have three options: - Establish trust - Sync users from AD to IPA - Drop IPA and go direct AD (but you loose a lot). We recommend the trust approach and yet it is a full trust but that does not mean that it is wild west. The trust just means that users can cross authenticate. But if there is no permissions set (which is the case by default) the users even if they are authenticated can't do anything. So if your AD guys a re worried that the trust would open the can of worms it would not. > 3.Since I already have 150 users, will I have to delete their IPA > accounts before setting up the trust? W > Are these users the same as AD users? If they are you can move to IPA 4.1 and convert them to ID Views to assign posix data to the AD users and then remove. https://copr.fedoraproject.org/coprs/mkosek/freeipa/ > > Sorry if my questions are a bit basic, but I need some guidance to get > me started. > > Thanks! > > Dave > > ++++++++++++++++++++++++++++++ > > David Fitzgerald > > Department of Earth Sciences > > Millersville University > > Millersville, PA 17551 > > Phone: 717-871-2394 > > E-Mail: david.fitzgerald at millersville.edu > > > -- 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 Tue Feb 17 21:21:03 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 17 Feb 2015 14:21:03 -0700 Subject: [Freeipa-users] Passsync fails to connect to LDAP In-Reply-To: References: <54E3A19C.9070007@redhat.com> <54E3A8AB.1010305@redhat.com> Message-ID: <54E3B0BF.9010409@redhat.com> On 02/17/2015 02:03 PM, Hugh wrote: > > On Tue, Feb 17, 2015 at 2:46 PM, Rich Megginson > wrote: > > > Ok, so I'm assuming 389-ds-base is 1.2.11.15-48 or later? I think > we may need a new version of passsync. > > I didn't even know those were installed, but you're spot on. Here are > the versions of *389*: > > 389-ds-base-1.2.11.15-48.el6_6.x86_64 > 389-ds-base-libs-1.2.11.15-48.el6_6.x86_64 > From what I can tell in the passsync installer, it was packaged just > last month, so I wouldn't think it would be too far out of date. > Certainly more recent than my version of IPA. Were there changes to > TLS support in passync or the 389-ds-base? I'm trying to find out now. > Thanks, > Hugh > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Tue Feb 17 21:34:52 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 17 Feb 2015 21:34:52 +0000 Subject: [Freeipa-users] question about Active Directory authentication In-Reply-To: <958EF916EB06874283F9B8F820726DD3B9FFA10B@FSMB1.muad.local> References: <958EF916EB06874283F9B8F820726DD3B9FFA10B@FSMB1.muad.local> Message-ID: <1424208749846.77996@vuw.ac.nz> "I have been informed that all computer users on our campus must now authenticate off of the University's Active Directory server, including all Linux machines." dictated by a clueless Windows ***** no doubt, ***sigh*** Here we are keeping both separate as AD is so bad security wise, but want some low risk trusts for certain groups of machines (common desktops). If the expectation is its directly off the AD then you dont need IPA at all. However without an expensive commercial addon per Linux server/desktop you wont be able to do much management and control. this has security implications, if you had say a finance or HR server without these commercial tools you may find any AD user could get on them, not what you would want. So you have 2 options in keeping IPA, a) trusts and you should be able keep your users. b) winsync and passync and all the AD users are synced over to IPA. Existing users stay as is, the ones in AD but not in IPA get pulled over to IPA. ***maybe*** c) You might be able to do both winsync and trusts at the same time then that is simpler provisioning. ie a user gets created in AD and automatically gets created in IPA ready for you to put in the user group you want. I'd like to do c) which I am looking at at present, if I ever get IPA on RHEL6.6 upgraded to RHEL7.1! regards Steven J ________________________________ From: freeipa-users-bounces at redhat.com on behalf of David Fitzgerald Sent: Wednesday, 18 February 2015 10:05 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] question about Active Directory authentication Hello, I am currently running an IPA 3.3 server on Centos 7. I have 70 IPA client machines running Scientific Linux 6.6 and 150 users. User directories are auto-mounted from a Centos 7 file server. I have been informed that all computer users on our campus must now authenticate off of the University's Active Directory server, including all Linux machines. I have been looking through the IPA documentation and am getting myself confused and not completely understanding what needs to be done, thus I have some questions. 1. The docs talk about setting up a trust between the IPA server and the AD server. Will I need to change all of the IPA clients as well as the IPA server, or do I only need change the server and not have to touch the clients? 2. Do I even need to set up a full trust relationship just to authenticate my users with AD? 3. Since I already have 150 users, will I have to delete their IPA accounts before setting up the trust? W Sorry if my questions are a bit basic, but I need some guidance to get me started. Thanks! Dave ++++++++++++++++++++++++++++++ David Fitzgerald Department of Earth Sciences Millersville University Millersville, PA 17551 Phone: 717-871-2394 E-Mail: david.fitzgerald at millersville.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Feb 17 21:58:54 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 17 Feb 2015 16:58:54 -0500 Subject: [Freeipa-users] question about Active Directory authentication In-Reply-To: <1424208749846.77996@vuw.ac.nz> References: <958EF916EB06874283F9B8F820726DD3B9FFA10B@FSMB1.muad.local> <1424208749846.77996@vuw.ac.nz> Message-ID: <54E3B99E.10603@redhat.com> On 02/17/2015 04:34 PM, Steven Jones wrote: > > "I have been informed that all computer users on our campus must now > authenticate off of the University's Active Directory server, > including all Linux machines." > > > dictated by a clueless Windows ***** no doubt, ***sigh*** Here we are > keeping both separate as AD is so bad security wise, but want some low > risk trusts for certain groups of machines (common desktops). > > > If the expectation is its directly off the AD then you dont need IPA > at all. However without an expensive commercial addon per Linux > server/desktop you wont be able to do much management and control. > this has security implications, if you had say a finance or HR server > without these commercial tools you may find any AD user could get on > them, not what you would want. > > > So you have 2 options in keeping IPA, > > > a) trusts and you should be able keep your users. > > > b) winsync and passync and all the AD users are synced over to IPA. > Existing users stay as is, the ones in AD but not in IPA get pulled > over to IPA. > > > ***maybe*** > > > c) You might be able to do both winsync and trusts at the same time > then that is simpler provisioning. ie a user gets created in AD and > automatically gets created in IPA ready for you to put in the user > group you want. > I am not sure this is the best solution really. Trust and sync do not help each other. The fact that you have trust does not help you to provision users the way you describe. > > I'd like to do c) which I am looking at at present, if I ever get IPA > on RHEL6.6 upgraded to RHEL7.1! > > > > > regards > > Steven J > > ------------------------------------------------------------------------ > *From:* freeipa-users-bounces at redhat.com > on behalf of David Fitzgerald > > *Sent:* Wednesday, 18 February 2015 10:05 a.m. > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] question about Active Directory authentication > > Hello, > > I am currently running an IPA 3.3 server on Centos 7. I have 70 IPA > client machines running Scientific Linux 6.6 and 150 users. User > directories are auto-mounted from a Centos 7 file server. > > I have been informed that all computer users on our campus must now > authenticate off of the University's Active Directory server, > including all Linux machines. I have been looking through the IPA > documentation and am getting myself confused and not completely > understanding what needs to be done, thus I have some questions. > > 1.The docs talk about setting up a trust between the IPA server and > the AD server. Will I need to change all of the IPA clients as well > as the IPA server, or do I only need change the server and not have to > touch the clients? > > 2.Do I even need to set up a full trust relationship just to > authenticate my users with AD? > > 3.Since I already have 150 users, will I have to delete their IPA > accounts before setting up the trust? W > > Sorry if my questions are a bit basic, but I need some guidance to get > me started. > > Thanks! > > Dave > > ++++++++++++++++++++++++++++++ > > David Fitzgerald > > Department of Earth Sciences > > Millersville University > > Millersville, PA 17551 > > Phone: 717-871-2394 > > E-Mail: david.fitzgerald at millersville.edu > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Tue Feb 17 22:21:58 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 17 Feb 2015 22:21:58 +0000 Subject: [Freeipa-users] question about Active Directory authentication In-Reply-To: <54E3B99E.10603@redhat.com> References: <958EF916EB06874283F9B8F820726DD3B9FFA10B@FSMB1.muad.local> <1424208749846.77996@vuw.ac.nz>,<54E3B99E.10603@redhat.com> Message-ID: <1424211576331.81797@vuw.ac.nz> ***maybe*** c) You might be able to do both winsync and trusts at the same time then that is simpler provisioning. ie a user gets created in AD and automatically gets created in IPA ready for you to put in the user group you want. I am not sure this is the best solution really. Trust and sync do not help each other. The fact that you have trust does not help you to provision users the way you describe. 8><------ They achieve different things. How otherwise do I get 2000+ AD users into IPA? To me winsync allows automated provisioning of users into IPA via AD, this greatly reduces manual effort. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Feb 17 22:51:58 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 17 Feb 2015 17:51:58 -0500 Subject: [Freeipa-users] question about Active Directory authentication In-Reply-To: <1424211576331.81797@vuw.ac.nz> References: <958EF916EB06874283F9B8F820726DD3B9FFA10B@FSMB1.muad.local> <1424208749846.77996@vuw.ac.nz>, <54E3B99E.10603@redhat.com> <1424211576331.81797@vuw.ac.nz> Message-ID: <54E3C60E.7010105@redhat.com> On 02/17/2015 05:21 PM, Steven Jones wrote: > > >> >> ***maybe*** >> >> >> c) You might be able to do both winsync and trusts at the same time >> then that is simpler provisioning. ie a user gets created in AD and >> automatically gets created in IPA ready for you to put in the user >> group you want. >> > > I am not sure this is the best solution really. > Trust and sync do not help each other. The fact that you have trust > does not help you to provision users the way you describe. > > 8><------ > > They achieve different things. How otherwise do I get 2000+ AD users > into IPA? To me winsync allows automated provisioning of users into > IPA via AD, this greatly reduces manual effort. That I get. I do not understand how trust helps you in this case. > > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Tue Feb 17 23:24:45 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 17 Feb 2015 23:24:45 +0000 Subject: [Freeipa-users] question about Active Directory authentication In-Reply-To: <54E3C60E.7010105@redhat.com> References: <958EF916EB06874283F9B8F820726DD3B9FFA10B@FSMB1.muad.local> <1424208749846.77996@vuw.ac.nz>, <54E3B99E.10603@redhat.com> <1424211576331.81797@vuw.ac.nz>,<54E3C60E.7010105@redhat.com> Message-ID: <1424215342849.9144@vuw.ac.nz> Ok, So with winsync I will have the 2000+ users in IPA. Within IPA I have several high risk/impact groups of servers and many low. For the low risk/impact servers and most desktops they can trust what AD tells them. For the high risk/impact servers/applications we do not want to reply on AD for any authorisation so permissions for these will be isolated from AD inside IPA. The idea is if we lose AD or IPA we should not lose both via any cross-linking. regards Steven ________________________________ From: freeipa-users-bounces at redhat.com on behalf of Dmitri Pal Sent: Wednesday, 18 February 2015 11:51 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] question about Active Directory authentication On 02/17/2015 05:21 PM, Steven Jones wrote: ***maybe*** c) You might be able to do both winsync and trusts at the same time then that is simpler provisioning. ie a user gets created in AD and automatically gets created in IPA ready for you to put in the user group you want. I am not sure this is the best solution really. Trust and sync do not help each other. The fact that you have trust does not help you to provision users the way you describe. 8><------ They achieve different things. How otherwise do I get 2000+ AD users into IPA? To me winsync allows automated provisioning of users into IPA via AD, this greatly reduces manual effort. That I get. I do not understand how trust helps you in this case. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aegelhofer at rubiconproject.com Tue Feb 17 23:47:39 2015 From: aegelhofer at rubiconproject.com (Andrew Egelhofer) Date: Tue, 17 Feb 2015 15:47:39 -0800 Subject: [Freeipa-users] [Solved] Help with debugging HBACs Message-ID: Hi Sumit & FreeIPA Users- Your suggestion on updating the version of sssd worked like a charm. Consider this issue solved. Thanks Everyone, -Andrew On Mon, Feb 16, 2015 at 12:32 PM, Andrew Egelhofer < aegelhofer at rubiconproject.com> wrote: > ?Thank you for the reply Sumit - I will look into updating the version of > sssd. If that doesn't work, I will also try adding the > ?'sourceHostCategory' attribute to rules. Though, I would imagine I would > have to do this for *all* rules if I want them to work as intended. I'll > report back my findings tomorrow. > > Thanks, > -Andrew > > On Mon, Feb 16, 2015 at 12:40 AM, Sumit Bose wrote: > >> On Sat, Feb 14, 2015 at 12:52:10PM -0800, Andrew Egelhofer wrote: >> > Hi FreeIPA Users- >> > >> > I've deployed a FreeIPA instance in my Lab, and enrolled a single host, >> and >> > a single user ('testuser'). The only HBAC rule I currently have is the >> > stock allow_all. Yet, when I attempt to log into the host via ssh, it >> > closes the connection. >> > >> > $ ssh testuser@ >> > Warning: Permanently added ',' (RSA) to the list of known >> > hosts. >> > testuser@'s password: >> > Connection closed by >> > >> > The host I'm attempting to login to can correctly look up the user using >> > getent: >> > >> > # getent passwd testuser >> > testuser:*:168400003:168400003:Test User:/home/testuser:/bin/bash >> > >> > Scanning /var/log/secure, I see these entries: >> > >> > Feb 14 12:01:50 sshd[6528]: pam_unix(sshd:auth): authentication >> > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.30.3.58 >> > user=testuser >> > Feb 14 12:01:51 sshd[6528]: pam_sss(sshd:auth): authentication >> > success; logname= uid=0 euid=0 tty=ssh ruser= >> > rhost=172.30.3.58 user=testuser >> > Feb 14 12:01:51 sshd[6528]: pam_sss(sshd:account): Access denied >> for >> > user testuser: 6 (Permission denied) >> > >> > That tells me (From reading online) the user / password was correctly >> > authenticated, but failed authorization due to HBAC rules. I've tested >> the >> > rule using the 'hbactest' utility and it passes >> > >> > [root@ ~]# ipa hbactest --user=testuser --host= >> --service=sshd >> > -------------------- >> > Access granted: True >> > -------------------- >> > Matched rules: allow_all >> > >> > I'm at a loss here, because If I comment out the line: >> > >> > account [default=bad success=ok user_unknown=ignore] pam_sss.so >> > >> > in /etc/pam.d/system-auth, the user is able to login. >> > >> > So what am I missing here? Is there a way I can debug HBAC rules? I've >> > already set debug_level = 10 in /etc/sssd/sssd.conf, and I see its able >> to >> > access the HBAC 'allow_all' rule in the log >> /var/log/sssd/sssd_. >> > .log: >> > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [sdap_get_generic_done] (7): Total count [0] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> [hbac_attrs_to_rule] >> > (7): Processing rule [allow_all] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_user_attrs_to_rule] (7): Processing users for rule [allow_all] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_get_category] >> > (5): Category is set to 'all'. >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_service_attrs_to_rule] (7): Processing PAM services for rule >> > [allow_all] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_get_category] >> > (5): Category is set to 'all'. >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_thost_attrs_to_rule] (7): Processing target hosts for rule >> [allow_all] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_get_category] >> > (5): Category is set to 'all'. >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_shost_attrs_to_rule] (7): Processing source hosts for rule >> [allow_all] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_host_attrs_to_rule] (4): No host specified, rule will never apply. >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_eval_user_element] (7): [12] groups for [admin] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_eval_user_element] (7): Added group [admins] for user [admin] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_eval_user_element] (8): Skipping non-group memberOf >> [cn=replication >> > administrators,cn=privileges,cn=pbac,dc=,dc=] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=add >> > replication agreements,cn=permissions,cn=pbac,dc=,dc=] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=modify >> > replication agreements,cn=permissions,cn=pbac,dc=,dc=] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=remove >> > replication agreements,cn=permissions,cn=pbac,dc=,dc=] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=host >> > enrollment,cn=privileges,cn=pbac,dc=,dc=] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=manage >> host >> > keytab,cn=permissions,cn=pbac,dc=,dc=] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=enroll a >> > host,cn=permissions,cn=pbac,dc=,dc=] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=add >> > krbprincipalname to a host,cn=permissions,cn=pbac,dc=,dc=] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=unlock >> user >> > accounts,cn=permissions,cn=pbac,dc=,dc=] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=manage >> > service keytab,cn=permissions,cn=pbac,dc=,dc=] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [hbac_eval_user_element] (7): Added group [trust admins] for user >> [admin] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] >> > [ipa_hbac_evaluate_rules] (3): Access denied by HBAC rules >> > >> > IPA server: >> > # rpm -q ipa-server sssd >> > ipa-server-3.0.0-42.el6.centos.x86_64 >> > sssd-1.11.6-30.el6_6.3.x86_64 >> > # cat /etc/redhat-release >> > CentOS release 6.5 (Final) >> > >> > Client: >> > # cat /etc/redhat-release >> > CentOS release 5.8 (Final) >> > # rpm -q sssd >> > sssd-1.5.1-49.el5_8.1 >> >> This version is quite old and I guess >> >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> [hbac_shost_attrs_to_rule] (7): Processing source hosts for rule [allow_all] >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> [hbac_host_attrs_to_rule] (4): No host specified, rule will never apply. >> >> is causing the issue. At that time it was possible to specific source >> hosts in HBAC rules. But since there is no reliable way to determine >> the source host (we have to rely on the data libpam is able to give us). >> we removed this in later versions. If you started with an old IPA server >> the related attributes are kept during updates, but newer versions like >> ipa v3 do not set them anymore. >> >> First I would recommend to update SSSD. If there is really no wy to >> update SSSD adding an attribute 'sourceHostCategory: all' to the LDAP >> object of the allow_all rule might help. >> >> HTH >> >> bye, >> Sumit >> > >> > Any help is appreciated. >> > >> > Thanks, >> > -Andrew >> >> > -- >> > Manage your subscription for the Freeipa-users mailing list: >> > https://www.redhat.com/mailman/listinfo/freeipa-users >> > Go To http://freeipa.org for more info on the project >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.zin at savoirfairelinux.com Wed Feb 18 06:23:57 2015 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Wed, 18 Feb 2015 01:23:57 -0500 (EST) Subject: [Freeipa-users] issues with sudo on RHEL5.8 In-Reply-To: <54E360BC.2040309@redhat.com> References: <1772774127.3318987.1424163151041.JavaMail.root@savoirfairelinux.com> <068660BA-2349-4D8D-A8FC-F03F0D61B819@allegrogroup.com> <2052617552.3341912.1424168298665.JavaMail.root@savoirfairelinux.com> <54E360BC.2040309@redhat.com> Message-ID: <2078771633.548597.1424240637374.JavaMail.root@savoirfairelinux.com> sure. Let me come back on that matter a bit later on next week. ----- Mail original ----- De: "Dmitri Pal" ?: freeipa-users at redhat.com Envoy?: Mardi 17 F?vrier 2015 19:39:40 Objet: Re: [Freeipa-users] issues with sudo on RHEL5.8 On 02/17/2015 05:18 AM, Nicolas Zin wrote: > Thanks, > > that helps! > I mistyped binddn and bindpw > > ----- Mail original ----- > De: "Lukasz Jaworski" > ?: "Nicolas Zin" > Cc: freeipa-users at redhat.com > Envoy?: Mardi 17 F?vrier 2015 13:31:20 > Objet: Re: [Freeipa-users] issues with sudo on RHEL5.8 > >> With a RHEL7 IDM installation, I try to make sudo working. >> On RHEL6 no problem (via sssd) >> On RHEL5.8 I don't manage to make it working (credential are good, I manage to request the schema, see below) >> Where can I found more logs? >> What did I forget? >> [root at srv-rhel58-01 ~]# cat /etc/nss_ldap.conf >> bindn uid=sudo,cn=sysaccounts,cn=etc,dc=company,dc=com >> binpw redhat5Sudo >> ssl start_tls >> tls_cacertfile /etc/openldap/cacerts/ipa.crt >> #tls_cacert /etc/openldap/cacerts/ipa.crt >> tls_checkpeer yes >> #uri ldap://srv-idm7-01.company.com, ldap://srv-idm7-02.company.com >> uri ldap://srv-idm7-01.company.com >> sudoers_base ou=SUDOers,dc=company,dc=com >> sudoers_debug: 2 > change last line (remove ":") to: > sudoers_debug 2 > > And then try sudo. > > Check: > /etc/nsswitch.conf > should be: > sudoers: files ldap > > Best regards, > Ender > We quite frequently get questions about how to configure SUDO with IPA from RHEL5.x clients. Would you mind sharing this configuration as a howto solution? http://www.freeipa.org/page/HowTos -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project From Less at imagine-sw.com Wed Feb 18 07:26:40 2015 From: Less at imagine-sw.com (Les Stott) Date: Wed, 18 Feb 2015 07:26:40 +0000 Subject: [Freeipa-users] bug in pki during install of CA replica and workaround/solution In-Reply-To: <4ED173A868981548967B4FCA27072226280B8783@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA27072226280AEAB2@AACMBXP04.exchserver.com> <54D4D23A.5070305@redhat.com> <54D4D552.8000805@redhat.com> <4ED173A868981548967B4FCA27072226280AFA9F@AACMBXP04.exchserver.com> <4ED173A868981548967B4FCA27072226280B8783@AACMBXP04.exchserver.com> Message-ID: <4ED173A868981548967B4FCA27072226280BD4CC@AACMBXP04.exchserver.com> Has anyone got any ideas on the below errors I am now receiving? Thanks in advance, Les > > > > I will test this out (update to 3.7.19-260) next week as I've got a > > few more CA replicas to setup. > > > > I'm still having issues. Different one this time. > > As I have previously worked around the install of CA replicas in my > production Production environment as above, I went to setup CA replication > in DR (both environments are completely separate). > > Make sure I did a yum update for all packages, including selinux-policy, and > also making sure all needed modules were loaded in httpd.conf I proceeded > to retry installation of CA replication. However, it failed with the following: > > Note: sb2sys01.domain.com is the replica I am trying to install.... > > (abbreviated below) > > ############################################# > Attempting to connect to: sb2sys01.domain.com:9445 Connected. > Posting Query = > https://sb2sys01.domain.com:9445//ca/admin/console/config/wizard?p=7& > op=next&xml=true&__password=XXXXXXXX&path=ca.p12 > RESPONSE STATUS: HTTP/1.1 200 OK > RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: > Content-Type: application/xml;charset=UTF-8 RESPONSE HEADER: Date: Fri, > 13 Feb 2015 08:09:35 GMT RESPONSE HEADER: Connection: close version="1.0" encoding="UTF-8"?> > > > admin/console/config/restorekeycertpanel.vm > > failure > > The pkcs12 file is not correct. > 19 > Error in RestoreKeyCertPanel(): updateStatus returns failure > ERROR: ConfigureCA: RestoreKeyCertPanel() failure > ERROR: unable to create CA > > ############################################ > > In /var/log/pki-ca/catalina.out I see... > > CMS Warning: FAILURE: Cannot build CA chain. Error > java.security.cert.CertificateException: Certificate is not a PKCS #11 > certificate|FAILURE: authz instance DirAclAuthz initialization failed and > skipped, error=Property internaldb.ldapconn.port missing value| Server is > started. > > Nothing gets populated in /etc/pki-ca/CS.cfg (based on comparison with a > working system). > > grep DirAclAuthz /etc/pki-ca/CS.cfg > authz.impl.DirAclAuthz.class=com.netscape.cms.authorization.DirAclAuthz > authz.instance.DirAclAuthz.ldap=internaldb > authz.instance.DirAclAuthz.pluginName=DirAclAuthz > authz.instance.DirAclAuthz.ldap._000=## > authz.instance.DirAclAuthz.ldap._001=## Internal Database > authz.instance.DirAclAuthz.ldap._002=## > authz.instance.DirAclAuthz.ldap.basedn= > authz.instance.DirAclAuthz.ldap.maxConns=15 > authz.instance.DirAclAuthz.ldap.minConns=3 > authz.instance.DirAclAuthz.ldap.ldapauth.authtype=BasicAuth > authz.instance.DirAclAuthz.ldap.ldapauth.bindDN=cn=Directory Manager > authz.instance.DirAclAuthz.ldap.ldapauth.bindPWPrompt=Internal LDAP > Database authz.instance.DirAclAuthz.ldap.ldapauth.clientCertNickname= > authz.instance.DirAclAuthz.ldap.ldapconn.host= > authz.instance.DirAclAuthz.ldap.ldapconn.port= > authz.instance.DirAclAuthz.ldap.ldapconn.secureConn=false > authz.instance.DirAclAuthz.ldap.multipleSuffix.enable=false > > The CA cert looks ok to me on the master. It does get copied to the replica in > /usr/share/ipa/html/ca.crt > > I don't see any errors in httpd error or access logs on the master or the > intended replica. > > The ipa-pki-proxy.conf config has the profilesubmit section. > > # matches for ee port > "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenI > nfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberR > ange|^/ca/ee/ca/getCRL|^/ca/ee/ca/profileSubmit"> > > I can confirm that pki-cad does start (but is unconfigured) and that it does > listen on port 9445. > > # netstat -apn |grep 9445 > tcp 0 0 :::9445 :::* LISTEN 31264/java > # service pki-cad status > pki-ca (pid 31264) is running... [ OK ] > 'pki-ca' must still be CONFIGURED! > (see /var/log/pki-ca-install.log) > > I am not sure what to try next. > > Appreciate any help to get over this error. > > Thanks, > > Les From thomas.raehalme at codecenter.fi Wed Feb 18 07:34:25 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Wed, 18 Feb 2015 09:34:25 +0200 Subject: [Freeipa-users] dirsrv hangs, 0% CPU util In-Reply-To: <20150216064443.GG26748@redhat.com> References: <54E111AE.4090600@redhat.com> <54E12444.8090604@redhat.com> <20150216064443.GG26748@redhat.com> Message-ID: Hi! On Mon, Feb 16, 2015 at 8:44 AM, Alexander Bokovoy wrote: > I suspect you've triggered https://fedorahosted.org/freeipa/ticket/4586 > and https://fedorahosted.org/freeipa/ticket/4635 -- slapi-nis plugin > configuration does not limit itself to $SUFFIX and listens to changes in > cn=changelog too so it may deadlock with a replication traffic. > > We fixed these partly by changing slapi-nis configuration, partly by > fixing bugs in 389-ds. > > I wonder if amending your slapi-nis config to avoid triggering internal > searches on cn=changelog would be enough. > > Is it possible to go around this issue by disabling replication? If so, is ipa-replica-manage disconnect enough or should we use del instead? Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Feb 18 07:34:53 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 Feb 2015 09:34:53 +0200 Subject: [Freeipa-users] No LDAPS for dirsrv In-Reply-To: References: <54E36DED.5060808@oberlin.edu> <54E37CA3.7090002@redhat.com> Message-ID: <20150218073453.GZ26748@redhat.com> On Tue, 17 Feb 2015, Thomas Raehalme wrote: >Hi! > >On Tue, Feb 17, 2015 at 8:43 PM, Thomas Raehalme < >thomas.raehalme at codecenter.fi> wrote: > >> Hi! >> >> On Tue, Feb 17, 2015 at 7:38 PM, Rob Crittenden >> wrote: >> >>> > Now I only wish we could resolve what's causing the dirsrv process to >>> > hang (wrote about that in another message last Sunday) about 10 minutes >>> > after IPA services were started. >>> >>> Evidence suggests that the last upgrade failed so I'd start there. It is >>> possible some plugins aren't configured properly, for example. >>> >>> >After having restart ipa service, the upgrade command was completed >successfully: > ># ipa-ldap-updater --upgrade >Upgrading IPA: > [1/8]: stopping directory server > [2/8]: saving configuration > [3/8]: disabling listeners > [4/8]: starting directory server > [5/8]: upgrading server > [6/8]: stopping directory server > [7/8]: restoring configuration > [8/8]: starting directory server >Done. > >Now dirsrv was stopped in 2 second when the previous time was over 500 >seconds. > >Unfortunately this still didn't resolve the issue. After the system has >been online for about 10 minutes, named starts complaining: > >Feb 17 21:04:14 ipa named[31117]: LDAP query timed out. Try to adjust >"timeout" parameter > >Also ldapsearch just hangs if you try to perform any queries. > >Any ideas what could go wrong here? So, can you get us a backtrace again? -- / Alexander Bokovoy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From abokovoy at redhat.com Wed Feb 18 07:48:08 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 Feb 2015 09:48:08 +0200 Subject: [Freeipa-users] dirsrv hangs, 0% CPU util In-Reply-To: References: <54E111AE.4090600@redhat.com> <54E12444.8090604@redhat.com> <20150216064443.GG26748@redhat.com> Message-ID: <20150218074808.GA26748@redhat.com> On Wed, 18 Feb 2015, Thomas Raehalme wrote: >Hi! > >On Mon, Feb 16, 2015 at 8:44 AM, Alexander Bokovoy >wrote: > >> I suspect you've triggered https://fedorahosted.org/freeipa/ticket/4586 >> and https://fedorahosted.org/freeipa/ticket/4635 -- slapi-nis plugin >> configuration does not limit itself to $SUFFIX and listens to changes in >> cn=changelog too so it may deadlock with a replication traffic. >> >> We fixed these partly by changing slapi-nis configuration, partly by >> fixing bugs in 389-ds. >> >> I wonder if amending your slapi-nis config to avoid triggering internal >> searches on cn=changelog would be enough. >> >> >Is it possible to go around this issue by disabling replication? If so, is >ipa-replica-manage disconnect enough or should we use del instead? I think you are solving wrong issue. Changing slapi-nis configuration to ignore cn=changelog was the change we did for FreeIPA 4.1. We ended up ignoring a bit more subtrees too: https://fedorahosted.org/freeipa/ticket/4635#comment:16 You need to show backtraces of nsslapd when it doesn't respond on LDAP queries to verify it is the same issue but I suspect it is very likely the issue. -- / Alexander Bokovoy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From sbose at redhat.com Wed Feb 18 08:06:48 2015 From: sbose at redhat.com (Sumit Bose) Date: Wed, 18 Feb 2015 09:06:48 +0100 Subject: [Freeipa-users] [Solved] Help with debugging HBACs In-Reply-To: References: Message-ID: <20150218080648.GA2822@p.redhat.com> On Tue, Feb 17, 2015 at 03:47:39PM -0800, Andrew Egelhofer wrote: > Hi Sumit & FreeIPA Users- > > Your suggestion on updating the version of sssd worked like a charm. > Consider this issue solved. Thank you for the feedback, glad I could help. bye, Sumit > > Thanks Everyone, > -Andrew > > On Mon, Feb 16, 2015 at 12:32 PM, Andrew Egelhofer < > aegelhofer at rubiconproject.com> wrote: > > > ?Thank you for the reply Sumit - I will look into updating the version of > > sssd. If that doesn't work, I will also try adding the > > ?'sourceHostCategory' attribute to rules. Though, I would imagine I would > > have to do this for *all* rules if I want them to work as intended. I'll > > report back my findings tomorrow. > > > > Thanks, > > -Andrew > > > > On Mon, Feb 16, 2015 at 12:40 AM, Sumit Bose wrote: > > > >> On Sat, Feb 14, 2015 at 12:52:10PM -0800, Andrew Egelhofer wrote: > >> > Hi FreeIPA Users- > >> > > >> > I've deployed a FreeIPA instance in my Lab, and enrolled a single host, > >> and > >> > a single user ('testuser'). The only HBAC rule I currently have is the > >> > stock allow_all. Yet, when I attempt to log into the host via ssh, it > >> > closes the connection. > >> > > >> > $ ssh testuser@ > >> > Warning: Permanently added ',' (RSA) to the list of known > >> > hosts. > >> > testuser@'s password: > >> > Connection closed by > >> > > >> > The host I'm attempting to login to can correctly look up the user using > >> > getent: > >> > > >> > # getent passwd testuser > >> > testuser:*:168400003:168400003:Test User:/home/testuser:/bin/bash > >> > > >> > Scanning /var/log/secure, I see these entries: > >> > > >> > Feb 14 12:01:50 sshd[6528]: pam_unix(sshd:auth): authentication > >> > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.30.3.58 > >> > user=testuser > >> > Feb 14 12:01:51 sshd[6528]: pam_sss(sshd:auth): authentication > >> > success; logname= uid=0 euid=0 tty=ssh ruser= > >> > rhost=172.30.3.58 user=testuser > >> > Feb 14 12:01:51 sshd[6528]: pam_sss(sshd:account): Access denied > >> for > >> > user testuser: 6 (Permission denied) > >> > > >> > That tells me (From reading online) the user / password was correctly > >> > authenticated, but failed authorization due to HBAC rules. I've tested > >> the > >> > rule using the 'hbactest' utility and it passes > >> > > >> > [root@ ~]# ipa hbactest --user=testuser --host= > >> --service=sshd > >> > -------------------- > >> > Access granted: True > >> > -------------------- > >> > Matched rules: allow_all > >> > > >> > I'm at a loss here, because If I comment out the line: > >> > > >> > account [default=bad success=ok user_unknown=ignore] pam_sss.so > >> > > >> > in /etc/pam.d/system-auth, the user is able to login. > >> > > >> > So what am I missing here? Is there a way I can debug HBAC rules? I've > >> > already set debug_level = 10 in /etc/sssd/sssd.conf, and I see its able > >> to > >> > access the HBAC 'allow_all' rule in the log > >> /var/log/sssd/sssd_. > >> > .log: > >> > > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [sdap_get_generic_done] (7): Total count [0] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> [hbac_attrs_to_rule] > >> > (7): Processing rule [allow_all] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_user_attrs_to_rule] (7): Processing users for rule [allow_all] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_get_category] > >> > (5): Category is set to 'all'. > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_service_attrs_to_rule] (7): Processing PAM services for rule > >> > [allow_all] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_get_category] > >> > (5): Category is set to 'all'. > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_thost_attrs_to_rule] (7): Processing target hosts for rule > >> [allow_all] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] [hbac_get_category] > >> > (5): Category is set to 'all'. > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_shost_attrs_to_rule] (7): Processing source hosts for rule > >> [allow_all] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_host_attrs_to_rule] (4): No host specified, rule will never apply. > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_eval_user_element] (7): [12] groups for [admin] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_eval_user_element] (7): Added group [admins] for user [admin] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_eval_user_element] (8): Skipping non-group memberOf > >> [cn=replication > >> > administrators,cn=privileges,cn=pbac,dc=,dc=] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=add > >> > replication agreements,cn=permissions,cn=pbac,dc=,dc=] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=modify > >> > replication agreements,cn=permissions,cn=pbac,dc=,dc=] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=remove > >> > replication agreements,cn=permissions,cn=pbac,dc=,dc=] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=host > >> > enrollment,cn=privileges,cn=pbac,dc=,dc=] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=manage > >> host > >> > keytab,cn=permissions,cn=pbac,dc=,dc=] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=enroll a > >> > host,cn=permissions,cn=pbac,dc=,dc=] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=add > >> > krbprincipalname to a host,cn=permissions,cn=pbac,dc=,dc=] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=unlock > >> user > >> > accounts,cn=permissions,cn=pbac,dc=,dc=] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_eval_user_element] (8): Skipping non-group memberOf [cn=manage > >> > service keytab,cn=permissions,cn=pbac,dc=,dc=] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [hbac_eval_user_element] (7): Added group [trust admins] for user > >> [admin] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > >> > [ipa_hbac_evaluate_rules] (3): Access denied by HBAC rules > >> > > >> > IPA server: > >> > # rpm -q ipa-server sssd > >> > ipa-server-3.0.0-42.el6.centos.x86_64 > >> > sssd-1.11.6-30.el6_6.3.x86_64 > >> > # cat /etc/redhat-release > >> > CentOS release 6.5 (Final) > >> > > >> > Client: > >> > # cat /etc/redhat-release > >> > CentOS release 5.8 (Final) > >> > # rpm -q sssd > >> > sssd-1.5.1-49.el5_8.1 > >> > >> This version is quite old and I guess > >> > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > >> [hbac_shost_attrs_to_rule] (7): Processing source hosts for rule [allow_all] > >> > (Fri Feb 13 21:38:15 2015) [sssd[be[.]]] > > >> [hbac_host_attrs_to_rule] (4): No host specified, rule will never apply. > >> > >> is causing the issue. At that time it was possible to specific source > >> hosts in HBAC rules. But since there is no reliable way to determine > >> the source host (we have to rely on the data libpam is able to give us). > >> we removed this in later versions. If you started with an old IPA server > >> the related attributes are kept during updates, but newer versions like > >> ipa v3 do not set them anymore. > >> > >> First I would recommend to update SSSD. If there is really no wy to > >> update SSSD adding an attribute 'sourceHostCategory: all' to the LDAP > >> object of the allow_all rule might help. > >> > >> HTH > >> > >> bye, > >> Sumit > >> > > >> > Any help is appreciated. > >> > > >> > Thanks, > >> > -Andrew > >> > >> > -- > >> > Manage your subscription for the Freeipa-users mailing list: > >> > https://www.redhat.com/mailman/listinfo/freeipa-users > >> > Go To http://freeipa.org for more info on the project > >> > >> > > From thomas.raehalme at codecenter.fi Wed Feb 18 08:10:27 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Wed, 18 Feb 2015 10:10:27 +0200 Subject: [Freeipa-users] No LDAPS for dirsrv In-Reply-To: <20150218073453.GZ26748@redhat.com> References: <54E36DED.5060808@oberlin.edu> <54E37CA3.7090002@redhat.com> <20150218073453.GZ26748@redhat.com> Message-ID: On Wed, Feb 18, 2015 at 9:34 AM, Alexander Bokovoy wrote: > > Unfortunately this still didn't resolve the issue. After the system has >> been online for about 10 minutes, named starts complaining: >> Also ldapsearch just hangs if you try to perform any queries. >> Any ideas what could go wrong here? >> > So, can you get us a backtrace again? > Here is a summary of what is going on: After a fresh start of IPA master with 'ipactl start' the system goes wrong after 5-10 minutes. What happens first is that KDC stops responding: kinit thomas.raehalme kinit: Cannot contact any KDC for realm 'EXAMPLE.COM' while getting initial credentials LDAP is still operational, however. It can be verified with ldapsearch. Finally, after total of 15 minutes LDAP is also not responding: Feb 18 10:00:12 ipa named[7410]: LDAP query timed out. Try to adjust "timeout" parameter Now I took some stacktraces which I will e-mail to you and Rob directly. When I then try to stop dirsrv, it responds but seems to wait indefinitely: [18/Feb/2015:10:03:03 +0200] - slapd shutting down - signaling operation threads [18/Feb/2015:10:03:03 +0200] - slapd shutting down - waiting for 30 threads to terminate I took two stacktraces from this situation as well. Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.zin at savoirfairelinux.com Wed Feb 18 08:13:46 2015 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Wed, 18 Feb 2015 03:13:46 -0500 (EST) Subject: [Freeipa-users] ad relation with winsync In-Reply-To: <487613314.673165.1423719446965.JavaMail.root@savoirfairelinux.com> References: <313055385.142650.1423642007008.JavaMail.root@savoirfairelinux.com> <599734995.147060.1423653496313.JavaMail.root@savoirfairelinux.com> <54DB6DE7.6070007@redhat.com> <487613314.673165.1423719446965.JavaMail.root@savoirfairelinux.com> Message-ID: <2047927347.576943.1424247226716.JavaMail.root@savoirfairelinux.com> Hi everyone, I'm back with my winsync replication. The replication process works fine, but whenI specify "OU=Linux,DC=mycompany,DC=com" where 2 users have been created, nothing is replicated. btw this is a big AD (90k objects). is it a problem? (idrange for example) If I replicate "cn=Users,DC=company,DC=com" I have users replicated. but I'm not sure that all are replicated. ----- Mail original ----- De: "Nicolas Zin" ?: "Rich Megginson" Cc: freeipa-users at redhat.com Envoy?: Jeudi 12 F?vrier 2015 09:37:26 Objet: Re: [Freeipa-users] ad relation with winsync Next step: having the replication working. The customer dont want to give to my sync user "Replicating directory changes", "Account Operator" and "Enterprise Read-Only Domain Controller" attributs and just want a "oneway replication". For the one way replication, I followed the documentation But I don't see any imported users. Do you have an idea? Are some of the Windows attributs necessary even for a one way (windows to linux) synchronisation? Regards, Nicolas ----- Mail original ----- De: "Rich Megginson" ?: freeipa-users at redhat.com Envoy?: Mercredi 11 F?vrier 2015 18:57:43 Objet: Re: [Freeipa-users] ad relation with winsync On 02/11/2015 04:18 AM, Nicolas Zin wrote: > I reply to myself. > This was certainly a Windows configurarion issue. I went further: > ipa-replica-manage connect --winsync --binddb cn=Administrator,cn=Users,dc=company,dc=com --bindpwd --passsync whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com -v > Directory Manager password: ******** > > Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate database for srv7idm2.ipa.company.com > ipa: INFO: AD Suffix is: DC=company,DC=com > The user for Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=company,dc=com > ipa: INFO: Added new sync agreement, waiting for it to become ready. . . > ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP error: Connect error: start: 0 end: 0 > ipa: INFO: Agreement is ready, starting replication . . . > Starting replication, please wait until this has completed. > > [srv7idm2.ipa.company.com] reports: Update failed! Status: [-11 - LDAP error: Connect error] > > > > So apparently I manage to connect to AD but something went wrong after? > How can I debug it? You can test it like this: # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN ldapsearch -xLLLZZ -H ldap://fqdn.of.ad.host -s base -b "DC=company,DC=com" -D "cn=Administrator,cn=Users,dc=company,dc=com" -w "password" > > > > Regards, > > > > Nicolas Zin > > > > ----- Mail original ----- > De: "Nicolas Zin" > ?: freeipa-users at redhat.com > Envoy?: Mercredi 11 F?vrier 2015 12:06:47 > Objet: [Freeipa-users] ad relation with winsync > > Hi, > > I now try to establish a winsync relation with a Windows 2008R2. > I installed IDM 3.3 on RHEL7. > > When I try to create the replication: > ipa-replica-manage connect --winsync --binddb cn=Administrator,cn=Users,dc=company,dc=com --bindpwd --passsync whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com > Directory Manager password: ******** > > Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate database for srv7idm2.ipa.company.com > ipa: INFO: Failed to connect to AD srever dc.company.com > ipa: INFO: The error was: {'info': 'TLS error -8157:Certificate extension not found','desc': 'Connect error'} > Failed to setup winsync replication > > > Do you have an idea, what's wrong? > Also is it possible to point to port 636 instead? > > > Notes: > - On the windows side, ssl has been activated (with pain) and ldp.exe manage to connect via ssl on the 636 port correctly (so the certificate is in place). I don't know how to check it is working properly on port 389, i.e. START_TLS works > - I checked that the 2 box have the same time (ntp) > - I nearly manage to make it working once, but I got another error during replication > > > > Nicolas Zin > nicolas.zin at savoirfairelinux.com > Ligne directe: 514-276-5468 poste 135 > > Fax : 514-276-5465 > 7275 Saint Urbain > Bureau 200 > Montr?al, QC, H2R 2Y5 > > > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project From pspacek at redhat.com Wed Feb 18 10:53:07 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 18 Feb 2015 11:53:07 +0100 Subject: [Freeipa-users] Cross-Realm authentification In-Reply-To: <54822289.3090901@redhat.com> References: <547F1233.4020709@kit.edu> <20141203135351.GG16288@redhat.com> <5480287B.4050406@kit.edu> <20141204110702.GH16288@redhat.com> <5481A47B.2000005@kit.edu> <20141205125637.GM16288@redhat.com> <20141205130426.GN16288@redhat.com> <5481BF4D.5060006@kit.edu> <5481C02D.6000805@redhat.com> <20141205202655.GR16288@redhat.com> <20141205205307.GS16288@redhat.com> <54822289.3090901@redhat.com> Message-ID: <54E46F13.9030700@redhat.com> On 5.12.2014 22:24, Petr Spacek wrote: > On 5.12.2014 21:53, Alexander Bokovoy wrote: >> On Fri, 05 Dec 2014, Alexander Bokovoy wrote: >>> On Fri, 05 Dec 2014, Petr Spacek wrote: >>>> On 5.12.2014 15:21, Andreas Ladanyi wrote: >>>>> Am 05.12.2014 um 14:04 schrieb Alexander Bokovoy: >>>>>> >>>>>>>>> >>>>>>>> Ok, i see one difference: i didnt use the "-requires_preauth" flag. Why >>>>>>>> did you use them ? >>>>>>> Because this is recommended by MIT documentation. The link between >>>>>>> realms has to be protected well, including preauth and good passwords >>>>>>> for the cross-realm principals. >>>>>>> >>>>>>> >>>>>>>> Is it possible or a good idea to add my trust domain, which isnt a AD >>>>>>>> domain, manualy to IPA 3.3 ? >>>>>>> Well, you can hack of course, that's up to you. I haven't checked that >>>>>>> myself and cannot give you definitive answer on this path, though. >>>>> At this time i havent an idea off the steps in detail how to do that. >>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> We may reconsider this check and instead of KRB5KRB_AP_ERR_ILL_CR_TKT >>>>>>>>> return KRB5_PLUGIN_NO_HANDLE to allow fallback to krb5.conf-defined >>>>>>>>> capaths but I remember we had some issues with krb5 versions prior to >>>>>>>>> 1.12 where capaths from krb5.conf were blocking work of the DAL >>>>>>>>> driver. >>>>>>>> I use MIT Kerberos 1.6 from OpenCSW on Solaris and FreeIPA 3.3.5. So >>>>>>>> this shouldnt be a problem ?! >>>>> Sorry i made a little typing mistake. The foreign realm ist MIT Kerberos >>>>> 1.9.2 and not 1.6 >>>>>>> 1.6 does not support cross-realm communication as support for RFC6806 >>>>>>> was added only in 1.7. So I don't think your setup would have any chance >>>>>>> to work at all. >>>>>> Hm.. on the other hand, 1.6 documentation talks about it: >>>>>> http://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Cross_002drealm-Authentication >>>>>> >>>>>> >>>>>> So may be their changelogs aren't as complete as they should be. :) >>>>>> >>>>>> With the link above you can also see with disabling preauth on the >>>>>> cross-realm krbtgt records is recommended. >>>>>> >>>>>> But I think most of your issues were because of the 88 port not being >>>>>> available and no other means to traverse firewall were configured. >>>>> I will look particular for that. >>>>> >>>>> There is no firewall between the two KDCs. >>>>> >>>>>> That >>>>>> is, aside from the fact that IPA will reject cross-realm tickets because >>>>>> of how we programmed DAL driver as I explained above. >>>>> >>>>> >>>>> I dont know in detail what DAL is doing. >>>>> >>>>> OK, it sounds like with IPA my setup wont be very easy :-) >>>> >>>> I guess that Alexander or Simo could point you to the line in the source code >>>> you have to change (or send you one-line patch?) but you will have to >>>> recompile the driver from source. >>>> >>>> Do you want to try this way? >>> Attached please find a patch that solves the issue of cross-realm trust >>> for me: >>> [root at ipa-05-m ~]# kinit admin >>> Password for admin at IPA5.TEST: [root at ipa-05-m ~]# KRB5_TRACE=/dev/stderr kvno >>> -S host master.f21.test >>> [16101] 1417810641.441614: Convert service host (service with host as >>> instance) on host master.f21.test to principal >>> [16101] 1417810641.449424: Remote host after forward canonicalization: >>> master.f21.test >>> [16101] 1417810641.449501: Remote host after reverse DNS processing: >>> master.f21.test >>> [16101] 1417810641.449549: Get host realm for master.f21.test >>> [16101] 1417810641.449593: Use local host master.f21.test to get host realm >>> [16101] 1417810641.449630: Look up master.f21.test in the domain_realm map >>> [16101] 1417810641.449655: Look up .f21.test in the domain_realm map >>> [16101] 1417810641.449677: Temporary realm is F21.TEST >>> [16101] 1417810641.449697: Got realm F21.TEST for host master.f21.test >>> [16101] 1417810641.449724: Got service principal host/master.f21.test at F21.TEST >>> [16101] 1417810641.449750: Getting credentials admin at IPA5.TEST -> >>> host/master.f21.test at F21.TEST using ccache KEYRING:persistent:0:0 >>> [16101] 1417810641.449888: Retrieving admin at IPA5.TEST -> >>> host/master.f21.test at F21.TEST from KEYRING:persistent:0:0 with result: >>> -1765328243/Matching credential not found >>> [16101] 1417810641.449946: Retrieving admin at IPA5.TEST -> >>> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: >>> -1765328243/Matching credential not found >>> [16101] 1417810641.450065: Retrieving admin at IPA5.TEST -> >>> krbtgt/IPA5.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: 0/Success >>> [16101] 1417810641.450095: Starting with TGT for client realm: >>> admin at IPA5.TEST -> krbtgt/IPA5.TEST at IPA5.TEST >>> [16101] 1417810641.450144: Retrieving admin at IPA5.TEST -> >>> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: >>> -1765328243/Matching credential not found >>> [16101] 1417810641.450171: Requesting TGT krbtgt/F21.TEST at IPA5.TEST using >>> TGT krbtgt/IPA5.TEST at IPA5.TEST >>> [16101] 1417810641.450216: Generated subkey for TGS request: aes256-cts/3A06 >>> [16101] 1417810641.450267: etypes requested in TGS request: aes256-cts, >>> aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts >>> [16101] 1417810641.450364: Encoding request body and padata into FAST request >>> [16101] 1417810641.450422: Sending request (890 bytes) to IPA5.TEST >>> [16101] 1417810641.450559: Sending initial UDP request to dgram >>> 192.168.5.109:88 >>> [16101] 1417810641.452191: Received answer from dgram 192.168.5.109:88 >>> [16101] 1417810641.452241: Response was from master KDC >>> [16101] 1417810641.452273: Decoding FAST response >>> [16101] 1417810641.452366: FAST reply key: aes256-cts/ADA3 >>> [16101] 1417810641.452420: TGS reply is for admin at IPA5.TEST -> >>> krbtgt/F21.TEST at IPA5.TEST with session key aes256-cts/2C28 >>> [16101] 1417810641.452453: TGS request result: 0/Success >>> [16101] 1417810641.452479: Removing admin at IPA5.TEST -> >>> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 >>> [16101] 1417810641.452509: Storing admin at IPA5.TEST -> >>> krbtgt/F21.TEST at IPA5.TEST in KEYRING:persistent:0:0 >>> [16101] 1417810641.452572: Received TGT for service realm: >>> krbtgt/F21.TEST at IPA5.TEST >>> [16101] 1417810641.452600: Requesting tickets for >>> host/master.f21.test at F21.TEST, referrals on >>> [16101] 1417810641.452626: Generated subkey for TGS request: aes256-cts/599E >>> [16101] 1417810641.452662: etypes requested in TGS request: aes256-cts, >>> aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts >>> [16101] 1417810641.452707: Encoding request body and padata into FAST request >>> [16101] 1417810641.452754: Sending request (855 bytes) to F21.TEST >>> [16101] 1417810641.452805: Resolving hostname master.f21.test >>> [16101] 1417810641.453031: Sending initial UDP request to dgram >>> 192.168.5.169:88 >>> [16101] 1417810641.456205: Received answer from dgram 192.168.5.169:88 >>> [16101] 1417810641.456285: Response was from master KDC >>> [16101] 1417810641.456318: Decoding FAST response >>> [16101] 1417810641.456380: FAST reply key: aes256-cts/E5C4 >>> [16101] 1417810641.456422: TGS reply is for admin at IPA5.TEST -> >>> host/master.f21.test at F21.TEST with session key aes256-cts/5D01 >>> [16101] 1417810641.456456: TGS request result: 0/Success >>> [16101] 1417810641.456479: Received creds for desired service >>> host/master.f21.test at F21.TEST >>> [16101] 1417810641.456522: Removing admin at IPA5.TEST -> >>> host/master.f21.test at F21.TEST from KEYRING:persistent:0:0 >>> [16101] 1417810641.456564: Storing admin at IPA5.TEST -> >>> host/master.f21.test at F21.TEST in KEYRING:persistent:0:0 >>> host/master.f21.test at F21.TEST: kvno = 2 >>> >>> [root at ipa-05-m ~]# klist -edf >>> Ticket cache: KEYRING:persistent:0:0 >>> Default principal: admin at IPA5.TEST >>> >>> Valid starting Expires Service principal >>> 05.12.2014 22:17:10 06.12.2014 22:17:10 host/master.f21.test at F21.TEST >>> Flags: FAT, Etype (skey, tkt): aes256-cts-hmac-sha1-96, >>> aes256-cts-hmac-sha1-96 05.12.2014 22:17:21 06.12.2014 22:17:14 >>> krbtgt/F21.TEST at IPA5.TEST >>> Flags: FAT, Etype (skey, tkt): aes256-cts-hmac-sha1-96, >>> aes256-cts-hmac-sha1-96 05.12.2014 22:17:17 06.12.2014 22:17:14 >>> krbtgt/IPA5.TEST at IPA5.TEST >>> Flags: FIA, Etype (skey, tkt): aes256-cts-hmac-sha1-96, >>> aes256-cts-hmac-sha1-96 >>> >>> Of course, the fact that Kerberos tickets can get issued doesn't mean >>> that user can login and gain certain privileges. After all, SSSDs on IPA >>> hosts will not be able to map these Kerberos principals to anything >>> locally unless you would explicitly instruct libkrb5 via /etc/krb5.conf >>> on each IPA host. >> Patch attached. > > For build instructions please see > http://www.freeipa.org/page/Build For the record/Google: Following fix was commited to ipa-4-1 branch and should be included in FreeIPA 4.1.3 release so should be able to use the released version for experiments. commit 0d3b4cd3ec1caa209534314bfa5720f0f8bce89f Author: Alexander Bokovoy Date: Fri Dec 5 21:22:23 2014 +0200 ipa-kdb: when processing transitions, hand over unknown ones to KDC When processing cross-realm trust transitions, let the KDC to handle those we don't know about. Admins might define the transitions as explicit [capaths] in krb5.conf. https://fedorahosted.org/freeipa/ticket/4791 Reviewed-By: Sumit Bose Reviewed-By: Simo Sorce -- Petr^2 Spacek From rmeggins at redhat.com Wed Feb 18 14:46:40 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 18 Feb 2015 07:46:40 -0700 Subject: [Freeipa-users] ad relation with winsync In-Reply-To: <2047927347.576943.1424247226716.JavaMail.root@savoirfairelinux.com> References: <313055385.142650.1423642007008.JavaMail.root@savoirfairelinux.com> <599734995.147060.1423653496313.JavaMail.root@savoirfairelinux.com> <54DB6DE7.6070007@redhat.com> <487613314.673165.1423719446965.JavaMail.root@savoirfairelinux.com> <2047927347.576943.1424247226716.JavaMail.root@savoirfairelinux.com> Message-ID: <54E4A5D0.1080500@redhat.com> On 02/18/2015 01:13 AM, Nicolas Zin wrote: > Hi everyone, > > I'm back with my winsync replication. > The replication process works fine, but whenI specify "OU=Linux,DC=mycompany,DC=com" where 2 users have been created, nothing is replicated. > btw this is a big AD (90k objects). is it a problem? (idrange for example) Not sure. You can enable the replication logging level in 389 to see what the problem is. http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting > > If I replicate "cn=Users,DC=company,DC=com" I have users replicated. but I'm not sure that all are replicated. > > ----- Mail original ----- > De: "Nicolas Zin" > ?: "Rich Megginson" > Cc: freeipa-users at redhat.com > Envoy?: Jeudi 12 F?vrier 2015 09:37:26 > Objet: Re: [Freeipa-users] ad relation with winsync > > Next step: having the replication working. The customer dont want to give to my sync user "Replicating directory changes", "Account Operator" and "Enterprise Read-Only Domain Controller" attributs and just want a "oneway replication". > For the one way replication, I followed the documentation > > But I don't see any imported users. Do you have an idea? Are some of the Windows attributs necessary even for a one way (windows to linux) synchronisation? > > > Regards, > > > > Nicolas > > ----- Mail original ----- > De: "Rich Megginson" > ?: freeipa-users at redhat.com > Envoy?: Mercredi 11 F?vrier 2015 18:57:43 > Objet: Re: [Freeipa-users] ad relation with winsync > > On 02/11/2015 04:18 AM, Nicolas Zin wrote: >> I reply to myself. >> This was certainly a Windows configurarion issue. I went further: >> ipa-replica-manage connect --winsync --binddb cn=Administrator,cn=Users,dc=company,dc=com --bindpwd --passsync whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com -v >> Directory Manager password: ******** >> >> Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate database for srv7idm2.ipa.company.com >> ipa: INFO: AD Suffix is: DC=company,DC=com >> The user for Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=company,dc=com >> ipa: INFO: Added new sync agreement, waiting for it to become ready. . . >> ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP error: Connect error: start: 0 end: 0 >> ipa: INFO: Agreement is ready, starting replication . . . >> Starting replication, please wait until this has completed. >> >> [srv7idm2.ipa.company.com] reports: Update failed! Status: [-11 - LDAP error: Connect error] >> >> >> >> So apparently I manage to connect to AD but something went wrong after? >> How can I debug it? > You can test it like this: > > # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN ldapsearch -xLLLZZ -H > ldap://fqdn.of.ad.host -s base -b "DC=company,DC=com" -D > "cn=Administrator,cn=Users,dc=company,dc=com" -w "password" > >> >> >> Regards, >> >> >> >> Nicolas Zin >> >> >> >> ----- Mail original ----- >> De: "Nicolas Zin" >> ?: freeipa-users at redhat.com >> Envoy?: Mercredi 11 F?vrier 2015 12:06:47 >> Objet: [Freeipa-users] ad relation with winsync >> >> Hi, >> >> I now try to establish a winsync relation with a Windows 2008R2. >> I installed IDM 3.3 on RHEL7. >> >> When I try to create the replication: >> ipa-replica-manage connect --winsync --binddb cn=Administrator,cn=Users,dc=company,dc=com --bindpwd --passsync whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com >> Directory Manager password: ******** >> >> Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate database for srv7idm2.ipa.company.com >> ipa: INFO: Failed to connect to AD srever dc.company.com >> ipa: INFO: The error was: {'info': 'TLS error -8157:Certificate extension not found','desc': 'Connect error'} >> Failed to setup winsync replication >> >> >> Do you have an idea, what's wrong? >> Also is it possible to point to port 636 instead? >> >> >> Notes: >> - On the windows side, ssl has been activated (with pain) and ldp.exe manage to connect via ssl on the 636 port correctly (so the certificate is in place). I don't know how to check it is working properly on port 389, i.e. START_TLS works >> - I checked that the 2 box have the same time (ntp) >> - I nearly manage to make it working once, but I got another error during replication >> >> >> >> Nicolas Zin >> nicolas.zin at savoirfairelinux.com >> Ligne directe: 514-276-5468 poste 135 >> >> Fax : 514-276-5465 >> 7275 Saint Urbain >> Bureau 200 >> Montr?al, QC, H2R 2Y5 >> >> >> From cory at pithoslabs.com Wed Feb 18 17:17:48 2015 From: cory at pithoslabs.com (Cory Carlton) Date: Wed, 18 Feb 2015 11:17:48 -0600 Subject: [Freeipa-users] New Replacing Master server help Message-ID: Hey all. We are in the process of essentially moving data centers while additionally changing to new OS(rhel from centos) - so we are building replica with master option servers to the new networks. version 3.0.. its up and is working as any of our instances. Question is how or what do I need to bring over on the new install -replica master(s) to ensure we have all the Original master server information, keys, crt's, CA etc. before we can shut it down for ever (+ a snapshot ;) ) we have struggled understanding exactly what to back up since the 3.0 version is lacking backup scripts. a thought, but not timely present would be to upgrade everything in place then migrate, again not timed right for us. Thanks in advance. Cory -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Feb 18 18:46:39 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 18 Feb 2015 13:46:39 -0500 Subject: [Freeipa-users] New Replacing Master server help In-Reply-To: References: Message-ID: <54E4DE0F.4070404@redhat.com> On 02/18/2015 12:17 PM, Cory Carlton wrote: > Hey all. > > We are in the process of essentially moving data centers while > additionally changing to new OS(rhel from centos) - so we are building > replica with master option servers to the new networks. version 3.0.. > its up and is working as any of our instances. > > Question is how or what do I need to bring over on the new install > -replica master(s) to ensure we have all the Original master server > information, keys, crt's, CA etc. before we can shut it down for ever > (+ a snapshot ;) ) > > we have struggled understanding exactly what to back up since the 3.0 > version is lacking backup scripts. > > > a thought, but not timely present would be to upgrade everything in > place then migrate, again not timed right for us. > > Thanks in advance. > > Cory > > > You need to make sure that at least one of the new replicas (better two) acts as an IPA CA. You need to move CRL generation to one of the new replicas that are CAs You need to move the certificate tracking from the old master to the new replica with CA. After that you can decommission old master. All these procedures are documented on the wiki and RHEL docs. You can also find some hints in these archives. Martin, do you think we need a combined wiki page that covers this use case or we already have something like this? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From api at psychopig.com Wed Feb 18 19:03:50 2015 From: api at psychopig.com (Hugh) Date: Wed, 18 Feb 2015 13:03:50 -0600 Subject: [Freeipa-users] Passsync fails to connect to LDAP In-Reply-To: <54E3B0BF.9010409@redhat.com> References: <54E3A19C.9070007@redhat.com> <54E3A8AB.1010305@redhat.com> <54E3B0BF.9010409@redhat.com> Message-ID: Sorry to be a pest, but I don't suppose you've heard back about this yet, have you? Thanks, Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory at pithoslabs.com Wed Feb 18 19:13:12 2015 From: cory at pithoslabs.com (Cory Carlton) Date: Wed, 18 Feb 2015 13:13:12 -0600 Subject: [Freeipa-users] New Replacing Master server help In-Reply-To: <54E4DE0F.4070404@redhat.com> References: <54E4DE0F.4070404@redhat.com> Message-ID: Thank you very much for the straight forward items. I will continue use of these archives (impressed with this group). Also improving my use of https://fedorahosted.org/freeipa/wiki On Wed, Feb 18, 2015 at 12:46 PM, Dmitri Pal wrote: > On 02/18/2015 12:17 PM, Cory Carlton wrote: > > Hey all. > > We are in the process of essentially moving data centers while > additionally changing to new OS(rhel from centos) - so we are building > replica with master option servers to the new networks. version 3.0.. its > up and is working as any of our instances. > > Question is how or what do I need to bring over on the new install > -replica master(s) to ensure we have all the Original master server > information, keys, crt's, CA etc. before we can shut it down for ever (+ a > snapshot ;) ) > > we have struggled understanding exactly what to back up since the 3.0 > version is lacking backup scripts. > > > a thought, but not timely present would be to upgrade everything in > place then migrate, again not timed right for us. > > Thanks in advance. > > Cory > > > > > You need to make sure that at least one of the new replicas (better two) > acts as an IPA CA. > You need to move CRL generation to one of the new replicas that are CAs > You need to move the certificate tracking from the old master to the new > replica with CA. > > After that you can decommission old master. > > All these procedures are documented on the wiki and RHEL docs. You can > also find some hints in these archives. > > Martin, do you think we need a combined wiki page that covers this use > case or we already have something like this? > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhosoi at redhat.com Wed Feb 18 19:19:02 2015 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 18 Feb 2015 11:19:02 -0800 Subject: [Freeipa-users] ping: Fwd: Passsync fails to connect to LDAP In-Reply-To: <54E4E34A.1070300@redhat.com> References: <54E4E34A.1070300@redhat.com> Message-ID: <54E4E5A6.8020200@redhat.com> Hello Hugh, Could you tell us the version of 389-ds-base the PassSync is trying to access? If the directory server is not new enough (389-ds-base-*1.3.2.26 *or 389-ds-base-*1.3.3.8 *), could you please try setting the following environment variable on the Windows machine on which PassSync is running?* * http://www.port389.org/docs/389ds/releases/release-passsync-1-1-6.html PassSync 1.1.6 supports TLS version 1.1 and newer SSL versions supported by NSS. SSLv3 is disabled, by default. To force to enable SSLv3.0, an environment variable LDAPSSL_ALLOW_OLD_SSL_VERSION has to be set with some non NULL value. In Computer | Properties | Advanced system settings | Environment Variables | System variables, add variable: LDAPSSL_ALLOW_OLD_SSL_VERSION, value: 1 Thanks, --noriko > -------- Forwarded Message -------- > Subject: [Freeipa-users] Passsync fails to connect to LDAP > Date: Tue, 17 Feb 2015 13:55:52 -0600 > From: Hugh > To: freeipa-users at redhat.com > > > > All, > After my education on what IPA/AD trusts can and can't do, I decided > to give the IPA-AD sync option a try. After finally finding what I > think is the proper software to install on the AD DC > (389-PassSync-1.1.6-x86_64.exe from the Fedora site), I believe I have > the settings correct, but the Password Synchronization software > refuses to connect. After changing the Log Level option to 1, I get > the below in the log file, which doesn't really tell me much of anything. > 02/17/15 13:18:20: Backoff time expired. Attempting sync > 02/17/15 13:18:20: Password list has 1 entries > 02/17/15 13:18:20: Ldap bind error in Connect > 81: Can't contact LDAP server > 02/17/15 13:18:20: Attempting to sync password for ADSERVER$ > 02/17/15 13:18:20: Searching for (ntuserdomainid=ADSERVER$) > 02/17/15 13:18:20: Ldap error in QueryUsername > 81: Can't contact LDAP server > 02/17/15 13:18:20: Deferring password change for ADSERVER$ > 02/17/15 13:18:20: Backing off for 256000ms > The credentials are definitely correct and IPA is set up to do LDAPS > as, on the same AD server, I can connect and bind using ldp.exe with > the same settings/credentials and I'm able to browse the LDAP tree. > I've done a wireshark capture and it looks like it's failing in the > TLS negotiation. I can see this entry in the capture: > TLSv1 Record Layer: Alert (Level: Fatal, Description: Protocol Version) > Content Type: Alert (21) > Version: TLS 1.2 (0x0303) > Length: 2 > Alert Message > Level: Fatal (2) > Description: Protocol Version (70) > I added the IPA CA cert to the cert files in the 389 passsynch > directory and I can confirm that as below. > C:\Program Files\389 Directory Password Synchronization>certutil -d . -L > Certificate Nickname Trust > Attributes > SSL,S/MIME,JAR/XPI > IPA CA cert CT,, > When I list that specific certificate, I can see the below in the output. > Certificate Trust Flags: > SSL Flags: > Valid CA > Trusted CA > Trusted Client CA > Email Flags: > Object Signing Flags: > Any pointers/ideas? > Thanks in advance, > Hugh > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.minkus at sonic.com Thu Feb 19 00:06:39 2015 From: martin.minkus at sonic.com (Martin Minkus) Date: Wed, 18 Feb 2015 16:06:39 -0800 Subject: [Freeipa-users] FreeIPA and Application Specific Passwords Message-ID: <54E5290F.8020301@sonic.com> Hello all, Am wondering what support FreeIPA has for Application Specific Passwords? My research seems to indicate 'none'. I've seen quite a few people ask about this, usually the example is wanting a separate password for dovecot etc. Google itself implemented this, allowing multiple passwords for imap accounts in gmail so that a stolen phone or ipad doesn't give the thief complete unfettered access to the entire google account. The single password can be easily changed or locked out and even if it is not, it only has access to email. I work for an organisation and we are looking at standardising on FreeIPA for all our single sign on and auth requirements. Except where we don't want single sign on, and separate passwords are advantageous or even required: - Web logins - VPN logins - Tacacs I'm assuming it's somewhat understandable to want to keep web logins separate - web sites are notoriously insecure, and we wouldn't want an employee's web login getting stolen/phished/etc giving an attacker vpn access, kerberos/ldap access to all our linux servers, and tacacs access to network infrastructure. The solution I've seen suggested to others that have asked about FreeIPA or OpenLDAP and Application Specific Passwords seems to be: Just create a separate user login for each application. Messy, but sure. I also see we could extend the schema and add in extra fields like webPassword and vpnPassword, but we'd have to maintain those fields/enforce complexity and length requirements/password expiry ourselves which is less than ideal. Or the final option might just be to run separate ldap instances for each application, so the username stays the same group membership is application specific in each ldap instance, and it gives us the password separation we desire. Also, most users don't need tacacs access or vpn access, though most(all) users will need web application access. Anyway. I'm wondering if there are any other potential options that I have missed? Or some better way we should be going about this? Yeah, we should probably trust our employees with their passwords more but apparently that is not the case. Thanks, Martin. From Steven.Jones at vuw.ac.nz Thu Feb 19 01:47:43 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 19 Feb 2015 01:47:43 +0000 Subject: [Freeipa-users] FreeIPA and Application Specific Passwords In-Reply-To: <54E5290F.8020301@sonic.com> References: <54E5290F.8020301@sonic.com> Message-ID: <1424310319193.90017@vuw.ac.nz> Hi, There is always a tradeoff between ease of use, complexity/cost and security. Looking at what you have written suggests to me that your entire system lacks a proper security / network architecture model and you are trying to enforce a "policy" from one point, IPA. regards Steven ________________________________________ From: freeipa-users-bounces at redhat.com on behalf of Martin Minkus Sent: Thursday, 19 February 2015 1:06 p.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] FreeIPA and Application Specific Passwords Hello all, Am wondering what support FreeIPA has for Application Specific Passwords? My research seems to indicate 'none'. I've seen quite a few people ask about this, usually the example is wanting a separate password for dovecot etc. Google itself implemented this, allowing multiple passwords for imap accounts in gmail so that a stolen phone or ipad doesn't give the thief complete unfettered access to the entire google account. The single password can be easily changed or locked out and even if it is not, it only has access to email. I work for an organisation and we are looking at standardising on FreeIPA for all our single sign on and auth requirements. Except where we don't want single sign on, and separate passwords are advantageous or even required: - Web logins - VPN logins - Tacacs I'm assuming it's somewhat understandable to want to keep web logins separate - web sites are notoriously insecure, and we wouldn't want an employee's web login getting stolen/phished/etc giving an attacker vpn access, kerberos/ldap access to all our linux servers, and tacacs access to network infrastructure. The solution I've seen suggested to others that have asked about FreeIPA or OpenLDAP and Application Specific Passwords seems to be: Just create a separate user login for each application. Messy, but sure. I also see we could extend the schema and add in extra fields like webPassword and vpnPassword, but we'd have to maintain those fields/enforce complexity and length requirements/password expiry ourselves which is less than ideal. Or the final option might just be to run separate ldap instances for each application, so the username stays the same group membership is application specific in each ldap instance, and it gives us the password separation we desire. Also, most users don't need tacacs access or vpn access, though most(all) users will need web application access. Anyway. I'm wondering if there are any other potential options that I have missed? Or some better way we should be going about this? Yeah, we should probably trust our employees with their passwords more but apparently that is not the case. Thanks, Martin. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project From jrichard at placeiq.com Thu Feb 19 05:52:12 2015 From: jrichard at placeiq.com (Jim Richard) Date: Thu, 19 Feb 2015 00:52:12 -0500 Subject: [Freeipa-users] Excessive CPU usage by ns-slapd Message-ID: <30BE1A3D-7170-485D-9A91-C868682450D9@placeiq.com> I?ve got 4 Redhat IDM masters in a multi-master config. 3.0.0-42.el6.centos is the IPA version, 389-ds-base version 1.2.11.15-48.el6_6, Centos 6.6 Monitoring established connections on port 389 and dsInOps over time shows a consistent/even level of activity however 2 of the 4 IPA servers show ever increasing CPI usage by ns-slapd. One ns-slapd process will start to show increased CPU for a time, then drop off as another then increases. This cycle continues with each switch seeing more and more total SPU usage by ns-slapd. strace timing for the offending ns-slapd looks like the following: % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 96.12 9.342272 1133 8243 poll 3.86 0.375457 53 7066 41 futex 0.01 0.000668 0 8244 8244 getpeername 0.00 0.000374 0 929 close 0.00 0.000368 0 3201 read 0.00 0.000151 0 882 setsockopt 0.00 0.000095 2 42 access 0.00 0.000033 0 1365 fcntl 0.00 0.000000 0 42 open 0.00 0.000000 0 39 stat 0.00 0.000000 0 42 fstat 0.00 0.000000 0 1 madvise 0.00 0.000000 0 441 accept 0.00 0.000000 0 441 getsockname 0.00 0.000000 0 1 restart_syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 9.719418 30979 8285 total I have carefully reviewed cn=config settings on all four master servers to confirm that they match. Based on this strace output can you perhaps point me in the right direction, give me a clue on what I should be looking at. Here?s a screen shot of my Zabbix reporting to help describe the problem. Note the graph in the bottom right corner. The problem is most certainly related to replication but I just don?t know what specifically to look at. Thanks in advance for any clues you can provide. Jim Richard | PlaceIQ | Systems Administrator | jrichard at placeiq.com | +1 (646) 338-8905 <> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-02-19 at 12.46.44 AM.png Type: image/png Size: 1563895 bytes Desc: not available URL: From jnansi at redhat.com Thu Feb 19 06:05:28 2015 From: jnansi at redhat.com (Jatin Nansi) Date: Thu, 19 Feb 2015 16:05:28 +1000 Subject: [Freeipa-users] Excessive CPU usage by ns-slapd In-Reply-To: <30BE1A3D-7170-485D-9A91-C868682450D9@placeiq.com> References: <30BE1A3D-7170-485D-9A91-C868682450D9@placeiq.com> Message-ID: <54E57D28.103@redhat.com> Check the ns-slapd access and error logs of the DS instance hosting the IPA instance. The strace output indicates that ns-slapd spent most of its time waiting for network activity to happen (poll), which is normal for ns-slapd. Jatin On 19/02/15 15:52, Jim Richard wrote: > I?ve got 4 Redhat IDM masters in a multi-master > config. 3.0.0-42.el6.centos is the IPA version, 389-ds-base version > 1.2.11.15-48.el6_6, Centos 6.6 > > Monitoring established connections on port 389 and dsInOps over time > shows a consistent/even level of activity however 2 of the 4 IPA > servers show ever increasing CPI usage by ns-slapd. One ns-slapd > process will start to show increased CPU for a time, then drop off as > another then increases. This cycle continues with each switch seeing > more and more total SPU usage by ns-slapd. > > strace timing for the offending ns-slapd looks like the following: > > > % time seconds usecs/call calls errors syscall > ------ ----------- ----------- --------- --------- ---------------- > 96.12 9.342272 1133 8243 poll > 3.86 0.375457 53 7066 41 futex > 0.01 0.000668 0 8244 8244 getpeername > 0.00 0.000374 0 929 close > 0.00 0.000368 0 3201 read > 0.00 0.000151 0 882 setsockopt > 0.00 0.000095 2 42 access > 0.00 0.000033 0 1365 fcntl > 0.00 0.000000 0 42 open > 0.00 0.000000 0 39 stat > 0.00 0.000000 0 42 fstat > 0.00 0.000000 0 1 madvise > 0.00 0.000000 0 441 accept > 0.00 0.000000 0 441 getsockname > 0.00 0.000000 0 1 restart_syscall > ------ ----------- ----------- --------- --------- ---------------- > 100.00 9.719418 30979 8285 total > > > I have carefully reviewed cn=config settings on all four master > servers to confirm that they match. > > Based on this strace output can you perhaps point me in the right > direction, give me a clue on what I should be looking at. > > Here?s a screen shot of my Zabbix reporting to help describe the > problem. Note the graph in the bottom right corner. > > The problem is most certainly related to replication but I just don?t > know what specifically to look at. > > > > > Thanks in advance for any clues you can provide. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jim Richard | PlaceIQ > | > Systems Administrator | jrichard at placeiq.com > | +1 (646) 338-8905 > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1563895 bytes Desc: not available URL: From mkosek at redhat.com Thu Feb 19 09:38:10 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Feb 2015 10:38:10 +0100 Subject: [Freeipa-users] New Replacing Master server help In-Reply-To: <54E4DE0F.4070404@redhat.com> References: <54E4DE0F.4070404@redhat.com> Message-ID: <54E5AF02.7080004@redhat.com> On 02/18/2015 07:46 PM, Dmitri Pal wrote: > On 02/18/2015 12:17 PM, Cory Carlton wrote: >> Hey all. >> >> We are in the process of essentially moving data centers while additionally >> changing to new OS(rhel from centos) - so we are building replica with master >> option servers to the new networks. version 3.0.. its up and is working as >> any of our instances. >> >> Question is how or what do I need to bring over on the new install -replica >> master(s) to ensure we have all the Original master server information, keys, >> crt's, CA etc. before we can shut it down for ever (+ a snapshot ;) ) >> >> we have struggled understanding exactly what to back up since the 3.0 version >> is lacking backup scripts. >> >> >> a thought, but not timely present would be to upgrade everything in place >> then migrate, again not timed right for us. >> >> Thanks in advance. >> >> Cory >> >> >> > > You need to make sure that at least one of the new replicas (better two) acts > as an IPA CA. > You need to move CRL generation to one of the new replicas that are CAs > You need to move the certificate tracking from the old master to the new > replica with CA. > > After that you can decommission old master. > > All these procedures are documented on the wiki and RHEL docs. You can also > find some hints in these archives. > > Martin, do you think we need a combined wiki page that covers this use case or > we already have something like this? I think we are already well set. This is the upstream page: http://www.freeipa.org/page/Howto/Migration#Migrating_to_different_platform_or_OS This is the downstream documentation, mostly targetted on RHEL-6.x to RHEL-7.0 migration, but also applicable on your use case: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html Martin From pspacek at redhat.com Thu Feb 19 09:46:57 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 19 Feb 2015 10:46:57 +0100 Subject: [Freeipa-users] FreeIPA and Application Specific Passwords In-Reply-To: <1424310319193.90017@vuw.ac.nz> References: <54E5290F.8020301@sonic.com> <1424310319193.90017@vuw.ac.nz> Message-ID: <54E5B111.5060202@redhat.com> On 19.2.2015 02:47, Steven Jones wrote: > Hi, > > There is always a tradeoff between ease of use, complexity/cost and security. Looking at what you have written suggests to me that your entire system lacks a proper security / network architecture model and you are trying to enforce a "policy" from one point, IPA. > > regards > > Steven > ________________________________________ > From: freeipa-users-bounces at redhat.com on behalf of Martin Minkus > Sent: Thursday, 19 February 2015 1:06 p.m. > To: freeipa-users at redhat.com > Subject: [Freeipa-users] FreeIPA and Application Specific Passwords > > Hello all, > > Am wondering what support FreeIPA has for Application Specific > Passwords? My research seems to indicate 'none'. I've seen quite a few > people ask about this, usually the example is wanting a separate > password for dovecot etc. > > Google itself implemented this, allowing multiple passwords for imap > accounts in gmail so that a stolen phone or ipad doesn't give the thief > complete unfettered access to the entire google account. The single > password can be easily changed or locked out and even if it is not, it > only has access to email. > > I work for an organisation and we are looking at standardising on > FreeIPA for all our single sign on and auth requirements. > > Except where we don't want single sign on, and separate passwords are > advantageous or even required: > > - Web logins If I understand correctly, your biggest worry is that somebody will steal user credentials via web form, right? IMHO the best option is to get rid of passwords in web apps completely and use true single-sign-on. The simplest thing may be just to use mod_auth_kerb and put the application behind Kerberos but more complex/flexible/fancy approaches are possible too, see http://www.freeipa.org/page/Web_App_Authentication This is 'The Approach' we are trying to pursue in FreeIPA project - authenticate only once (when logging in to a machine) and never type password again. This allows you to use two-factor authentication without apps knowing about it etc. Alternative is to use SAML/OpenID/other web technology to tie web apps to web-based authentication portal which may allow SSO from Kerberos (without mod_auth_kerb) or to simply have single trusted place to log-in from web form. I hope Jan or Simo can correct my misunderstandings and add more details. Have a nice day! Petr^2 Spacek > - VPN logins > - Tacacs > > I'm assuming it's somewhat understandable to want to keep web logins > separate - web sites are notoriously insecure, and we wouldn't want an > employee's web login getting stolen/phished/etc giving an attacker vpn > access, kerberos/ldap access to all our linux servers, and tacacs access > to network infrastructure. > > The solution I've seen suggested to others that have asked about FreeIPA > or OpenLDAP and Application Specific Passwords seems to be: Just create > a separate user login for each application. > > Messy, but sure. > > I also see we could extend the schema and add in extra fields like > webPassword and vpnPassword, but we'd have to maintain those > fields/enforce complexity and length requirements/password expiry > ourselves which is less than ideal. > > Or the final option might just be to run separate ldap instances for > each application, so the username stays the same group membership is > application specific in each ldap instance, and it gives us the password > separation we desire. Also, most users don't need tacacs access or vpn > access, though most(all) users will need web application access. > > Anyway. I'm wondering if there are any other potential options that I > have missed? Or some better way we should be going about this? > > Yeah, we should probably trust our employees with their passwords more > but apparently that is not the case. > > Thanks, > Martin. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -- Petr^2 Spacek From mkosek at redhat.com Thu Feb 19 09:49:22 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Feb 2015 10:49:22 +0100 Subject: [Freeipa-users] FreeIPA and Application Specific Passwords In-Reply-To: <54E5290F.8020301@sonic.com> References: <54E5290F.8020301@sonic.com> Message-ID: <54E5B1A2.8070401@redhat.com> On 02/19/2015 01:06 AM, Martin Minkus wrote: > Hello all, > > Am wondering what support FreeIPA has for Application Specific > Passwords? My research seems to indicate 'none'. I've seen quite a few > people ask about this, usually the example is wanting a separate > password for dovecot etc. > > Google itself implemented this, allowing multiple passwords for imap > accounts in gmail so that a stolen phone or ipad doesn't give the thief > complete unfettered access to the entire google account. The single > password can be easily changed or locked out and even if it is not, it > only has access to email. > > I work for an organisation and we are looking at standardising on > FreeIPA for all our single sign on and auth requirements. > > Except where we don't want single sign on, and separate passwords are > advantageous or even required: > > - Web logins > - VPN logins > - Tacacs > > I'm assuming it's somewhat understandable to want to keep web logins > separate - web sites are notoriously insecure, and we wouldn't want an > employee's web login getting stolen/phished/etc giving an attacker vpn > access, kerberos/ldap access to all our linux servers, and tacacs access > to network infrastructure. I am not sure what exactly is the fear here. If FreeIPA Web Authentication modules are used (http://www.freeipa.org/page/Web_App_Authentication), the user credentials are not stored on the web server, they go straight to SSSD where the user get's authenticated to remote LDAP (FreeIPA/AD). Alternatively, you could also set up SAML with mod_auth_mellon and Ipsilon to get a federated login where the web app would never get to the actual password. > The solution I've seen suggested to others that have asked about FreeIPA > or OpenLDAP and Application Specific Passwords seems to be: Just create > a separate user login for each application. > > Messy, but sure. > > I also see we could extend the schema and add in extra fields like > webPassword and vpnPassword, but we'd have to maintain those > fields/enforce complexity and length requirements/password expiry > ourselves which is less than ideal. > > Or the final option might just be to run separate ldap instances for > each application, so the username stays the same group membership is > application specific in each ldap instance, and it gives us the password > separation we desire. Also, most users don't need tacacs access or vpn > access, though most(all) users will need web application access. > > Anyway. I'm wondering if there are any other potential options that I > have missed? Or some better way we should be going about this? > > Yeah, we should probably trust our employees with their passwords more > but apparently that is not the case. > > Thanks, > Martin. I think we have exactly this request tracked: https://fedorahosted.org/freeipa/ticket/4510 It already contains long discussion on the topics with some ideas. We still miss the horsepower to actually add support for it though. Martin From jpazdziora at redhat.com Thu Feb 19 10:06:58 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 19 Feb 2015 11:06:58 +0100 Subject: [Freeipa-users] FreeIPA and Application Specific Passwords In-Reply-To: <54E5290F.8020301@sonic.com> References: <54E5290F.8020301@sonic.com> Message-ID: <20150219100658.GA18794@redhat.com> On Wed, Feb 18, 2015 at 04:06:39PM -0800, Martin Minkus wrote: > > Except where we don't want single sign on, and separate passwords are > advantageous or even required: > > - Web logins Could you elaborate on the use cases when you'd want your users to log in using their passwords on a Web login, instead of using SSO, be it Kerberos or SAML? Is that purely the application not supporting it or are there some other reasons (you say "we don't want single sign on" which sounds like a political or compliance issue, not technical one). -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From David.Fitzgerald at millersville.edu Thu Feb 19 14:26:32 2015 From: David.Fitzgerald at millersville.edu (David Fitzgerald) Date: Thu, 19 Feb 2015 14:26:32 +0000 Subject: [Freeipa-users] question about Active Directory authentication In-Reply-To: <1424215342849.9144@vuw.ac.nz> References: <958EF916EB06874283F9B8F820726DD3B9FFA10B@FSMB1.muad.local> <1424208749846.77996@vuw.ac.nz>, <54E3B99E.10603@redhat.com> <1424211576331.81797@vuw.ac.nz>,<54E3C60E.7010105@redhat.com> <1424215342849.9144@vuw.ac.nz> Message-ID: <958EF916EB06874283F9B8F820726DD3B9FFD619@FSMB1.muad.local> Thanks for all the info. I think I will go the trust route with IPA 4.1 and see what happens (in a test environment first of course.) From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Steven Jones Sent: Tuesday, February 17, 2015 6:25 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] question about Active Directory authentication Ok, So with winsync I will have the 2000+ users in IPA. Within IPA I have several high risk/impact groups of servers and many low. For the low risk/impact servers and most desktops they can trust what AD tells them. For the high risk/impact servers/applications we do not want to reply on AD for any authorisation so permissions for these will be isolated from AD inside IPA. The idea is if we lose AD or IPA we should not lose both via any cross-linking. regards Steven ________________________________ From: freeipa-users-bounces at redhat.com > on behalf of Dmitri Pal > Sent: Wednesday, 18 February 2015 11:51 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] question about Active Directory authentication On 02/17/2015 05:21 PM, Steven Jones wrote: ***maybe*** c) You might be able to do both winsync and trusts at the same time then that is simpler provisioning. ie a user gets created in AD and automatically gets created in IPA ready for you to put in the user group you want. I am not sure this is the best solution really. Trust and sync do not help each other. The fact that you have trust does not help you to provision users the way you describe. 8><------ They achieve different things. How otherwise do I get 2000+ AD users into IPA? To me winsync allows automated provisioning of users into IPA via AD, this greatly reduces manual effort. That I get. I do not understand how trust helps you in this case. -- 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 Thu Feb 19 14:33:23 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 19 Feb 2015 07:33:23 -0700 Subject: [Freeipa-users] Excessive CPU usage by ns-slapd In-Reply-To: <54E57D28.103@redhat.com> References: <30BE1A3D-7170-485D-9A91-C868682450D9@placeiq.com> <54E57D28.103@redhat.com> Message-ID: <54E5F433.50702@redhat.com> On 02/18/2015 11:05 PM, Jatin Nansi wrote: > Check the ns-slapd access and error logs of the DS instance hosting > the IPA instance. The strace output indicates that ns-slapd spent most > of its time waiting for network activity to happen (poll), which is > normal for ns-slapd. The number of open connections correlates to the CPU usage. Do this: # ls -al /proc/`cat /var/run/dirsrv/slapd-MY-DOMAIN.pid`/fd|grep socket|wc -l How many socket connections do you have? Also, it will be very useful to get some stack traces of the running server to see what the various threads are doing. See http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs > > Jatin > On 19/02/15 15:52, Jim Richard wrote: >> I?ve got 4 Redhat IDM masters in a multi-master >> config. 3.0.0-42.el6.centos is the IPA version, 389-ds-base version >> 1.2.11.15-48.el6_6, Centos 6.6 >> >> Monitoring established connections on port 389 and dsInOps over time >> shows a consistent/even level of activity however 2 of the 4 IPA >> servers show ever increasing CPI usage by ns-slapd. One ns-slapd >> process will start to show increased CPU for a time, then drop off as >> another then increases. This cycle continues with each switch seeing >> more and more total SPU usage by ns-slapd. >> >> strace timing for the offending ns-slapd looks like the following: >> >> >> % time seconds usecs/call calls errors syscall >> ------ ----------- ----------- --------- --------- ---------------- >> 96.12 9.342272 1133 8243 poll >> 3.86 0.375457 53 7066 41 futex >> 0.01 0.000668 0 8244 8244 getpeername >> 0.00 0.000374 0 929 close >> 0.00 0.000368 0 3201 read >> 0.00 0.000151 0 882 setsockopt >> 0.00 0.000095 2 42 access >> 0.00 0.000033 0 1365 fcntl >> 0.00 0.000000 0 42 open >> 0.00 0.000000 0 39 stat >> 0.00 0.000000 0 42 fstat >> 0.00 0.000000 0 1 madvise >> 0.00 0.000000 0 441 accept >> 0.00 0.000000 0 441 getsockname >> 0.00 0.000000 0 1 restart_syscall >> ------ ----------- ----------- --------- --------- ---------------- >> 100.00 9.719418 30979 8285 total >> >> >> I have carefully reviewed cn=config settings on all four master >> servers to confirm that they match. >> >> Based on this strace output can you perhaps point me in the right >> direction, give me a clue on what I should be looking at. >> >> Here?s a screen shot of my Zabbix reporting to help describe the >> problem. Note the graph in the bottom right corner. >> >> The problem is most certainly related to replication but I just don?t >> know what specifically to look at. >> >> >> >> >> Thanks in advance for any clues you can provide. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Jim Richard | PlaceIQ >> | >> Systems Administrator | jrichard at placeiq.com >> | +1 (646) 338-8905 >> >> >> >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1563895 bytes Desc: not available URL: From jwest at iki.fi Thu Feb 19 15:07:41 2015 From: jwest at iki.fi (Jani West) Date: Thu, 19 Feb 2015 17:07:41 +0200 Subject: [Freeipa-users] Migration fails from 3.0.0 to 3.3.3 on Centos 6/7 Message-ID: <54E5FC3D.3070904@iki.fi> Trying to migrate from CentOS 6.6 with FreeIPA 3.0.0-42 to CentOS 7.0 with FreeIPA 3.3.3-28 by using replication. I have prepared replication file and moved it to the new replica server. Configured the firewalld and installed Ipa and other needed packages via yum. When running "ipa-replica-install --setup-ca -d" installation will always stuck on: ---------------------------------------------------------------------- "Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [2/19]: configuring certificate server instance ipa : DEBUG Starting external process ipa : DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpHJBhR5 ipa : DEBUG Process finished, return code=1 ipa : DEBUG stdout=Loading deployment configuration from /tmp/tmpHJBhR5. Installing CA into /var/lib/pki/pki-tomcat. Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. Installation failed. ipa : DEBUG stderr=pkispawn : WARNING ....... unable to validate security domain user/password through REST interface. Interface not available pkispawn : ERROR ....... Exception from Java Configuration Servlet: Error while updating security domain: java.io.IOException: java.io.IOException: SocketException cannot read on socket ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpHJBhR5' returned non-zero exit status 1 ---------------------------------------------------------------------- Betwee the attempts I have cleaned yu ipa and pki configurations and deleteted the old replication agreement. Apache logs on old CentOS 6 server have these errors. ---------------------------------------------------------------------- 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST /ca/admin/ca/getDomainXML HTTP/1.0" 200 1158 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST /ca/admin/ca/updateDomainXML HTTP/1.0" 404 - 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST /ca/agent/ca/updateDomainXML HTTP/1.0" 403 323 [Thu Feb 19 11:38:44 2015] [error] Bad remote server certificate: -8181 [Thu Feb 19 11:38:44 2015] [error] SSL Library Error: -8181 Certificate has expired [Thu Feb 19 11:38:44 2015] [error] Re-negotiation handshake failed: Not accepted by client!? ---------------------------------------------------------------------- What certificate this means? ca.crt have more than five years left. Clocks are synced, /ca/admin/ca/updateDomainXML can be found on ipa-pki-proxy.conf and there are no obvious reason. Any hints? -- -- Jani West From dpal at redhat.com Thu Feb 19 16:14:45 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 19 Feb 2015 11:14:45 -0500 Subject: [Freeipa-users] Migration fails from 3.0.0 to 3.3.3 on Centos 6/7 In-Reply-To: <54E5FC3D.3070904@iki.fi> References: <54E5FC3D.3070904@iki.fi> Message-ID: <54E60BF5.7@redhat.com> On 02/19/2015 10:07 AM, Jani West wrote: > Trying to migrate from CentOS 6.6 with FreeIPA 3.0.0-42 to CentOS 7.0 > with FreeIPA 3.3.3-28 by using replication. > > I have prepared replication file and moved it to the new replica > server. Configured the firewalld and installed Ipa and other needed > packages via yum. > > When running "ipa-replica-install --setup-ca -d" installation will > always stuck on: > > ---------------------------------------------------------------------- > "Configuring certificate server (pki-tomcatd): Estimated time 3 > minutes 30 seconds > [2/19]: configuring certificate server instance > ipa : DEBUG Starting external process > ipa : DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpHJBhR5 > ipa : DEBUG Process finished, return code=1 > ipa : DEBUG stdout=Loading deployment configuration from > /tmp/tmpHJBhR5. > Installing CA into /var/lib/pki/pki-tomcat. > Storing deployment configuration into > /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. > Installation failed. > > > ipa : DEBUG stderr=pkispawn : WARNING ....... unable to > validate security domain user/password through REST interface. > Interface not available > pkispawn : ERROR ....... Exception from Java Configuration > Servlet: Error while updating security domain: java.io.IOException: > java.io.IOException: SocketException cannot read on socket > > ipa : CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmpHJBhR5' returned non-zero exit > status 1 > ---------------------------------------------------------------------- > > Betwee the attempts I have cleaned yu ipa and pki configurations and > deleteted the old replication agreement. > > > Apache logs on old CentOS 6 server have these errors. > ---------------------------------------------------------------------- > 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST > /ca/admin/ca/getDomainXML HTTP/1.0" 200 1158 > 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST > /ca/admin/ca/updateDomainXML HTTP/1.0" 404 - > 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST > /ca/agent/ca/updateDomainXML HTTP/1.0" 403 323 > [Thu Feb 19 11:38:44 2015] [error] Bad remote server certificate: -8181 > [Thu Feb 19 11:38:44 2015] [error] SSL Library Error: -8181 > Certificate has expired > [Thu Feb 19 11:38:44 2015] [error] Re-negotiation handshake failed: > Not accepted by client!? > ---------------------------------------------------------------------- > > What certificate this means? ca.crt have more than five years left. > > Clocks are synced, /ca/admin/ca/updateDomainXML can be found on > ipa-pki-proxy.conf and there are no obvious reason. Any hints? Are CA ports accessible on your master? Can you check your FW please? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From mkosek at redhat.com Thu Feb 19 16:22:13 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Feb 2015 17:22:13 +0100 Subject: [Freeipa-users] Migration fails from 3.0.0 to 3.3.3 on Centos 6/7 In-Reply-To: <54E60BF5.7@redhat.com> References: <54E5FC3D.3070904@iki.fi> <54E60BF5.7@redhat.com> Message-ID: <54E60DB5.7080206@redhat.com> On 02/19/2015 05:14 PM, Dmitri Pal wrote: > On 02/19/2015 10:07 AM, Jani West wrote: >> Trying to migrate from CentOS 6.6 with FreeIPA 3.0.0-42 to CentOS 7.0 with >> FreeIPA 3.3.3-28 by using replication. >> >> I have prepared replication file and moved it to the new replica server. >> Configured the firewalld and installed Ipa and other needed packages via yum. >> >> When running "ipa-replica-install --setup-ca -d" installation will always >> stuck on: >> >> ---------------------------------------------------------------------- >> "Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 >> seconds >> [2/19]: configuring certificate server instance >> ipa : DEBUG Starting external process >> ipa : DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpHJBhR5 >> ipa : DEBUG Process finished, return code=1 >> ipa : DEBUG stdout=Loading deployment configuration from >> /tmp/tmpHJBhR5. >> Installing CA into /var/lib/pki/pki-tomcat. >> Storing deployment configuration into >> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. >> Installation failed. >> >> >> ipa : DEBUG stderr=pkispawn : WARNING ....... unable to >> validate security domain user/password through REST interface. Interface not >> available >> pkispawn : ERROR ....... Exception from Java Configuration Servlet: >> Error while updating security domain: java.io.IOException: >> java.io.IOException: SocketException cannot read on socket >> >> ipa : CRITICAL failed to configure ca instance Command >> '/usr/sbin/pkispawn -s CA -f /tmp/tmpHJBhR5' returned non-zero exit status 1 >> ---------------------------------------------------------------------- >> >> Betwee the attempts I have cleaned yu ipa and pki configurations and >> deleteted the old replication agreement. >> >> >> Apache logs on old CentOS 6 server have these errors. >> ---------------------------------------------------------------------- >> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >> /ca/admin/ca/getDomainXML HTTP/1.0" 200 1158 >> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >> /ca/admin/ca/updateDomainXML HTTP/1.0" 404 - >> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >> /ca/agent/ca/updateDomainXML HTTP/1.0" 403 323 >> [Thu Feb 19 11:38:44 2015] [error] Bad remote server certificate: -8181 >> [Thu Feb 19 11:38:44 2015] [error] SSL Library Error: -8181 Certificate has >> expired >> [Thu Feb 19 11:38:44 2015] [error] Re-negotiation handshake failed: Not >> accepted by client!? >> ---------------------------------------------------------------------- >> >> What certificate this means? ca.crt have more than five years left. >> >> Clocks are synced, /ca/admin/ca/updateDomainXML can be found on >> ipa-pki-proxy.conf and there are no obvious reason. Any hints? > > Are CA ports accessible on your master? Can you check your FW please? > This line makes me think that expired certs may be involved: [Thu Feb 19 11:38:44 2015] [error] SSL Library Error: -8181 Certificate has expired CCing JanCh who have the best context in this area. From dpal at redhat.com Thu Feb 19 16:23:34 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 19 Feb 2015 11:23:34 -0500 Subject: [Freeipa-users] FreeIPA and Application Specific Passwords In-Reply-To: <20150219100658.GA18794@redhat.com> References: <54E5290F.8020301@sonic.com> <20150219100658.GA18794@redhat.com> Message-ID: <54E60E06.4000202@redhat.com> On 02/19/2015 05:06 AM, Jan Pazdziora wrote: > On Wed, Feb 18, 2015 at 04:06:39PM -0800, Martin Minkus wrote: >> Except where we don't want single sign on, and separate passwords are >> advantageous or even required: >> >> - Web logins > Could you elaborate on the use cases when you'd want your users to log > in using their passwords on a Web login, instead of using SSO, be it > Kerberos or SAML? Is that purely the application not supporting it > or are there some other reasons (you say "we don't want single sign > on" which sounds like a political or compliance issue, not technical > one). > IMO the case is: I have a phone and a tablet and a laptop. I do not want to use one password for all three. On the phone and tablet people save their passwords so I do not want to have same password cached on all devices. I want to have a password per device. IMO the way to go is certs rather than passwords. We are not there yet but with upcoming changes we will get much closer. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From mkosek at redhat.com Thu Feb 19 16:29:13 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Feb 2015 17:29:13 +0100 Subject: [Freeipa-users] FreeIPA and Application Specific Passwords In-Reply-To: <54E60E06.4000202@redhat.com> References: <54E5290F.8020301@sonic.com> <20150219100658.GA18794@redhat.com> <54E60E06.4000202@redhat.com> Message-ID: <54E60F59.3090304@redhat.com> On 02/19/2015 05:23 PM, Dmitri Pal wrote: > On 02/19/2015 05:06 AM, Jan Pazdziora wrote: >> On Wed, Feb 18, 2015 at 04:06:39PM -0800, Martin Minkus wrote: >>> Except where we don't want single sign on, and separate passwords are >>> advantageous or even required: >>> >>> - Web logins >> Could you elaborate on the use cases when you'd want your users to log >> in using their passwords on a Web login, instead of using SSO, be it >> Kerberos or SAML? Is that purely the application not supporting it >> or are there some other reasons (you say "we don't want single sign >> on" which sounds like a political or compliance issue, not technical >> one). >> > IMO the case is: > I have a phone and a tablet and a laptop. > I do not want to use one password for all three. > On the phone and tablet people save their passwords so I do not want to have > same password cached on all devices. I want to have a password per device. > > IMO the way to go is certs rather than passwords. Certs would certainly help in this case. However, the UX would need to be really good in order to beat saved password in GMail style, IMO. > We are not there yet but with upcoming changes we will get much closer. > From dpal at redhat.com Thu Feb 19 16:32:45 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 19 Feb 2015 11:32:45 -0500 Subject: [Freeipa-users] FreeIPA and Application Specific Passwords In-Reply-To: <54E60F59.3090304@redhat.com> References: <54E5290F.8020301@sonic.com> <20150219100658.GA18794@redhat.com> <54E60E06.4000202@redhat.com> <54E60F59.3090304@redhat.com> Message-ID: <54E6102D.9010505@redhat.com> On 02/19/2015 11:29 AM, Martin Kosek wrote: > On 02/19/2015 05:23 PM, Dmitri Pal wrote: >> On 02/19/2015 05:06 AM, Jan Pazdziora wrote: >>> On Wed, Feb 18, 2015 at 04:06:39PM -0800, Martin Minkus wrote: >>>> Except where we don't want single sign on, and separate passwords are >>>> advantageous or even required: >>>> >>>> - Web logins >>> Could you elaborate on the use cases when you'd want your users to log >>> in using their passwords on a Web login, instead of using SSO, be it >>> Kerberos or SAML? Is that purely the application not supporting it >>> or are there some other reasons (you say "we don't want single sign >>> on" which sounds like a political or compliance issue, not technical >>> one). >>> >> IMO the case is: >> I have a phone and a tablet and a laptop. >> I do not want to use one password for all three. >> On the phone and tablet people save their passwords so I do not want to have >> same password cached on all devices. I want to have a password per device. >> >> IMO the way to go is certs rather than passwords. > Certs would certainly help in this case. However, the UX would need to be > really good in order to beat saved password in GMail style, IMO. I imagine Ipsilon based SSO when Ipsilon can make a decision which assertions to issue depending on the cert you have. > >> We are not there yet but with upcoming changes we will get much closer. >> -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From jwest at iki.fi Thu Feb 19 16:37:11 2015 From: jwest at iki.fi (Jani West) Date: Thu, 19 Feb 2015 18:37:11 +0200 Subject: [Freeipa-users] Migration fails from 3.0.0 to 3.3.3 on Centos 6/7 In-Reply-To: <54E60DB5.7080206@redhat.com> References: <54E5FC3D.3070904@iki.fi> <54E60BF5.7@redhat.com> <54E60DB5.7080206@redhat.com> Message-ID: <54E61137.5030906@iki.fi> Hi, How I can check the cert and test? I did curl -v -k https://xxx/ca/admin/ca/getDomainXML According to that the cert have plenty of time left. On the otherhand https://xxx/ca/admin/ca/updateDomainXML is givin the the same cert but also http 404. On 02/19/2015 06:22 PM, Martin Kosek wrote: > On 02/19/2015 05:14 PM, Dmitri Pal wrote: >> On 02/19/2015 10:07 AM, Jani West wrote: >>> Trying to migrate from CentOS 6.6 with FreeIPA 3.0.0-42 to CentOS 7.0 with >>> FreeIPA 3.3.3-28 by using replication. >>> >>> I have prepared replication file and moved it to the new replica server. >>> Configured the firewalld and installed Ipa and other needed packages via yum. >>> >>> When running "ipa-replica-install --setup-ca -d" installation will always >>> stuck on: >>> >>> ---------------------------------------------------------------------- >>> "Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 >>> seconds >>> [2/19]: configuring certificate server instance >>> ipa : DEBUG Starting external process >>> ipa : DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpHJBhR5 >>> ipa : DEBUG Process finished, return code=1 >>> ipa : DEBUG stdout=Loading deployment configuration from >>> /tmp/tmpHJBhR5. >>> Installing CA into /var/lib/pki/pki-tomcat. >>> Storing deployment configuration into >>> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. >>> Installation failed. >>> >>> >>> ipa : DEBUG stderr=pkispawn : WARNING ....... unable to >>> validate security domain user/password through REST interface. Interface not >>> available >>> pkispawn : ERROR ....... Exception from Java Configuration Servlet: >>> Error while updating security domain: java.io.IOException: >>> java.io.IOException: SocketException cannot read on socket >>> >>> ipa : CRITICAL failed to configure ca instance Command >>> '/usr/sbin/pkispawn -s CA -f /tmp/tmpHJBhR5' returned non-zero exit status 1 >>> ---------------------------------------------------------------------- >>> >>> Betwee the attempts I have cleaned yu ipa and pki configurations and >>> deleteted the old replication agreement. >>> >>> >>> Apache logs on old CentOS 6 server have these errors. >>> ---------------------------------------------------------------------- >>> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >>> /ca/admin/ca/getDomainXML HTTP/1.0" 200 1158 >>> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >>> /ca/admin/ca/updateDomainXML HTTP/1.0" 404 - >>> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >>> /ca/agent/ca/updateDomainXML HTTP/1.0" 403 323 >>> [Thu Feb 19 11:38:44 2015] [error] Bad remote server certificate: -8181 >>> [Thu Feb 19 11:38:44 2015] [error] SSL Library Error: -8181 Certificate has >>> expired >>> [Thu Feb 19 11:38:44 2015] [error] Re-negotiation handshake failed: Not >>> accepted by client!? >>> ---------------------------------------------------------------------- >>> >>> What certificate this means? ca.crt have more than five years left. >>> >>> Clocks are synced, /ca/admin/ca/updateDomainXML can be found on >>> ipa-pki-proxy.conf and there are no obvious reason. Any hints? >> >> Are CA ports accessible on your master? Can you check your FW please? >> > > This line makes me think that expired certs may be involved: > > [Thu Feb 19 11:38:44 2015] [error] SSL Library Error: -8181 Certificate has > expired > > CCing JanCh who have the best context in this area. > -- -- Jani West -- jwest at iki.fi -- +358 40 5010914 -- -- Liinalahdentie 4 -- 01800 KLAUKKALA -- FINLAND -- "Haluaisin, ett? Suomi olisi paljon monikulttuurisempi. T?nne tulee muualta paljon ihmisi?, mutta heit? ei tuoda tarpeeksi esille. Jotenkin me pid?mme heid?t verhojen takana. On t?rke??, ett? Suomesta saataisiin avoin ja suvaitsevainen. Sulkeutunut ajattelutapa on Suomen ongelma. Ehk? me pelk??mme mielenosoituksia, joita esimerkiksi Ruotsin l?hi?iss? on ollut ja sit?, ett? jotain kauheaa tapahtuu. Ei ymm?rret?, ett? maahanmuuttajat voivat tuoda Suomeen my?s paljon hyv??. Toivoisin hallitukselta sit?, ett? koko kansaa kuullaan, my?s eri kulttuureista tulevia. Hallituksen pit?isi rahoittaa ja tukea enemm?n Suomen kansainv?list?mist?. My?s eduskunta voisi kuunnella maahanmuuttajia enemm?n." HS 8.6.2013: Essi, 16 v. Etu-T??l?n lukio. From jrichard at placeiq.com Thu Feb 19 19:11:51 2015 From: jrichard at placeiq.com (Jim Richard) Date: Thu, 19 Feb 2015 14:11:51 -0500 Subject: [Freeipa-users] Excessive CPU usage by ns-slapd In-Reply-To: <54E5F433.50702@redhat.com> References: <30BE1A3D-7170-485D-9A91-C868682450D9@placeiq.com> <54E57D28.103@redhat.com> <54E5F433.50702@redhat.com> Message-ID: <09887AA8-5F57-495E-9AFC-2B34969DBB66@placeiq.com> Hi Rich, here?s what all 4 of my IPA servers look like right now. You can see that SSO-107?s CPU usage is much higher than the other 3 and it spikes to over 100% often. And what I see over time is that the higher and higher cpu usage will happen between two of my four servers, one will drop off and the other increases and each time this cycle happens, the cpu usage on the one server that is spiking will get a little bit higher. The two servers that show this behavior are SSO-107 and SSO-109. I?ve attached some more detailed stack trace as well. Here?s what my replication agreements look like: [root at sso-107 (NY) ~]$ ipa-replica-manage list sso-108.nym1.placeiq.net: master sso-110.nym1.placeiq.net: master sso-107.nym1.placeiq.net: master sso-109.nym1.placeiq.net: master [root at sso-107 (NY) ~]$ ipa-replica-manage list sso-107.nym1.placeiq.net sso-108.nym1.placeiq.net: replica sso-110.nym1.placeiq.net: replica [root at sso-107 (NY) ~]$ ipa-replica-manage list sso-108.nym1.placeiq.net sso-107.nym1.placeiq.net: replica sso-109.nym1.placeiq.net: replica [root at sso-107 (NY) ~]$ ipa-replica-manage list sso-109.nym1.placeiq.net sso-108.nym1.placeiq.net: replica sso-110.nym1.placeiq.net: replica [root at sso-107 (NY) ~]$ ipa-replica-manage list sso-110.nym1.placeiq.net sso-107.nym1.placeiq.net: replica sso-109.nym1.placeiq.net: replica SSO-107 top - 15:58:08 up 2 days, 10:00, 1 user, load average: 0.00, 0.03, 0.06 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 12.2%us, 1.1%sy, 0.0%ni, 86.7%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2952788k total, 2160216k used, 792572k free, 182584k buffers Swap: 4094972k total, 0k used, 4094972k free, 678292k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11615 dirsrv 20 0 2063m 843m 19m S 25.5 29.3 403:53.56 ns-slapd [root at sso-107 (NY) /var/log/dirsrv/slapd-PLACEIQ-NET]$ ls -al /proc/`cat /var/run/dirsrv/slapd-PLACEIQ-NET.pid`/fd|grep socket|wc -l 245 SSO-108 top - 15:57:26 up 3 days, 17:25, 1 user, load average: 0.03, 0.03, 0.00 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 0.3%us, 0.2%sy, 0.0%ni, 99.4%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2952788k total, 2200792k used, 751996k free, 182084k buffers Swap: 4094972k total, 0k used, 4094972k free, 713848k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 24399 dirsrv 20 0 2055m 819m 19m S 0.8 28.4 54:48.53 ns-slapd [root at sso-108 (NY) /var/log/dirsrv/slapd-PLACEIQ-NET]$ ls -al /proc/`cat /var/run/dirsrv/slapd-PLACEIQ-NET.pid`/fd|grep socket|wc -l 232 SSO-109 top - 16:00:05 up 4 days, 9:10, 1 user, load average: 0.06, 0.32, 0.35 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 0.7%us, 0.3%sy, 0.0%ni, 98.9%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2952788k total, 2422572k used, 530216k free, 235472k buffers Swap: 4094972k total, 0k used, 4094972k free, 906080k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 22522 dirsrv 20 0 2065m 772m 19m S 1.2 26.8 308:13.07 ns-slapd [root at sso-109 (NY) ~]$ ls -al /proc/`cat /var/run/dirsrv/slapd-PLACEIQ-NET.pid`/fd|grep socket|wc -l 219 SSO-110 top - 16:07:54 up 14 days, 18:03, 1 user, load average: 0.00, 0.01, 0.00 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 2.0%us, 1.0%sy, 0.0%ni, 96.7%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2952788k total, 2304556k used, 648232k free, 155216k buffers Swap: 4094972k total, 64k used, 4094908k free, 748972k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2401 dirsrv 20 0 2074m 839m 18m S 4.8 29.1 48:25.58 ns-slapd [root at sso-110 (NY) /var/log/dirsrv/slapd-PLACEIQ-NET]$ ls -al /proc/`cat /var/run/dirsrv/slapd-PLACEIQ-NET.pid`/fd|grep socket|wc -l 257 Jim Richard | PlaceIQ | Systems Administrator | jrichard at placeiq.com | +1 (646) 338-8905 <> > On Feb 19, 2015, at 9:33 AM, Rich Megginson wrote: > > On 02/18/2015 11:05 PM, Jatin Nansi wrote: >> Check the ns-slapd access and error logs of the DS instance hosting the IPA instance. The strace output indicates that ns-slapd spent most of its time waiting for network activity to happen (poll), which is normal for ns-slapd. > > The number of open connections correlates to the CPU usage. Do this: > > # ls -al /proc/`cat /var/run/dirsrv/slapd-MY-DOMAIN.pid`/fd|grep socket|wc -l > > How many socket connections do you have? > > Also, it will be very useful to get some stack traces of the running server to see what the various threads are doing. See http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs > >> >> Jatin >> On 19/02/15 15:52, Jim Richard wrote: >>> I?ve got 4 Redhat IDM masters in a multi-master config. 3.0.0-42.el6.centos is the IPA version, 389-ds-base version 1.2.11.15-48.el6_6, Centos 6.6 >>> >>> Monitoring established connections on port 389 and dsInOps over time shows a consistent/even level of activity however 2 of the 4 IPA servers show ever increasing CPI usage by ns-slapd. One ns-slapd process will start to show increased CPU for a time, then drop off as another then increases. This cycle continues with each switch seeing more and more total SPU usage by ns-slapd. >>> >>> strace timing for the offending ns-slapd looks like the following: >>> >>> >>> % time seconds usecs/call calls errors syscall >>> ------ ----------- ----------- --------- --------- ---------------- >>> 96.12 9.342272 1133 8243 poll >>> 3.86 0.375457 53 7066 41 futex >>> 0.01 0.000668 0 8244 8244 getpeername >>> 0.00 0.000374 0 929 close >>> 0.00 0.000368 0 3201 read >>> 0.00 0.000151 0 882 setsockopt >>> 0.00 0.000095 2 42 access >>> 0.00 0.000033 0 1365 fcntl >>> 0.00 0.000000 0 42 open >>> 0.00 0.000000 0 39 stat >>> 0.00 0.000000 0 42 fstat >>> 0.00 0.000000 0 1 madvise >>> 0.00 0.000000 0 441 accept >>> 0.00 0.000000 0 441 getsockname >>> 0.00 0.000000 0 1 restart_syscall >>> ------ ----------- ----------- --------- --------- ---------------- >>> 100.00 9.719418 30979 8285 total >>> >>> >>> I have carefully reviewed cn=config settings on all four master servers to confirm that they match. >>> >>> Based on this strace output can you perhaps point me in the right direction, give me a clue on what I should be looking at. >>> >>> Here?s a screen shot of my Zabbix reporting to help describe the problem. Note the graph in the bottom right corner. >>> >>> The problem is most certainly related to replication but I just don?t know what specifically to look at. >>> >>> >>> >>> >>> >>> Thanks in advance for any clues you can provide. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Jim Richard | PlaceIQ | Systems Administrator | jrichard at placeiq.com | +1 (646) 338-8905 <> >>> >>> >>> >>> >>> >> >> >> > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sso-107-stacktrace.1424369987.txt URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sso-109-stacktrace.1424370008.txt URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.raehalme at codecenter.fi Thu Feb 19 19:41:28 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Thu, 19 Feb 2015 21:41:28 +0200 Subject: [Freeipa-users] How to remove an offline replica? Message-ID: Hi! I have a replica which is offline, and I'd like to remove it (to be later replaced). When trying to remove the replica with ipa-replica-manage according to the instructions on the wiki, I get an error about inaccessible LDAP server: # ipa-replica-manage del ipa-1.example.com Connection to 'ipa-1.example.com' failed: Can't contact LDAP server Unable to delete replica 'ipa-1.example.com' ipa-1.example.com is the IPA replica and I am executing the command on IPA master. I also tried disconnect, but the result was the same: # ipa-replica-manage disconnect ipa-1.example.com Failed to get list of agreements from 'ipa-1.example.com': Can't contact LDAP server Does anyone have a hint on how to get the replica removed? I'm running ipa-server-3.0.0-42 on CentOS 6.6. Thanks! Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.raehalme at codecenter.fi Thu Feb 19 19:45:19 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Thu, 19 Feb 2015 21:45:19 +0200 Subject: [Freeipa-users] How to remove an offline replica? In-Reply-To: References: Message-ID: On Thu, Feb 19, 2015 at 9:41 PM, Thomas Raehalme < thomas.raehalme at codecenter.fi> wrote: > # ipa-replica-manage del ipa-1.example.com > Connection to 'ipa-1.example.com' failed: Can't contact LDAP server > Unable to delete replica 'ipa-1.example.com' > And right after posting I found the --force command-line parameter which did the trick! Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Feb 19 19:45:50 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Feb 2015 14:45:50 -0500 Subject: [Freeipa-users] How to remove an offline replica? In-Reply-To: References: Message-ID: <54E63D6E.8020604@redhat.com> Thomas Raehalme wrote: > Hi! > > I have a replica which is offline, and I'd like to remove it (to be > later replaced). > > When trying to remove the replica with ipa-replica-manage according to > the instructions on the wiki, I get an error about inaccessible LDAP server: > > # ipa-replica-manage del ipa-1.example.com > Connection to 'ipa-1.example.com ' failed: > Can't contact LDAP server > Unable to delete replica 'ipa-1.example.com ' > > ipa-1.example.com is the IPA replica and I am > executing the command on IPA master. > > I also tried disconnect, but the result was the same: > > # ipa-replica-manage disconnect ipa-1.example.com > Failed to get list of agreements from 'ipa-1.example.com > ': Can't contact LDAP server > > Does anyone have a hint on how to get the replica removed? I'm running > ipa-server-3.0.0-42 on CentOS 6.6. Add the --force flag. rob From rmeggins at redhat.com Thu Feb 19 19:47:34 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 19 Feb 2015 12:47:34 -0700 Subject: [Freeipa-users] Excessive CPU usage by ns-slapd In-Reply-To: <09887AA8-5F57-495E-9AFC-2B34969DBB66@placeiq.com> References: <30BE1A3D-7170-485D-9A91-C868682450D9@placeiq.com> <54E57D28.103@redhat.com> <54E5F433.50702@redhat.com> <09887AA8-5F57-495E-9AFC-2B34969DBB66@placeiq.com> Message-ID: <54E63DD6.2020407@redhat.com> On 02/19/2015 12:11 PM, Jim Richard wrote: > Hi Rich, here?s what all 4 of my IPA servers look like right now. You > can see that SSO-107?s CPU usage is much higher than the other 3 and > it spikes to over 100% often. And what I see over time is that the > higher and higher cpu usage will happen between two of my four > servers, one will drop off and the other increases and each time this > cycle happens, the cpu usage on the one server that is spiking will > get a little bit higher. > > The two servers that show this behavior are SSO-107 and SSO-109. SSO-107 is almost entirely idle except for 1 thread doing replication updates, and the poll thread. There are 255 descriptors it is polling on. SSO-109 is entirely idle except for the poll thread. There are 230 descriptors it is polling on. You might try using top with the ns-slapd process and the 'H' - Threads mode flag. It would be very interesting to see the cpu usage breakdown by thread. If it is indeed the poll thread that is consuming all of the cpu, there's not much that can be done. CPU usage in the poll thread is a function of the number of connections, but since there is not much difference between 230 and 255, I would not expect a large CPU usage difference between 107 and 109 based solely on number of connections. Are you seeing timeouts or application failures or poor performance that seems to be due to high CPU usage? If so, and these are virtual machines, you might consider adding more virtual CPUs to give the server more processing power for the worker threads to compensate for monopolization by the poll thread. > > I?ve attached some more detailed stack trace as well. > > > > > > > > > > Here?s what my replication agreements look like: > > [root at sso-107 (NY) ~]$ ipa-replica-manage list > sso-108.nym1.placeiq.net : master > sso-110.nym1.placeiq.net : master > sso-107.nym1.placeiq.net : master > sso-109.nym1.placeiq.net : master > > [root at sso-107 (NY) ~]$ ipa-replica-manage list > sso-107.nym1.placeiq.net > sso-108.nym1.placeiq.net : replica > sso-110.nym1.placeiq.net : replica > > [root at sso-107 (NY) ~]$ ipa-replica-manage list > sso-108.nym1.placeiq.net > sso-107.nym1.placeiq.net : replica > sso-109.nym1.placeiq.net : replica > > [root at sso-107 (NY) ~]$ ipa-replica-manage list > sso-109.nym1.placeiq.net > sso-108.nym1.placeiq.net : replica > sso-110.nym1.placeiq.net : replica > > [root at sso-107 (NY) ~]$ ipa-replica-manage list > sso-110.nym1.placeiq.net > sso-107.nym1.placeiq.net : replica > sso-109.nym1.placeiq.net : replica > > > > > > SSO-107 > > top - 15:58:08 up 2 days, 10:00, 1 user, load average: 0.00, 0.03, 0.06 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 12.2%us, 1.1%sy, 0.0%ni, 86.7%id, 0.1%wa, 0.0%hi, 0.0%si, > 0.0%st > Mem: 2952788k total, 2160216k used, 792572k free, 182584k buffers > Swap: 4094972k total, 0k used, 4094972k free, 678292k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 11615 dirsrv 20 0 2063m 843m 19m S 25.5 29.3 403:53.56 ns-slapd > > [root at sso-107 (NY) /var/log/dirsrv/slapd-PLACEIQ-NET]$ ls -al > /proc/`cat /var/run/dirsrv/slapd-PLACEIQ-NET.pid`/fd|grep socket|wc -l > 245 > > > > > SSO-108 > > top - 15:57:26 up 3 days, 17:25, 1 user, load average: 0.03, 0.03, 0.00 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.3%us, 0.2%sy, 0.0%ni, 99.4%id, 0.1%wa, 0.0%hi, 0.0%si, > 0.0%st > Mem: 2952788k total, 2200792k used, 751996k free, 182084k buffers > Swap: 4094972k total, 0k used, 4094972k free, 713848k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 24399 dirsrv 20 0 2055m 819m 19m S 0.8 28.4 54:48.53 ns-slapd > > [root at sso-108 (NY) /var/log/dirsrv/slapd-PLACEIQ-NET]$ ls -al > /proc/`cat /var/run/dirsrv/slapd-PLACEIQ-NET.pid`/fd|grep socket|wc -l > 232 > > > > > SSO-109 > > top - 16:00:05 up 4 days, 9:10, 1 user, load average: 0.06, 0.32, 0.35 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.7%us, 0.3%sy, 0.0%ni, 98.9%id, 0.2%wa, 0.0%hi, 0.0%si, > 0.0%st > Mem: 2952788k total, 2422572k used, 530216k free, 235472k buffers > Swap: 4094972k total, 0k used, 4094972k free, 906080k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 22522 dirsrv 20 0 2065m 772m 19m S 1.2 26.8 308:13.07 ns-slapd > > [root at sso-109 (NY) ~]$ ls -al /proc/`cat > /var/run/dirsrv/slapd-PLACEIQ-NET.pid`/fd|grep socket|wc -l > 219 > > > > > > SSO-110 > > top - 16:07:54 up 14 days, 18:03, 1 user, load average: 0.00, 0.01, 0.00 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 2.0%us, 1.0%sy, 0.0%ni, 96.7%id, 0.3%wa, 0.0%hi, 0.0%si, > 0.0%st > Mem: 2952788k total, 2304556k used, 648232k free, 155216k buffers > Swap: 4094972k total, 64k used, 4094908k free, 748972k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 2401 dirsrv 20 0 2074m 839m 18m S 4.8 29.1 48:25.58 ns-slapd > [root at sso-110 (NY) /var/log/dirsrv/slapd-PLACEIQ-NET]$ ls -al > /proc/`cat /var/run/dirsrv/slapd-PLACEIQ-NET.pid`/fd|grep socket|wc -l > 257 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jim Richard | PlaceIQ > | > Systems Administrator | jrichard at placeiq.com > | +1 (646) 338-8905 > > > > >> On Feb 19, 2015, at 9:33 AM, Rich Megginson > > wrote: >> >> On 02/18/2015 11:05 PM, Jatin Nansi wrote: >>> Check the ns-slapd access and error logs of the DS instance hosting >>> the IPA instance. The strace output indicates that ns-slapd spent >>> most of its time waiting for network activity to happen (poll), >>> which is normal for ns-slapd. >> >> The number of open connections correlates to the CPU usage. Do this: >> >> # ls -al /proc/`cat /var/run/dirsrv/slapd-MY-DOMAIN.pid`/fd|grep >> socket|wc -l >> >> How many socket connections do you have? >> >> Also, it will be very useful to get some stack traces of the running >> server to see what the various threads are doing. See >> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs >> >>> >>> Jatin >>> On 19/02/15 15:52, Jim Richard wrote: >>>> I?ve got 4 Redhat IDM masters in a multi-master >>>> config. 3.0.0-42.el6.centos is the IPA version, 389-ds-base version >>>> 1.2.11.15-48.el6_6, Centos 6.6 >>>> >>>> Monitoring established connections on port 389 and dsInOps over >>>> time shows a consistent/even level of activity however 2 of the 4 >>>> IPA servers show ever increasing CPI usage by ns-slapd. One >>>> ns-slapd process will start to show increased CPU for a time, then >>>> drop off as another then increases. This cycle continues with each >>>> switch seeing more and more total SPU usage by ns-slapd. >>>> >>>> strace timing for the offending ns-slapd looks like the following: >>>> >>>> > >>>> % time seconds usecs/call calls errors syscall >>>> ------ ----------- ----------- --------- --------- ---------------- >>>> 96.12 9.342272 1133 8243 poll >>>> 3.86 0.375457 53 7066 41 futex >>>> 0.01 0.000668 0 8244 8244 getpeername >>>> 0.00 0.000374 0 929 close >>>> 0.00 0.000368 0 3201 read >>>> 0.00 0.000151 0 882 setsockopt >>>> 0.00 0.000095 2 42 access >>>> 0.00 0.000033 0 1365 fcntl >>>> 0.00 0.000000 0 42 open >>>> 0.00 0.000000 0 39 stat >>>> 0.00 0.000000 0 42 fstat >>>> 0.00 0.000000 0 1 madvise >>>> 0.00 0.000000 0 441 accept >>>> 0.00 0.000000 0 441 getsockname >>>> 0.00 0.000000 0 1 restart_syscall >>>> ------ ----------- ----------- --------- --------- ---------------- >>>> 100.00 9.719418 30979 8285 total >>>> >>>> >>>> I have carefully reviewed cn=config settings on all four master >>>> servers to confirm that they match. >>>> >>>> Based on this strace output can you perhaps point me in the right >>>> direction, give me a clue on what I should be looking at. >>>> >>>> Here?s a screen shot of my Zabbix reporting to help describe the >>>> problem. Note the graph in the bottom right corner. >>>> >>>> The problem is most certainly related to replication but I just >>>> don?t know what specifically to look at. >>>> >>>> >>>> >>>> >>>> >>>> Thanks in advance for any clues you can provide. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Jim Richard | PlaceIQ >>>> | >>>> Systems Administrator | jrichard at placeiq.com >>>> | +1 (646) 338-8905 >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrichard at placeiq.com Thu Feb 19 19:54:44 2015 From: jrichard at placeiq.com (Jim Richard) Date: Thu, 19 Feb 2015 14:54:44 -0500 Subject: [Freeipa-users] Migration fails from 3.0.0 to 3.3.3 on Centos 6/7 In-Reply-To: <54E61137.5030906@iki.fi> References: <54E5FC3D.3070904@iki.fi> <54E60BF5.7@redhat.com> <54E60DB5.7080206@redhat.com> <54E61137.5030906@iki.fi> Message-ID: Hey guys, for what it?s worth, I spent a couple weeks working with Endi Sukma Dewata, edewata at redhat.com, "Re: [Freeipa-users] Redhat/Centos iDM 3.0 to 3.1 upgrade fail?. Unfortunately my post subject was not accurate but in fact, I was attempting the exact same thing and seeing the exact same error. The main LDAP instance would come up ok but upon attempting to migrate the PKI stuff with the new ldap schema etc, it just fails? In the end we couldn?t figure it out, basically had to just give up. Maybe one of you could reach out to Endi and he could share some insights. I?d love to be able to make this work as well but as of now it looks like my only option if I want to upgrade to version 3.3/Centos 7 is well, there is no option?. I?d be happy to share or help in any way. Jim Richard | PlaceIQ | Systems Administrator | jrichard at placeiq.com | +1 (646) 338-8905 <> > On Feb 19, 2015, at 11:37 AM, Jani West wrote: > > Hi, > > How I can check the cert and test? > > I did curl -v -k https://xxx/ca/admin/ca/getDomainXML > > According to that the cert have plenty of time left. > > On the otherhand > https://xxx/ca/admin/ca/updateDomainXML is givin the the same cert but also http 404. > > On 02/19/2015 06:22 PM, Martin Kosek wrote: >> On 02/19/2015 05:14 PM, Dmitri Pal wrote: >>> On 02/19/2015 10:07 AM, Jani West wrote: >>>> Trying to migrate from CentOS 6.6 with FreeIPA 3.0.0-42 to CentOS 7.0 with >>>> FreeIPA 3.3.3-28 by using replication. >>>> >>>> I have prepared replication file and moved it to the new replica server. >>>> Configured the firewalld and installed Ipa and other needed packages via yum. >>>> >>>> When running "ipa-replica-install --setup-ca -d" installation will always >>>> stuck on: >>>> >>>> ---------------------------------------------------------------------- >>>> "Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 >>>> seconds >>>> [2/19]: configuring certificate server instance >>>> ipa : DEBUG Starting external process >>>> ipa : DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpHJBhR5 >>>> ipa : DEBUG Process finished, return code=1 >>>> ipa : DEBUG stdout=Loading deployment configuration from >>>> /tmp/tmpHJBhR5. >>>> Installing CA into /var/lib/pki/pki-tomcat. >>>> Storing deployment configuration into >>>> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. >>>> Installation failed. >>>> >>>> >>>> ipa : DEBUG stderr=pkispawn : WARNING ....... unable to >>>> validate security domain user/password through REST interface. Interface not >>>> available >>>> pkispawn : ERROR ....... Exception from Java Configuration Servlet: >>>> Error while updating security domain: java.io.IOException: >>>> java.io.IOException: SocketException cannot read on socket >>>> >>>> ipa : CRITICAL failed to configure ca instance Command >>>> '/usr/sbin/pkispawn -s CA -f /tmp/tmpHJBhR5' returned non-zero exit status 1 >>>> ---------------------------------------------------------------------- >>>> >>>> Betwee the attempts I have cleaned yu ipa and pki configurations and >>>> deleteted the old replication agreement. >>>> >>>> >>>> Apache logs on old CentOS 6 server have these errors. >>>> ---------------------------------------------------------------------- >>>> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >>>> /ca/admin/ca/getDomainXML HTTP/1.0" 200 1158 >>>> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >>>> /ca/admin/ca/updateDomainXML HTTP/1.0" 404 - >>>> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >>>> /ca/agent/ca/updateDomainXML HTTP/1.0" 403 323 >>>> [Thu Feb 19 11:38:44 2015] [error] Bad remote server certificate: -8181 >>>> [Thu Feb 19 11:38:44 2015] [error] SSL Library Error: -8181 Certificate has >>>> expired >>>> [Thu Feb 19 11:38:44 2015] [error] Re-negotiation handshake failed: Not >>>> accepted by client!? >>>> ---------------------------------------------------------------------- >>>> >>>> What certificate this means? ca.crt have more than five years left. >>>> >>>> Clocks are synced, /ca/admin/ca/updateDomainXML can be found on >>>> ipa-pki-proxy.conf and there are no obvious reason. Any hints? >>> >>> Are CA ports accessible on your master? Can you check your FW please? >>> >> >> This line makes me think that expired certs may be involved: >> >> [Thu Feb 19 11:38:44 2015] [error] SSL Library Error: -8181 Certificate has >> expired >> >> CCing JanCh who have the best context in this area. >> > > > -- > -- Jani West -- jwest at iki.fi -- +358 40 5010914 -- > -- Liinalahdentie 4 -- 01800 KLAUKKALA -- FINLAND -- > > "Haluaisin, ett? Suomi olisi paljon monikulttuurisempi. > T?nne tulee muualta paljon ihmisi?, mutta heit? ei tuoda > tarpeeksi esille. Jotenkin me pid?mme heid?t verhojen takana. > On t?rke??, ett? Suomesta saataisiin avoin ja suvaitsevainen. > Sulkeutunut ajattelutapa on Suomen ongelma. Ehk? me > pelk??mme mielenosoituksia, joita esimerkiksi Ruotsin > l?hi?iss? on ollut ja sit?, ett? jotain kauheaa tapahtuu. > Ei ymm?rret?, ett? maahanmuuttajat voivat tuoda > Suomeen my?s paljon hyv??. Toivoisin hallitukselta sit?, > ett? koko kansaa kuullaan, my?s eri kulttuureista > tulevia. Hallituksen pit?isi rahoittaa ja tukea enemm?n > Suomen kansainv?list?mist?. My?s eduskunta voisi kuunnella > maahanmuuttajia enemm?n." > > HS 8.6.2013: Essi, 16 v. Etu-T??l?n lukio. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwest at iki.fi Thu Feb 19 22:14:14 2015 From: jwest at iki.fi (Jani West) Date: Fri, 20 Feb 2015 00:14:14 +0200 Subject: [Freeipa-users] Migration fails from 3.0.0 to 3.3.3 on Centos 6/7 In-Reply-To: References: <54E5FC3D.3070904@iki.fi> <54E60BF5.7@redhat.com> <54E60DB5.7080206@redhat.com> <54E61137.5030906@iki.fi> Message-ID: <54E66036.7060302@iki.fi> Hi, I can also test If there is any ideas. I have fresh CentOS 7 vm with snapshots. Absolutely this is related to CA / Tomcat PKI as Jim said. I have fidled a bit with the /etc/httpd/conf.d/ipa-pki-proxy.conf on old server to fix LocationMatch/Proxying I changed this # matches for admin port and installer # -> All the matches will be redirected to ajp://localhost:9447 No difference. On 02/19/2015 09:54 PM, Jim Richard wrote: > Hey guys, for what it?s worth, I spent a couple weeks working with Endi > Sukma Dewata, edewata at redhat.com , "Re: > [Freeipa-users] Redhat/Centos iDM 3.0 to 3.1 upgrade fail?. > > Unfortunately my post subject was not accurate but in fact, I was > attempting the exact same thing and seeing the exact same error. The > main LDAP instance would come up ok but upon attempting to migrate the > PKI stuff with the new ldap schema etc, it just fails? > > > In the end we couldn?t figure it out, basically had to just give up. > > Maybe one of you could reach out to Endi and he could share some insights. > > I?d love to be able to make this work as well but as of now it looks > like my only option if I want to upgrade to version 3.3/Centos 7 is > well, there is no option?. > > I?d be happy to share or help in any way. > > > > > Jim Richard | PlaceIQ > | > Systems Administrator | jrichard at placeiq.com > | +1 (646) 338-8905 > > > > >> On Feb 19, 2015, at 11:37 AM, Jani West > > wrote: >> >> Hi, >> >> How I can check the cert and test? >> >> I did curl -v -k https://xxx/ca/admin/ca/getDomainXML >> >> According to that the cert have plenty of time left. >> >> On the otherhand >> https://xxx/ca/admin/ca/updateDomainXML is givin the the same cert but >> also http 404. >> >> On 02/19/2015 06:22 PM, Martin Kosek wrote: >>> On 02/19/2015 05:14 PM, Dmitri Pal wrote: >>>> On 02/19/2015 10:07 AM, Jani West wrote: >>>>> Trying to migrate from CentOS 6.6 with FreeIPA 3.0.0-42 to CentOS >>>>> 7.0 with >>>>> FreeIPA 3.3.3-28 by using replication. >>>>> >>>>> I have prepared replication file and moved it to the new replica >>>>> server. >>>>> Configured the firewalld and installed Ipa and other needed >>>>> packages via yum. >>>>> >>>>> When running "ipa-replica-install --setup-ca -d" installation will >>>>> always >>>>> stuck on: >>>>> >>>>> ---------------------------------------------------------------------- >>>>> "Configuring certificate server (pki-tomcatd): Estimated time 3 >>>>> minutes 30 >>>>> seconds >>>>> [2/19]: configuring certificate server instance >>>>> ipa : DEBUG Starting external process >>>>> ipa : DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpHJBhR5 >>>>> ipa : DEBUG Process finished, return code=1 >>>>> ipa : DEBUG stdout=Loading deployment configuration from >>>>> /tmp/tmpHJBhR5. >>>>> Installing CA into /var/lib/pki/pki-tomcat. >>>>> Storing deployment configuration into >>>>> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. >>>>> Installation failed. >>>>> >>>>> >>>>> ipa : DEBUG stderr=pkispawn : WARNING ....... unable to >>>>> validate security domain user/password through REST interface. >>>>> Interface not >>>>> available >>>>> pkispawn : ERROR ....... Exception from Java Configuration >>>>> Servlet: >>>>> Error while updating security domain: java.io.IOException: >>>>> java.io.IOException: SocketException cannot read on socket >>>>> >>>>> ipa : CRITICAL failed to configure ca instance Command >>>>> '/usr/sbin/pkispawn -s CA -f /tmp/tmpHJBhR5' returned non-zero exit >>>>> status 1 >>>>> ---------------------------------------------------------------------- >>>>> >>>>> Betwee the attempts I have cleaned yu ipa and pki configurations and >>>>> deleteted the old replication agreement. >>>>> >>>>> >>>>> Apache logs on old CentOS 6 server have these errors. >>>>> ---------------------------------------------------------------------- >>>>> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >>>>> /ca/admin/ca/getDomainXML HTTP/1.0" 200 1158 >>>>> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >>>>> /ca/admin/ca/updateDomainXML HTTP/1.0" 404 - >>>>> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >>>>> /ca/agent/ca/updateDomainXML HTTP/1.0" 403 323 >>>>> [Thu Feb 19 11:38:44 2015] [error] Bad remote server certificate: -8181 >>>>> [Thu Feb 19 11:38:44 2015] [error] SSL Library Error: -8181 >>>>> Certificate has >>>>> expired >>>>> [Thu Feb 19 11:38:44 2015] [error] Re-negotiation handshake failed: Not >>>>> accepted by client!? >>>>> ---------------------------------------------------------------------- >>>>> >>>>> What certificate this means? ca.crt have more than five years left. >>>>> >>>>> Clocks are synced, /ca/admin/ca/updateDomainXML can be found on >>>>> ipa-pki-proxy.conf and there are no obvious reason. Any hints? >>>> >>>> Are CA ports accessible on your master? Can you check your FW please? >>>> >>> >>> This line makes me think that expired certs may be involved: >>> >>> [Thu Feb 19 11:38:44 2015] [error] SSL Library Error: -8181 >>> Certificate has >>> expired >>> >>> CCing JanCh who have the best context in this area. >>> >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project > From dpal at redhat.com Thu Feb 19 23:07:10 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 19 Feb 2015 18:07:10 -0500 Subject: [Freeipa-users] Migration fails from 3.0.0 to 3.3.3 on Centos 6/7 In-Reply-To: References: <54E5FC3D.3070904@iki.fi> <54E60BF5.7@redhat.com> <54E60DB5.7080206@redhat.com> <54E61137.5030906@iki.fi> Message-ID: <54E66C9E.7010105@redhat.com> On 02/19/2015 02:54 PM, Jim Richard wrote: > Hey guys, for what it's worth, I spent a couple weeks working with > Endi Sukma Dewata, edewata at redhat.com , > "Re: [Freeipa-users] Redhat/Centos iDM 3.0 to 3.1 upgrade fail". > > Unfortunately my post subject was not accurate but in fact, I was > attempting the exact same thing and seeing the exact same error. The > main LDAP instance would come up ok but upon attempting to migrate the > PKI stuff with the new ldap schema etc, it just fails... > If you have been gradually upgrading it might very well be that you are hitting some of the earlier bugs related to cert tracking. The page can help you with troubleshooting http://www.freeipa.org/page/Troubleshooting#IPA_won.27t_start.2C_expired_certificates You need to see whether the certs on the master have expired and whether they are now properly tracked. Rob is this the right way of checking the cert validity (see previous mail in the thread)? > > In the end we couldn't figure it out, basically had to just give up. > > Maybe one of you could reach out to Endi and he could share some > insights. > > I'd love to be able to make this work as well but as of now it looks > like my only option if I want to upgrade to version 3.3/Centos 7 is > well, there is no option.... > > I'd be happy to share or help in any way. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jim Richard | PlaceIQ > | > Systems Administrator | jrichard at placeiq.com > | +1 (646) 338-8905 > > > > >> On Feb 19, 2015, at 11:37 AM, Jani West > > wrote: >> >> Hi, >> >> How I can check the cert and test? >> >> I did curl -v -k https://xxx/ca/admin/ca/getDomainXML >> >> According to that the cert have plenty of time left. >> >> On the otherhand >> https://xxx/ca/admin/ca/updateDomainXML is givin the the same cert >> but also http 404. >> >> On 02/19/2015 06:22 PM, Martin Kosek wrote: >>> On 02/19/2015 05:14 PM, Dmitri Pal wrote: >>>> On 02/19/2015 10:07 AM, Jani West wrote: >>>>> Trying to migrate from CentOS 6.6 with FreeIPA 3.0.0-42 to CentOS >>>>> 7.0 with >>>>> FreeIPA 3.3.3-28 by using replication. >>>>> >>>>> I have prepared replication file and moved it to the new replica >>>>> server. >>>>> Configured the firewalld and installed Ipa and other needed >>>>> packages via yum. >>>>> >>>>> When running "ipa-replica-install --setup-ca -d" installation will >>>>> always >>>>> stuck on: >>>>> >>>>> ---------------------------------------------------------------------- >>>>> "Configuring certificate server (pki-tomcatd): Estimated time 3 >>>>> minutes 30 >>>>> seconds >>>>> [2/19]: configuring certificate server instance >>>>> ipa : DEBUG Starting external process >>>>> ipa : DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpHJBhR5 >>>>> ipa : DEBUG Process finished, return code=1 >>>>> ipa : DEBUG stdout=Loading deployment configuration from >>>>> /tmp/tmpHJBhR5. >>>>> Installing CA into /var/lib/pki/pki-tomcat. >>>>> Storing deployment configuration into >>>>> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. >>>>> Installation failed. >>>>> >>>>> >>>>> ipa : DEBUG stderr=pkispawn : WARNING ....... unable to >>>>> validate security domain user/password through REST interface. >>>>> Interface not >>>>> available >>>>> pkispawn : ERROR ....... Exception from Java Configuration >>>>> Servlet: >>>>> Error while updating security domain: java.io.IOException: >>>>> java.io.IOException: SocketException cannot read on socket >>>>> >>>>> ipa : CRITICAL failed to configure ca instance Command >>>>> '/usr/sbin/pkispawn -s CA -f /tmp/tmpHJBhR5' returned non-zero >>>>> exit status 1 >>>>> ---------------------------------------------------------------------- >>>>> >>>>> Betwee the attempts I have cleaned yu ipa and pki configurations and >>>>> deleteted the old replication agreement. >>>>> >>>>> >>>>> Apache logs on old CentOS 6 server have these errors. >>>>> ---------------------------------------------------------------------- >>>>> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >>>>> /ca/admin/ca/getDomainXML HTTP/1.0" 200 1158 >>>>> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >>>>> /ca/admin/ca/updateDomainXML HTTP/1.0" 404 - >>>>> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >>>>> /ca/agent/ca/updateDomainXML HTTP/1.0" 403 323 >>>>> [Thu Feb 19 11:38:44 2015] [error] Bad remote server certificate: >>>>> -8181 >>>>> [Thu Feb 19 11:38:44 2015] [error] SSL Library Error: -8181 >>>>> Certificate has >>>>> expired >>>>> [Thu Feb 19 11:38:44 2015] [error] Re-negotiation handshake >>>>> failed: Not >>>>> accepted by client!? >>>>> ---------------------------------------------------------------------- >>>>> >>>>> What certificate this means? ca.crt have more than five years left. >>>>> >>>>> Clocks are synced, /ca/admin/ca/updateDomainXML can be found on >>>>> ipa-pki-proxy.conf and there are no obvious reason. Any hints? >>>> >>>> Are CA ports accessible on your master? Can you check your FW please? >>>> >>> >>> This line makes me think that expired certs may be involved: >>> >>> [Thu Feb 19 11:38:44 2015] [error] SSL Library Error: -8181 >>> Certificate has >>> expired >>> >>> CCing JanCh who have the best context in this area. >>> >> >> >> -- >> -- Jani West -- jwest at iki.fi -- +358 40 >> 5010914 -- >> -- Liinalahdentie 4 -- 01800 KLAUKKALA -- FINLAND -- >> >> "Haluaisin, ett? Suomi olisi paljon monikulttuurisempi. >> T?nne tulee muualta paljon ihmisi?, mutta heit? ei tuoda >> tarpeeksi esille. Jotenkin me pid?mme heid?t verhojen takana. >> On t?rke??, ett? Suomesta saataisiin avoin ja suvaitsevainen. >> Sulkeutunut ajattelutapa on Suomen ongelma. Ehk? me >> pelk??mme mielenosoituksia, joita esimerkiksi Ruotsin >> l?hi?iss? on ollut ja sit?, ett? jotain kauheaa tapahtuu. >> Ei ymm?rret?, ett? maahanmuuttajat voivat tuoda >> Suomeen my?s paljon hyv??. Toivoisin hallitukselta sit?, >> ett? koko kansaa kuullaan, my?s eri kulttuureista >> tulevia. Hallituksen pit?isi rahoittaa ja tukea enemm?n >> Suomen kansainv?list?mist?. My?s eduskunta voisi kuunnella >> maahanmuuttajia enemm?n." >> >> HS 8.6.2013: Essi, 16 v. Etu-T??l?n lukio. >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project > > > -- 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 Fri Feb 20 00:41:55 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 19 Feb 2015 19:41:55 -0500 Subject: [Freeipa-users] FreeIPA and Application Specific Passwords In-Reply-To: <54E6102D.9010505@redhat.com> References: <54E5290F.8020301@sonic.com> <20150219100658.GA18794@redhat.com> <54E60E06.4000202@redhat.com> <54E60F59.3090304@redhat.com> <54E6102D.9010505@redhat.com> Message-ID: <1424392915.5560.16.camel@willson.usersys.redhat.com> On Thu, 2015-02-19 at 11:32 -0500, Dmitri Pal wrote: > On 02/19/2015 11:29 AM, Martin Kosek wrote: > > On 02/19/2015 05:23 PM, Dmitri Pal wrote: > >> On 02/19/2015 05:06 AM, Jan Pazdziora wrote: > >>> On Wed, Feb 18, 2015 at 04:06:39PM -0800, Martin Minkus wrote: > >>>> Except where we don't want single sign on, and separate passwords are > >>>> advantageous or even required: > >>>> > >>>> - Web logins > >>> Could you elaborate on the use cases when you'd want your users to log > >>> in using their passwords on a Web login, instead of using SSO, be it > >>> Kerberos or SAML? Is that purely the application not supporting it > >>> or are there some other reasons (you say "we don't want single sign > >>> on" which sounds like a political or compliance issue, not technical > >>> one). > >>> > >> IMO the case is: > >> I have a phone and a tablet and a laptop. > >> I do not want to use one password for all three. > >> On the phone and tablet people save their passwords so I do not want to have > >> same password cached on all devices. I want to have a password per device. > >> > >> IMO the way to go is certs rather than passwords. > > Certs would certainly help in this case. However, the UX would need to be > > really good in order to beat saved password in GMail style, IMO. > > I imagine Ipsilon based SSO when Ipsilon can make a decision which > assertions to issue depending on the cert you have. A lot of apps can't do certs. I mentioned to someone (Nathan, did I talk with you ?) a few weeks ago during DevConf.cz an idea I have to actually build application passwords (and more) support. I will try to come up with a design page as soon as I get a moment to put down my tougths coherently. Simo. -- Simo Sorce * Red Hat, Inc * New York From danofsatx at gmail.com Fri Feb 20 01:00:25 2015 From: danofsatx at gmail.com (Dan Mossor) Date: Thu, 19 Feb 2015 19:00:25 -0600 Subject: [Freeipa-users] WebUI authentication problems Message-ID: <54E68729.1050106@fedoraproject.org> I just installed a new server on Fedora 21 Server, using the rolekit deployment tool. Everything was installed and configured (I hope) properly, but I'm running into a problem. The version is freeipa-server-4.1.2-1.fc21.x86_64, and I can connect to the WebUI only after a restart of ipa.service. After approximately 15 minutes, I am kicked out of the active session - while in the middle of using it - and cannot log back in. Login was attempted from 4 browsers across two machines, and every time the login screen returns with "Your session has expired. Please re-login." /var/log/httpd/errors is showing the following: [Fri Feb 20 00:37:03.972736 2015] [auth_kerb:error] [pid 1158] [client 10.1.0.15:54958] gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, ASN.1 structure is missing a required field), referer: https://vader.dom.net/ipa/ui/index.html [Fri Feb 20 00:37:34.300510 2015] [auth_kerb:error] [pid 1173] [client 10.1.0.15:54961] gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, ASN.1 structure is missing a required field), referer: https://vader.dom.net/ipa/ui/index.html [Fri Feb 20 00:37:34.406615 2015] [auth_kerb:error] [pid 1616] [client 10.1.0.15:54965] gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, ASN.1 structure is missing a required field), referer: https://vader.dom.net/ipa/ui/index.html [Fri Feb 20 00:37:50.356014 2015] [auth_kerb:error] [pid 1161] [client 10.1.0.15:54966] gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, ASN.1 structure is missing a required field), referer: https://vader.dom.net/ipa/ui/index.html [Fri Feb 20 00:37:52.263088 2015] [auth_kerb:error] [pid 1417] [client 10.1.0.15:54968] gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, ASN.1 structure is missing a required field), referer: https://vader.dom.net/ipa/ui/index.html [Fri Feb 20 00:37:52.327075 2015] [auth_kerb:error] [pid 1168] [client 10.1.0.15:54967] gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, ASN.1 structure is missing a required field), referer: https://vader.dom.net/ipa/ui/index.html [Fri Feb 20 00:45:35.603016 2015] [auth_kerb:error] [pid 1173] [client 10.1.1.17:54157] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error), referer: https://vader.dom.net/ipa/ui/ Restarting httpd, I can log in, and am immediately logged out again with the above errors. Restarting ipa.service, I was able to log in with my user account, and was notified that my password expires in 0 days - even though it was just created less than an hour ago. Is this a known issue, or is there a hidden problem with the rolekit deployment that I need to track down? -- Dan Mossor, RHCSA Systems Engineer at Large Fedora Plasma Product WG | Fedora QA Team | Fedora Server WG Fedora Infrastructure Apprentice FAS: dmossor IRC: danofsatx San Antonio, Texas, USA From Less at imagine-sw.com Fri Feb 20 05:56:36 2015 From: Less at imagine-sw.com (Les Stott) Date: Fri, 20 Feb 2015 05:56:36 +0000 Subject: [Freeipa-users] ipa-getcert list fails to report correctly Message-ID: <4ED173A868981548967B4FCA27072226280BF4DF@AACMBXP04.exchserver.com> Hi all, The following is blocking the ability for me to install a CA replica. Environment: RHEL 6.6 IPA 3.0.0-42 PKI 9.0.3-38 On the master the following is happening: ipa-getcert list Number of certificates and requests being tracked: 5. (but it shows no certificate details in the output) Running "getcert list" shows complete output. Also, when trying to browse https://master.mydomain.com/ca/ee/ca/getCertChain i get a failed response. The apache error logs on the master show.... [Thu Feb 19 23:23:23 2015] [error] SSL Library Error: -12271 SSL client cannot verify your certificate The reason I am trying to browse that address is because that's what the ipa-ca-install setup is failing at (it complains that the CA certificate is not in proper format, in fact it's not able to get it at all). I know from another working ipa setup that .... Browsing to the above address provides valid xml content and ipa-getcert list shows certificate details and not just the number of tracked certificates. Been trying for a long time to figure out the issues without luck. I would greatly appreciate any help to troubleshoot and resolve the above issues. Regards, Les -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwest at iki.fi Fri Feb 20 08:16:21 2015 From: jwest at iki.fi (West, Jani) Date: Fri, 20 Feb 2015 10:16:21 +0200 Subject: [Freeipa-users] Migration fails from 3.0.0 to 3.3.3 on Centos 6/7 In-Reply-To: <54E66C9E.7010105@redhat.com> References: <54E5FC3D.3070904@iki.fi> " <54E60BF5.7@redhat.com>" <54E60DB5.7080206@redhat.com> <54E61137.5030906@iki.fi> <54E66C9E.7010105@redhat.com> Message-ID: <1d33952d513a47857439feaf0658901a@westi.foo> Hi, Validity, status and serials seems to be fine. One interesting pick: While the installation is not too old it might be installed initially with FreeIpa 2.x That's why i have to use ldap port 7389 instead of 398. # getcert list |grep expires expires: 2016-11-21 13:40:41 UTC expires: 2016-11-21 13:40:44 UTC expires: 2016-11-21 13:40:41 UTC expires: 2016-10-30 09:08:12 UTC expires: 2016-10-30 09:07:12 UTC expires: 2016-10-30 09:07:12 UTC expires: 2016-10-30 09:07:12 UTC expires: 2016-10-30 09:07:12 UTC # getcert list -d /etc/httpd/alias -n ipaCert |egrep -i '(status|expires)' status: MONITORING expires: 2016-10-30 09:07:12 UTC # certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial Serial Number: 31 (0x1f) # ldapsearch -x -h localhost -p 7389 -b uid=ipara,ou=People,o=ipaca description # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: description # # ipara, people, ipaca dn: uid=ipara,ou=people,o=ipaca description: 2;31;CN=Certificate Authority,O=WESTI;CN=IPA RA,O=WESTI # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 -- -- Jani West On 20.2.2015 01:07, Dmitri Pal wrote: > On 02/19/2015 02:54 PM, Jim Richard wrote: > >> Hey guys, for what it's worth, I spent a couple weeks working with >> Endi Sukma Dewata, edewata at redhat.com, "Re: [Freeipa-users] >> Redhat/Centos iDM 3.0 to 3.1 upgrade fail". >> >> Unfortunately my post subject was not accurate but in fact, I was >> attempting the exact same thing and seeing the exact same error. The >> main LDAP instance would come up ok but upon attempting to migrate >> the PKI stuff with the new ldap schema etc, it just fails? > > If you have been gradually upgrading it might very well be that you > are hitting some of the earlier bugs related to cert tracking. > The page can help you with troubleshooting > http://www.freeipa.org/page/Troubleshooting#IPA_won.27t_start.2C_expired_certificates > [4] > You need to see whether the certs on the master have expired and > whether they are now properly tracked. > Rob is this the right way of checking the cert validity (see previous > mail in the thread)? > >> In the end we couldn't figure it out, basically had to just give up. >> >> >> Maybe one of you could reach out to Endi and he could share some >> insights. >> >> I'd love to be able to make this work as well but as of now it looks >> like my only option if I want to upgrade to version 3.3/Centos 7 is >> well, there is no option?. >> >> I'd be happy to share or help in any way. >> >> Jim Richard | PlaceIQ [1] | Systems Administrator | >> jrichard at placeiq.com | +1 (646) 338-8905 >> >> On Feb 19, 2015, at 11:37 AM, Jani West wrote: >> >> Hi, >> >> How I can check the cert and test? >> >> I did curl -v -k https://xxx/ca/admin/ca/getDomainXML [2] >> >> According to that the cert have plenty of time left. >> >> On the otherhand >> https://xxx/ca/admin/ca/updateDomainXML [3] is givin the the same >> cert but also http 404. >> >> On 02/19/2015 06:22 PM, Martin Kosek wrote: >> On 02/19/2015 05:14 PM, Dmitri Pal wrote: >> On 02/19/2015 10:07 AM, Jani West wrote: >> Trying to migrate from CentOS 6.6 with FreeIPA 3.0.0-42 to CentOS >> 7.0 with >> FreeIPA 3.3.3-28 by using replication. >> >> I have prepared replication file and moved it to the new replica >> server. >> Configured the firewalld and installed Ipa and other needed >> packages via yum. >> >> When running "ipa-replica-install --setup-ca -d" installation will >> always >> stuck on: >> >> > ---------------------------------------------------------------------- >> "Configuring certificate server (pki-tomcatd): Estimated time 3 >> minutes 30 >> seconds >> [2/19]: configuring certificate server instance >> ipa : DEBUG Starting external process >> ipa : DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpHJBhR5 >> ipa : DEBUG Process finished, return code=1 >> ipa : DEBUG stdout=Loading deployment configuration from >> /tmp/tmpHJBhR5. >> Installing CA into /var/lib/pki/pki-tomcat. >> Storing deployment configuration into >> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. >> Installation failed. >> >> ipa : DEBUG stderr=pkispawn : WARNING ....... unable to >> validate security domain user/password through REST interface. >> Interface not >> available >> pkispawn : ERROR ....... Exception from Java Configuration Servlet: >> Error while updating security domain: java.io.IOException: >> java.io.IOException: SocketException cannot read on socket >> >> ipa : CRITICAL failed to configure ca instance Command >> '/usr/sbin/pkispawn -s CA -f /tmp/tmpHJBhR5' returned non-zero exit >> status 1 >> > ---------------------------------------------------------------------- >> >> Betwee the attempts I have cleaned yu ipa and pki configurations >> and >> deleteted the old replication agreement. >> >> Apache logs on old CentOS 6 server have these errors. >> > ---------------------------------------------------------------------- >> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >> /ca/admin/ca/getDomainXML HTTP/1.0" 200 1158 >> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >> /ca/admin/ca/updateDomainXML HTTP/1.0" 404 - >> 192.168.177.8 - - [19/Feb/2015:11:38:44 +0200] "POST >> /ca/agent/ca/updateDomainXML HTTP/1.0" 403 323 >> [Thu Feb 19 11:38:44 2015] [error] Bad remote server certificate: >> -8181 >> [Thu Feb 19 11:38:44 2015] [error] SSL Library Error: -8181 >> Certificate has >> expired >> [Thu Feb 19 11:38:44 2015] [error] Re-negotiation handshake failed: >> Not >> accepted by client!? >> > ---------------------------------------------------------------------- >> >> What certificate this means? ca.crt have more than five years left. >> >> Clocks are synced, /ca/admin/ca/updateDomainXML can be found on >> ipa-pki-proxy.conf and there are no obvious reason. Any hints? >> >> Are CA ports accessible on your master? Can you check your FW >> please? > > This line makes me think that expired certs may be involved: > > [Thu Feb 19 11:38:44 2015] [error] SSL Library Error: -8181 > Certificate has > expired > > CCing JanCh who have the best context in this area. > > -- > -- Jani West -- jwest at iki.fi -- +358 40 5010914 -- > -- Liinalahdentie 4 -- 01800 KLAUKKALA -- FINLAND -- > > "Haluaisin, ett? Suomi olisi paljon monikulttuurisempi. > T?nne tulee muualta paljon ihmisi?, mutta heit? ei tuoda > tarpeeksi esille. Jotenkin me pid?mme heid?t verhojen takana. > On t?rke??, ett? Suomesta saataisiin avoin ja suvaitsevainen. > Sulkeutunut ajattelutapa on Suomen ongelma. Ehk? me > pelk??mme mielenosoituksia, joita esimerkiksi Ruotsin > l?hi?iss? on ollut ja sit?, ett? jotain kauheaa tapahtuu. > Ei ymm?rret?, ett? maahanmuuttajat voivat tuoda > Suomeen my?s paljon hyv??. Toivoisin hallitukselta sit?, > ett? koko kansaa kuullaan, my?s eri kulttuureista > tulevia. Hallituksen pit?isi rahoittaa ja tukea enemm?n > Suomen kansainv?list?mist?. My?s eduskunta voisi kuunnella > maahanmuuttajia enemm?n." > > HS 8.6.2013: Essi, 16 v. Etu-T??l?n lukio. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users [5] > Go To http://freeipa.org [6] for more info on the project > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > Links: > ------ > [1] > http://www.google.com/url?q=http%3A%2F%2Fwww.placeiq.com%2F&sa=D&sntz=1&usg=AFrqEzcYjZpDPyqW7feNK9EgLq-c9JlHiw > [2] https://xxx/ca/admin/ca/getDomainXML > [3] https://xxx/ca/admin/ca/updateDomainXML > [4] > http://www.freeipa.org/page/Troubleshooting#IPA_won.27t_start.2C_expired_certificates > [5] https://www.redhat.com/mailman/listinfo/freeipa-users > [6] http://freeipa.org From gjn at gjn.priv.at Fri Feb 20 08:36:17 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Fri, 20 Feb 2015 09:36:17 +0100 Subject: [Freeipa-users] FreeIpa and Dovecot Message-ID: <1654083.WhB8c8qxCE@techz> Hello, have any a functional Link for this Problem. I found nothing that is working correct ? :-(. -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From jpazdziora at redhat.com Fri Feb 20 08:39:27 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 20 Feb 2015 09:39:27 +0100 Subject: [Freeipa-users] FreeIpa and Dovecot In-Reply-To: <1654083.WhB8c8qxCE@techz> References: <1654083.WhB8c8qxCE@techz> Message-ID: <20150220083927.GP31303@redhat.com> On Fri, Feb 20, 2015 at 09:36:17AM +0100, G?nther J. Niederwimmer wrote: > > have any a functional Link for this Problem. Can you elaborate what the problem actually is? Specifically, what setup you try to achieve, how you do it, where it starts to fail. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Fri Feb 20 08:44:26 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Feb 2015 09:44:26 +0100 Subject: [Freeipa-users] WebUI authentication problems In-Reply-To: <54E68729.1050106@fedoraproject.org> References: <54E68729.1050106@fedoraproject.org> Message-ID: <54E6F3EA.8020707@redhat.com> On 02/20/2015 02:00 AM, Dan Mossor wrote: > I just installed a new server on Fedora 21 Server, using the rolekit deployment > tool. Everything was installed and configured (I hope) properly, but I'm > running into a problem. The version is freeipa-server-4.1.2-1.fc21.x86_64, and > I can connect to the WebUI only after a restart of ipa.service. > > After approximately 15 minutes, I am kicked out of the active session - while > in the middle of using it - and cannot log back in. Login was attempted from 4 > browsers across two machines, and every time the login screen returns with > "Your session has expired. Please re-login." > > /var/log/httpd/errors is showing the following: > [Fri Feb 20 00:37:03.972736 2015] [auth_kerb:error] [pid 1158] [client > 10.1.0.15:54958] gss_accept_sec_context() failed: Unspecified GSS failure. > Minor code may provide more information (, ASN.1 structure is missing a > required field), referer: https://vader.dom.net/ipa/ui/index.html > [Fri Feb 20 00:37:34.300510 2015] [auth_kerb:error] [pid 1173] [client > 10.1.0.15:54961] gss_accept_sec_context() failed: Unspecified GSS failure. > Minor code may provide more information (, ASN.1 structure is missing a > required field), referer: https://vader.dom.net/ipa/ui/index.html > [Fri Feb 20 00:37:34.406615 2015] [auth_kerb:error] [pid 1616] [client > 10.1.0.15:54965] gss_accept_sec_context() failed: Unspecified GSS failure. > Minor code may provide more information (, ASN.1 structure is missing a > required field), referer: https://vader.dom.net/ipa/ui/index.html > [Fri Feb 20 00:37:50.356014 2015] [auth_kerb:error] [pid 1161] [client > 10.1.0.15:54966] gss_accept_sec_context() failed: Unspecified GSS failure. > Minor code may provide more information (, ASN.1 structure is missing a > required field), referer: https://vader.dom.net/ipa/ui/index.html > [Fri Feb 20 00:37:52.263088 2015] [auth_kerb:error] [pid 1417] [client > 10.1.0.15:54968] gss_accept_sec_context() failed: Unspecified GSS failure. > Minor code may provide more information (, ASN.1 structure is missing a > required field), referer: https://vader.dom.net/ipa/ui/index.html > [Fri Feb 20 00:37:52.327075 2015] [auth_kerb:error] [pid 1168] [client > 10.1.0.15:54967] gss_accept_sec_context() failed: Unspecified GSS failure. > Minor code may provide more information (, ASN.1 structure is missing a > required field), referer: https://vader.dom.net/ipa/ui/index.html > [Fri Feb 20 00:45:35.603016 2015] [auth_kerb:error] [pid 1173] [client > 10.1.1.17:54157] gss_accept_sec_context() failed: An unsupported mechanism was > requested (, Unknown error), referer: https://vader.dom.net/ipa/ui/ > > Restarting httpd, I can log in, and am immediately logged out again with the > above errors. > > Restarting ipa.service, I was able to log in with my user account, and was > notified that my password expires in 0 days - even though it was just created > less than an hour ago. > > Is this a known issue, or is there a hidden problem with the rolekit deployment > that I need to track down? CCing Petr for Web UI and Simo for the Kerberos part. We know about several common gotchas related to Web UI auth, having them documented on http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI But this seems as a new case. You can still check the pointers on this page though. If none of them help, it may help to show us: - the Kerberos ticket and default encryptions: $ kinit $ klist -e - any related Kerberos errors from /var/log/krb5kdc.log Martin From mkosek at redhat.com Fri Feb 20 08:51:15 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Feb 2015 09:51:15 +0100 Subject: [Freeipa-users] ipa-getcert list fails to report correctly In-Reply-To: <4ED173A868981548967B4FCA27072226280BF4DF@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA27072226280BF4DF@AACMBXP04.exchserver.com> Message-ID: <54E6F583.2030603@redhat.com> On 02/20/2015 06:56 AM, Les Stott wrote: > Hi all, > > The following is blocking the ability for me to install a CA replica. > > Environment: > > RHEL 6.6 > > IPA 3.0.0-42 > > PKI 9.0.3-38 > > On the master the following is happening: > > ipa-getcert list > > Number of certificates and requests being tracked: 5. > > (but it shows no certificate details in the output) > > Running ?getcert list? shows complete output. > > Also, when trying to browse https://master.mydomain.com/ca/ee/ca/getCertChain i > get a failed response. The apache error logs on the master show?. > > [Thu Feb 19 23:23:23 2015] [error] SSL Library Error: -12271 SSL client cannot > verify your certificate > > The reason I am trying to browse that address is because that?s what the > ipa-ca-install setup is failing at (it complains that the CA certificate is not > in proper format, in fact it?s not able to get it at all). > > I know from another working ipa setup that ?. > > Browsing to the above address provides valid xml content and ipa-getcert list > shows certificate details and not just the number of tracked certificates. > > Been trying for a long time to figure out the issues without luck. > > I would greatly appreciate any help to troubleshoot and resolve the above issues. > > Regards, > > Les Endi or JanC, would you have any advise for Les? To me, it looks like the Apache does not have proper certificate installed. My ipa-getcert on RHEL-6.6 shows 3 Server-Certs tracked, making it in total of 8 certs tracked: # ipa-getcert list Number of certificates and requests being tracked: 8. Request ID '20141111000002': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:00:01 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20141111000047': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:00:46 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20141111000302': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:03:02 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes What is actually in your Apache NSS database? # certutil -L -d /etc/httpd/alias/ Martin From mkosek at redhat.com Fri Feb 20 08:53:31 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Feb 2015 09:53:31 +0100 Subject: [Freeipa-users] FreeIpa and Dovecot In-Reply-To: <1654083.WhB8c8qxCE@techz> References: <1654083.WhB8c8qxCE@techz> Message-ID: <54E6F60B.9040706@redhat.com> On 02/20/2015 09:36 AM, G?nther J. Niederwimmer wrote: > Hello, > > have any a functional Link for this Problem. > > I found nothing that is working correct ? :-(. I only know about Dovecot HOWTOs on http://www.freeipa.org/page/HowTos#Mail_Services If there is a problem with the instructions and you would be able to find out what is actually wrong (we can help if you give us specific problems you have), it would be nice to help us and fix the HOWTO. From pvoborni at redhat.com Fri Feb 20 09:53:28 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 20 Feb 2015 10:53:28 +0100 Subject: [Freeipa-users] WebUI authentication problems In-Reply-To: <54E6F3EA.8020707@redhat.com> References: <54E68729.1050106@fedoraproject.org> <54E6F3EA.8020707@redhat.com> Message-ID: <54E70418.5050700@redhat.com> On 02/20/2015 09:44 AM, Martin Kosek wrote: > On 02/20/2015 02:00 AM, Dan Mossor wrote: >> I just installed a new server on Fedora 21 Server, using the rolekit >> deployment >> tool. Everything was installed and configured (I hope) properly, but I'm >> running into a problem. The version is >> freeipa-server-4.1.2-1.fc21.x86_64, and >> I can connect to the WebUI only after a restart of ipa.service. >> >> After approximately 15 minutes, I am kicked out of the active session >> - while >> in the middle of using it - and cannot log back in. Default FreeIPA session lifetime is 20mins. Expiration time is extended on each request. Session also expires when krb ticket expires. We have known issue that Web UI, if SSO is used, does not work if ticket expires in 5mins but it produces little bit different output. >> Login was >> attempted from 4 >> browsers across two machines, and every time the login screen returns >> with >> "Your session has expired. Please re-login." Does it work if you use forms-based authentication or if you use CLI tool? >> >> /var/log/httpd/errors is showing the following: >> [Fri Feb 20 00:37:03.972736 2015] [auth_kerb:error] [pid 1158] [client >> 10.1.0.15:54958] gss_accept_sec_context() failed: Unspecified GSS >> failure. >> Minor code may provide more information (, ASN.1 structure is missing a >> required field), referer: https://vader.dom.net/ipa/ui/index.html >> [Fri Feb 20 00:37:34.300510 2015] [auth_kerb:error] [pid 1173] [client >> 10.1.0.15:54961] gss_accept_sec_context() failed: Unspecified GSS >> failure. >> Minor code may provide more information (, ASN.1 structure is missing a >> required field), referer: https://vader.dom.net/ipa/ui/index.html >> [Fri Feb 20 00:37:34.406615 2015] [auth_kerb:error] [pid 1616] [client >> 10.1.0.15:54965] gss_accept_sec_context() failed: Unspecified GSS >> failure. >> Minor code may provide more information (, ASN.1 structure is missing a >> required field), referer: https://vader.dom.net/ipa/ui/index.html >> [Fri Feb 20 00:37:50.356014 2015] [auth_kerb:error] [pid 1161] [client >> 10.1.0.15:54966] gss_accept_sec_context() failed: Unspecified GSS >> failure. >> Minor code may provide more information (, ASN.1 structure is missing a >> required field), referer: https://vader.dom.net/ipa/ui/index.html >> [Fri Feb 20 00:37:52.263088 2015] [auth_kerb:error] [pid 1417] [client >> 10.1.0.15:54968] gss_accept_sec_context() failed: Unspecified GSS >> failure. >> Minor code may provide more information (, ASN.1 structure is missing a >> required field), referer: https://vader.dom.net/ipa/ui/index.html >> [Fri Feb 20 00:37:52.327075 2015] [auth_kerb:error] [pid 1168] [client >> 10.1.0.15:54967] gss_accept_sec_context() failed: Unspecified GSS >> failure. >> Minor code may provide more information (, ASN.1 structure is missing a >> required field), referer: https://vader.dom.net/ipa/ui/index.html >> [Fri Feb 20 00:45:35.603016 2015] [auth_kerb:error] [pid 1173] [client >> 10.1.1.17:54157] gss_accept_sec_context() failed: An unsupported >> mechanism was >> requested (, Unknown error), referer: https://vader.dom.net/ipa/ui/ This looks like a culprit to me, though IDK what's its cause. Simo may know more. In a meantime you could try to enable debugging to get more info from /var/log/httpd/error_log by creating /etc/ipa/server.conf and restarting httpd. # cat /etc/ipa/server.conf [global] debug=True You could also open browser develeper tools (press F12) and inspect XHR communication in network tab [1]. Check especially if some request to /ipa/session/json or ipa/session/login_kerberos or ipa/session/login_password does not end with 401 Unauthorized status code. And then what's the cause of next 401 after series of 200. It might contain some pointers. Like session expiration time and such. [1] https://pvoborni.fedorapeople.org/images/ff-dev-tools-xhr.png >> >> Restarting httpd, I can log in, and am immediately logged out again >> with the >> above errors. >> >> Restarting ipa.service, I was able to log in with my user account, and >> was >> notified that my password expires in 0 days - even though it was just >> created >> less than an hour ago. Have you modified Kerberos Ticket Policy or any Password Policy? >> >> Is this a known issue, or is there a hidden problem with the rolekit >> deployment >> that I need to track down? It's not a known issue. > > CCing Petr for Web UI and Simo for the Kerberos part. We know about > several common gotchas related to Web UI auth, having them documented on > http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI > > But this seems as a new case. You can still check the pointers on this > page though. If none of them help, it may help to show us: > > - the Kerberos ticket and default encryptions: > $ kinit > $ klist -e > > - any related Kerberos errors from /var/log/krb5kdc.log > > Martin -- Petr Vobornik From gianluca.cecchi at gmail.com Fri Feb 20 10:44:41 2015 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Fri, 20 Feb 2015 11:44:41 +0100 Subject: [Freeipa-users] WebUI authentication problems In-Reply-To: <54E70418.5050700@redhat.com> References: <54E68729.1050106@fedoraproject.org> <54E6F3EA.8020707@redhat.com> <54E70418.5050700@redhat.com> Message-ID: On Fri, Feb 20, 2015 at 10:53 AM, Petr Vobornik wrote: > On 02/20/2015 09:44 AM, Martin Kosek wrote: > >> On 02/20/2015 02:00 AM, Dan Mossor wrote: >> >>> I just installed a new server on Fedora 21 Server, using the rolekit >>> deployment >>> tool. Everything was installed and configured (I hope) properly, but I'm >>> running into a problem. The version is >>> freeipa-server-4.1.2-1.fc21.x86_64, and >>> I can connect to the WebUI only after a restart of ipa.service. >>> >> Hello I actually have quite similar problems in CentOS 7 too, with ipa-server-3.3.3-28.0.1.el7.centos.3.x86_64 and related packages SO the same behavior that if I restart ipa service I'm able to connect (thanks btw, I didn't realize that, having big problems using the WebUI) and that my errors are of this type [Fri Feb 20 10:32:15.850834 2015] [auth_kerb:error] [pid 2029] [client 192.168.1.128:50147] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error), referer: https://c7server.localdomain.local/ipa/ui/ [Fri Feb 20 10:32:22.670791 2015] [auth_kerb:error] [pid 15793] [client 192.168.1.128:50150] krb5_get_init_creds_password() failed: Decrypt integrity check failed, referer: https://c7server.localdomain.local/ipa/ui/ This happens both from an external browser (I enabled form authentication) and from a firefox session launched from the ipa server itself after configuring it for kerberos. I don't want to mess with this thread so let me know if I have to open a dedicated thread specifying for example CentOS 7 or you think it is ok to get in here... so that I paste here other relevant info. Thanks in advance Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Fri Feb 20 14:04:23 2015 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 20 Feb 2015 09:04:23 -0500 Subject: [Freeipa-users] WebUI authentication problems In-Reply-To: References: <54E68729.1050106@fedoraproject.org> <54E6F3EA.8020707@redhat.com> <54E70418.5050700@redhat.com> Message-ID: <1424441063.5560.25.camel@willson.usersys.redhat.com> On Fri, 2015-02-20 at 11:44 +0100, Gianluca Cecchi wrote: > On Fri, Feb 20, 2015 at 10:53 AM, Petr Vobornik wrote: > > > On 02/20/2015 09:44 AM, Martin Kosek wrote: > > > >> On 02/20/2015 02:00 AM, Dan Mossor wrote: > >> > >>> I just installed a new server on Fedora 21 Server, using the rolekit > >>> deployment > >>> tool. Everything was installed and configured (I hope) properly, but I'm > >>> running into a problem. The version is > >>> freeipa-server-4.1.2-1.fc21.x86_64, and > >>> I can connect to the WebUI only after a restart of ipa.service. > >>> > >> > Hello > I actually have quite similar problems in CentOS 7 too, > with ipa-server-3.3.3-28.0.1.el7.centos.3.x86_64 and related packages > SO the same behavior that if I restart ipa service I'm able to connect > (thanks btw, I didn't realize that, having big problems using the WebUI) > and that my errors are of this type > > [Fri Feb 20 10:32:15.850834 2015] [auth_kerb:error] [pid 2029] [client > 192.168.1.128:50147] gss_accept_sec_context() failed: An unsupported > mechanism was requested (, Unknown error), referer: > https://c7server.localdomain.local/ipa/ui/ > [Fri Feb 20 10:32:22.670791 2015] [auth_kerb:error] [pid 15793] [client > 192.168.1.128:50150] krb5_get_init_creds_password() failed: Decrypt > integrity check failed, referer: https://c7server.localdomain.local/ipa/ui/ > > This happens both from an external browser (I enabled form authentication) > and from a firefox session launched from the ipa server itself after > configuring it for kerberos. > > I don't want to mess with this thread so let me know if I have to open a > dedicated thread specifying for example CentOS 7 or you think it is ok to > get in here... so that I paste here other relevant info. This is a completely different problem, it just means you do not have appropriate tickets in your browser, which then probably prroceeds trying to use the IAKERB mechanism, and fails. Simo. From ssorce at redhat.com Fri Feb 20 14:06:09 2015 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 20 Feb 2015 09:06:09 -0500 Subject: [Freeipa-users] WebUI authentication problems In-Reply-To: <54E70418.5050700@redhat.com> References: <54E68729.1050106@fedoraproject.org> <54E6F3EA.8020707@redhat.com> <54E70418.5050700@redhat.com> Message-ID: <1424441169.5560.26.camel@willson.usersys.redhat.com> On Fri, 2015-02-20 at 10:53 +0100, Petr Vobornik wrote: > >> [Fri Feb 20 00:45:35.603016 2015] [auth_kerb:error] [pid 1173] > [client > >> 10.1.1.17:54157] gss_accept_sec_context() failed: An unsupported > >> mechanism was > >> requested (, Unknown error), referer: https://vader.dom.net/ipa/ui/ > > This looks like a culprit to me, though IDK what's its cause. Simo > may > know more. I do not know the cause of the above error, investigating. Simo. From rcritten at redhat.com Fri Feb 20 14:39:03 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Feb 2015 09:39:03 -0500 Subject: [Freeipa-users] ipa-getcert list fails to report correctly In-Reply-To: <54E6F583.2030603@redhat.com> References: <4ED173A868981548967B4FCA27072226280BF4DF@AACMBXP04.exchserver.com> <54E6F583.2030603@redhat.com> Message-ID: <54E74707.5040006@redhat.com> Martin Kosek wrote: > On 02/20/2015 06:56 AM, Les Stott wrote: >> Hi all, >> >> The following is blocking the ability for me to install a CA replica. >> >> Environment: >> >> RHEL 6.6 >> >> IPA 3.0.0-42 >> >> PKI 9.0.3-38 >> >> On the master the following is happening: >> >> ipa-getcert list >> >> Number of certificates and requests being tracked: 5. >> >> (but it shows no certificate details in the output) >> >> Running ?getcert list? shows complete output. >> >> Also, when trying to browse >> https://master.mydomain.com/ca/ee/ca/getCertChain i >> get a failed response. The apache error logs on the master show?. >> >> [Thu Feb 19 23:23:23 2015] [error] SSL Library Error: -12271 SSL >> client cannot >> verify your certificate >> >> The reason I am trying to browse that address is because that?s what the >> ipa-ca-install setup is failing at (it complains that the CA >> certificate is not >> in proper format, in fact it?s not able to get it at all). >> >> I know from another working ipa setup that ?. >> >> Browsing to the above address provides valid xml content and >> ipa-getcert list >> shows certificate details and not just the number of tracked >> certificates. >> >> Been trying for a long time to figure out the issues without luck. >> >> I would greatly appreciate any help to troubleshoot and resolve the >> above issues. >> >> Regards, >> >> Les > > Endi or JanC, would you have any advise for Les? To me, it looks like > the Apache does not have proper certificate installed. > > My ipa-getcert on RHEL-6.6 shows 3 Server-Certs tracked, making it in > total of 8 certs tracked: > > # ipa-getcert list > Number of certificates and requests being tracked: 8. > Request ID '20141111000002': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM',nickname='Server-Cert',token='NSS > Certificate > DB',pinfile='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=vm-086.example.com,O=EXAMPLE.COM > expires: 2016-11-11 00:00:01 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > Request ID '20141111000047': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=vm-086.example.com,O=EXAMPLE.COM > expires: 2016-11-11 00:00:46 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > Request ID '20141111000302': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=vm-086.example.com,O=EXAMPLE.COM > expires: 2016-11-11 00:03:02 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > > > What is actually in your Apache NSS database? > > # certutil -L -d /etc/httpd/alias/ > > Martin > Remember ipa-getcert is just a shortcut for certificates using the certmonger CA named IPA, so it's more a filter than anything else. I don't know why it wouldn't display any output but I'd file a bug. I think we'd need to see the getcert list output to try to figure out what is going on. As for the SSL error fetching the cert chain I think Martin may be onto something. The request is proxied through Apache. I think the client here might be the Apache proxy client. I believe this command replicates what Apache is doing, you might give it a try on the master. This will get the chain directly from dogtag, bypassing Apache: $ curl -v --cacert /etc/ipa/ca.crt https://`hostname`:9444/ca/ee/ca/getCertChain rob From danofsatx at gmail.com Fri Feb 20 15:00:08 2015 From: danofsatx at gmail.com (Dan Mossor) Date: Fri, 20 Feb 2015 09:00:08 -0600 Subject: [Freeipa-users] WebUI authentication problems In-Reply-To: <54E70418.5050700@redhat.com> References: <54E68729.1050106@fedoraproject.org> <54E6F3EA.8020707@redhat.com> <54E70418.5050700@redhat.com> Message-ID: <54E74BF8.6010809@fedoraproject.org> On 02/20/2015 03:53 AM, Petr Vobornik wrote: > On 02/20/2015 09:44 AM, Martin Kosek wrote: >> On 02/20/2015 02:00 AM, Dan Mossor wrote: <---snip---> >>> After approximately 15 minutes, I am kicked out of the active session >>> - while >>> in the middle of using it - and cannot log back in. > > Default FreeIPA session lifetime is 20mins. Expiration time is extended > on each request. Session also expires when krb ticket expires. We have > known issue that Web UI, if SSO is used, does not work if ticket expires > in 5mins but it produces little bit different output. > So, the oddity continues. Firefox was at fault here - once I cleaned up FF and configured it with the new certificate, these authentication problems cleared up. >>> Login was >>> attempted from 4 >>> browsers across two machines, and every time the login screen returns >>> with >>> "Your session has expired. Please re-login." > > Does it work if you use forms-based authentication or if you use CLI tool? > When I attempted to go to use the form based authentication from both Firefox and Chrome, it brought up the page to configure the browser - it did not present me with a login. <----snip----> >>> [Fri Feb 20 00:45:35.603016 2015] [auth_kerb:error] [pid 1173] [client >>> 10.1.1.17:54157] gss_accept_sec_context() failed: An unsupported >>> mechanism was >>> requested (, Unknown error), referer: https://vader.dom.net/ipa/ui/ > > This looks like a culprit to me, though IDK what's its cause. Simo may > know more. > > In a meantime you could try to enable debugging to get more info from > /var/log/httpd/error_log by creating /etc/ipa/server.conf and restarting > httpd. > > # cat /etc/ipa/server.conf > [global] > debug=True > > You could also open browser develeper tools (press F12) and inspect XHR > communication in network tab [1]. Check especially if some request to > /ipa/session/json or ipa/session/login_kerberos or > ipa/session/login_password does not end with 401 Unauthorized status > code. And then what's the cause of next 401 after series of 200. It > might contain some pointers. Like session expiration time and such. > > [1] https://pvoborni.fedorapeople.org/images/ff-dev-tools-xhr.png > I was looking at the console last night, and unfortunately I didn't save any of the error messages displayed. I can't recall the exact wording, but the one clue I was able to get from the Firefox console was that the certificate wasn't trusted - it said it was because it was expired, but it was actually due to my not having granted the exception to the self-signed cert yet. I was unable to do this due to the Firefox glitches mentioned previously. >>> >>> Restarting httpd, I can log in, and am immediately logged out again >>> with the >>> above errors. >>> >>> Restarting ipa.service, I was able to log in with my user account, and >>> was >>> notified that my password expires in 0 days - even though it was just >>> created >>> less than an hour ago. > > Have you modified Kerberos Ticket Policy or any Password Policy? > No, it was a default rolekit deployment - the only thing in my settings.json file was the admin password. >>> >>> Is this a known issue, or is there a hidden problem with the rolekit >>> deployment >>> that I need to track down? > > It's not a known issue. > >> >> CCing Petr for Web UI and Simo for the Kerberos part. We know about >> several common gotchas related to Web UI auth, having them documented on >> http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI >> >> But this seems as a new case. You can still check the pointers on this >> page though. If none of them help, it may help to show us: >> >> - the Kerberos ticket and default encryptions: >> $ kinit >> $ klist -e >> >> - any related Kerberos errors from /var/log/krb5kdc.log >> >> Martin After much deliberation and many reboots, I finally figured out one key issue - I was using a Fedora 21 Cloud image to deploy, and converting the Cloud product to the Server product after the instance was created. For some reason, my original step of issuing 'systemctl disable cloud-init.service', while returning a successful message, was undone on the next reboot. The cloud-init tools were resetting the hostname on every boot to freeipa.localdomain, as that was what was used in the seed. This was causing pkinit to fail, so nothing would authenticate. The cloud-init services are all removed now, and the system is stable. I sent this original message out of frustration because I was stymied at the problem. I eventually figured it out, and apologize for not following up when I figured out the errors were all mine. Thank you all for the pointers, the help y'all dish out here on the list is phenomenal. Regards, Dan -- Dan Mossor, RHCSA Systems Engineer at Large Fedora Plasma Product WG | Fedora QA Team | Fedora Server WG Fedora Infrastructure Apprentice FAS: dmossor IRC: danofsatx San Antonio, Texas, USA From martin.minkus at sonic.com Fri Feb 20 17:41:03 2015 From: martin.minkus at sonic.com (Martin Minkus) Date: Fri, 20 Feb 2015 09:41:03 -0800 Subject: [Freeipa-users] FreeIPA and Application Specific Passwords In-Reply-To: <20150219100658.GA18794@redhat.com> References: <54E5290F.8020301@sonic.com> <20150219100658.GA18794@redhat.com> Message-ID: <54E771AF.9090803@sonic.com> On 19/02/15 02:06, Jan Pazdziora wrote: > On Wed, Feb 18, 2015 at 04:06:39PM -0800, Martin Minkus wrote: >> >> Except where we don't want single sign on, and separate passwords are >> advantageous or even required: >> >> - Web logins > > Could you elaborate on the use cases when you'd want your users to log > in using their passwords on a Web login, instead of using SSO, be it > Kerberos or SAML? Is that purely the application not supporting it > or are there some other reasons (you say "we don't want single sign > on" which sounds like a political or compliance issue, not technical > one). Hi, thanks for your response. It seems to be related to a compliance issue. We need to be pci compliant as some of our systems handle credit card data. We already use two factor auth for vpn's using Duo but it seems management would like to store vpn passwords in our FreeIPA directory but have it be a separate and different password to the usual login password. Anyway, I guess we will figure out a technical solution that works for us. Thanks, Martin. From thomas.raehalme at codecenter.fi Sat Feb 21 13:05:08 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Sat, 21 Feb 2015 15:05:08 +0200 Subject: [Freeipa-users] Identifying current CA master Message-ID: Hi! I am in the process of migrating FreeIPA master to another server following the instructions on page http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master. In the instructions 'post-save command' should have one of two given values, but when I execute the script on the current IPA master there is no value at all: # getcert list -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca" | grep post-save post-save command: Is this a problem? We are using ipa-server-3.0.0-42 on CentOS 6.6. According to yum the original version which we installed is ipa-server-3.0.0-26. Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjn at gjn.priv.at Sun Feb 22 21:19:32 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Sun, 22 Feb 2015 22:19:32 +0100 Subject: [Freeipa-users] Centos 7 No permission to /home/.. Message-ID: <3639142.SAz7JWVjyl@techz> Hello, I have installed centos 7 and a ipa-server on a other system a second ipa- server. But I can't create a user home directory, not on the server and not on a ipa- client with autocreate ? Have any a hint on witch place I can search for this problem ? sssd ipa-server / client .... When you like info please tell me what? -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From Less at imagine-sw.com Mon Feb 23 01:18:28 2015 From: Less at imagine-sw.com (Les Stott) Date: Mon, 23 Feb 2015 01:18:28 +0000 Subject: [Freeipa-users] ipa-getcert list fails to report correctly In-Reply-To: <54E74707.5040006@redhat.com> References: <4ED173A868981548967B4FCA27072226280BF4DF@AACMBXP04.exchserver.com> <54E6F583.2030603@redhat.com> <54E74707.5040006@redhat.com> Message-ID: <4ED173A868981548967B4FCA27072226280C1C78@AACMBXP04.exchserver.com> > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Saturday, 21 February 2015 1:39 AM > To: Martin Kosek; Les Stott; freeipa-users at redhat.com; Endi Dewata; Jan > Cholasta > Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly > > Martin Kosek wrote: > > On 02/20/2015 06:56 AM, Les Stott wrote: > >> Hi all, > >> > >> The following is blocking the ability for me to install a CA replica. > >> > >> Environment: > >> > >> RHEL 6.6 > >> > >> IPA 3.0.0-42 > >> > >> PKI 9.0.3-38 > >> > >> On the master the following is happening: > >> > >> ipa-getcert list > >> > >> Number of certificates and requests being tracked: 5. > >> > >> (but it shows no certificate details in the output) > >> > >> Running "getcert list" shows complete output. > >> > >> Also, when trying to browse > >> https://master.mydomain.com/ca/ee/ca/getCertChain i get a failed > >> response. The apache error logs on the master show.... > >> > >> [Thu Feb 19 23:23:23 2015] [error] SSL Library Error: -12271 SSL > >> client cannot verify your certificate > >> > >> The reason I am trying to browse that address is because that's what > >> the ipa-ca-install setup is failing at (it complains that the CA > >> certificate is not in proper format, in fact it's not able to get it > >> at all). > >> > >> I know from another working ipa setup that .... > >> > >> Browsing to the above address provides valid xml content and > >> ipa-getcert list shows certificate details and not just the number of > >> tracked certificates. > >> > >> Been trying for a long time to figure out the issues without luck. > >> > >> I would greatly appreciate any help to troubleshoot and resolve the > >> above issues. > >> > >> Regards, > >> > >> Les > > > > Endi or JanC, would you have any advise for Les? To me, it looks like > > the Apache does not have proper certificate installed. > > > > My ipa-getcert on RHEL-6.6 shows 3 Server-Certs tracked, making it in > > total of 8 certs tracked: > > > > # ipa-getcert list > > Number of certificates and requests being tracked: 8. > > Request ID '20141111000002': > > status: MONITORING > > stuck: no > > key pair storage: > > type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- > COM',nicknam > > e='Server-Cert',token='NSS > > Certificate > > DB',pinfile='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/pwdfile.txt' > > certificate: > > type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- > COM',nicknam > > e='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=EXAMPLE.COM > > subject: CN=vm-086.example.com,O=EXAMPLE.COM > > expires: 2016-11-11 00:00:01 UTC > > key usage: > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > eku: id-kp-serverAuth,id-kp-clientAuth > > pre-save command: > > post-save command: > > track: yes > > auto-renew: yes > > Request ID '20141111000047': > > status: MONITORING > > stuck: no > > key pair storage: > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' > > ,token='NSS Certificate > > DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' > > certificate: > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' > > ,token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=EXAMPLE.COM > > subject: CN=vm-086.example.com,O=EXAMPLE.COM > > expires: 2016-11-11 00:00:46 UTC > > key usage: > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > eku: id-kp-serverAuth,id-kp-clientAuth > > pre-save command: > > post-save command: > > track: yes > > auto-renew: yes > > Request ID '20141111000302': > > status: MONITORING > > stuck: no > > key pair storage: > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='N > > SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > certificate: > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='N > > SS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=EXAMPLE.COM > > subject: CN=vm-086.example.com,O=EXAMPLE.COM > > expires: 2016-11-11 00:03:02 UTC > > key usage: > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > eku: id-kp-serverAuth,id-kp-clientAuth > > pre-save command: > > post-save command: > > track: yes > > auto-renew: yes > > > > > > What is actually in your Apache NSS database? > > > > # certutil -L -d /etc/httpd/alias/ > > > > Martin > > > > Remember ipa-getcert is just a shortcut for certificates using the certmonger > CA named IPA, so it's more a filter than anything else. I don't know why it > wouldn't display any output but I'd file a bug. > > I think we'd need to see the getcert list output to try to figure out what is > going on. > > As for the SSL error fetching the cert chain I think Martin may be onto > something. The request is proxied through Apache. I think the client here > might be the Apache proxy client. > > I believe this command replicates what Apache is doing, you might give it a > try on the master. This will get the chain directly from dogtag, bypassing > Apache: > > $ curl -v --cacert /etc/ipa/ca.crt > https://`hostname`:9444/ca/ee/ca/getCertChain > > rob Certutil shows.... certutil -L -d /etc/httpd/alias/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI MYDOMAIN.COM IPA CA CT,C,C ipaCert u,u,u Signing-Cert u,u,u Server-Cert u,u,u curl -v --cacert /etc/ipa/ca.crt https://`hostname`:9444/ca/ee/ca/getCertChain * About to connect() to `hostname` port 9444 (#0) * Trying 192.168.1.1... connected * Connected to `hostname` (192.168.1.1) port 9444 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/ipa/ca.crt CApath: none * SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA * Server certificate: * subject: CN=`hostname`,O=MYDOMAIN.COM * start date: Dec 13 01:21:30 2013 GMT * expire date: Dec 03 01:21:30 2015 GMT * common name: `hostname` * issuer: CN=Certificate Authority,O=MYDOMAIN.COM > GET /ca/ee/ca/getCertChain HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > Host: `hostname`:9444 > Accept: */* > < HTTP/1.1 200 OK < Server: Apache-Coyote/1.1 < Content-Type: application/xml < Content-Length: 1434 < Date: Mon, 23 Feb 2015 01:04:29 GMT < 0MIIDzwYJKoZIhvcNAQcCoIIDwDCCA7wCAQExADAPBgkqhkiG9w0BBwGgAgQAoIIDoDCCA5wwggKEoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwOjEYMBYGA1UEChMPREVSSVZBVElWRVMuQ09NMR4wHAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTMxMjEzMDEyMTI5WhcNMzMxMjEzMDEyMTI5WjA6MRgwFgYDVQQKEw9ERVJJVkFUSVZFUy5DT00xHjAcBgNVBAMTFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAA8EaYhmpjSA8o3/1kB/W1+0K6+FrwCS+njOgRtXhiTdmtSddXSDVxHOafFwqN26BR+QRPZbbpJY70gP3SG8W+J6+c37PMVNshWz6UfChGt6ubgFxlSTGUUre2Osr9I4C836MXpGJvRx2VDEuMUxv8j7B9iDRnTDglseqPqrMct2No4wk4cLtA9puBJb0Es76SOHP9edXlf6GBnuYwR8YMc1yJLqpP8IGpHhEkVxMsRpqkEpuuRwEFa7uBcTDhqVV24BpFlseZVubpiOdEgfb3IRBTjvI1Mum9OCJbuj9P/WmqMnrA0sQsmF/R3WBwFdMAsN3+bQCRw73+rwoeDNcCAwEAAaOBrDCBqTAfBgNVHSMEGDAWgBSO8J+j2jAuyg3a0yE+3oVCQJCWUTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBxjAdBgNVHQ4EFgQUjvCfo9owLsoN2tMhPt6FQkCQllEwRgYIKwYBBQUHAQEEOjA4MDYGCCsGAQUFBzABhipodHRwOi8vc2IybW9uMDEuZGVyaXZhdGl2ZXMuY29tOjgwL2* Connection #0 to host `hostname` left intact * Closing connection #0 NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAKH8YkoTAzX2xNYMkZSDK84EK3e4FUixdXxc/EC5ehjrtaqXT1KT9Fl9DAF5/jYNKqgmEmtHnPGlfQ7/Y1ESdhEGcBZjU4qLe4HaFXuw5c9odDYxhtjQUd1g7ifY8SKOcHDCY+6Xx6F/rhFgzrXXMndn8ZaYryctPoOAj/5INnLrJq8S4XyLmb2BHM4e1ORQbOhDi8xjhfK2veYXvIu55BrhpRSS/goz5oSE8e+QE/H9afRmeV2+WkS/YDhSyoUDb7CYjklRuONzX3GopKtp1yyLXQZnBFjCvIJvja0mo3ik3AXxSZuOwUIlV23U8CyPU/rDeiV00iUyA/fLvdkEtZkxAA== In any event, I've decided to rebuilt my DR IPA environment. Late last year the master in DR had to be rebuilt due to a disk issue. While IPA was restored manually and appeared to be working fine, CA replication hasn't worked. I finally got CA replication working in Prod after enabling needed apache modules and performing a yum update to update related packages, but these things didn't help in DR. It's my strong suspicion that something got missed when restoring the DR master IPA server and this is what is causing all my grief. Therefore, I'm going to wipe it out and start from scratch in DR. There are other benefits for me to do this anyway. Regards, Les From mkosek at redhat.com Mon Feb 23 08:29:33 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Feb 2015 09:29:33 +0100 Subject: [Freeipa-users] Identifying current CA master In-Reply-To: References: Message-ID: <54EAE4ED.9030700@redhat.com> On 02/21/2015 02:05 PM, Thomas Raehalme wrote: > Hi! > > I am in the process of migrating FreeIPA master to another server following > the instructions on page > http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master. > > In the instructions 'post-save command' should have one of two given > values, but when I execute the script on the current IPA master there is no > value at all: > > # getcert list -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca" | > grep post-save > post-save command: > > Is this a problem? Good question. You are most likely hitting bug https://bugzilla.redhat.com/show_bug.cgi?id=1178190 that is planned to be fixed in RHEL-6.7. It should only affect the display of the values, the actual storage and execution should be OK. As indicated in the bug, you can verify the values are set up correctly in /var/lib/certmonger/requests. Does that help? > We are using ipa-server-3.0.0-42 on CentOS 6.6. According to yum the > original version which we installed is ipa-server-3.0.0-26. > > Best regards, > Thomas From jhrozek at redhat.com Mon Feb 23 08:55:06 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 23 Feb 2015 09:55:06 +0100 Subject: [Freeipa-users] Centos 7 No permission to /home/.. In-Reply-To: <3639142.SAz7JWVjyl@techz> References: <3639142.SAz7JWVjyl@techz> Message-ID: <20150223085506.GD2968@hendrix.lan> On Sun, Feb 22, 2015 at 10:19:32PM +0100, G?nther J. Niederwimmer wrote: > Hello, > > I have installed centos 7 and a ipa-server on a other system a second ipa- > server. > > But I can't create a user home directory, not on the server and not on a ipa- > client with autocreate ? > > Have any a hint on witch place I can search for this problem ? > > sssd ipa-server / client .... > > When you like info please tell me what? The first step is verifying that "getent passwd $user" actually reports the home dir you'd like it to. It's especially important to check with users from trusted AD domains. Do you intend to auto-create the home directories on the clients or have them mounted from a central location? In the former case, you should check configuration of oddjob-mkhomedir, in the latter, you should check the automounter configuration. From Less at imagine-sw.com Mon Feb 23 09:01:29 2015 From: Less at imagine-sw.com (Les Stott) Date: Mon, 23 Feb 2015 09:01:29 +0000 Subject: [Freeipa-users] ipa-getcert list fails to report correctly In-Reply-To: <4ED173A868981548967B4FCA27072226280C1C78@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA27072226280BF4DF@AACMBXP04.exchserver.com> <54E6F583.2030603@redhat.com> <54E74707.5040006@redhat.com> <4ED173A868981548967B4FCA27072226280C1C78@AACMBXP04.exchserver.com> Message-ID: <4ED173A868981548967B4FCA27072226280C21AB@AACMBXP04.exchserver.com> > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Les Stott > Sent: Monday, 23 February 2015 12:18 PM > To: Rob Crittenden; Martin Kosek; freeipa-users at redhat.com; Endi Dewata; > Jan Cholasta > Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly > > > > > -----Original Message----- > > From: Rob Crittenden [mailto:rcritten at redhat.com] > > Sent: Saturday, 21 February 2015 1:39 AM > > To: Martin Kosek; Les Stott; freeipa-users at redhat.com; Endi Dewata; > > Jan Cholasta > > Subject: Re: [Freeipa-users] ipa-getcert list fails to report > > correctly > > > > Martin Kosek wrote: > > > On 02/20/2015 06:56 AM, Les Stott wrote: > > >> Hi all, > > >> > > >> The following is blocking the ability for me to install a CA replica. > > >> > > >> Environment: > > >> > > >> RHEL 6.6 > > >> > > >> IPA 3.0.0-42 > > >> > > >> PKI 9.0.3-38 > > >> > > >> On the master the following is happening: > > >> > > >> ipa-getcert list > > >> > > >> Number of certificates and requests being tracked: 5. > > >> > > >> (but it shows no certificate details in the output) > > >> > > >> Running "getcert list" shows complete output. > > >> > > >> Also, when trying to browse > > >> https://master.mydomain.com/ca/ee/ca/getCertChain i get a failed > > >> response. The apache error logs on the master show.... > > >> > > >> [Thu Feb 19 23:23:23 2015] [error] SSL Library Error: -12271 SSL > > >> client cannot verify your certificate > > >> > > >> The reason I am trying to browse that address is because that's > > >> what the ipa-ca-install setup is failing at (it complains that the > > >> CA certificate is not in proper format, in fact it's not able to > > >> get it at all). > > >> > > >> I know from another working ipa setup that .... > > >> > > >> Browsing to the above address provides valid xml content and > > >> ipa-getcert list shows certificate details and not just the number > > >> of tracked certificates. > > >> > > >> Been trying for a long time to figure out the issues without luck. > > >> > > >> I would greatly appreciate any help to troubleshoot and resolve the > > >> above issues. > > >> > > >> Regards, > > >> > > >> Les > > > > > > Endi or JanC, would you have any advise for Les? To me, it looks > > > like the Apache does not have proper certificate installed. > > > > > > My ipa-getcert on RHEL-6.6 shows 3 Server-Certs tracked, making it > > > in total of 8 certs tracked: > > > > > > # ipa-getcert list > > > Number of certificates and requests being tracked: 8. > > > Request ID '20141111000002': > > > status: MONITORING > > > stuck: no > > > key pair storage: > > > type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- > > COM',nicknam > > > e='Server-Cert',token='NSS > > > Certificate > > > DB',pinfile='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/pwdfile.txt' > > > certificate: > > > type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- > > COM',nicknam > > > e='Server-Cert',token='NSS > > > Certificate DB' > > > CA: IPA > > > issuer: CN=Certificate Authority,O=EXAMPLE.COM > > > subject: CN=vm-086.example.com,O=EXAMPLE.COM > > > expires: 2016-11-11 00:00:01 UTC > > > key usage: > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > eku: id-kp-serverAuth,id-kp-clientAuth > > > pre-save command: > > > post-save command: > > > track: yes > > > auto-renew: yes > > > Request ID '20141111000047': > > > status: MONITORING > > > stuck: no > > > key pair storage: > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' > > > ,token='NSS Certificate > > > DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' > > > certificate: > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' > > > ,token='NSS > > > Certificate DB' > > > CA: IPA > > > issuer: CN=Certificate Authority,O=EXAMPLE.COM > > > subject: CN=vm-086.example.com,O=EXAMPLE.COM > > > expires: 2016-11-11 00:00:46 UTC > > > key usage: > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > eku: id-kp-serverAuth,id-kp-clientAuth > > > pre-save command: > > > post-save command: > > > track: yes > > > auto-renew: yes > > > Request ID '20141111000302': > > > status: MONITORING > > > stuck: no > > > key pair storage: > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token= > > > 'N SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > certificate: > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token= > > > 'N > > > SS > > > Certificate DB' > > > CA: IPA > > > issuer: CN=Certificate Authority,O=EXAMPLE.COM > > > subject: CN=vm-086.example.com,O=EXAMPLE.COM > > > expires: 2016-11-11 00:03:02 UTC > > > key usage: > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > eku: id-kp-serverAuth,id-kp-clientAuth > > > pre-save command: > > > post-save command: > > > track: yes > > > auto-renew: yes > > > > > > > > > What is actually in your Apache NSS database? > > > > > > # certutil -L -d /etc/httpd/alias/ > > > > > > Martin > > > > > > > Remember ipa-getcert is just a shortcut for certificates using the > > certmonger CA named IPA, so it's more a filter than anything else. I > > don't know why it wouldn't display any output but I'd file a bug. > > > > I think we'd need to see the getcert list output to try to figure out > > what is going on. > > > > As for the SSL error fetching the cert chain I think Martin may be > > onto something. The request is proxied through Apache. I think the > > client here might be the Apache proxy client. > > > > I believe this command replicates what Apache is doing, you might give > > it a try on the master. This will get the chain directly from dogtag, > > bypassing > > Apache: > > > > $ curl -v --cacert /etc/ipa/ca.crt > > https://`hostname`:9444/ca/ee/ca/getCertChain > > > > rob > > Certutil shows.... > > certutil -L -d /etc/httpd/alias/ > > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > > MYDOMAIN.COM IPA CA CT,C,C > ipaCert u,u,u > Signing-Cert u,u,u > Server-Cert u,u,u > > curl -v --cacert /etc/ipa/ca.crt > https://`hostname`:9444/ca/ee/ca/getCertChain > * About to connect() to `hostname` port 9444 (#0) > * Trying 192.168.1.1... connected > * Connected to `hostname` (192.168.1.1) port 9444 (#0) > * Initializing NSS with certpath: sql:/etc/pki/nssdb > * CAfile: /etc/ipa/ca.crt > CApath: none > * SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA > * Server certificate: > * subject: CN=`hostname`,O=MYDOMAIN.COM > * start date: Dec 13 01:21:30 2013 GMT > * expire date: Dec 03 01:21:30 2015 GMT > * common name: `hostname` > * issuer: CN=Certificate Authority,O=MYDOMAIN.COM > > GET /ca/ee/ca/getCertChain HTTP/1.1 > > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 > > NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > > Host: `hostname`:9444 > > Accept: */* > > > < HTTP/1.1 200 OK > < Server: Apache-Coyote/1.1 > < Content-Type: application/xml > < Content-Length: 1434 > < Date: Mon, 23 Feb 2015 01:04:29 GMT > < > standalone="no"?>0MIID > zwYJKoZIhvcNAQcCoIIDwDCCA7wCAQExADAPBgkqhkiG9w0BBwGgAgQAoII > DoDCCA5wwggKEoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwOjEYMBYGA1U > EChMPREVSSVZBVElWRVMuQ09NMR4wHAYDVQQDExVDZXJ0aWZpY2F0ZSB > BdXRob3JpdHkwHhcNMTMxMjEzMDEyMTI5WhcNMzMxMjEzMDEyMTI5Wj > A6MRgwFgYDVQQKEw9ERVJJVkFUSVZFUy5DT00xHjAcBgNVBAMTFUNlcnRp > ZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCg > gEBAMAA8EaYhmpjSA8o3/1kB/W1+0K6+FrwCS+njOgRtXhiTdmtSddXSDVxH > OafFwqN26BR+QRPZbbpJY70gP3SG8W+J6+c37PMVNshWz6UfChGt6ubgFxlS > TGUUre2Osr9I4C836MXpGJvRx2VDEuMUxv8j7B9iDRnTDglseqPqrMct2No4w > k4cLtA9puBJb0Es76SOHP9edXlf6GBnuYwR8YMc1yJLqpP8IGpHhEkVxMsRpqk > EpuuRwEFa7uBcTDhqVV24BpFlseZVubpiOdEgfb3IRBTjvI1Mum9OCJbuj9P/W > mqMnrA0sQsmF/R3WBwFdMAsN3+bQCRw73+rwoeDNcCAwEAAaOBrDCBq > TAfBgNVHSMEGDAWgBSO8J+j2jAuyg3a0yE+3oVCQJCWUTAPBgNVHRMBAf8 > EBTADAQH/MA4GA1UdDwEB/wQEAwIBxjAdBgNVHQ4EFgQUjvCfo9owLsoN > 2tMhPt6FQkCQllEwRgYIKwYBBQUHAQEEOjA4MDYGCCsGAQUFBzABhipodHR > wOi8vc2I! > ybW9uMDEuZGVyaXZhdGl2ZXMuY29tOjgwL2* Connection #0 to host > `hostname` left intact > * Closing connection #0 > NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAKH8YkoTAzX2xNYMkZSDK84EK3 > e4FUixdXxc/EC5ehjrtaqXT1KT9Fl9DAF5/jYNKqgmEmtHnPGlfQ7/Y1ESdhEGcB > ZjU4qLe4HaFXuw5c9odDYxhtjQUd1g7ifY8SKOcHDCY+6Xx6F/rhFgzrXXMndn8 > ZaYryctPoOAj/5INnLrJq8S4XyLmb2BHM4e1ORQbOhDi8xjhfK2veYXvIu55Brhp > RSS/goz5oSE8e+QE/H9afRmeV2+WkS/YDhSyoUDb7CYjklRuONzX3GopKtp1y > yLXQZnBFjCvIJvja0mo3ik3AXxSZuOwUIlV23U8CyPU/rDeiV00iUyA/fLvdkEtZkx > AA== > > > In any event, I've decided to rebuilt my DR IPA environment. Late last year > the master in DR had to be rebuilt due to a disk issue. While IPA was restored > manually and appeared to be working fine, CA replication hasn't worked. I > finally got CA replication working in Prod after enabling needed apache > modules and performing a yum update to update related packages, but > these things didn't help in DR. It's my strong suspicion that something got > missed when restoring the DR master IPA server and this is what is causing all > my grief. Therefore, I'm going to wipe it out and start from scratch in DR. > There are other benefits for me to do this anyway. > Well things have gone from bad to worse. I removed IPA in DR. uninstalled all ipa clients, uninstalled replicas, removed replication agreements and removed the master. Ran pki-remove to clear any leftover pki instances and used certutil -D to remove left behind ipa entries in /etc/httpd/alias. So, clean slate to start again. This time, in order to mirror config with prod, I began an installation for the master on a different server, let's call it serverb. It was previously a replica (in my prod environment, serverb is the true master, servera, serverc, and serverd are replicas). So, trying to install a new fresh instance of IPA and it still fails to configure a CA. Attached is the relevant portion of the server install log file (ipa-server-install.txt). I have removed certificate and copyright info to reduce its size. Also my server to install is serverb.mydomain.com Apache logs at the time of the error show: [Mon Feb 23 03:05:31 2015] [error] SSL Library Error: -12195 Peer does not recognize and trust the CA that issued your certificate Certificate databases only show the following (note that "Server-Cert cert-pki-ca" got installed before the installer crashed). Prior to trying installation I had to manually remove server certs left behind from the previous installation via ... certutil -d /etc/httpd/alias -D -n "Server-Cert" certutil -d /etc/httpd/alias -D -n "MYDOMAIN.COM IPA CA" certutil -d /etc/httpd/alias -D -n ipaCert certutil -L -d /var/lib/pki-ca/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert cert-pki-ca CTu,Cu,Cu certutil -L -d /etc/pki/nssdb Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Selinux is in permissive mode. Ausearch -m avc does show some selinux issues, but its permissive mode so it should be ok right? In any event I have previously tried installing a CA replica with selinux disabled and it didn't help. I have tried removing ipa and pki rpms and reinstalling. Then rerunning the ipa server install script but the same error occurs. I noticed that /etc/ipa/ca.crt was still old, and referencing the original master. I removed that and again reran the installer but the same error occurred. Note also that /etc/ipa/cr.crt was not recreated when ipa-python was reinstalled. Other logs: /var/log/pki-ca/system shows 5042.main - [23/Feb/2015:03:05:12 EST] [3] [3] Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate 5042.main - [23/Feb/2015:03:05:12 EST] [13] [3] authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value 5042.http-9445-1 - [23/Feb/2015:03:05:26 EST] [3] [3] Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate 5042.http-9445-1 - [23/Feb/2015:03:05:35 EST] [3] [3] CASigningUnit: Object certificate not found. Error org.mozilla.jss.crypto.ObjectNotFoundException /var/log/pki-ca/catalina.out Feb 23, 2015 3:05:11 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory ca 64-bit osutil library loaded 64-bit osutil library loaded CMS Warning: FAILURE: Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate|FAILURE: authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value| Server is started. Feb 23, 2015 3:05:12 AM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-9180 Feb 23, 2015 3:05:12 AM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-9443 Feb 23, 2015 3:05:12 AM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-9445 Feb 23, 2015 3:05:12 AM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-9444 Feb 23, 2015 3:05:12 AM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-9446 Feb 23, 2015 3:05:12 AM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:9447 Feb 23, 2015 3:05:12 AM org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/25 config=null Feb 23, 2015 3:05:12 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 1655 ms I have no idea where to look next. There must be some remnant of the old system hanging around screwing things up but I cannot figure it out. This will drive me insane! I can provide more logs if needed. Thanks in advance for any help. Regards, Les -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ipa-server-install.txt URL: From gjn at gjn.priv.at Mon Feb 23 16:29:32 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Mon, 23 Feb 2015 17:29:32 +0100 Subject: [Freeipa-users] Centos 7 No permission to /home/.. In-Reply-To: <20150223085506.GD2968@hendrix.lan> References: <3639142.SAz7JWVjyl@techz> <20150223085506.GD2968@hendrix.lan> Message-ID: <2739423.kvsteOPKIv@techz> Hello, Am Montag, 23. Februar 2015, 09:55:06 schrieb Jakub Hrozek: > On Sun, Feb 22, 2015 at 10:19:32PM +0100, G?nther J. Niederwimmer wrote: > > Hello, > > > > I have installed centos 7 and a ipa-server on a other system a second ipa- > > server. > > > > But I can't create a user home directory, not on the server and not on a > > ipa- client with autocreate ? > > > > Have any a hint on witch place I can search for this problem ? > > > > sssd ipa-server / client .... > > > > When you like info please tell me what? > > The first step is verifying that "getent passwd $user" actually reports > the home dir you'd like it to. It's especially important to check with > users from trusted AD domains. This is working, tell me "/home/xxxx" > Do you intend to auto-create the home directories on the clients or have > them mounted from a central location? In the former case, you should > check configuration of oddjob-mkhomedir, in the latter, you should check > the automounter configuration. I tested all (?), I have configured a ntp /mount for /home, Create a /home/user directory only on the ipa-server, nothing is working I have allways permission denied ? I found a Bug report for the oddjob-mkhomedir, to change the permission from 0002 to 0077 but now, I am on the end ? But on a ipa client a can't do chown -R xxxx:ipausers to change the permission. The ipausers Group is not found on a client? Is this a sssd problem? Now I uninstall all and start again ?. -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From CWhite at skytouchtechnology.com Mon Feb 23 17:03:34 2015 From: CWhite at skytouchtechnology.com (Craig White) Date: Mon, 23 Feb 2015 17:03:34 +0000 Subject: [Freeipa-users] Centos 7 No permission to /home/.. In-Reply-To: <2739423.kvsteOPKIv@techz> References: <3639142.SAz7JWVjyl@techz> <20150223085506.GD2968@hendrix.lan> <2739423.kvsteOPKIv@techz> Message-ID: -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of G?nther J. Niederwimmer Sent: Monday, February 23, 2015 9:30 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Centos 7 No permission to /home/.. Hello, Am Montag, 23. Februar 2015, 09:55:06 schrieb Jakub Hrozek: > On Sun, Feb 22, 2015 at 10:19:32PM +0100, G?nther J. Niederwimmer wrote: > > Hello, > > > > I have installed centos 7 and a ipa-server on a other system a > > second ipa- server. > > > > But I can't create a user home directory, not on the server and not > > on a > > ipa- client with autocreate ? > > > > Have any a hint on witch place I can search for this problem ? > > > > sssd ipa-server / client .... > > > > When you like info please tell me what? > > The first step is verifying that "getent passwd $user" actually > reports the home dir you'd like it to. It's especially important to > check with users from trusted AD domains. This is working, tell me "/home/xxxx" > Do you intend to auto-create the home directories on the clients or > have them mounted from a central location? In the former case, you > should check configuration of oddjob-mkhomedir, in the latter, you > should check the automounter configuration. I tested all (?), I have configured a ntp /mount for /home, Create a /home/user directory only on the ipa-server, nothing is working I have allways permission denied ? I found a Bug report for the oddjob-mkhomedir, to change the permission from 0002 to 0077 but now, I am on the end ? But on a ipa client a can't do chown -R xxxx:ipausers to change the permission. The ipausers Group is not found on a client? Is this a sssd problem? Now I uninstall all and start again ?. ---- On my setup, group 'ipausers' is not a Posix Group and thus isn't relevant to any of the servers. If indeed oddjob_mkhomedir is creating users $HOME with 755 permissions, then you might want to have a root cron script running on the NFS server itself to set the permissions on a regular basis... ie. 0 * * * * chmod 0700 /home/* > /dev/null 2>&1 #Every hour on the hour, set /home/* to users only. Not an SSSD problem. Craig From jhrozek at redhat.com Mon Feb 23 19:20:45 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 23 Feb 2015 20:20:45 +0100 Subject: [Freeipa-users] Centos 7 No permission to /home/.. In-Reply-To: <2739423.kvsteOPKIv@techz> References: <3639142.SAz7JWVjyl@techz> <20150223085506.GD2968@hendrix.lan> <2739423.kvsteOPKIv@techz> Message-ID: <20150223192045.GJ9792@hendrix.redhat.com> On Mon, Feb 23, 2015 at 05:29:32PM +0100, G?nther J. Niederwimmer wrote: > I tested all (?), I have configured a ntp /mount for /home, Create a /home/user > directory only on the ipa-server, nothing is working I have allways permission > denied ? > > I found a Bug report for the oddjob-mkhomedir, to change the permission from > 0002 to 0077 but now, I am on the end ? Which bugreport? IIRC there was one by Stef Walter which I can't find right now described the default permissions, but it should still be configurable.. From thomas.raehalme at codecenter.fi Tue Feb 24 08:26:54 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Tue, 24 Feb 2015 10:26:54 +0200 Subject: [Freeipa-users] Identifying current CA master In-Reply-To: <54EAE4ED.9030700@redhat.com> References: <54EAE4ED.9030700@redhat.com> Message-ID: Hi! On Mon, Feb 23, 2015 at 10:29 AM, Martin Kosek wrote: > Good question. You are most likely hitting bug > https://bugzilla.redhat.com/show_bug.cgi?id=1178190 > that is planned to be fixed in RHEL-6.7. > > It should only affect the display of the values, the actual storage and > execution should be OK. As indicated in the bug, you can verify the values > are > set up correctly in /var/lib/certmonger/requests. > > Does that help? > I checked the request under /var/lib/certmonger/requests and post-save command seems to be defined properly. Thanks! Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jurrien.Bloemen at dmc.amcnetworks.com Tue Feb 24 09:15:11 2015 From: Jurrien.Bloemen at dmc.amcnetworks.com (=?utf-8?B?QmxvZW1lbiwgSnVycmnDq24=?=) Date: Tue, 24 Feb 2015 09:15:11 +0000 Subject: [Freeipa-users] Root overrides HBAC rules for the command su Message-ID: <54EC411F.50405@dmc.amcnetworks.com> Hi, In FreeIPA you can create users and restrict on which hosts the user can login to. This is all great and works fine. If a user1 is logged in to a system. Knows the password of user2 and issues the command "su" to be that user2 on that same system. This is not allowed because the user2 does not have HBAC rules for that system. This is as expected. But if the user root tries the "su" command to be user2 is works despite the fact that user2 has no HBAC rule for that system. Why does this works? Is there a way to prevent this? Or is this something in "su" that it works like the way it does? Best regards, Jurri?n This message (including any attachments) may contain information that is privileged or confidential. If you are not the intended recipient, please notify the sender and delete this email immediately from your systems and destroy all copies of it. You may not, directly or indirectly, use, disclose, distribute, print or copy this email or any part of it if you are not the intended recipient -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjn at gjn.priv.at Tue Feb 24 09:24:26 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Tue, 24 Feb 2015 10:24:26 +0100 Subject: [Freeipa-users] Centos 7 No permission to /home/.. In-Reply-To: <20150223192045.GJ9792@hendrix.redhat.com> References: <3639142.SAz7JWVjyl@techz> <2739423.kvsteOPKIv@techz> <20150223192045.GJ9792@hendrix.redhat.com> Message-ID: <14844939.vLDfFerSbt@techz> Am Montag, 23. Februar 2015, 20:20:45 schrieb Jakub Hrozek: > On Mon, Feb 23, 2015 at 05:29:32PM +0100, G?nther J. Niederwimmer wrote: > > I tested all (?), I have configured a ntp /mount for /home, Create a > > /home/user directory only on the ipa-server, nothing is working I have > > allways permission denied ? > > > > I found a Bug report for the oddjob-mkhomedir, to change the permission > > from 0002 to 0077 but now, I am on the end ? > > Which bugreport? IIRC there was one by Stef Walter which I can't find > right now described the default permissions, but it should still be > configurable.. I found this, http://stackoverflow.com/questions/23040225/incorrect-permissions-when-home-directory-is-automatically-created-in-freeipa -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From sbose at redhat.com Tue Feb 24 09:53:00 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 24 Feb 2015 10:53:00 +0100 Subject: [Freeipa-users] Root overrides HBAC rules for the command su In-Reply-To: <54EC411F.50405@dmc.amcnetworks.com> References: <54EC411F.50405@dmc.amcnetworks.com> Message-ID: <20150224095300.GI3271@p.redhat.com> On Tue, Feb 24, 2015 at 09:15:11AM +0000, Bloemen, Jurri?n wrote: > Hi, > > In FreeIPA you can create users and restrict on which hosts the user can login to. This is all great and works fine. > > If a user1 is logged in to a system. Knows the password of user2 and issues the command "su" to be that user2 on that same system. This is not allowed because the user2 does not have HBAC rules for that system. This is as expected. > > But if the user root tries the "su" command to be user2 is works despite the fact that user2 has no HBAC rule for that system. > > Why does this works? Is there a way to prevent this? Or is this something in "su" that it works like the way it does? It is the PAM configuration of su, e.g. on F21 it looks like this: #%PAM-1.0 auth sufficient pam_rootok.so # Uncomment the following line to implicitly trust users in the "wheel" # group. #auth sufficient pam_wheel.so trust use_uid # Uncomment the following line to require a user to be in the "wheel" # group. #auth required pam_wheel.so use_uid auth substack system-auth auth include postlogin account sufficient pam_succeed_if.so uid = 0 use_uid quiet account include system-auth password include system-auth session include system-auth session include postlogin session optional pam_xauth.so If you are root authentication is skipped with pam_rootok.so and access control by 'pam_succeed_if.so uid = 0 use_uid quiet'. You can change this if you want but is is not very useful because there are various other way for root to become user2 without calling su. root can do everything on the local system. HTH bye, Sumit > > Best regards, > > Jurri?n > > This message (including any attachments) may contain information that is privileged or confidential. If you are not the intended recipient, please notify the sender and delete this email immediately from your systems and destroy all copies of it. You may not, directly or indirectly, use, disclose, distribute, print or copy this email or any part of it if you are not the intended recipient > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From veera.veluchamy at aspiresys.com Mon Feb 23 10:13:50 2015 From: veera.veluchamy at aspiresys.com (Veera Veluchamy) Date: Mon, 23 Feb 2015 10:13:50 +0000 Subject: [Freeipa-users] Reg:FreeIPA Client Configuration Message-ID: Hi, I have configure FreeIPA server in centos and synchronized with windows active directory .If I create any users in AD it will be automatically synchronized with IPAServer . But I'm unable to configure IPA client in my centos machine which is installed on another machine. IPA Client is unable to discover dns entry. Can anybody tell me how to resolve this issue. Regards, Veerakumar V Infrastructure Application Support [Aspire Systems] This e-mail message and any attachments are for the sole use of the intended recipient(s) and may contain proprietary, confidential, trade secret or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited and may be a violation of law. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Feb 24 14:50:01 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 24 Feb 2015 15:50:01 +0100 Subject: [Freeipa-users] Reg:FreeIPA Client Configuration In-Reply-To: References: Message-ID: <54EC8F99.1090802@redhat.com> On 02/23/2015 11:13 AM, Veera Veluchamy wrote: > Hi, > > I have configure FreeIPA server in centos and synchronized with windows active directory .If I create any users in AD it will be automatically synchronized with IPAServer . But I'm unable to configure IPA client in my centos machine which is installed on another machine. > > IPA Client is unable to discover dns entry. > > Can anybody tell me how to resolve this issue. Looks like DNS issue to me. Some tips and advise how to troubleshoot are here: http://www.freeipa.org/page/Troubleshooting#DNS_Issues Martin From rcritten at redhat.com Tue Feb 24 15:06:33 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Feb 2015 10:06:33 -0500 Subject: [Freeipa-users] Migration fails from 3.0.0 to 3.3.3 on Centos 6/7 In-Reply-To: <1d33952d513a47857439feaf0658901a@westi.foo> References: <54E5FC3D.3070904@iki.fi> " <54E60BF5.7@redhat.com>" <54E60DB5.7080206@redhat.com> <54E61137.5030906@iki.fi> <54E66C9E.7010105@redhat.com> <1d33952d513a47857439feaf0658901a@westi.foo> Message-ID: <54EC9379.3090502@redhat.com> West, Jani wrote: > Hi, > > Validity, status and serials seems to be fine. One interesting pick: > While the installation is not too old it might be installed initially > with FreeIpa 2.x That's why i have to use ldap port 7389 instead of 398. > > # getcert list |grep expires > expires: 2016-11-21 13:40:41 UTC > expires: 2016-11-21 13:40:44 UTC > expires: 2016-11-21 13:40:41 UTC > expires: 2016-10-30 09:08:12 UTC > expires: 2016-10-30 09:07:12 UTC > expires: 2016-10-30 09:07:12 UTC > expires: 2016-10-30 09:07:12 UTC > expires: 2016-10-30 09:07:12 UTC > # getcert list -d /etc/httpd/alias -n ipaCert |egrep -i '(status|expires)' > status: MONITORING > expires: 2016-10-30 09:07:12 UTC > # certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial > Serial Number: 31 (0x1f) > # ldapsearch -x -h localhost -p 7389 -b uid=ipara,ou=People,o=ipaca > description > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: description > # > > # ipara, people, ipaca > dn: uid=ipara,ou=people,o=ipaca > description: 2;31;CN=Certificate Authority,O=WESTI;CN=IPA RA,O=WESTI > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > I suspect you are bootstrapping the replica with expired certs. After the failed install the certs probably still exist on the replica in /var/lib/pki-ca/alias. Check the dates. I think you needsto refresh /root/cacerts.p12 on the master you are preparing the replica on. In newer IPA we regenerate this on-the-fly but it isn't in 3.0. Use PKCS12Export to do this. rob From jwest at iki.fi Tue Feb 24 15:44:17 2015 From: jwest at iki.fi (West, Jani) Date: Tue, 24 Feb 2015 17:44:17 +0200 Subject: [Freeipa-users] Migration fails from 3.0.0 to 3.3.3 on Centos 6/7 In-Reply-To: <54EC9379.3090502@redhat.com> References: <54E5FC3D.3070904@iki.fi> " <54E60BF5.7@redhat.com>" <54E60DB5.7080206@redhat.com> "\"<54E61137.5030906@iki.fi>" " <54E66C9E.7010105@redhat.com> <1d33952d513a47857439feaf0658901a@westi.foo> <54EC9379.3090502@redhat.com> Message-ID: Thank you for the tip, Just created new /root/cacerts.p12. Should I import it to the CA somehow or just restart the ipa server? Will reset the new replicate vm to clean CentOS 7 installation without any leftovers from ipa-replica-install. -- -- Jani West On 24.2.2015 17:06, Rob Crittenden wrote: > West, Jani wrote: >> Hi, >> >> Validity, status and serials seems to be fine. One interesting pick: >> While the installation is not too old it might be installed initially >> with FreeIpa 2.x That's why i have to use ldap port 7389 instead of >> 398. >> >> # getcert list |grep expires >> expires: 2016-11-21 13:40:41 UTC >> expires: 2016-11-21 13:40:44 UTC >> expires: 2016-11-21 13:40:41 UTC >> expires: 2016-10-30 09:08:12 UTC >> expires: 2016-10-30 09:07:12 UTC >> expires: 2016-10-30 09:07:12 UTC >> expires: 2016-10-30 09:07:12 UTC >> expires: 2016-10-30 09:07:12 UTC >> # getcert list -d /etc/httpd/alias -n ipaCert |egrep -i >> '(status|expires)' >> status: MONITORING >> expires: 2016-10-30 09:07:12 UTC >> # certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial >> Serial Number: 31 (0x1f) >> # ldapsearch -x -h localhost -p 7389 -b uid=ipara,ou=People,o=ipaca >> description >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (objectclass=*) >> # requesting: description >> # >> >> # ipara, people, ipaca >> dn: uid=ipara,ou=people,o=ipaca >> description: 2;31;CN=Certificate Authority,O=WESTI;CN=IPA RA,O=WESTI >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> >> > > I suspect you are bootstrapping the replica with expired certs. After > the failed install the certs probably still exist on the replica in > /var/lib/pki-ca/alias. Check the dates. > > I think you needsto refresh /root/cacerts.p12 on the master you are > preparing the replica on. In newer IPA we regenerate this on-the-fly > but > it isn't in 3.0. Use PKCS12Export to do this. > > rob From rcritten at redhat.com Tue Feb 24 16:06:40 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Feb 2015 11:06:40 -0500 Subject: [Freeipa-users] Migration fails from 3.0.0 to 3.3.3 on Centos 6/7 In-Reply-To: References: <54E5FC3D.3070904@iki.fi> " <54E60BF5.7@redhat.com>" <54E60DB5.7080206@redhat.com> "\"<54E61137.5030906@iki.fi>" " <54E66C9E.7010105@redhat.com> <1d33952d513a47857439feaf0658901a@westi.foo> <54EC9379.3090502@redhat.com> Message-ID: <54ECA190.8010804@redhat.com> West, Jani wrote: > Thank you for the tip, > > Just created new /root/cacerts.p12. Should I import it to the CA somehow > or just restart the ipa server? > > Will reset the new replicate vm to clean CentOS 7 installation without > any leftovers from ipa-replica-install. > Re-run ipa-replica-prepare and it will pick up the new file. Use that newly prepared file on your replica and hopefully that will do the trick. rob From rob.verduijn at gmail.com Tue Feb 24 17:34:39 2015 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Tue, 24 Feb 2015 18:34:39 +0100 Subject: [Freeipa-users] multi-tenancy status Message-ID: Hello, I'm interested in setting up ipa with multiple tenancies. However I can only find this document about the subject: http://www.freeipa.org/page/V3/Multitenancy What is the status of the implementation of multiple tenancies. Cheers Rob Verduijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Feb 24 18:48:55 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 24 Feb 2015 13:48:55 -0500 Subject: [Freeipa-users] multi-tenancy status In-Reply-To: References: Message-ID: <54ECC797.402@redhat.com> On 02/24/2015 12:34 PM, Rob Verduijn wrote: > Hello, > > I'm interested in setting up ipa with multiple tenancies. > > However I can only find this document about the subject: > http://www.freeipa.org/page/V3/Multitenancy > > What is the status of the implementation of multiple tenancies. Unscheduled. Too much work to implement as proposed. We will go with IPA to IPA trusts and SAML based federation (project Ipsilon) first. > > Cheers > Rob Verduijn > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Tue Feb 24 19:48:16 2015 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Tue, 24 Feb 2015 20:48:16 +0100 Subject: [Freeipa-users] multi-tenancy status In-Reply-To: <54ECC797.402@redhat.com> References: <54ECC797.402@redhat.com> Message-ID: Now that sounds like an interesting project :-) besides the following links any other places where I can read up about it ? https://fedorahosted.org/ipsilon/ http://www.freeipa.org/page/Web_App_Authentication http://en.wikipedia.org/wiki/Identity_provider http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language Cheers Rob 2015-02-24 19:48 GMT+01:00 Dmitri Pal : > On 02/24/2015 12:34 PM, Rob Verduijn wrote: > > Hello, > > I'm interested in setting up ipa with multiple tenancies. > > However I can only find this document about the subject: > http://www.freeipa.org/page/V3/Multitenancy > > What is the status of the implementation of multiple tenancies. > > > Unscheduled. > Too much work to implement as proposed. > We will go with IPA to IPA trusts and SAML based federation (project > Ipsilon) first. > > > Cheers > Rob Verduijn > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Feb 24 19:55:12 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Feb 2015 14:55:12 -0500 Subject: [Freeipa-users] multi-tenancy status In-Reply-To: References: <54ECC797.402@redhat.com> Message-ID: <54ECD720.9050101@redhat.com> Rob Verduijn wrote: > Now that sounds like an interesting project :-) > > besides the following links any other places where I can read up about it ? > https://fedorahosted.org/ipsilon/ > http://www.freeipa.org/page/Web_App_Authentication > http://en.wikipedia.org/wiki/Identity_provider > http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language For more details on SAML2 than you'll even want, see https://wiki.oasis-open.org/security/FrontPage mod_auth_mellon is an SP for Apache that is compatible with Ipsilon. There is also https://shibboleth.net/ Devs hang out in #ipsilon on freenode Ipsilon will be one of the changes in F-22: http://fedoraproject.org/wiki/Releases/22/ChangeSet#Ipsilon A test day is planned for March 12 (assuming approved by FESCO). rob > > Cheers > Rob > > 2015-02-24 19:48 GMT+01:00 Dmitri Pal >: > > On 02/24/2015 12:34 PM, Rob Verduijn wrote: >> Hello, >> >> I'm interested in setting up ipa with multiple tenancies. >> >> However I can only find this document about the subject: >> http://www.freeipa.org/page/V3/Multitenancy >> >> What is the status of the implementation of multiple tenancies. > > Unscheduled. > Too much work to implement as proposed. > We will go with IPA to IPA trusts and SAML based federation (project > Ipsilon) first. > >> >> Cheers >> Rob Verduijn >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > > > From rob.verduijn at gmail.com Tue Feb 24 20:08:36 2015 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Tue, 24 Feb 2015 21:08:36 +0100 Subject: [Freeipa-users] multi-tenancy status In-Reply-To: <54ECD720.9050101@redhat.com> References: <54ECC797.402@redhat.com> <54ECD720.9050101@redhat.com> Message-ID: Thanx, That all sounds very interesting, I've got some reading up to do. I'm going to point this out to some people :-) Rob 2015-02-24 20:55 GMT+01:00 Rob Crittenden : > Rob Verduijn wrote: > > Now that sounds like an interesting project :-) > > > > besides the following links any other places where I can read up about > it ? > > https://fedorahosted.org/ipsilon/ > > http://www.freeipa.org/page/Web_App_Authentication > > http://en.wikipedia.org/wiki/Identity_provider > > http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language > > For more details on SAML2 than you'll even want, see > https://wiki.oasis-open.org/security/FrontPage > > mod_auth_mellon is an SP for Apache that is compatible with Ipsilon. > There is also https://shibboleth.net/ > > Devs hang out in #ipsilon on freenode > > Ipsilon will be one of the changes in F-22: > http://fedoraproject.org/wiki/Releases/22/ChangeSet#Ipsilon > > A test day is planned for March 12 (assuming approved by FESCO). > > rob > > > > > Cheers > > Rob > > > > 2015-02-24 19:48 GMT+01:00 Dmitri Pal > >: > > > > On 02/24/2015 12:34 PM, Rob Verduijn wrote: > >> Hello, > >> > >> I'm interested in setting up ipa with multiple tenancies. > >> > >> However I can only find this document about the subject: > >> http://www.freeipa.org/page/V3/Multitenancy > >> > >> What is the status of the implementation of multiple tenancies. > > > > Unscheduled. > > Too much work to implement as proposed. > > We will go with IPA to IPA trusts and SAML based federation (project > > Ipsilon) first. > > > >> > >> Cheers > >> Rob Verduijn > >> > >> > > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager IdM portfolio > > Red Hat, Inc. > > > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go To http://freeipa.org for more info on the project > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwest at iki.fi Tue Feb 24 21:46:36 2015 From: jwest at iki.fi (Jani West) Date: Tue, 24 Feb 2015 23:46:36 +0200 Subject: [Freeipa-users] Migration fails from 3.0.0 to 3.3.3 on Centos 6/7 In-Reply-To: <54ECA190.8010804@redhat.com> References: <54E5FC3D.3070904@iki.fi> " <54E60BF5.7@redhat.com>" <54E60DB5.7080206@redhat.com> "\"<54E61137.5030906@iki.fi>" " <54E66C9E.7010105@redhat.com> <1d33952d513a47857439feaf0658901a@westi.foo> <54EC9379.3090502@redhat.com> <54ECA190.8010804@redhat.com> Message-ID: <54ECF13C.7060209@iki.fi> Re-created replication file and run ipa-replica-install o fresh CentOS 7 server. It is still giving the same error: --------------------- 2015-02-24T21:40:54Z DEBUG Process finished, return code=1 2015-02-24T21:40:54Z DEBUG stdout=Loading deployment configuration from /tmp/tmpR56_Ck. Installing CA into /var/lib/pki/pki-tomcat. Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. Installation failed. 2015-02-24T21:40:54Z DEBUG stderr=pkispawn : WARNING ....... unable to validate security domain user/password through REST interface. Interface not available pkispawn : ERROR ....... Exception from Java Configuration Servlet: Error while updating security domain: java.io.IOException: 2 --------------------. On 02/24/2015 06:06 PM, Rob Crittenden wrote: > West, Jani wrote: >> Thank you for the tip, >> >> Just created new /root/cacerts.p12. Should I import it to the CA somehow >> or just restart the ipa server? >> >> Will reset the new replicate vm to clean CentOS 7 installation without >> any leftovers from ipa-replica-install. >> > > Re-run ipa-replica-prepare and it will pick up the new file. Use that > newly prepared file on your replica and hopefully that will do the trick. > > rob > -- -- Jani West -- jwest at iki.fi -- +358 40 5010914 -- -- Liinalahdentie 4 -- 01800 KLAUKKALA -- FINLAND -- "Haluaisin, ett? Suomi olisi paljon monikulttuurisempi. T?nne tulee muualta paljon ihmisi?, mutta heit? ei tuoda tarpeeksi esille. Jotenkin me pid?mme heid?t verhojen takana. On t?rke??, ett? Suomesta saataisiin avoin ja suvaitsevainen. Sulkeutunut ajattelutapa on Suomen ongelma. Ehk? me pelk??mme mielenosoituksia, joita esimerkiksi Ruotsin l?hi?iss? on ollut ja sit?, ett? jotain kauheaa tapahtuu. Ei ymm?rret?, ett? maahanmuuttajat voivat tuoda Suomeen my?s paljon hyv??. Toivoisin hallitukselta sit?, ett? koko kansaa kuullaan, my?s eri kulttuureista tulevia. Hallituksen pit?isi rahoittaa ja tukea enemm?n Suomen kansainv?list?mist?. My?s eduskunta voisi kuunnella maahanmuuttajia enemm?n." HS 8.6.2013: Essi, 16 v. Etu-T??l?n lukio. From rcritten at redhat.com Tue Feb 24 22:00:29 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Feb 2015 17:00:29 -0500 Subject: [Freeipa-users] Migration fails from 3.0.0 to 3.3.3 on Centos 6/7 In-Reply-To: <54ECF13C.7060209@iki.fi> References: <54E5FC3D.3070904@iki.fi> " <54E60BF5.7@redhat.com>" <54E60DB5.7080206@redhat.com> "\"<54E61137.5030906@iki.fi>" " <54E66C9E.7010105@redhat.com> <1d33952d513a47857439feaf0658901a@westi.foo> <54EC9379.3090502@redhat.com> <54ECA190.8010804@redhat.com> <54ECF13C.7060209@iki.fi> Message-ID: <54ECF47D.2030405@redhat.com> Jani West wrote: > Re-created replication file and run ipa-replica-install o fresh CentOS 7 > server. > > It is still giving the same error: > > --------------------- > 2015-02-24T21:40:54Z DEBUG Process finished, return code=1 > 2015-02-24T21:40:54Z DEBUG stdout=Loading deployment configuration from > /tmp/tmpR56_Ck. > Installing CA into /var/lib/pki/pki-tomcat. > Storing deployment configuration into > /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. > Installation failed. > > > 2015-02-24T21:40:54Z DEBUG stderr=pkispawn : WARNING ....... unable > to validate security domain user/password through REST interface. > Interface not available That is expected. > pkispawn : ERROR ....... Exception from Java Configuration > Servlet: Error while updating security domain: java.io.IOException: 2 I think a fresh set of logs is in needed. rob > --------------------. > > On 02/24/2015 06:06 PM, Rob Crittenden wrote: >> West, Jani wrote: >>> Thank you for the tip, >>> >>> Just created new /root/cacerts.p12. Should I import it to the CA somehow >>> or just restart the ipa server? >>> >>> Will reset the new replicate vm to clean CentOS 7 installation without >>> any leftovers from ipa-replica-install. >>> >> >> Re-run ipa-replica-prepare and it will pick up the new file. Use that >> newly prepared file on your replica and hopefully that will do the trick. >> >> rob >> > > From jwest at iki.fi Tue Feb 24 22:08:30 2015 From: jwest at iki.fi (Jani West) Date: Wed, 25 Feb 2015 00:08:30 +0200 Subject: [Freeipa-users] Migration fails from 3.0.0 to 3.3.3 on Centos 6/7 In-Reply-To: <54ECF47D.2030405@redhat.com> References: <54E5FC3D.3070904@iki.fi> " <54E60BF5.7@redhat.com>" <54E60DB5.7080206@redhat.com> "\"<54E61137.5030906@iki.fi>" " <54E66C9E.7010105@redhat.com> <1d33952d513a47857439feaf0658901a@westi.foo> <54EC9379.3090502@redhat.com> <54ECA190.8010804@redhat.com> <54ECF13C.7060209@iki.fi> <54ECF47D.2030405@redhat.com> Message-ID: <54ECF65E.1090805@iki.fi> On old master apache logs looks like this: --------------- [Tue Feb 24 23:37:40 2015] [error] [client 192.168.177.8] File does not exist: /var/www/html/ca [Tue Feb 24 23:37:41 2015] [error] [client 192.168.177.8] File does not exist: /var/www/html/ca [Tue Feb 24 23:38:22 2015] [error] [client 192.168.177.8] File does not exist: /var/www/html/ca 192.168.177.8 - - [24/Feb/2015:10:35:47 +0200] "POST /ca/agent/ca/updateDomainXML HTTP/1.0" 403 323 192.168.177.8 - - [24/Feb/2015:23:37:40 +0200] "GET /ca/rest/securityDomain/domainInfo HTTP/1.1" 404 325 192.168.177.8 - - [24/Feb/2015:23:37:41 +0200] "GET /ca/admin/ca/getDomainXML HTTP/1.1" 200 1158 192.168.177.8 - - [24/Feb/2015:23:37:41 +0200] "GET /ca/rest/account/login HTTP/1.1" 404 313 192.168.177.8 - - [24/Feb/2015:23:38:19 +0200] "POST /ca/admin/ca/getCertChain HTTP/1.0" 200 1410 192.168.177.8 - - [24/Feb/2015:23:38:22 +0200] "GET /ca/rest/account/login HTTP/1.1" 404 313 192.168.177.8 - - [24/Feb/2015:23:38:22 +0200] "POST /ca/admin/ca/getCookie HTTP/1.1" 200 4088 192.168.177.8 - - [24/Feb/2015:23:38:22 +0200] "POST /ca/admin/ca/getDomainXML HTTP/1.0" 200 1158 192.168.177.8 - - [24/Feb/2015:23:38:23 +0200] "POST /ca/admin/ca/getCertChain HTTP/1.0" 200 1410 192.168.177.8 - - [24/Feb/2015:23:38:23 +0200] "POST /ca/admin/ca/updateNumberRange HTTP/1.0" 404 - 192.168.177.8 - - [24/Feb/2015:23:38:24 +0200] "POST /ca/admin/ca/updateNumberRange HTTP/1.0" 404 - 192.168.177.8 - - [24/Feb/2015:23:38:23 +0200] "POST /ca/ee/ca/updateNumberRange HTTP/1.0" 200 163 192.168.177.8 - - [24/Feb/2015:23:38:24 +0200] "POST /ca/ee/ca/updateNumberRange HTTP/1.0" 200 163 192.168.177.8 - - [24/Feb/2015:23:38:27 +0200] "POST /ca/admin/ca/updateNumberRange HTTP/1.0" 404 - 192.168.177.8 - - [24/Feb/2015:23:38:27 +0200] "POST /ca/ee/ca/updateNumberRange HTTP/1.0" 200 153 192.168.177.8 - - [24/Feb/2015:23:38:30 +0200] "POST /ca/admin/ca/getConfigEntries HTTP/1.0" 200 13714 192.168.177.8 - - [24/Feb/2015:23:41:06 +0200] "POST /ca/admin/ca/getDomainXML HTTP/1.0" 200 1158 192.168.177.8 - - [24/Feb/2015:23:41:06 +0200] "POST /ca/admin/ca/updateDomainXML HTTP/1.0" 404 - 192.168.177.8 - - [24/Feb/2015:23:41:06 +0200] "POST /ca/agent/ca/updateDomainXML HTTP/1.0" 200 115 --------------------- and /var/log/ipareplica-install.log on new replica looks like this: -------------------- pkispawn : ERROR ....... Exception from Java Configuration Servlet: Error while updating security domain: java.io.IOException: 2 2015-02-24T21:40:54Z CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpR56_Ck' returned non-zero exit status 1 2015-02-24T21:40:54Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 638, in run_script return_value = main_function() File "/usr/sbin/ipa-replica-install", line 667, in main CA = cainstance.install_replica_ca(config) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1689, in install_replica_ca subject_base=config.subject_base) 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/install/service.py", line 364, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 615, in __spawn_instance raise RuntimeError('Configuration of CA failed') 2015-02-24T21:40:54Z DEBUG The ipa-replica-install command failed, exception: RuntimeError: Configuration of CA failed -------------------- Just give me a shout if you want me to run replication again and if you need any extra logs. On 02/25/2015 12:00 AM, Rob Crittenden wrote: > Jani West wrote: >> Re-created replication file and run ipa-replica-install o fresh CentOS 7 >> server. >> >> It is still giving the same error: >> >> --------------------- >> 2015-02-24T21:40:54Z DEBUG Process finished, return code=1 >> 2015-02-24T21:40:54Z DEBUG stdout=Loading deployment configuration from >> /tmp/tmpR56_Ck. >> Installing CA into /var/lib/pki/pki-tomcat. >> Storing deployment configuration into >> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. >> Installation failed. >> >> >> 2015-02-24T21:40:54Z DEBUG stderr=pkispawn : WARNING ....... unable >> to validate security domain user/password through REST interface. >> Interface not available > > That is expected. > >> pkispawn : ERROR ....... Exception from Java Configuration >> Servlet: Error while updating security domain: java.io.IOException: 2 > > I think a fresh set of logs is in needed. > > rob > >> --------------------. >> >> On 02/24/2015 06:06 PM, Rob Crittenden wrote: >>> West, Jani wrote: >>>> Thank you for the tip, >>>> >>>> Just created new /root/cacerts.p12. Should I import it to the CA somehow >>>> or just restart the ipa server? >>>> >>>> Will reset the new replicate vm to clean CentOS 7 installation without >>>> any leftovers from ipa-replica-install. >>>> >>> >>> Re-run ipa-replica-prepare and it will pick up the new file. Use that >>> newly prepared file on your replica and hopefully that will do the trick. >>> >>> rob >>> >> >> -- -- Jani West -- jwest at iki.fi -- +358 40 5010914 -- -- Liinalahdentie 4 -- 01800 KLAUKKALA -- FINLAND -- "Haluaisin, ett? Suomi olisi paljon monikulttuurisempi. T?nne tulee muualta paljon ihmisi?, mutta heit? ei tuoda tarpeeksi esille. Jotenkin me pid?mme heid?t verhojen takana. On t?rke??, ett? Suomesta saataisiin avoin ja suvaitsevainen. Sulkeutunut ajattelutapa on Suomen ongelma. Ehk? me pelk??mme mielenosoituksia, joita esimerkiksi Ruotsin l?hi?iss? on ollut ja sit?, ett? jotain kauheaa tapahtuu. Ei ymm?rret?, ett? maahanmuuttajat voivat tuoda Suomeen my?s paljon hyv??. Toivoisin hallitukselta sit?, ett? koko kansaa kuullaan, my?s eri kulttuureista tulevia. Hallituksen pit?isi rahoittaa ja tukea enemm?n Suomen kansainv?list?mist?. My?s eduskunta voisi kuunnella maahanmuuttajia enemm?n." HS 8.6.2013: Essi, 16 v. Etu-T??l?n lukio. From rcritten at redhat.com Tue Feb 24 22:27:07 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Feb 2015 17:27:07 -0500 Subject: [Freeipa-users] Migration fails from 3.0.0 to 3.3.3 on Centos 6/7 In-Reply-To: <54ECF65E.1090805@iki.fi> References: <54E5FC3D.3070904@iki.fi> " <54E60BF5.7@redhat.com>" <54E60DB5.7080206@redhat.com> "\"<54E61137.5030906@iki.fi>" " <54E66C9E.7010105@redhat.com> <1d33952d513a47857439feaf0658901a@westi.foo> <54EC9379.3090502@redhat.com> <54ECA190.8010804@redhat.com> <54ECF13C.7060209@iki.fi> <54ECF47D.2030405@redhat.com> <54ECF65E.1090805@iki.fi> Message-ID: <54ECFABB.9020002@redhat.com> Jani West wrote: > On old master apache logs looks like this: > > --------------- > [Tue Feb 24 23:37:40 2015] [error] [client 192.168.177.8] File does not > exist: /var/www/html/ca > [Tue Feb 24 23:37:41 2015] [error] [client 192.168.177.8] File does not > exist: /var/www/html/ca > [Tue Feb 24 23:38:22 2015] [error] [client 192.168.177.8] File does not > exist: /var/www/html/ca > 192.168.177.8 - - [24/Feb/2015:10:35:47 +0200] "POST > /ca/agent/ca/updateDomainXML HTTP/1.0" 403 323 > 192.168.177.8 - - [24/Feb/2015:23:37:40 +0200] "GET > /ca/rest/securityDomain/domainInfo HTTP/1.1" 404 325 > 192.168.177.8 - - [24/Feb/2015:23:37:41 +0200] "GET > /ca/admin/ca/getDomainXML HTTP/1.1" 200 1158 > 192.168.177.8 - - [24/Feb/2015:23:37:41 +0200] "GET > /ca/rest/account/login HTTP/1.1" 404 313 > 192.168.177.8 - - [24/Feb/2015:23:38:19 +0200] "POST > /ca/admin/ca/getCertChain HTTP/1.0" 200 1410 > 192.168.177.8 - - [24/Feb/2015:23:38:22 +0200] "GET > /ca/rest/account/login HTTP/1.1" 404 313 > 192.168.177.8 - - [24/Feb/2015:23:38:22 +0200] "POST > /ca/admin/ca/getCookie HTTP/1.1" 200 4088 > 192.168.177.8 - - [24/Feb/2015:23:38:22 +0200] "POST > /ca/admin/ca/getDomainXML HTTP/1.0" 200 1158 > 192.168.177.8 - - [24/Feb/2015:23:38:23 +0200] "POST > /ca/admin/ca/getCertChain HTTP/1.0" 200 1410 > 192.168.177.8 - - [24/Feb/2015:23:38:23 +0200] "POST > /ca/admin/ca/updateNumberRange HTTP/1.0" 404 - > 192.168.177.8 - - [24/Feb/2015:23:38:24 +0200] "POST > /ca/admin/ca/updateNumberRange HTTP/1.0" 404 - > 192.168.177.8 - - [24/Feb/2015:23:38:23 +0200] "POST > /ca/ee/ca/updateNumberRange HTTP/1.0" 200 163 > 192.168.177.8 - - [24/Feb/2015:23:38:24 +0200] "POST > /ca/ee/ca/updateNumberRange HTTP/1.0" 200 163 > 192.168.177.8 - - [24/Feb/2015:23:38:27 +0200] "POST > /ca/admin/ca/updateNumberRange HTTP/1.0" 404 - > 192.168.177.8 - - [24/Feb/2015:23:38:27 +0200] "POST > /ca/ee/ca/updateNumberRange HTTP/1.0" 200 153 > 192.168.177.8 - - [24/Feb/2015:23:38:30 +0200] "POST > /ca/admin/ca/getConfigEntries HTTP/1.0" 200 13714 > 192.168.177.8 - - [24/Feb/2015:23:41:06 +0200] "POST > /ca/admin/ca/getDomainXML HTTP/1.0" 200 1158 > 192.168.177.8 - - [24/Feb/2015:23:41:06 +0200] "POST > /ca/admin/ca/updateDomainXML HTTP/1.0" 404 - > 192.168.177.8 - - [24/Feb/2015:23:41:06 +0200] "POST > /ca/agent/ca/updateDomainXML HTTP/1.0" 200 115 > --------------------- > > and /var/log/ipareplica-install.log on new replica looks like this: > -------------------- > pkispawn : ERROR ....... Exception from Java Configuration > Servlet: Error while updating security domain: java.io.IOException: 2 > > 2015-02-24T21:40:54Z CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmpR56_Ck' returned non-zero exit > status 1 > 2015-02-24T21:40:54Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 638, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-replica-install", line 667, in main > CA = cainstance.install_replica_ca(config) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 1689, in install_replica_ca > subject_base=config.subject_base) > > 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/install/service.py", > line 364, in start_creation > method() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 615, in __spawn_instance > raise RuntimeError('Configuration of CA failed') > > 2015-02-24T21:40:54Z DEBUG The ipa-replica-install command failed, > exception: RuntimeError: Configuration of CA failed > -------------------- > > Just give me a shout if you want me to run replication again and if you > need any extra logs. The full ipaserver-install.log and /var/log/pki/pki-tomcat/ca/debug would be handy. Feel free to send them to me directly as they are probably rather large. rob > > > On 02/25/2015 12:00 AM, Rob Crittenden wrote: >> Jani West wrote: >>> Re-created replication file and run ipa-replica-install o fresh CentOS 7 >>> server. >>> >>> It is still giving the same error: >>> >>> --------------------- >>> 2015-02-24T21:40:54Z DEBUG Process finished, return code=1 >>> 2015-02-24T21:40:54Z DEBUG stdout=Loading deployment configuration from >>> /tmp/tmpR56_Ck. >>> Installing CA into /var/lib/pki/pki-tomcat. >>> Storing deployment configuration into >>> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. >>> Installation failed. >>> >>> >>> 2015-02-24T21:40:54Z DEBUG stderr=pkispawn : WARNING ....... unable >>> to validate security domain user/password through REST interface. >>> Interface not available >> >> That is expected. >> >>> pkispawn : ERROR ....... Exception from Java Configuration >>> Servlet: Error while updating security domain: java.io.IOException: 2 >> >> I think a fresh set of logs is in needed. >> >> rob >> >>> --------------------. >>> >>> On 02/24/2015 06:06 PM, Rob Crittenden wrote: >>>> West, Jani wrote: >>>>> Thank you for the tip, >>>>> >>>>> Just created new /root/cacerts.p12. Should I import it to the CA >>>>> somehow >>>>> or just restart the ipa server? >>>>> >>>>> Will reset the new replicate vm to clean CentOS 7 installation without >>>>> any leftovers from ipa-replica-install. >>>>> >>>> >>>> Re-run ipa-replica-prepare and it will pick up the new file. Use that >>>> newly prepared file on your replica and hopefully that will do the >>>> trick. >>>> >>>> rob >>>> >>> >>> > > From Less at imagine-sw.com Wed Feb 25 02:11:48 2015 From: Less at imagine-sw.com (Les Stott) Date: Wed, 25 Feb 2015 02:11:48 +0000 Subject: [Freeipa-users] ipa-getcert list fails to report correctly - RESOLVED Message-ID: <4ED173A868981548967B4FCA27072226280C401C@AACMBXP04.exchserver.com> > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Les Stott > Sent: Monday, 23 February 2015 8:01 PM > To: Rob Crittenden; Martin Kosek; freeipa-users at redhat.com; Endi Dewata; > Jan Cholasta > Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly > > > > > -----Original Message----- > > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > > bounces at redhat.com] On Behalf Of Les Stott > > Sent: Monday, 23 February 2015 12:18 PM > > To: Rob Crittenden; Martin Kosek; freeipa-users at redhat.com; Endi > > Dewata; Jan Cholasta > > Subject: Re: [Freeipa-users] ipa-getcert list fails to report > > correctly > > > > > > > > > -----Original Message----- > > > From: Rob Crittenden [mailto:rcritten at redhat.com] > > > Sent: Saturday, 21 February 2015 1:39 AM > > > To: Martin Kosek; Les Stott; freeipa-users at redhat.com; Endi Dewata; > > > Jan Cholasta > > > Subject: Re: [Freeipa-users] ipa-getcert list fails to report > > > correctly > > > > > > Martin Kosek wrote: > > > > On 02/20/2015 06:56 AM, Les Stott wrote: > > > >> Hi all, > > > >> > > > >> The following is blocking the ability for me to install a CA replica. > > > >> > > > >> Environment: > > > >> > > > >> RHEL 6.6 > > > >> > > > >> IPA 3.0.0-42 > > > >> > > > >> PKI 9.0.3-38 > > > >> > > > >> On the master the following is happening: > > > >> > > > >> ipa-getcert list > > > >> > > > >> Number of certificates and requests being tracked: 5. > > > >> > > > >> (but it shows no certificate details in the output) > > > >> > > > >> Running "getcert list" shows complete output. > > > >> > > > >> Also, when trying to browse > > > >> https://master.mydomain.com/ca/ee/ca/getCertChain i get a failed > > > >> response. The apache error logs on the master show.... > > > >> > > > >> [Thu Feb 19 23:23:23 2015] [error] SSL Library Error: -12271 SSL > > > >> client cannot verify your certificate > > > >> > > > >> The reason I am trying to browse that address is because that's > > > >> what the ipa-ca-install setup is failing at (it complains that > > > >> the CA certificate is not in proper format, in fact it's not able > > > >> to get it at all). > > > >> > > > >> I know from another working ipa setup that .... > > > >> > > > >> Browsing to the above address provides valid xml content and > > > >> ipa-getcert list shows certificate details and not just the > > > >> number of tracked certificates. > > > >> > > > >> Been trying for a long time to figure out the issues without luck. > > > >> > > > >> I would greatly appreciate any help to troubleshoot and resolve > > > >> the above issues. > > > >> > > > >> Regards, > > > >> > > > >> Les > > > > > > > > Endi or JanC, would you have any advise for Les? To me, it looks > > > > like the Apache does not have proper certificate installed. > > > > > > > > My ipa-getcert on RHEL-6.6 shows 3 Server-Certs tracked, making it > > > > in total of 8 certs tracked: > > > > > > > > # ipa-getcert list > > > > Number of certificates and requests being tracked: 8. > > > > Request ID '20141111000002': > > > > status: MONITORING > > > > stuck: no > > > > key pair storage: > > > > type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- > > > COM',nicknam > > > > e='Server-Cert',token='NSS > > > > Certificate > > > > DB',pinfile='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/pwdfile.txt' > > > > certificate: > > > > type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- > > > COM',nicknam > > > > e='Server-Cert',token='NSS > > > > Certificate DB' > > > > CA: IPA > > > > issuer: CN=Certificate Authority,O=EXAMPLE.COM > > > > subject: CN=vm-086.example.com,O=EXAMPLE.COM > > > > expires: 2016-11-11 00:00:01 UTC > > > > key usage: > > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > > eku: id-kp-serverAuth,id-kp-clientAuth > > > > pre-save command: > > > > post-save command: > > > > track: yes > > > > auto-renew: yes > > > > Request ID '20141111000047': > > > > status: MONITORING > > > > stuck: no > > > > key pair storage: > > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server- > Cert' > > > > ,token='NSS Certificate > > > > DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' > > > > certificate: > > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server- > Cert' > > > > ,token='NSS > > > > Certificate DB' > > > > CA: IPA > > > > issuer: CN=Certificate Authority,O=EXAMPLE.COM > > > > subject: CN=vm-086.example.com,O=EXAMPLE.COM > > > > expires: 2016-11-11 00:00:46 UTC > > > > key usage: > > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > > eku: id-kp-serverAuth,id-kp-clientAuth > > > > pre-save command: > > > > post-save command: > > > > track: yes > > > > auto-renew: yes > > > > Request ID '20141111000302': > > > > status: MONITORING > > > > stuck: no > > > > key pair storage: > > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',toke > > > > n= 'N SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > > certificate: > > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',toke > > > > n= > > > > 'N > > > > SS > > > > Certificate DB' > > > > CA: IPA > > > > issuer: CN=Certificate Authority,O=EXAMPLE.COM > > > > subject: CN=vm-086.example.com,O=EXAMPLE.COM > > > > expires: 2016-11-11 00:03:02 UTC > > > > key usage: > > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > > eku: id-kp-serverAuth,id-kp-clientAuth > > > > pre-save command: > > > > post-save command: > > > > track: yes > > > > auto-renew: yes > > > > > > > > > > > > What is actually in your Apache NSS database? > > > > > > > > # certutil -L -d /etc/httpd/alias/ > > > > > > > > Martin > > > > > > > > > > Remember ipa-getcert is just a shortcut for certificates using the > > > certmonger CA named IPA, so it's more a filter than anything else. I > > > don't know why it wouldn't display any output but I'd file a bug. > > > > > > I think we'd need to see the getcert list output to try to figure > > > out what is going on. > > > > > > As for the SSL error fetching the cert chain I think Martin may be > > > onto something. The request is proxied through Apache. I think the > > > client here might be the Apache proxy client. > > > > > > I believe this command replicates what Apache is doing, you might > > > give it a try on the master. This will get the chain directly from > > > dogtag, bypassing > > > Apache: > > > > > > $ curl -v --cacert /etc/ipa/ca.crt > > > https://`hostname`:9444/ca/ee/ca/getCertChain > > > > > > rob > > > > Certutil shows.... > > > > certutil -L -d /etc/httpd/alias/ > > > > Certificate Nickname Trust Attributes > > > > SSL,S/MIME,JAR/XPI > > > > MYDOMAIN.COM IPA CA CT,C,C > > ipaCert u,u,u > > Signing-Cert u,u,u > > Server-Cert u,u,u > > > > curl -v --cacert /etc/ipa/ca.crt > > https://`hostname`:9444/ca/ee/ca/getCertChain > > * About to connect() to `hostname` port 9444 (#0) > > * Trying 192.168.1.1... connected > > * Connected to `hostname` (192.168.1.1) port 9444 (#0) > > * Initializing NSS with certpath: sql:/etc/pki/nssdb > > * CAfile: /etc/ipa/ca.crt > > CApath: none > > * SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA > > * Server certificate: > > * subject: CN=`hostname`,O=MYDOMAIN.COM > > * start date: Dec 13 01:21:30 2013 GMT > > * expire date: Dec 03 01:21:30 2015 GMT > > * common name: `hostname` > > * issuer: CN=Certificate Authority,O=MYDOMAIN.COM > > > GET /ca/ee/ca/getCertChain HTTP/1.1 > > > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 > > > NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > > > Host: `hostname`:9444 > > > Accept: */* > > > > > < HTTP/1.1 200 OK > > < Server: Apache-Coyote/1.1 > > < Content-Type: application/xml > > < Content-Length: 1434 > > < Date: Mon, 23 Feb 2015 01:04:29 GMT > > < > > > > standalone="no"?>0MIID > > > zwYJKoZIhvcNAQcCoIIDwDCCA7wCAQExADAPBgkqhkiG9w0BBwGgAgQAoII > > > DoDCCA5wwggKEoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwOjEYMBYGA1U > > > EChMPREVSSVZBVElWRVMuQ09NMR4wHAYDVQQDExVDZXJ0aWZpY2F0ZSB > > > BdXRob3JpdHkwHhcNMTMxMjEzMDEyMTI5WhcNMzMxMjEzMDEyMTI5Wj > > > A6MRgwFgYDVQQKEw9ERVJJVkFUSVZFUy5DT00xHjAcBgNVBAMTFUNlcnRp > > > ZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCg > > > gEBAMAA8EaYhmpjSA8o3/1kB/W1+0K6+FrwCS+njOgRtXhiTdmtSddXSDVxH > > > OafFwqN26BR+QRPZbbpJY70gP3SG8W+J6+c37PMVNshWz6UfChGt6ubgFxlS > > > TGUUre2Osr9I4C836MXpGJvRx2VDEuMUxv8j7B9iDRnTDglseqPqrMct2No4w > > > k4cLtA9puBJb0Es76SOHP9edXlf6GBnuYwR8YMc1yJLqpP8IGpHhEkVxMsRpqk > > > EpuuRwEFa7uBcTDhqVV24BpFlseZVubpiOdEgfb3IRBTjvI1Mum9OCJbuj9P/W > > > mqMnrA0sQsmF/R3WBwFdMAsN3+bQCRw73+rwoeDNcCAwEAAaOBrDCBq > > > TAfBgNVHSMEGDAWgBSO8J+j2jAuyg3a0yE+3oVCQJCWUTAPBgNVHRMBAf8 > > > EBTADAQH/MA4GA1UdDwEB/wQEAwIBxjAdBgNVHQ4EFgQUjvCfo9owLsoN > > > 2tMhPt6FQkCQllEwRgYIKwYBBQUHAQEEOjA4MDYGCCsGAQUFBzABhipodHR > > wOi8vc2I! > > ybW9uMDEuZGVyaXZhdGl2ZXMuY29tOjgwL2* Connection #0 to host > `hostname` > > left intact > > * Closing connection #0 > > > NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAKH8YkoTAzX2xNYMkZSDK84EK3 > > > e4FUixdXxc/EC5ehjrtaqXT1KT9Fl9DAF5/jYNKqgmEmtHnPGlfQ7/Y1ESdhEGcB > > > ZjU4qLe4HaFXuw5c9odDYxhtjQUd1g7ifY8SKOcHDCY+6Xx6F/rhFgzrXXMndn8 > > > ZaYryctPoOAj/5INnLrJq8S4XyLmb2BHM4e1ORQbOhDi8xjhfK2veYXvIu55Brhp > > > RSS/goz5oSE8e+QE/H9afRmeV2+WkS/YDhSyoUDb7CYjklRuONzX3GopKtp1y > > > yLXQZnBFjCvIJvja0mo3ik3AXxSZuOwUIlV23U8CyPU/rDeiV00iUyA/fLvdkEtZkx > > AA== > > > > > > In any event, I've decided to rebuilt my DR IPA environment. Late last > > year the master in DR had to be rebuilt due to a disk issue. While IPA > > was restored manually and appeared to be working fine, CA replication > > hasn't worked. I finally got CA replication working in Prod after > > enabling needed apache modules and performing a yum update to update > > related packages, but these things didn't help in DR. It's my strong > > suspicion that something got missed when restoring the DR master IPA > > server and this is what is causing all my grief. Therefore, I'm going to wipe it > out and start from scratch in DR. > > There are other benefits for me to do this anyway. > > > > Well things have gone from bad to worse. > > I removed IPA in DR. uninstalled all ipa clients, uninstalled replicas, removed > replication agreements and removed the master. Ran pki-remove to clear > any leftover pki instances and used certutil -D to remove left behind ipa > entries in /etc/httpd/alias. > > So, clean slate to start again. > > This time, in order to mirror config with prod, I began an installation for the > master on a different server, let's call it serverb. It was previously a replica (in > my prod environment, serverb is the true master, servera, serverc, and > serverd are replicas). > > So, trying to install a new fresh instance of IPA and it still fails to configure a > CA. > > Attached is the relevant portion of the server install log file (ipa-server- > install.txt). I have removed certificate and copyright info to reduce its size. > Also my server to install is serverb.mydomain.com > > Apache logs at the time of the error show: > [Mon Feb 23 03:05:31 2015] [error] SSL Library Error: -12195 Peer does not > recognize and trust the CA that issued your certificate > > Certificate databases only show the following (note that "Server-Cert cert- > pki-ca" got installed before the installer crashed). Prior to trying installation I > had to manually remove server certs left behind from the previous > installation via ... > certutil -d /etc/httpd/alias -D -n "Server-Cert" > certutil -d /etc/httpd/alias -D -n "MYDOMAIN.COM IPA CA" > certutil -d /etc/httpd/alias -D -n ipaCert > > certutil -L -d /var/lib/pki-ca/alias > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > Server-Cert cert-pki-ca CTu,Cu,Cu > > certutil -L -d /etc/pki/nssdb > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > > > Selinux is in permissive mode. > Ausearch -m avc does show some selinux issues, but its permissive mode so > it should be ok right? In any event I have previously tried installing a CA > replica with selinux disabled and it didn't help. > > I have tried removing ipa and pki rpms and reinstalling. Then rerunning the > ipa server install script but the same error occurs. > > I noticed that /etc/ipa/ca.crt was still old, and referencing the original master. > I removed that and again reran the installer but the same error occurred. > > Note also that /etc/ipa/cr.crt was not recreated when ipa-python was > reinstalled. > > Other logs: > > /var/log/pki-ca/system shows > 5042.main - [23/Feb/2015:03:05:12 EST] [3] [3] Cannot build CA chain. Error > java.security.cert.CertificateException: Certificate is not a PKCS #11 > certificate 5042.main - [23/Feb/2015:03:05:12 EST] [13] [3] authz instance > DirAclAuthz initialization failed and skipped, error=Property > internaldb.ldapconn.port missing value > 5042.http-9445-1 - [23/Feb/2015:03:05:26 EST] [3] [3] Cannot build CA chain. > Error java.security.cert.CertificateException: Certificate is not a PKCS #11 > certificate > 5042.http-9445-1 - [23/Feb/2015:03:05:35 EST] [3] [3] CASigningUnit: Object > certificate not found. Error org.mozilla.jss.crypto.ObjectNotFoundException > > /var/log/pki-ca/catalina.out > Feb 23, 2015 3:05:11 AM org.apache.catalina.startup.HostConfig > deployDirectory > INFO: Deploying web application directory ca 64-bit osutil library loaded 64-bit > osutil library loaded CMS Warning: FAILURE: Cannot build CA chain. Error > java.security.cert.CertificateException: Certificate is not a PKCS #11 > certificate|FAILURE: authz instance DirAclAuthz initialization failed and > skipped, error=Property internaldb.ldapconn.port missing value| Server is > started. > Feb 23, 2015 3:05:12 AM org.apache.coyote.http11.Http11Protocol start > INFO: Starting Coyote HTTP/1.1 on http-9180 Feb 23, 2015 3:05:12 AM > org.apache.coyote.http11.Http11Protocol start > INFO: Starting Coyote HTTP/1.1 on http-9443 Feb 23, 2015 3:05:12 AM > org.apache.coyote.http11.Http11Protocol start > INFO: Starting Coyote HTTP/1.1 on http-9445 Feb 23, 2015 3:05:12 AM > org.apache.coyote.http11.Http11Protocol start > INFO: Starting Coyote HTTP/1.1 on http-9444 Feb 23, 2015 3:05:12 AM > org.apache.coyote.http11.Http11Protocol start > INFO: Starting Coyote HTTP/1.1 on http-9446 Feb 23, 2015 3:05:12 AM > org.apache.jk.common.ChannelSocket init > INFO: JK: ajp13 listening on /0.0.0.0:9447 Feb 23, 2015 3:05:12 AM > org.apache.jk.server.JkMain start > INFO: Jk running ID=0 time=0/25 config=null Feb 23, 2015 3:05:12 AM > org.apache.catalina.startup.Catalina start > INFO: Server startup in 1655 ms > > I have no idea where to look next. There must be some remnant of the old > system hanging around screwing things up but I cannot figure it out. This will > drive me insane! > > I can provide more logs if needed. > > Thanks in advance for any help. > Have resolved this. Here is the procedure to completely remove FreeIPA so you can start again. ipa-server-install --uninstall certutil -d /etc/httpd/alias -D -n "Server-Cert" certutil -d /etc/httpd/alias -D -n "DERIVATIVES.COM IPA CA" certutil -d /etc/httpd/alias -D -n ipaCert certutil -d /etc/httpd/alias -D -n Signing-Cert yum -y remove pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools ipa-server-selinux ipa-server ipa-client ipa-admintools ipa-python ipa-pki-ca-theme ipa-pki-common-theme 389-ds-base 389-ds-base-libs userdel pkisrv userdel pkiuser rm -rf /etc/pki-ca /var/lib/pki-ca /var/log/pki-ca /etc/certmonger /etc/sysconfig/pki-ca /etc/sysconfig/pki /var/run/pki-ca.pid /usr/share/pki /etc/ipa /var/log/ipa* reboot Now you have a clean slate. Then install works as normal for IPA Server, Replica and CA Replica installations. Hope this saves someone else time in the future. Regards, Les From Less at imagine-sw.com Wed Feb 25 02:14:41 2015 From: Less at imagine-sw.com (Les Stott) Date: Wed, 25 Feb 2015 02:14:41 +0000 Subject: [Freeipa-users] bug in pki during install of CA replica and workaround/solution - RESOLVED Message-ID: <4ED173A868981548967B4FCA27072226280C402D@AACMBXP04.exchserver.com> Have resolved the issues below by completely removing FreeIPA and starting from scratch. Here is the procedure to completely remove FreeIPA so you can start again. ipa-server-install --uninstall certutil -d /etc/httpd/alias -D -n "Server-Cert" certutil -d /etc/httpd/alias -D -n "MYDOMAIN.COM IPA CA" certutil -d /etc/httpd/alias -D -n ipaCert certutil -d /etc/httpd/alias -D -n Signing-Cert yum -y remove pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools ipa-server-selinux ipa-server ipa-client ipa-admintools ipa-python ipa-pki-ca-theme ipa-pki-common-theme 389-ds-base 389-ds-base-libs userdel pkisrv userdel pkiuser rm -rf /etc/pki-ca /var/lib/pki-ca /var/log/pki-ca /etc/certmonger /etc/sysconfig/pki-ca /etc/sysconfig/pki /var/run/pki-ca.pid /usr/share/pki /etc/ipa /var/log/ipa* reboot Now you have a clean slate. Then install works as normal for IPA Server, Replica and CA Replica installations. Hope this saves someone else time in the future. Regards, Les > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Les Stott > Sent: Wednesday, 18 February 2015 6:27 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] bug in pki during install of CA replica and > workaround/solution > > Has anyone got any ideas on the below errors I am now receiving? > > Thanks in advance, > > Les > > > > > > > I will test this out (update to 3.7.19-260) next week as I've got a > > > few more CA replicas to setup. > > > > > > > I'm still having issues. Different one this time. > > > > As I have previously worked around the install of CA replicas in my > > production Production environment as above, I went to setup CA > > replication in DR (both environments are completely separate). > > > > Make sure I did a yum update for all packages, including > > selinux-policy, and also making sure all needed modules were loaded in > > httpd.conf I proceeded to retry installation of CA replication. However, it > failed with the following: > > > > Note: sb2sys01.domain.com is the replica I am trying to install.... > > > > (abbreviated below) > > > > ############################################# > > Attempting to connect to: sb2sys01.domain.com:9445 Connected. > > Posting Query = > > > https://sb2sys01.domain.com:9445//ca/admin/console/config/wizard?p=7& > > op=next&xml=true&__password=XXXXXXXX&path=ca.p12 > > RESPONSE STATUS: HTTP/1.1 200 OK > > RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: > > Content-Type: application/xml;charset=UTF-8 RESPONSE HEADER: Date: > > Fri, > > 13 Feb 2015 08:09:35 GMT RESPONSE HEADER: Connection: close > version="1.0" encoding="UTF-8"?> > > > > > > admin/console/config/restorekeycertpanel.vm > > > > failure > > > > The pkcs12 file is not correct. > > 19 > > Error in RestoreKeyCertPanel(): updateStatus returns failure > > ERROR: ConfigureCA: RestoreKeyCertPanel() failure > > ERROR: unable to create CA > > > > ############################################ > > > > In /var/log/pki-ca/catalina.out I see... > > > > CMS Warning: FAILURE: Cannot build CA chain. Error > > java.security.cert.CertificateException: Certificate is not a PKCS #11 > > certificate|FAILURE: authz instance DirAclAuthz initialization failed > > certificate|and > > skipped, error=Property internaldb.ldapconn.port missing value| Server > > is started. > > > > Nothing gets populated in /etc/pki-ca/CS.cfg (based on comparison with > > a working system). > > > > grep DirAclAuthz /etc/pki-ca/CS.cfg > > authz.impl.DirAclAuthz.class=com.netscape.cms.authorization.DirAclAuth > > z authz.instance.DirAclAuthz.ldap=internaldb > > authz.instance.DirAclAuthz.pluginName=DirAclAuthz > > authz.instance.DirAclAuthz.ldap._000=## > > authz.instance.DirAclAuthz.ldap._001=## Internal Database > > authz.instance.DirAclAuthz.ldap._002=## > > authz.instance.DirAclAuthz.ldap.basedn= > > authz.instance.DirAclAuthz.ldap.maxConns=15 > > authz.instance.DirAclAuthz.ldap.minConns=3 > > authz.instance.DirAclAuthz.ldap.ldapauth.authtype=BasicAuth > > authz.instance.DirAclAuthz.ldap.ldapauth.bindDN=cn=Directory Manager > > authz.instance.DirAclAuthz.ldap.ldapauth.bindPWPrompt=Internal LDAP > > Database authz.instance.DirAclAuthz.ldap.ldapauth.clientCertNickname= > > authz.instance.DirAclAuthz.ldap.ldapconn.host= > > authz.instance.DirAclAuthz.ldap.ldapconn.port= > > authz.instance.DirAclAuthz.ldap.ldapconn.secureConn=false > > authz.instance.DirAclAuthz.ldap.multipleSuffix.enable=false > > > > The CA cert looks ok to me on the master. It does get copied to the > > replica in /usr/share/ipa/html/ca.crt > > > > I don't see any errors in httpd error or access logs on the master or > > the intended replica. > > > > The ipa-pki-proxy.conf config has the profilesubmit section. > > > > # matches for ee port > > > > "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenI > > > nfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberR > > ange|^/ca/ee/ca/getCRL|^/ca/ee/ca/profileSubmit"> > > > > I can confirm that pki-cad does start (but is unconfigured) and that > > it does listen on port 9445. > > > > # netstat -apn |grep 9445 > > tcp 0 0 :::9445 :::* LISTEN 31264/java > > # service pki-cad status > > pki-ca (pid 31264) is running... [ OK ] > > 'pki-ca' must still be CONFIGURED! > > (see /var/log/pki-ca-install.log) > > > > I am not sure what to try next. > > > > Appreciate any help to get over this error. > > > > Thanks, > > > > Les > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From mkosek at redhat.com Wed Feb 25 11:35:14 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Feb 2015 12:35:14 +0100 Subject: [Freeipa-users] ipa-getcert list fails to report correctly - RESOLVED In-Reply-To: <4ED173A868981548967B4FCA27072226280C401C@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA27072226280C401C@AACMBXP04.exchserver.com> Message-ID: <54EDB372.3010602@redhat.com> On 02/25/2015 03:11 AM, Les Stott wrote: > > >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >> bounces at redhat.com] On Behalf Of Les Stott >> Sent: Monday, 23 February 2015 8:01 PM >> To: Rob Crittenden; Martin Kosek; freeipa-users at redhat.com; Endi Dewata; >> Jan Cholasta >> Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly >> >> >> >>> -----Original Message----- >>> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >>> bounces at redhat.com] On Behalf Of Les Stott >>> Sent: Monday, 23 February 2015 12:18 PM >>> To: Rob Crittenden; Martin Kosek; freeipa-users at redhat.com; Endi >>> Dewata; Jan Cholasta >>> Subject: Re: [Freeipa-users] ipa-getcert list fails to report >>> correctly >>> >>> >>> >>>> -----Original Message----- >>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>> Sent: Saturday, 21 February 2015 1:39 AM >>>> To: Martin Kosek; Les Stott; freeipa-users at redhat.com; Endi Dewata; >>>> Jan Cholasta >>>> Subject: Re: [Freeipa-users] ipa-getcert list fails to report >>>> correctly >>>> >>>> Martin Kosek wrote: >>>>> On 02/20/2015 06:56 AM, Les Stott wrote: >>>>>> Hi all, >>>>>> >>>>>> The following is blocking the ability for me to install a CA replica. >>>>>> >>>>>> Environment: >>>>>> >>>>>> RHEL 6.6 >>>>>> >>>>>> IPA 3.0.0-42 >>>>>> >>>>>> PKI 9.0.3-38 >>>>>> >>>>>> On the master the following is happening: >>>>>> >>>>>> ipa-getcert list >>>>>> >>>>>> Number of certificates and requests being tracked: 5. >>>>>> >>>>>> (but it shows no certificate details in the output) >>>>>> >>>>>> Running "getcert list" shows complete output. >>>>>> >>>>>> Also, when trying to browse >>>>>> https://master.mydomain.com/ca/ee/ca/getCertChain i get a failed >>>>>> response. The apache error logs on the master show.... >>>>>> >>>>>> [Thu Feb 19 23:23:23 2015] [error] SSL Library Error: -12271 SSL >>>>>> client cannot verify your certificate >>>>>> >>>>>> The reason I am trying to browse that address is because that's >>>>>> what the ipa-ca-install setup is failing at (it complains that >>>>>> the CA certificate is not in proper format, in fact it's not able >>>>>> to get it at all). >>>>>> >>>>>> I know from another working ipa setup that .... >>>>>> >>>>>> Browsing to the above address provides valid xml content and >>>>>> ipa-getcert list shows certificate details and not just the >>>>>> number of tracked certificates. >>>>>> >>>>>> Been trying for a long time to figure out the issues without luck. >>>>>> >>>>>> I would greatly appreciate any help to troubleshoot and resolve >>>>>> the above issues. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Les >>>>> >>>>> Endi or JanC, would you have any advise for Les? To me, it looks >>>>> like the Apache does not have proper certificate installed. >>>>> >>>>> My ipa-getcert on RHEL-6.6 shows 3 Server-Certs tracked, making it >>>>> in total of 8 certs tracked: >>>>> >>>>> # ipa-getcert list >>>>> Number of certificates and requests being tracked: 8. >>>>> Request ID '20141111000002': >>>>> status: MONITORING >>>>> stuck: no >>>>> key pair storage: >>>>> type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- >>>> COM',nicknam >>>>> e='Server-Cert',token='NSS >>>>> Certificate >>>>> DB',pinfile='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/pwdfile.txt' >>>>> certificate: >>>>> type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- >>>> COM',nicknam >>>>> e='Server-Cert',token='NSS >>>>> Certificate DB' >>>>> CA: IPA >>>>> issuer: CN=Certificate Authority,O=EXAMPLE.COM >>>>> subject: CN=vm-086.example.com,O=EXAMPLE.COM >>>>> expires: 2016-11-11 00:00:01 UTC >>>>> key usage: >>>>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>>> pre-save command: >>>>> post-save command: >>>>> track: yes >>>>> auto-renew: yes >>>>> Request ID '20141111000047': >>>>> status: MONITORING >>>>> stuck: no >>>>> key pair storage: >>>>> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server- >> Cert' >>>>> ,token='NSS Certificate >>>>> DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' >>>>> certificate: >>>>> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server- >> Cert' >>>>> ,token='NSS >>>>> Certificate DB' >>>>> CA: IPA >>>>> issuer: CN=Certificate Authority,O=EXAMPLE.COM >>>>> subject: CN=vm-086.example.com,O=EXAMPLE.COM >>>>> expires: 2016-11-11 00:00:46 UTC >>>>> key usage: >>>>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>>> pre-save command: >>>>> post-save command: >>>>> track: yes >>>>> auto-renew: yes >>>>> Request ID '20141111000302': >>>>> status: MONITORING >>>>> stuck: no >>>>> key pair storage: >>>>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',toke >>>>> n= 'N SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>>> certificate: >>>>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',toke >>>>> n= >>>>> 'N >>>>> SS >>>>> Certificate DB' >>>>> CA: IPA >>>>> issuer: CN=Certificate Authority,O=EXAMPLE.COM >>>>> subject: CN=vm-086.example.com,O=EXAMPLE.COM >>>>> expires: 2016-11-11 00:03:02 UTC >>>>> key usage: >>>>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>>> pre-save command: >>>>> post-save command: >>>>> track: yes >>>>> auto-renew: yes >>>>> >>>>> >>>>> What is actually in your Apache NSS database? >>>>> >>>>> # certutil -L -d /etc/httpd/alias/ >>>>> >>>>> Martin >>>>> >>>> >>>> Remember ipa-getcert is just a shortcut for certificates using the >>>> certmonger CA named IPA, so it's more a filter than anything else. I >>>> don't know why it wouldn't display any output but I'd file a bug. >>>> >>>> I think we'd need to see the getcert list output to try to figure >>>> out what is going on. >>>> >>>> As for the SSL error fetching the cert chain I think Martin may be >>>> onto something. The request is proxied through Apache. I think the >>>> client here might be the Apache proxy client. >>>> >>>> I believe this command replicates what Apache is doing, you might >>>> give it a try on the master. This will get the chain directly from >>>> dogtag, bypassing >>>> Apache: >>>> >>>> $ curl -v --cacert /etc/ipa/ca.crt >>>> https://`hostname`:9444/ca/ee/ca/getCertChain >>>> >>>> rob >>> >>> Certutil shows.... >>> >>> certutil -L -d /etc/httpd/alias/ >>> >>> Certificate Nickname Trust Attributes >>> >>> SSL,S/MIME,JAR/XPI >>> >>> MYDOMAIN.COM IPA CA CT,C,C >>> ipaCert u,u,u >>> Signing-Cert u,u,u >>> Server-Cert u,u,u >>> >>> curl -v --cacert /etc/ipa/ca.crt >>> https://`hostname`:9444/ca/ee/ca/getCertChain >>> * About to connect() to `hostname` port 9444 (#0) >>> * Trying 192.168.1.1... connected >>> * Connected to `hostname` (192.168.1.1) port 9444 (#0) >>> * Initializing NSS with certpath: sql:/etc/pki/nssdb >>> * CAfile: /etc/ipa/ca.crt >>> CApath: none >>> * SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA >>> * Server certificate: >>> * subject: CN=`hostname`,O=MYDOMAIN.COM >>> * start date: Dec 13 01:21:30 2013 GMT >>> * expire date: Dec 03 01:21:30 2015 GMT >>> * common name: `hostname` >>> * issuer: CN=Certificate Authority,O=MYDOMAIN.COM >>>> GET /ca/ee/ca/getCertChain HTTP/1.1 >>>> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 >>>> NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 >>>> Host: `hostname`:9444 >>>> Accept: */* >>>> >>> < HTTP/1.1 200 OK >>> < Server: Apache-Coyote/1.1 >>> < Content-Type: application/xml >>> < Content-Length: 1434 >>> < Date: Mon, 23 Feb 2015 01:04:29 GMT >>> < >>> >> >> standalone="no"?>0MIID >>> >> zwYJKoZIhvcNAQcCoIIDwDCCA7wCAQExADAPBgkqhkiG9w0BBwGgAgQAoII >>> >> DoDCCA5wwggKEoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwOjEYMBYGA1U >>> >> EChMPREVSSVZBVElWRVMuQ09NMR4wHAYDVQQDExVDZXJ0aWZpY2F0ZSB >>> >> BdXRob3JpdHkwHhcNMTMxMjEzMDEyMTI5WhcNMzMxMjEzMDEyMTI5Wj >>> >> A6MRgwFgYDVQQKEw9ERVJJVkFUSVZFUy5DT00xHjAcBgNVBAMTFUNlcnRp >>> >> ZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCg >>> >> gEBAMAA8EaYhmpjSA8o3/1kB/W1+0K6+FrwCS+njOgRtXhiTdmtSddXSDVxH >>> >> OafFwqN26BR+QRPZbbpJY70gP3SG8W+J6+c37PMVNshWz6UfChGt6ubgFxlS >>> >> TGUUre2Osr9I4C836MXpGJvRx2VDEuMUxv8j7B9iDRnTDglseqPqrMct2No4w >>> >> k4cLtA9puBJb0Es76SOHP9edXlf6GBnuYwR8YMc1yJLqpP8IGpHhEkVxMsRpqk >>> >> EpuuRwEFa7uBcTDhqVV24BpFlseZVubpiOdEgfb3IRBTjvI1Mum9OCJbuj9P/W >>> >> mqMnrA0sQsmF/R3WBwFdMAsN3+bQCRw73+rwoeDNcCAwEAAaOBrDCBq >>> >> TAfBgNVHSMEGDAWgBSO8J+j2jAuyg3a0yE+3oVCQJCWUTAPBgNVHRMBAf8 >>> >> EBTADAQH/MA4GA1UdDwEB/wQEAwIBxjAdBgNVHQ4EFgQUjvCfo9owLsoN >>> >> 2tMhPt6FQkCQllEwRgYIKwYBBQUHAQEEOjA4MDYGCCsGAQUFBzABhipodHR >>> wOi8vc2I! >>> ybW9uMDEuZGVyaXZhdGl2ZXMuY29tOjgwL2* Connection #0 to host >> `hostname` >>> left intact >>> * Closing connection #0 >>> >> NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAKH8YkoTAzX2xNYMkZSDK84EK3 >>> >> e4FUixdXxc/EC5ehjrtaqXT1KT9Fl9DAF5/jYNKqgmEmtHnPGlfQ7/Y1ESdhEGcB >>> >> ZjU4qLe4HaFXuw5c9odDYxhtjQUd1g7ifY8SKOcHDCY+6Xx6F/rhFgzrXXMndn8 >>> >> ZaYryctPoOAj/5INnLrJq8S4XyLmb2BHM4e1ORQbOhDi8xjhfK2veYXvIu55Brhp >>> >> RSS/goz5oSE8e+QE/H9afRmeV2+WkS/YDhSyoUDb7CYjklRuONzX3GopKtp1y >>> >> yLXQZnBFjCvIJvja0mo3ik3AXxSZuOwUIlV23U8CyPU/rDeiV00iUyA/fLvdkEtZkx >>> AA== >>> >>> >>> In any event, I've decided to rebuilt my DR IPA environment. Late last >>> year the master in DR had to be rebuilt due to a disk issue. While IPA >>> was restored manually and appeared to be working fine, CA replication >>> hasn't worked. I finally got CA replication working in Prod after >>> enabling needed apache modules and performing a yum update to update >>> related packages, but these things didn't help in DR. It's my strong >>> suspicion that something got missed when restoring the DR master IPA >>> server and this is what is causing all my grief. Therefore, I'm going to wipe it >> out and start from scratch in DR. >>> There are other benefits for me to do this anyway. >>> >> >> Well things have gone from bad to worse. >> >> I removed IPA in DR. uninstalled all ipa clients, uninstalled replicas, removed >> replication agreements and removed the master. Ran pki-remove to clear >> any leftover pki instances and used certutil -D to remove left behind ipa >> entries in /etc/httpd/alias. >> >> So, clean slate to start again. >> >> This time, in order to mirror config with prod, I began an installation for the >> master on a different server, let's call it serverb. It was previously a replica (in >> my prod environment, serverb is the true master, servera, serverc, and >> serverd are replicas). >> >> So, trying to install a new fresh instance of IPA and it still fails to configure a >> CA. >> >> Attached is the relevant portion of the server install log file (ipa-server- >> install.txt). I have removed certificate and copyright info to reduce its size. >> Also my server to install is serverb.mydomain.com >> >> Apache logs at the time of the error show: >> [Mon Feb 23 03:05:31 2015] [error] SSL Library Error: -12195 Peer does not >> recognize and trust the CA that issued your certificate >> >> Certificate databases only show the following (note that "Server-Cert cert- >> pki-ca" got installed before the installer crashed). Prior to trying installation I >> had to manually remove server certs left behind from the previous >> installation via ... >> certutil -d /etc/httpd/alias -D -n "Server-Cert" >> certutil -d /etc/httpd/alias -D -n "MYDOMAIN.COM IPA CA" >> certutil -d /etc/httpd/alias -D -n ipaCert >> >> certutil -L -d /var/lib/pki-ca/alias >> Certificate Nickname Trust Attributes >> SSL,S/MIME,JAR/XPI >> Server-Cert cert-pki-ca CTu,Cu,Cu >> >> certutil -L -d /etc/pki/nssdb >> Certificate Nickname Trust Attributes >> SSL,S/MIME,JAR/XPI >> >> >> Selinux is in permissive mode. >> Ausearch -m avc does show some selinux issues, but its permissive mode so >> it should be ok right? In any event I have previously tried installing a CA >> replica with selinux disabled and it didn't help. >> >> I have tried removing ipa and pki rpms and reinstalling. Then rerunning the >> ipa server install script but the same error occurs. >> >> I noticed that /etc/ipa/ca.crt was still old, and referencing the original master. >> I removed that and again reran the installer but the same error occurred. >> >> Note also that /etc/ipa/cr.crt was not recreated when ipa-python was >> reinstalled. >> >> Other logs: >> >> /var/log/pki-ca/system shows >> 5042.main - [23/Feb/2015:03:05:12 EST] [3] [3] Cannot build CA chain. Error >> java.security.cert.CertificateException: Certificate is not a PKCS #11 >> certificate 5042.main - [23/Feb/2015:03:05:12 EST] [13] [3] authz instance >> DirAclAuthz initialization failed and skipped, error=Property >> internaldb.ldapconn.port missing value >> 5042.http-9445-1 - [23/Feb/2015:03:05:26 EST] [3] [3] Cannot build CA chain. >> Error java.security.cert.CertificateException: Certificate is not a PKCS #11 >> certificate >> 5042.http-9445-1 - [23/Feb/2015:03:05:35 EST] [3] [3] CASigningUnit: Object >> certificate not found. Error org.mozilla.jss.crypto.ObjectNotFoundException >> >> /var/log/pki-ca/catalina.out >> Feb 23, 2015 3:05:11 AM org.apache.catalina.startup.HostConfig >> deployDirectory >> INFO: Deploying web application directory ca 64-bit osutil library loaded 64-bit >> osutil library loaded CMS Warning: FAILURE: Cannot build CA chain. Error >> java.security.cert.CertificateException: Certificate is not a PKCS #11 >> certificate|FAILURE: authz instance DirAclAuthz initialization failed and >> skipped, error=Property internaldb.ldapconn.port missing value| Server is >> started. >> Feb 23, 2015 3:05:12 AM org.apache.coyote.http11.Http11Protocol start >> INFO: Starting Coyote HTTP/1.1 on http-9180 Feb 23, 2015 3:05:12 AM >> org.apache.coyote.http11.Http11Protocol start >> INFO: Starting Coyote HTTP/1.1 on http-9443 Feb 23, 2015 3:05:12 AM >> org.apache.coyote.http11.Http11Protocol start >> INFO: Starting Coyote HTTP/1.1 on http-9445 Feb 23, 2015 3:05:12 AM >> org.apache.coyote.http11.Http11Protocol start >> INFO: Starting Coyote HTTP/1.1 on http-9444 Feb 23, 2015 3:05:12 AM >> org.apache.coyote.http11.Http11Protocol start >> INFO: Starting Coyote HTTP/1.1 on http-9446 Feb 23, 2015 3:05:12 AM >> org.apache.jk.common.ChannelSocket init >> INFO: JK: ajp13 listening on /0.0.0.0:9447 Feb 23, 2015 3:05:12 AM >> org.apache.jk.server.JkMain start >> INFO: Jk running ID=0 time=0/25 config=null Feb 23, 2015 3:05:12 AM >> org.apache.catalina.startup.Catalina start >> INFO: Server startup in 1655 ms >> >> I have no idea where to look next. There must be some remnant of the old >> system hanging around screwing things up but I cannot figure it out. This will >> drive me insane! >> >> I can provide more logs if needed. >> >> Thanks in advance for any help. >> > > Have resolved this. Great! Thanks for reaching back to us. > Here is the procedure to completely remove FreeIPA so you can start again. To me, that sounds like the FreeIPA uninstaller is missing some clean up steps. I would personally rather resolve it in the the actual code than just having this information in the list archives. > > ipa-server-install --uninstall > certutil -d /etc/httpd/alias -D -n "Server-Cert" > certutil -d /etc/httpd/alias -D -n "DERIVATIVES.COM IPA CA" > certutil -d /etc/httpd/alias -D -n ipaCert > certutil -d /etc/httpd/alias -D -n Signing-Cert This sounds like https://fedorahosted.org/freeipa/ticket/4639. We should bump the priority if it is really causing issues. > yum -y remove pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools ipa-server-selinux ipa-server ipa-client ipa-admintools ipa-python ipa-pki-ca-theme ipa-pki-common-theme 389-ds-base 389-ds-base-libs > userdel pkisrv > userdel pkiuser This should not be needed at all, AFAIK. > rm -rf /etc/pki-ca /var/lib/pki-ca /var/log/pki-ca /etc/certmonger /etc/sysconfig/pki-ca /etc/sysconfig/pki /var/run/pki-ca.pid /usr/share/pki /etc/ipa /var/log/ipa* > reboot > > Now you have a clean slate. Do you know which step of the steps above actually helped you resolve the reinstall issue? > > Then install works as normal for IPA Server, Replica and CA Replica installations. > > Hope this saves someone else time in the future. > > Regards, > > Les From janne.blomqvist at aalto.fi Wed Feb 25 12:44:22 2015 From: janne.blomqvist at aalto.fi (Janne Blomqvist) Date: Wed, 25 Feb 2015 14:44:22 +0200 Subject: [Freeipa-users] AD sync via polling? Message-ID: <54EDC3A6.1030500@aalto.fi> Hi, is it possible to use winsync to sync stuff from AD without having to create domain trusts, or install some kind of sync services on the AD DC's? For some background, we want to fetch user/group info and authenticate against AD (managed by another department), but we also have a need to have some own users/groups on top of the AD ones. So the initial plan would be something like A1. We join a machine to the AD domain, so we can fetch information from AD via getent or ldapsearch. A2. Scripts are written to fetch data from AD on the machine in (1) above, merge and push this user/group data into freeIPA. These scripts run periodically via cron. Clients are configured roughly per the following: B1. sssd on clients is configured to fetch user/group data from freeIPA. B2. pam_krb5 in client machines is configured to authenticate against AD. B3. pam_ldap (or pam_sss, if its use of kerberos doesn't conflict with the configuration for connecting to AD used by pam_krb5?) in client machines is configured to authenticate against freeIPA, for those users who don't have accounts in AD. Yes, I can see this being a lot simpler if we could get a cross domain trust going on between AD and our freeIPA servers or even just the winsync services running on the DC's, but organizational politics being what they are, this isn't happening. :( So my questions are - Can the freeIPA winsync tool bend to providing A2 above, or do we have to do it ourselves? - As this setups is weird and non-standard, will using freeIPA actually help us here, or would life be easier by just using 389 or openldap directly? In essence, our main usage of freeIPA would be to provide management tools for those users/groups which are not synced from AD. - With the constraints above that we have to live with, is there a better way to accomplish this? - Does the thing in B3 work? I.e. can I have pam_krb5 with config in /etc/krb5.conf for connecting to AD, then pam_sss with sssd.conf using the ipa or krb5 auth provider pointing to our freeIPA server(s). Thanks, -- Janne Blomqvist From dpal at redhat.com Wed Feb 25 13:48:28 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 25 Feb 2015 08:48:28 -0500 Subject: [Freeipa-users] AD sync via polling? In-Reply-To: <54EDC3A6.1030500@aalto.fi> References: <54EDC3A6.1030500@aalto.fi> Message-ID: <54EDD2AC.4040103@redhat.com> On 02/25/2015 07:44 AM, Janne Blomqvist wrote: > Hi, > > is it possible to use winsync to sync stuff from AD without having to > create domain trusts, or install some kind of sync services on the AD > DC's? > > For some background, we want to fetch user/group info and authenticate > against AD (managed by another department), but we also have a need to > have some own users/groups on top of the AD ones. So the initial plan > would be something like > > A1. We join a machine to the AD domain, so we can fetch information > from AD via getent or ldapsearch. > > A2. Scripts are written to fetch data from AD on the machine in (1) > above, merge and push this user/group data into freeIPA. These scripts > run periodically via cron. > > Clients are configured roughly per the following: > > B1. sssd on clients is configured to fetch user/group data from freeIPA. > > B2. pam_krb5 in client machines is configured to authenticate against AD. > > B3. pam_ldap (or pam_sss, if its use of kerberos doesn't conflict with > the configuration for connecting to AD used by pam_krb5?) in client > machines is configured to authenticate against freeIPA, for those > users who don't have accounts in AD. > > Yes, I can see this being a lot simpler if we could get a cross domain > trust going on between AD and our freeIPA servers or even just the > winsync services running on the DC's, but organizational politics > being what they are, this isn't happening. :( > > So my questions are > > - Can the freeIPA winsync tool bend to providing A2 above, or do we > have to do it ourselves? > > - As this setups is weird and non-standard, will using freeIPA > actually help us here, or would life be easier by just using 389 or > openldap directly? In essence, our main usage of freeIPA would be to > provide management tools for those users/groups which are not synced > from AD. > > - With the constraints above that we have to live with, is there a > better way to accomplish this? > > - Does the thing in B3 work? I.e. can I have pam_krb5 with config in > /etc/krb5.conf for connecting to AD, then pam_sss with sssd.conf using > the ipa or krb5 auth provider pointing to our freeIPA server(s). > > > Thanks, You can use SSSD and define two domains one for AD and one for IPA. You join machine to IPA to at least take advantage of what it provides for objects you manage but use AD as a second domain in SSSD configuration. You do not need to sync anything or use pam_krb5/pam_ldap. So no scripts. You can also decide to join the machine into AD instead but I do not see any benefits from doing it. The only price in this setup is that one of the domains (the second one) would have to use fully qualified user names to log into the system. HTH -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From hugh at psychopig.com Wed Feb 25 08:12:53 2015 From: hugh at psychopig.com (Hugh) Date: Wed, 25 Feb 2015 02:12:53 -0600 Subject: [Freeipa-users] Web UI plugins or other extensions Message-ID: <54ED8405.2030107@psychopig.com> All, We're running ipa-server-3.0.0-42/389-ds-base-1.2.11.15-48 on CentOS 6.5. We've set up synching between our IPA and AD and that seems to be working. What we'd like to do now is allow admins when they're creating users in IPA to be able to set those users up for synching to AD with the web UI without having to drop to the command line or edit LDAP directly. As you know, in order to synch from IPA->AD, you need to add the ntuser objectclass and the ntUserDomainId and ntUserCreateNewAccount attributes. However, those attributes/class are not in the web UI by defauly and from what I can see, our version of ipa-server/DS does not have support for web UI plugins. Is that true? Is there any way to be able to set a user to be synched via the web UI? Thanks, Hugh From rmeggins at redhat.com Wed Feb 25 14:21:16 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 25 Feb 2015 07:21:16 -0700 Subject: [Freeipa-users] AD sync via polling? In-Reply-To: <54EDD2AC.4040103@redhat.com> References: <54EDC3A6.1030500@aalto.fi> <54EDD2AC.4040103@redhat.com> Message-ID: <54EDDA5C.4030201@redhat.com> On 02/25/2015 06:48 AM, Dmitri Pal wrote: > On 02/25/2015 07:44 AM, Janne Blomqvist wrote: >> Hi, >> >> is it possible to use winsync to sync stuff from AD without having to >> create domain trusts, or install some kind of sync services on the AD >> DC's? >> >> For some background, we want to fetch user/group info and >> authenticate against AD (managed by another department), but we also >> have a need to have some own users/groups on top of the AD ones. So >> the initial plan would be something like >> >> A1. We join a machine to the AD domain, so we can fetch information >> from AD via getent or ldapsearch. >> >> A2. Scripts are written to fetch data from AD on the machine in (1) >> above, merge and push this user/group data into freeIPA. These >> scripts run periodically via cron. >> >> Clients are configured roughly per the following: >> >> B1. sssd on clients is configured to fetch user/group data from freeIPA. >> >> B2. pam_krb5 in client machines is configured to authenticate against >> AD. >> >> B3. pam_ldap (or pam_sss, if its use of kerberos doesn't conflict >> with the configuration for connecting to AD used by pam_krb5?) in >> client machines is configured to authenticate against freeIPA, for >> those users who don't have accounts in AD. >> >> Yes, I can see this being a lot simpler if we could get a cross >> domain trust going on between AD and our freeIPA servers or even just >> the winsync services running on the DC's, but organizational politics >> being what they are, this isn't happening. :( >> >> So my questions are >> >> - Can the freeIPA winsync tool bend to providing A2 above, or do we >> have to do it ourselves? >> >> - As this setups is weird and non-standard, will using freeIPA >> actually help us here, or would life be easier by just using 389 or >> openldap directly? In essence, our main usage of freeIPA would be to >> provide management tools for those users/groups which are not synced >> from AD. >> >> - With the constraints above that we have to live with, is there a >> better way to accomplish this? >> >> - Does the thing in B3 work? I.e. can I have pam_krb5 with config in >> /etc/krb5.conf for connecting to AD, then pam_sss with sssd.conf >> using the ipa or krb5 auth provider pointing to our freeIPA server(s). >> >> >> Thanks, > You can use SSSD and define two domains one for AD and one for IPA. > You join machine to IPA to at least take advantage of what it provides > for objects you manage but use AD as a second domain in SSSD > configuration. > You do not need to sync anything or use pam_krb5/pam_ldap. So no scripts. > You can also decide to join the machine into AD instead but I do not > see any benefits from doing it. > The only price in this setup is that one of the domains (the second > one) would have to use fully qualified user names to log into the system. +1 If however you still want to do something with scripts and the Windows AD DirSync control with polling, see https://github.com/richm/scripts/blob/master/dirsyncctrl.py > > HTH > > From pvoborni at redhat.com Wed Feb 25 14:22:36 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 25 Feb 2015 15:22:36 +0100 Subject: [Freeipa-users] Announcing FreeIPA 4.1.3 Message-ID: <54EDDAAC.4080309@redhat.com> The FreeIPA team would like to announce FreeIPA v4.1.3 bug fix release! It can be downloaded from http://www.freeipa.org/page/Downloads . Fedora 21 builds are already on their way to updates-testing repository. Builds for Fedora 20 are available in the official COPR repository [https://copr.fedoraproject.org/coprs/mkosek/freeipa/]. == Highlights in 4.1.3 == === Enhancements === * ID Views support user SSH public keys * ID Views support IPA user overrides * OTP token authentication and synchronization windows are configurable * RADIUS server proxy fields added to user page in Web UI === Bug fixes === * Issues fixed in ipa-restore: ** doesn't crash if replica is unreachable ** checks if it isn't a restore on non matching host ** improved validation of input options to disallow invalid combinations ** doesn't fail if run on a system without IPA installed ** creates correct log directories * certificate renewal process is synchronized * migrate-ds: warns user if compat plugin is enabled * PassSync plugin could not update synchronized users due to too strict access control * replication agreements by Replication Administrators could not be removed due to strict access control * anonymous read of a DUA profile was not possible due to strict access control * various upgrade fixes related to DNSSEC == Upgrading == Upgrade instructions are available on upgrade page [http://www.freeipa.org/page/Upgrade]. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.1.2 == === Alexander Bokovoy (4) === * Support Samba PASSDB 0.2.0 aka interface version 24 * ipa-cldap: support NETLOGON_NT_VERSION_5EX_WITH_IP properly * ipa-kdb: when processing transitions, hand over unknown ones to KDC * ipa-kdb: reject principals from disabled domains as a KDC policy === David Kupka (5) === * Use singular in help metavars + update man pages. * Always add /etc/hosts record when DNS is being configured. * Remove ipanttrustauthincoming/ipanttrustauthoutgoing from ipa trust-add output. * Abort backup restoration on not matching host. * idviews: Allow setting ssh public key on ipauseroverride-add === Gabe Alford (3) === * Remove dependency on subscription-manager * Typos in ipa-rmkeytab options help and man page * permission-add does not prompt for ipapermright in interactive mode === Jan Cholasta (18) === * Fix automatic CA cert renewal endless loop in dogtag-ipa-ca-renew-agent * Do not renew the IPA CA cert by serial number in dogtag-ipa-ca-renew-agent * Improve validation of --instance and --backend options in ipa-restore * Check subject name encoding in ipa-cacert-manage renew * Refer the user to freeipa.org when something goes wrong in ipa-cacert-manage * Fix ipa-restore on systems without IPA installed * Remove RUV from LDIF files before using them in ipa-restore * Fix CA certificate renewal syslog alert * Do not crash on unknown services in installutils.stopped_service * Restart dogtag when its server certificate is renewed * Make certificate renewal process synchronized * Fix validation of ipa-restore options * Do not assume certmonger is running in httpinstance * Put LDIF files to their original location in ipa-restore * Revert "Make all ipatokenTOTP attributes mandatory" * Create correct log directories during full restore in ipa-restore * Do not crash when replica is unreachable in ipa-restore * Bump 389-ds-base and pki-ca dependencies for POODLE fixes === Jan Pazdziora (1) === * No explicit zone specification. === Martin Babinsky (11) === * Moved dbus-python dependence to freeipa-python package * ipa-kdb: unexpected error code in 'ipa_kdb_audit_as_req' triggers a message * always get PAC for client principal if AS_REQ is true * ipa-kdb: more robust handling of principal addition/editing * OTP: failed search for the user of last token emits an error message * ipa-pwd-extop: added an informational comment about intentional fallthrough * ipa-uuid: emit a message when unexpected mod type is encountered * OTP: emit a log message when LDAP entry for config record is not found * ipa-client-install: put eol character after the last line of altered config file(s) * migrate-ds: exit with error message if no users/groups to migrate are found * Changing the token owner changes also the manager === Martin Ba?ti (19) === * Fix zonemgr option encoding detection * Throw zonemgr error message before installation proceeds * Upgrade fix: masking named should be executed only once * Using wget to get status of CA * Show SSHFP record containing space in fingerprint * Fix don't check certificate during getting CA status * Fix: Upgrade forwardzones zones after adding newer replica * Fix zone find during forwardzone upgrade * Fix traceback if zonemgr error contains unicode * DNS tests: separate current forward zone tests * New test cases for Forward_zones * Detect and warn about invalid DNS forward zone configuration * DNS tests: warning if forward zone is inactive * Add debug messages into client autodetection * DNSSEC catch ldap exceptions in ipa-dnskeysyncd * DNSSEC: fix root zone dns name conversion * Always return absolute idnsname in dnszone commands * Use dyndns_update instead of deprecated sssd option * Fix reference counting in pkcs11 extension === Martin Ko?ek (7) === * Bump SSSD Requires to 1.12.3 * Allow PassSync user to locate and update NT users * Allow Replication Administrators manipulate Winsync Agreements * Replication Administrators cannot remove replication agreements * Add anonymous read ACI for DUA profile * Print PublicError traceback when in debug mode * group-detach does not add correct objectclasses === Nathaniel McCallum (7) === * Catch USBError during YubiKey location * Preliminary refactoring of libotp files * Move authentication configuration cache into libotp * Enable last token deletion when password auth type is configured * Make token auth and sync windows configurable * Create an OTP help topic * Prefer TCP connections to UDP in krb5 clients === Petr Voborn?k (10) === * webui: add radius fields to user page * fix indentation in ipa-restore page * add --hosts and --hostgroup options to allow/retrieve keytab methods * webui: fix service unprovisioning * webui: increase duration of notification messages * revert removal of cn attribute from idnsRecord * migrate-ds: fix compat plugin check * rpcclient: use json_encode_binary for verbose output * Fix TOTP Synchronization Window label * Become IPA 4.1.3 === Simo Sorce (3) === * Avoid calling ldap functions without a context * Remove the removal of the ccache * Handle DAL ABI change in MIT 1.13 === Tom?? Babej (9) === * Re-initialize NSS database after otptoken plugin tests * certs: Fix incorrect flag handling in load_cacert * hosts: Display assigned ID view by default in host-find and show commands * idviews: Complain if host is already assigned the ID View in idview-apply * idviews: Ignore host or hostgroup options set to None * baseldap: Handle missing parent objects properly in *-find commands * ipatests: Add coverage for referential integrity plugin applied on ipaAssignedIDView * ipatests: Fix old command references in the ID views tests * ipatests: Fix incorrect assumptions in idviews tests -- Petr Vobornik From edewata at redhat.com Wed Feb 25 14:50:11 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 25 Feb 2015 21:50:11 +0700 Subject: [Freeipa-users] ipa-getcert list fails to report correctly - RESOLVED In-Reply-To: <54EDB372.3010602@redhat.com> References: <4ED173A868981548967B4FCA27072226280C401C@AACMBXP04.exchserver.com> <54EDB372.3010602@redhat.com> Message-ID: <54EDE123.4020207@redhat.com> On 2/25/2015 6:35 PM, Martin Kosek wrote: >> yum -y remove pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools ipa-server-selinux ipa-server ipa-client ipa-admintools ipa-python ipa-pki-ca-theme ipa-pki-common-theme 389-ds-base 389-ds-base-libs >> userdel pkisrv >> userdel pkiuser > > This should not be needed at all, AFAIK. This may not be related to this problem, but sometimes reinstalling the packages is necessary to resolve installation problem. For example: https://fedorahosted.org/freeipa/ticket/4591 In this ticket reinstalling 389-ds-base will recreate the missing folder. -- Endi S. Dewata From pvoborni at redhat.com Wed Feb 25 14:53:22 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 25 Feb 2015 15:53:22 +0100 Subject: [Freeipa-users] Web UI plugins or other extensions In-Reply-To: <54ED8405.2030107@psychopig.com> References: <54ED8405.2030107@psychopig.com> Message-ID: <54EDE1E2.2080705@redhat.com> On 02/25/2015 09:12 AM, Hugh wrote: > All, > > We're running ipa-server-3.0.0-42/389-ds-base-1.2.11.15-48 on CentOS > 6.5. We've set up synching between our IPA and AD and that seems to be > working. What we'd like to do now is allow admins when they're creating > users in IPA to be able to set those users up for synching to AD with > the web UI without having to drop to the command line or edit LDAP > directly. As you know, in order to synch from IPA->AD, you need to add > the ntuser objectclass and the ntUserDomainId and ntUserCreateNewAccount > attributes. However, those attributes/class are not in the web UI by > defauly and from what I can see, our version of ipa-server/DS does not > have support for web UI plugins. Is that true? Is there any way to be > able to set a user to be synched via the web UI? > > Thanks, > > Hugh > Hello Hugh, it could be done in 3.0 by direct manipulation of /usr/share/ipa/ui/user.js Doing that is ugly and breaks on rpm upgrades. IIUC, the goal would be to simulate CLI (API)call: $ ipa user-mod bbar --addattr='objectclass=ntuser' --setattr='ntUserDomainId=foo'--setattr='ntUserDomainId=True' Adding ntUserDomainId and ntUserDomainId is easy - it's just one declaration in the list of fields. But adding the objectclass isn't, Current pattern is that the object classes(which are not added by default) are added in ipalib backend plugin if attribute is present in the mod list for the first time for the object. I would discourage to do that in Web UI. But in theory it can be done. One has to add multivalued field named objectclass and then he can add new ones and delete others. But this is bad UX. Better would be to add the objecclass attr on demand on update but it requires direct modification of update code which is more difficult (don't know it from top of my head). HTH -- Petr Vobornik From smartin at blackducksoftware.com Wed Feb 25 16:59:19 2015 From: smartin at blackducksoftware.com (Shaun Martin) Date: Wed, 25 Feb 2015 16:59:19 +0000 Subject: [Freeipa-users] Forward first not working Message-ID: <6485FD7F-35D0-40BB-81EF-AE79D64FEBB9@blackducksoftware.com> Hi, I am having an issue with the forward first not appear to be working. I have two separate IPA servers that server separate realms. I have for the reverse zone configured forwarders to point to the other realms IPA server. All versions are identical on the IPA servers. I have included details on version and tests that show this is not working. $ yum list installed |grep bind-dyndb-ldap bind-dyndb-ldap.x86_64 3.5-4.el7 @base $ yum list installed |grep ipa ipa-admintools.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-client.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-python.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-server.x86_64 3.3.3-28.0.1.el7.centos.3 @updates libipa_hbac.x86_64 1.11.2-68.el7_0.6 @updates libipa_hbac-python.x86_64 1.11.2-68.el7_0.6 @updates python-iniparse.noarch 0.4-9.el7 @anaconda sssd-ipa.x86_64 BELOW IS WITH FORWARDING DISABLED. It cannot find 10.1.0.9 but can find 10.1.20.9. This is expected as this server only has the 10.1.20.9 record. $ nslookup > server 10.1.20.9 Default server: 10.1.20.9 Address: 10.1.20.9#53 > 10.1.20.9 Server: 10.1.20.9 Address: 10.1.20.9#53 9.20.1.10.in-addr.arpa name = prd-ops-ipa01.uzb.local. > 10.1.0.9 Server: 10.1.20.9 Address: 10.1.20.9#53 ** server can't find 9.0.1.10.in-addr.arpa.: NXDOMAIN BELOW IS WITH FORWARDING ENABLED. It cannot find 10.1.20.9 but can find 10.1.0.9. This is expected as the forwarding server only has the 10.1.0.9 record. > 10.1.20.9 Server: 10.1.20.9 Address: 10.1.20.9#53 ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN > 10.1.0.9 Server: 10.1.20.9 Address: 10.1.20.9#53 Non-authoritative answer: 9.0.1.10.in-addr.arpa name = ops-ipa01.bbf.local. Authoritative answers can be found from: 1.10.in-addr.arpa nameserver = ops-ipa01.bbf.local. BELOW IS WITH FORWARD FIRST ENABLED. It cannot find 10.1.20.9 but can find 10.1.0.9. This is un-expected as the local zone has the 10.1.20.9 and the forward server has the 10.1.0.9 so we should be getting both. > 10.1.20.9 Server: 10.1.20.9 Address: 10.1.20.9#53 ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN > 10.1.0.9 Server: 10.1.20.9 Address: 10.1.20.9#53 Non-authoritative answer: 9.0.1.10.in-addr.arpa name = ops-ipa01.bbf.local. Authoritative answers can be found from: 1.10.in-addr.arpa nameserver = ops-ipa01.bbf.local. ops-ipa01.bbf.local internet address = 10.1.0.9 Any help is greatly appreciated. Thanks, Shaun [cid:1F369212-0E28-4C3C-8955-33CDA7C2FAB4 at blackducksoftware.com] Shaun Martin IT\OPS Manager Black Duck Software O: +1.781.425.4336 Black Duck Software | OpenHUB | OSDelivers | OSS Logistics [cid:CC23E6F1-CA96-4E59-978B-D0D9EDE0F2DB at blackducksoftware.com] [cid:AC8F793C-9870-4ECB-B844-3337F98BA51F at blackducksoftware.com] [cid:AB6B7F6B-C85C-4E52-8B42-9C9A5EB9D0D1 at blackducksoftware.com] [cid:931AE271-12EC-458A-BB1F-7455AD35B154 at blackducksoftware.com] [cid:8EB9FA0C-F1E0-4E32-9E58-0D6A646A5625 at blackducksoftware.com] [cid:1A0AC858-0DCC-44B4-B3D0-8BB35E291B02 at blackducksoftware.com] JP Morgan Chase & Co. Hall of Innovation Inductee -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 7EA68D51-363B-4FAD-A939-D9CD926D70AB.png Type: image/png Size: 3790 bytes Desc: 7EA68D51-363B-4FAD-A939-D9CD926D70AB.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: E33E6B21-2C3E-4C55-8796-46161EE14AC6.png Type: image/png Size: 280 bytes Desc: E33E6B21-2C3E-4C55-8796-46161EE14AC6.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: EDB9C095-85D8-437C-A4CF-A515712839CA.png Type: image/png Size: 248 bytes Desc: EDB9C095-85D8-437C-A4CF-A515712839CA.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8D343C4D-B65C-473A-96DE-792AF2B5D16E.png Type: image/png Size: 227 bytes Desc: 8D343C4D-B65C-473A-96DE-792AF2B5D16E.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 3FCDCA9B-C8EA-4EB2-9184-457FF1A9AB5D.png Type: image/png Size: 335 bytes Desc: 3FCDCA9B-C8EA-4EB2-9184-457FF1A9AB5D.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: D1E6BBB6-3622-496C-B3BF-7DC86A214CB8.png Type: image/png Size: 355 bytes Desc: D1E6BBB6-3622-496C-B3BF-7DC86A214CB8.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: B8FD9DF1-3230-44BF-80DA-AEA16CB00E29.png Type: image/png Size: 316 bytes Desc: B8FD9DF1-3230-44BF-80DA-AEA16CB00E29.png URL: From dpal at redhat.com Wed Feb 25 17:02:58 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 25 Feb 2015 12:02:58 -0500 Subject: [Freeipa-users] Web UI plugins or other extensions In-Reply-To: <54EDE1E2.2080705@redhat.com> References: <54ED8405.2030107@psychopig.com> <54EDE1E2.2080705@redhat.com> Message-ID: <54EE0042.6040509@redhat.com> On 02/25/2015 09:53 AM, Petr Vobornik wrote: > On 02/25/2015 09:12 AM, Hugh wrote: >> All, >> >> We're running ipa-server-3.0.0-42/389-ds-base-1.2.11.15-48 on CentOS >> 6.5. We've set up synching between our IPA and AD and that seems to be >> working. What we'd like to do now is allow admins when they're creating >> users in IPA to be able to set those users up for synching to AD with >> the web UI without having to drop to the command line or edit LDAP >> directly. As you know, in order to synch from IPA->AD, you need to add >> the ntuser objectclass and the ntUserDomainId and ntUserCreateNewAccount >> attributes. However, those attributes/class are not in the web UI by >> defauly and from what I can see, our version of ipa-server/DS does not >> have support for web UI plugins. Is that true? Is there any way to be >> able to set a user to be synched via the web UI? >> >> Thanks, >> >> Hugh >> > > Hello Hugh, > > it could be done in 3.0 by direct manipulation of > /usr/share/ipa/ui/user.js Doing that is ugly and breaks on rpm > upgrades. IIUC, the goal would be to simulate CLI (API)call: > > $ ipa user-mod bbar --addattr='objectclass=ntuser' > --setattr='ntUserDomainId=foo'--setattr='ntUserDomainId=True' > > Adding ntUserDomainId and ntUserDomainId is easy - it's just one > declaration in the list of fields. But adding the objectclass isn't, > > Current pattern is that the object classes(which are not added by > default) are added in ipalib backend plugin if attribute is present in > the mod list for the first time for the object. > > I would discourage to do that in Web UI. But in theory it can be done. > One has to add multivalued field named objectclass and then he can add > new ones and delete others. But this is bad UX. Better would be to add > the objecclass attr on demand on update but it requires direct > modification of update code which is more difficult (don't know it > from top of my head). > > HTH But let us step back and ask the question why do you need to create the users you sync manually first? The users in a specific OU will be synced anyways without you manually creating them in IPA. So this is unclear why the whole thing is actually needed. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From mbasti at redhat.com Wed Feb 25 17:42:29 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Feb 2015 18:42:29 +0100 Subject: [Freeipa-users] Forward first not working In-Reply-To: <6485FD7F-35D0-40BB-81EF-AE79D64FEBB9@blackducksoftware.com> References: <6485FD7F-35D0-40BB-81EF-AE79D64FEBB9@blackducksoftware.com> Message-ID: <54EE0985.7090807@redhat.com> On 25/02/15 17:59, Shaun Martin wrote: > Hi, > > I am having an issue with the forward first not appear to be working. > I have two separate IPA servers that server separate realms. I have > for the reverse zone configured forwarders to point to the other > realms IPA server. All versions are identical on the IPA servers. I > have included details on version and tests that show this is not working. > > $ yum list installed |grep bind-dyndb-ldap > bind-dyndb-ldap.x86_64 3.5-4.el7 @base > > $ yum list installed |grep ipa > ipa-admintools.x86_64 3.3.3-28.0.1.el7.centos.3 @updates > ipa-client.x86_64 3.3.3-28.0.1.el7.centos.3 @updates > ipa-python.x86_64 3.3.3-28.0.1.el7.centos.3 @updates > ipa-server.x86_64 3.3.3-28.0.1.el7.centos.3 @updates > libipa_hbac.x86_64 1.11.2-68.el7_0.6 > @updates > libipa_hbac-python.x86_64 1.11.2-68.el7_0.6 > @updates > python-iniparse.noarch 0.4-9.el7 @anaconda > sssd-ipa.x86_64 > > *BELOW IS WITH FORWARDING DISABLED*. It cannot find 10.1.0.9 but can > find 10.1.20.9. This is expected as this server only has the 10.1.20.9 > record. > $ nslookup > > server 10.1.20.9 > Default server: 10.1.20.9 > Address: 10.1.20.9#53 > > 10.1.20.9 > Server:10.1.20.9 > Address:10.1.20.9#53 > > 9.20.1.10.in-addr.arpaname = prd-ops-ipa01.uzb.local. > > 10.1.0.9 > Server:10.1.20.9 > Address:10.1.20.9#53 > > ** server can't find 9.0.1.10.in-addr.arpa.: NXDOMAIN > > *BELOW IS WITH FORWARDING ENABLED*. It cannot find 10.1.20.9 but can > find 10.1.0.9. This is expected as the forwarding server only has the > 10.1.0.9 record. > > 10.1.20.9 > Server:10.1.20.9 > Address:10.1.20.9#53 > > ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN > > 10.1.0.9 > Server:10.1.20.9 > Address:10.1.20.9#53 > > Non-authoritative answer: > 9.0.1.10.in-addr.arpaname = ops-ipa01.bbf.local. > > Authoritative answers can be found from: > 1.10.in-addr.arpanameserver = ops-ipa01.bbf.local. > > > *BELOW IS WITH FORWARD FIRST ENABLED*. It cannot find 10.1.20.9 but > can find 10.1.0.9. This is un-expected as the local zone has the > 10.1.20.9 and the forward server has the 10.1.0.9 so we should be > getting both. > > 10.1.20.9 > Server:10.1.20.9 > Address:10.1.20.9#53 > > ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN > > 10.1.0.9 > Server:10.1.20.9 > Address:10.1.20.9#53 > > Non-authoritative answer: > 9.0.1.10.in-addr.arpaname = ops-ipa01.bbf.local. > > Authoritative answers can be found from: > 1.10.in-addr.arpanameserver = ops-ipa01.bbf.local. > ops-ipa01.bbf.localinternet address = 10.1.0.9 > > > Any help is greatly appreciated. > > Thanks, > Shaun > > > Shaun Martin > IT\OPS Manager > Black Duck Software > O: +1.781.425.4336 > > Black Duck Software | OpenHUB > | OSDelivers > | OSS Logistics > > > > > /JP Morgan Chase & Co. Hall of Innovation Inductee/ > > > > Hello, we need more info: do you use global forwarders, or zone forwarders? how your reverse zones are configured (name, delegation)? Default forwarding policy is first, IMO both of your examples with forwarding enabled are forwarding first policy. Martin -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 3790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 280 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 248 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 227 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 335 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 355 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 316 bytes Desc: not available URL: From smartin at blackducksoftware.com Wed Feb 25 17:51:42 2015 From: smartin at blackducksoftware.com (Shaun Martin) Date: Wed, 25 Feb 2015 17:51:42 +0000 Subject: [Freeipa-users] Forward first not working In-Reply-To: <54EE0985.7090807@redhat.com> References: <6485FD7F-35D0-40BB-81EF-AE79D64FEBB9@blackducksoftware.com> <54EE0985.7090807@redhat.com> Message-ID: Hi Martin, The zone name is the following for both servers. Zone name: 1.10.in-addr.arpa. I am using zone forwarders. With forward first enabled though it should try and return an answer from the local DNS, it clearly does not though. The only time I receive the local record is when forwarding is disabled. Thanks, Shaun [cid:1F369212-0E28-4C3C-8955-33CDA7C2FAB4 at blackducksoftware.com] Shaun Martin IT\OPS Manager Black Duck Software O: +1.781.425.4336 Black Duck Software | OpenHUB | OSDelivers | OSS Logistics [cid:CC23E6F1-CA96-4E59-978B-D0D9EDE0F2DB at blackducksoftware.com] [cid:AC8F793C-9870-4ECB-B844-3337F98BA51F at blackducksoftware.com] [cid:AB6B7F6B-C85C-4E52-8B42-9C9A5EB9D0D1 at blackducksoftware.com] [cid:931AE271-12EC-458A-BB1F-7455AD35B154 at blackducksoftware.com] [cid:8EB9FA0C-F1E0-4E32-9E58-0D6A646A5625 at blackducksoftware.com] [cid:1A0AC858-0DCC-44B4-B3D0-8BB35E291B02 at blackducksoftware.com] JP Morgan Chase & Co. Hall of Innovation Inductee On Feb 25, 2015, at 12:42 PM, Martin Basti > wrote: On 25/02/15 17:59, Shaun Martin wrote: Hi, I am having an issue with the forward first not appear to be working. I have two separate IPA servers that server separate realms. I have for the reverse zone configured forwarders to point to the other realms IPA server. All versions are identical on the IPA servers. I have included details on version and tests that show this is not working. $ yum list installed |grep bind-dyndb-ldap bind-dyndb-ldap.x86_64 3.5-4.el7 @base $ yum list installed |grep ipa ipa-admintools.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-client.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-python.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-server.x86_64 3.3.3-28.0.1.el7.centos.3 @updates libipa_hbac.x86_64 1.11.2-68.el7_0.6 @updates libipa_hbac-python.x86_64 1.11.2-68.el7_0.6 @updates python-iniparse.noarch 0.4-9.el7 @anaconda sssd-ipa.x86_64 BELOW IS WITH FORWARDING DISABLED. It cannot find 10.1.0.9 but can find 10.1.20.9. This is expected as this server only has the 10.1.20.9 record. $ nslookup > server 10.1.20.9 Default server: 10.1.20.9 Address: 10.1.20.9#53 > 10.1.20.9 Server: 10.1.20.9 Address: 10.1.20.9#53 9.20.1.10.in-addr.arpa name = prd-ops-ipa01.uzb.local. > 10.1.0.9 Server: 10.1.20.9 Address: 10.1.20.9#53 ** server can't find 9.0.1.10.in-addr.arpa.: NXDOMAIN BELOW IS WITH FORWARDING ENABLED. It cannot find 10.1.20.9 but can find 10.1.0.9. This is expected as the forwarding server only has the 10.1.0.9 record. > 10.1.20.9 Server: 10.1.20.9 Address: 10.1.20.9#53 ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN > 10.1.0.9 Server: 10.1.20.9 Address: 10.1.20.9#53 Non-authoritative answer: 9.0.1.10.in-addr.arpa name = ops-ipa01.bbf.local. Authoritative answers can be found from: 1.10.in-addr.arpa nameserver = ops-ipa01.bbf.local. BELOW IS WITH FORWARD FIRST ENABLED. It cannot find 10.1.20.9 but can find 10.1.0.9. This is un-expected as the local zone has the 10.1.20.9 and the forward server has the 10.1.0.9 so we should be getting both. > 10.1.20.9 Server: 10.1.20.9 Address: 10.1.20.9#53 ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN > 10.1.0.9 Server: 10.1.20.9 Address: 10.1.20.9#53 Non-authoritative answer: 9.0.1.10.in-addr.arpa name = ops-ipa01.bbf.local. Authoritative answers can be found from: 1.10.in-addr.arpa nameserver = ops-ipa01.bbf.local. ops-ipa01.bbf.local internet address = 10.1.0.9 Any help is greatly appreciated. Thanks, Shaun Shaun Martin IT\OPS Manager Black Duck Software O: +1.781.425.4336 Black Duck Software | OpenHUB | OSDelivers | OSS Logistics JP Morgan Chase & Co. Hall of Innovation Inductee Hello, we need more info: do you use global forwarders, or zone forwarders? how your reverse zones are configured (name, delegation)? Default forwarding policy is first, IMO both of your examples with forwarding enabled are forwarding first policy. Martin -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 7EA68D51-363B-4FAD-A939-D9CD926D70AB.png Type: image/png Size: 3790 bytes Desc: 7EA68D51-363B-4FAD-A939-D9CD926D70AB.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: E33E6B21-2C3E-4C55-8796-46161EE14AC6.png Type: image/png Size: 280 bytes Desc: E33E6B21-2C3E-4C55-8796-46161EE14AC6.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: EDB9C095-85D8-437C-A4CF-A515712839CA.png Type: image/png Size: 248 bytes Desc: EDB9C095-85D8-437C-A4CF-A515712839CA.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8D343C4D-B65C-473A-96DE-792AF2B5D16E.png Type: image/png Size: 227 bytes Desc: 8D343C4D-B65C-473A-96DE-792AF2B5D16E.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 3FCDCA9B-C8EA-4EB2-9184-457FF1A9AB5D.png Type: image/png Size: 335 bytes Desc: 3FCDCA9B-C8EA-4EB2-9184-457FF1A9AB5D.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: D1E6BBB6-3622-496C-B3BF-7DC86A214CB8.png Type: image/png Size: 355 bytes Desc: D1E6BBB6-3622-496C-B3BF-7DC86A214CB8.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: B8FD9DF1-3230-44BF-80DA-AEA16CB00E29.png Type: image/png Size: 316 bytes Desc: B8FD9DF1-3230-44BF-80DA-AEA16CB00E29.png URL: From mbasti at redhat.com Wed Feb 25 18:18:49 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Feb 2015 19:18:49 +0100 Subject: [Freeipa-users] Forward first not working In-Reply-To: References: <6485FD7F-35D0-40BB-81EF-AE79D64FEBB9@blackducksoftware.com> <54EE0985.7090807@redhat.com> Message-ID: <54EE1209.2030403@redhat.com> On 25/02/15 18:51, Shaun Martin wrote: > Hi Martin, > > The zone name is the following for both servers. > > Zone name: > 1.10.in-addr.arpa. > > > I am using zone forwarders. > > With forward first enabled though it should try and return an answer > from the local DNS, it clearly does not though. The only time I > receive the local record is when forwarding is disabled. > > Thanks, > Shaun > > > Shaun Martin > IT\OPS Manager > Black Duck Software > O: +1.781.425.4336 > > Black Duck Software | OpenHUB > | OSDelivers > | OSS Logistics > > > > > /JP Morgan Chase & Co. Hall of Innovation Inductee/ > > > On Feb 25, 2015, at 12:42 PM, Martin Basti > wrote: > >> On 25/02/15 17:59, Shaun Martin wrote: >>> Hi, >>> >>> I am having an issue with the forward first not appear to be >>> working. I have two separate IPA servers that server separate >>> realms. I have for the reverse zone configured forwarders to point >>> to the other realms IPA server. All versions are identical on the >>> IPA servers. I have included details on version and tests that show >>> this is not working. >>> >>> $ yum list installed |grep bind-dyndb-ldap >>> bind-dyndb-ldap.x86_64 3.5-4.el7 >>> @base >>> >>> $ yum list installed |grep ipa >>> ipa-admintools.x86_64 3.3.3-28.0.1.el7.centos.3 @updates >>> ipa-client.x86_64 3.3.3-28.0.1.el7.centos.3 @updates >>> ipa-python.x86_64 3.3.3-28.0.1.el7.centos.3 @updates >>> ipa-server.x86_64 3.3.3-28.0.1.el7.centos.3 @updates >>> libipa_hbac.x86_64 1.11.2-68.el7_0.6 @updates >>> libipa_hbac-python.x86_64 1.11.2-68.el7_0.6 @updates >>> python-iniparse.noarch 0.4-9.el7 >>> @anaconda >>> sssd-ipa.x86_64 >>> >>> *BELOW IS WITH FORWARDING DISABLED*. It cannot find 10.1.0.9 but can >>> find 10.1.20.9. This is expected as this server only has the >>> 10.1.20.9 record. >>> $ nslookup >>> > server 10.1.20.9 >>> Default server: 10.1.20.9 >>> Address: 10.1.20.9#53 >>> > 10.1.20.9 >>> Server:10.1.20.9 >>> Address:10.1.20.9#53 >>> >>> 9.20.1.10.in-addr.arpaname = prd-ops-ipa01.uzb.local. >>> > 10.1.0.9 >>> Server:10.1.20.9 >>> Address:10.1.20.9#53 >>> >>> ** server can't find 9.0.1.10.in-addr.arpa.: NXDOMAIN >>> >>> *BELOW IS WITH FORWARDING ENABLED*. It cannot find 10.1.20.9 but can >>> find 10.1.0.9. This is expected as the forwarding server only has >>> the 10.1.0.9 record. >>> > 10.1.20.9 >>> Server:10.1.20.9 >>> Address:10.1.20.9#53 >>> >>> ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN >>> > 10.1.0.9 >>> Server:10.1.20.9 >>> Address:10.1.20.9#53 >>> >>> Non-authoritative answer: >>> 9.0.1.10.in-addr.arpaname = ops-ipa01.bbf.local. >>> >>> Authoritative answers can be found from: >>> 1.10.in-addr.arpanameserver = ops-ipa01.bbf.local. >>> >>> >>> *BELOW IS WITH FORWARD FIRST ENABLED*. It cannot find 10.1.20.9 but >>> can find 10.1.0.9. This is un-expected as the local zone has the >>> 10.1.20.9 and the forward server has the 10.1.0.9 so we should be >>> getting both. >>> > 10.1.20.9 >>> Server:10.1.20.9 >>> Address:10.1.20.9#53 >>> >>> ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN >>> > 10.1.0.9 >>> Server:10.1.20.9 >>> Address:10.1.20.9#53 >>> >>> Non-authoritative answer: >>> 9.0.1.10.in-addr.arpaname = ops-ipa01.bbf.local. >>> >>> Authoritative answers can be found from: >>> 1.10.in-addr.arpanameserver = ops-ipa01.bbf.local. >>> ops-ipa01.bbf.localinternet address = 10.1.0.9 >>> >>> >>> Any help is greatly appreciated. >>> >>> Thanks, >>> Shaun >>> >>> >>> Shaun Martin >>> IT\OPS Manager >>> Black Duck Software >>> O: +1.781.425.4336 >>> >>> Black Duck Software | OpenHUB >>> | OSDelivers >>> | OSS Logistics >>> >>> >>> >> Attachment.png>>> Attachment.png>>> Attachment.png>>> Attachment.png>>> Attachment.png> >>> >>> /JP Morgan Chase & Co. Hall of Innovation Inductee/ >>> >>> >>> >>> >> Hello, >> >> we need more info: >> do you use global forwarders, or zone forwarders? >> how your reverse zones are configured (name, delegation)? >> >> Default forwarding policy is first, IMO both of your examples with >> forwarding enabled are forwarding first policy. >> >> Martin >> >> -- >> Martin Basti > You issue is, the IPA < 4.1, separate zones in following way: * zone with forwarders specified == forward zone, records inside are ignored * zone without forwarders, or zone with --forward-policy=none == master zone, no forwarding So if you specify forwarders, your zone works as BIND's forward zone without records. And I'm not sure if forwarding between 2 authoritative zones with the same name will work, because the zone is authoritative on IPA side, so IPA will return authoritative answer NXDOMAIN and will not try to forward query. You may need NS delegation to subzone. I suggest to create separate zones, there should not be 2 authoritative servers with the same zone. FYI: Forward zones IPA 4.1: http://www.freeipa.org/page/V4/Forward_zones HTH Martin -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 3790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 280 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 248 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 227 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 335 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 355 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 316 bytes Desc: not available URL: From hugh at psychopig.com Wed Feb 25 18:22:56 2015 From: hugh at psychopig.com (Hugh) Date: Wed, 25 Feb 2015 12:22:56 -0600 Subject: [Freeipa-users] Web UI plugins or other extensions In-Reply-To: <54EE0042.6040509@redhat.com> References: <54ED8405.2030107@psychopig.com> <54EDE1E2.2080705@redhat.com> <54EE0042.6040509@redhat.com> Message-ID: <54EE1300.70104@psychopig.com> On 2/25/2015 11:02 AM, Dmitri Pal wrote: > But let us step back and ask the question why do you need to create the > users you sync manually first? > The users in a specific OU will be synced anyways without you manually > creating them in IPA. > So this is unclear why the whole thing is actually needed. What we'd like to do is have admins create users in IPA via the web interface (or CLI, if they're so inclined) and add them to an IPA group then have those users synched over to our AD environment, so those users can log into their Windows workstations. We'd like to avoid duplicate or unnecessary effort in terms of creating users. More steps to a process = more likelihood of mistakes. We'd like to create the users in IPA so that we're consistent in everyone using the IPA web interface to manage their user accounts. Thanks, Hugh From dpal at redhat.com Wed Feb 25 18:50:11 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 25 Feb 2015 13:50:11 -0500 Subject: [Freeipa-users] Web UI plugins or other extensions In-Reply-To: <54EE1300.70104@psychopig.com> References: <54ED8405.2030107@psychopig.com> <54EDE1E2.2080705@redhat.com> <54EE0042.6040509@redhat.com> <54EE1300.70104@psychopig.com> Message-ID: <54EE1963.1040100@redhat.com> On 02/25/2015 01:22 PM, Hugh wrote: > On 2/25/2015 11:02 AM, Dmitri Pal wrote: >> But let us step back and ask the question why do you need to create the >> users you sync manually first? >> The users in a specific OU will be synced anyways without you manually >> creating them in IPA. >> So this is unclear why the whole thing is actually needed. > What we'd like to do is have admins create users in IPA via the web > interface (or CLI, if they're so inclined) and add them to an IPA group > then have those users synched over to our AD environment, so those users > can log into their Windows workstations. We'd like to avoid duplicate or > unnecessary effort in terms of creating users. More steps to a process = > more likelihood of mistakes. > > We'd like to create the users in IPA so that we're consistent in > everyone using the IPA web interface to manage their user accounts. > > Thanks, > > Hugh > Will all users created via IPA interface synched to AD? Is there any harm to make all users be created with the attributes mentioned earlier in this thread? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From hugh at psychopig.com Wed Feb 25 19:15:25 2015 From: hugh at psychopig.com (Hugh) Date: Wed, 25 Feb 2015 13:15:25 -0600 Subject: [Freeipa-users] Web UI plugins or other extensions In-Reply-To: <54EE1963.1040100@redhat.com> References: <54ED8405.2030107@psychopig.com> <54EDE1E2.2080705@redhat.com> <54EE0042.6040509@redhat.com> <54EE1300.70104@psychopig.com> <54EE1963.1040100@redhat.com> Message-ID: <54EE1F4D.6000001@psychopig.com> On 2/25/2015 12:50 PM, Dmitri Pal wrote: > Will all users created via IPA interface synched to AD? > Is there any harm to make all users be created with the attributes > mentioned earlier in this thread? > Almost all. We have some users that will be role accounts for various pieces of software. It's fine with me if all users by default get those attributes and for those that shouldn't we can manually go back and remove the object/attributes. Hugh From nathan at nathanpeters.com Wed Feb 25 19:58:56 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Wed, 25 Feb 2015 11:58:56 -0800 Subject: [Freeipa-users] [Solaris 10] Cannot login through console or ssh with ipa users Message-ID: <6a76256421cfb199ed4a9e21658c42d4.squirrel@webmail.nathanpeters.com> I am having trouble logging in with an IPA user on Solaris 10. The machine is able to correctly initialize tickets using kinit. The issue appears to be PAM related. I am using FreeIPA 4.1.3. I have tried to follow the instructions here as best I can : http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html Here is my kinit and klist tests -------------------------------- $ kinit ipauser1 Password for ipauser1 at IPADOMAIN.NET: [07:45 PM] ipaclient5-sandbox-atdev-van:/var/log$ klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: ipauser1 at IPADOMAIN.NET Valid starting Expires Service principal 02/25/15 19:45:10 02/26/15 19:45:10 krbtgt/IPADOMAIN.NET at IPADOMAIN.NET renew until 03/04/15 19:45:10 Here is the last 2 lines of the output of getent passwd showing my ipa admin and user ------------------------------------------------------------------------------------- admin:x:375200000:375200000:Administrator:/home/admin:/bin/bash ipauser1:x:375200006:375200006:ipa user1:/home/ipauser1:/bin/bash However, this is what happens when I try to login as 'ipauser1'. On the console I am prompted with 'Password:' I enter the valid password, and suddenly Putty pops up a window 'Server unexpectedly closed network connection'. If I try to login as ipauser1 at ipadomain.net it still fails, but in a different way. The putty window stays open and I get an 'Access denied' message and am prompted for the password again: Logs with 'ipauser1' -------------------- Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.info] Connection from 10.5.5.57 port 57607 on 10.21.19.16 port 22 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: Client protocol version 2.0; client software version PuTTY_Release_0.63 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: no match: PuTTY_Release_0.63 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: Enabling compatibility mode for protocol 2.0 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: Local version string SSH-2.0-OpenSSH_6.6 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: permanently_set_uid: 100/65534 [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEXINIT sent [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEXINIT received [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: kex: client->server aes256-ctr hmac-sha2-256 none [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: kex: server->client aes256-ctr hmac-sha2-256 none [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: server_input_channel_req: channel 0 request winadj at putty.projects.tartarus.org reply 1 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: session_input_channel_req: session 0 req winadj at putty.projects.tartarus.org Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS sent [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_NEWKEYS [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS received [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: KEX done [preauth] Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: userauth-request for user ipauser1 service ssh-connection method none [preauth] Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: attempt 0 failures 0 [preauth] Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: PAM: initializing for "ipauser1" Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 781331 auth.debug] PAM[761]: pam_start(sshd,ipauser1,811c170:812b8e0) - debug = 1 Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 496445 auth.debug] PAM[761]: pam_set_item(812b8e0:service) Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 496445 auth.debug] PAM[761]: pam_set_item(812b8e0:user) Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 496445 auth.debug] PAM[761]: pam_set_item(812b8e0:conv) Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: PAM: setting PAM_RHOST to "10.5.5.57" Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 496445 auth.debug] PAM[761]: pam_set_item(812b8e0:rhost) Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: PAM: setting PAM_TTY to "ssh" Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 496445 auth.debug] PAM[761]: pam_set_item(812b8e0:tty) Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: userauth-request for user ipauser1 service ssh-connection method keyboard-interactive [preauth] Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: attempt 1 failures 0 [preauth] Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: keyboard-interactive devs [preauth] Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: auth2_challenge: user=ipauser1 devs= [preauth] Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: kbdint_alloc: devices 'pam' [preauth] Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: auth2_challenge_start: trying authentication method 'pam' [preauth] Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 120752 auth.debug] PAM[763]: pam_set_item(812b8e0:conv) Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 690215 auth.debug] PAM[763]: pam_authenticate(812b8e0, 1) Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 130555 auth.debug] PAM[763]: load_modules(812b8e0, pam_sm_authenticate)=/usr/lib/security/pam_authtok_get.so.1 Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 149594 auth.debug] PAM[763]: load_function: successful load of pam_sm_authenticate Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 130555 auth.debug] PAM[763]: load_modules(812b8e0, pam_sm_authenticate)=/usr/lib/security/pam_dhkeys.so.1 Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 149594 auth.debug] PAM[763]: load_function: successful load of pam_sm_authenticate Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 130555 auth.debug] PAM[763]: load_modules(812b8e0, pam_sm_authenticate)=/usr/lib/security/pam_unix_cred.so.1 Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 149594 auth.debug] PAM[763]: load_function: successful load of pam_sm_authenticate Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 130555 auth.debug] PAM[763]: load_modules(812b8e0, pam_sm_authenticate)=/usr/lib/security/pam_krb5.so.1 Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 149594 auth.debug] PAM[763]: load_function: successful load of pam_sm_authenticate Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 130555 auth.debug] PAM[763]: load_modules(812b8e0, pam_sm_authenticate)=/usr/lib/security/pam_unix_auth.so.1 Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 149594 auth.debug] PAM[763]: load_function: successful load of pam_sm_authenticate Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 634615 auth.debug] pam_authtok_get:pam_sm_authenticate: flags = 1 Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 776247 auth.debug] PAM[763]: pam_get_user(812b8e0, 812b8e0, NULL) Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.info] Postponed keyboard-interactive for ipauser1 from 10.5.5.57 port 57607 ssh2 [preauth] Feb 25 19:46:58 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 120752 auth.debug] PAM[763]: pam_set_item(812b8e0:authtok) Feb 25 19:46:58 ipaclient5-sandbox-atdev-van.ipadomain.net last message repeated 1 time Feb 25 19:46:58 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 655841 auth.debug] PAM-KRB5 (auth): pam_sm_authenticate flags=1 Feb 25 19:46:58 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID 549540 auth.debug] PAM-KRB5 (auth): attempt_krb5_auth: start: user='ipauser1' Feb 25 19:47:08 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: server_input_channel_req: channel 0 request window-change reply 0 Feb 25 19:47:08 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 Feb 25 19:47:08 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: session_input_channel_req: session 0 req window-change Logs with ipauser1 at ipadomain.net ------------------ Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.info] Connection from 10.5.5.57 port 57655 on 10.21.19.16 port 22 Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: Client protocol version 2.0; client software version PuTTY_Release_0.63 Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: no match: PuTTY_Release_0.63 Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: Enabling compatibility mode for protocol 2.0 Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: Local version string SSH-2.0-OpenSSH_6.6 Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: permanently_set_uid: 100/65534 [preauth] Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEXINIT sent [preauth] Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEXINIT received [preauth] Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: kex: client->server aes256-ctr hmac-sha2-256 none [preauth] Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: kex: server->client aes256-ctr hmac-sha2-256 none [preauth] Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth] Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS sent [preauth] Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_NEWKEYS [preauth] Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS received [preauth] Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: KEX done [preauth] Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: userauth-request for user ipauser1 at ipadomain.net service ssh-connection method none [preauth] Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: attempt 0 failures 0 [preauth] Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.info] Invalid user ipauser1 at ipadomain.net from 10.5.5.57 Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.info] input_userauth_request: invalid user ipauser1 at ipadomain.net [preauth] Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: PAM: initializing for "ipauser1 at ipadomain.net" Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 781347 auth.debug] PAM[765]: pam_start(sshd,ipauser1 at ipadomain.net,811c170:812d610) - debug = 1 Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 645040 auth.debug] PAM[765]: pam_set_item(812d610:service) Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 645040 auth.debug] PAM[765]: pam_set_item(812d610:user) Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 645040 auth.debug] PAM[765]: pam_set_item(812d610:conv) Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: PAM: setting PAM_RHOST to "10.5.5.57" Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 645040 auth.debug] PAM[765]: pam_set_item(812d610:rhost) Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: PAM: setting PAM_TTY to "ssh" Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 645040 auth.debug] PAM[765]: pam_set_item(812d610:tty) Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: userauth-request for user ipauser1 at ipadomain.net service ssh-connection method keyboard-interactive [preauth] Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: attempt 1 failures 0 [preauth] Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: keyboard-interactive devs [preauth] Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: auth2_challenge: user=ipauser1 at ipadomain.net devs= [preauth] Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: kbdint_alloc: devices 'pam' [preauth] Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: auth2_challenge_start: trying authentication method 'pam' [preauth] Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 269347 auth.debug] PAM[767]: pam_set_item(812d610:conv) Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 690217 auth.debug] PAM[767]: pam_authenticate(812d610, 1) Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 130556 auth.debug] PAM[767]: load_modules(812d610, pam_sm_authenticate)=/usr/lib/security/pam_authtok_get.so.1 Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 278576 auth.debug] PAM[767]: load_function: successful load of pam_sm_authenticate Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 130556 auth.debug] PAM[767]: load_modules(812d610, pam_sm_authenticate)=/usr/lib/security/pam_dhkeys.so.1 Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 278576 auth.debug] PAM[767]: load_function: successful load of pam_sm_authenticate Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 130556 auth.debug] PAM[767]: load_modules(812d610, pam_sm_authenticate)=/usr/lib/security/pam_unix_cred.so.1 Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 278576 auth.debug] PAM[767]: load_function: successful load of pam_sm_authenticate Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 130556 auth.debug] PAM[767]: load_modules(812d610, pam_sm_authenticate)=/usr/lib/security/pam_krb5.so.1 Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 278576 auth.debug] PAM[767]: load_function: successful load of pam_sm_authenticate Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 130556 auth.debug] PAM[767]: load_modules(812d610, pam_sm_authenticate)=/usr/lib/security/pam_unix_auth.so.1 Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 278576 auth.debug] PAM[767]: load_function: successful load of pam_sm_authenticate Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 634615 auth.debug] pam_authtok_get:pam_sm_authenticate: flags = 1 Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 896806 auth.debug] PAM[767]: pam_get_user(812d610, 812d610, NULL) Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.info] Postponed keyboard-interactive for invalid user ipauser1 at ipadomain.net from 10.5.5.57 port 57655 ssh2 [preauth] Feb 25 19:49:55 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: server_input_channel_req: channel 0 request winadj at putty.projects.tartarus.org reply 1 Feb 25 19:49:55 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 Feb 25 19:49:55 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: session_input_channel_req: session 0 req winadj at putty.projects.tartarus.org Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 269347 auth.debug] PAM[767]: pam_set_item(812d610:authtok) Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net last message repeated 1 time Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 564987 auth.debug] PAM[767]: pam_authenticate(812d610, 1): error No account present for user Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 655841 auth.debug] PAM-KRB5 (auth): pam_sm_authenticate flags=1 Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 564987 auth.debug] PAM[767]: pam_authenticate(812d610, 1): error No account present for user Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 896952 auth.debug] pam_unix_auth: entering pam_sm_authenticate() Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 219349 auth.debug] pam_unix_auth: user ipauser1 at ipadomain.net not found Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 564987 auth.debug] PAM[767]: pam_authenticate(812d610, 1): error No account present for user Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID 269347 auth.debug] PAM[767]: pam_set_item(812d610:authtok) Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.error] error: PAM: No account present for user for illegal user ipauser1 at ipadomain.net from 10.5.5.57 Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.info] Failed keyboard-interactive/pam for invalid user ipauser1 at ipadomain.net from 10.5.5.57 port 57655 ssh2 Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: userauth-request for user ipauser1 at ipadomain.net service ssh-connection method keyboard-interactive [preauth] Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: attempt 2 failures 1 [preauth] Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: keyboard-interactive devs [preauth] Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: auth2_challenge: user=ipauser1 at ipadomain.net devs= [preauth] Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: kbdint_alloc: devices 'pam' [preauth] Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.debug] debug1: auth2_challenge_start: trying authentication method 'pam' [preauth] Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID 531491 auth.debug] PAM[768]: pam_set_item(812d610:conv) Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID 561236 auth.debug] PAM[768]: pam_authenticate(812d610, 1) Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID 195047 auth.debug] PAM[768]: load_modules(812d610, pam_sm_authenticate)=/usr/lib/security/pam_authtok_get.so.1 Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID 502849 auth.debug] PAM[768]: load_function: successful load of pam_sm_authenticate Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID 195047 auth.debug] PAM[768]: load_modules(812d610, pam_sm_authenticate)=/usr/lib/security/pam_dhkeys.so.1 Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID 502849 auth.debug] PAM[768]: load_function: successful load of pam_sm_authenticate Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID 195047 auth.debug] PAM[768]: load_modules(812d610, pam_sm_authenticate)=/usr/lib/security/pam_unix_cred.so.1 Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID 502849 auth.debug] PAM[768]: load_function: successful load of pam_sm_authenticate Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID 195047 auth.debug] PAM[768]: load_modules(812d610, pam_sm_authenticate)=/usr/lib/security/pam_krb5.so.1 Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID 502849 auth.debug] PAM[768]: load_function: successful load of pam_sm_authenticate Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID 195047 auth.debug] PAM[768]: load_modules(812d610, pam_sm_authenticate)=/usr/lib/security/pam_unix_auth.so.1 Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID 502849 auth.debug] PAM[768]: load_function: successful load of pam_sm_authenticate Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID 634615 auth.debug] pam_authtok_get:pam_sm_authenticate: flags = 1 Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID 251960 auth.debug] PAM[768]: pam_get_user(812d610, 812d610, NULL) Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID 800047 auth.info] Postponed keyboard-interactive for invalid user ipauser1 at ipadomain.net from 10.5.5.57 port 57655 ssh2 [preauth] Here is my /etc/krb5.conf file ------------------------------ [libdefaults] default_realm = IPADOMAIN.NET dns_lookup_kdc = true [realms] IPADOMAIN.NET = { kdc = 10.21.19.20 admin_server = 10.21.19.20 } [domain_realm] .ipadomain.net = IPADOMAIN.NET ipadomain.net = IPADOMAIN.NET [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log kdc_rotate = { period = 1d version = 10 } [appdefaults] kinit = { renewable = true forwardable= true } Here is my /etc/pam.conf (please note that some stuff is commented out for troubleshooting. I have tried with everything uncommented and it doesn't work. I have also tried following about 10 different ways to configure PAM that I have seen in other forum posts where people were having Solaris troubles and have not found the magic combination yet. ------------------------ # #ident "@(#)pam.conf 1.31 07/12/07 SMI" # # Copyright 2007 Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # # PAM configuration # # Unless explicitly defined, all services use the modules # defined in the "other" section. # # Modules are defined with relative pathnames, i.e., they are # relative to /usr/lib/security/$ISA. Absolute path names, as # present in this file in previous releases are still acceptable. # # Authentication management # # login service (explicit because of pam_dial_auth) # 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 debug login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1 # # rlogin service (explicit because of pam_rhost_auth) # #rlogin auth requisite pam_authtok_get.so.1 #rlogin auth required pam_dhkeys.so.1 #rlogin auth required pam_unix_cred.so.1 #rlogin auth required pam_unix_auth.so.1 # # Kerberized rlogin service # #krlogin auth required pam_unix_cred.so.1 #krlogin auth required pam_krb5.so.1 # # rsh service (explicit because of pam_rhost_auth, # and pam_unix_auth for meaningful pam_setcred) # #rsh auth required pam_unix_cred.so.1 # # Kerberized rsh service # #krsh auth required pam_unix_cred.so.1 #krsh auth required pam_krb5.so.1 # # Kerberized telnet service # #ktelnet auth required pam_unix_cred.so.1 #ktelnet auth required pam_krb5.so.1 # # PPP service (explicit because of pam_dial_auth) # #ppp auth requisite pam_authtok_get.so.1 #ppp auth required pam_dhkeys.so.1 #ppp auth required pam_unix_cred.so.1 #ppp auth required pam_unix_auth.so.1 #ppp auth required pam_dial_auth.so.1 # # Default definitions for Authentication management # Used when service name is not explicitly mentioned for authentication # other auth requisite pam_authtok_get.so.1 debug other auth required pam_dhkeys.so.1 debug other auth required pam_unix_cred.so.1 debug other auth sufficient pam_krb5.so.1 debug other auth required pam_unix_auth.so.1 debug # # passwd command (explicit because of a different authentication module) # #passwd auth required pam_passwd_auth.so.1 # # cron service (explicit because of non-usage of pam_roles.so.1) # #cron account required pam_unix_account.so.1 # # Default definition for Account management # Used when service name is not explicitly mentioned for account management # other account requisite pam_roles.so.1 debug other account required pam_unix_account.so.1 debug #other account sufficient pam_ldap.so.1 other account required pam_krb5.so.1 debug # # Default definition for Session management # Used when service name is not explicitly mentioned for session management # other session required pam_mkhomedir.so.1 skel=/etc/skel/ umask=0027 other session required pam_unix_session.so.1 # # Default definition for Password management # Used when service name is not explicitly mentioned for password management # #other password required pam_dhkeys.so.1 #other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 force_check other password sufficient pam_krb5.so.1 debug other password required pam_authtok_store.so.1 From nathan at nathanpeters.com Wed Feb 25 20:11:10 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Wed, 25 Feb 2015 12:11:10 -0800 Subject: [Freeipa-users] [SSSD] default_domain_suffix breaks IPA user logins Message-ID: <11502507b62fbcd92506561dfdc55bf7.squirrel@webmail.nathanpeters.com> FreeIPA Server 4.1.2 FreeIPA client 3.0.0-42 I'm not sure how to go about fixing this or working around it. In our organization we have a trust relationship between ad.somedomain.net and ipadomain.net. We don't want our AD users having to type username at ad.somedomain.net when logging in to an IPA machine so we have added default_domain_suffix = ad.somedomain.net to the [sssd] section of sssd.conf. This works great when logging in with an AD user. I can login using 'username' and they end up with the proper shell and home directory /home/ad.somedomain.net/username etc. However, when I try to login with an IPA user using the username ipauser at ipadomain.net I am just disconnected. Removing the default_domain_suffix line immediately fixes , but then we lose the ability to login with AD users just typing their username. Does anyone know how to fix this / workaround it so we can use the default_domain_suffix option and not break internal FreeIPA user logins? From dpal at redhat.com Wed Feb 25 20:58:41 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 25 Feb 2015 15:58:41 -0500 Subject: [Freeipa-users] [Solaris 10] Cannot login through console or ssh with ipa users In-Reply-To: <6a76256421cfb199ed4a9e21658c42d4.squirrel@webmail.nathanpeters.com> References: <6a76256421cfb199ed4a9e21658c42d4.squirrel@webmail.nathanpeters.com> Message-ID: <54EE3781.4040400@redhat.com> On 02/25/2015 02:58 PM, nathan at nathanpeters.com wrote: > I am having trouble logging in with an IPA user on Solaris 10. The > machine is able to correctly initialize tickets using kinit. The issue > appears to be PAM related. I am using FreeIPA 4.1.3. > > I have tried to follow the instructions here as best I can : > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html > > Here is my kinit and klist tests > -------------------------------- > $ kinit ipauser1 > Password for ipauser1 at IPADOMAIN.NET: > [07:45 PM] ipaclient5-sandbox-atdev-van:/var/log$ klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: ipauser1 at IPADOMAIN.NET > > Valid starting Expires Service principal > 02/25/15 19:45:10 02/26/15 19:45:10 krbtgt/IPADOMAIN.NET at IPADOMAIN.NET > renew until 03/04/15 19:45:10 > > Here is the last 2 lines of the output of getent passwd showing my ipa > admin and user > ------------------------------------------------------------------------------------- > admin:x:375200000:375200000:Administrator:/home/admin:/bin/bash > ipauser1:x:375200006:375200006:ipa user1:/home/ipauser1:/bin/bash > > > However, this is what happens when I try to login as 'ipauser1'. On the > console I am prompted with 'Password:' I enter the valid password, and > suddenly Putty pops up a window 'Server unexpectedly closed network > connection'. If I try to login as ipauser1 at ipadomain.net it still fails, > but in a different way. The putty window stays open and I get an 'Access > denied' message and am prompted for the password again: > > Logs with 'ipauser1' > -------------------- > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.info] Connection from 10.5.5.57 port 57607 on 10.21.19.16 port > 22 > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: Client protocol version 2.0; client software > version PuTTY_Release_0.63 > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: no match: PuTTY_Release_0.63 > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: Enabling compatibility mode for protocol 2.0 > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: Local version string SSH-2.0-OpenSSH_6.6 > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: permanently_set_uid: 100/65534 [preauth] > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: list_hostkey_types: > ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: SSH2_MSG_KEXINIT sent [preauth] > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: SSH2_MSG_KEXINIT received [preauth] > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: kex: client->server aes256-ctr hmac-sha2-256 > none [preauth] > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: kex: server->client aes256-ctr hmac-sha2-256 > none [preauth] > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received > [preauth] > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID > 800047 auth.debug] debug1: server_input_channel_req: channel 0 request > winadj at putty.projects.tartarus.org reply 1 > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID > 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID > 800047 auth.debug] debug1: session_input_channel_req: session 0 req > winadj at putty.projects.tartarus.org > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS sent [preauth] > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: expecting SSH2_MSG_NEWKEYS [preauth] > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS received [preauth] > Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: KEX done [preauth] > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: userauth-request for user ipauser1 service > ssh-connection method none [preauth] > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: attempt 0 failures 0 [preauth] > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: PAM: initializing for "ipauser1" > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 781331 auth.debug] PAM[761]: pam_start(sshd,ipauser1,811c170:812b8e0) - > debug = 1 > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 496445 auth.debug] PAM[761]: pam_set_item(812b8e0:service) > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 496445 auth.debug] PAM[761]: pam_set_item(812b8e0:user) > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 496445 auth.debug] PAM[761]: pam_set_item(812b8e0:conv) > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: PAM: setting PAM_RHOST to "10.5.5.57" > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 496445 auth.debug] PAM[761]: pam_set_item(812b8e0:rhost) > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: PAM: setting PAM_TTY to "ssh" > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 496445 auth.debug] PAM[761]: pam_set_item(812b8e0:tty) > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: userauth-request for user ipauser1 service > ssh-connection method keyboard-interactive [preauth] > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: attempt 1 failures 0 [preauth] > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: keyboard-interactive devs [preauth] > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: auth2_challenge: user=ipauser1 devs= [preauth] > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: kbdint_alloc: devices 'pam' [preauth] > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.debug] debug1: auth2_challenge_start: trying authentication > method 'pam' [preauth] > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 120752 auth.debug] PAM[763]: pam_set_item(812b8e0:conv) > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 690215 auth.debug] PAM[763]: pam_authenticate(812b8e0, 1) > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 130555 auth.debug] PAM[763]: load_modules(812b8e0, > pam_sm_authenticate)=/usr/lib/security/pam_authtok_get.so.1 > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 149594 auth.debug] PAM[763]: load_function: successful load of > pam_sm_authenticate > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 130555 auth.debug] PAM[763]: load_modules(812b8e0, > pam_sm_authenticate)=/usr/lib/security/pam_dhkeys.so.1 > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 149594 auth.debug] PAM[763]: load_function: successful load of > pam_sm_authenticate > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 130555 auth.debug] PAM[763]: load_modules(812b8e0, > pam_sm_authenticate)=/usr/lib/security/pam_unix_cred.so.1 > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 149594 auth.debug] PAM[763]: load_function: successful load of > pam_sm_authenticate > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 130555 auth.debug] PAM[763]: load_modules(812b8e0, > pam_sm_authenticate)=/usr/lib/security/pam_krb5.so.1 > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 149594 auth.debug] PAM[763]: load_function: successful load of > pam_sm_authenticate > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 130555 auth.debug] PAM[763]: load_modules(812b8e0, > pam_sm_authenticate)=/usr/lib/security/pam_unix_auth.so.1 > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 149594 auth.debug] PAM[763]: load_function: successful load of > pam_sm_authenticate > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 634615 auth.debug] pam_authtok_get:pam_sm_authenticate: flags = 1 > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 776247 auth.debug] PAM[763]: pam_get_user(812b8e0, 812b8e0, NULL) > Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID > 800047 auth.info] Postponed keyboard-interactive for ipauser1 from > 10.5.5.57 port 57607 ssh2 [preauth] > Feb 25 19:46:58 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 120752 auth.debug] PAM[763]: pam_set_item(812b8e0:authtok) > Feb 25 19:46:58 ipaclient5-sandbox-atdev-van.ipadomain.net last message > repeated 1 time > Feb 25 19:46:58 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 655841 auth.debug] PAM-KRB5 (auth): pam_sm_authenticate flags=1 > Feb 25 19:46:58 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[763]: [ID > 549540 auth.debug] PAM-KRB5 (auth): attempt_krb5_auth: start: > user='ipauser1' > Feb 25 19:47:08 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID > 800047 auth.debug] debug1: server_input_channel_req: channel 0 request > window-change reply 0 > Feb 25 19:47:08 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID > 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 > Feb 25 19:47:08 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID > 800047 auth.debug] debug1: session_input_channel_req: session 0 req > window-change > > Logs with ipauser1 at ipadomain.net > ------------------ > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.info] Connection from 10.5.5.57 port 57655 on 10.21.19.16 port > 22 > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: Client protocol version 2.0; client software > version PuTTY_Release_0.63 > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: no match: PuTTY_Release_0.63 > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: Enabling compatibility mode for protocol 2.0 > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: Local version string SSH-2.0-OpenSSH_6.6 > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: permanently_set_uid: 100/65534 [preauth] > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: list_hostkey_types: > ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: SSH2_MSG_KEXINIT sent [preauth] > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: SSH2_MSG_KEXINIT received [preauth] > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: kex: client->server aes256-ctr hmac-sha2-256 > none [preauth] > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: kex: server->client aes256-ctr hmac-sha2-256 > none [preauth] > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received > [preauth] > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS sent [preauth] > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: expecting SSH2_MSG_NEWKEYS [preauth] > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS received [preauth] > Feb 25 19:49:44 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: KEX done [preauth] > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: userauth-request for user > ipauser1 at ipadomain.net service ssh-connection method none [preauth] > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: attempt 0 failures 0 [preauth] > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.info] Invalid user ipauser1 at ipadomain.net from 10.5.5.57 > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.info] input_userauth_request: invalid user > ipauser1 at ipadomain.net [preauth] > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: PAM: initializing for "ipauser1 at ipadomain.net" > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 781347 auth.debug] PAM[765]: > pam_start(sshd,ipauser1 at ipadomain.net,811c170:812d610) - debug = 1 > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 645040 auth.debug] PAM[765]: pam_set_item(812d610:service) > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 645040 auth.debug] PAM[765]: pam_set_item(812d610:user) > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 645040 auth.debug] PAM[765]: pam_set_item(812d610:conv) > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: PAM: setting PAM_RHOST to "10.5.5.57" > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 645040 auth.debug] PAM[765]: pam_set_item(812d610:rhost) > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: PAM: setting PAM_TTY to "ssh" > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 645040 auth.debug] PAM[765]: pam_set_item(812d610:tty) > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: userauth-request for user > ipauser1 at ipadomain.net service ssh-connection method keyboard-interactive > [preauth] > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: attempt 1 failures 0 [preauth] > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: keyboard-interactive devs [preauth] > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: auth2_challenge: user=ipauser1 at ipadomain.net > devs= [preauth] > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: kbdint_alloc: devices 'pam' [preauth] > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: auth2_challenge_start: trying authentication > method 'pam' [preauth] > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 269347 auth.debug] PAM[767]: pam_set_item(812d610:conv) > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 690217 auth.debug] PAM[767]: pam_authenticate(812d610, 1) > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 130556 auth.debug] PAM[767]: load_modules(812d610, > pam_sm_authenticate)=/usr/lib/security/pam_authtok_get.so.1 > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 278576 auth.debug] PAM[767]: load_function: successful load of > pam_sm_authenticate > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 130556 auth.debug] PAM[767]: load_modules(812d610, > pam_sm_authenticate)=/usr/lib/security/pam_dhkeys.so.1 > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 278576 auth.debug] PAM[767]: load_function: successful load of > pam_sm_authenticate > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 130556 auth.debug] PAM[767]: load_modules(812d610, > pam_sm_authenticate)=/usr/lib/security/pam_unix_cred.so.1 > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 278576 auth.debug] PAM[767]: load_function: successful load of > pam_sm_authenticate > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 130556 auth.debug] PAM[767]: load_modules(812d610, > pam_sm_authenticate)=/usr/lib/security/pam_krb5.so.1 > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 278576 auth.debug] PAM[767]: load_function: successful load of > pam_sm_authenticate > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 130556 auth.debug] PAM[767]: load_modules(812d610, > pam_sm_authenticate)=/usr/lib/security/pam_unix_auth.so.1 > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 278576 auth.debug] PAM[767]: load_function: successful load of > pam_sm_authenticate > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 634615 auth.debug] pam_authtok_get:pam_sm_authenticate: flags = 1 > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 896806 auth.debug] PAM[767]: pam_get_user(812d610, 812d610, NULL) > Feb 25 19:49:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.info] Postponed keyboard-interactive for invalid user > ipauser1 at ipadomain.net from 10.5.5.57 port 57655 ssh2 [preauth] > Feb 25 19:49:55 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID > 800047 auth.debug] debug1: server_input_channel_req: channel 0 request > winadj at putty.projects.tartarus.org reply 1 > Feb 25 19:49:55 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID > 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 > Feb 25 19:49:55 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID > 800047 auth.debug] debug1: session_input_channel_req: session 0 req > winadj at putty.projects.tartarus.org > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 269347 auth.debug] PAM[767]: pam_set_item(812d610:authtok) > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net last message > repeated 1 time > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 564987 auth.debug] PAM[767]: pam_authenticate(812d610, 1): error No > account present for user > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 655841 auth.debug] PAM-KRB5 (auth): pam_sm_authenticate flags=1 > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 564987 auth.debug] PAM[767]: pam_authenticate(812d610, 1): error No > account present for user > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 896952 auth.debug] pam_unix_auth: entering pam_sm_authenticate() > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 219349 auth.debug] pam_unix_auth: user ipauser1 at ipadomain.net not found > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 564987 auth.debug] PAM[767]: pam_authenticate(812d610, 1): error No > account present for user > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[767]: [ID > 269347 auth.debug] PAM[767]: pam_set_item(812d610:authtok) > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.error] error: PAM: No account present for user for illegal > user ipauser1 at ipadomain.net from 10.5.5.57 > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.info] Failed keyboard-interactive/pam for invalid user > ipauser1 at ipadomain.net from 10.5.5.57 port 57655 ssh2 > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: userauth-request for user > ipauser1 at ipadomain.net service ssh-connection method keyboard-interactive > [preauth] > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: attempt 2 failures 1 [preauth] > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: keyboard-interactive devs [preauth] > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: auth2_challenge: user=ipauser1 at ipadomain.net > devs= [preauth] > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: kbdint_alloc: devices 'pam' [preauth] > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.debug] debug1: auth2_challenge_start: trying authentication > method 'pam' [preauth] > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID > 531491 auth.debug] PAM[768]: pam_set_item(812d610:conv) > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID > 561236 auth.debug] PAM[768]: pam_authenticate(812d610, 1) > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID > 195047 auth.debug] PAM[768]: load_modules(812d610, > pam_sm_authenticate)=/usr/lib/security/pam_authtok_get.so.1 > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID > 502849 auth.debug] PAM[768]: load_function: successful load of > pam_sm_authenticate > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID > 195047 auth.debug] PAM[768]: load_modules(812d610, > pam_sm_authenticate)=/usr/lib/security/pam_dhkeys.so.1 > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID > 502849 auth.debug] PAM[768]: load_function: successful load of > pam_sm_authenticate > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID > 195047 auth.debug] PAM[768]: load_modules(812d610, > pam_sm_authenticate)=/usr/lib/security/pam_unix_cred.so.1 > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID > 502849 auth.debug] PAM[768]: load_function: successful load of > pam_sm_authenticate > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID > 195047 auth.debug] PAM[768]: load_modules(812d610, > pam_sm_authenticate)=/usr/lib/security/pam_krb5.so.1 > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID > 502849 auth.debug] PAM[768]: load_function: successful load of > pam_sm_authenticate > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID > 195047 auth.debug] PAM[768]: load_modules(812d610, > pam_sm_authenticate)=/usr/lib/security/pam_unix_auth.so.1 > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID > 502849 auth.debug] PAM[768]: load_function: successful load of > pam_sm_authenticate > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID > 634615 auth.debug] pam_authtok_get:pam_sm_authenticate: flags = 1 > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[768]: [ID > 251960 auth.debug] PAM[768]: pam_get_user(812d610, 812d610, NULL) > Feb 25 19:49:56 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[765]: [ID > 800047 auth.info] Postponed keyboard-interactive for invalid user > ipauser1 at ipadomain.net from 10.5.5.57 port 57655 ssh2 [preauth] > > > > Here is my /etc/krb5.conf file > ------------------------------ > [libdefaults] > default_realm = IPADOMAIN.NET > dns_lookup_kdc = true > > [realms] > IPADOMAIN.NET = { > kdc = 10.21.19.20 > admin_server = 10.21.19.20 > } > > [domain_realm] > .ipadomain.net = IPADOMAIN.NET > ipadomain.net = IPADOMAIN.NET > > [logging] > default = FILE:/var/krb5/kdc.log > kdc = FILE:/var/krb5/kdc.log > kdc_rotate = { > period = 1d > version = 10 > } > > [appdefaults] > kinit = { > renewable = true > forwardable= true > } > > Here is my /etc/pam.conf > > (please note that some stuff is commented out for troubleshooting. I have > tried with everything uncommented and it doesn't work. I have also tried > following about 10 different ways to configure PAM that I have seen in > other forum posts where people were having Solaris troubles and have not > found the magic combination yet. > ------------------------ > > # > #ident "@(#)pam.conf 1.31 07/12/07 SMI" > # > # Copyright 2007 Sun Microsystems, Inc. All rights reserved. > # Use is subject to license terms. > # > # PAM configuration > # > # Unless explicitly defined, all services use the modules > # defined in the "other" section. > # > # Modules are defined with relative pathnames, i.e., they are > # relative to /usr/lib/security/$ISA. Absolute path names, as > # present in this file in previous releases are still acceptable. > # > # Authentication management > # > # login service (explicit because of pam_dial_auth) > # > 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 debug > login auth required pam_unix_auth.so.1 > login auth required pam_dial_auth.so.1 > # > # rlogin service (explicit because of pam_rhost_auth) > # > #rlogin auth requisite pam_authtok_get.so.1 > #rlogin auth required pam_dhkeys.so.1 > #rlogin auth required pam_unix_cred.so.1 > #rlogin auth required pam_unix_auth.so.1 > # > # Kerberized rlogin service > # > #krlogin auth required pam_unix_cred.so.1 > #krlogin auth required pam_krb5.so.1 > # > # rsh service (explicit because of pam_rhost_auth, > # and pam_unix_auth for meaningful pam_setcred) > # > #rsh auth required pam_unix_cred.so.1 > # > # Kerberized rsh service > # > #krsh auth required pam_unix_cred.so.1 > #krsh auth required pam_krb5.so.1 > # > # Kerberized telnet service > # > #ktelnet auth required pam_unix_cred.so.1 > #ktelnet auth required pam_krb5.so.1 > # > # PPP service (explicit because of pam_dial_auth) > # > #ppp auth requisite pam_authtok_get.so.1 > #ppp auth required pam_dhkeys.so.1 > #ppp auth required pam_unix_cred.so.1 > #ppp auth required pam_unix_auth.so.1 > #ppp auth required pam_dial_auth.so.1 > # > # Default definitions for Authentication management > # Used when service name is not explicitly mentioned for authentication > # > other auth requisite pam_authtok_get.so.1 debug > other auth required pam_dhkeys.so.1 debug > other auth required pam_unix_cred.so.1 debug > other auth sufficient pam_krb5.so.1 debug > other auth required pam_unix_auth.so.1 debug > # > # passwd command (explicit because of a different authentication module) > # > #passwd auth required pam_passwd_auth.so.1 > # > # cron service (explicit because of non-usage of pam_roles.so.1) > # > #cron account required pam_unix_account.so.1 > # > # Default definition for Account management > # Used when service name is not explicitly mentioned for account management > # > other account requisite pam_roles.so.1 debug > other account required pam_unix_account.so.1 debug > #other account sufficient pam_ldap.so.1 > other account required pam_krb5.so.1 debug > # > # Default definition for Session management > # Used when service name is not explicitly mentioned for session management > # > other session required pam_mkhomedir.so.1 skel=/etc/skel/ umask=0027 > other session required pam_unix_session.so.1 > # > # Default definition for Password management > # Used when service name is not explicitly mentioned for password management > # > #other password required pam_dhkeys.so.1 > #other password requisite pam_authtok_get.so.1 > other password requisite pam_authtok_check.so.1 force_check > other password sufficient pam_krb5.so.1 debug > other password required pam_authtok_store.so.1 > > > > It does not seem to recognize the user in the secan attempt but the first attempt seems to authenticate and then disconnect. I do not see trace from accounting session but I suspect that your pam stack does not authorize authenticated user. Try to allow all authenticated users first. This will prove that it is a pam stack accounting phase configuration issue. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Wed Feb 25 21:11:48 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 25 Feb 2015 16:11:48 -0500 Subject: [Freeipa-users] Web UI plugins or other extensions In-Reply-To: <54EE1F4D.6000001@psychopig.com> References: <54ED8405.2030107@psychopig.com> <54EDE1E2.2080705@redhat.com> <54EE0042.6040509@redhat.com> <54EE1300.70104@psychopig.com> <54EE1963.1040100@redhat.com> <54EE1F4D.6000001@psychopig.com> Message-ID: <54EE3A94.1020804@redhat.com> On 02/25/2015 02:15 PM, Hugh wrote: > On 2/25/2015 12:50 PM, Dmitri Pal wrote: >> Will all users created via IPA interface synched to AD? >> Is there any harm to make all users be created with the attributes >> mentioned earlier in this thread? >> > Almost all. We have some users that will be role accounts for various > pieces of software. It's fine with me if all users by default get those > attributes and for those that shouldn't we can manually go back and > remove the object/attributes. > > Hugh > I think you can start with adding ntUser object class into the list of the object classes in the IPA configuration in UI. That would apply it to the new entries automatically. If that does not work it is probably a bug. If it works you will have the object class right there. Next step is creating attributes - ntUserDomainId - I wonder whether it can be auto-populated using managed entry or CoS configuration in DS. If that works it will be a config change rather than a code change which means it will survive upgrades (most likely). - ntUserCreateNewAccount - should be set to true AFAIU and I wonder if it can be set to true using same managed entry or CoS mechanism. I am not saying that would work but that might work and would avoid doing code changes. If you willing to do code changes than it should be possible to just update the user plugin to autopopulate the entries with these attributes. But that would definitely blow up during upgrade. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From jhrozek at redhat.com Wed Feb 25 21:16:37 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 25 Feb 2015 22:16:37 +0100 Subject: [Freeipa-users] [SSSD] default_domain_suffix breaks IPA user logins In-Reply-To: <11502507b62fbcd92506561dfdc55bf7.squirrel@webmail.nathanpeters.com> References: <11502507b62fbcd92506561dfdc55bf7.squirrel@webmail.nathanpeters.com> Message-ID: <20150225211637.GX9792@hendrix.redhat.com> On Wed, Feb 25, 2015 at 12:11:10PM -0800, nathan at nathanpeters.com wrote: > FreeIPA Server 4.1.2 > FreeIPA client 3.0.0-42 > > I'm not sure how to go about fixing this or working around it. > > In our organization we have a trust relationship between ad.somedomain.net > and ipadomain.net. > > We don't want our AD users having to type username at ad.somedomain.net when > logging in to an IPA machine so we have added > default_domain_suffix = ad.somedomain.net to the [sssd] section of > sssd.conf. > > This works great when logging in with an AD user. I can login using > 'username' and they end up with the proper shell and home directory > /home/ad.somedomain.net/username etc. > > However, when I try to login with an IPA user using the username > ipauser at ipadomain.net I am just disconnected. Removing the > default_domain_suffix line immediately fixes , but then we lose the > ability to login with AD users just typing their username. > > Does anyone know how to fix this / workaround it so we can use the > default_domain_suffix option and not break internal FreeIPA user logins? Known issue: https://fedorahosted.org/sssd/ticket/2569 I just acked a patch by Michal Zidek that fixes the problem. In the meantime, you can set: use_fully_qualified_names = True in the [domain] section. From nathan at nathanpeters.com Wed Feb 25 21:37:16 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Wed, 25 Feb 2015 13:37:16 -0800 Subject: [Freeipa-users] [Solaris 10] Cannot login through console or ssh with ipa users In-Reply-To: <54EE3781.4040400@redhat.com> References: <6a76256421cfb199ed4a9e21658c42d4.squirrel@webmail.nathanpeters.com> <54EE3781.4040400@redhat.com> Message-ID: <68d55813aaa45ea0871f17210093c820.squirrel@webmail.nathanpeters.com> > It does not seem to recognize the user in the secan attempt but the > first attempt seems to authenticate and then disconnect. > I do not see trace from accounting session but I suspect that your pam > stack does not authorize authenticated user. > Try to allow all authenticated users first. This will prove that it is a > pam stack accounting phase configuration issue. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > How do I allow all authenticated users? In the freeIPA domain I have a rule 'allow_all' that allows any user to connect to any system on any service. This is working fine for linux clients. I assume you mean to do it on the Solaris machine? I don't have any users specifically blocked, ie, there is nothing in my sshd_config file that is limiting the users and groups that can login. Eg, I've got no 'AllowUsers' lines or anything like that. I've even got PermitRootLogin set to yes and have tested that root can login. From nathan at nathanpeters.com Wed Feb 25 21:51:20 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Wed, 25 Feb 2015 13:51:20 -0800 Subject: [Freeipa-users] [SSSD] default_domain_suffix breaks IPA user logins In-Reply-To: <20150225211637.GX9792@hendrix.redhat.com> References: <11502507b62fbcd92506561dfdc55bf7.squirrel@webmail.nathanpeters.com> <20150225211637.GX9792@hendrix.redhat.com> Message-ID: > On Wed, Feb 25, 2015 at 12:11:10PM -0800, nathan at nathanpeters.com wrote: >> FreeIPA Server 4.1.2 >> FreeIPA client 3.0.0-42 >> >> I'm not sure how to go about fixing this or working around it. >> >> In our organization we have a trust relationship between >> ad.somedomain.net >> and ipadomain.net. >> >> We don't want our AD users having to type username at ad.somedomain.net >> when >> logging in to an IPA machine so we have added >> default_domain_suffix = ad.somedomain.net to the [sssd] section of >> sssd.conf. >> >> This works great when logging in with an AD user. I can login using >> 'username' and they end up with the proper shell and home directory >> /home/ad.somedomain.net/username etc. >> >> However, when I try to login with an IPA user using the username >> ipauser at ipadomain.net I am just disconnected. Removing the >> default_domain_suffix line immediately fixes , but then we lose the >> ability to login with AD users just typing their username. >> >> Does anyone know how to fix this / workaround it so we can use the >> default_domain_suffix option and not break internal FreeIPA user logins? > > Known issue: > https://fedorahosted.org/sssd/ticket/2569 > > I just acked a patch by Michal Zidek that fixes the problem. In the > meantime, > you can set: > use_fully_qualified_names = True > in the [domain] section. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > Thank you. I have confirmed that adding use_fully_qualified_names = true to my sssd conf file allows both FreeIPA and AD users to login :) From matt.wells at mosaic451.com Wed Feb 25 21:54:00 2015 From: matt.wells at mosaic451.com (Matt Wells) Date: Wed, 25 Feb 2015 13:54:00 -0800 Subject: [Freeipa-users] 2-Factor and services Message-ID: I've got many of users setup with 2-Factor and I'd like to enforce it with some services. For example. Server vpn.example.com is an openvpn servers setup to use PAM. Since he's tied to my 4.X IDM servers I can use 2-Factor with him. However I want to enforce that users from this system/service require 2-Factor. Can anyone point me in the right direction? My Google Foo is showing to be poor on this one and any guidance would be appreciated. As always thanks for taking the time to read over this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugh at psychopig.com Wed Feb 25 22:39:23 2015 From: hugh at psychopig.com (Hugh) Date: Wed, 25 Feb 2015 16:39:23 -0600 Subject: [Freeipa-users] Web UI plugins or other extensions In-Reply-To: <54EE3A94.1020804@redhat.com> References: <54ED8405.2030107@psychopig.com> <54EDE1E2.2080705@redhat.com> <54EE0042.6040509@redhat.com> <54EE1300.70104@psychopig.com> <54EE1963.1040100@redhat.com> <54EE1F4D.6000001@psychopig.com> <54EE3A94.1020804@redhat.com> Message-ID: <54EE4F1B.4050506@psychopig.com> On 2/25/2015 3:11 PM, Dmitri Pal wrote: > I think you can start with adding ntUser object class into the list of > the object classes in the IPA configuration in UI. That would apply it > to the new entries automatically. How is that done? I'd rather not have to tweak the package files, since that will cause upgrades to be problematic, as you and Petr said. > If that does not work it is probably a bug. If it works you will have > the object class right there. > > Next step is creating attributes > - ntUserDomainId - I wonder whether it can be auto-populated using > managed entry or CoS configuration in DS. If that works it will be a > config change rather than a code change which means it will survive > upgrades (most likely). > - ntUserCreateNewAccount - should be set to true AFAIU and I wonder if > it can be set to true using same managed entry or CoS mechanism. > > I am not saying that would work but that might work and would avoid > doing code changes. I couldn't find any decent documentation on managed entries or class of service functionality. Can you point me in the right direction? > If you willing to do code changes than it should be possible to just > update the user plugin to autopopulate the entries with these > attributes. But that would definitely blow up during upgrade. Yeah, that's pretty far down on the list of options for this project. But, you never know ... Hugh From nathan at nathanpeters.com Wed Feb 25 23:00:06 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Wed, 25 Feb 2015 15:00:06 -0800 Subject: [Freeipa-users] [Solaris 10] Cannot login through console or ssh with ipa users In-Reply-To: <54EE3781.4040400@redhat.com> References: <6a76256421cfb199ed4a9e21658c42d4.squirrel@webmail.nathanpeters.com> <54EE3781.4040400@redhat.com> Message-ID: <1a98bc6888577cc56a7d5667bfa15572.squirrel@webmail.nathanpeters.com> > It does not seem to recognize the user in the secan attempt but the > first attempt seems to authenticate and then disconnect. > I do not see trace from accounting session but I suspect that your pam > stack does not authorize authenticated user. > Try to allow all authenticated users first. This will prove that it is a > pam stack accounting phase configuration issue. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > I'm not sure how to enable a trace for an accounting session. Here is what I've done to enable debugging so far : add the following line to /etc/syslog.conf *.debug /var/log/pam_log svcadm restart system-log touch /etc/pam_debug cat "debug_flags=65535" > /etc/pam_debug I have a little more debugging info now than before, but it still stops at the krb5 line. See below for more detailed log. Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: Client protocol version 2.0; client software version PuTTY_Release_0.63 Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: no match: PuTTY_Release_0.63 Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: Enabling compatibility mode for protocol 2.0 Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: Local version string SSH-2.0-OpenSSH_6.6 Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: permanently_set_uid: 100/65534 [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEXINIT sent [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEXINIT received [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: kex: client->server aes256-ctr hmac-sha2-256 none [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: kex: server->client aes256-ctr hmac-sha2-256 none [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS sent [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_NEWKEYS [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS received [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: KEX done [preauth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: userauth-request for user ipauser1 service ssh-connection method none [preauth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: attempt 0 failures 0 [preauth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: PAM: initializing for "ipauser1" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 489767 auth.debug] PAM[938]: pam_start(sshd,ipauser1,811c170:812b8e0) - debug = ffff Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 984622 auth.debug] PAM[938]: pam_set_item(812b8e0:service)=sshd Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 984622 auth.debug] PAM[938]: pam_set_item(812b8e0:user)=ipauser1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 984619 auth.debug] PAM[938]: pam_set_item(812b8e0:conv)=8086ff8 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 960046 auth.debug] PAM[938]: pam_get_item(812b8e0:service)=sshd Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: login auth requisite pam_authtok_get.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: login auth required pam_dhkeys.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: login auth required pam_unix_cred.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: login auth sufficient pam_krb5.so.1 debug Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: login auth required pam_unix_auth.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: login auth required pam_dial_auth.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: rlogin auth requisite pam_authtok_get.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: rlogin auth required pam_dhkeys.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: rlogin auth required pam_unix_cred.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: rlogin auth required pam_unix_auth.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: krlogin auth required pam_unix_cred.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: krlogin auth required pam_krb5.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: rsh auth required pam_unix_cred.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: krsh auth required pam_unix_cred.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: krsh auth required pam_krb5.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: ktelnet auth required pam_unix_cred.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: ktelnet auth required pam_krb5.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: ppp auth requisite pam_authtok_get.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: ppp auth required pam_dhkeys.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: ppp auth required pam_unix_cred.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: ppp auth required pam_unix_auth.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: ppp auth required pam_dial_auth.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: other auth requisite pam_authtok_get.so.1 debug Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 531506 auth.debug] PAM[938]: read_pam_conf(812b8e0): processing "other" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 216047 auth.debug] PAM[938]: read_pam_conf(812b8e0): adding first other[auth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: other auth required pam_dhkeys.so.1 debug Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 531506 auth.debug] PAM[938]: read_pam_conf(812b8e0): processing "other" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 287990 auth.debug] PAM[938]: read_pam_conf(812b8e0): adding more other[auth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: other auth required pam_unix_cred.so.1 debug Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 531506 auth.debug] PAM[938]: read_pam_conf(812b8e0): processing "other" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 287990 auth.debug] PAM[938]: read_pam_conf(812b8e0): adding more other[auth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: other auth sufficient pam_krb5.so.1 debug Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 531506 auth.debug] PAM[938]: read_pam_conf(812b8e0): processing "other" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 287990 auth.debug] PAM[938]: read_pam_conf(812b8e0): adding more other[auth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: other auth required pam_unix_auth.so.1 debug Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 531506 auth.debug] PAM[938]: read_pam_conf(812b8e0): processing "other" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 287990 auth.debug] PAM[938]: read_pam_conf(812b8e0): adding more other[auth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: passwd auth sufficient pam_passwd_auth.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: passwd auth required pam_krb5.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: cron account required pam_unix_account.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: other account sufficient pam_krb5.so.1 debug Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 531506 auth.debug] PAM[938]: read_pam_conf(812b8e0): processing "other" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 216047 auth.debug] PAM[938]: read_pam_conf(812b8e0): adding first other[account] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: other account requisite pam_roles.so.1 debug Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 531506 auth.debug] PAM[938]: read_pam_conf(812b8e0): processing "other" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 287990 auth.debug] PAM[938]: read_pam_conf(812b8e0): adding more other[account] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: other account required pam_unix_account.so.1 debug Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 531506 auth.debug] PAM[938]: read_pam_conf(812b8e0): processing "other" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 287990 auth.debug] PAM[938]: read_pam_conf(812b8e0): adding more other[account] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: other session required pam_mkhomedir.so.1 skel=/etc/skel/ umask=0027 debug Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 531506 auth.debug] PAM[938]: read_pam_conf(812b8e0): processing "other" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 216047 auth.debug] PAM[938]: read_pam_conf(812b8e0): adding first other[session] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: other session required pam_unix_session.so.1 debug Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 531506 auth.debug] PAM[938]: read_pam_conf(812b8e0): processing "other" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 287990 auth.debug] PAM[938]: read_pam_conf(812b8e0): adding more other[session] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: other password required pam_dhkeys.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 531506 auth.debug] PAM[938]: read_pam_conf(812b8e0): processing "other" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 216047 auth.debug] PAM[938]: read_pam_conf(812b8e0): adding first other[password] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: other password requisite pam_authtok_get.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 531506 auth.debug] PAM[938]: read_pam_conf(812b8e0): processing "other" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 287990 auth.debug] PAM[938]: read_pam_conf(812b8e0): adding more other[password] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: other password requisite pam_authtok_check.so.1 force_check Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 531506 auth.debug] PAM[938]: read_pam_conf(812b8e0): processing "other" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 287990 auth.debug] PAM[938]: read_pam_conf(812b8e0): adding more other[password] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: other password sufficient pam_krb5.so.1 debug Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 531506 auth.debug] PAM[938]: read_pam_conf(812b8e0): processing "other" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 287990 auth.debug] PAM[938]: read_pam_conf(812b8e0): adding more other[password] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry: other password required pam_authtok_store.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 531506 auth.debug] PAM[938]: read_pam_conf(812b8e0): processing "other" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 287990 auth.debug] PAM[938]: read_pam_conf(812b8e0): adding more other[password] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: PAM: setting PAM_RHOST to "10.5.5.57" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 984622 auth.debug] PAM[938]: pam_set_item(812b8e0:rhost)=10.5.5.57 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: PAM: setting PAM_TTY to "ssh" Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 984622 auth.debug] PAM[938]: pam_set_item(812b8e0:tty)=ssh Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: userauth-request for user ipauser1 service ssh-connection method keyboard-interactive [preauth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: attempt 1 failures 0 [preauth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: keyboard-interactive devs [preauth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: auth2_challenge: user=ipauser1 devs= [preauth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: kbdint_alloc: devices 'pam' [preauth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: auth2_challenge_start: trying authentication method 'pam' [preauth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 960046 auth.debug] PAM[938]: pam_get_item(812b8e0:user)=ipauser1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 766510 auth.debug] PAM[940]: pam_get_item(812b8e0:user)=ipauser1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 791083 auth.debug] PAM[940]: pam_set_item(812b8e0:conv)=80868e8 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 135072 auth.debug] PAM[940]: pam_authenticate(812b8e0, 1) Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 881946 auth.debug] PAM[940]: load_modules(812b8e0, pam_sm_authenticate)=/usr/lib/security/pam_authtok_get.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 396308 auth.debug] PAM[940]: load_function: successful load of pam_sm_authenticate Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 881946 auth.debug] PAM[940]: load_modules(812b8e0, pam_sm_authenticate)=/usr/lib/security/pam_dhkeys.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 396308 auth.debug] PAM[940]: load_function: successful load of pam_sm_authenticate Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 881946 auth.debug] PAM[940]: load_modules(812b8e0, pam_sm_authenticate)=/usr/lib/security/pam_unix_cred.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 396308 auth.debug] PAM[940]: load_function: successful load of pam_sm_authenticate Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 881946 auth.debug] PAM[940]: load_modules(812b8e0, pam_sm_authenticate)=/usr/lib/security/pam_krb5.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 396308 auth.debug] PAM[940]: load_function: successful load of pam_sm_authenticate Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 881946 auth.debug] PAM[940]: load_modules(812b8e0, pam_sm_authenticate)=/usr/lib/security/pam_unix_auth.so.1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 396308 auth.debug] PAM[940]: load_function: successful load of pam_sm_authenticate Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 634615 auth.debug] pam_authtok_get:pam_sm_authenticate: flags = 1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 679169 auth.debug] PAM[940]: pam_get_user(812b8e0, 812b8e0, NULL) Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 766510 auth.debug] PAM[940]: pam_get_item(812b8e0:user)=ipauser1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 766510 auth.debug] PAM[940]: pam_get_item(812b8e0:authtok)=NULL Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 766510 auth.debug] PAM[940]: pam_get_item(812b8e0:repository)=NULL Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 766507 auth.debug] PAM[940]: pam_get_item(812b8e0:conv)=80868e8 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 340417 auth.debug] PAM[940]: pam_conv_msg(812b8e0:1[0]=Password: ) Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.info] Postponed keyboard-interactive for ipauser1 from 10.5.5.57 port 60559 ssh2 [preauth] Feb 25 22:53:06 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: server_input_channel_req: channel 0 request winadj at putty.projects.tartarus.org reply 1 Feb 25 22:53:06 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 Feb 25 22:53:06 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: session_input_channel_req: session 0 req winadj at putty.projects.tartarus.org Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 314604 auth.debug] PAM[940]: pam_conv_resp(812b8e0 pam_conv = Success) ret_respp = 80477b4 Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 569401 auth.debug] PAM[940]: pam_conv_resp(812b8e0:[0] len=8, code=0) Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 766510 auth.debug] PAM[940]: pam_get_item(812b8e0:authtok)=NULL Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 791086 auth.debug] PAM[940]: pam_set_item(812b8e0:authtok)=******** Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net last message repeated 1 time Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 736554 auth.debug] PAM[940]: pam_authenticate(812b8e0, 1): /usr/lib/security/pam_authtok_get.so.1 returned Ignore module Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 766510 auth.debug] PAM[940]: pam_get_item(812b8e0:user)=ipauser1 Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 766510 auth.debug] PAM[940]: pam_get_item(812b8e0:authtok)=******** Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 766510 auth.debug] PAM[940]: pam_get_item(812b8e0:repository)=NULL Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 736554 auth.debug] PAM[940]: pam_authenticate(812b8e0, 1): /usr/lib/security/pam_dhkeys.so.1 returned Ignore module Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 736554 auth.debug] PAM[940]: pam_authenticate(812b8e0, 1): /usr/lib/security/pam_unix_cred.so.1 returned Ignore module Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 655841 auth.debug] PAM-KRB5 (auth): pam_sm_authenticate flags=1 Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 766510 auth.debug] PAM[940]: pam_get_item(812b8e0:user)=ipauser1 Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 706257 auth.debug] PAM[940]: pam_get_data(812b8e0:SUNW-KRB5-AUTH-DATA)=PAM_NO_MODULE_DATA Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 286919 auth.debug] PAM[940]: pam_set_data(812b8e0:SUNW-KRB5-AUTH-DATA:2)=813c0f0 Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 766510 auth.debug] PAM[940]: pam_get_item(812b8e0:repository)=NULL Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 766510 auth.debug] PAM[940]: pam_get_item(812b8e0:authtok)=******** Feb 25 22:53:15 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[940]: [ID 549540 auth.debug] PAM-KRB5 (auth): attempt_krb5_auth: start: user='ipauser1' From Steven.Jones at vuw.ac.nz Wed Feb 25 23:09:22 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 25 Feb 2015 23:09:22 +0000 Subject: [Freeipa-users] 2-Factor and services In-Reply-To: References: Message-ID: <1424905633142.51631@vuw.ac.nz> Hi, So pass authentication to a RSA radius server and key fobs? Looks like RHEL7.1 can do this, I am waiting for its release to do just this. regards Steven Jones B.Eng (Hons) 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 Matt Wells Sent: Thursday, 26 February 2015 10:54 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] 2-Factor and services I've got many of users setup with 2-Factor and I'd like to enforce it with some services. For example. Server vpn.example.com is an openvpn servers setup to use PAM. Since he's tied to my 4.X IDM servers I can use 2-Factor with him. However I want to enforce that users from this system/service require 2-Factor. Can anyone point me in the right direction? My Google Foo is showing to be poor on this one and any guidance would be appreciated. As always thanks for taking the time to read over this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Feb 25 23:28:23 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 25 Feb 2015 18:28:23 -0500 Subject: [Freeipa-users] 2-Factor and services In-Reply-To: References: Message-ID: <54EE5A97.8060209@redhat.com> On 02/25/2015 04:54 PM, Matt Wells wrote: > I've got many of users setup with 2-Factor and I'd like to enforce it > with some services. > For example. > Server vpn.example.com is an openvpn servers > setup to use PAM. > Since he's tied to my 4.X IDM servers I can use 2-Factor with him. > However I want to enforce that users from this system/service require > 2-Factor. > Can anyone point me in the right direction? My Google Foo is showing > to be poor on this one and any guidance would be appreciated. > > As always thanks for taking the time to read over this. > > So do you want to use 2FA for some users and 1FA for others or do you want to have flexibility to use 2FA for the same user on one system and not another? Do you plan to use external tokens like RSA or you plan to use native OTP support in IPA? -- 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 Feb 25 23:58:31 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 25 Feb 2015 18:58:31 -0500 Subject: [Freeipa-users] [Solaris 10] Cannot login through console or ssh with ipa users In-Reply-To: <68d55813aaa45ea0871f17210093c820.squirrel@webmail.nathanpeters.com> References: <6a76256421cfb199ed4a9e21658c42d4.squirrel@webmail.nathanpeters.com> <54EE3781.4040400@redhat.com> <68d55813aaa45ea0871f17210093c820.squirrel@webmail.nathanpeters.com> Message-ID: <54EE61A7.2020304@redhat.com> On 02/25/2015 04:37 PM, nathan at nathanpeters.com wrote: >> It does not seem to recognize the user in the secan attempt but the >> first attempt seems to authenticate and then disconnect. >> I do not see trace from accounting session but I suspect that your pam >> stack does not authorize authenticated user. >> Try to allow all authenticated users first. This will prove that it is a >> pam stack accounting phase configuration issue. >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > How do I allow all authenticated users? In the freeIPA domain I have a > rule 'allow_all' that allows any user to connect to any system on any > service. This is working fine for linux clients. > > I assume you mean to do it on the Solaris machine? I don't have any users > specifically blocked, ie, there is nothing in my sshd_config file that is > limiting the users and groups that can login. Eg, I've got no > 'AllowUsers' lines or anything like that. I've even got PermitRootLogin > set to yes and have tested that root can login. > > > > other account required pam_permit.so and comment other pam modules in the section: Default definition for Account management # Used when service name is not explicitly mentioned for account management # other account requisite pam_roles.so.1 debug other account required pam_unix_account.so.1 debug #other account sufficient pam_ldap.so.1 other account required pam_krb5.so.1 debug -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Feb 26 00:18:33 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 25 Feb 2015 19:18:33 -0500 Subject: [Freeipa-users] Web UI plugins or other extensions In-Reply-To: <54EE4F1B.4050506@psychopig.com> References: <54ED8405.2030107@psychopig.com> <54EDE1E2.2080705@redhat.com> <54EE0042.6040509@redhat.com> <54EE1300.70104@psychopig.com> <54EE1963.1040100@redhat.com> <54EE1F4D.6000001@psychopig.com> <54EE3A94.1020804@redhat.com> <54EE4F1B.4050506@psychopig.com> Message-ID: <54EE6659.1000401@redhat.com> On 02/25/2015 05:39 PM, Hugh wrote: > On 2/25/2015 3:11 PM, Dmitri Pal wrote: >> I think you can start with adding ntUser object class into the list of >> the object classes in the IPA configuration in UI. That would apply it >> to the new entries automatically. > How is that done? I'd rather not have to tweak the package files, since > that will cause upgrades to be problematic, as you and Petr said. Log into UI. Go to IPA Server -> Configuration. See default user objectclasses, add a new one: ntUser. Save configuration. Add a new user in UI or command line. Check his object classes with --raw using command line. Is should now that an entry has a new object class applied to it. But I just checked the schema objectClasses: ( 2.16.840.1.113730.3.2.8 NAME 'ntUser' DESC 'Netscape defined objectclass' SUP top MUST ( ntUserDomainId ) MAY ( description $ l $ ou $ seeAlso $ ntUserPriv $ ntUserHomeDir $ ntUserComment $ ntUserFlags $ ntUserScriptPath $ ntUserAuthFlags $ ntUserUsrComment $ ntUserParms $ ntUserWorkstations $ ntUserLastLogon $ ntUserLastLogoff $ ntUserAcctExpires $ ntUserMaxStorage $ ntUserUnitsPerWeek $ ntUserLogonHours $ ntUserBadPwCount $ ntUserNumLogons $ ntUserLogonServer $ ntUserCountryCode $ ntUserCodePage $ ntUserUniqueId $ ntUserPrimaryGroupId $ ntUserProfile $ ntUserHomeDirDrive $ ntUserPasswordExpired $ ntUserCreateNewAccount $ ntUserDeleteAccount $ ntUniqueId) X-ORIGIN 'Netscape NT Synchronization' ) ntUserDomainId is a required attribute so IPA will be broken. To overcome it you might want to make it non mandatory i.e. objectClasses: ( 2.16.840.1.113730.3.2.8 NAME 'ntUser' DESC 'Netscape defined objectclass' SUP top MAY ( ntUserDomainId $ description $ l $ ou $ seeAlso $ ntUserPriv $ ntUserHomeDir $ ntUserComment $ ntUserFlags $ ntUserScriptPath $ ntUserAuthFlags $ ntUserUsrComment $ ntUserParms $ ntUserWorkstations $ ntUserLastLogon $ ntUserLastLogoff $ ntUserAcctExpires $ ntUserMaxStorage $ ntUserUnitsPerWeek $ ntUserLogonHours $ ntUserBadPwCount $ ntUserNumLogons $ ntUserLogonServer $ ntUserCountryCode $ ntUserCodePage $ ntUserUniqueId $ ntUserPrimaryGroupId $ ntUserProfile $ ntUserHomeDirDrive $ ntUserPasswordExpired $ ntUserCreateNewAccount $ ntUserDeleteAccount $ ntUniqueId) X-ORIGIN 'Netscape NT Synchronization' ) It can be found in the 50ns-directory.ldif > >> If that does not work it is probably a bug. If it works you will have >> the object class right there. >> >> Next step is creating attributes >> - ntUserDomainId - I wonder whether it can be auto-populated using >> managed entry or CoS configuration in DS. If that works it will be a >> config change rather than a code change which means it will survive >> upgrades (most likely). >> - ntUserCreateNewAccount - should be set to true AFAIU and I wonder if >> it can be set to true using same managed entry or CoS mechanism. >> >> I am not saying that would work but that might work and would avoid >> doing code changes. > I couldn't find any decent documentation on managed entries or class of > service functionality. Can you point me in the right direction? http://directory.fedoraproject.org/docs/389ds/howto/howto-classofservice.html http://www.port389.org/docs/389ds/design/managed-entry-design.html But a quick look does not seem to render what we need to do here. So here is a workaround. Create a script that will using CLI. List all the users that have ntUser object class but do not have ntUserDomainId set. If you find such entries set proper attributes using ipa user-mod command. Run it as a cron job every 5 min or so. You can also make it smarter in future to deal with your special cases. For example if your special users follow some naming convention you can instead of adding attributes strip the object class. This is the best I was able to come up with :-) > >> If you willing to do code changes than it should be possible to just >> update the user plugin to autopopulate the entries with these >> attributes. But that would definitely blow up during upgrade. > Yeah, that's pretty far down on the list of options for this project. > But, you never know ... > > Hugh > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From Less at imagine-sw.com Thu Feb 26 01:02:46 2015 From: Less at imagine-sw.com (Les Stott) Date: Thu, 26 Feb 2015 01:02:46 +0000 Subject: [Freeipa-users] ipa-getcert list fails to report correctly - RESOLVED In-Reply-To: <54EDB372.3010602@redhat.com> References: <4ED173A868981548967B4FCA27072226280C401C@AACMBXP04.exchserver.com> <54EDB372.3010602@redhat.com> Message-ID: <4ED173A868981548967B4FCA27072226280C5F99@AACMBXP04.exchserver.com> > -----Original Message----- > From: Martin Kosek [mailto:mkosek at redhat.com] > Sent: Wednesday, 25 February 2015 10:35 PM > To: Les Stott; Rob Crittenden; freeipa-users at redhat.com; Endi Dewata; Jan > Cholasta > Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly - > RESOLVED > > On 02/25/2015 03:11 AM, Les Stott wrote: > > > > > >> -----Original Message----- > >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > >> bounces at redhat.com] On Behalf Of Les Stott > >> Sent: Monday, 23 February 2015 8:01 PM > >> To: Rob Crittenden; Martin Kosek; freeipa-users at redhat.com; Endi > >> Dewata; Jan Cholasta > >> Subject: Re: [Freeipa-users] ipa-getcert list fails to report > >> correctly > >> > >> > >> > >>> -----Original Message----- > >>> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > >>> bounces at redhat.com] On Behalf Of Les Stott > >>> Sent: Monday, 23 February 2015 12:18 PM > >>> To: Rob Crittenden; Martin Kosek; freeipa-users at redhat.com; Endi > >>> Dewata; Jan Cholasta > >>> Subject: Re: [Freeipa-users] ipa-getcert list fails to report > >>> correctly > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Rob Crittenden [mailto:rcritten at redhat.com] > >>>> Sent: Saturday, 21 February 2015 1:39 AM > >>>> To: Martin Kosek; Les Stott; freeipa-users at redhat.com; Endi Dewata; > >>>> Jan Cholasta > >>>> Subject: Re: [Freeipa-users] ipa-getcert list fails to report > >>>> correctly > >>>> > >>>> Martin Kosek wrote: > >>>>> On 02/20/2015 06:56 AM, Les Stott wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> The following is blocking the ability for me to install a CA replica. > >>>>>> > >>>>>> Environment: > >>>>>> > >>>>>> RHEL 6.6 > >>>>>> > >>>>>> IPA 3.0.0-42 > >>>>>> > >>>>>> PKI 9.0.3-38 > >>>>>> > >>>>>> On the master the following is happening: > >>>>>> > >>>>>> ipa-getcert list > >>>>>> > >>>>>> Number of certificates and requests being tracked: 5. > >>>>>> > >>>>>> (but it shows no certificate details in the output) > >>>>>> > >>>>>> Running "getcert list" shows complete output. > >>>>>> > >>>>>> Also, when trying to browse > >>>>>> https://master.mydomain.com/ca/ee/ca/getCertChain i get a failed > >>>>>> response. The apache error logs on the master show.... > >>>>>> > >>>>>> [Thu Feb 19 23:23:23 2015] [error] SSL Library Error: -12271 SSL > >>>>>> client cannot verify your certificate > >>>>>> > >>>>>> The reason I am trying to browse that address is because that's > >>>>>> what the ipa-ca-install setup is failing at (it complains that > >>>>>> the CA certificate is not in proper format, in fact it's not able > >>>>>> to get it at all). > >>>>>> > >>>>>> I know from another working ipa setup that .... > >>>>>> > >>>>>> Browsing to the above address provides valid xml content and > >>>>>> ipa-getcert list shows certificate details and not just the > >>>>>> number of tracked certificates. > >>>>>> > >>>>>> Been trying for a long time to figure out the issues without luck. > >>>>>> > >>>>>> I would greatly appreciate any help to troubleshoot and resolve > >>>>>> the above issues. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Les > >>>>> > >>>>> Endi or JanC, would you have any advise for Les? To me, it looks > >>>>> like the Apache does not have proper certificate installed. > >>>>> > >>>>> My ipa-getcert on RHEL-6.6 shows 3 Server-Certs tracked, making it > >>>>> in total of 8 certs tracked: > >>>>> > >>>>> # ipa-getcert list > >>>>> Number of certificates and requests being tracked: 8. > >>>>> Request ID '20141111000002': > >>>>> status: MONITORING > >>>>> stuck: no > >>>>> key pair storage: > >>>>> type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- > >>>> COM',nicknam > >>>>> e='Server-Cert',token='NSS > >>>>> Certificate > >>>>> DB',pinfile='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- > COM/pwdfile.txt' > >>>>> certificate: > >>>>> type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- > >>>> COM',nicknam > >>>>> e='Server-Cert',token='NSS > >>>>> Certificate DB' > >>>>> CA: IPA > >>>>> issuer: CN=Certificate Authority,O=EXAMPLE.COM > >>>>> subject: CN=vm-086.example.com,O=EXAMPLE.COM > >>>>> expires: 2016-11-11 00:00:01 UTC > >>>>> key usage: > >>>>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > >>>>> eku: id-kp-serverAuth,id-kp-clientAuth > >>>>> pre-save command: > >>>>> post-save command: > >>>>> track: yes > >>>>> auto-renew: yes > >>>>> Request ID '20141111000047': > >>>>> status: MONITORING > >>>>> stuck: no > >>>>> key pair storage: > >>>>> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server- > >> Cert' > >>>>> ,token='NSS Certificate > >>>>> DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' > >>>>> certificate: > >>>>> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server- > >> Cert' > >>>>> ,token='NSS > >>>>> Certificate DB' > >>>>> CA: IPA > >>>>> issuer: CN=Certificate Authority,O=EXAMPLE.COM > >>>>> subject: CN=vm-086.example.com,O=EXAMPLE.COM > >>>>> expires: 2016-11-11 00:00:46 UTC > >>>>> key usage: > >>>>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > >>>>> eku: id-kp-serverAuth,id-kp-clientAuth > >>>>> pre-save command: > >>>>> post-save command: > >>>>> track: yes > >>>>> auto-renew: yes > >>>>> Request ID '20141111000302': > >>>>> status: MONITORING > >>>>> stuck: no > >>>>> key pair storage: > >>>>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',toke > >>>>> n= 'N SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > >>>>> certificate: > >>>>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',toke > >>>>> n= > >>>>> 'N > >>>>> SS > >>>>> Certificate DB' > >>>>> CA: IPA > >>>>> issuer: CN=Certificate Authority,O=EXAMPLE.COM > >>>>> subject: CN=vm-086.example.com,O=EXAMPLE.COM > >>>>> expires: 2016-11-11 00:03:02 UTC > >>>>> key usage: > >>>>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > >>>>> eku: id-kp-serverAuth,id-kp-clientAuth > >>>>> pre-save command: > >>>>> post-save command: > >>>>> track: yes > >>>>> auto-renew: yes > >>>>> > >>>>> > >>>>> What is actually in your Apache NSS database? > >>>>> > >>>>> # certutil -L -d /etc/httpd/alias/ > >>>>> > >>>>> Martin > >>>>> > >>>> > >>>> Remember ipa-getcert is just a shortcut for certificates using the > >>>> certmonger CA named IPA, so it's more a filter than anything else. > >>>> I don't know why it wouldn't display any output but I'd file a bug. > >>>> > >>>> I think we'd need to see the getcert list output to try to figure > >>>> out what is going on. > >>>> > >>>> As for the SSL error fetching the cert chain I think Martin may be > >>>> onto something. The request is proxied through Apache. I think the > >>>> client here might be the Apache proxy client. > >>>> > >>>> I believe this command replicates what Apache is doing, you might > >>>> give it a try on the master. This will get the chain directly from > >>>> dogtag, bypassing > >>>> Apache: > >>>> > >>>> $ curl -v --cacert /etc/ipa/ca.crt > >>>> https://`hostname`:9444/ca/ee/ca/getCertChain > >>>> > >>>> rob > >>> > >>> Certutil shows.... > >>> > >>> certutil -L -d /etc/httpd/alias/ > >>> > >>> Certificate Nickname Trust Attributes > >>> > >>> SSL,S/MIME,JAR/XPI > >>> > >>> MYDOMAIN.COM IPA CA CT,C,C > >>> ipaCert u,u,u > >>> Signing-Cert u,u,u > >>> Server-Cert u,u,u > >>> > >>> curl -v --cacert /etc/ipa/ca.crt > >>> https://`hostname`:9444/ca/ee/ca/getCertChain > >>> * About to connect() to `hostname` port 9444 (#0) > >>> * Trying 192.168.1.1... connected > >>> * Connected to `hostname` (192.168.1.1) port 9444 (#0) > >>> * Initializing NSS with certpath: sql:/etc/pki/nssdb > >>> * CAfile: /etc/ipa/ca.crt > >>> CApath: none > >>> * SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA > >>> * Server certificate: > >>> * subject: CN=`hostname`,O=MYDOMAIN.COM > >>> * start date: Dec 13 01:21:30 2013 GMT > >>> * expire date: Dec 03 01:21:30 2015 GMT > >>> * common name: `hostname` > >>> * issuer: CN=Certificate Authority,O=MYDOMAIN.COM > >>>> GET /ca/ee/ca/getCertChain HTTP/1.1 > >>>> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 > >>>> NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > >>>> Host: `hostname`:9444 > >>>> Accept: */* > >>>> > >>> < HTTP/1.1 200 OK > >>> < Server: Apache-Coyote/1.1 > >>> < Content-Type: application/xml > >>> < Content-Length: 1434 > >>> < Date: Mon, 23 Feb 2015 01:04:29 GMT < >>> encoding="UTF-8" > >>> > >> > standalone="no"?>0MIID > >>> > >> > zwYJKoZIhvcNAQcCoIIDwDCCA7wCAQExADAPBgkqhkiG9w0BBwGgAgQAoII > >>> > >> > DoDCCA5wwggKEoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwOjEYMBYGA1U > >>> > >> > EChMPREVSSVZBVElWRVMuQ09NMR4wHAYDVQQDExVDZXJ0aWZpY2F0ZSB > >>> > >> > BdXRob3JpdHkwHhcNMTMxMjEzMDEyMTI5WhcNMzMxMjEzMDEyMTI5Wj > >>> > >> > A6MRgwFgYDVQQKEw9ERVJJVkFUSVZFUy5DT00xHjAcBgNVBAMTFUNlcnRp > >>> > >> > ZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCg > >>> > >> > gEBAMAA8EaYhmpjSA8o3/1kB/W1+0K6+FrwCS+njOgRtXhiTdmtSddXSDVxH > >>> > >> > OafFwqN26BR+QRPZbbpJY70gP3SG8W+J6+c37PMVNshWz6UfChGt6ubgFxlS > >>> > >> > TGUUre2Osr9I4C836MXpGJvRx2VDEuMUxv8j7B9iDRnTDglseqPqrMct2No4w > >>> > >> > k4cLtA9puBJb0Es76SOHP9edXlf6GBnuYwR8YMc1yJLqpP8IGpHhEkVxMsRpqk > >>> > >> > EpuuRwEFa7uBcTDhqVV24BpFlseZVubpiOdEgfb3IRBTjvI1Mum9OCJbuj9P/W > >>> > >> > mqMnrA0sQsmF/R3WBwFdMAsN3+bQCRw73+rwoeDNcCAwEAAaOBrDCBq > >>> > >> > TAfBgNVHSMEGDAWgBSO8J+j2jAuyg3a0yE+3oVCQJCWUTAPBgNVHRMBAf8 > >>> > >> > EBTADAQH/MA4GA1UdDwEB/wQEAwIBxjAdBgNVHQ4EFgQUjvCfo9owLsoN > >>> > >> > 2tMhPt6FQkCQllEwRgYIKwYBBQUHAQEEOjA4MDYGCCsGAQUFBzABhipodHR > >>> wOi8vc2I! > >>> ybW9uMDEuZGVyaXZhdGl2ZXMuY29tOjgwL2* Connection #0 to host > >> `hostname` > >>> left intact > >>> * Closing connection #0 > >>> > >> > NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAKH8YkoTAzX2xNYMkZSDK84EK3 > >>> > >> > e4FUixdXxc/EC5ehjrtaqXT1KT9Fl9DAF5/jYNKqgmEmtHnPGlfQ7/Y1ESdhEGcB > >>> > >> > ZjU4qLe4HaFXuw5c9odDYxhtjQUd1g7ifY8SKOcHDCY+6Xx6F/rhFgzrXXMndn8 > >>> > >> > ZaYryctPoOAj/5INnLrJq8S4XyLmb2BHM4e1ORQbOhDi8xjhfK2veYXvIu55Brhp > >>> > >> > RSS/goz5oSE8e+QE/H9afRmeV2+WkS/YDhSyoUDb7CYjklRuONzX3GopKtp1y > >>> > >> > yLXQZnBFjCvIJvja0mo3ik3AXxSZuOwUIlV23U8CyPU/rDeiV00iUyA/fLvdkEtZkx > >>> AA== > >>> > >>> > >>> In any event, I've decided to rebuilt my DR IPA environment. Late > >>> last year the master in DR had to be rebuilt due to a disk issue. > >>> While IPA was restored manually and appeared to be working fine, CA > >>> replication hasn't worked. I finally got CA replication working in > >>> Prod after enabling needed apache modules and performing a yum > >>> update to update related packages, but these things didn't help in > >>> DR. It's my strong suspicion that something got missed when > >>> restoring the DR master IPA server and this is what is causing all > >>> my grief. Therefore, I'm going to wipe it > >> out and start from scratch in DR. > >>> There are other benefits for me to do this anyway. > >>> > >> > >> Well things have gone from bad to worse. > >> > >> I removed IPA in DR. uninstalled all ipa clients, uninstalled > >> replicas, removed replication agreements and removed the master. Ran > >> pki-remove to clear any leftover pki instances and used certutil -D > >> to remove left behind ipa entries in /etc/httpd/alias. > >> > >> So, clean slate to start again. > >> > >> This time, in order to mirror config with prod, I began an > >> installation for the master on a different server, let's call it > >> serverb. It was previously a replica (in my prod environment, serverb > >> is the true master, servera, serverc, and serverd are replicas). > >> > >> So, trying to install a new fresh instance of IPA and it still fails > >> to configure a CA. > >> > >> Attached is the relevant portion of the server install log file > >> (ipa-server- install.txt). I have removed certificate and copyright info to > reduce its size. > >> Also my server to install is serverb.mydomain.com > >> > >> Apache logs at the time of the error show: > >> [Mon Feb 23 03:05:31 2015] [error] SSL Library Error: -12195 Peer > >> does not recognize and trust the CA that issued your certificate > >> > >> Certificate databases only show the following (note that "Server-Cert > >> cert- pki-ca" got installed before the installer crashed). Prior to > >> trying installation I had to manually remove server certs left behind > >> from the previous installation via ... > >> certutil -d /etc/httpd/alias -D -n "Server-Cert" > >> certutil -d /etc/httpd/alias -D -n "MYDOMAIN.COM IPA CA" > >> certutil -d /etc/httpd/alias -D -n ipaCert > >> > >> certutil -L -d /var/lib/pki-ca/alias > >> Certificate Nickname Trust Attributes > >> SSL,S/MIME,JAR/XPI > >> Server-Cert cert-pki-ca CTu,Cu,Cu > >> > >> certutil -L -d /etc/pki/nssdb > >> Certificate Nickname Trust Attributes > >> > >> SSL,S/MIME,JAR/XPI > >> > >> > >> Selinux is in permissive mode. > >> Ausearch -m avc does show some selinux issues, but its permissive > >> mode so it should be ok right? In any event I have previously tried > >> installing a CA replica with selinux disabled and it didn't help. > >> > >> I have tried removing ipa and pki rpms and reinstalling. Then > >> rerunning the ipa server install script but the same error occurs. > >> > >> I noticed that /etc/ipa/ca.crt was still old, and referencing the original > master. > >> I removed that and again reran the installer but the same error occurred. > >> > >> Note also that /etc/ipa/cr.crt was not recreated when ipa-python was > >> reinstalled. > >> > >> Other logs: > >> > >> /var/log/pki-ca/system shows > >> 5042.main - [23/Feb/2015:03:05:12 EST] [3] [3] Cannot build CA chain. > >> Error > >> java.security.cert.CertificateException: Certificate is not a PKCS > >> #11 certificate 5042.main - [23/Feb/2015:03:05:12 EST] [13] [3] authz > >> instance DirAclAuthz initialization failed and skipped, > >> error=Property internaldb.ldapconn.port missing value > >> 5042.http-9445-1 - [23/Feb/2015:03:05:26 EST] [3] [3] Cannot build CA > chain. > >> Error java.security.cert.CertificateException: Certificate is not a > >> PKCS #11 certificate > >> 5042.http-9445-1 - [23/Feb/2015:03:05:35 EST] [3] [3] CASigningUnit: > >> Object certificate not found. Error > >> org.mozilla.jss.crypto.ObjectNotFoundException > >> > >> /var/log/pki-ca/catalina.out > >> Feb 23, 2015 3:05:11 AM org.apache.catalina.startup.HostConfig > >> deployDirectory > >> INFO: Deploying web application directory ca 64-bit osutil library > >> loaded 64-bit osutil library loaded CMS Warning: FAILURE: Cannot > >> build CA chain. Error > >> java.security.cert.CertificateException: Certificate is not a PKCS > >> #11 > >> certificate|FAILURE: authz instance DirAclAuthz initialization failed > >> certificate|and > >> skipped, error=Property internaldb.ldapconn.port missing value| > >> Server is started. > >> Feb 23, 2015 3:05:12 AM org.apache.coyote.http11.Http11Protocol start > >> INFO: Starting Coyote HTTP/1.1 on http-9180 Feb 23, 2015 3:05:12 AM > >> org.apache.coyote.http11.Http11Protocol start > >> INFO: Starting Coyote HTTP/1.1 on http-9443 Feb 23, 2015 3:05:12 AM > >> org.apache.coyote.http11.Http11Protocol start > >> INFO: Starting Coyote HTTP/1.1 on http-9445 Feb 23, 2015 3:05:12 AM > >> org.apache.coyote.http11.Http11Protocol start > >> INFO: Starting Coyote HTTP/1.1 on http-9444 Feb 23, 2015 3:05:12 AM > >> org.apache.coyote.http11.Http11Protocol start > >> INFO: Starting Coyote HTTP/1.1 on http-9446 Feb 23, 2015 3:05:12 AM > >> org.apache.jk.common.ChannelSocket init > >> INFO: JK: ajp13 listening on /0.0.0.0:9447 Feb 23, 2015 3:05:12 AM > >> org.apache.jk.server.JkMain start > >> INFO: Jk running ID=0 time=0/25 config=null Feb 23, 2015 3:05:12 AM > >> org.apache.catalina.startup.Catalina start > >> INFO: Server startup in 1655 ms > >> > >> I have no idea where to look next. There must be some remnant of the > >> old system hanging around screwing things up but I cannot figure it > >> out. This will drive me insane! > >> > >> I can provide more logs if needed. > >> > >> Thanks in advance for any help. > >> > > > > Have resolved this. > > Great! Thanks for reaching back to us. > > > Here is the procedure to completely remove FreeIPA so you can start > again. > > To me, that sounds like the FreeIPA uninstaller is missing some clean up > steps. > I would personally rather resolve it in the the actual code than just having this > information in the list archives. > > > > > ipa-server-install --uninstall > > certutil -d /etc/httpd/alias -D -n "Server-Cert" > > certutil -d /etc/httpd/alias -D -n "DERIVATIVES.COM IPA CA" > > certutil -d /etc/httpd/alias -D -n ipaCert certutil -d > > /etc/httpd/alias -D -n Signing-Cert > > This sounds like https://fedorahosted.org/freeipa/ticket/4639. We should > bump the priority if it is really causing issues. > Yes, definitely experienced this behaviour. > > yum -y remove pki-selinux pki-ca pki-common pki-setup pki-silent > > pki-java-tools pki-symkey pki-util pki-native-tools ipa-server-selinux > > ipa-server ipa-client ipa-admintools ipa-python ipa-pki-ca-theme > > ipa-pki-common-theme 389-ds-base 389-ds-base-libs userdel pkisrv > > userdel pkiuser > > This should not be needed at all, AFAIK. > Possibly not, but wanted to start with a clean system without having to reinstall the OS from scratch. > > rm -rf /etc/pki-ca /var/lib/pki-ca /var/log/pki-ca /etc/certmonger > > /etc/sysconfig/pki-ca /etc/sysconfig/pki /var/run/pki-ca.pid > > /usr/share/pki /etc/ipa /var/log/ipa* reboot > > > > Now you have a clean slate. > > Do you know which step of the steps above actually helped you resolve the > reinstall issue? > The reboot I think was key to the whole process, but pki remnants seemed left behind too which caused grief. Previously I had never rebooted the system in between uninstall/reinstall. /etc/ipa/ca.crt was also left behind. It caused an issue during one reinstall as it never got updated and the install bombed out because it found a mismatched cert. This led me to deleting all possible ipa/pki directories and then removing/reinstalling rpms to restore to default state. I noticed that in some cases (I went through this same process on 6 servers to reinstall and setup CA replicas) I could still see a left over process running as the pkiuser (tomcat/java) which stopped the "userdel pkiuser" command from completing. I had to kill that process and then userdel pkiuser worked. Regards, Les > > > > Then install works as normal for IPA Server, Replica and CA Replica > installations. > > > > Hope this saves someone else time in the future. > > > > Regards, > > > > Les > > From Less at imagine-sw.com Thu Feb 26 01:05:33 2015 From: Less at imagine-sw.com (Les Stott) Date: Thu, 26 Feb 2015 01:05:33 +0000 Subject: [Freeipa-users] ipa-getcert list fails to report correctly - RESOLVED In-Reply-To: <54EDE123.4020207@redhat.com> References: <4ED173A868981548967B4FCA27072226280C401C@AACMBXP04.exchserver.com> <54EDB372.3010602@redhat.com> <54EDE123.4020207@redhat.com> Message-ID: <4ED173A868981548967B4FCA27072226280C5FAB@AACMBXP04.exchserver.com> > -----Original Message----- > From: Endi Sukma Dewata [mailto:edewata at redhat.com] > Sent: Thursday, 26 February 2015 1:50 AM > To: Martin Kosek > Cc: Les Stott; Rob Crittenden; freeipa-users at redhat.com; Jan Cholasta > Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly - > RESOLVED > > On 2/25/2015 6:35 PM, Martin Kosek wrote: > >> yum -y remove pki-selinux pki-ca pki-common pki-setup pki-silent > >> pki-java-tools pki-symkey pki-util pki-native-tools > >> ipa-server-selinux ipa-server ipa-client ipa-admintools ipa-python > >> ipa-pki-ca-theme ipa-pki-common-theme 389-ds-base 389-ds-base-libs > >> userdel pkisrv userdel pkiuser > > > > This should not be needed at all, AFAIK. > > This may not be related to this problem, but sometimes reinstalling the > packages is necessary to resolve installation problem. For example: > https://fedorahosted.org/freeipa/ticket/4591 > In this ticket reinstalling 389-ds-base will recreate the missing folder. > I didn't actually see this issue when I ran thought reinstall, but then I did remove and reinstall 389-ds-base which would have re-created it. Regards, Les From edewata at redhat.com Thu Feb 26 02:56:02 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 26 Feb 2015 09:56:02 +0700 Subject: [Freeipa-users] ipa-getcert list fails to report correctly - RESOLVED In-Reply-To: <4ED173A868981548967B4FCA27072226280C5F99@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA27072226280C401C@AACMBXP04.exchserver.com> <54EDB372.3010602@redhat.com> <4ED173A868981548967B4FCA27072226280C5F99@AACMBXP04.exchserver.com> Message-ID: <54EE8B42.3090302@redhat.com> On 2/26/2015 8:02 AM, Les Stott wrote: >>> rm -rf /etc/pki-ca /var/lib/pki-ca /var/log/pki-ca /etc/certmonger >>> /etc/sysconfig/pki-ca /etc/sysconfig/pki /var/run/pki-ca.pid >>> /usr/share/pki /etc/ipa /var/log/ipa* reboot >>> >>> Now you have a clean slate. >> >> Do you know which step of the steps above actually helped you resolve the >> reinstall issue? >> > > The reboot I think was key to the whole process, but pki remnants seemed left behind too which caused grief. Previously I had never rebooted the system in between uninstall/reinstall. > > /etc/ipa/ca.crt was also left behind. It caused an issue during one reinstall as it never got updated and the install bombed out because it found a mismatched cert. This led me to deleting all possible ipa/pki directories and then removing/reinstalling rpms to restore to default state. > > I noticed that in some cases (I went through this same process on 6 servers to reinstall and setup CA replicas) I could still see a left over process running as the pkiuser (tomcat/java) which stopped the "userdel pkiuser" command from completing. I had to kill that process and then userdel pkiuser worked. Some of the above files/folders should have been removed automatically when the Dogtag instance/package is removed. There's already a ticket to improve this on Dogtag 10: https://fedorahosted.org/pki/ticket/1172 I created a new ticket for Dogtag 9: https://fedorahosted.org/pki/ticket/1280 Thanks! -- Endi S. Dewata From pspacek at redhat.com Thu Feb 26 08:27:40 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 26 Feb 2015 09:27:40 +0100 Subject: [Freeipa-users] Forward first not working In-Reply-To: <54EE1209.2030403@redhat.com> References: <6485FD7F-35D0-40BB-81EF-AE79D64FEBB9@blackducksoftware.com> <54EE0985.7090807@redhat.com> <54EE1209.2030403@redhat.com> Message-ID: <54EED8FC.5090709@redhat.com> On 25.2.2015 19:18, Martin Basti wrote: > And I'm not sure if forwarding between 2 authoritative zones with the same name > will work, because the zone is authoritative on IPA side, so IPA will return > authoritative answer NXDOMAIN and will not try to forward query. > You may need NS delegation to subzone. > > I suggest to create separate zones, there should not be 2 authoritative servers > with the same zone. > > FYI: Forward zones IPA 4.1: http://www.freeipa.org/page/V4/Forward_zones Martin is right. Could you clarify what are you trying to achieve? What is the use-case? Maybe we can recommend something for your particular use-case. === Background === You are trying to create 'overlay'/mix records from two authoritative zones together which is not supported by BIND. (After all, term 'authoritative' is used for a reason :-)) If you look at [1] you can see that in all cases the algorithm starts with following two steps: 1. search local database for an authoritative answer 2. if local server is authoritative, return the answer (including NXDOMAIN if DNS name was not found) In practice it means that BIND will never combine local data with data from forwarders. [1] http://www.freeipa.org/page/V4/Forward_zones#Forwarding_policy_in_forward_and_master_zones -- Petr^2 Spacek From rcritten at redhat.com Thu Feb 26 14:07:06 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Feb 2015 09:07:06 -0500 Subject: [Freeipa-users] Web UI plugins or other extensions In-Reply-To: <54EE6659.1000401@redhat.com> References: <54ED8405.2030107@psychopig.com> <54EDE1E2.2080705@redhat.com> <54EE0042.6040509@redhat.com> <54EE1300.70104@psychopig.com> <54EE1963.1040100@redhat.com> <54EE1F4D.6000001@psychopig.com> <54EE3A94.1020804@redhat.com> <54EE4F1B.4050506@psychopig.com> <54EE6659.1000401@redhat.com> Message-ID: <54EF288A.40805@redhat.com> Dmitri Pal wrote: > On 02/25/2015 05:39 PM, Hugh wrote: >> On 2/25/2015 3:11 PM, Dmitri Pal wrote: >>> I think you can start with adding ntUser object class into the list of >>> the object classes in the IPA configuration in UI. That would apply it >>> to the new entries automatically. >> How is that done? I'd rather not have to tweak the package files, since >> that will cause upgrades to be problematic, as you and Petr said. > Log into UI. Go to IPA Server -> Configuration. > See default user objectclasses, add a new one: ntUser. > Save configuration. Add a new user in UI or command line. Check his > object classes with --raw using command line. Is should now that an > entry has a new object class applied to it. > > But I just checked the schema > objectClasses: ( 2.16.840.1.113730.3.2.8 NAME 'ntUser' DESC 'Netscape > defined objectclass' SUP top MUST ( ntUserDomainId ) MAY ( description $ > l $ ou $ seeAlso $ ntUserPriv $ ntUserHomeDir $ ntUserComment $ > ntUserFlags $ ntUserScriptPath $ ntUserAuthFlags $ ntUserUsrComment $ > ntUserParms $ ntUserWorkstations $ ntUserLastLogon $ ntUserLastLogoff $ > ntUserAcctExpires $ ntUserMaxStorage $ ntUserUnitsPerWeek $ > ntUserLogonHours $ ntUserBadPwCount $ ntUserNumLogons $ > ntUserLogonServer $ ntUserCountryCode $ ntUserCodePage $ ntUserUniqueId > $ ntUserPrimaryGroupId $ ntUserProfile $ ntUserHomeDirDrive $ > ntUserPasswordExpired $ ntUserCreateNewAccount $ ntUserDeleteAccount $ > ntUniqueId) X-ORIGIN 'Netscape NT Synchronization' ) > > > ntUserDomainId is a required attribute so IPA will be broken. > To overcome it you might want to make it non mandatory i.e. > > > objectClasses: ( 2.16.840.1.113730.3.2.8 NAME 'ntUser' DESC 'Netscape > defined objectclass' SUP top MAY ( ntUserDomainId $ description $ l $ ou > $ seeAlso $ ntUserPriv $ ntUserHomeDir $ ntUserComment $ ntUserFlags $ > ntUserScriptPath $ ntUserAuthFlags $ ntUserUsrComment $ ntUserParms $ > ntUserWorkstations $ ntUserLastLogon $ ntUserLastLogoff $ > ntUserAcctExpires $ ntUserMaxStorage $ ntUserUnitsPerWeek $ > ntUserLogonHours $ ntUserBadPwCount $ ntUserNumLogons $ > ntUserLogonServer $ ntUserCountryCode $ ntUserCodePage $ ntUserUniqueId > $ ntUserPrimaryGroupId $ ntUserProfile $ ntUserHomeDirDrive $ > ntUserPasswordExpired $ ntUserCreateNewAccount $ ntUserDeleteAccount $ > ntUniqueId) X-ORIGIN 'Netscape NT Synchronization' ) > > It can be found in the 50ns-directory.ldif > >> >>> If that does not work it is probably a bug. If it works you will have >>> the object class right there. >>> >>> Next step is creating attributes >>> - ntUserDomainId - I wonder whether it can be auto-populated using >>> managed entry or CoS configuration in DS. If that works it will be a >>> config change rather than a code change which means it will survive >>> upgrades (most likely). >>> - ntUserCreateNewAccount - should be set to true AFAIU and I wonder if >>> it can be set to true using same managed entry or CoS mechanism. >>> >>> I am not saying that would work but that might work and would avoid >>> doing code changes. >> I couldn't find any decent documentation on managed entries or class of >> service functionality. Can you point me in the right direction? > > http://directory.fedoraproject.org/docs/389ds/howto/howto-classofservice.html > > http://www.port389.org/docs/389ds/design/managed-entry-design.html > > But a quick look does not seem to render what we need to do here. > > So here is a workaround. > > Create a script that will using CLI. List all the users that have ntUser > object class but do not have ntUserDomainId set. > If you find such entries set proper attributes using ipa user-mod command. > > Run it as a cron job every 5 min or so. > > You can also make it smarter in future to deal with your special cases. > For example if your special users follow some naming convention you can > instead of adding attributes strip the object class. > > > This is the best I was able to come up with :-) >> >>> If you willing to do code changes than it should be possible to just >>> update the user plugin to autopopulate the entries with these >>> attributes. But that would definitely blow up during upgrade. >> Yeah, that's pretty far down on the list of options for this project. >> But, you never know ... I think this would be fairly easily done in a plugin without having to mess with configuration or changing schema. SEe http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf slide 17. Yes, this doc is for 3.3 but the coding part should still apply to 3.0 in this limited case. I suggest this because: - you don't mind that the UI doesn't show the fields - you don't mind that this applies to all new users - you want it to persist through upgrades rob From dbischof at hrz.uni-kassel.de Thu Feb 26 15:07:38 2015 From: dbischof at hrz.uni-kassel.de (dbischof at hrz.uni-kassel.de) Date: Thu, 26 Feb 2015 16:07:38 +0100 (CET) Subject: [Freeipa-users] Replica install fails when using --setup-ca In-Reply-To: References: Message-ID: Hi, for the record: The problem was a misconfigured Apache on the IPA master, cf. https://www.redhat.com/archives/freeipa-users/2015-February/msg00041.html In my case, my Apache didn't load proxy_ajp_module and after this was fixed, ipa-replica-install --setup-ca worked as expected. Thanks to Endi Sukma Dewata and Martin Kosek for putting me on the right track. On Tue, 6 Jan 2015, dbischof at hrz.uni-kassel.de wrote: > I have two small FreeIPA installations (for two different realms), both > with CentOS 6/FreeIPA 3.0.0-42. After running them both with only one > master server each for a while, I attempted to extend both installations > with one replica each. > > Doing a > > ipa-replica-install --setup-ca /var/lib/ipa/replica-info-... > > worked fine for one of the installations, but failed for the other: > > --- > [...] > > [3/17]: configuring certificate server instance ipa : CRITICAL failed > to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent > ConfigureCA -cs_hostname xxx -cs_port 9445 -client_certdb_dir > /tmp/tmp-YsXvhP -client_certdb_pwd XXXXXXXX -preop_pin > vJl0m3xc9Oz7b1fIgttD -domain_name IPA -admin_user admin -admin_email > root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent > -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject > CN=ipa-ca-agent,O=YYY -ldap_host xxx -ldap_port 7389 -bind_dn > cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name > ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA > -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name > internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=YYY > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=YYY > -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=YYY > -ca_server_cert_subject_name CN=xxx,O=YYY > -ca_audit_signing_cert_subject_name CN=CA Audit,O=YYY > -ca_sign_cert_subject_name CN=Certificate Authority,O=YYY -external > false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX > -sd_hostname mmm -sd_admin_port 443 -sd_admin_name admin > -sd_admin_password XXXXXXXX -clone_start_tls true -clone_uri > https://mmm:443' returned non-zero exit status 255 > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > --- > > /var/log/ipareplica-install.log: > > --- > [...] > Error in DomainPanel(): updateStatus value is null > ERROR: ConfigureCA: DomainPanel() failure > ERROR: unable to create CA > > ####################################################################### > > 2015-01-06T13:36:25Z DEBUG stderr= > 2015-01-06T13:36:25Z CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > 2015-01-06T13:36:25Z INFO File > "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", line > 614, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-replica-install", line 476, in main > (CA, cs) = cainstance.install_replica_ca(config) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line > 1626, in install_replica_ca > subject_base=config.subject_base) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line > 626, in configure_instance > self.start_creation(runtime=210) > > File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", > line 358, in start_creation > method() > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line > 888, in __configure_instance > raise RuntimeError('Configuration of CA failed') > > 2015-01-06T13:36:25Z INFO The ipa-replica-install command failed, > exception: RuntimeError: Configuration of CA failed > --- > > Omitting "--setup-ca" lets me successfully install a working replica > server. > > The problem appears to be my installation (since the other one works) - > however: Both (intended) replica servers are nearly identical (operating > system version, installed packages, etc.). > > My understanding is that a replica without a CA is not a 100%-clone of a > IPA master, right? What are the downsides of having a replica without a > CA? Mit freundlichen Gruessen/With best regards, --Daniel. From matt.wells at mosaic451.com Thu Feb 26 17:40:18 2015 From: matt.wells at mosaic451.com (Matt Wells) Date: Thu, 26 Feb 2015 09:40:18 -0800 Subject: [Freeipa-users] Fwd: 2-Factor and services In-Reply-To: References: Message-ID: Had an error on my options for the list and the replies failed to get to me. We'll see if this reply works. :) @Dmitri - Anyone coming through this service/host (OpenVPN with pam) will be required to use 2-Factor. Their normal logins at their desk are not required for 2-factor, it's ok if they use it but it's not required at all. This VPN service is as assumed, exposed to the internet. We're wanting to protect ourselves as best we can with AAA. ------------------------------- I've got many of users setup with 2-Factor and I'd like to enforce it with some services. For example. Server vpn.example.com is an openvpn servers setup to use PAM. Since he's tied to my 4.X IDM servers I can use 2-Factor with him. However I want to enforce that users from this system/service require 2-Factor. Can anyone point me in the right direction? My Google Foo is showing to be poor on this one and any guidance would be appreciated. As always thanks for taking the time to read over this. So do you want to use 2FA for some users and 1FA for others or do you want to have flexibility to use 2FA for the same user on one system and not another? Do you plan to use external tokens like RSA or you plan to use native OTP support in IPA? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Matt Wells Chief Systems Architect RHCVA, RHCA #110-000-353 (702) 808-0424 matt.wells at mosaic451.com Las Vegas | Phoenix | Portland Mosaic451.com CONFIDENTIALITY NOTICE: This transmittal is a confidential communication or may otherwise be privileged. If you are not intended recipient, you are hereby notified that you have received this transmittal in error and that any review, dissemination, distribution or copying of this transmittal is strictly prohibited. If you have received this communication in error, please notify this office, and immediately delete this message and all its attachments, if any. From nathan at nathanpeters.com Thu Feb 26 18:15:21 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Thu, 26 Feb 2015 10:15:21 -0800 Subject: [Freeipa-users] [Solaris 10] Cannot login through console or ssh with ipa users In-Reply-To: <54EE61A7.2020304@redhat.com> References: <6a76256421cfb199ed4a9e21658c42d4.squirrel@webmail.nathanpeters.com> <54EE3781.4040400@redhat.com> <68d55813aaa45ea0871f17210093c820.squirrel@webmail.nathanpeters.com> <54EE61A7.2020304@redhat.com> Message-ID: <8912f5330c977b8a1d302c62ce148fab.squirrel@webmail.nathanpeters.com> > On 02/25/2015 04:37 PM, nathan at nathanpeters.com wrote: >>> It does not seem to recognize the user in the secan attempt but the >>> first attempt seems to authenticate and then disconnect. >>> I do not see trace from accounting session but I suspect that your pam >>> stack does not authorize authenticated user. >>> Try to allow all authenticated users first. This will prove that it is >>> a >>> pam stack accounting phase configuration issue. >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project >>> >> How do I allow all authenticated users? In the freeIPA domain I have a >> rule 'allow_all' that allows any user to connect to any system on any >> service. This is working fine for linux clients. >> >> I assume you mean to do it on the Solaris machine? I don't have any >> users >> specifically blocked, ie, there is nothing in my sshd_config file that >> is >> limiting the users and groups that can login. Eg, I've got no >> 'AllowUsers' lines or anything like that. I've even got PermitRootLogin >> set to yes and have tested that root can login. >> >> >> >> > > other account required pam_permit.so > > and comment other pam modules in the section: > > Default definition for Account management > # Used when service name is not explicitly mentioned for account > management > # > other account requisite pam_roles.so.1 debug > other account required pam_unix_account.so.1 debug > #other account sufficient pam_ldap.so.1 > other account required pam_krb5.so.1 debug > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > pam_permit does not exist in Solaris 10 so I cannot use that to test. The only way I could break down where the error is happening is to restore to a completely default pam.conf and add the krb5.so entries 1 at a time. The first entry was added fine in the login section although I noted that the 'try_first_pass' option also does not exist in Solaris, so not sure why the guide for Solaris is saying to use that: login auth sufficient pam_krb5.so.1 The following entry is what broke the system : other auth sufficient pam_krb5.so.1 I placed it in the same place as in the guide (under unix_cred and before unix_auth). So we know its the auth thats failing, not the account? Here is how it broke : root can no longer login through ssh. I compared the log entries for logins before and after the auth change and they are identical up to about line 127. I noticed that the login that failed threw a strange krb5 pam_no_module_data error before disconnecting the ssh client. Here are the 2 logs for reference: unsuccessful root login ----------------------- Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID 872586 auth.debug] PAM[494]: pam_authenticate(812bf10, 1): /usr/lib/security/pam_authtok_get.so.1 returned Ignore module Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID 455340 auth.debug] PAM[494]: pam_get_item(812bf10:user)=root Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID 455340 auth.debug] PAM[494]: pam_get_item(812bf10:authtok)=******** Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID 455340 auth.debug] PAM[494]: pam_get_item(812bf10:repository)=NULL Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID 872586 auth.debug] PAM[494]: pam_authenticate(812bf10, 1): /usr/lib/security/pam_dhkeys.so.1 returned Ignore module Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID 872586 auth.debug] PAM[494]: pam_authenticate(812bf10, 1): /usr/lib/security/pam_unix_cred.so.1 returned Ignore module Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID 455340 auth.debug] PAM[494]: pam_get_item(812bf10:user)=root Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID 395087 auth.debug] PAM[494]: pam_get_data(812bf10:SUNW-KRB5-AUTH-DATA)=PAM_NO_MODULE_DATA Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID 140038 auth.debug] PAM[494]: pam_set_data(812bf10:SUNW-KRB5-AUTH-DATA:2)=812cc20 Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID 455340 auth.debug] PAM[494]: pam_get_item(812bf10:repository)=NULL Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID 455340 auth.debug] PAM[494]: pam_get_item(812bf10:authtok)=******** successful root login --------------------- Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 806026 auth.debug] PAM[482]: pam_authenticate(812e218, 1): /usr/lib/security/pam_authtok_get.so.1 returned Ignore module Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 390833 auth.debug] PAM[482]: pam_get_item(812e218:user)=root Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 390833 auth.debug] PAM[482]: pam_get_item(812e218:authtok)=******** Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 390833 auth.debug] PAM[482]: pam_get_item(812e218:repository)=NULL Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 806026 auth.debug] PAM[482]: pam_authenticate(812e218, 1): /usr/lib/security/pam_dhkeys.so.1 returned Ignore module Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 806026 auth.debug] PAM[482]: pam_authenticate(812e218, 1): /usr/lib/security/pam_unix_cred.so.1 returned Ignore module Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 390833 auth.debug] PAM[482]: pam_get_item(812e218:user)=root Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 390833 auth.debug] PAM[482]: pam_get_item(812e218:authtok)=******** Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 390833 auth.debug] PAM[482]: pam_get_item(812e218:repository)=NULL Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 806026 auth.debug] PAM[482]: pam_authenticate(812e218, 1): /usr/lib/security/pam_unix_auth.so.1 returned Success Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 361950 auth.debug] PAM[482]: pam_authenticate(812e218, 1): final: Success Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 800047 auth.debug] debug1: do_pam_account: called Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 690203 auth.debug] PAM[482]: pam_acct_mgmt(812e218, 0) Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 130549 auth.debug] PAM[482]: load_modules(812e218, pam_sm_acct_mgmt)=/usr/lib/security/pam_roles.so.1 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 149591 auth.debug] PAM[482]: load_function: successful load of pam_sm_acct_mgmt Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 130549 auth.debug] PAM[482]: load_modules(812e218, pam_sm_acct_mgmt)=/usr/lib/security/pam_unix_account.so.1 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 149591 auth.debug] PAM[482]: load_function: successful load of pam_sm_acct_mgmt Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 390833 auth.debug] PAM[482]: pam_get_item(812e218:user)=root Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 390833 auth.debug] PAM[482]: pam_get_item(812e218:auser)=NULL Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 390833 auth.debug] PAM[482]: pam_get_item(812e218:ruser)=NULL Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 390833 auth.debug] PAM[482]: pam_get_item(812e218:rhost)=10.5.5.57 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 806026 auth.debug] PAM[482]: pam_acct_mgmt(812e218, 0): /usr/lib/security/pam_roles.so.1 returned Ignore module Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 390833 auth.debug] PAM[482]: pam_get_item(812e218:user)=root Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 390833 auth.debug] PAM[482]: pam_get_item(812e218:repository)=NULL Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 330580 auth.debug] PAM[482]: pam_get_data(812e218:SUNW-UNIX-AUTHTOK-DATA)=PAM_NO_MODULE_DATA Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 710061 auth.debug] PAM[482]: pam_set_data(812e218:SUNW-UNIX-AUTHTOK-DATA:2)=812e880 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 806026 auth.debug] PAM[482]: pam_acct_mgmt(812e218, 0): /usr/lib/security/pam_unix_account.so.1 returned Success Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 361950 auth.debug] PAM[482]: pam_acct_mgmt(812e218, 0): final: Success Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID 804632 auth.debug] PAM[482]: pam_getenvlist(812e218) Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: PAM: num PAM env strings 0 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.info] Postponed keyboard-interactive/pam for root from 10.5.5.57 port 53885 ssh2 [preauth] Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: do_pam_account: called Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.info] Accepted keyboard-interactive/pam for root from 10.5.5.57 port 53885 ssh2 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: monitor_child_preauth: root has been authenticated by privileged process Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: monitor_read_log: child log fd closed Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 415390 auth.debug] PAM[480]: pam_set_item(812e218:conv)=8086ff8 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: PAM: establishing credentials Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 690202 auth.debug] PAM[480]: pam_setcred(812e218, 1) Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 259530 auth.debug] PAM[480]: load_modules(812e218, pam_sm_setcred)=/usr/lib/security/pam_authtok_get.so.1 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 985081 auth.debug] PAM[480]: load_function: successful load of pam_sm_setcred Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 259530 auth.debug] PAM[480]: load_modules(812e218, pam_sm_setcred)=/usr/lib/security/pam_dhkeys.so.1 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 985081 auth.debug] PAM[480]: load_function: successful load of pam_sm_setcred Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 259530 auth.debug] PAM[480]: load_modules(812e218, pam_sm_setcred)=/usr/lib/security/pam_unix_cred.so.1 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 985081 auth.debug] PAM[480]: load_function: successful load of pam_sm_setcred Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 259530 auth.debug] PAM[480]: load_modules(812e218, pam_sm_setcred)=/usr/lib/security/pam_unix_auth.so.1 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 985081 auth.debug] PAM[480]: load_function: successful load of pam_sm_setcred Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 740490 auth.debug] PAM[480]: pam_setcred(812e218, 1): /usr/lib/security/pam_authtok_get.so.1 returned Ignore module Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 390817 auth.debug] PAM[480]: pam_get_item(812e218:user)=root Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 390817 auth.debug] PAM[480]: pam_get_item(812e218:authtok)=NULL Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 740490 auth.debug] PAM[480]: pam_setcred(812e218, 1): /usr/lib/security/pam_dhkeys.so.1 returned Ignore module Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 390817 auth.debug] PAM[480]: pam_get_item(812e218:user)=root Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 390817 auth.debug] PAM[480]: pam_get_item(812e218:auser)=NULL Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 390817 auth.debug] PAM[480]: pam_get_item(812e218:rhost)=10.5.5.57 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 390817 auth.debug] PAM[480]: pam_get_item(812e218:tty)=ssh Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 390817 auth.debug] PAM[480]: pam_get_item(812e218:resource)=NULL Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 740490 auth.debug] PAM[480]: pam_setcred(812e218, 1): /usr/lib/security/pam_unix_cred.so.1 returned Success Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 740490 auth.debug] PAM[480]: pam_setcred(812e218, 1): /usr/lib/security/pam_unix_auth.so.1 returned Ignore module Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 361438 auth.debug] PAM[480]: pam_setcred(812e218, 1): final: Success Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 415390 auth.debug] PAM[480]: pam_set_item(812e218:conv)=8086ff8 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 690202 auth.debug] PAM[480]: pam_open_session(812e218, 0) Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 259530 auth.debug] PAM[480]: load_modules(812e218, pam_sm_open_session)=/usr/lib/security/pam_unix_session.so.1 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 985081 auth.debug] PAM[480]: load_function: successful load of pam_sm_open_session Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 390817 auth.debug] PAM[480]: pam_get_item(812e218:tty)=ssh Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 390817 auth.debug] PAM[480]: pam_get_item(812e218:user)=root Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 390817 auth.debug] PAM[480]: pam_get_item(812e218:rhost)=10.5.5.57 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 740490 auth.debug] PAM[480]: pam_open_session(812e218, 0): /usr/lib/security/pam_unix_session.so.1 returned Success Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 361438 auth.debug] PAM[480]: pam_open_session(812e218, 0): final: Success Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: Entering interactive session for SSH2. Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: server_init_dispatch_20 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: input_session_request Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: channel 0: new [server-session] Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: session_new: session 0 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: session_open: channel 0 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: session_open: session 0: link with channel 0 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: server_input_channel_open: confirm session Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: server_input_channel_req: channel 0 request pty-req reply 1 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: session_input_channel_req: session 0 req pty-req Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: Allocating pty. Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: session_pty_req: session 0 alloc /dev/pts/2 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: server_input_channel_req: channel 0 request shell reply 1 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.debug] debug1: session_input_channel_req: session 0 req shell Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID 800047 auth.info] Starting session: shell on pts/2 for root from 10.5.5.57 port 53885 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID 415422 auth.debug] PAM[484]: pam_set_item(812e218:conv)=8086ff8 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID 800047 auth.debug] debug1: PAM: reinitializing credentials Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID 690204 auth.debug] PAM[484]: pam_setcred(812e218, 4) Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID 259531 auth.debug] PAM[484]: load_modules(812e218, pam_sm_setcred)=/usr/lib/security/pam_authtok_get.so.1 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID 871562 auth.debug] PAM[484]: pam_setcred(812e218, 4): /usr/lib/security/pam_authtok_get.so.1 returned Ignore module Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID 871562 auth.debug] PAM[484]: pam_setcred(812e218, 4): /usr/lib/security/pam_dhkeys.so.1 returned Ignore module Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID 390849 auth.debug] PAM[484]: pam_get_item(812e218:user)=root Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID 390849 auth.debug] PAM[484]: pam_get_item(812e218:auser)=NULL Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID 390849 auth.debug] PAM[484]: pam_get_item(812e218:rhost)=10.5.5.57 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID 390849 auth.debug] PAM[484]: pam_get_item(812e218:tty)=ssh Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID 390849 auth.debug] PAM[484]: pam_get_item(812e218:resource)=NULL Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID 871562 auth.debug] PAM[484]: pam_setcred(812e218, 4): /usr/lib/security/pam_unix_cred.so.1 returned Success Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID 871562 auth.debug] PAM[484]: pam_setcred(812e218, 4): /usr/lib/security/pam_unix_auth.so.1 returned Ignore module Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID 362462 auth.debug] PAM[484]: pam_setcred(812e218, 4): final: Success Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID 800047 auth.debug] debug1: permanently_set_uid: 0/0 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID 482209 auth.debug] PAM[484]: pam_getenvlist(812e218) Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[414]: [ID 800047 auth.debug] debug1: server_input_channel_req: channel 0 request winadj at putty.projects.tartarus.org reply 1 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[414]: [ID 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[414]: [ID 800047 auth.debug] debug1: session_input_channel_req: session 0 req winadj at putty.projects.tartarus.org Feb 26 17:45:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[414]: [ID 800047 auth.debug] debug1: server_input_channel_req: channel 0 request window-change reply 0 Feb 26 17:45:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[414]: [ID 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 Feb 26 17:45:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[414]: [ID 800047 auth.debug] debug1: session_input_channel_req: session 0 req window-change From dpal at redhat.com Thu Feb 26 22:09:45 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 26 Feb 2015 17:09:45 -0500 Subject: [Freeipa-users] Fwd: 2-Factor and services In-Reply-To: References: Message-ID: <54EF99A9.1070701@redhat.com> On 02/26/2015 12:40 PM, Matt Wells wrote: > Had an error on my options for the list and the replies failed to get > to me. We'll see if this reply works. :) > > @Dmitri - Anyone coming through this service/host (OpenVPN with pam) > will be required to use 2-Factor. Their normal logins at their desk > are not required for 2-factor, it's ok if they use it but it's not > required at all. > This VPN service is as assumed, exposed to the internet. We're > wanting to protect ourselves as best we can with AAA. If we just talking about managing users in IdM and having tokens for them managed in IdM too then the recommendation is: - Set users to use OTP or password (set both check boxes) - Configure VPN to use Kerberos authentication against IPA - that will force use of 2FA with the policy above - Configure computers at the desk to use LDAP (you loose Kerberos SSO) - that would allow single factor with the policy above What are your desktops? Lunux? Mac? Is there any AD involved? > > > ------------------------------- > I've got many of users setup with 2-Factor and I'd like to enforce it > with some services. > For example. > Server vpn.example.com is an openvpn servers setup to use PAM. > Since he's tied to my 4.X IDM servers I can use 2-Factor with him. > However I want to enforce that users from this system/service require > 2-Factor. > Can anyone point me in the right direction? My Google Foo is showing > to be poor on this one and any guidance would be appreciated. > > As always thanks for taking the time to read over this. > > > So do you want to use 2FA for some users and 1FA for others or do you > want to have flexibility to use 2FA for the same user on one system > and not another? > Do you plan to use external tokens like RSA or you plan to use native > OTP support in IPA? > > > > > -- > 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 Feb 26 22:12:13 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 26 Feb 2015 17:12:13 -0500 Subject: [Freeipa-users] [Solaris 10] Cannot login through console or ssh with ipa users In-Reply-To: <8912f5330c977b8a1d302c62ce148fab.squirrel@webmail.nathanpeters.com> References: <6a76256421cfb199ed4a9e21658c42d4.squirrel@webmail.nathanpeters.com> <54EE3781.4040400@redhat.com> <68d55813aaa45ea0871f17210093c820.squirrel@webmail.nathanpeters.com> <54EE61A7.2020304@redhat.com> <8912f5330c977b8a1d302c62ce148fab.squirrel@webmail.nathanpeters.com> Message-ID: <54EF9A3D.60608@redhat.com> On 02/26/2015 01:15 PM, nathan at nathanpeters.com wrote: >> On 02/25/2015 04:37 PM, nathan at nathanpeters.com wrote: >>>> It does not seem to recognize the user in the secan attempt but the >>>> first attempt seems to authenticate and then disconnect. >>>> I do not see trace from accounting session but I suspect that your pam >>>> stack does not authorize authenticated user. >>>> Try to allow all authenticated users first. This will prove that it is >>>> a >>>> pam stack accounting phase configuration issue. >>>> >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager IdM portfolio >>>> Red Hat, Inc. >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go To http://freeipa.org for more info on the project >>>> >>> How do I allow all authenticated users? In the freeIPA domain I have a >>> rule 'allow_all' that allows any user to connect to any system on any >>> service. This is working fine for linux clients. >>> >>> I assume you mean to do it on the Solaris machine? I don't have any >>> users >>> specifically blocked, ie, there is nothing in my sshd_config file that >>> is >>> limiting the users and groups that can login. Eg, I've got no >>> 'AllowUsers' lines or anything like that. I've even got PermitRootLogin >>> set to yes and have tested that root can login. >>> >>> >>> >>> >> other account required pam_permit.so >> >> and comment other pam modules in the section: >> >> Default definition for Account management >> # Used when service name is not explicitly mentioned for account >> management >> # >> other account requisite pam_roles.so.1 debug >> other account required pam_unix_account.so.1 debug >> #other account sufficient pam_ldap.so.1 >> other account required pam_krb5.so.1 debug >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > pam_permit does not exist in Solaris 10 so I cannot use that to test. The > only way I could break down where the error is happening is to restore to > a completely default pam.conf and add the krb5.so entries 1 at a time. > > The first entry was added fine in the login section although I noted that > the 'try_first_pass' option also does not exist in Solaris, so not sure > why the guide for Solaris is saying to use that: > login auth sufficient pam_krb5.so.1 > > The following entry is what broke the system : > other auth sufficient pam_krb5.so.1 > > I placed it in the same place as in the guide (under unix_cred and before > unix_auth). So we know its the auth thats failing, not the account? > > Here is how it broke : root can no longer login through ssh. > > I compared the log entries for logins before and after the auth change and > they are identical up to about line 127. > > I noticed that the login that failed threw a strange krb5 > pam_no_module_data error before disconnecting the ssh client. > > Here are the 2 logs for reference: > > unsuccessful root login > ----------------------- > Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID > 872586 auth.debug] PAM[494]: pam_authenticate(812bf10, 1): > /usr/lib/security/pam_authtok_get.so.1 returned Ignore module > Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID > 455340 auth.debug] PAM[494]: pam_get_item(812bf10:user)=root > Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID > 455340 auth.debug] PAM[494]: pam_get_item(812bf10:authtok)=******** > Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID > 455340 auth.debug] PAM[494]: pam_get_item(812bf10:repository)=NULL > Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID > 872586 auth.debug] PAM[494]: pam_authenticate(812bf10, 1): > /usr/lib/security/pam_dhkeys.so.1 returned Ignore module > Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID > 872586 auth.debug] PAM[494]: pam_authenticate(812bf10, 1): > /usr/lib/security/pam_unix_cred.so.1 returned Ignore module > Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID > 455340 auth.debug] PAM[494]: pam_get_item(812bf10:user)=root > Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID > 395087 auth.debug] PAM[494]: > pam_get_data(812bf10:SUNW-KRB5-AUTH-DATA)=PAM_NO_MODULE_DATA > Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID > 140038 auth.debug] PAM[494]: > pam_set_data(812bf10:SUNW-KRB5-AUTH-DATA:2)=812cc20 > Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID > 455340 auth.debug] PAM[494]: pam_get_item(812bf10:repository)=NULL > Feb 26 17:51:57 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[494]: [ID > 455340 auth.debug] PAM[494]: pam_get_item(812bf10:authtok)=******** > > > successful root login > --------------------- > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 806026 auth.debug] PAM[482]: pam_authenticate(812e218, 1): > /usr/lib/security/pam_authtok_get.so.1 returned Ignore module > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 390833 auth.debug] PAM[482]: pam_get_item(812e218:user)=root > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 390833 auth.debug] PAM[482]: pam_get_item(812e218:authtok)=******** > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 390833 auth.debug] PAM[482]: pam_get_item(812e218:repository)=NULL > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 806026 auth.debug] PAM[482]: pam_authenticate(812e218, 1): > /usr/lib/security/pam_dhkeys.so.1 returned Ignore module > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 806026 auth.debug] PAM[482]: pam_authenticate(812e218, 1): > /usr/lib/security/pam_unix_cred.so.1 returned Ignore module > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 390833 auth.debug] PAM[482]: pam_get_item(812e218:user)=root > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 390833 auth.debug] PAM[482]: pam_get_item(812e218:authtok)=******** > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 390833 auth.debug] PAM[482]: pam_get_item(812e218:repository)=NULL > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 806026 auth.debug] PAM[482]: pam_authenticate(812e218, 1): > /usr/lib/security/pam_unix_auth.so.1 returned Success > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 361950 auth.debug] PAM[482]: pam_authenticate(812e218, 1): final: Success > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 800047 auth.debug] debug1: do_pam_account: called > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 690203 auth.debug] PAM[482]: pam_acct_mgmt(812e218, 0) > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 130549 auth.debug] PAM[482]: load_modules(812e218, > pam_sm_acct_mgmt)=/usr/lib/security/pam_roles.so.1 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 149591 auth.debug] PAM[482]: load_function: successful load of > pam_sm_acct_mgmt > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 130549 auth.debug] PAM[482]: load_modules(812e218, > pam_sm_acct_mgmt)=/usr/lib/security/pam_unix_account.so.1 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 149591 auth.debug] PAM[482]: load_function: successful load of > pam_sm_acct_mgmt > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 390833 auth.debug] PAM[482]: pam_get_item(812e218:user)=root > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 390833 auth.debug] PAM[482]: pam_get_item(812e218:auser)=NULL > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 390833 auth.debug] PAM[482]: pam_get_item(812e218:ruser)=NULL > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 390833 auth.debug] PAM[482]: pam_get_item(812e218:rhost)=10.5.5.57 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 806026 auth.debug] PAM[482]: pam_acct_mgmt(812e218, 0): > /usr/lib/security/pam_roles.so.1 returned Ignore module > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 390833 auth.debug] PAM[482]: pam_get_item(812e218:user)=root > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 390833 auth.debug] PAM[482]: pam_get_item(812e218:repository)=NULL > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 330580 auth.debug] PAM[482]: > pam_get_data(812e218:SUNW-UNIX-AUTHTOK-DATA)=PAM_NO_MODULE_DATA > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 710061 auth.debug] PAM[482]: > pam_set_data(812e218:SUNW-UNIX-AUTHTOK-DATA:2)=812e880 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 806026 auth.debug] PAM[482]: pam_acct_mgmt(812e218, 0): > /usr/lib/security/pam_unix_account.so.1 returned Success > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 361950 auth.debug] PAM[482]: pam_acct_mgmt(812e218, 0): final: Success > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[482]: [ID > 804632 auth.debug] PAM[482]: pam_getenvlist(812e218) > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: PAM: num PAM env strings 0 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.info] Postponed keyboard-interactive/pam for root from > 10.5.5.57 port 53885 ssh2 [preauth] > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: do_pam_account: called > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.info] Accepted keyboard-interactive/pam for root from > 10.5.5.57 port 53885 ssh2 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: monitor_child_preauth: root has been > authenticated by privileged process > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: monitor_read_log: child log fd closed > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 415390 auth.debug] PAM[480]: pam_set_item(812e218:conv)=8086ff8 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: PAM: establishing credentials > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 690202 auth.debug] PAM[480]: pam_setcred(812e218, 1) > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 259530 auth.debug] PAM[480]: load_modules(812e218, > pam_sm_setcred)=/usr/lib/security/pam_authtok_get.so.1 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 985081 auth.debug] PAM[480]: load_function: successful load of > pam_sm_setcred > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 259530 auth.debug] PAM[480]: load_modules(812e218, > pam_sm_setcred)=/usr/lib/security/pam_dhkeys.so.1 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 985081 auth.debug] PAM[480]: load_function: successful load of > pam_sm_setcred > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 259530 auth.debug] PAM[480]: load_modules(812e218, > pam_sm_setcred)=/usr/lib/security/pam_unix_cred.so.1 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 985081 auth.debug] PAM[480]: load_function: successful load of > pam_sm_setcred > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 259530 auth.debug] PAM[480]: load_modules(812e218, > pam_sm_setcred)=/usr/lib/security/pam_unix_auth.so.1 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 985081 auth.debug] PAM[480]: load_function: successful load of > pam_sm_setcred > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 740490 auth.debug] PAM[480]: pam_setcred(812e218, 1): > /usr/lib/security/pam_authtok_get.so.1 returned Ignore module > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 390817 auth.debug] PAM[480]: pam_get_item(812e218:user)=root > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 390817 auth.debug] PAM[480]: pam_get_item(812e218:authtok)=NULL > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 740490 auth.debug] PAM[480]: pam_setcred(812e218, 1): > /usr/lib/security/pam_dhkeys.so.1 returned Ignore module > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 390817 auth.debug] PAM[480]: pam_get_item(812e218:user)=root > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 390817 auth.debug] PAM[480]: pam_get_item(812e218:auser)=NULL > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 390817 auth.debug] PAM[480]: pam_get_item(812e218:rhost)=10.5.5.57 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 390817 auth.debug] PAM[480]: pam_get_item(812e218:tty)=ssh > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 390817 auth.debug] PAM[480]: pam_get_item(812e218:resource)=NULL > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 740490 auth.debug] PAM[480]: pam_setcred(812e218, 1): > /usr/lib/security/pam_unix_cred.so.1 returned Success > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 740490 auth.debug] PAM[480]: pam_setcred(812e218, 1): > /usr/lib/security/pam_unix_auth.so.1 returned Ignore module > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 361438 auth.debug] PAM[480]: pam_setcred(812e218, 1): final: Success > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 415390 auth.debug] PAM[480]: pam_set_item(812e218:conv)=8086ff8 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 690202 auth.debug] PAM[480]: pam_open_session(812e218, 0) > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 259530 auth.debug] PAM[480]: load_modules(812e218, > pam_sm_open_session)=/usr/lib/security/pam_unix_session.so.1 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 985081 auth.debug] PAM[480]: load_function: successful load of > pam_sm_open_session > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 390817 auth.debug] PAM[480]: pam_get_item(812e218:tty)=ssh > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 390817 auth.debug] PAM[480]: pam_get_item(812e218:user)=root > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 390817 auth.debug] PAM[480]: pam_get_item(812e218:rhost)=10.5.5.57 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 740490 auth.debug] PAM[480]: pam_open_session(812e218, 0): > /usr/lib/security/pam_unix_session.so.1 returned Success > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 361438 auth.debug] PAM[480]: pam_open_session(812e218, 0): final: Success > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: Entering interactive session for SSH2. > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: server_init_dispatch_20 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: server_input_channel_open: ctype session rchan > 256 win 16384 max 16384 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: input_session_request > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: channel 0: new [server-session] > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: session_new: session 0 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: session_open: channel 0 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: session_open: session 0: link with channel 0 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: server_input_channel_open: confirm session > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: server_input_channel_req: channel 0 request > pty-req reply 1 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: session_input_channel_req: session 0 req > pty-req > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: Allocating pty. > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: session_pty_req: session 0 alloc /dev/pts/2 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: server_input_channel_req: channel 0 request > shell reply 1 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.debug] debug1: session_input_channel_req: session 0 req shell > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[480]: [ID > 800047 auth.info] Starting session: shell on pts/2 for root from 10.5.5.57 > port 53885 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID > 415422 auth.debug] PAM[484]: pam_set_item(812e218:conv)=8086ff8 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID > 800047 auth.debug] debug1: PAM: reinitializing credentials > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID > 690204 auth.debug] PAM[484]: pam_setcred(812e218, 4) > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID > 259531 auth.debug] PAM[484]: load_modules(812e218, > pam_sm_setcred)=/usr/lib/security/pam_authtok_get.so.1 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID > 871562 auth.debug] PAM[484]: pam_setcred(812e218, 4): > /usr/lib/security/pam_authtok_get.so.1 returned Ignore module > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID > 871562 auth.debug] PAM[484]: pam_setcred(812e218, 4): > /usr/lib/security/pam_dhkeys.so.1 returned Ignore module > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID > 390849 auth.debug] PAM[484]: pam_get_item(812e218:user)=root > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID > 390849 auth.debug] PAM[484]: pam_get_item(812e218:auser)=NULL > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID > 390849 auth.debug] PAM[484]: pam_get_item(812e218:rhost)=10.5.5.57 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID > 390849 auth.debug] PAM[484]: pam_get_item(812e218:tty)=ssh > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID > 390849 auth.debug] PAM[484]: pam_get_item(812e218:resource)=NULL > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID > 871562 auth.debug] PAM[484]: pam_setcred(812e218, 4): > /usr/lib/security/pam_unix_cred.so.1 returned Success > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID > 871562 auth.debug] PAM[484]: pam_setcred(812e218, 4): > /usr/lib/security/pam_unix_auth.so.1 returned Ignore module > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID > 362462 auth.debug] PAM[484]: pam_setcred(812e218, 4): final: Success > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID > 800047 auth.debug] debug1: permanently_set_uid: 0/0 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[484]: [ID > 482209 auth.debug] PAM[484]: pam_getenvlist(812e218) > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[414]: [ID > 800047 auth.debug] debug1: server_input_channel_req: channel 0 request > winadj at putty.projects.tartarus.org reply 1 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[414]: [ID > 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 > Feb 26 17:45:37 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[414]: [ID > 800047 auth.debug] debug1: session_input_channel_req: session 0 req > winadj at putty.projects.tartarus.org > Feb 26 17:45:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[414]: [ID > 800047 auth.debug] debug1: server_input_channel_req: channel 0 request > window-change reply 0 > Feb 26 17:45:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[414]: [ID > 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 > Feb 26 17:45:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[414]: [ID > 800047 auth.debug] debug1: session_input_channel_req: session 0 req > window-change > > root is not an ipa managed user so it is purely your pam configuration. I thought we were trying to figure out why your ipa users are not handled properly. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From nathan at nathanpeters.com Fri Feb 27 03:17:55 2015 From: nathan at nathanpeters.com (Nathan Peters) Date: Thu, 26 Feb 2015 19:17:55 -0800 Subject: [Freeipa-users] [Solaris 10] Cannot login through console or ssh with ipa users In-Reply-To: <54EF9A3D.60608@redhat.com> References: <6a76256421cfb199ed4a9e21658c42d4.squirrel@webmail.nathanpeters.com> <54EE3781.4040400@redhat.com> <68d55813aaa45ea0871f17210093c820.squirrel@webmail.nathanpeters.com> <54EE61A7.2020304@redhat.com><8912f5330c977b8a1d302c62ce148fab.squirrel@webmail.nathanpeters.com> <54EF9A3D.60608@redhat.com> Message-ID: <7BD4178CD8064FB7BF7DF4B84B2A5B4C@Azul> Yes, we are trying to figure out why IPA users are not being handled properly however given that : 1. the method you suggested to troubleshoot my Solaris 10 system, adding pam_permit.so to the stack, will never work because Solaris does not include pam_permit.so. so therefore 2. I had to come up with some different way to troubleshoot how or why FreeIPA authorization is failing. so therefore 3. Lacking the module you suggested, I chose an alternative approach : put the pam configuration to a default and prove that no logins were broken and once the basic pam configuration was proven then I had to : 4. I added the freeIPA components (kerberos) until something broke. In this case, the ipa users were never able to login, so stating that adding kerberos broke the whole pam stack so that not even a regular user could login should have been a useful troubleshooting step. So... perhaps you could answer one of 2 things 1. how do I troubleshoot a Solaris system without pam_permit.so? and 2. why would adding kerberos in the exact way that the manual stated break my whole pam stack so that both regular users and freeipa users could not login? -----Original Message----- From: Dmitri Pal Sent: Thursday, February 26, 2015 2:12 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] [Solaris 10] Cannot login through console or ssh with ipa users root is not an ipa managed user so it is purely your pam configuration. I thought we were trying to figure out why your ipa users are not handled properly. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project From rcritten at redhat.com Fri Feb 27 03:50:33 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Feb 2015 22:50:33 -0500 Subject: [Freeipa-users] [Solaris 10] Cannot login through console or ssh with ipa users In-Reply-To: <7BD4178CD8064FB7BF7DF4B84B2A5B4C@Azul> References: <6a76256421cfb199ed4a9e21658c42d4.squirrel@webmail.nathanpeters.com> <54EE3781.4040400@redhat.com> <68d55813aaa45ea0871f17210093c820.squirrel@webmail.nathanpeters.com> <54EE61A7.2020304@redhat.com><8912f5330c977b8a1d302c62ce148fab.squirrel@webmail.nathanpeters.com> <54EF9A3D.60608@redhat.com> <7BD4178CD8064FB7BF7DF4B84B2A5B4C@Azul> Message-ID: <54EFE989.2010008@redhat.com> Nathan Peters wrote: > Yes, we are trying to figure out why IPA users are not being handled > properly however > given that : > 1. the method you suggested to troubleshoot my Solaris 10 system, adding > pam_permit.so to the stack, will never work because Solaris does not > include pam_permit.so. > so therefore > 2. I had to come up with some different way to troubleshoot how or why > FreeIPA authorization is failing. > so therefore > 3. Lacking the module you suggested, I chose an alternative approach : > put the pam configuration to a default and prove that no logins were broken > and once the basic pam configuration was proven then I had to : > 4. I added the freeIPA components (kerberos) until something broke. In > this case, the ipa users were never able to login, so stating that > adding kerberos broke the whole pam stack so that not even a regular > user could login should have been a useful troubleshooting step. > > So... perhaps you could answer one of 2 things > 1. how do I troubleshoot a Solaris system without pam_permit.so? > and > 2. why would adding kerberos in the exact way that the manual stated > break my whole pam stack so that both regular users and freeipa users > could not login? We don't have any in-house Solaris (or AIX or HP/ux for that matter) expertise which is why we no longer provide detailed documentation on how to configure non-Linux clients (what you found are really, really old). It's a no-win for us because we can't keep the docs updated, tested, etc. so they atrophy and generally just make people mad. On at least some of the pages there is a big fat warning (e.g. http://www.freeipa.org/page/FreeIPAv1:ConfiguringSolarisClients). >From the Solaris perspective this is just Kerberos authentication. The OS docs should provide the necessary details. This looks like a good place to start: http://docs.oracle.com/cd/E23824_01/html/821-1456/setup-148.html#setup-341 (though it's Solaris 11, not 10). This is a blog I found on configuring Solaris 10 against an AD server which is a reasonable parallel: http://blog.scottlowe.org/2006/08/15/solaris-10-and-active-directory-integration/ Here is something contributed by another IPA user, again for Solaris 11: https://www.redhat.com/archives/freeipa-users/2013-January/msg00021.html rob From mkosek at redhat.com Fri Feb 27 08:21:02 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Feb 2015 09:21:02 +0100 Subject: [Freeipa-users] Replica install fails when using --setup-ca In-Reply-To: References: Message-ID: <54F028EE.8000206@redhat.com> On 02/26/2015 04:07 PM, dbischof at hrz.uni-kassel.de wrote: > Hi, > > for the record: The problem was a misconfigured Apache on the IPA master, cf. > > https://www.redhat.com/archives/freeipa-users/2015-February/msg00041.html > > In my case, my Apache didn't load proxy_ajp_module and after this was fixed, > ipa-replica-install --setup-ca worked as expected. > > Thanks to Endi Sukma Dewata and Martin Kosek for putting me on the right track. You are welcome. This case actually got me thinking what we can do to automate and check this misconfiguration *before* running in such hard-to-debug problem. I think we should simply check for all required Apache modules beforehand, in the past I already put together a minimal list of Apache modules that can be checked (ajp module is there :-)). I filed a ticket to do it: https://fedorahosted.org/freeipa/ticket/4928 Also Ccing Less for reference. Martin From metebilgin48 at gmail.com Fri Feb 27 08:30:52 2015 From: metebilgin48 at gmail.com (mete bilgin) Date: Fri, 27 Feb 2015 10:30:52 +0200 Subject: [Freeipa-users] Centos 7 - ipa-server-3.3.3 AD trust trust-fetch-domains and add external group problem Message-ID: Hello, I'm trying to install ipa-server with trust (Win 2008R2). trustdomain-find will work but when i try to trust-fetch-domains "ipa: ERROR: AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides, for example" return. Force to reinstall adtrust. Have any idea where is the problem? sssd-ipa-1.11.2-68.el7_0.6.x86_64 libipa_hbac-python-1.11.2-68.el7_0.6.x86_64 ipa-admintools-3.3.3-28.0.1.el7.centos.3.x86_64 ipa-server-3.3.3-28.0.1.el7.centos.3.x86_64 iniparser-3.1-5.el7.x86_64 ipa-client-3.3.3-28.0.1.el7.centos.3.x86_64 ipa-python-3.3.3-28.0.1.el7.centos.3.x86_64 python-iniparse-0.4-9.el7.noarch libipa_hbac-1.11.2-68.el7_0.6.x86_64 ipa-server-trust-ad-3.3.3-28.0.1.el7.centos.3.x86_64 ipaserver-install.log 2015-01-20T13:09:15Z DEBUG /usr/sbin/ipa-server-install was invoked with options: {'reverse_zone': None, 'mkhomedir': False, 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, 'subject': None, 'no_forwarders': False, 'ui_redirect': True, 'domain_name': None, 'idmax': 0, 'hbac_allow': False, 'no_reverse': False, 'dirsrv_pkcs12': None, 'unattended': False, 'trust_sshfp': False, 'external_ca_file': None, 'no_host_dns': False, 'http_pkcs12': None, 'realm_name': None, 'forwarders': None, 'idstart': 1812800000, 'external_ca': False, 'ip_address': None, 'conf_ssh': True, 'zonemgr': None, 'root_ca_file': None, 'setup_dns': False, 'host_name': None, 'debug': False, 'external_cert_file': None, 'uninstall': False} Best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Feb 27 08:33:47 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Feb 2015 09:33:47 +0100 Subject: [Freeipa-users] Centos 7 - ipa-server-3.3.3 AD trust trust-fetch-domains and add external group problem In-Reply-To: References: Message-ID: <54F02BEB.5070506@redhat.com> On 02/27/2015 09:30 AM, mete bilgin wrote: > Hello, > > I'm trying to install ipa-server with trust (Win 2008R2). trustdomain-find will > work but when i try to trust-fetch-domains "ipa: ERROR: AD domain controller > complains about communication sequence. It may mean unsynchronized time on both > sides, for example" return. Force to reinstall adtrust. Have any idea where is > the problem? You probably done that, but did you indeed verify that the time on both your IPA server and AD are the same? http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Date.2Ftime_settings Martin From metebilgin48 at gmail.com Fri Feb 27 08:39:18 2015 From: metebilgin48 at gmail.com (mete bilgin) Date: Fri, 27 Feb 2015 10:39:18 +0200 Subject: [Freeipa-users] Centos 7 - ipa-server-3.3.3 AD trust trust-fetch-domains and add external group problem In-Reply-To: <54F02BEB.5070506@redhat.com> References: <54F02BEB.5070506@redhat.com> Message-ID: 2015-02-27 10:33 GMT+02:00 Martin Kosek : > On 02/27/2015 09:30 AM, mete bilgin wrote: > >> Hello, >> >> I'm trying to install ipa-server with trust (Win 2008R2). >> trustdomain-find will >> work but when i try to trust-fetch-domains "ipa: ERROR: AD domain >> controller >> complains about communication sequence. It may mean unsynchronized time >> on both >> sides, for example" return. Force to reinstall adtrust. Have any idea >> where is >> the problem? >> > > You probably done that, but did you indeed verify that the time on both > your IPA server and AD are the same? > > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup# > Date.2Ftime_settings > > Martin > Yes i did that. [root at ipa01 log]# ntpdate -u 27 Feb 10:37:00 ntpdate[11281]: adjust time server 192.168.12.239 offset -0.016979 sec By the way, #wbinfo --online-status BUILTIN : online ipadomain: online addomain : offline -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Feb 27 08:45:58 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Feb 2015 09:45:58 +0100 Subject: [Freeipa-users] Centos 7 - ipa-server-3.3.3 AD trust trust-fetch-domains and add external group problem In-Reply-To: References: <54F02BEB.5070506@redhat.com> Message-ID: <54F02EC6.5090405@redhat.com> On 02/27/2015 09:39 AM, mete bilgin wrote: > > > 2015-02-27 10:33 GMT+02:00 Martin Kosek >: > > On 02/27/2015 09:30 AM, mete bilgin wrote: > > Hello, > > I'm trying to install ipa-server with trust (Win 2008R2). > trustdomain-find will > work but when i try to trust-fetch-domains "ipa: ERROR: AD domain > controller > complains about communication sequence. It may mean unsynchronized time > on both > sides, for example" return. Force to reinstall adtrust. Have any idea > where is > the problem? > > > You probably done that, but did you indeed verify that the time on both > your IPA server and AD are the same? > > http://www.freeipa.org/page/__Howto/IPAv3_AD_trust_setup#__Date.2Ftime_settings > > > Martin > > Yes i did that. > [root at ipa01 log]# ntpdate -u > 27 Feb 10:37:00 ntpdate[11281]: adjust time server 192.168.12.239 offset > -0.016979 sec > > By the way, > #wbinfo --online-status > > BUILTIN : online > ipadomain: online > addomain : offline Right. Did you also check the actual AD? Especially when AD is in a VM, or of if for example it's time zone is wrong, the UTC time may not match. Martin From metebilgin48 at gmail.com Fri Feb 27 09:01:34 2015 From: metebilgin48 at gmail.com (mete bilgin) Date: Fri, 27 Feb 2015 11:01:34 +0200 Subject: [Freeipa-users] Centos 7 - ipa-server-3.3.3 AD trust trust-fetch-domains and add external group problem In-Reply-To: <54F02EC6.5090405@redhat.com> References: <54F02BEB.5070506@redhat.com> <54F02EC6.5090405@redhat.com> Message-ID: 2015-02-27 10:45 GMT+02:00 Martin Kosek : > On 02/27/2015 09:39 AM, mete bilgin wrote: > >> >> >> 2015-02-27 10:33 GMT+02:00 Martin Kosek > >: >> >> On 02/27/2015 09:30 AM, mete bilgin wrote: >> >> Hello, >> >> I'm trying to install ipa-server with trust (Win 2008R2). >> trustdomain-find will >> work but when i try to trust-fetch-domains "ipa: ERROR: AD domain >> controller >> complains about communication sequence. It may mean >> unsynchronized time >> on both >> sides, for example" return. Force to reinstall adtrust. Have any >> idea >> where is >> the problem? >> >> >> You probably done that, but did you indeed verify that the time on >> both >> your IPA server and AD are the same? >> >> http://www.freeipa.org/page/__Howto/IPAv3_AD_trust_setup#__ >> Date.2Ftime_settings >> > Date.2Ftime_settings> >> >> Martin >> >> Yes i did that. >> [root at ipa01 log]# ntpdate -u >> 27 Feb 10:37:00 ntpdate[11281]: adjust time server 192.168.12.239 offset >> -0.016979 sec >> >> By the way, >> #wbinfo --online-status >> >> BUILTIN : online >> ipadomain: online >> addomain : offline >> > > Right. Did you also check the actual AD? Especially when AD is in a VM, or > of if for example it's time zone is wrong, the UTC time may not match. > > Martin > On AD time zone (UTC+02:00) Istanbul and the same time with ipa server. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Feb 27 09:05:46 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Feb 2015 10:05:46 +0100 Subject: [Freeipa-users] Centos 7 - ipa-server-3.3.3 AD trust trust-fetch-domains and add external group problem In-Reply-To: References: <54F02BEB.5070506@redhat.com> <54F02EC6.5090405@redhat.com> Message-ID: <54F0336A.7060409@redhat.com> On 02/27/2015 10:01 AM, mete bilgin wrote: > > 2015-02-27 10:45 GMT+02:00 Martin Kosek >: > > On 02/27/2015 09:39 AM, mete bilgin wrote: > > > > 2015-02-27 10:33 GMT+02:00 Martin Kosek > >>: > > On 02/27/2015 09:30 AM, mete bilgin wrote: > > Hello, > > I'm trying to install ipa-server with trust (Win 2008R2). > trustdomain-find will > work but when i try to trust-fetch-domains "ipa: ERROR: AD domain > controller > complains about communication sequence. It may mean > unsynchronized time > on both > sides, for example" return. Force to reinstall adtrust. Have > any idea > where is > the problem? > > > You probably done that, but did you indeed verify that the time on > both > your IPA server and AD are the same? > > http://www.freeipa.org/page/____Howto/IPAv3_AD_trust_setup#____Date.2Ftime_settings > > > > > > Martin > > Yes i did that. > [root at ipa01 log]# ntpdate -u > 27 Feb 10:37:00 ntpdate[11281]: adjust time server 192.168.12.239 offset > -0.016979 sec > > By the way, > #wbinfo --online-status > > BUILTIN : online > ipadomain: online > addomain : offline > > > Right. Did you also check the actual AD? Especially when AD is in a VM, or > of if for example it's time zone is wrong, the UTC time may not match. > > Martin > > On AD time zone (UTC+02:00) Istanbul and the same time with ipa server. > Ok, thanks. It was worth a try. If this is the case, I think you will simply need to follow our guide for debugging Trusts and send us the logs: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust Thanks, Martin From metebilgin48 at gmail.com Fri Feb 27 09:19:59 2015 From: metebilgin48 at gmail.com (mete bilgin) Date: Fri, 27 Feb 2015 11:19:59 +0200 Subject: [Freeipa-users] Centos 7 - ipa-server-3.3.3 AD trust trust-fetch-domains and add external group problem In-Reply-To: <54F0336A.7060409@redhat.com> References: <54F02BEB.5070506@redhat.com> <54F02EC6.5090405@redhat.com> <54F0336A.7060409@redhat.com> Message-ID: 2015-02-27 11:05 GMT+02:00 Martin Kosek : > On 02/27/2015 10:01 AM, mete bilgin wrote: > >> >> 2015-02-27 10:45 GMT+02:00 Martin Kosek > >: >> >> On 02/27/2015 09:39 AM, mete bilgin wrote: >> >> >> >> 2015-02-27 10:33 GMT+02:00 Martin Kosek > >> >>: >> >> On 02/27/2015 09:30 AM, mete bilgin wrote: >> >> Hello, >> >> I'm trying to install ipa-server with trust (Win 2008R2). >> trustdomain-find will >> work but when i try to trust-fetch-domains "ipa: ERROR: >> AD domain >> controller >> complains about communication sequence. It may mean >> unsynchronized time >> on both >> sides, for example" return. Force to reinstall adtrust. >> Have >> any idea >> where is >> the problem? >> >> >> You probably done that, but did you indeed verify that the >> time on >> both >> your IPA server and AD are the same? >> >> http://www.freeipa.org/page/____Howto/IPAv3_AD_trust_setup#_ >> ___Date.2Ftime_settings >> > Date.2Ftime_settings> >> >> > Date.2Ftime_settings >> > Date.2Ftime_settings>> >> >> Martin >> >> Yes i did that. >> [root at ipa01 log]# ntpdate -u >> 27 Feb 10:37:00 ntpdate[11281]: adjust time server 192.168.12.239 >> offset >> -0.016979 sec >> >> By the way, >> #wbinfo --online-status >> >> BUILTIN : online >> ipadomain: online >> addomain : offline >> >> >> Right. Did you also check the actual AD? Especially when AD is in a >> VM, or >> of if for example it's time zone is wrong, the UTC time may not match. >> >> Martin >> >> On AD time zone (UTC+02:00) Istanbul and the same time with ipa server. >> >> > Ok, thanks. It was worth a try. If this is the case, I think you will > simply need to follow our guide for debugging Trusts and send us the logs: > > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust > > Thanks, > Martin > Hi, I open debug and try to understand but, i can not :( Here the logs. Thank a lot. Error_log [Fri Feb 27 11:08:48.740996 2015] [:error] [pid 5367] ipa: INFO: admin at IPDOMAIN.COM: ping(version=u'2.51'): SUCCESS 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 scavenger: 100 dns: 100 ldb: 100 pm_process() returned Yes Using binding ncacn_np:ipa01.IPDOMAIN.com[,] s4_tevent: Added timed event "dcerpc_connect_timeout_handler": 0x7fed9c334520 s4_tevent: Added timed event "composite_trigger": 0x7fed9c3ec530 s4_tevent: Added timed event "composite_trigger": 0x7fed9c2f6310 s4_tevent: Running timer event 0x7fed9c3ec530 "composite_trigger" s4_tevent: Destroying timer event 0x7fed9c2f6310 "composite_trigger" Mapped to DCERPC endpoint \pipe\lsarpc added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 s4_tevent: Ending timer event 0x7fed9c3ec530 "composite_trigger" s4_tevent: Added timed event "connect_multi_timer": 0x7fed9c4cb560 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4cb0b0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4cb0b0 s4_tevent: Destroying timer event 0x7fed9c4cb560 "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 = 663430 SO_RCVBUF = 261942 SO_SNDLOWAT = 1 SO_RCVLOWAT = 1 SO_SNDTIMEO = 0 SO_RCVTIMEO = 0 TCP_QUICKACK = 1 TCP_DEFER_ACCEPT = 0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4caa80 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Destroying timer event 0x7fed9c4caa80 "tevent_req_timedout" Starting GENSEC mechanism spnego Starting GENSEC submechanism gssapi_krb5 Ticket in credentials cache for @IPDOMAIN will expire in 80256 secs s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d0960 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Destroying timer event 0x7fed9c4d0960 "tevent_req_timedout" gensec_gssapi: NO credentials were delegated GSSAPI Connection will be cryptographically sealed s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d0360 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Destroying timer event 0x7fed9c4d0360 "tevent_req_timedout" s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4cf550 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Destroying timer event 0x7fed9c4cf550 "tevent_req_timedout" num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=72, this_data=72, max_data=65535, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d9a30 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4d9df0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d9640 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d9640 s4_tevent: Destroying timer event 0x7fed9c4d9a30 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c4d9df0 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c3ec8a0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c3ec8a0 s4_tevent: Destroying timer event 0x7fed9c334520 "dcerpc_connect_timeout_handler" lsa_OpenPolicy2: struct lsa_OpenPolicy2 in: struct lsa_OpenPolicy2 system_name : * system_name : '' attr : * attr: struct lsa_ObjectAttribute len : 0x00000000 (0) root_dir : NULL object_name : NULL attributes : 0x00000000 (0) sec_desc : NULL sec_qos : * sec_qos: struct lsa_QosInfo len : 0x00000000 (0) impersonation_level : 0x0000 (0) context_mode : 0x00 (0) effective_only : 0x00 (0) access_mask : 0x02000000 (33554432) 0: LSA_POLICY_VIEW_LOCAL_INFORMATION 0: LSA_POLICY_VIEW_AUDIT_INFORMATION 0: LSA_POLICY_GET_PRIVATE_INFORMATION 0: LSA_POLICY_TRUST_ADMIN 0: LSA_POLICY_CREATE_ACCOUNT 0: LSA_POLICY_CREATE_SECRET 0: LSA_POLICY_CREATE_PRIVILEGE 0: LSA_POLICY_SET_DEFAULT_QUOTA_LIMITS 0: LSA_POLICY_SET_AUDIT_REQUIREMENTS 0: LSA_POLICY_AUDIT_LOG_ADMIN 0: LSA_POLICY_SERVER_ADMIN 0: LSA_POLICY_LOOKUP_NAMES 0: LSA_POLICY_NOTIFICATION rpc request data: [0000] 00 00 02 00 01 00 00 00 00 00 00 00 01 00 00 00 ........ ........ [0010] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ [0020] 00 00 00 00 00 00 00 00 04 00 02 00 00 00 00 00 ........ ........ [0030] 00 00 00 00 00 00 00 02 ........ s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4d0be0 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=80, this_data=80, max_data=4280, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d9d00 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d9910 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d9910 s4_tevent: Destroying timer event 0x7fed9c4d9d00 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c4d0be0 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c3ec8a0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c3ec8a0 lsa_OpenPolicy2: struct lsa_OpenPolicy2 out: struct lsa_OpenPolicy2 handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000014-0000-0000-f054-20348a2a0000 result : NT_STATUS_OK rpc reply data: [0000] 00 00 00 00 14 00 00 00 00 00 00 00 F0 54 20 34 ........ .....T 4 [0010] 8A 2A 00 00 00 00 00 00 .*...... lsa_QueryInfoPolicy2: struct lsa_QueryInfoPolicy2 in: struct lsa_QueryInfoPolicy2 handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000014-0000-0000-f054-20348a2a0000 level : LSA_POLICY_INFO_DNS (12) rpc request data: [0000] 00 00 00 00 14 00 00 00 00 00 00 00 F0 54 20 34 ........ .....T 4 [0010] 8A 2A 00 00 0C 00 .*.... s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c3ec350 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=46, this_data=46, max_data=4280, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d9ec0 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d9af0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d9af0 s4_tevent: Destroying timer event 0x7fed9c4d9ec0 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c3ec350 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d0ad0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d0ad0 lsa_QueryInfoPolicy2: struct lsa_QueryInfoPolicy2 out: struct lsa_QueryInfoPolicy2 info : * info : * info : union lsa_PolicyInformation(case 12) dns: struct lsa_DnsDomainInfo name: struct lsa_StringLarge length : 0x0010 (16) size : 0x0012 (18) string : * string : 'IPDOMAIN' dns_domain: struct lsa_StringLarge length : 0x0018 (24) size : 0x001a (26) string : * string : 'IPDOMAIN.com' dns_forest: struct lsa_StringLarge length : 0x0018 (24) size : 0x001a (26) string : * string : 'IPDOMAIN.com' domain_guid : 00000015-e851-c207-0dd0-a20419e2e2c7 sid : * sid : S-1-5-21-3255298129-77778957-3353535001 result : NT_STATUS_OK rpc reply data: [0000] 00 00 02 00 0C 00 00 00 10 00 12 00 04 00 02 00 ........ ........ [0010] 18 00 1A 00 08 00 02 00 18 00 1A 00 0C 00 02 00 ........ ........ [0020] 15 00 00 00 51 E8 07 C2 0D D0 A2 04 19 E2 E2 C7 ....Q... ........ [0030] 10 00 02 00 09 00 00 00 00 00 00 00 08 00 00 00 ........ ........ [0040] 42 00 49 00 4C 00 59 00 4F 00 4E 00 45 00 52 00 B.I.L.Y. O.N.E.R. [0050] 0D 00 00 00 00 00 00 00 0C 00 00 00 62 00 69 00 ........ ....b.i. [0060] 6C 00 79 00 6F 00 6E 00 65 00 72 00 2E 00 63 00 l.y.o.n. e.r...c. [0070] 6F 00 6D 00 0D 00 00 00 00 00 00 00 0C 00 00 00 o.m..... ........ [0080] 62 00 69 00 6C 00 79 00 6F 00 6E 00 65 00 72 00 b.i.l.y. o.n.e.r. [0090] 2E 00 63 00 6F 00 6D 00 04 00 00 00 01 04 00 00 ..c.o.m. ........ [00A0] 00 00 00 05 15 00 00 00 51 E8 07 C2 0D D0 A2 04 ........ Q....... [00B0] 19 E2 E2 C7 00 00 00 00 ........ lsa_QueryInfoPolicy2: struct lsa_QueryInfoPolicy2 in: struct lsa_QueryInfoPolicy2 handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000014-0000-0000-f054-20348a2a0000 level : LSA_POLICY_INFO_ROLE (6) rpc request data: [0000] 00 00 00 00 14 00 00 00 00 00 00 00 F0 54 20 34 ........ .....T 4 [0010] 8A 2A 00 00 06 00 .*.... s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4d0f90 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=46, this_data=46, max_data=4280, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4da450 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d9fe0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d9fe0 s4_tevent: Destroying timer event 0x7fed9c4da450 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c4d0f90 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c3ec3e0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c3ec3e0 lsa_QueryInfoPolicy2: struct lsa_QueryInfoPolicy2 out: struct lsa_QueryInfoPolicy2 info : * info : * info : union lsa_PolicyInformation(case 6) role: struct lsa_ServerRole role : LSA_ROLE_PRIMARY (3) result : NT_STATUS_OK rpc reply data: [0000] 00 00 02 00 06 00 00 00 03 00 00 00 00 00 00 00 ........ ........ 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 scavenger: 100 dns: 100 ldb: 100 pm_process() returned Yes added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 finddcs: searching for a DC by DNS domain addomain.com finddcs: looking for SRV records for _ldap._tcp.addomain.com ads_dns_lookup_srv: 3 records returned in the answer section. ads_dns_parse_rr_srv: Parsed ad.addomain.com [0, 100, 389] ads_dns_parse_rr_srv: Parsed kratos.addomain.com [0, 100, 389] ads_dns_parse_rr_srv: Parsed beatrice.addomain.com [0, 100, 389] Addrs = 192.168.12.236 at 389/ad,172.16.50.70 at 389/kratos,192.168.12.239 at 389 /beatrice finddcs: DNS SRV response 0 at '192.168.12.236' finddcs: DNS SRV response 1 at '172.16.50.70' finddcs: DNS SRV response 2 at '192.168.12.239' finddcs: performing CLDAP query on 192.168.12.236 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d6230 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d66e0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d66e0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d69b0 s4_tevent: Destroying timer event 0x7fed9c4d69b0 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c4d6230 "tevent_req_timedout" &response->data.nt5_ex: struct NETLOGON_SAM_LOGON_RESPONSE_EX command : LOGON_SAM_LOGON_RESPONSE_EX (23) sbz : 0x0000 (0) server_type : 0x000031fd (12797) 1: NBT_SERVER_PDC 1: NBT_SERVER_GC 1: NBT_SERVER_LDAP 1: NBT_SERVER_DS 1: NBT_SERVER_KDC 1: NBT_SERVER_TIMESERV 1: NBT_SERVER_CLOSEST 1: NBT_SERVER_WRITABLE 0: NBT_SERVER_GOOD_TIMESERV 0: NBT_SERVER_NDNC 0: NBT_SERVER_SELECT_SECRET_DOMAIN_6 1: NBT_SERVER_FULL_SECRET_DOMAIN_6 1: NBT_SERVER_ADS_WEB_SERVICE 0: NBT_SERVER_HAS_DNS_NAME 0: NBT_SERVER_IS_DEFAULT_NC 0: NBT_SERVER_FOREST_ROOT domain_uuid : 6aac190b-04eb-464f-bdcc-b07e27e2d1e5 forest : 'addomain.com' dns_domain : 'addomain.com' pdc_dns_name : 'ad.addomain.com' domain_name : 'LIBERO' pdc_name : 'ad' user_name : '' server_site : 'Default-First-Site-Name' client_site : 'Default-First-Site-Name' sockaddr_size : 0x00 (0) sockaddr: struct nbt_sockaddr sockaddr_family : 0x00000000 (0) pdc_ip : (null) remaining : DATA_BLOB length=0 next_closest_site : NULL nt_version : 0x00000005 (5) 1: NETLOGON_NT_VERSION_1 0: NETLOGON_NT_VERSION_5 1: NETLOGON_NT_VERSION_5EX 0: NETLOGON_NT_VERSION_5EX_WITH_IP 0: NETLOGON_NT_VERSION_WITH_CLOSEST_SITE 0: NETLOGON_NT_VERSION_AVOID_NT4EMUL 0: NETLOGON_NT_VERSION_PDC 0: NETLOGON_NT_VERSION_IP 0: NETLOGON_NT_VERSION_LOCAL 0: NETLOGON_NT_VERSION_GC lmnt_token : 0xffff (65535) lm20_token : 0xffff (65535) finddcs: Found matching DC 192.168.12.236 with server_type=0x000031fd Using binding ncacn_np:ad.addomain.com[,] s4_tevent: Added timed event "dcerpc_connect_timeout_handler": 0x7fed9c4d4b90 s4_tevent: Added timed event "composite_trigger": 0x7fed9c4d5180 s4_tevent: Added timed event "composite_trigger": 0x7fed9c4d54b0 s4_tevent: Running timer event 0x7fed9c4d5180 "composite_trigger" s4_tevent: Destroying timer event 0x7fed9c4d54b0 "composite_trigger" Mapped to DCERPC endpoint \pipe\lsarpc added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 s4_tevent: Ending timer event 0x7fed9c4d5180 "composite_trigger" s4_tevent: Added timed event "connect_multi_timer": 0x7fed9c4d8b90 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d5180 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d5180 s4_tevent: Destroying timer event 0x7fed9c4d8b90 "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 = 23080 SO_RCVBUF = 87380 SO_SNDLOWAT = 1 SO_RCVLOWAT = 1 SO_SNDTIMEO = 0 SO_RCVTIMEO = 0 TCP_QUICKACK = 1 TCP_DEFER_ACCEPT = 0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4dbfe0 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d8b90 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d8b90 s4_tevent: Destroying timer event 0x7fed9c4dbfe0 "tevent_req_timedout" Starting GENSEC mechanism spnego Starting GENSEC submechanism gssapi_krb5 Ticket in credentials cache for @IPDOMAIN will expire in 86400 secs GSS client Update(krb5)(1) Update failed: Unspecified GSS failure. Minor code may provide more information: KDC policy rejects request s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4f6040 smb_signing_sign_pdu: sent SMB signature of [0000] 42 53 52 53 50 59 4C 20 BSRSPYL s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d8b90 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d8b90 s4_tevent: Destroying timer event 0x7fed9c4f6040 "tevent_req_timedout" GENSEC SPNEGO: client GENSEC accepted, but server rejected (bad password?) SPNEGO(gssapi_krb5) login failed: NT_STATUS_INVALID_PARAMETER s4_tevent: Destroying timer event 0x7fed9c4d4b90 "dcerpc_connect_timeout_handler" [Fri Feb 27 11:08:49.254156 2015] [:error] [pid 5366] ipa: INFO: admin at IPDOMAIN.COM: trust_fetch_domains(u'addomain.com', rights=False, all=False, raw=False, version=u'2.65'): RemoteRetrieveError s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c3eb9c0 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4cb560 s4_tevent: Destroying timer event 0x7fed9c3eb9c0 "tevent_req_timedout" s4_tevent: Cancel immediate event 0x7fed9c4cb560 "tevent_queue_immediate_trigger" /var/log/samba/log.wb-IPDOMAIN [2015/02/27 11:00:47.053371, 4, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_dual.c:1333(child_handler) child daemon request 20 [2015/02/27 11:00:47.053486, 10, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_dual.c:458(child_process_request) child_process_request: request fn LIST_TRUSTDOM [2015/02/27 11:00:47.053545, 3, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_misc.c:161(winbindd_dual_list_trusted_domains) [ 5701]: list trusted domains [2015/02/27 11:00:47.053599, 10, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:2857(trusted_domains) trusted_domains: [Cached] - doing backend query for info for domain IPDOMAIN [2015/02/27 11:00:47.053660, 3, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_samr.c:365(sam_trusted_domains) samr: trusted domains [2015/02/27 11:00:47.053805, 4, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_ncacn_np.c:60(make_internal_rpc_pipe_p) Create pipe requested \lsarpc [2015/02/27 11:00:47.053861, 10, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:221(init_pipe_handles) init_pipe_handle_list: created handle list for pipe \lsarpc [2015/02/27 11:00:47.053901, 10, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:238(init_pipe_handles) init_pipe_handle_list: pipe_handles ref count = 1 for pipe \lsarpc [2015/02/27 11:00:47.053957, 4, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_ncacn_np.c:100(make_internal_rpc_pipe_p) Created internal pipe \lsarpc [2015/02/27 11:00:47.054020, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_OpenPolicy: struct lsa_OpenPolicy in: struct lsa_OpenPolicy system_name : * system_name : 0x005c (92) attr : * attr: struct lsa_ObjectAttribute len : 0x00000018 (24) root_dir : NULL object_name : NULL attributes : 0x00000000 (0) sec_desc : NULL sec_qos : * sec_qos: struct lsa_QosInfo len : 0x0000000c (12) impersonation_level : 0x0002 (2) context_mode : 0x01 (1) effective_only : 0x00 (0) access_mask : 0x02000000 (33554432) 0: LSA_POLICY_VIEW_LOCAL_INFORMATION 0: LSA_POLICY_VIEW_AUDIT_INFORMATION 0: LSA_POLICY_GET_PRIVATE_INFORMATION 0: LSA_POLICY_TRUST_ADMIN 0: LSA_POLICY_CREATE_ACCOUNT 0: LSA_POLICY_CREATE_SECRET 0: LSA_POLICY_CREATE_PRIVILEGE 0: LSA_POLICY_SET_DEFAULT_QUOTA_LIMITS 0: LSA_POLICY_SET_AUDIT_REQUIREMENTS 0: LSA_POLICY_AUDIT_LOG_ADMIN 0: LSA_POLICY_SERVER_ADMIN 0: LSA_POLICY_LOOKUP_NAMES 0: LSA_POLICY_NOTIFICATION [2015/02/27 11:00:47.054624, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_OpenPolicy: struct lsa_OpenPolicy in: struct lsa_OpenPolicy system_name : * system_name : 0x005c (92) attr : * attr: struct lsa_ObjectAttribute len : 0x00000018 (24) root_dir : NULL object_name : NULL attributes : 0x00000000 (0) sec_desc : NULL sec_qos : * sec_qos: struct lsa_QosInfo len : 0x0000000c (12) impersonation_level : 0x0002 (2) context_mode : 0x01 (1) effective_only : 0x00 (0) access_mask : 0x02000000 (33554432) 0: LSA_POLICY_VIEW_LOCAL_INFORMATION 0: LSA_POLICY_VIEW_AUDIT_INFORMATION 0: LSA_POLICY_GET_PRIVATE_INFORMATION 0: LSA_POLICY_TRUST_ADMIN 0: LSA_POLICY_CREATE_ACCOUNT 0: LSA_POLICY_CREATE_SECRET 0: LSA_POLICY_CREATE_PRIVILEGE 0: LSA_POLICY_SET_DEFAULT_QUOTA_LIMITS 0: LSA_POLICY_SET_AUDIT_REQUIREMENTS 0: LSA_POLICY_AUDIT_LOG_ADMIN 0: LSA_POLICY_SERVER_ADMIN 0: LSA_POLICY_LOOKUP_NAMES 0: LSA_POLICY_NOTIFICATION [2015/02/27 11:00:47.055210, 10, pid=5702, effective(0, 0), real(0, 0)] ../libcli/security/access_check.c:58(se_map_generic) se_map_generic(): mapped mask 0xb0000000 to 0x000f0fff [2015/02/27 11:00:47.055301, 4, pid=5702, effective(0, 0), real(0, 0)] ../source3/rpc_server/srv_access_check.c:84(access_check_object) _lsa_OpenPolicy2: ACCESS should be DENIED (requested: 0x000f0fff) but overritten by euid == sec_initial_uid() [2015/02/27 11:00:47.055363, 4, pid=5702, effective(0, 0), real(0, 0)] ../source3/rpc_server/srv_access_check.c:105(access_check_object) _lsa_OpenPolicy2: access GRANTED (requested: 0x000f0fff, granted: 0x000f0fff) [2015/02/27 11:00:47.055406, 6, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:302(create_rpc_handle_internal) Opened policy hnd[1] [0000] 00 00 00 00 33 01 00 00 00 00 00 00 F0 54 3F 32 ....3... .....T?2 [0010] 46 16 00 00 F... [2015/02/27 11:00:47.055600, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_OpenPolicy: struct lsa_OpenPolicy out: struct lsa_OpenPolicy handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000133-0000-0000-f054-3f3246160000 result : NT_STATUS_OK [2015/02/27 11:00:47.055771, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_req_trigger": 0x7f06abf8ee70 [2015/02/27 11:00:47.055818, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_req_trigger": 0x7f06abf8ee70 [2015/02/27 11:00:47.055865, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_OpenPolicy: struct lsa_OpenPolicy out: struct lsa_OpenPolicy handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000133-0000-0000-f054-3f3246160000 result : NT_STATUS_OK [2015/02/27 11:00:47.056021, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_EnumTrustedDomainsEx: struct lsa_EnumTrustedDomainsEx in: struct lsa_EnumTrustedDomainsEx handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000133-0000-0000-f054-3f3246160000 resume_handle : * resume_handle : 0x00000000 (0) max_size : 0xffffffff (4294967295) [2015/02/27 11:00:47.056196, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_EnumTrustedDomainsEx: struct lsa_EnumTrustedDomainsEx in: struct lsa_EnumTrustedDomainsEx handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000133-0000-0000-f054-3f3246160000 resume_handle : * resume_handle : 0x00000000 (0) max_size : 0xffffffff (4294967295) [2015/02/27 11:00:47.056367, 6, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:337(find_policy_by_hnd_internal) Found policy hnd[0] [0000] 00 00 00 00 33 01 00 00 00 00 00 00 F0 54 3F 32 ....3... .....T?2 [0010] 46 16 00 00 F... [2015/02/27 11:00:47.056515, 5, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:1249(smbldap_search_ext) smbldap_search_ext: base => [cn=ad,cn=trusts,dc=IPDOMAIN,dc=com], filter => [(objectClass=ipaNTTrustedDomain)], scope => [2] [2015/02/27 11:00:47.056897, 10, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:595(smb_ldap_setup_conn) smb_ldap_setup_connection: ldapi://%2fvar%2frun%2fslapd-IPDOMAIN-COM.socket [2015/02/27 11:00:47.056995, 2, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:794(smbldap_open_connection) smbldap_open_connection: connection opened [2015/02/27 11:00:47.057044, 10, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:954(smbldap_connect_system) ldap_connect_system: Binding to ldap server ldapi://%2fvar%2frun%2fslapd-IPDOMAIN-COM.socket as "(null)" [2015/02/27 11:00:47.077904, 3, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:1013(smbldap_connect_system) ldap_connect_system: successful connection to the LDAP server ldap_connect_system: LDAP server does support paged results [2015/02/27 11:00:47.078003, 4, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:1092(smbldap_open) The LDAP server is successfully connected [2015/02/27 11:00:47.079442, 9, pid=5702, effective(0, 0), real(0, 0)] ipa_sam.c:2164(fill_pdb_trusted_domain) Failed to set forest trust info. [2015/02/27 11:00:47.079509, 5, pid=5702, effective(0, 0), real(0, 0)] ipa_sam.c:2705(ipasam_enum_trusted_domains) ipasam_enum_trusted_domains: got 1 domains [2015/02/27 11:00:47.079556, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_EnumTrustedDomainsEx: struct lsa_EnumTrustedDomainsEx out: struct lsa_EnumTrustedDomainsEx resume_handle : * resume_handle : 0xffffffff (4294967295) domains : * domains: struct lsa_DomainListEx count : 0x00000001 (1) domains : * domains: ARRAY(1) domains: struct lsa_TrustDomainInfoInfoEx domain_name: struct lsa_StringLarge length : 0x0014 (20) size : 0x0016 (22) string : * string : ' ADDOMAIN.INT' netbios_name: struct lsa_StringLarge length : 0x000c (12) size : 0x000e (14) string : * string : 'ADDOMAIN' sid : * sid : S-1-5-21-1343024091-2000478354-725345543 trust_direction : 0x00000003 (3) 1: LSA_TRUST_DIRECTION_INBOUND 1: LSA_TRUST_DIRECTION_OUTBOUND trust_type : LSA_TRUST_TYPE_UPLEVEL (2) trust_attributes : 0x00000008 (8) 0: LSA_TRUST_ATTRIBUTE_NON_TRANSITIVE 0: LSA_TRUST_ATTRIBUTE_UPLEVEL_ONLY 0: LSA_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN 1: LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE 0: LSA_TRUST_ATTRIBUTE_CROSS_ORGANIZATION 0: LSA_TRUST_ATTRIBUTE_WITHIN_FOREST 0: LSA_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL 0: LSA_TRUST_ATTRIBUTE_USES_RC4_ENCRYPTION result : NT_STATUS_OK [2015/02/27 11:00:47.080205, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_req_trigger": 0x7f06abf9eaf0 [2015/02/27 11:00:47.080255, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_req_trigger": 0x7f06abf9eaf0 [2015/02/27 11:00:47.080311, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_EnumTrustedDomainsEx: struct lsa_EnumTrustedDomainsEx out: struct lsa_EnumTrustedDomainsEx resume_handle : * resume_handle : 0xffffffff (4294967295) domains : * domains: struct lsa_DomainListEx count : 0x00000001 (1) domains : * domains: ARRAY(1) domains: struct lsa_TrustDomainInfoInfoEx domain_name: struct lsa_StringLarge length : 0x0014 (20) size : 0x0016 (22) string : * string : ' ADDOMAIN.INT' netbios_name: struct lsa_StringLarge length : 0x000c (12) size : 0x000e (14) string : * string : 'ADDOMAIN' sid : * sid : S-1-5-21-1343024091-2000478354-725345543 trust_direction : 0x00000003 (3) 1: LSA_TRUST_DIRECTION_INBOUND 1: LSA_TRUST_DIRECTION_OUTBOUND trust_type : LSA_TRUST_TYPE_UPLEVEL (2) trust_attributes : 0x00000008 (8) 0: LSA_TRUST_ATTRIBUTE_NON_TRANSITIVE 0: LSA_TRUST_ATTRIBUTE_UPLEVEL_ONLY 0: LSA_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN 1: LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE 0: LSA_TRUST_ATTRIBUTE_CROSS_ORGANIZATION 0: LSA_TRUST_ATTRIBUTE_WITHIN_FOREST 0: LSA_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL 0: LSA_TRUST_ATTRIBUTE_USES_RC4_ENCRYPTION result : NT_STATUS_OK [2015/02/27 11:00:47.080991, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_Close: struct lsa_Close in: struct lsa_Close handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000133-0000-0000-f054-3f3246160000 [2015/02/27 11:00:47.081129, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_Close: struct lsa_Close in: struct lsa_Close handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000133-0000-0000-f054-3f3246160000 [2015/02/27 11:00:47.081260, 6, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:337(find_policy_by_hnd_internal) Found policy hnd[0] [0000] 00 00 00 00 33 01 00 00 00 00 00 00 F0 54 3F 32 ....3... .....T?2 [0010] 46 16 00 00 F... [2015/02/27 11:00:47.081336, 6, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:337(find_policy_by_hnd_internal) Found policy hnd[0] [0000] 00 00 00 00 33 01 00 00 00 00 00 00 F0 54 3F 32 ....3... .....T?2 [0010] 46 16 00 00 F... [2015/02/27 11:00:47.081405, 6, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:386(close_policy_hnd) Closed policy [2015/02/27 11:00:47.081476, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_Close: struct lsa_Close out: struct lsa_Close handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000000-0000-0000-0000-000000000000 result : NT_STATUS_OK [2015/02/27 11:00:47.081618, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_req_trigger": 0x7f06abf9e000 [2015/02/27 11:00:47.081661, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_req_trigger": 0x7f06abf9e000 [2015/02/27 11:00:47.081703, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_Close: struct lsa_Close out: struct lsa_Close handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000000-0000-0000-0000-000000000000 result : NT_STATUS_OK [2015/02/27 11:00:47.081847, 10, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:416(close_policy_by_pipe) Deleted handle list for RPC connection \lsarpc [2015/02/27 11:00:47.081909, 4, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_dual.c:1341(child_handler) Finished processing child request 20 [2015/02/27 11:00:47.081949, 10, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_dual.c:1358(child_handler) Writing 3556 bytes to parent [2015/02/27 11:05:47.154872, 4, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_dual.c:1333(child_handler) child daemon request 20 [2015/02/27 11:05:47.154945, 10, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_dual.c:458(child_process_request) child_process_request: request fn LIST_TRUSTDOM [2015/02/27 11:05:47.154986, 3, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_misc.c:161(winbindd_dual_list_trusted_domains) [ 5701]: list trusted domains [2015/02/27 11:05:47.155034, 10, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:2857(trusted_domains) trusted_domains: [Cached] - doing backend query for info for domain IPDOMAIN [2015/02/27 11:05:47.155074, 3, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_samr.c:365(sam_trusted_domains) samr: trusted domains [2015/02/27 11:05:47.155191, 4, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_ncacn_np.c:60(make_internal_rpc_pipe_p) Create pipe requested \lsarpc [2015/02/27 11:05:47.155254, 10, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:221(init_pipe_handles) init_pipe_handle_list: created handle list for pipe \lsarpc [2015/02/27 11:05:47.155329, 10, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:238(init_pipe_handles) init_pipe_handle_list: pipe_handles ref count = 1 for pipe \lsarpc [2015/02/27 11:05:47.155391, 4, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_ncacn_np.c:100(make_internal_rpc_pipe_p) Created internal pipe \lsarpc [2015/02/27 11:05:47.155491, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_OpenPolicy: struct lsa_OpenPolicy in: struct lsa_OpenPolicy system_name : * system_name : 0x005c (92) attr : * attr: struct lsa_ObjectAttribute len : 0x00000018 (24) root_dir : NULL object_name : NULL attributes : 0x00000000 (0) sec_desc : NULL sec_qos : * sec_qos: struct lsa_QosInfo len : 0x0000000c (12) impersonation_level : 0x0002 (2) context_mode : 0x01 (1) effective_only : 0x00 (0) access_mask : 0x02000000 (33554432) 0: LSA_POLICY_VIEW_LOCAL_INFORMATION 0: LSA_POLICY_VIEW_AUDIT_INFORMATION 0: LSA_POLICY_GET_PRIVATE_INFORMATION 0: LSA_POLICY_TRUST_ADMIN 0: LSA_POLICY_CREATE_ACCOUNT 0: LSA_POLICY_CREATE_SECRET 0: LSA_POLICY_CREATE_PRIVILEGE 0: LSA_POLICY_SET_DEFAULT_QUOTA_LIMITS 0: LSA_POLICY_SET_AUDIT_REQUIREMENTS 0: LSA_POLICY_AUDIT_LOG_ADMIN 0: LSA_POLICY_SERVER_ADMIN 0: LSA_POLICY_LOOKUP_NAMES 0: LSA_POLICY_NOTIFICATION [2015/02/27 11:05:47.156151, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_OpenPolicy: struct lsa_OpenPolicy in: struct lsa_OpenPolicy system_name : * system_name : 0x005c (92) attr : * attr: struct lsa_ObjectAttribute len : 0x00000018 (24) root_dir : NULL object_name : NULL attributes : 0x00000000 (0) sec_desc : NULL sec_qos : * sec_qos: struct lsa_QosInfo len : 0x0000000c (12) impersonation_level : 0x0002 (2) context_mode : 0x01 (1) effective_only : 0x00 (0) access_mask : 0x02000000 (33554432) 0: LSA_POLICY_VIEW_LOCAL_INFORMATION 0: LSA_POLICY_VIEW_AUDIT_INFORMATION 0: LSA_POLICY_GET_PRIVATE_INFORMATION 0: LSA_POLICY_TRUST_ADMIN 0: LSA_POLICY_CREATE_ACCOUNT 0: LSA_POLICY_CREATE_SECRET 0: LSA_POLICY_CREATE_PRIVILEGE 0: LSA_POLICY_SET_DEFAULT_QUOTA_LIMITS 0: LSA_POLICY_SET_AUDIT_REQUIREMENTS 0: LSA_POLICY_AUDIT_LOG_ADMIN 0: LSA_POLICY_SERVER_ADMIN 0: LSA_POLICY_LOOKUP_NAMES 0: LSA_POLICY_NOTIFICATION [2015/02/27 11:05:47.156741, 10, pid=5702, effective(0, 0), real(0, 0)] ../libcli/security/access_check.c:58(se_map_generic) se_map_generic(): mapped mask 0xb0000000 to 0x000f0fff [2015/02/27 11:05:47.156831, 4, pid=5702, effective(0, 0), real(0, 0)] ../source3/rpc_server/srv_access_check.c:84(access_check_object) _lsa_OpenPolicy2: ACCESS should be DENIED (requested: 0x000f0fff) but overritten by euid == sec_initial_uid() [2015/02/27 11:05:47.156933, 4, pid=5702, effective(0, 0), real(0, 0)] ../source3/rpc_server/srv_access_check.c:105(access_check_object) _lsa_OpenPolicy2: access GRANTED (requested: 0x000f0fff, granted: 0x000f0fff) [2015/02/27 11:05:47.157013, 6, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:302(create_rpc_handle_internal) Opened policy hnd[1] [0000] 00 00 00 00 34 01 00 00 00 00 00 00 F0 54 6B 33 ....4... .....Tk3 [0010] 46 16 00 00 F... [2015/02/27 11:05:47.157154, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_OpenPolicy: struct lsa_OpenPolicy out: struct lsa_OpenPolicy handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000134-0000-0000-f054-6b3346160000 result : NT_STATUS_OK [2015/02/27 11:05:47.157518, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_req_trigger": 0x7f06abfc9120 [2015/02/27 11:05:47.157578, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_req_trigger": 0x7f06abfc9120 [2015/02/27 11:05:47.157625, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_OpenPolicy: struct lsa_OpenPolicy out: struct lsa_OpenPolicy handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000134-0000-0000-f054-6b3346160000 result : NT_STATUS_OK [2015/02/27 11:05:47.157898, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_EnumTrustedDomainsEx: struct lsa_EnumTrustedDomainsEx in: struct lsa_EnumTrustedDomainsEx handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000134-0000-0000-f054-6b3346160000 resume_handle : * resume_handle : 0x00000000 (0) max_size : 0xffffffff (4294967295) [2015/02/27 11:05:47.158106, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_EnumTrustedDomainsEx: struct lsa_EnumTrustedDomainsEx in: struct lsa_EnumTrustedDomainsEx handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000134-0000-0000-f054-6b3346160000 resume_handle : * resume_handle : 0x00000000 (0) max_size : 0xffffffff (4294967295) [2015/02/27 11:05:47.158281, 6, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:337(find_policy_by_hnd_internal) Found policy hnd[0] [0000] 00 00 00 00 34 01 00 00 00 00 00 00 F0 54 6B 33 ....4... .....Tk3 [0010] 46 16 00 00 F... [2015/02/27 11:05:47.158538, 5, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:1249(smbldap_search_ext) smbldap_search_ext: base => [cn=ad,cn=trusts,dc=IPDOMAIN,dc=com], filter => [(objectClass=ipaNTTrustedDomain)], scope => [2] [2015/02/27 11:05:47.159500, 10, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:595(smb_ldap_setup_conn) smb_ldap_setup_connection: ldapi://%2fvar%2frun%2fslapd-IPDOMAIN-COM.socket [2015/02/27 11:05:47.159589, 2, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:794(smbldap_open_connection) smbldap_open_connection: connection opened [2015/02/27 11:05:47.159634, 10, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:954(smbldap_connect_system) ldap_connect_system: Binding to ldap server ldapi://%2fvar%2frun%2fslapd-IPDOMAIN-COM.socket as "(null)" [2015/02/27 11:05:47.181629, 3, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:1013(smbldap_connect_system) ldap_connect_system: successful connection to the LDAP server ldap_connect_system: LDAP server does support paged results [2015/02/27 11:05:47.181725, 4, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:1092(smbldap_open) The LDAP server is successfully connected [2015/02/27 11:05:47.183171, 9, pid=5702, effective(0, 0), real(0, 0)] ipa_sam.c:2164(fill_pdb_trusted_domain) Failed to set forest trust info. [2015/02/27 11:05:47.183238, 5, pid=5702, effective(0, 0), real(0, 0)] ipa_sam.c:2705(ipasam_enum_trusted_domains) ipasam_enum_trusted_domains: got 1 domains [2015/02/27 11:05:47.183289, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_EnumTrustedDomainsEx: struct lsa_EnumTrustedDomainsEx out: struct lsa_EnumTrustedDomainsEx resume_handle : * resume_handle : 0xffffffff (4294967295) domains : * domains: struct lsa_DomainListEx count : 0x00000001 (1) domains : * domains: ARRAY(1) domains: struct lsa_TrustDomainInfoInfoEx domain_name: struct lsa_StringLarge length : 0x0014 (20) size : 0x0016 (22) string : * string : ' ADDOMAIN.INT' netbios_name: struct lsa_StringLarge length : 0x000c (12) size : 0x000e (14) string : * string : 'ADDOMAIN' sid : * sid : S-1-5-21-1343024091-2000478354-725345543 trust_direction : 0x00000003 (3) 1: LSA_TRUST_DIRECTION_INBOUND 1: LSA_TRUST_DIRECTION_OUTBOUND trust_type : LSA_TRUST_TYPE_UPLEVEL (2) trust_attributes : 0x00000008 (8) 0: LSA_TRUST_ATTRIBUTE_NON_TRANSITIVE 0: LSA_TRUST_ATTRIBUTE_UPLEVEL_ONLY 0: LSA_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN 1: LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE 0: LSA_TRUST_ATTRIBUTE_CROSS_ORGANIZATION 0: LSA_TRUST_ATTRIBUTE_WITHIN_FOREST 0: LSA_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL 0: LSA_TRUST_ATTRIBUTE_USES_RC4_ENCRYPTION result : NT_STATUS_OK [2015/02/27 11:05:47.184014, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_req_trigger": 0x7f06abfc9120 [2015/02/27 11:05:47.184066, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_req_trigger": 0x7f06abfc9120 [2015/02/27 11:05:47.184123, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_EnumTrustedDomainsEx: struct lsa_EnumTrustedDomainsEx out: struct lsa_EnumTrustedDomainsEx resume_handle : * resume_handle : 0xffffffff (4294967295) domains : * domains: struct lsa_DomainListEx count : 0x00000001 (1) domains : * domains: ARRAY(1) domains: struct lsa_TrustDomainInfoInfoEx domain_name: struct lsa_StringLarge length : 0x0014 (20) size : 0x0016 (22) string : * string : ' ADDOMAIN.INT' netbios_name: struct lsa_StringLarge length : 0x000c (12) size : 0x000e (14) string : * string : 'ADDOMAIN' sid : * sid : S-1-5-21-1343024091-2000478354-725345543 trust_direction : 0x00000003 (3) 1: LSA_TRUST_DIRECTION_INBOUND 1: LSA_TRUST_DIRECTION_OUTBOUND trust_type : LSA_TRUST_TYPE_UPLEVEL (2) trust_attributes : 0x00000008 (8) 0: LSA_TRUST_ATTRIBUTE_NON_TRANSITIVE 0: LSA_TRUST_ATTRIBUTE_UPLEVEL_ONLY 0: LSA_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN 1: LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE 0: LSA_TRUST_ATTRIBUTE_CROSS_ORGANIZATION 0: LSA_TRUST_ATTRIBUTE_WITHIN_FOREST 0: LSA_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL 0: LSA_TRUST_ATTRIBUTE_USES_RC4_ENCRYPTION result : NT_STATUS_OK [2015/02/27 11:05:47.184804, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_Close: struct lsa_Close in: struct lsa_Close handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000134-0000-0000-f054-6b3346160000 [2015/02/27 11:05:47.184964, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_Close: struct lsa_Close in: struct lsa_Close handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000134-0000-0000-f054-6b3346160000 [2015/02/27 11:05:47.185088, 6, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:337(find_policy_by_hnd_internal) Found policy hnd[0] [0000] 00 00 00 00 34 01 00 00 00 00 00 00 F0 54 6B 33 ....4... .....Tk3 [0010] 46 16 00 00 F... [2015/02/27 11:05:47.185170, 6, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:337(find_policy_by_hnd_internal) Found policy hnd[0] [0000] 00 00 00 00 34 01 00 00 00 00 00 00 F0 54 6B 33 ....4... .....Tk3 [0010] 46 16 00 00 F... [2015/02/27 11:05:47.185240, 6, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:386(close_policy_hnd) Closed policy [2015/02/27 11:05:47.185277, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_Close: struct lsa_Close out: struct lsa_Close handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000000-0000-0000-0000-000000000000 result : NT_STATUS_OK [2015/02/27 11:05:47.185415, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_req_trigger": 0x7f06abfa5bb0 [2015/02/27 11:05:47.185503, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_req_trigger": 0x7f06abfa5bb0 [2015/02/27 11:05:47.185562, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_Close: struct lsa_Close out: struct lsa_Close handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000000-0000-0000-0000-000000000000 result : NT_STATUS_OK [2015/02/27 11:05:47.185710, 10, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:416(close_policy_by_pipe) Deleted handle list for RPC connection \lsarpc [2015/02/27 11:05:47.185770, 4, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_dual.c:1341(child_handler) Finished processing child request 20 [2015/02/27 11:05:47.185811, 10, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_dual.c:1358(child_handler) Writing 3556 bytes to parent [2015/02/27 11:10:47.255289, 4, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_dual.c:1333(child_handler) child daemon request 20 [2015/02/27 11:10:47.255360, 10, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_dual.c:458(child_process_request) child_process_request: request fn LIST_TRUSTDOM [2015/02/27 11:10:47.255401, 3, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_misc.c:161(winbindd_dual_list_trusted_domains) [ 5701]: list trusted domains [2015/02/27 11:10:47.255485, 10, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:2857(trusted_domains) trusted_domains: [Cached] - doing backend query for info for domain IPDOMAIN [2015/02/27 11:10:47.255529, 3, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_samr.c:365(sam_trusted_domains) samr: trusted domains [2015/02/27 11:10:47.255639, 4, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_ncacn_np.c:60(make_internal_rpc_pipe_p) Create pipe requested \lsarpc [2015/02/27 11:10:47.255692, 10, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:221(init_pipe_handles) init_pipe_handle_list: created handle list for pipe \lsarpc [2015/02/27 11:10:47.255734, 10, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:238(init_pipe_handles) init_pipe_handle_list: pipe_handles ref count = 1 for pipe \lsarpc [2015/02/27 11:10:47.255815, 4, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_ncacn_np.c:100(make_internal_rpc_pipe_p) Created internal pipe \lsarpc [2015/02/27 11:10:47.255880, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_OpenPolicy: struct lsa_OpenPolicy in: struct lsa_OpenPolicy system_name : * system_name : 0x005c (92) attr : * attr: struct lsa_ObjectAttribute len : 0x00000018 (24) root_dir : NULL object_name : NULL attributes : 0x00000000 (0) sec_desc : NULL sec_qos : * sec_qos: struct lsa_QosInfo len : 0x0000000c (12) impersonation_level : 0x0002 (2) context_mode : 0x01 (1) effective_only : 0x00 (0) access_mask : 0x02000000 (33554432) 0: LSA_POLICY_VIEW_LOCAL_INFORMATION 0: LSA_POLICY_VIEW_AUDIT_INFORMATION 0: LSA_POLICY_GET_PRIVATE_INFORMATION 0: LSA_POLICY_TRUST_ADMIN 0: LSA_POLICY_CREATE_ACCOUNT 0: LSA_POLICY_CREATE_SECRET 0: LSA_POLICY_CREATE_PRIVILEGE 0: LSA_POLICY_SET_DEFAULT_QUOTA_LIMITS 0: LSA_POLICY_SET_AUDIT_REQUIREMENTS 0: LSA_POLICY_AUDIT_LOG_ADMIN 0: LSA_POLICY_SERVER_ADMIN 0: LSA_POLICY_LOOKUP_NAMES 0: LSA_POLICY_NOTIFICATION [2015/02/27 11:10:47.256395, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_OpenPolicy: struct lsa_OpenPolicy in: struct lsa_OpenPolicy system_name : * system_name : 0x005c (92) attr : * attr: struct lsa_ObjectAttribute len : 0x00000018 (24) root_dir : NULL object_name : NULL attributes : 0x00000000 (0) sec_desc : NULL sec_qos : * sec_qos: struct lsa_QosInfo len : 0x0000000c (12) impersonation_level : 0x0002 (2) context_mode : 0x01 (1) effective_only : 0x00 (0) access_mask : 0x02000000 (33554432) 0: LSA_POLICY_VIEW_LOCAL_INFORMATION 0: LSA_POLICY_VIEW_AUDIT_INFORMATION 0: LSA_POLICY_GET_PRIVATE_INFORMATION 0: LSA_POLICY_TRUST_ADMIN 0: LSA_POLICY_CREATE_ACCOUNT 0: LSA_POLICY_CREATE_SECRET 0: LSA_POLICY_CREATE_PRIVILEGE 0: LSA_POLICY_SET_DEFAULT_QUOTA_LIMITS 0: LSA_POLICY_SET_AUDIT_REQUIREMENTS 0: LSA_POLICY_AUDIT_LOG_ADMIN 0: LSA_POLICY_SERVER_ADMIN 0: LSA_POLICY_LOOKUP_NAMES 0: LSA_POLICY_NOTIFICATION [2015/02/27 11:10:47.256938, 10, pid=5702, effective(0, 0), real(0, 0)] ../libcli/security/access_check.c:58(se_map_generic) se_map_generic(): mapped mask 0xb0000000 to 0x000f0fff [2015/02/27 11:10:47.257001, 4, pid=5702, effective(0, 0), real(0, 0)] ../source3/rpc_server/srv_access_check.c:84(access_check_object) _lsa_OpenPolicy2: ACCESS should be DENIED (requested: 0x000f0fff) but overritten by euid == sec_initial_uid() [2015/02/27 11:10:47.257057, 4, pid=5702, effective(0, 0), real(0, 0)] ../source3/rpc_server/srv_access_check.c:105(access_check_object) _lsa_OpenPolicy2: access GRANTED (requested: 0x000f0fff, granted: 0x000f0fff) [2015/02/27 11:10:47.257100, 6, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:302(create_rpc_handle_internal) Opened policy hnd[1] [0000] 00 00 00 00 35 01 00 00 00 00 00 00 F0 54 97 34 ....5... .....T.4 [0010] 46 16 00 00 F... [2015/02/27 11:10:47.257176, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_OpenPolicy: struct lsa_OpenPolicy out: struct lsa_OpenPolicy handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000135-0000-0000-f054-973446160000 result : NT_STATUS_OK [2015/02/27 11:10:47.257321, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_req_trigger": 0x7f06abfa9f40 [2015/02/27 11:10:47.257365, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_req_trigger": 0x7f06abfa9f40 [2015/02/27 11:10:47.257410, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_OpenPolicy: struct lsa_OpenPolicy out: struct lsa_OpenPolicy handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000135-0000-0000-f054-973446160000 result : NT_STATUS_OK [2015/02/27 11:10:47.257600, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_EnumTrustedDomainsEx: struct lsa_EnumTrustedDomainsEx in: struct lsa_EnumTrustedDomainsEx handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000135-0000-0000-f054-973446160000 resume_handle : * resume_handle : 0x00000000 (0) max_size : 0xffffffff (4294967295) [2015/02/27 11:10:47.257778, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_EnumTrustedDomainsEx: struct lsa_EnumTrustedDomainsEx in: struct lsa_EnumTrustedDomainsEx handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000135-0000-0000-f054-973446160000 resume_handle : * resume_handle : 0x00000000 (0) max_size : 0xffffffff (4294967295) [2015/02/27 11:10:47.257948, 6, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:337(find_policy_by_hnd_internal) Found policy hnd[0] [0000] 00 00 00 00 35 01 00 00 00 00 00 00 F0 54 97 34 ....5... .....T.4 [0010] 46 16 00 00 F... [2015/02/27 11:10:47.258027, 5, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:1249(smbldap_search_ext) smbldap_search_ext: base => [cn=ad,cn=trusts,dc=IPDOMAIN,dc=com], filter => [(objectClass=ipaNTTrustedDomain)], scope => [2] [2015/02/27 11:10:47.258808, 10, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:595(smb_ldap_setup_conn) smb_ldap_setup_connection: ldapi://%2fvar%2frun%2fslapd-IPDOMAIN-COM.socket [2015/02/27 11:10:47.258946, 2, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:794(smbldap_open_connection) smbldap_open_connection: connection opened [2015/02/27 11:10:47.259026, 10, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:954(smbldap_connect_system) ldap_connect_system: Binding to ldap server ldapi://%2fvar%2frun%2fslapd-IPDOMAIN-COM.socket as "(null)" [2015/02/27 11:10:47.282065, 3, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:1013(smbldap_connect_system) ldap_connect_system: successful connection to the LDAP server ldap_connect_system: LDAP server does support paged results [2015/02/27 11:10:47.282170, 4, pid=5702, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:1092(smbldap_open) The LDAP server is successfully connected [2015/02/27 11:10:47.283882, 9, pid=5702, effective(0, 0), real(0, 0)] ipa_sam.c:2164(fill_pdb_trusted_domain) Failed to set forest trust info. [2015/02/27 11:10:47.283952, 5, pid=5702, effective(0, 0), real(0, 0)] ipa_sam.c:2705(ipasam_enum_trusted_domains) ipasam_enum_trusted_domains: got 1 domains [2015/02/27 11:10:47.283999, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_EnumTrustedDomainsEx: struct lsa_EnumTrustedDomainsEx out: struct lsa_EnumTrustedDomainsEx resume_handle : * resume_handle : 0xffffffff (4294967295) domains : * domains: struct lsa_DomainListEx count : 0x00000001 (1) domains : * domains: ARRAY(1) domains: struct lsa_TrustDomainInfoInfoEx domain_name: struct lsa_StringLarge length : 0x0014 (20) size : 0x0016 (22) string : * string : ' ADDOMAIN.INT' netbios_name: struct lsa_StringLarge length : 0x000c (12) size : 0x000e (14) string : * string : 'ADDOMAIN' sid : * sid : S-1-5-21-1343024091-2000478354-725345543 trust_direction : 0x00000003 (3) 1: LSA_TRUST_DIRECTION_INBOUND 1: LSA_TRUST_DIRECTION_OUTBOUND trust_type : LSA_TRUST_TYPE_UPLEVEL (2) trust_attributes : 0x00000008 (8) 0: LSA_TRUST_ATTRIBUTE_NON_TRANSITIVE 0: LSA_TRUST_ATTRIBUTE_UPLEVEL_ONLY 0: LSA_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN 1: LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE 0: LSA_TRUST_ATTRIBUTE_CROSS_ORGANIZATION 0: LSA_TRUST_ATTRIBUTE_WITHIN_FOREST 0: LSA_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL 0: LSA_TRUST_ATTRIBUTE_USES_RC4_ENCRYPTION result : NT_STATUS_OK [2015/02/27 11:10:47.284677, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_req_trigger": 0x7f06abfa9f40 [2015/02/27 11:10:47.284741, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_req_trigger": 0x7f06abfa9f40 [2015/02/27 11:10:47.284801, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_EnumTrustedDomainsEx: struct lsa_EnumTrustedDomainsEx out: struct lsa_EnumTrustedDomainsEx resume_handle : * resume_handle : 0xffffffff (4294967295) domains : * domains: struct lsa_DomainListEx count : 0x00000001 (1) domains : * domains: ARRAY(1) domains: struct lsa_TrustDomainInfoInfoEx domain_name: struct lsa_StringLarge length : 0x0014 (20) size : 0x0016 (22) string : * string : ' ADDOMAIN.INT' netbios_name: struct lsa_StringLarge length : 0x000c (12) size : 0x000e (14) string : * string : 'ADDOMAIN' sid : * sid : S-1-5-21-1343024091-2000478354-725345543 trust_direction : 0x00000003 (3) 1: LSA_TRUST_DIRECTION_INBOUND 1: LSA_TRUST_DIRECTION_OUTBOUND trust_type : LSA_TRUST_TYPE_UPLEVEL (2) trust_attributes : 0x00000008 (8) 0: LSA_TRUST_ATTRIBUTE_NON_TRANSITIVE 0: LSA_TRUST_ATTRIBUTE_UPLEVEL_ONLY 0: LSA_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN 1: LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE 0: LSA_TRUST_ATTRIBUTE_CROSS_ORGANIZATION 0: LSA_TRUST_ATTRIBUTE_WITHIN_FOREST 0: LSA_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL 0: LSA_TRUST_ATTRIBUTE_USES_RC4_ENCRYPTION result : NT_STATUS_OK [2015/02/27 11:10:47.285545, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_Close: struct lsa_Close in: struct lsa_Close handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000135-0000-0000-f054-973446160000 [2015/02/27 11:10:47.285697, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_Close: struct lsa_Close in: struct lsa_Close handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000135-0000-0000-f054-973446160000 [2015/02/27 11:10:47.285846, 6, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:337(find_policy_by_hnd_internal) Found policy hnd[0] [0000] 00 00 00 00 35 01 00 00 00 00 00 00 F0 54 97 34 ....5... .....T.4 [0010] 46 16 00 00 F... [2015/02/27 11:10:47.285933, 6, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:337(find_policy_by_hnd_internal) Found policy hnd[0] [0000] 00 00 00 00 35 01 00 00 00 00 00 00 F0 54 97 34 ....5... .....T.4 [0010] 46 16 00 00 F... [2015/02/27 11:10:47.286004, 6, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:386(close_policy_hnd) Closed policy [2015/02/27 11:10:47.286043, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_Close: struct lsa_Close out: struct lsa_Close handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000000-0000-0000-0000-000000000000 result : NT_STATUS_OK [2015/02/27 11:10:47.286185, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_req_trigger": 0x7f06abf9e0d0 [2015/02/27 11:10:47.286228, 50, pid=5702, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_req_trigger": 0x7f06abf9e0d0 [2015/02/27 11:10:47.286271, 1, pid=5702, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) lsa_Close: struct lsa_Close out: struct lsa_Close handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000000-0000-0000-0000-000000000000 result : NT_STATUS_OK [2015/02/27 11:10:47.286414, 10, pid=5702, effective(0, 0), real(0, 0), class=rpc_srv] ../source3/rpc_server/rpc_handles.c:416(close_policy_by_pipe) Deleted handle list for RPC connection \lsarpc [2015/02/27 11:10:47.286510, 4, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_dual.c:1341(child_handler) Finished processing child request 20 [2015/02/27 11:10:47.286552, 10, pid=5702, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_dual.c:1358(child_handler) Writing 3556 bytes to parent /var/log/samba/log.winbindd [2015/02/27 11:00:47.052902, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Running timer event 0x7f06abf8d030 "rescan_trusted_domains" [2015/02/27 11:00:47.053077, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f06abf8a520 [2015/02/27 11:00:47.053128, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Added timed event "rescan_trusted_domains": 0x7f06abf8b6c0 [2015/02/27 11:00:47.053169, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Ending timer event 0x7f06abf8d030 "rescan_trusted_domains" [2015/02/27 11:00:47.053213, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f06abf8a520 [2015/02/27 11:00:47.053269, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Added timed event "tevent_req_timedout": 0x7f06abf8c200 [2015/02/27 11:00:47.082050, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Destroying timer event 0x7f06abf8c200 "tevent_req_timedout" [2015/02/27 11:00:47.082144, 18, pid=5701, effective(0, 0), real(0, 0)] ../source3/lib/util_tdb.c:286(tdb_unpack) tdb_unpack(d, 167) -> 4 [2015/02/27 11:00:47.082190, 18, pid=5701, effective(0, 0), real(0, 0)] ../source3/lib/util_tdb.c:286(tdb_unpack) tdb_unpack(fffddd, 163) -> 30 [2015/02/27 11:00:47.082229, 11, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:4509(unpack_tdc_domains) unpack_tdc_domains: Unpacking domain BUILTIN () SID S-1-5-32, flags = 0x0, attribs = 0x0, type = 0x0 [2015/02/27 11:00:47.082270, 18, pid=5701, effective(0, 0), real(0, 0)] ../source3/lib/util_tdb.c:286(tdb_unpack) tdb_unpack(fffddd, 133) -> 62 [2015/02/27 11:00:47.082309, 11, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:4509(unpack_tdc_domains) unpack_tdc_domains: Unpacking domain IPADOMAIN () SID S-1-5-21-3255298129-77778957-3353535001, flags = 0x0, attribs = 0x0, type = 0x0 [2015/02/27 11:00:47.082350, 18, pid=5701, effective(0, 0), real(0, 0)] ../source3/lib/util_tdb.c:286(tdb_unpack) tdb_unpack(fffddd, 71) -> 71 [2015/02/27 11:00:47.082388, 11, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:4509(unpack_tdc_domains) unpack_tdc_domains: Unpacking domain ADDOMAIN (ADDOMAIN.COM) SID S-1-5-21-1343024091-2000478354-725345543, flags = 0x0, attribs = 0x0, type = 0x0 [2015/02/27 11:05:47.153573, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Running timer event 0x7f06abf8b6c0 "rescan_trusted_domains" [2015/02/27 11:05:47.154271, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f06abf8a520 [2015/02/27 11:05:47.154325, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Added timed event "rescan_trusted_domains": 0x7f06abf8d030 [2015/02/27 11:05:47.154365, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Ending timer event 0x7f06abf8b6c0 "rescan_trusted_domains" [2015/02/27 11:05:47.154486, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f06abf8a520 [2015/02/27 11:05:47.154561, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Added timed event "tevent_req_timedout": 0x7f06abf8c2c0 [2015/02/27 11:05:47.185908, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Destroying timer event 0x7f06abf8c2c0 "tevent_req_timedout" [2015/02/27 11:05:47.186051, 18, pid=5701, effective(0, 0), real(0, 0)] ../source3/lib/util_tdb.c:286(tdb_unpack) tdb_unpack(d, 167) -> 4 [2015/02/27 11:05:47.186099, 18, pid=5701, effective(0, 0), real(0, 0)] ../source3/lib/util_tdb.c:286(tdb_unpack) tdb_unpack(fffddd, 163) -> 30 [2015/02/27 11:05:47.186137, 11, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:4509(unpack_tdc_domains) unpack_tdc_domains: Unpacking domain BUILTIN () SID S-1-5-32, flags = 0x0, attribs = 0x0, type = 0x0 [2015/02/27 11:05:47.186178, 18, pid=5701, effective(0, 0), real(0, 0)] ../source3/lib/util_tdb.c:286(tdb_unpack) tdb_unpack(fffddd, 133) -> 62 [2015/02/27 11:05:47.186216, 11, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:4509(unpack_tdc_domains) unpack_tdc_domains: Unpacking domain IPADOMAIN () SID S-1-5-21-3255298129-77778957-3353535001, flags = 0x0, attribs = 0x0, type = 0x0 [2015/02/27 11:05:47.186257, 18, pid=5701, effective(0, 0), real(0, 0)] ../source3/lib/util_tdb.c:286(tdb_unpack) tdb_unpack(fffddd, 71) -> 71 [2015/02/27 11:05:47.186294, 11, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:4509(unpack_tdc_domains) unpack_tdc_domains: Unpacking domain ADDOMAIN (ADDOMAIN.COM) SID S-1-5-21-1343024091-2000478354-725345543, flags = 0x0, attribs = 0x0, type = 0x0 [2015/02/27 11:08:48.908349, 6, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:870(new_connection) accepted socket 23 [2015/02/27 11:08:48.908935, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:720(process_request) process_request: request fn COMERFACE_VERSION [2015/02/27 11:08:48.908986, 3, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_misc.c:395(winbindd_COMerface_version) [11419]: request COMerface version [2015/02/27 11:08:48.909031, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f06abf8c0c0 [2015/02/27 11:08:48.909072, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f06abf8c0c0 [2015/02/27 11:08:48.909129, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:816(winbind_client_response_written) winbind_client_response_written[11419:COMERFACE_VERSION]: delivered response to client [2015/02/27 11:08:48.909216, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:720(process_request) process_request: request fn WINBINDD_PRIV_PIPE_DIR [2015/02/27 11:08:48.909270, 3, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_misc.c:428(winbindd_priv_pipe_dir) [11419]: request location of privileged pipe [2015/02/27 11:08:48.909498, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f06abf8c0c0 [2015/02/27 11:08:48.909556, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f06abf8c0c0 [2015/02/27 11:08:48.909614, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:816(winbind_client_response_written) winbind_client_response_written[11419:WINBINDD_PRIV_PIPE_DIR]: delivered response to client [2015/02/27 11:08:48.909751, 6, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:870(new_connection) accepted socket 28 [2015/02/27 11:08:48.909815, 6, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:918(winbind_client_request_read) closing socket 23, client exited [2015/02/27 11:08:48.909881, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:693(process_request) process_request: Handling async request 11419:SID_TO_GID [2015/02/27 11:08:48.909925, 3, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_sid_to_gid.c:48(winbindd_sid_to_gid_send) sid to gid S-1-5-32-544 [2015/02/27 11:08:48.909970, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/wb_sids2xids.c:95(wb_sids2xids_send) SID 0: S-1-5-32-544 [2015/02/27 11:08:48.910076, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/wb_lookupsids.c:254(wb_lookupsids_bulk) No bulk setup for SID S-1-5-32-544 with 2 subauths [2015/02/27 11:08:48.910138, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:791(find_lookup_domain_from_sid) find_lookup_domain_from_sid(S-1-5-32-544) [2015/02/27 11:08:48.910181, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:794(find_lookup_domain_from_sid) calling find_domain_from_sid [2015/02/27 11:08:48.910228, 1, pid=5701, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_prCOM_function_debug) wbCOM_LookupSid: struct wbCOM_LookupSid in: struct wbCOM_LookupSid sid : * sid : S-1-5-32-544 [2015/02/27 11:08:48.910380, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f06abf7fd90 [2015/02/27 11:08:48.910463, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f06abf7fd90 [2015/02/27 11:08:48.910538, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Added timed event "tevent_req_timedout": 0x7f06abf8e3b0 [2015/02/27 11:08:48.924276, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Destroying timer event 0x7f06abf8e3b0 "tevent_req_timedout" [2015/02/27 11:08:48.924359, 1, pid=5701, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_prCOM_function_debug) wbCOM_LookupSid: struct wbCOM_LookupSid out: struct wbCOM_LookupSid type : * type : SID_NAME_ALIAS (4) domain : * domain : * domain : 'BUILTIN' name : * name : * name : 'Administrators' result : NT_STATUS_OK [2015/02/27 11:08:48.924605, 1, pid=5701, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_prCOM_function_debug) wbCOM_Sids2UnixIDs: struct wbCOM_Sids2UnixIDs in: struct wbCOM_Sids2UnixIDs domains : * domains: struct lsa_RefDomainList count : 0x00000001 (1) domains : * domains: ARRAY(1) domains: struct lsa_DomainInfo name: struct lsa_StringLarge length : 0x000e (14) size : 0x0010 (16) string : * string : 'BUILTIN' sid : * sid : S-1-5-32 max_size : 0x00000000 (0) ids : * ids: struct wbCOM_TransIDArray num_ids : 0x00000001 (1) ids: ARRAY(1) ids: struct wbCOM_TransID type : ID_TYPE_GID (2) domain_index : 0x00000000 (0) rid : 0x00000220 (544) xid: struct unixid id : 0xffffffff (4294967295) type : ID_TYPE_GID (2) [2015/02/27 11:08:48.925081, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f06abf89a40 [2015/02/27 11:08:48.925134, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f06abf89a40 [2015/02/27 11:08:48.925182, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Added timed event "tevent_req_timedout": 0x7f06abf8e1a0 [2015/02/27 11:08:48.926573, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Destroying timer event 0x7f06abf8e1a0 "tevent_req_timedout" [2015/02/27 11:08:48.926634, 1, pid=5701, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_prCOM_function_debug) wbCOM_Sids2UnixIDs: struct wbCOM_Sids2UnixIDs out: struct wbCOM_Sids2UnixIDs ids : * ids: struct wbCOM_TransIDArray num_ids : 0x00000001 (1) ids: ARRAY(1) ids: struct wbCOM_TransID type : ID_TYPE_GID (2) domain_index : 0x00000000 (0) rid : 0x00000220 (544) xid: struct unixid id : 0xffffffff (4294967295) type : ID_TYPE_GID (2) result : NT_STATUS_OK [2015/02/27 11:08:48.926907, 10, pid=5701, effective(0, 0), real(0, 0), class=tdb] ../source3/lib/gencache.c:296(gencache_set_data_blob) Adding cache entry with key=[IDMAP/SID2XID/S-1-5-32-544] and timeout=[Fri Feb 27 11:10:48 AM 2015 EET] (120 seconds ahead) [2015/02/27 11:08:48.926996, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:755(wb_request_done) wb_request_done[11419:SID_TO_GID]: NT_STATUS_OK [2015/02/27 11:08:48.927044, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f06abf8d3b0 [2015/02/27 11:08:48.927092, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f06abf8d3b0 [2015/02/27 11:08:48.927153, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:816(winbind_client_response_written) winbind_client_response_written[11419:SID_TO_GID]: delivered response to client [2015/02/27 11:08:48.927563, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:693(process_request) process_request: Handling async request 11419:SID_TO_GID [2015/02/27 11:08:48.927619, 3, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_sid_to_gid.c:48(winbindd_sid_to_gid_send) sid to gid S-1-5-32-545 [2015/02/27 11:08:48.927662, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/wb_sids2xids.c:95(wb_sids2xids_send) SID 0: S-1-5-32-545 [2015/02/27 11:08:48.927717, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/wb_lookupsids.c:254(wb_lookupsids_bulk) No bulk setup for SID S-1-5-32-545 with 2 subauths [2015/02/27 11:08:48.927765, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:791(find_lookup_domain_from_sid) find_lookup_domain_from_sid(S-1-5-32-545) [2015/02/27 11:08:48.927809, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:794(find_lookup_domain_from_sid) calling find_domain_from_sid [2015/02/27 11:08:48.927863, 1, pid=5701, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_prCOM_function_debug) wbCOM_LookupSid: struct wbCOM_LookupSid in: struct wbCOM_LookupSid sid : * sid : S-1-5-32-545 [2015/02/27 11:08:48.927962, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f06abf7fd90 [2015/02/27 11:08:48.928006, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f06abf7fd90 [2015/02/27 11:08:48.928052, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Added timed event "tevent_req_timedout": 0x7f06abf8e3b0 [2015/02/27 11:08:48.934789, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Destroying timer event 0x7f06abf8e3b0 "tevent_req_timedout" [2015/02/27 11:08:48.934862, 1, pid=5701, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_prCOM_function_debug) wbCOM_LookupSid: struct wbCOM_LookupSid out: struct wbCOM_LookupSid type : * type : SID_NAME_ALIAS (4) domain : * domain : * domain : 'BUILTIN' name : * name : * name : 'Users' result : NT_STATUS_OK [2015/02/27 11:08:48.935071, 1, pid=5701, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_prCOM_function_debug) wbCOM_Sids2UnixIDs: struct wbCOM_Sids2UnixIDs in: struct wbCOM_Sids2UnixIDs domains : * domains: struct lsa_RefDomainList count : 0x00000001 (1) domains : * domains: ARRAY(1) domains: struct lsa_DomainInfo name: struct lsa_StringLarge length : 0x000e (14) size : 0x0010 (16) string : * string : 'BUILTIN' sid : * sid : S-1-5-32 max_size : 0x00000000 (0) ids : * ids: struct wbCOM_TransIDArray num_ids : 0x00000001 (1) ids: ARRAY(1) ids: struct wbCOM_TransID type : ID_TYPE_GID (2) domain_index : 0x00000000 (0) rid : 0x00000221 (545) xid: struct unixid id : 0xffffffff (4294967295) type : ID_TYPE_GID (2) [2015/02/27 11:08:48.935580, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f06abf89a40 [2015/02/27 11:08:48.935627, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f06abf89a40 [2015/02/27 11:08:48.935675, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Added timed event "tevent_req_timedout": 0x7f06abf8e1a0 [2015/02/27 11:08:48.936900, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Destroying timer event 0x7f06abf8e1a0 "tevent_req_timedout" [2015/02/27 11:08:48.936961, 1, pid=5701, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_prCOM_function_debug) wbCOM_Sids2UnixIDs: struct wbCOM_Sids2UnixIDs out: struct wbCOM_Sids2UnixIDs ids : * ids: struct wbCOM_TransIDArray num_ids : 0x00000001 (1) ids: ARRAY(1) ids: struct wbCOM_TransID type : ID_TYPE_GID (2) domain_index : 0x00000000 (0) rid : 0x00000221 (545) xid: struct unixid id : 0xffffffff (4294967295) type : ID_TYPE_GID (2) result : NT_STATUS_OK [2015/02/27 11:08:48.937228, 10, pid=5701, effective(0, 0), real(0, 0), class=tdb] ../source3/lib/gencache.c:296(gencache_set_data_blob) Adding cache entry with key=[IDMAP/SID2XID/S-1-5-32-545] and timeout=[Fri Feb 27 11:10:48 AM 2015 EET] (120 seconds ahead) [2015/02/27 11:08:48.937301, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:755(wb_request_done) wb_request_done[11419:SID_TO_GID]: NT_STATUS_OK [2015/02/27 11:08:48.937347, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f06abf8d3b0 [2015/02/27 11:08:48.937388, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f06abf8d3b0 [2015/02/27 11:08:48.937476, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:816(winbind_client_response_written) winbind_client_response_written[11419:SID_TO_GID]: delivered response to client [2015/02/27 11:08:48.938814, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:693(process_request) process_request: Handling async request 11419:SIDS_TO_XIDS [2015/02/27 11:08:48.938877, 3, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_sids_to_xids.c:50(winbindd_sids_to_xids_send) sids_to_xids [2015/02/27 11:08:48.938920, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_sids_to_xids.c:68(winbindd_sids_to_xids_send) num_sids: 3 [2015/02/27 11:08:48.938960, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/wb_sids2xids.c:95(wb_sids2xids_send) SID 0: S-1-1-0 [2015/02/27 11:08:48.939011, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/wb_sids2xids.c:95(wb_sids2xids_send) SID 1: S-1-5-2 [2015/02/27 11:08:48.939059, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/wb_sids2xids.c:95(wb_sids2xids_send) SID 2: S-1-5-11 [2015/02/27 11:08:48.939108, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/wb_lookupsids.c:254(wb_lookupsids_bulk) No bulk setup for SID S-1-1-0 with 1 subauths [2015/02/27 11:08:48.939149, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/wb_lookupsids.c:254(wb_lookupsids_bulk) No bulk setup for SID S-1-5-2 with 1 subauths [2015/02/27 11:08:48.939187, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/wb_lookupsids.c:254(wb_lookupsids_bulk) No bulk setup for SID S-1-5-11 with 1 subauths [2015/02/27 11:08:48.939227, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:791(find_lookup_domain_from_sid) find_lookup_domain_from_sid(S-1-1-0) [2015/02/27 11:08:48.939267, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:794(find_lookup_domain_from_sid) calling find_domain_from_sid [2015/02/27 11:08:48.939304, 5, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/wb_lookupsid.c:53(wb_lookupsid_send) Could not find domain for sid S-1-1-0 [2015/02/27 11:08:48.939344, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_req_trigger": 0x7f06abf8cb60 [2015/02/27 11:08:48.939386, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_req_trigger": 0x7f06abf8cb60 [2015/02/27 11:08:48.939459, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:791(find_lookup_domain_from_sid) find_lookup_domain_from_sid(S-1-5-2) [2015/02/27 11:08:48.939506, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:794(find_lookup_domain_from_sid) calling find_domain_from_sid [2015/02/27 11:08:48.939543, 5, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/wb_lookupsid.c:53(wb_lookupsid_send) Could not find domain for sid S-1-5-2 [2015/02/27 11:08:48.939583, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_req_trigger": 0x7f06abf8ca80 [2015/02/27 11:08:48.939622, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_req_trigger": 0x7f06abf8ca80 [2015/02/27 11:08:48.939664, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:791(find_lookup_domain_from_sid) find_lookup_domain_from_sid(S-1-5-11) [2015/02/27 11:08:48.939704, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:794(find_lookup_domain_from_sid) calling find_domain_from_sid [2015/02/27 11:08:48.939741, 5, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/wb_lookupsid.c:53(wb_lookupsid_send) Could not find domain for sid S-1-5-11 [2015/02/27 11:08:48.939780, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_req_trigger": 0x7f06abf87cc0 [2015/02/27 11:08:48.939828, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_req_trigger": 0x7f06abf87cc0 [2015/02/27 11:08:48.939874, 1, pid=5701, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_prCOM_function_debug) wbCOM_Sids2UnixIDs: struct wbCOM_Sids2UnixIDs in: struct wbCOM_Sids2UnixIDs domains : * domains: struct lsa_RefDomainList count : 0x00000002 (2) domains : * domains: ARRAY(2) domains: struct lsa_DomainInfo name: struct lsa_StringLarge length : 0x0000 (0) size : 0x0002 (2) string : * string : '' sid : * sid : S-1-1 domains: struct lsa_DomainInfo name: struct lsa_StringLarge length : 0x0000 (0) size : 0x0002 (2) string : * string : '' sid : * sid : S-1-5 max_size : 0x00000000 (0) ids : * ids: struct wbCOM_TransIDArray num_ids : 0x00000003 (3) ids: ARRAY(3) ids: struct wbCOM_TransID type : ID_TYPE_NOT_SPECIFIED (0) domain_index : 0x00000000 (0) rid : 0x00000000 (0) xid: struct unixid id : 0xffffffff (4294967295) type : ID_TYPE_NOT_SPECIFIED (0) ids: struct wbCOM_TransID type : ID_TYPE_NOT_SPECIFIED (0) domain_index : 0x00000001 (1) rid : 0x00000002 (2) xid: struct unixid id : 0xffffffff (4294967295) type : ID_TYPE_NOT_SPECIFIED (0) ids: struct wbCOM_TransID type : ID_TYPE_NOT_SPECIFIED (0) domain_index : 0x00000001 (1) rid : 0x0000000b (11) xid: struct unixid id : 0xffffffff (4294967295) type : ID_TYPE_NOT_SPECIFIED (0) [2015/02/27 11:08:48.940740, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f06abf89a40 [2015/02/27 11:08:48.940788, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f06abf89a40 [2015/02/27 11:08:48.940835, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Added timed event "tevent_req_timedout": 0x7f06abf8e7f0 [2015/02/27 11:08:48.942839, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Destroying timer event 0x7f06abf8e7f0 "tevent_req_timedout" [2015/02/27 11:08:48.942898, 1, pid=5701, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_prCOM_function_debug) wbCOM_Sids2UnixIDs: struct wbCOM_Sids2UnixIDs out: struct wbCOM_Sids2UnixIDs ids : * ids: struct wbCOM_TransIDArray num_ids : 0x00000003 (3) ids: ARRAY(3) ids: struct wbCOM_TransID type : ID_TYPE_NOT_SPECIFIED (0) domain_index : 0x00000000 (0) rid : 0x00000000 (0) xid: struct unixid id : 0xffffffff (4294967295) type : ID_TYPE_NOT_SPECIFIED (0) ids: struct wbCOM_TransID type : ID_TYPE_NOT_SPECIFIED (0) domain_index : 0x00000001 (1) rid : 0x00000002 (2) xid: struct unixid id : 0xffffffff (4294967295) type : ID_TYPE_NOT_SPECIFIED (0) ids: struct wbCOM_TransID type : ID_TYPE_NOT_SPECIFIED (0) domain_index : 0x00000001 (1) rid : 0x0000000b (11) xid: struct unixid id : 0xffffffff (4294967295) type : ID_TYPE_NOT_SPECIFIED (0) result : NT_STATUS_OK [2015/02/27 11:08:48.943379, 10, pid=5701, effective(0, 0), real(0, 0), class=tdb] ../source3/lib/gencache.c:296(gencache_set_data_blob) Adding cache entry with key=[IDMAP/SID2XID/S-1-1-0] and timeout=[Fri Feb 27 11:10:48 AM 2015 EET] (120 seconds ahead) [2015/02/27 11:08:48.943483, 10, pid=5701, effective(0, 0), real(0, 0), class=tdb] ../source3/lib/gencache.c:296(gencache_set_data_blob) Adding cache entry with key=[IDMAP/SID2XID/S-1-5-2] and timeout=[Fri Feb 27 11:10:48 AM 2015 EET] (120 seconds ahead) [2015/02/27 11:08:48.943558, 10, pid=5701, effective(0, 0), real(0, 0), class=tdb] ../source3/lib/gencache.c:296(gencache_set_data_blob) Adding cache entry with key=[IDMAP/SID2XID/S-1-5-11] and timeout=[Fri Feb 27 11:10:48 AM 2015 EET] (120 seconds ahead) [2015/02/27 11:08:48.943683, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:755(wb_request_done) wb_request_done[11419:SIDS_TO_XIDS]: NT_STATUS_OK [2015/02/27 11:08:48.943749, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f06abf8d3b0 [2015/02/27 11:08:48.943810, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f06abf8d3b0 [2015/02/27 11:08:48.943887, 10, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:816(winbind_client_response_written) winbind_client_response_written[11419:SIDS_TO_XIDS]: delivered response to client [2015/02/27 11:08:49.318259, 6, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:918(winbind_client_request_read) closing socket 28, client exited [2015/02/27 11:10:47.254799, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Running timer event 0x7f06abf8d030 "rescan_trusted_domains" [2015/02/27 11:10:47.254986, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f06abf8a520 [2015/02/27 11:10:47.255035, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Added timed event "rescan_trusted_domains": 0x7f06abf8b6c0 [2015/02/27 11:10:47.255076, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Ending timer event 0x7f06abf8d030 "rescan_trusted_domains" [2015/02/27 11:10:47.255120, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f06abf8a520 [2015/02/27 11:10:47.255176, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Added timed event "tevent_req_timedout": 0x7f06abf8c200 [2015/02/27 11:10:47.286656, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Destroying timer event 0x7f06abf8c200 "tevent_req_timedout" [2015/02/27 11:10:47.286751, 18, pid=5701, effective(0, 0), real(0, 0)] ../source3/lib/util_tdb.c:286(tdb_unpack) tdb_unpack(d, 167) -> 4 [2015/02/27 11:10:47.286797, 18, pid=5701, effective(0, 0), real(0, 0)] ../source3/lib/util_tdb.c:286(tdb_unpack) tdb_unpack(fffddd, 163) -> 30 [2015/02/27 11:10:47.286835, 11, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:4509(unpack_tdc_domains) unpack_tdc_domains: Unpacking domain BUILTIN () SID S-1-5-32, flags = 0x0, attribs = 0x0, type = 0x0 [2015/02/27 11:10:47.286884, 18, pid=5701, effective(0, 0), real(0, 0)] ../source3/lib/util_tdb.c:286(tdb_unpack) tdb_unpack(fffddd, 133) -> 62 [2015/02/27 11:10:47.286924, 11, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:4509(unpack_tdc_domains) unpack_tdc_domains: Unpacking domain IPADOMAIN () SID S-1-5-21-3255298129-77778957-3353535001, flags = 0x0, attribs = 0x0, type = 0x0 [2015/02/27 11:10:47.286965, 18, pid=5701, effective(0, 0), real(0, 0)] ../source3/lib/util_tdb.c:286(tdb_unpack) tdb_unpack(fffddd, 71) -> 71 [2015/02/27 11:10:47.287003, 11, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:4509(unpack_tdc_domains) unpack_tdc_domains: Unpacking domain ADDOMAIN (ADDOMAIN.COM) SID S-1-5-21-1343024091-2000478354-725345543, flags = 0x0, attribs = 0x0, type = 0x0 [2015/02/27 11:15:47.338716, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Running timer event 0x7f06abf8b6c0 "rescan_trusted_domains" [2015/02/27 11:15:47.338947, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f06abf8a520 [2015/02/27 11:15:47.338998, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Added timed event "rescan_trusted_domains": 0x7f06abf8d030 [2015/02/27 11:15:47.339038, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Ending timer event 0x7f06abf8b6c0 "rescan_trusted_domains" [2015/02/27 11:15:47.339083, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f06abf8a520 [2015/02/27 11:15:47.339138, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Added timed event "tevent_req_timedout": 0x7f06abf8c2c0 [2015/02/27 11:15:47.369479, 50, pid=5701, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Destroying timer event 0x7f06abf8c2c0 "tevent_req_timedout" [2015/02/27 11:15:47.369590, 18, pid=5701, effective(0, 0), real(0, 0)] ../source3/lib/util_tdb.c:286(tdb_unpack) tdb_unpack(d, 167) -> 4 [2015/02/27 11:15:47.369649, 18, pid=5701, effective(0, 0), real(0, 0)] ../source3/lib/util_tdb.c:286(tdb_unpack) tdb_unpack(fffddd, 163) -> 30 [2015/02/27 11:15:47.369689, 11, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:4509(unpack_tdc_domains) unpack_tdc_domains: Unpacking domain BUILTIN () SID S-1-5-32, flags = 0x0, attribs = 0x0, type = 0x0 [2015/02/27 11:15:47.369730, 18, pid=5701, effective(0, 0), real(0, 0)] ../source3/lib/util_tdb.c:286(tdb_unpack) tdb_unpack(fffddd, 133) -> 62 [2015/02/27 11:15:47.369769, 11, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:4509(unpack_tdc_domains) unpack_tdc_domains: Unpacking domain IPADOMAIN () SID S-1-5-21-3255298129-77778957-3353535001, flags = 0x0, attribs = 0x0, type = 0x0 [2015/02/27 11:15:47.369810, 18, pid=5701, effective(0, 0), real(0, 0)] ../source3/lib/util_tdb.c:286(tdb_unpack) tdb_unpack(fffddd, 71) -> 71 [2015/02/27 11:15:47.369848, 11, pid=5701, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:4509(unpack_tdc_domains) unpack_tdc_domains: Unpacking domain ADDOMAIN (ADDOMAIN.COM) SID S-1-5-21-1343024091-2000478354-725345543, flags = 0x0, attribs = 0x0, type = 0x0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Feb 27 09:36:02 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Feb 2015 11:36:02 +0200 Subject: [Freeipa-users] Centos 7 - ipa-server-3.3.3 AD trust trust-fetch-domains and add external group problem In-Reply-To: References: <54F02BEB.5070506@redhat.com> <54F02EC6.5090405@redhat.com> <54F0336A.7060409@redhat.com> Message-ID: <20150227093602.GX25455@redhat.com> On Fri, 27 Feb 2015, mete bilgin wrote: >2015-02-27 11:05 GMT+02:00 Martin Kosek : > >> On 02/27/2015 10:01 AM, mete bilgin wrote: >> >>> >>> 2015-02-27 10:45 GMT+02:00 Martin Kosek >> >: >>> >>> On 02/27/2015 09:39 AM, mete bilgin wrote: >>> >>> >>> >>> 2015-02-27 10:33 GMT+02:00 Martin Kosek >> >>> >>: >>> >>> On 02/27/2015 09:30 AM, mete bilgin wrote: >>> >>> Hello, >>> >>> I'm trying to install ipa-server with trust (Win 2008R2). >>> trustdomain-find will >>> work but when i try to trust-fetch-domains "ipa: ERROR: >>> AD domain >>> controller >>> complains about communication sequence. It may mean >>> unsynchronized time >>> on both >>> sides, for example" return. Force to reinstall adtrust. >>> Have >>> any idea >>> where is >>> the problem? >>> >>> >>> You probably done that, but did you indeed verify that the >>> time on >>> both >>> your IPA server and AD are the same? >>> >>> http://www.freeipa.org/page/____Howto/IPAv3_AD_trust_setup#_ >>> ___Date.2Ftime_settings >>> >> Date.2Ftime_settings> >>> >>> >> Date.2Ftime_settings >>> >> Date.2Ftime_settings>> >>> >>> Martin >>> >>> Yes i did that. >>> [root at ipa01 log]# ntpdate -u >>> 27 Feb 10:37:00 ntpdate[11281]: adjust time server 192.168.12.239 >>> offset >>> -0.016979 sec >>> >>> By the way, >>> #wbinfo --online-status >>> >>> BUILTIN : online >>> ipadomain: online >>> addomain : offline >>> >>> >>> Right. Did you also check the actual AD? Especially when AD is in a >>> VM, or >>> of if for example it's time zone is wrong, the UTC time may not match. >>> >>> Martin >>> >>> On AD time zone (UTC+02:00) Istanbul and the same time with ipa server. >>> >>> >> Ok, thanks. It was worth a try. If this is the case, I think you will >> simply need to follow our guide for debugging Trusts and send us the logs: >> >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust >> >> Thanks, >> Martin >> > >Hi, > >I open debug and try to understand but, i can not :( Here the logs. > >Thank a lot. > > >Error_log > >[Fri Feb 27 11:08:48.740996 2015] [:error] [pid 5367] ipa: INFO: >admin at IPDOMAIN.COM: ping(version=u'2.51'): SUCCESS >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 > scavenger: 100 > dns: 100 > ldb: 100 >pm_process() returned Yes >Using binding ncacn_np:ipa01.IPDOMAIN.com[,] >s4_tevent: Added timed event "dcerpc_connect_timeout_handler": >0x7fed9c334520 >s4_tevent: Added timed event "composite_trigger": 0x7fed9c3ec530 >s4_tevent: Added timed event "composite_trigger": 0x7fed9c2f6310 >s4_tevent: Running timer event 0x7fed9c3ec530 "composite_trigger" >s4_tevent: Destroying timer event 0x7fed9c2f6310 "composite_trigger" >Mapped to DCERPC endpoint \pipe\lsarpc >added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 >netmask=255.255.0.0 >added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 >netmask=255.255.255.0 >added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 >netmask=255.255.0.0 >added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 >netmask=255.255.255.0 >s4_tevent: Ending timer event 0x7fed9c3ec530 "composite_trigger" >s4_tevent: Added timed event "connect_multi_timer": 0x7fed9c4cb560 >s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4cb0b0 >s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4cb0b0 >s4_tevent: Destroying timer event 0x7fed9c4cb560 "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 = 663430 > SO_RCVBUF = 261942 > SO_SNDLOWAT = 1 > SO_RCVLOWAT = 1 > SO_SNDTIMEO = 0 > SO_RCVTIMEO = 0 > TCP_QUICKACK = 1 > TCP_DEFER_ACCEPT = 0 >s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4caa80 >s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >0x7fed9c4cb560 >s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >0x7fed9c4cb560 >s4_tevent: Destroying timer event 0x7fed9c4caa80 "tevent_req_timedout" >Starting GENSEC mechanism spnego >Starting GENSEC submechanism gssapi_krb5 >Ticket in credentials cache for @IPDOMAIN will expire in 80256 secs >s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d0960 >s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >0x7fed9c4cb560 >s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >0x7fed9c4cb560 >s4_tevent: Destroying timer event 0x7fed9c4d0960 "tevent_req_timedout" >gensec_gssapi: NO credentials were delegated >GSSAPI Connection will be cryptographically sealed >s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d0360 >s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >0x7fed9c4cb560 >s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >0x7fed9c4cb560 >s4_tevent: Destroying timer event 0x7fed9c4d0360 "tevent_req_timedout" >s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4cf550 >s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >0x7fed9c4cb560 >s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >0x7fed9c4cb560 >s4_tevent: Destroying timer event 0x7fed9c4cf550 "tevent_req_timedout" >num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, >data_total=72, this_data=72, max_data=65535, param_offset=84, param_pad=2, >param_disp=0, data_offset=84, data_pad=0, data_disp=0 >s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d9a30 >s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >0x7fed9c4cb560 >s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4d9df0 >s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >0x7fed9c4cb560 >s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d9640 >s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d9640 >s4_tevent: Destroying timer event 0x7fed9c4d9a30 "tevent_req_timedout" >s4_tevent: Destroying timer event 0x7fed9c4d9df0 "dcerpc_timeout_handler" >s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c3ec8a0 >s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c3ec8a0 >s4_tevent: Destroying timer event 0x7fed9c334520 >"dcerpc_connect_timeout_handler" > lsa_OpenPolicy2: struct lsa_OpenPolicy2 > in: struct lsa_OpenPolicy2 > system_name : * > system_name : '' > attr : * > attr: struct lsa_ObjectAttribute > len : 0x00000000 (0) > root_dir : NULL > object_name : NULL > attributes : 0x00000000 (0) > sec_desc : NULL > sec_qos : * > sec_qos: struct lsa_QosInfo > len : 0x00000000 (0) > impersonation_level : 0x0000 (0) > context_mode : 0x00 (0) > effective_only : 0x00 (0) > access_mask : 0x02000000 (33554432) > 0: LSA_POLICY_VIEW_LOCAL_INFORMATION > 0: LSA_POLICY_VIEW_AUDIT_INFORMATION > 0: LSA_POLICY_GET_PRIVATE_INFORMATION > 0: LSA_POLICY_TRUST_ADMIN > 0: LSA_POLICY_CREATE_ACCOUNT > 0: LSA_POLICY_CREATE_SECRET > 0: LSA_POLICY_CREATE_PRIVILEGE > 0: LSA_POLICY_SET_DEFAULT_QUOTA_LIMITS > 0: LSA_POLICY_SET_AUDIT_REQUIREMENTS > 0: LSA_POLICY_AUDIT_LOG_ADMIN > 0: LSA_POLICY_SERVER_ADMIN > 0: LSA_POLICY_LOOKUP_NAMES > 0: LSA_POLICY_NOTIFICATION >rpc request data: >[0000] 00 00 02 00 01 00 00 00 00 00 00 00 01 00 00 00 ........ ........ >[0010] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ >[0020] 00 00 00 00 00 00 00 00 04 00 02 00 00 00 00 00 ........ ........ >[0030] 00 00 00 00 00 00 00 02 ........ >s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4d0be0 >s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, >data_total=80, this_data=80, max_data=4280, param_offset=84, param_pad=2, >param_disp=0, data_offset=84, data_pad=0, data_disp=0 >s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d9d00 >s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >0x7fed9c4cb560 >s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >0x7fed9c4cb560 >s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d9910 >s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d9910 >s4_tevent: Destroying timer event 0x7fed9c4d9d00 "tevent_req_timedout" >s4_tevent: Destroying timer event 0x7fed9c4d0be0 "dcerpc_timeout_handler" >s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c3ec8a0 >s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c3ec8a0 > lsa_OpenPolicy2: struct lsa_OpenPolicy2 > out: struct lsa_OpenPolicy2 > handle : * > handle: struct policy_handle > handle_type : 0x00000000 (0) > uuid : >00000014-0000-0000-f054-20348a2a0000 > result : NT_STATUS_OK >rpc reply data: >[0000] 00 00 00 00 14 00 00 00 00 00 00 00 F0 54 20 34 ........ .....T 4 >[0010] 8A 2A 00 00 00 00 00 00 .*...... > lsa_QueryInfoPolicy2: struct lsa_QueryInfoPolicy2 > in: struct lsa_QueryInfoPolicy2 > handle : * > handle: struct policy_handle > handle_type : 0x00000000 (0) > uuid : >00000014-0000-0000-f054-20348a2a0000 > level : LSA_POLICY_INFO_DNS (12) >rpc request data: >[0000] 00 00 00 00 14 00 00 00 00 00 00 00 F0 54 20 34 ........ .....T 4 >[0010] 8A 2A 00 00 0C 00 .*.... >s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c3ec350 >s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, >data_total=46, this_data=46, max_data=4280, param_offset=84, param_pad=2, >param_disp=0, data_offset=84, data_pad=0, data_disp=0 >s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d9ec0 >s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >0x7fed9c4cb560 >s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >0x7fed9c4cb560 >s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d9af0 >s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d9af0 >s4_tevent: Destroying timer event 0x7fed9c4d9ec0 "tevent_req_timedout" >s4_tevent: Destroying timer event 0x7fed9c3ec350 "dcerpc_timeout_handler" >s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d0ad0 >s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d0ad0 > lsa_QueryInfoPolicy2: struct lsa_QueryInfoPolicy2 > out: struct lsa_QueryInfoPolicy2 > info : * > info : * > info : union >lsa_PolicyInformation(case 12) > dns: struct lsa_DnsDomainInfo > name: struct lsa_StringLarge > length : 0x0010 (16) > size : 0x0012 (18) > string : * > string : 'IPDOMAIN' > dns_domain: struct lsa_StringLarge > length : 0x0018 (24) > size : 0x001a (26) > string : * > string : 'IPDOMAIN.com' > dns_forest: struct lsa_StringLarge > length : 0x0018 (24) > size : 0x001a (26) > string : * > string : 'IPDOMAIN.com' > domain_guid : >00000015-e851-c207-0dd0-a20419e2e2c7 > sid : * > sid : >S-1-5-21-3255298129-77778957-3353535001 > result : NT_STATUS_OK >rpc reply data: >[0000] 00 00 02 00 0C 00 00 00 10 00 12 00 04 00 02 00 ........ ........ >[0010] 18 00 1A 00 08 00 02 00 18 00 1A 00 0C 00 02 00 ........ ........ >[0020] 15 00 00 00 51 E8 07 C2 0D D0 A2 04 19 E2 E2 C7 ....Q... ........ >[0030] 10 00 02 00 09 00 00 00 00 00 00 00 08 00 00 00 ........ ........ >[0040] 42 00 49 00 4C 00 59 00 4F 00 4E 00 45 00 52 00 B.I.L.Y. O.N.E.R. >[0050] 0D 00 00 00 00 00 00 00 0C 00 00 00 62 00 69 00 ........ ....b.i. >[0060] 6C 00 79 00 6F 00 6E 00 65 00 72 00 2E 00 63 00 l.y.o.n. e.r...c. >[0070] 6F 00 6D 00 0D 00 00 00 00 00 00 00 0C 00 00 00 o.m..... ........ >[0080] 62 00 69 00 6C 00 79 00 6F 00 6E 00 65 00 72 00 b.i.l.y. o.n.e.r. >[0090] 2E 00 63 00 6F 00 6D 00 04 00 00 00 01 04 00 00 ..c.o.m. ........ >[00A0] 00 00 00 05 15 00 00 00 51 E8 07 C2 0D D0 A2 04 ........ Q....... >[00B0] 19 E2 E2 C7 00 00 00 00 ........ > lsa_QueryInfoPolicy2: struct lsa_QueryInfoPolicy2 > in: struct lsa_QueryInfoPolicy2 > handle : * > handle: struct policy_handle > handle_type : 0x00000000 (0) > uuid : >00000014-0000-0000-f054-20348a2a0000 > level : LSA_POLICY_INFO_ROLE (6) >rpc request data: >[0000] 00 00 00 00 14 00 00 00 00 00 00 00 F0 54 20 34 ........ .....T 4 >[0010] 8A 2A 00 00 06 00 .*.... >s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4d0f90 >s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, >data_total=46, this_data=46, max_data=4280, param_offset=84, param_pad=2, >param_disp=0, data_offset=84, data_pad=0, data_disp=0 >s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4da450 >s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >0x7fed9c4cb560 >s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >0x7fed9c4cb560 >s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d9fe0 >s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d9fe0 >s4_tevent: Destroying timer event 0x7fed9c4da450 "tevent_req_timedout" >s4_tevent: Destroying timer event 0x7fed9c4d0f90 "dcerpc_timeout_handler" >s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c3ec3e0 >s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c3ec3e0 > lsa_QueryInfoPolicy2: struct lsa_QueryInfoPolicy2 > out: struct lsa_QueryInfoPolicy2 > info : * > info : * > info : union >lsa_PolicyInformation(case 6) > role: struct lsa_ServerRole > role : LSA_ROLE_PRIMARY (3) > result : NT_STATUS_OK >rpc reply data: >[0000] 00 00 02 00 06 00 00 00 03 00 00 00 00 00 00 00 ........ ........ >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 > scavenger: 100 > dns: 100 > ldb: 100 >pm_process() returned Yes >added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 >netmask=255.255.0.0 >added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 >netmask=255.255.255.0 >added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 >netmask=255.255.0.0 >added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 >netmask=255.255.255.0 >added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 >netmask=255.255.0.0 >added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 >netmask=255.255.255.0 >added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 >netmask=255.255.0.0 >added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 >netmask=255.255.255.0 >finddcs: searching for a DC by DNS domain addomain.com >finddcs: looking for SRV records for _ldap._tcp.addomain.com >ads_dns_lookup_srv: 3 records returned in the answer section. >ads_dns_parse_rr_srv: Parsed ad.addomain.com [0, 100, 389] >ads_dns_parse_rr_srv: Parsed kratos.addomain.com [0, 100, 389] >ads_dns_parse_rr_srv: Parsed beatrice.addomain.com [0, 100, 389] >Addrs = 192.168.12.236 at 389/ad,172.16.50.70 at 389/kratos,192.168.12.239 at 389 >/beatrice >finddcs: DNS SRV response 0 at '192.168.12.236' >finddcs: DNS SRV response 1 at '172.16.50.70' >finddcs: DNS SRV response 2 at '192.168.12.239' >finddcs: performing CLDAP query on 192.168.12.236 >s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d6230 >s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d66e0 >s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d66e0 >s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d69b0 >s4_tevent: Destroying timer event 0x7fed9c4d69b0 "tevent_req_timedout" >s4_tevent: Destroying timer event 0x7fed9c4d6230 "tevent_req_timedout" > &response->data.nt5_ex: struct NETLOGON_SAM_LOGON_RESPONSE_EX > command : LOGON_SAM_LOGON_RESPONSE_EX (23) > sbz : 0x0000 (0) > server_type : 0x000031fd (12797) > 1: NBT_SERVER_PDC > 1: NBT_SERVER_GC > 1: NBT_SERVER_LDAP > 1: NBT_SERVER_DS > 1: NBT_SERVER_KDC > 1: NBT_SERVER_TIMESERV > 1: NBT_SERVER_CLOSEST > 1: NBT_SERVER_WRITABLE > 0: NBT_SERVER_GOOD_TIMESERV > 0: NBT_SERVER_NDNC > 0: NBT_SERVER_SELECT_SECRET_DOMAIN_6 > 1: NBT_SERVER_FULL_SECRET_DOMAIN_6 > 1: NBT_SERVER_ADS_WEB_SERVICE > 0: NBT_SERVER_HAS_DNS_NAME > 0: NBT_SERVER_IS_DEFAULT_NC > 0: NBT_SERVER_FOREST_ROOT > domain_uuid : 6aac190b-04eb-464f-bdcc-b07e27e2d1e5 > forest : 'addomain.com' > dns_domain : 'addomain.com' > pdc_dns_name : 'ad.addomain.com' > domain_name : 'LIBERO' > pdc_name : 'ad' > user_name : '' > server_site : 'Default-First-Site-Name' > client_site : 'Default-First-Site-Name' > sockaddr_size : 0x00 (0) > sockaddr: struct nbt_sockaddr > sockaddr_family : 0x00000000 (0) > pdc_ip : (null) > remaining : DATA_BLOB length=0 > next_closest_site : NULL > nt_version : 0x00000005 (5) > 1: NETLOGON_NT_VERSION_1 > 0: NETLOGON_NT_VERSION_5 > 1: NETLOGON_NT_VERSION_5EX > 0: NETLOGON_NT_VERSION_5EX_WITH_IP > 0: NETLOGON_NT_VERSION_WITH_CLOSEST_SITE > 0: NETLOGON_NT_VERSION_AVOID_NT4EMUL > 0: NETLOGON_NT_VERSION_PDC > 0: NETLOGON_NT_VERSION_IP > 0: NETLOGON_NT_VERSION_LOCAL > 0: NETLOGON_NT_VERSION_GC > lmnt_token : 0xffff (65535) > lm20_token : 0xffff (65535) >finddcs: Found matching DC 192.168.12.236 with server_type=0x000031fd >Using binding ncacn_np:ad.addomain.com[,] >s4_tevent: Added timed event "dcerpc_connect_timeout_handler": >0x7fed9c4d4b90 >s4_tevent: Added timed event "composite_trigger": 0x7fed9c4d5180 >s4_tevent: Added timed event "composite_trigger": 0x7fed9c4d54b0 >s4_tevent: Running timer event 0x7fed9c4d5180 "composite_trigger" >s4_tevent: Destroying timer event 0x7fed9c4d54b0 "composite_trigger" >Mapped to DCERPC endpoint \pipe\lsarpc >added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 >netmask=255.255.0.0 >added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 >netmask=255.255.255.0 >added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 >netmask=255.255.0.0 >added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 >netmask=255.255.255.0 >s4_tevent: Ending timer event 0x7fed9c4d5180 "composite_trigger" >s4_tevent: Added timed event "connect_multi_timer": 0x7fed9c4d8b90 >s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d5180 >s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d5180 >s4_tevent: Destroying timer event 0x7fed9c4d8b90 "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 = 23080 > SO_RCVBUF = 87380 > SO_SNDLOWAT = 1 > SO_RCVLOWAT = 1 > SO_SNDTIMEO = 0 > SO_RCVTIMEO = 0 > TCP_QUICKACK = 1 > TCP_DEFER_ACCEPT = 0 >s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4dbfe0 >s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >0x7fed9c4d8b90 >s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >0x7fed9c4d8b90 >s4_tevent: Destroying timer event 0x7fed9c4dbfe0 "tevent_req_timedout" >Starting GENSEC mechanism spnego >Starting GENSEC submechanism gssapi_krb5 >Ticket in credentials cache for @IPDOMAIN will expire in 86400 secs >GSS client Update(krb5)(1) Update failed: Unspecified GSS failure. Minor >code may provide more information: KDC policy rejects request This means your trust is not working. How did you established trust? Show exact commands. "KDC policy rejects request" means AD DC was unable to complete trust validation. Usually it means it was unable to talk back to IPA master which it discovers via SRV records over DNS. -- / Alexander Bokovoy From metebilgin48 at gmail.com Fri Feb 27 09:44:47 2015 From: metebilgin48 at gmail.com (mete bilgin) Date: Fri, 27 Feb 2015 11:44:47 +0200 Subject: [Freeipa-users] Centos 7 - ipa-server-3.3.3 AD trust trust-fetch-domains and add external group problem In-Reply-To: <20150227093602.GX25455@redhat.com> References: <54F02BEB.5070506@redhat.com> <54F02EC6.5090405@redhat.com> <54F0336A.7060409@redhat.com> <20150227093602.GX25455@redhat.com> Message-ID: 2015-02-27 11:36 GMT+02:00 Alexander Bokovoy : > On Fri, 27 Feb 2015, mete bilgin wrote: > >> 2015-02-27 11:05 GMT+02:00 Martin Kosek : >> >> On 02/27/2015 10:01 AM, mete bilgin wrote: >>> >>> >>>> 2015-02-27 10:45 GMT+02:00 Martin Kosek >>> >: >>>> >>>> On 02/27/2015 09:39 AM, mete bilgin wrote: >>>> >>>> >>>> >>>> 2015-02-27 10:33 GMT+02:00 Martin Kosek >>> >>>> >>: >>>> >>>> On 02/27/2015 09:30 AM, mete bilgin wrote: >>>> >>>> Hello, >>>> >>>> I'm trying to install ipa-server with trust (Win >>>> 2008R2). >>>> trustdomain-find will >>>> work but when i try to trust-fetch-domains "ipa: ERROR: >>>> AD domain >>>> controller >>>> complains about communication sequence. It may mean >>>> unsynchronized time >>>> on both >>>> sides, for example" return. Force to reinstall adtrust. >>>> Have >>>> any idea >>>> where is >>>> the problem? >>>> >>>> >>>> You probably done that, but did you indeed verify that the >>>> time on >>>> both >>>> your IPA server and AD are the same? >>>> >>>> http://www.freeipa.org/page/____Howto/IPAv3_AD_trust_setup#_ >>>> ___Date.2Ftime_settings >>>> >>> Date.2Ftime_settings> >>>> >>>> >>> Date.2Ftime_settings >>>> >>> Date.2Ftime_settings>> >>>> >>>> Martin >>>> >>>> Yes i did that. >>>> [root at ipa01 log]# ntpdate -u >>>> 27 Feb 10:37:00 ntpdate[11281]: adjust time server >>>> 192.168.12.239 >>>> offset >>>> -0.016979 sec >>>> >>>> By the way, >>>> #wbinfo --online-status >>>> >>>> BUILTIN : online >>>> ipadomain: online >>>> addomain : offline >>>> >>>> >>>> Right. Did you also check the actual AD? Especially when AD is in a >>>> VM, or >>>> of if for example it's time zone is wrong, the UTC time may not >>>> match. >>>> >>>> Martin >>>> >>>> On AD time zone (UTC+02:00) Istanbul and the same time with ipa server. >>>> >>>> >>>> Ok, thanks. It was worth a try. If this is the case, I think you will >>> simply need to follow our guide for debugging Trusts and send us the >>> logs: >>> >>> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust >>> >>> Thanks, >>> Martin >>> >>> >> Hi, >> >> I open debug and try to understand but, i can not :( Here the logs. >> >> Thank a lot. >> >> >> Error_log >> >> [Fri Feb 27 11:08:48.740996 2015] [:error] [pid 5367] ipa: INFO: >> admin at IPDOMAIN.COM: ping(version=u'2.51'): SUCCESS >> 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 >> scavenger: 100 >> dns: 100 >> ldb: 100 >> pm_process() returned Yes >> Using binding ncacn_np:ipa01.IPDOMAIN.com[,] >> s4_tevent: Added timed event "dcerpc_connect_timeout_handler": >> 0x7fed9c334520 >> s4_tevent: Added timed event "composite_trigger": 0x7fed9c3ec530 >> s4_tevent: Added timed event "composite_trigger": 0x7fed9c2f6310 >> s4_tevent: Running timer event 0x7fed9c3ec530 "composite_trigger" >> s4_tevent: Destroying timer event 0x7fed9c2f6310 "composite_trigger" >> Mapped to DCERPC endpoint \pipe\lsarpc >> added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 >> netmask=255.255.0.0 >> added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 >> netmask=255.255.255.0 >> added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 >> netmask=255.255.0.0 >> added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 >> netmask=255.255.255.0 >> s4_tevent: Ending timer event 0x7fed9c3ec530 "composite_trigger" >> s4_tevent: Added timed event "connect_multi_timer": 0x7fed9c4cb560 >> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4cb0b0 >> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4cb0b0 >> s4_tevent: Destroying timer event 0x7fed9c4cb560 "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 = 663430 >> SO_RCVBUF = 261942 >> SO_SNDLOWAT = 1 >> SO_RCVLOWAT = 1 >> SO_SNDTIMEO = 0 >> SO_RCVTIMEO = 0 >> TCP_QUICKACK = 1 >> TCP_DEFER_ACCEPT = 0 >> s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4caa80 >> s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4cb560 >> s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4cb560 >> s4_tevent: Destroying timer event 0x7fed9c4caa80 "tevent_req_timedout" >> Starting GENSEC mechanism spnego >> Starting GENSEC submechanism gssapi_krb5 >> Ticket in credentials cache for @IPDOMAIN will expire in 80256 secs >> s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d0960 >> s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4cb560 >> s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4cb560 >> s4_tevent: Destroying timer event 0x7fed9c4d0960 "tevent_req_timedout" >> gensec_gssapi: NO credentials were delegated >> GSSAPI Connection will be cryptographically sealed >> s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d0360 >> s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4cb560 >> s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4cb560 >> s4_tevent: Destroying timer event 0x7fed9c4d0360 "tevent_req_timedout" >> s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4cf550 >> s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4cb560 >> s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4cb560 >> s4_tevent: Destroying timer event 0x7fed9c4cf550 "tevent_req_timedout" >> num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, >> data_total=72, this_data=72, max_data=65535, param_offset=84, param_pad=2, >> param_disp=0, data_offset=84, data_pad=0, data_disp=0 >> s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d9a30 >> s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4cb560 >> s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4d9df0 >> s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4cb560 >> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d9640 >> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d9640 >> s4_tevent: Destroying timer event 0x7fed9c4d9a30 "tevent_req_timedout" >> s4_tevent: Destroying timer event 0x7fed9c4d9df0 "dcerpc_timeout_handler" >> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c3ec8a0 >> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c3ec8a0 >> s4_tevent: Destroying timer event 0x7fed9c334520 >> "dcerpc_connect_timeout_handler" >> lsa_OpenPolicy2: struct lsa_OpenPolicy2 >> in: struct lsa_OpenPolicy2 >> system_name : * >> system_name : '' >> attr : * >> attr: struct lsa_ObjectAttribute >> len : 0x00000000 (0) >> root_dir : NULL >> object_name : NULL >> attributes : 0x00000000 (0) >> sec_desc : NULL >> sec_qos : * >> sec_qos: struct lsa_QosInfo >> len : 0x00000000 (0) >> impersonation_level : 0x0000 (0) >> context_mode : 0x00 (0) >> effective_only : 0x00 (0) >> access_mask : 0x02000000 (33554432) >> 0: LSA_POLICY_VIEW_LOCAL_INFORMATION >> 0: LSA_POLICY_VIEW_AUDIT_INFORMATION >> 0: LSA_POLICY_GET_PRIVATE_INFORMATION >> 0: LSA_POLICY_TRUST_ADMIN >> 0: LSA_POLICY_CREATE_ACCOUNT >> 0: LSA_POLICY_CREATE_SECRET >> 0: LSA_POLICY_CREATE_PRIVILEGE >> 0: LSA_POLICY_SET_DEFAULT_QUOTA_LIMITS >> 0: LSA_POLICY_SET_AUDIT_REQUIREMENTS >> 0: LSA_POLICY_AUDIT_LOG_ADMIN >> 0: LSA_POLICY_SERVER_ADMIN >> 0: LSA_POLICY_LOOKUP_NAMES >> 0: LSA_POLICY_NOTIFICATION >> rpc request data: >> [0000] 00 00 02 00 01 00 00 00 00 00 00 00 01 00 00 00 ........ >> ........ >> [0010] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ >> ........ >> [0020] 00 00 00 00 00 00 00 00 04 00 02 00 00 00 00 00 ........ >> ........ >> [0030] 00 00 00 00 00 00 00 02 ........ >> s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >> s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4d0be0 >> s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >> s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >> num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, >> data_total=80, this_data=80, max_data=4280, param_offset=84, param_pad=2, >> param_disp=0, data_offset=84, data_pad=0, data_disp=0 >> s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d9d00 >> s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4cb560 >> s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >> s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4cb560 >> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d9910 >> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d9910 >> s4_tevent: Destroying timer event 0x7fed9c4d9d00 "tevent_req_timedout" >> s4_tevent: Destroying timer event 0x7fed9c4d0be0 "dcerpc_timeout_handler" >> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c3ec8a0 >> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c3ec8a0 >> lsa_OpenPolicy2: struct lsa_OpenPolicy2 >> out: struct lsa_OpenPolicy2 >> handle : * >> handle: struct policy_handle >> handle_type : 0x00000000 (0) >> uuid : >> 00000014-0000-0000-f054-20348a2a0000 >> result : NT_STATUS_OK >> rpc reply data: >> [0000] 00 00 00 00 14 00 00 00 00 00 00 00 F0 54 20 34 ........ >> .....T 4 >> [0010] 8A 2A 00 00 00 00 00 00 .*...... >> lsa_QueryInfoPolicy2: struct lsa_QueryInfoPolicy2 >> in: struct lsa_QueryInfoPolicy2 >> handle : * >> handle: struct policy_handle >> handle_type : 0x00000000 (0) >> uuid : >> 00000014-0000-0000-f054-20348a2a0000 >> level : LSA_POLICY_INFO_DNS (12) >> rpc request data: >> [0000] 00 00 00 00 14 00 00 00 00 00 00 00 F0 54 20 34 ........ >> .....T 4 >> [0010] 8A 2A 00 00 0C 00 .*.... >> s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >> s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c3ec350 >> s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >> s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >> num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, >> data_total=46, this_data=46, max_data=4280, param_offset=84, param_pad=2, >> param_disp=0, data_offset=84, data_pad=0, data_disp=0 >> s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d9ec0 >> s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4cb560 >> s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >> s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4cb560 >> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d9af0 >> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d9af0 >> s4_tevent: Destroying timer event 0x7fed9c4d9ec0 "tevent_req_timedout" >> s4_tevent: Destroying timer event 0x7fed9c3ec350 "dcerpc_timeout_handler" >> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d0ad0 >> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d0ad0 >> lsa_QueryInfoPolicy2: struct lsa_QueryInfoPolicy2 >> out: struct lsa_QueryInfoPolicy2 >> info : * >> info : * >> info : union >> lsa_PolicyInformation(case 12) >> dns: struct lsa_DnsDomainInfo >> name: struct lsa_StringLarge >> length : 0x0010 (16) >> size : 0x0012 (18) >> string : * >> string : 'IPDOMAIN' >> dns_domain: struct lsa_StringLarge >> length : 0x0018 (24) >> size : 0x001a (26) >> string : * >> string : 'IPDOMAIN.com' >> dns_forest: struct lsa_StringLarge >> length : 0x0018 (24) >> size : 0x001a (26) >> string : * >> string : 'IPDOMAIN.com' >> domain_guid : >> 00000015-e851-c207-0dd0-a20419e2e2c7 >> sid : * >> sid : >> S-1-5-21-3255298129-77778957-3353535001 >> result : NT_STATUS_OK >> rpc reply data: >> [0000] 00 00 02 00 0C 00 00 00 10 00 12 00 04 00 02 00 ........ >> ........ >> [0010] 18 00 1A 00 08 00 02 00 18 00 1A 00 0C 00 02 00 ........ >> ........ >> [0020] 15 00 00 00 51 E8 07 C2 0D D0 A2 04 19 E2 E2 C7 ....Q... >> ........ >> [0030] 10 00 02 00 09 00 00 00 00 00 00 00 08 00 00 00 ........ >> ........ >> [0040] 42 00 49 00 4C 00 59 00 4F 00 4E 00 45 00 52 00 B.I.L.Y. >> O.N.E.R. >> [0050] 0D 00 00 00 00 00 00 00 0C 00 00 00 62 00 69 00 ........ >> ....b.i. >> [0060] 6C 00 79 00 6F 00 6E 00 65 00 72 00 2E 00 63 00 l.y.o.n. >> e.r...c. >> [0070] 6F 00 6D 00 0D 00 00 00 00 00 00 00 0C 00 00 00 o.m..... >> ........ >> [0080] 62 00 69 00 6C 00 79 00 6F 00 6E 00 65 00 72 00 b.i.l.y. >> o.n.e.r. >> [0090] 2E 00 63 00 6F 00 6D 00 04 00 00 00 01 04 00 00 ..c.o.m. >> ........ >> [00A0] 00 00 00 05 15 00 00 00 51 E8 07 C2 0D D0 A2 04 ........ >> Q....... >> [00B0] 19 E2 E2 C7 00 00 00 00 ........ >> lsa_QueryInfoPolicy2: struct lsa_QueryInfoPolicy2 >> in: struct lsa_QueryInfoPolicy2 >> handle : * >> handle: struct policy_handle >> handle_type : 0x00000000 (0) >> uuid : >> 00000014-0000-0000-f054-20348a2a0000 >> level : LSA_POLICY_INFO_ROLE (6) >> rpc request data: >> [0000] 00 00 00 00 14 00 00 00 00 00 00 00 F0 54 20 34 ........ >> .....T 4 >> [0010] 8A 2A 00 00 06 00 .*.... >> s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >> s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4d0f90 >> s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >> s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >> num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, >> data_total=46, this_data=46, max_data=4280, param_offset=84, param_pad=2, >> param_disp=0, data_offset=84, data_pad=0, data_disp=0 >> s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4da450 >> s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4cb560 >> s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c2f22c0 >> s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4cb560 >> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d9fe0 >> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d9fe0 >> s4_tevent: Destroying timer event 0x7fed9c4da450 "tevent_req_timedout" >> s4_tevent: Destroying timer event 0x7fed9c4d0f90 "dcerpc_timeout_handler" >> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c3ec3e0 >> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c3ec3e0 >> lsa_QueryInfoPolicy2: struct lsa_QueryInfoPolicy2 >> out: struct lsa_QueryInfoPolicy2 >> info : * >> info : * >> info : union >> lsa_PolicyInformation(case 6) >> role: struct lsa_ServerRole >> role : LSA_ROLE_PRIMARY (3) >> result : NT_STATUS_OK >> rpc reply data: >> [0000] 00 00 02 00 06 00 00 00 03 00 00 00 00 00 00 00 ........ >> ........ >> 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 >> scavenger: 100 >> dns: 100 >> ldb: 100 >> pm_process() returned Yes >> added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 >> netmask=255.255.0.0 >> added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 >> netmask=255.255.255.0 >> added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 >> netmask=255.255.0.0 >> added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 >> netmask=255.255.255.0 >> added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 >> netmask=255.255.0.0 >> added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 >> netmask=255.255.255.0 >> added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 >> netmask=255.255.0.0 >> added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 >> netmask=255.255.255.0 >> finddcs: searching for a DC by DNS domain addomain.com >> finddcs: looking for SRV records for _ldap._tcp.addomain.com >> ads_dns_lookup_srv: 3 records returned in the answer section. >> ads_dns_parse_rr_srv: Parsed ad.addomain.com [0, 100, 389] >> ads_dns_parse_rr_srv: Parsed kratos.addomain.com [0, 100, 389] >> ads_dns_parse_rr_srv: Parsed beatrice.addomain.com [0, 100, 389] >> Addrs = 192.168.12.236 at 389/ad,172.16.50.70 at 389/kratos,192.168.12.239 at 389 >> /beatrice >> finddcs: DNS SRV response 0 at '192.168.12.236' >> finddcs: DNS SRV response 1 at '172.16.50.70' >> finddcs: DNS SRV response 2 at '192.168.12.239' >> finddcs: performing CLDAP query on 192.168.12.236 >> s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d6230 >> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d66e0 >> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d66e0 >> s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d69b0 >> s4_tevent: Destroying timer event 0x7fed9c4d69b0 "tevent_req_timedout" >> s4_tevent: Destroying timer event 0x7fed9c4d6230 "tevent_req_timedout" >> &response->data.nt5_ex: struct NETLOGON_SAM_LOGON_RESPONSE_EX >> command : LOGON_SAM_LOGON_RESPONSE_EX (23) >> sbz : 0x0000 (0) >> server_type : 0x000031fd (12797) >> 1: NBT_SERVER_PDC >> 1: NBT_SERVER_GC >> 1: NBT_SERVER_LDAP >> 1: NBT_SERVER_DS >> 1: NBT_SERVER_KDC >> 1: NBT_SERVER_TIMESERV >> 1: NBT_SERVER_CLOSEST >> 1: NBT_SERVER_WRITABLE >> 0: NBT_SERVER_GOOD_TIMESERV >> 0: NBT_SERVER_NDNC >> 0: NBT_SERVER_SELECT_SECRET_DOMAIN_6 >> 1: NBT_SERVER_FULL_SECRET_DOMAIN_6 >> 1: NBT_SERVER_ADS_WEB_SERVICE >> 0: NBT_SERVER_HAS_DNS_NAME >> 0: NBT_SERVER_IS_DEFAULT_NC >> 0: NBT_SERVER_FOREST_ROOT >> domain_uuid : 6aac190b-04eb-464f-bdcc-b07e27e2d1e5 >> forest : 'addomain.com' >> dns_domain : 'addomain.com' >> pdc_dns_name : 'ad.addomain.com' >> domain_name : 'LIBERO' >> pdc_name : 'ad' >> user_name : '' >> server_site : 'Default-First-Site-Name' >> client_site : 'Default-First-Site-Name' >> sockaddr_size : 0x00 (0) >> sockaddr: struct nbt_sockaddr >> sockaddr_family : 0x00000000 (0) >> pdc_ip : (null) >> remaining : DATA_BLOB length=0 >> next_closest_site : NULL >> nt_version : 0x00000005 (5) >> 1: NETLOGON_NT_VERSION_1 >> 0: NETLOGON_NT_VERSION_5 >> 1: NETLOGON_NT_VERSION_5EX >> 0: NETLOGON_NT_VERSION_5EX_WITH_IP >> 0: NETLOGON_NT_VERSION_WITH_CLOSEST_SITE >> 0: NETLOGON_NT_VERSION_AVOID_NT4EMUL >> 0: NETLOGON_NT_VERSION_PDC >> 0: NETLOGON_NT_VERSION_IP >> 0: NETLOGON_NT_VERSION_LOCAL >> 0: NETLOGON_NT_VERSION_GC >> lmnt_token : 0xffff (65535) >> lm20_token : 0xffff (65535) >> finddcs: Found matching DC 192.168.12.236 with server_type=0x000031fd >> Using binding ncacn_np:ad.addomain.com[,] >> s4_tevent: Added timed event "dcerpc_connect_timeout_handler": >> 0x7fed9c4d4b90 >> s4_tevent: Added timed event "composite_trigger": 0x7fed9c4d5180 >> s4_tevent: Added timed event "composite_trigger": 0x7fed9c4d54b0 >> s4_tevent: Running timer event 0x7fed9c4d5180 "composite_trigger" >> s4_tevent: Destroying timer event 0x7fed9c4d54b0 "composite_trigger" >> Mapped to DCERPC endpoint \pipe\lsarpc >> added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 >> netmask=255.255.0.0 >> added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 >> netmask=255.255.255.0 >> added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 >> netmask=255.255.0.0 >> added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 >> netmask=255.255.255.0 >> s4_tevent: Ending timer event 0x7fed9c4d5180 "composite_trigger" >> s4_tevent: Added timed event "connect_multi_timer": 0x7fed9c4d8b90 >> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d5180 >> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d5180 >> s4_tevent: Destroying timer event 0x7fed9c4d8b90 "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 = 23080 >> SO_RCVBUF = 87380 >> SO_SNDLOWAT = 1 >> SO_RCVLOWAT = 1 >> SO_SNDTIMEO = 0 >> SO_RCVTIMEO = 0 >> TCP_QUICKACK = 1 >> TCP_DEFER_ACCEPT = 0 >> s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4dbfe0 >> s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4d8b90 >> s4_tevent: Run immediate event "tevent_queue_immediate_trigger": >> 0x7fed9c4d8b90 >> s4_tevent: Destroying timer event 0x7fed9c4dbfe0 "tevent_req_timedout" >> Starting GENSEC mechanism spnego >> Starting GENSEC submechanism gssapi_krb5 >> Ticket in credentials cache for @IPDOMAIN will expire in 86400 secs >> GSS client Update(krb5)(1) Update failed: Unspecified GSS failure. Minor >> code may provide more information: KDC policy rejects request >> > This means your trust is not working. How did you established trust? > Show exact commands. > > "KDC policy rejects request" means AD DC was unable to complete trust > validation. Usually it means it was unable to talk back to IPA master > which it discovers via SRV records over DNS. > -- > / Alexander Bokovoy > Hi, When i add the turs return this. [root at ipa01 ~]# ipa trust-add --type=ad --admin admin --password Realm name: addomain.com Active directory domain administrator's password: ------------------------------------------- Re-established trust to domain "ADDOMAIN.COM" ------------------------------------------- Realm name: ADDOMAIN.COM Domain NetBIOS name: ADDOMAIN Domain Security Identifier: S-1-5-21-1343024091-2000478354-725345543 SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Feb 27 09:53:29 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Feb 2015 11:53:29 +0200 Subject: [Freeipa-users] Centos 7 - ipa-server-3.3.3 AD trust trust-fetch-domains and add external group problem In-Reply-To: References: <54F02BEB.5070506@redhat.com> <54F02EC6.5090405@redhat.com> <54F0336A.7060409@redhat.com> <20150227093602.GX25455@redhat.com> Message-ID: <20150227095329.GZ25455@redhat.com> On Fri, 27 Feb 2015, mete bilgin wrote: >>> Starting GENSEC mechanism spnego >>> Starting GENSEC submechanism gssapi_krb5 >>> Ticket in credentials cache for @IPDOMAIN will expire in 86400 secs >>> GSS client Update(krb5)(1) Update failed: Unspecified GSS failure. Minor >>> code may provide more information: KDC policy rejects request >>> >> This means your trust is not working. How did you established trust? >> Show exact commands. >> >> "KDC policy rejects request" means AD DC was unable to complete trust >> validation. Usually it means it was unable to talk back to IPA master >> which it discovers via SRV records over DNS. >> -- >> / Alexander Bokovoy >> > > >Hi, > >When i add the turs return this. > >[root at ipa01 ~]# ipa trust-add --type=ad --admin admin --password >Realm name: addomain.com >Active directory domain administrator's password: >------------------------------------------- >Re-established trust to domain "ADDOMAIN.COM" >------------------------------------------- > Realm name: ADDOMAIN.COM > Domain NetBIOS name: ADDOMAIN > Domain Security Identifier: S-1-5-21-1343024091-2000478354-725345543 > SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, >S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, >S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, > S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 > SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, >S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, >S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, > S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 > Trust direction: Two-way trust > Trust type: Active Directory domain > Trust status: Established and verified Ok, and did you run that with debug enabled in smb.conf.empty? Can you give us /var/log/httpd/error_log for this run? In 4.x we fixed the part that mistakenly reports trust is 'established and verified' when it actually wasn't, but before that we need to see the debug logs to know the reason. There are only two (external) reasons: 1. AD DC was unable to resolve IPA DC via DNS query for SRV records for Kerberos and LDAP. 2. AD DC was unable to reach IPA DC due to misconfigured firewall. -- / Alexander Bokovoy From metebilgin48 at gmail.com Fri Feb 27 10:12:49 2015 From: metebilgin48 at gmail.com (mete bilgin) Date: Fri, 27 Feb 2015 12:12:49 +0200 Subject: [Freeipa-users] Centos 7 - ipa-server-3.3.3 AD trust trust-fetch-domains and add external group problem In-Reply-To: <20150227095329.GZ25455@redhat.com> References: <54F02BEB.5070506@redhat.com> <54F02EC6.5090405@redhat.com> <54F0336A.7060409@redhat.com> <20150227093602.GX25455@redhat.com> <20150227095329.GZ25455@redhat.com> Message-ID: 2015-02-27 11:53 GMT+02:00 Alexander Bokovoy : > On Fri, 27 Feb 2015, mete bilgin wrote: > >> Starting GENSEC mechanism spnego >>>> Starting GENSEC submechanism gssapi_krb5 >>>> Ticket in credentials cache for @IPDOMAIN will expire in 86400 secs >>>> GSS client Update(krb5)(1) Update failed: Unspecified GSS failure. >>>> Minor >>>> code may provide more information: KDC policy rejects request >>>> >>>> This means your trust is not working. How did you established trust? >>> Show exact commands. >>> >>> "KDC policy rejects request" means AD DC was unable to complete trust >>> validation. Usually it means it was unable to talk back to IPA master >>> which it discovers via SRV records over DNS. >>> -- >>> / Alexander Bokovoy >>> >>> >> >> Hi, >> >> When i add the turs return this. >> >> [root at ipa01 ~]# ipa trust-add --type=ad --admin admin --password >> Realm name: addomain.com >> Active directory domain administrator's password: >> ------------------------------------------- >> Re-established trust to domain "ADDOMAIN.COM" >> ------------------------------------------- >> Realm name: ADDOMAIN.COM >> Domain NetBIOS name: ADDOMAIN >> Domain Security Identifier: S-1-5-21-1343024091-2000478354-725345543 >> SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, >> S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, >> S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, >> S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 >> SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, >> S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, >> S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, >> S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 >> Trust direction: Two-way trust >> Trust type: Active Directory domain >> Trust status: Established and verified >> > Ok, and did you run that with debug enabled in smb.conf.empty? Can you > give us /var/log/httpd/error_log for this run? > > In 4.x we fixed the part that mistakenly reports trust is 'established > and verified' when it actually wasn't, but before that we need to see > the debug logs to know the reason. > > There are only two (external) reasons: > 1. AD DC was unable to resolve IPA DC via DNS query for SRV records for > Kerberos and LDAP. > 2. AD DC was unable to reach IPA DC due to misconfigured firewall. > > > -- > / Alexander Bokovoy > Hi, /var/log/httpd/error_log [Fri Feb 27 12:08:05.484181 2015] [:error] [pid 5367] ipa: INFO: admin at IPADOMAIN.COM: ping(version=u'2.51'): SUCCESS 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 scavenger: 100 dns: 100 ldb: 100 pm_process() returned Yes Using binding ncacn_np:ipa01.IPADOMAIN.COM[,] s4_tevent: Added timed event "dcerpc_connect_timeout_handler": 0x7fed9c4c80e0 s4_tevent: Added timed event "composite_trigger": 0x7fed9c50b290 s4_tevent: Added timed event "composite_trigger": 0x7fed9c3dbad0 s4_tevent: Running timer event 0x7fed9c50b290 "composite_trigger" s4_tevent: Destroying timer event 0x7fed9c3dbad0 "composite_trigger" Mapped to DCERPC endpoint \pipe\lsarpc added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 s4_tevent: Ending timer event 0x7fed9c50b290 "composite_trigger" s4_tevent: Added timed event "connect_multi_timer": 0x7fed9c4d3ea0 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d3520 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d3520 s4_tevent: Destroying timer event 0x7fed9c4d3ea0 "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 = 663430 SO_RCVBUF = 261942 SO_SNDLOWAT = 1 SO_RCVLOWAT = 1 SO_SNDTIMEO = 0 SO_RCVTIMEO = 0 TCP_QUICKACK = 1 TCP_DEFER_ACCEPT = 0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d82e0 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Destroying timer event 0x7fed9c4d82e0 "tevent_req_timedout" Starting GENSEC mechanism spnego Starting GENSEC submechanism gssapi_krb5 Ticket in credentials cache for @IPADOMAIN will expire in 76694 secs s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d96f0 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Destroying timer event 0x7fed9c4d96f0 "tevent_req_timedout" gensec_gssapi: NO credentials were delegated GSSAPI Connection will be cryptographically sealed s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4dcdb0 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Destroying timer event 0x7fed9c4dcdb0 "tevent_req_timedout" s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4dd100 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Destroying timer event 0x7fed9c4dd100 "tevent_req_timedout" num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=72, this_data=72, max_data=65535, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4dddc0 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4de2d0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4dda70 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4dda70 s4_tevent: Destroying timer event 0x7fed9c4dddc0 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c4de2d0 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c3eb870 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c3eb870 s4_tevent: Destroying timer event 0x7fed9c4c80e0 "dcerpc_connect_timeout_handler" lsa_OpenPolicy2: struct lsa_OpenPolicy2 in: struct lsa_OpenPolicy2 system_name : * system_name : '' attr : * attr: struct lsa_ObjectAttribute len : 0x00000000 (0) root_dir : NULL object_name : NULL attributes : 0x00000000 (0) sec_desc : NULL sec_qos : * sec_qos: struct lsa_QosInfo len : 0x00000000 (0) impersonation_level : 0x0000 (0) context_mode : 0x00 (0) effective_only : 0x00 (0) access_mask : 0x02000000 (33554432) 0: LSA_POLICY_VIEW_LOCAL_INFORMATION 0: LSA_POLICY_VIEW_AUDIT_INFORMATION 0: LSA_POLICY_GET_PRIVATE_INFORMATION 0: LSA_POLICY_TRUST_ADMIN 0: LSA_POLICY_CREATE_ACCOUNT 0: LSA_POLICY_CREATE_SECRET 0: LSA_POLICY_CREATE_PRIVILEGE 0: LSA_POLICY_SET_DEFAULT_QUOTA_LIMITS 0: LSA_POLICY_SET_AUDIT_REQUIREMENTS 0: LSA_POLICY_AUDIT_LOG_ADMIN 0: LSA_POLICY_SERVER_ADMIN 0: LSA_POLICY_LOOKUP_NAMES 0: LSA_POLICY_NOTIFICATION rpc request data: [0000] 00 00 02 00 01 00 00 00 00 00 00 00 01 00 00 00 ........ ........ [0010] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ [0020] 00 00 00 00 00 00 00 00 04 00 02 00 00 00 00 00 ........ ........ [0030] 00 00 00 00 00 00 00 02 ........ s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4d3630 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=80, this_data=80, max_data=4280, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4de250 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d37d0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d37d0 s4_tevent: Destroying timer event 0x7fed9c4de250 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c4d3630 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c3e07e0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c3e07e0 lsa_OpenPolicy2: struct lsa_OpenPolicy2 out: struct lsa_OpenPolicy2 handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000013-0000-0000-f054-0b4240160000 result : NT_STATUS_OK rpc reply data: [0000] 00 00 00 00 13 00 00 00 00 00 00 00 F0 54 0B 42 ........ .....T.B [0010] 40 16 00 00 00 00 00 00 @....... lsa_QueryInfoPolicy2: struct lsa_QueryInfoPolicy2 in: struct lsa_QueryInfoPolicy2 handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000013-0000-0000-f054-0b4240160000 level : LSA_POLICY_INFO_DNS (12) rpc request data: [0000] 00 00 00 00 13 00 00 00 00 00 00 00 F0 54 0B 42 ........ .....T.B [0010] 40 16 00 00 0C 00 @..... s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4d37b0 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=46, this_data=46, max_data=4280, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4de3d0 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4de080 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4de080 s4_tevent: Destroying timer event 0x7fed9c4de3d0 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c4d37b0 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c3e08c0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c3e08c0 lsa_QueryInfoPolicy2: struct lsa_QueryInfoPolicy2 out: struct lsa_QueryInfoPolicy2 info : * info : * info : union lsa_PolicyInformation(case 12) dns: struct lsa_DnsDomainInfo name: struct lsa_StringLarge length : 0x0010 (16) size : 0x0012 (18) string : * string : 'IPADOMAIN' dns_domain: struct lsa_StringLarge length : 0x0018 (24) size : 0x001a (26) string : * string : 'IPADOMAIN.COM' dns_forest: struct lsa_StringLarge length : 0x0018 (24) size : 0x001a (26) string : * string : 'IPADOMAIN.COM' domain_guid : 00000015-e851-c207-0dd0-a20419e2e2c7 sid : * sid : S-1-5-21-3255298129-77778957-3353535001 result : NT_STATUS_OK rpc reply data: [0000] 00 00 02 00 0C 00 00 00 10 00 12 00 04 00 02 00 ........ ........ [0010] 18 00 1A 00 08 00 02 00 18 00 1A 00 0C 00 02 00 ........ ........ [0020] 15 00 00 00 51 E8 07 C2 0D D0 A2 04 19 E2 E2 C7 ....Q... ........ [0030] 10 00 02 00 09 00 00 00 00 00 00 00 08 00 00 00 ........ ........ [0040] 42 00 49 00 4C 00 59 00 4F 00 4E 00 45 00 52 00 B.I.L.Y. O.N.E.R. [0050] 0D 00 00 00 00 00 00 00 0C 00 00 00 62 00 69 00 ........ ....b.i. [0060] 6C 00 79 00 6F 00 6E 00 65 00 72 00 2E 00 63 00 l.y.o.n. e.r...c. [0070] 6F 00 6D 00 0D 00 00 00 00 00 00 00 0C 00 00 00 o.m..... ........ [0080] 62 00 69 00 6C 00 79 00 6F 00 6E 00 65 00 72 00 b.i.l.y. o.n.e.r. [0090] 2E 00 63 00 6F 00 6D 00 04 00 00 00 01 04 00 00 ..c.o.m. ........ [00A0] 00 00 00 05 15 00 00 00 51 E8 07 C2 0D D0 A2 04 ........ Q....... [00B0] 19 E2 E2 C7 00 00 00 00 ........ lsa_QueryInfoPolicy2: struct lsa_QueryInfoPolicy2 in: struct lsa_QueryInfoPolicy2 handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000013-0000-0000-f054-0b4240160000 level : LSA_POLICY_INFO_ROLE (6) rpc request data: [0000] 00 00 00 00 13 00 00 00 00 00 00 00 F0 54 0B 42 ........ .....T.B [0010] 40 16 00 00 06 00 @..... s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4da190 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=46, this_data=46, max_data=4280, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4ded50 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4dea00 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4dea00 s4_tevent: Destroying timer event 0x7fed9c4ded50 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c4da190 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d96b0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d96b0 lsa_QueryInfoPolicy2: struct lsa_QueryInfoPolicy2 out: struct lsa_QueryInfoPolicy2 info : * info : * info : union lsa_PolicyInformation(case 6) role: struct lsa_ServerRole role : LSA_ROLE_PRIMARY (3) result : NT_STATUS_OK rpc reply data: [0000] 00 00 02 00 06 00 00 00 03 00 00 00 00 00 00 00 ........ ........ s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c456960 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c5091d0 s4_tevent: Destroying timer event 0x7fed9c456960 "tevent_req_timedout" s4_tevent: Cancel immediate event 0x7fed9c5091d0 "tevent_queue_immediate_trigger" s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4c9cf0 smb_signing_md5: sequence number 28 smb_signing_sign_pdu: sent SMB signature of [0000] AD 05 35 AC 10 CB 27 85 ..5...'. s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c273010 s4_tevent: Destroying timer event 0x7fed9c4c9cf0 "tevent_req_timedout" s4_tevent: Cancel immediate event 0x7fed9c273010 "tevent_queue_immediate_trigger" 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 scavenger: 100 dns: 100 ldb: 100 pm_process() returned Yes added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 finddcs: searching for a DC by DNS domain ADDOMAIN.COM finddcs: looking for SRV records for _ldap._tcp.ADDOMAIN.COM ads_dns_lookup_srv: 3 records returned in the answer section. ads_dns_parse_rr_srv: Parsed ad01.ADDOMAIN.COM [0, 100, 389] ads_dns_parse_rr_srv: Parsed ad02.ADDOMAIN.COM [0, 100, 389] ads_dns_parse_rr_srv: Parsed ad03.ADDOMAIN.COM [0, 100, 389] Addrs = 192.168.12.236 at 389/ad01,172.16.50.70 at 389/ad02,192.168.12.239 at 389 /ad03 finddcs: DNS SRV response 0 at '192.168.12.236' finddcs: DNS SRV response 1 at '172.16.50.70' finddcs: DNS SRV response 2 at '192.168.12.239' finddcs: performing CLDAP query on 192.168.12.236 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4caae0 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c279e50 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c279e50 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c2d2970 s4_tevent: Destroying timer event 0x7fed9c2d2970 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c4caae0 "tevent_req_timedout" &response->data.nt5_ex: struct NETLOGON_SAM_LOGON_RESPONSE_EX command : LOGON_SAM_LOGON_RESPONSE_EX (23) sbz : 0x0000 (0) server_type : 0x000031fd (12797) 1: NBT_SERVER_PDC 1: NBT_SERVER_GC 1: NBT_SERVER_LDAP 1: NBT_SERVER_DS 1: NBT_SERVER_KDC 1: NBT_SERVER_TIMESERV 1: NBT_SERVER_CLOSEST 1: NBT_SERVER_WRITABLE 0: NBT_SERVER_GOOD_TIMESERV 0: NBT_SERVER_NDNC 0: NBT_SERVER_SELECT_SECRET_DOMAIN_6 1: NBT_SERVER_FULL_SECRET_DOMAIN_6 1: NBT_SERVER_ADS_WEB_SERVICE 0: NBT_SERVER_HAS_DNS_NAME 0: NBT_SERVER_IS_DEFAULT_NC 0: NBT_SERVER_FOREST_ROOT domain_uuid : 6aac190b-04eb-464f-bdcc-b07e27e2d1e5 forest : 'ADDOMAIN.COM' dns_domain : 'ADDOMAIN.COM' pdc_dns_name : 'ad01.ADDOMAIN.COM' domain_name : 'ADDOMAIN' pdc_name : 'ad01' user_name : '' server_site : 'Default-First-Site-Name' client_site : 'Default-First-Site-Name' sockaddr_size : 0x00 (0) sockaddr: struct nbt_sockaddr sockaddr_family : 0x00000000 (0) pdc_ip : (null) remaining : DATA_BLOB length=0 next_closest_site : NULL nt_version : 0x00000005 (5) 1: NETLOGON_NT_VERSION_1 0: NETLOGON_NT_VERSION_5 1: NETLOGON_NT_VERSION_5EX 0: NETLOGON_NT_VERSION_5EX_WITH_IP 0: NETLOGON_NT_VERSION_WITH_CLOSEST_SITE 0: NETLOGON_NT_VERSION_AVOID_NT4EMUL 0: NETLOGON_NT_VERSION_PDC 0: NETLOGON_NT_VERSION_IP 0: NETLOGON_NT_VERSION_LOCAL 0: NETLOGON_NT_VERSION_GC lmnt_token : 0xffff (65535) lm20_token : 0xffff (65535) finddcs: Found matching DC 192.168.12.236 with server_type=0x000031fd 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 scavenger: 100 dns: 100 ldb: 100 pm_process() returned Yes Using binding ncacn_np:ad01.ADDOMAIN.COM[,] s4_tevent: Added timed event "dcerpc_connect_timeout_handler": 0x7fed9c4d1dd0 s4_tevent: Added timed event "composite_trigger": 0x7fed9c4caae0 s4_tevent: Added timed event "composite_trigger": 0x7fed9c2db340 s4_tevent: Running timer event 0x7fed9c4caae0 "composite_trigger" s4_tevent: Destroying timer event 0x7fed9c2db340 "composite_trigger" Mapped to DCERPC endpoint \pipe\lsarpc added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 s4_tevent: Ending timer event 0x7fed9c4caae0 "composite_trigger" s4_tevent: Added timed event "connect_multi_timer": 0x7fed9c3cf8e0 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4caae0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4caae0 s4_tevent: Destroying timer event 0x7fed9c3cf8e0 "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 = 23080 SO_RCVBUF = 87380 SO_SNDLOWAT = 1 SO_RCVLOWAT = 1 SO_SNDTIMEO = 0 SO_RCVTIMEO = 0 TCP_QUICKACK = 1 TCP_DEFER_ACCEPT = 0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4dd1c0 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4dcdd0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4dcdd0 s4_tevent: Destroying timer event 0x7fed9c4dd1c0 "tevent_req_timedout" Starting GENSEC mechanism spnego Starting GENSEC submechanism ntlmssp negotiate: struct NEGOTIATE_MESSAGE Signature : 'NTLMSSP' MessageType : NtLmNegotiate (1) NegotiateFlags : 0x60088215 (1611170325) 1: NTLMSSP_NEGOTIATE_UNICODE 0: NTLMSSP_NEGOTIATE_OEM 1: NTLMSSP_REQUEST_TARGET 1: NTLMSSP_NEGOTIATE_SIGN 0: NTLMSSP_NEGOTIATE_SEAL 0: NTLMSSP_NEGOTIATE_DATAGRAM 0: NTLMSSP_NEGOTIATE_LM_KEY 0: NTLMSSP_NEGOTIATE_NETWARE 1: NTLMSSP_NEGOTIATE_NTLM 0: NTLMSSP_NEGOTIATE_NT_ONLY 0: NTLMSSP_ANONYMOUS 0: NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED 0: NTLMSSP_NEGOTIATE_OEM_WORKSTATION_SUPPLIED 0: NTLMSSP_NEGOTIATE_THIS_IS_LOCAL_CALL 1: NTLMSSP_NEGOTIATE_ALWAYS_SIGN 0: NTLMSSP_TARGET_TYPE_DOMAIN 0: NTLMSSP_TARGET_TYPE_SERVER 0: NTLMSSP_TARGET_TYPE_SHARE 1: NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY 0: NTLMSSP_NEGOTIATE_IDENTIFY 0: NTLMSSP_REQUEST_NON_NT_SESSION_KEY 0: NTLMSSP_NEGOTIATE_TARGET_INFO 0: NTLMSSP_NEGOTIATE_VERSION 1: NTLMSSP_NEGOTIATE_128 1: NTLMSSP_NEGOTIATE_KEY_EXCH 0: NTLMSSP_NEGOTIATE_56 DomainNameLen : 0x0008 (8) DomainNameMaxLen : 0x0008 (8) DomainName : * DomainName : 'IPADOMAIN' WorkstationLen : 0x0008 (8) WorkstationMaxLen : 0x0008 (8) Workstation : * Workstation : 'IPADOMAIN' s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4cce50 smb_signing_sign_pdu: sent SMB signature of [0000] 42 53 52 53 50 59 4C 20 BSRSPYL s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4dcdd0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4dcdd0 s4_tevent: Destroying timer event 0x7fed9c4cce50 "tevent_req_timedout" Got challenge flags: Got NTLMSSP neg_flags=0x62898215 NTLMSSP_NEGOTIATE_UNICODE NTLMSSP_REQUEST_TARGET NTLMSSP_NEGOTIATE_SIGN NTLMSSP_NEGOTIATE_NTLM NTLMSSP_NEGOTIATE_ALWAYS_SIGN NTLMSSP_NEGOTIATE_NTLM2 NTLMSSP_NEGOTIATE_TARGET_INFO NTLMSSP_NEGOTIATE_VERSION NTLMSSP_NEGOTIATE_128 NTLMSSP_NEGOTIATE_KEY_EXCH NTLMSSP: Set final flags: Got NTLMSSP neg_flags=0x60088215 NTLMSSP_NEGOTIATE_UNICODE NTLMSSP_REQUEST_TARGET NTLMSSP_NEGOTIATE_SIGN NTLMSSP_NEGOTIATE_NTLM NTLMSSP_NEGOTIATE_ALWAYS_SIGN NTLMSSP_NEGOTIATE_NTLM2 NTLMSSP_NEGOTIATE_128 NTLMSSP_NEGOTIATE_KEY_EXCH s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4cda00 smb_signing_sign_pdu: sent SMB signature of [0000] 42 53 52 53 50 59 4C 20 BSRSPYL s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4dcdd0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4dcdd0 s4_tevent: Destroying timer event 0x7fed9c4cda00 "tevent_req_timedout" smb_signing_activate: user_session_key [0000] CF 87 99 C6 23 92 38 CB E1 A5 77 3B A6 83 22 35 ....#.8. ..w;.."5 smb_signing_activate: NULL response_data smb_signing_md5: sequence number 1 smb_signing_check_pdu: seq 1: got good SMB signature of [0000] 36 6D 36 95 D5 4D 59 F4 6m6..MY. s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4ccd00 smb_signing_md5: sequence number 2 smb_signing_sign_pdu: sent SMB signature of [0000] 96 8F 91 1E 51 95 4F 0F ....Q.O. s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4dcdd0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4dcdd0 smb_signing_md5: sequence number 3 smb_signing_check_pdu: seq 3: got good SMB signature of [0000] D9 7B 8F 20 F5 BC CF 68 .{. ...h s4_tevent: Destroying timer event 0x7fed9c4ccd00 "tevent_req_timedout" s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4cc9a0 smb_signing_md5: sequence number 4 smb_signing_sign_pdu: sent SMB signature of [0000] DD 31 0C 55 92 DE FC E7 .1.U.... s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4dcdd0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4dcdd0 smb_signing_md5: sequence number 5 smb_signing_check_pdu: seq 5: got good SMB signature of [0000] 31 FD 9D 28 A1 DE 1C 2E 1..(.... s4_tevent: Destroying timer event 0x7fed9c4cc9a0 "tevent_req_timedout" num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=72, this_data=72, max_data=65535, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4cd590 smb_signing_md5: sequence number 6 smb_signing_sign_pdu: sent SMB signature of [0000] F7 3D 8A 85 B4 9A BA 7A .=.....z s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4dcdd0 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4de180 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4dcdd0 smb_signing_md5: sequence number 7 smb_signing_check_pdu: seq 7: got good SMB signature of [0000] A4 0D AB F2 AD F7 E7 54 .......T s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4cd7b0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4cd7b0 s4_tevent: Destroying timer event 0x7fed9c4cd590 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c4de180 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c0354e0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c0354e0 s4_tevent: Destroying timer event 0x7fed9c4d1dd0 "dcerpc_connect_timeout_handler" lsa_OpenPolicy2: struct lsa_OpenPolicy2 in: struct lsa_OpenPolicy2 system_name : * system_name : '' attr : * attr: struct lsa_ObjectAttribute len : 0x00000000 (0) root_dir : NULL object_name : NULL attributes : 0x00000000 (0) sec_desc : NULL sec_qos : * sec_qos: struct lsa_QosInfo len : 0x00000000 (0) impersonation_level : 0x0000 (0) context_mode : 0x00 (0) effective_only : 0x00 (0) access_mask : 0x02000000 (33554432) 0: LSA_POLICY_VIEW_LOCAL_INFORMATION 0: LSA_POLICY_VIEW_AUDIT_INFORMATION 0: LSA_POLICY_GET_PRIVATE_INFORMATION 0: LSA_POLICY_TRUST_ADMIN 0: LSA_POLICY_CREATE_ACCOUNT 0: LSA_POLICY_CREATE_SECRET 0: LSA_POLICY_CREATE_PRIVILEGE 0: LSA_POLICY_SET_DEFAULT_QUOTA_LIMITS 0: LSA_POLICY_SET_AUDIT_REQUIREMENTS 0: LSA_POLICY_AUDIT_LOG_ADMIN 0: LSA_POLICY_SERVER_ADMIN 0: LSA_POLICY_LOOKUP_NAMES 0: LSA_POLICY_NOTIFICATION rpc request data: [0000] 00 00 02 00 01 00 00 00 00 00 00 00 01 00 00 00 ........ ........ [0010] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ [0020] 00 00 00 00 00 00 00 00 04 00 02 00 00 00 00 00 ........ ........ [0030] 00 00 00 00 00 00 00 02 ........ s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c4c9cf0 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4c9280 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c4c9cf0 s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c4c9cf0 num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=80, this_data=80, max_data=4280, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4de040 smb_signing_md5: sequence number 8 smb_signing_sign_pdu: sent SMB signature of [0000] B2 A8 8C 3E D8 8D D2 CE ...>.... s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4dcdd0 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c4c9cf0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4dcdd0 smb_signing_md5: sequence number 9 smb_signing_check_pdu: seq 9: got good SMB signature of [0000] 6E 09 43 5E 16 77 DD 6C n.C^.w.l s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4cd990 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4cd990 s4_tevent: Destroying timer event 0x7fed9c4de040 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c4c9280 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c0354e0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c0354e0 lsa_OpenPolicy2: struct lsa_OpenPolicy2 out: struct lsa_OpenPolicy2 handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 523067c0-2963-41a2-9b62-de196bc43c47 result : NT_STATUS_OK rpc reply data: [0000] 00 00 00 00 C0 67 30 52 63 29 A2 41 9B 62 DE 19 .....g0R c).A.b.. [0010] 6B C4 3C 47 00 00 00 00 k...k. .Ga<%..# [0110] 88 C6 02 D2 45 59 47 57 71 0B D9 49 04 30 0E 8C ....EYGW q..I.0.. [0120] 83 59 8E 8A F6 25 AB 3E 53 54 0B 65 AF 34 24 AC .Y...%.> ST.e.4$. [0130] 7D 8D F8 A8 B8 88 20 D3 98 08 E3 EB B4 2A B5 03 }..... . .....*.. [0140] 28 3C 03 A2 55 21 9E 4F 53 BA 25 C2 33 E5 06 53 (<..U!.O S.%.3..S [0150] 22 79 E0 9A 06 A4 C6 16 34 0E 86 14 06 FE 31 C1 "y...... 4.....1. [0160] D1 6C EF 65 88 35 67 8D 3D E9 EF 1D 41 14 9B F4 .l.e.5g. =...A... [0170] 5E 05 B7 75 25 1F A6 7C A0 8C 8D F6 CD 1F CE 7B ^..u%..| .......{ [0180] 17 8B 09 8A 68 D1 25 60 45 32 F8 C1 E1 96 7B 55 ....h.%` E2....{U [0190] F6 FC CE 1E B2 46 F7 C6 CC 83 CB C2 6E 42 74 8C .....F.. ....nBt. [01A0] 58 9C 5A B3 62 18 00 82 16 6D 70 1F 15 E5 80 0E X.Z.b... .mp..... [01B0] E7 72 54 24 6D 71 E5 F4 DD 40 B3 81 79 09 CF 3B .rT$mq.. . at ..y..; [01C0] 17 15 E7 C7 58 1B 9F 36 97 AB CD 34 39 CF B6 87 ....X..6 ...49... [01D0] DA B7 FF 0E 65 78 C7 44 3A 54 7F D9 7C C8 DD 7B ....ex.D :T..|..{ [01E0] 26 01 9F 34 E7 E9 00 B5 F2 8E E5 E7 4E C3 01 6D &..4.... ....N..m [01F0] 4D DB 98 81 F7 EA 97 E3 CC 2E 65 2A C4 3D 4F 9C M....... ..e*.=O. [0200] 88 DF E4 BD E8 26 68 B7 26 6E 7C B3 C3 4A 09 04 .....&h. &n|..J.. [0210] 43 A1 ED 23 7A F0 72 36 77 7F BA E4 29 38 EF 10 C..#z.r6 w...)8.. [0220] 0F 5E 27 2F 31 28 2E B7 58 5C C9 72 9B 4F 9C 3F .^'/1(.. X\.r.O.? [0230] 9A 91 68 87 5B 99 39 AE E1 DA D8 9E E3 5F D6 15 ..h.[.9. ....._.. [0240] 7E C4 86 DA B1 F3 53 C0 01 51 D0 B5 00 CC 99 6D ~.....S. .Q.....m [0250] 19 16 52 63 67 01 D4 41 23 53 B6 E9 15 16 00 15 ..Rcg..A #S...... [0260] 6F 0C 77 2F D9 A5 38 AD 22 BB DA 8C 62 E7 44 61 o.w/..8. "...b.Da [0270] F5 83 67 A3 DB 2C DA 83 52 A3 F7 71 C9 B3 7F 69 ..g..,.. R..q...i [0280] C1 84 8A F6 D1 E0 D9 E3 2E 67 A6 0E 43 10 8F 56 ........ .g..C..V [0290] 4A 04 60 55 A4 30 33 66 BC 52 6A 58 11 37 03 F9 J.`U.03f .RjX.7.. [02A0] B7 6A 1C 9B AF 2B D1 0A 34 A6 0E 83 4E F2 8F 0C .j...+.. 4...N... [02B0] F9 F3 6F A3 7B BA CA CF 12 82 65 1A 95 AA 6D 5A ..o.{... ..e...mZ [02C0] 4C 9A DB 8F FC 85 1F AC DD 52 E9 C5 D7 57 78 41 L....... .R...WxA [02D0] AD 63 86 61 06 2D AF B5 2E 69 E6 4E 42 8E AA 3B .c.a.-.. .i.NB..; [02E0] 07 11 5F 7A F7 CE FF 95 48 4A 46 A6 0F 8B 74 CC .._z.... HJF...t. [02F0] 38 1D BF 73 C1 78 78 DD 73 6D 52 3E C6 01 38 D1 8..s.xx. smR>..8. [0300] E4 27 24 F7 22 87 6B 86 0B 64 68 D6 1B 31 96 C2 .'$.".k. .dh..1.. [0310] A7 35 BF F6 38 70 EE 9E 26 BB 48 9F A6 68 54 69 .5..8p.. &.H..hTi [0320] 9F 5E 2D 29 9A 78 6B EB 8A CE A6 59 FC 5E 61 4A .^-).xk. ...Y.^aJ [0330] D5 9C A4 65 5F 21 A3 49 7A 9A 40 38 AD 28 27 11 ...e_!.I z. at 8.('. [0340] B4 41 11 7F 37 0B AE 85 2A E2 35 89 78 1C A2 EB .A..7... *.5.x... [0350] 77 75 43 9C D1 C9 A4 D2 90 1F 7F A9 84 0D FD C1 wuC..... ........ [0360] D0 BA 67 3D 64 53 EB 0C 34 23 01 83 66 EC 22 35 ..g=dS.. 4#..f."5 [0370] EA 29 46 9F 57 1F 83 C2 03 F0 41 CD 35 C0 88 10 .)F.W... ..A.5... [0380] 8E 98 2C 85 EE CA BD DA CE 34 B5 B6 A1 02 DF 2B ..,..... .4.....+ [0390] 9A 64 71 39 B8 F6 CF 4C 4B C7 64 86 58 D7 D9 6F .dq9...L K.d.X..o [03A0] 4A D6 FD 80 A5 51 96 DB 8C 4A 0F AF 1A 9A AC 28 J....Q.. .J.....( [03B0] 79 30 68 9B D3 2E 8E D6 1A C4 DD 9A 78 A8 CC 73 y0h..... ....x..s [03C0] F1 94 2F 00 3B ED 4A B3 00 2E AD 2A 5B E8 2A 70 ../.;.J. ...*[.*p [03D0] CE F8 82 08 92 3F 02 73 BF 36 37 BE A1 25 C5 93 .....?.s .67..%.. [03E0] 29 75 9B F0 24 52 C9 4D 25 46 31 D5 69 2C 61 70 )u..$R.M %F1.i,ap [03F0] 82 1E D0 B1 4E 2D 0E 05 AE 60 06 3C 0D E1 94 05 ....N-.. .`.<.... [0400] 2F 9A 73 97 BC AC F6 30 AC DE E8 FB C6 E4 7C 17 /.s....0 ......|. [0410] B0 6F C8 DE 76 05 0E 6E 2F C7 83 EB FA C3 10 5E .o..v..n /......^ [0420] FF EA 60 8C 9C 22 3E F6 95 B2 B1 00 95 34 61 C3 ..`..">. .....4a. [0430] D1 9F 39 A3 EF E8 E2 A1 B6 92 7E 13 CF 18 8A A5 ..9..... ..~..... [0440] 0E DD 0B B9 44 38 A5 B2 9A 2B FF 0D 8E 85 46 7F ....D8.. .+....F. [0450] 8D B4 5C 60 16 66 AF 07 51 11 89 91 84 D4 89 BC ..\`.f.. Q....... [0460] 83 AE 8F D8 99 DC A0 C7 F9 29 08 3E 1A 1D 56 22 ........ .).>..V" [0470] 0C 92 AE 9C 74 5C 39 46 7E EF BA 09 A0 D3 98 B3 ....t\9F ~....... [0480] 97 D1 E0 CC 83 9C A4 F0 D9 92 40 70 81 84 FA 18 ........ .. at p.... [0490] 73 DF 25 F9 CD E9 40 A1 8B 5E A9 F8 25 AC AC 1E s.%... at . .^..%... [04A0] D7 DD 5E 54 62 9B 25 40 9C 89 F3 D1 41 49 4B 7C ..^Tb.%@ ....AIK| [04B0] DD 67 7A 43 E9 41 74 48 8E AC 4F 41 42 93 B6 A9 .gzC.AtH ..OAB... [04C0] 6D 5C F4 80 78 EE A8 DA FE C2 4B FA 19 7F FE 3E m\..x... ..K....> [04D0] 9C B8 4B 26 70 0F 32 53 28 FF EC 77 00 00 01 00 ..K&p.2S (..w.... s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c4c9cf0 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4e1fc0 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c4c9cf0 s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c4c9cf0 num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=1272, this_data=1272, max_data=4280, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4e3db0 smb_signing_md5: sequence number 18 smb_signing_sign_pdu: sent SMB signature of [0000] 1A 49 DF F6 E8 63 A6 88 .I...c.. s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4dcdd0 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c4c9cf0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4dcdd0 smb_signing_md5: sequence number 19 smb_signing_check_pdu: seq 19: got good SMB signature of [0000] 79 1A F5 6C DA 8F 59 32 y..l..Y2 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4e2140 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4e2140 s4_tevent: Destroying timer event 0x7fed9c4e3db0 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c4e1fc0 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4e1530 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4e1530 lsa_CreateTrustedDomainEx2: struct lsa_CreateTrustedDomainEx2 out: struct lsa_CreateTrustedDomainEx2 trustdom_handle : * trustdom_handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 86a5ad6a-47dc-4d86-8e78-c8c493bef40f result : NT_STATUS_OK rpc reply data: [0000] 00 00 00 00 6A AD A5 86 DC 47 86 4D 8E 78 C8 C4 ....j... .G.M.x.. [0010] 93 BE F4 0F 00 00 00 00 ........ lsa_OpenTrustedDomainByName: struct lsa_OpenTrustedDomainByName in: struct lsa_OpenTrustedDomainByName handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 523067c0-2963-41a2-9b62-de196bc43c47 name: struct lsa_String length : 0x0018 (24) size : 0x0018 (24) string : * string : 'IPADOMAIN.COM' access_mask : 0x02000000 (33554432) 0: LSA_TRUSTED_QUERY_DOMAIN_NAME 0: LSA_TRUSTED_QUERY_CONTROLLERS 0: LSA_TRUSTED_SET_CONTROLLERS 0: LSA_TRUSTED_QUERY_POSIX 0: LSA_TRUSTED_SET_POSIX 0: LSA_TRUSTED_SET_AUTH 0: LSA_TRUSTED_QUERY_AUTH rpc request data: [0000] 00 00 00 00 C0 67 30 52 63 29 A2 41 9B 62 DE 19 .....g0R c).A.b.. [0010] 6B C4 3C 47 18 00 18 00 00 00 02 00 0C 00 00 00 k..-..` .\..sN{. [04C0] 73 92 2A 90 18 F0 D1 06 CC 6F FA BF 54 57 01 AE s.*..... .o..TW.. [04D0] 17 8B 69 EB 00 00 01 00 ..i..... s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4e2140 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=1264, this_data=1264, max_data=4280, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c046240 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4e2a70 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4e2a70 s4_tevent: Destroying timer event 0x7fed9c046240 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c4e2140 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c044c90 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c044c90 lsa_CreateTrustedDomainEx2: struct lsa_CreateTrustedDomainEx2 out: struct lsa_CreateTrustedDomainEx2 trustdom_handle : * trustdom_handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000015-0000-0000-f054-0c4240160000 result : NT_STATUS_OK rpc reply data: [0000] 00 00 00 00 15 00 00 00 00 00 00 00 F0 54 0C 42 ........ .....T.B [0010] 40 16 00 00 00 00 00 00 @....... lsa_OpenTrustedDomainByName: struct lsa_OpenTrustedDomainByName in: struct lsa_OpenTrustedDomainByName handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000013-0000-0000-f054-0b4240160000 name: struct lsa_String length : 0x0014 (20) size : 0x0014 (20) string : * string : 'ADDOMAIN.COM' access_mask : 0x02000000 (33554432) 0: LSA_TRUSTED_QUERY_DOMAIN_NAME 0: LSA_TRUSTED_QUERY_CONTROLLERS 0: LSA_TRUSTED_SET_CONTROLLERS 0: LSA_TRUSTED_QUERY_POSIX 0: LSA_TRUSTED_SET_POSIX 0: LSA_TRUSTED_SET_AUTH 0: LSA_TRUSTED_QUERY_AUTH rpc request data: [0000] 00 00 00 00 13 00 00 00 00 00 00 00 F0 54 0B 42 ........ .....T.B [0010] 40 16 00 00 14 00 14 00 00 00 02 00 0A 00 00 00 @....... ........ [0020] 00 00 00 00 0A 00 00 00 4C 00 49 00 42 00 45 00 ........ L.I.B.E. [0030] 52 00 4F 00 2E 00 49 00 4E 00 54 00 00 00 00 02 R.O...I. N.T..... s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c045400 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=88, this_data=88, max_data=4280, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4e3820 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4e3430 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4e3430 s4_tevent: Destroying timer event 0x7fed9c4e3820 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c045400 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c044c90 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c044c90 lsa_OpenTrustedDomainByName: struct lsa_OpenTrustedDomainByName out: struct lsa_OpenTrustedDomainByName trustdom_handle : * trustdom_handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000016-0000-0000-f054-0c4240160000 result : NT_STATUS_OK rpc reply data: [0000] 00 00 00 00 16 00 00 00 00 00 00 00 F0 54 0C 42 ........ .....T.B [0010] 40 16 00 00 00 00 00 00 @....... lsa_SetInformationTrustedDomain: struct lsa_SetInformationTrustedDomain in: struct lsa_SetInformationTrustedDomain trustdom_handle : * trustdom_handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000016-0000-0000-f054-0c4240160000 level : LSA_TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES (13) info : * info : union lsa_TrustedDomainInfo(case 13) enc_types: struct lsa_TrustDomainInfoSupportedEncTypes enc_types : 0x0000001c (28) 0: KERB_ENCTYPE_DES_CBC_CRC 0: KERB_ENCTYPE_DES_CBC_MD5 1: KERB_ENCTYPE_RC4_HMAC_MD5 1: KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 1: KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96 rpc request data: [0000] 00 00 00 00 16 00 00 00 00 00 00 00 F0 54 0C 42 ........ .....T.B [0010] 40 16 00 00 0D 00 0D 00 1C 00 00 00 @....... .... s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c4e3520 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=52, this_data=52, max_data=4280, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4e2360 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c243eb0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d7ba0 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4e38e0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4e38e0 s4_tevent: Destroying timer event 0x7fed9c4e2360 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c4e3520 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4e3350 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4e3350 lsa_SetInformationTrustedDomain: struct lsa_SetInformationTrustedDomain out: struct lsa_SetInformationTrustedDomain result : NT_STATUS_OK rpc reply data: [0000] 00 00 00 00 .... lsa_SetInformationTrustedDomain: struct lsa_SetInformationTrustedDomain in: struct lsa_SetInformationTrustedDomain trustdom_handle : * trustdom_handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000016-0000-0000-f054-0c4240160000 level : LSA_TRUSTED_DOMAIN_INFO_INFO_EX (6) info : * info : union lsa_TrustedDomainInfo(case 6) info_ex: struct lsa_TrustDomainInfoInfoEx domain_name: struct lsa_StringLarge length : 0x0014 (20) size : 0x0016 (22) string : * string : 'ADDOMAIN.COM' netbios_name: struct lsa_StringLarge length : 0x000c (12) size : 0x000e (14) string : * string : 'ADDOMAIN' sid : * sid : S-1-5-21-1343024091-2000478354-725345543 trust_direction : 0x00000003 (3) 1: LSA_TRUST_DIRECTION_INBOUND 1: LSA_TRUST_DIRECTION_OUTBOUND trust_type : LSA_TRUST_TYPE_UPLEVEL (2) trust_attributes : 0x00000008 (8) 0: LSA_TRUST_ATTRIBUTE_NON_TRANSITIVE 0: LSA_TRUST_ATTRIBUTE_UPLEVEL_ONLY 0: LSA_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN 1: LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE 0: LSA_TRUST_ATTRIBUTE_CROSS_ORGANIZATION 0: LSA_TRUST_ATTRIBUTE_WITHIN_FOREST 0: LSA_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL 0: LSA_TRUST_ATTRIBUTE_USES_RC4_ENCRYPTION rpc request data: [0000] 00 00 00 00 16 00 00 00 00 00 00 00 F0 54 0C 42 ........ .....T.B [0010] 40 16 00 00 06 00 06 00 14 00 16 00 00 00 02 00 @....... ........ [0020] 0C 00 0E 00 04 00 02 00 08 00 02 00 03 00 00 00 ........ ........ [0030] 02 00 00 00 08 00 00 00 0B 00 00 00 00 00 00 00 ........ ........ [0040] 0A 00 00 00 4C 00 49 00 42 00 45 00 52 00 4F 00 ....L.I. B.E.R.O. [0050] 2E 00 49 00 4E 00 54 00 07 00 00 00 00 00 00 00 ..I.N.T. ........ [0060] 06 00 00 00 4C 00 49 00 42 00 45 00 52 00 4F 00 ....L.I. B.E.R.O. [0070] 04 00 00 00 01 04 00 00 00 00 00 05 15 00 00 00 ........ ........ [0080] DB EB 0C 50 92 E0 3C 77 07 E5 3B 2B ...P..data.nt5_ex: struct NETLOGON_SAM_LOGON_RESPONSE_EX command : LOGON_SAM_LOGON_RESPONSE_EX (23) sbz : 0x0000 (0) server_type : 0x000013fc (5116) 0: NBT_SERVER_PDC 1: NBT_SERVER_GC 1: NBT_SERVER_LDAP 1: NBT_SERVER_DS 1: NBT_SERVER_KDC 1: NBT_SERVER_TIMESERV 1: NBT_SERVER_CLOSEST 1: NBT_SERVER_WRITABLE 1: NBT_SERVER_GOOD_TIMESERV 0: NBT_SERVER_NDNC 0: NBT_SERVER_SELECT_SECRET_DOMAIN_6 1: NBT_SERVER_FULL_SECRET_DOMAIN_6 0: NBT_SERVER_ADS_WEB_SERVICE 0: NBT_SERVER_HAS_DNS_NAME 0: NBT_SERVER_IS_DEFAULT_NC 0: NBT_SERVER_FOREST_ROOT domain_uuid : 6aac190b-04eb-464f-bdcc-b07e27e2d1e5 forest : 'ADDOMAIN.COM' dns_domain : 'ADDOMAIN.COM' pdc_dns_name : 'ad03.ADDOMAIN.COM' domain_name : 'ADDOMAIN' pdc_name : 'ad03' user_name : '' server_site : 'Default-First-Site-Name' client_site : 'Default-First-Site-Name' sockaddr_size : 0x00 (0) sockaddr: struct nbt_sockaddr sockaddr_family : 0x00000000 (0) pdc_ip : (null) remaining : DATA_BLOB length=0 next_closest_site : NULL nt_version : 0x00000005 (5) 1: NETLOGON_NT_VERSION_1 0: NETLOGON_NT_VERSION_5 1: NETLOGON_NT_VERSION_5EX 0: NETLOGON_NT_VERSION_5EX_WITH_IP 0: NETLOGON_NT_VERSION_WITH_CLOSEST_SITE 0: NETLOGON_NT_VERSION_AVOID_NT4EMUL 0: NETLOGON_NT_VERSION_PDC 0: NETLOGON_NT_VERSION_IP 0: NETLOGON_NT_VERSION_LOCAL 0: NETLOGON_NT_VERSION_GC lmnt_token : 0xffff (65535) lm20_token : 0xffff (65535) finddcs: Found matching DC 192.168.12.239 with server_type=0x000013fc Using binding ncacn_np:ad03.ADDOMAIN.COM[,] s4_tevent: Added timed event "dcerpc_connect_timeout_handler": 0x7fed9c4b0e00 s4_tevent: Added timed event "composite_trigger": 0x7fed9c143740 s4_tevent: Added timed event "composite_trigger": 0x7fed9c44fa30 s4_tevent: Running timer event 0x7fed9c143740 "composite_trigger" s4_tevent: Destroying timer event 0x7fed9c44fa30 "composite_trigger" Mapped to DCERPC endpoint \pipe\lsarpc added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 s4_tevent: Ending timer event 0x7fed9c143740 "composite_trigger" s4_tevent: Added timed event "connect_multi_timer": 0x7fed9c3db990 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4cfdd0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4cfdd0 s4_tevent: Destroying timer event 0x7fed9c3db990 "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 = 23080 SO_RCVBUF = 87380 SO_SNDLOWAT = 1 SO_RCVLOWAT = 1 SO_SNDTIMEO = 0 SO_RCVTIMEO = 0 TCP_QUICKACK = 1 TCP_DEFER_ACCEPT = 0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4def10 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4b08e0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4b08e0 s4_tevent: Destroying timer event 0x7fed9c4def10 "tevent_req_timedout" Starting GENSEC mechanism spnego Starting GENSEC submechanism ntlmssp negotiate: struct NEGOTIATE_MESSAGE Signature : 'NTLMSSP' MessageType : NtLmNegotiate (1) NegotiateFlags : 0x60088215 (1611170325) 1: NTLMSSP_NEGOTIATE_UNICODE 0: NTLMSSP_NEGOTIATE_OEM 1: NTLMSSP_REQUEST_TARGET 1: NTLMSSP_NEGOTIATE_SIGN 0: NTLMSSP_NEGOTIATE_SEAL 0: NTLMSSP_NEGOTIATE_DATAGRAM 0: NTLMSSP_NEGOTIATE_LM_KEY 0: NTLMSSP_NEGOTIATE_NETWARE 1: NTLMSSP_NEGOTIATE_NTLM 0: NTLMSSP_NEGOTIATE_NT_ONLY 0: NTLMSSP_ANONYMOUS 0: NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED 0: NTLMSSP_NEGOTIATE_OEM_WORKSTATION_SUPPLIED 0: NTLMSSP_NEGOTIATE_THIS_IS_LOCAL_CALL 1: NTLMSSP_NEGOTIATE_ALWAYS_SIGN 0: NTLMSSP_TARGET_TYPE_DOMAIN 0: NTLMSSP_TARGET_TYPE_SERVER 0: NTLMSSP_TARGET_TYPE_SHARE 1: NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY 0: NTLMSSP_NEGOTIATE_IDENTIFY 0: NTLMSSP_REQUEST_NON_NT_SESSION_KEY 0: NTLMSSP_NEGOTIATE_TARGET_INFO 0: NTLMSSP_NEGOTIATE_VERSION 1: NTLMSSP_NEGOTIATE_128 1: NTLMSSP_NEGOTIATE_KEY_EXCH 0: NTLMSSP_NEGOTIATE_56 DomainNameLen : 0x0008 (8) DomainNameMaxLen : 0x0008 (8) DomainName : * DomainName : 'IPADOMAIN' WorkstationLen : 0x0008 (8) WorkstationMaxLen : 0x0008 (8) Workstation : * Workstation : 'IPADOMAIN' s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c3c0c80 smb_signing_sign_pdu: sent SMB signature of [0000] 42 53 52 53 50 59 4C 20 BSRSPYL s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4b08e0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4b08e0 s4_tevent: Destroying timer event 0x7fed9c3c0c80 "tevent_req_timedout" Got challenge flags: Got NTLMSSP neg_flags=0x62898215 NTLMSSP_NEGOTIATE_UNICODE NTLMSSP_REQUEST_TARGET NTLMSSP_NEGOTIATE_SIGN NTLMSSP_NEGOTIATE_NTLM NTLMSSP_NEGOTIATE_ALWAYS_SIGN NTLMSSP_NEGOTIATE_NTLM2 NTLMSSP_NEGOTIATE_TARGET_INFO NTLMSSP_NEGOTIATE_VERSION NTLMSSP_NEGOTIATE_128 NTLMSSP_NEGOTIATE_KEY_EXCH NTLMSSP: Set final flags: Got NTLMSSP neg_flags=0x60088215 NTLMSSP_NEGOTIATE_UNICODE NTLMSSP_REQUEST_TARGET NTLMSSP_NEGOTIATE_SIGN NTLMSSP_NEGOTIATE_NTLM NTLMSSP_NEGOTIATE_ALWAYS_SIGN NTLMSSP_NEGOTIATE_NTLM2 NTLMSSP_NEGOTIATE_128 NTLMSSP_NEGOTIATE_KEY_EXCH s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4d96e0 smb_signing_sign_pdu: sent SMB signature of [0000] 42 53 52 53 50 59 4C 20 BSRSPYL s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4b08e0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4b08e0 s4_tevent: Destroying timer event 0x7fed9c4d96e0 "tevent_req_timedout" smb_signing_activate: user_session_key [0000] 49 48 D5 4C 6B BC EF 57 05 A0 A8 6D 94 DB 81 A2 IH.Lk..W ...m.... smb_signing_activate: NULL response_data smb_signing_md5: sequence number 1 smb_signing_check_pdu: seq 1: got good SMB signature of [0000] A2 2B A4 AE 75 66 A7 18 .+..uf.. s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c4c5ee0 smb_signing_md5: sequence number 2 smb_signing_sign_pdu: sent SMB signature of [0000] E1 FB 62 87 CB CF 97 FB ..b..... s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4b08e0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4b08e0 smb_signing_md5: sequence number 3 smb_signing_check_pdu: seq 3: got good SMB signature of [0000] 8B 96 23 AD 33 4C 9B D7 ..#.3L.. s4_tevent: Destroying timer event 0x7fed9c4c5ee0 "tevent_req_timedout" s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c446990 smb_signing_md5: sequence number 4 smb_signing_sign_pdu: sent SMB signature of [0000] EE 7E FA 78 DE 5A B2 61 .~.x.Z.a s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4b08e0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4b08e0 smb_signing_md5: sequence number 5 smb_signing_check_pdu: seq 5: got good SMB signature of [0000] 7E E3 DA 67 DE DB BC C0 ~..g.... s4_tevent: Destroying timer event 0x7fed9c446990 "tevent_req_timedout" num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=72, this_data=72, max_data=65535, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c3c0b40 smb_signing_md5: sequence number 6 smb_signing_sign_pdu: sent SMB signature of [0000] 27 30 57 0B BD 00 E9 C2 '0W..... s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4b08e0 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c3b9160 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4b08e0 smb_signing_md5: sequence number 7 smb_signing_check_pdu: seq 7: got good SMB signature of [0000] 72 F9 3E FB D7 51 7D BF r.>..Q}. s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4d9e80 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4d9e80 s4_tevent: Destroying timer event 0x7fed9c3c0b40 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c3b9160 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c3d7b90 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c3d7b90 s4_tevent: Destroying timer event 0x7fed9c4b0e00 "dcerpc_connect_timeout_handler" Using binding ncacn_np:ad03.ADDOMAIN.COM[,] s4_tevent: Added timed event "dcerpc_connect_timeout_handler": 0x7fed9c4cfdd0 s4_tevent: Added timed event "composite_trigger": 0x7fed9c4c5ee0 s4_tevent: Added timed event "composite_trigger": 0x7fed9c4e29f0 s4_tevent: Running timer event 0x7fed9c4c5ee0 "composite_trigger" s4_tevent: Destroying timer event 0x7fed9c4e29f0 "composite_trigger" Mapped to DCERPC endpoint \pipe\netlogon added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 added interface docker0 ip=172.17.42.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface ens192 ip=192.168.12.27 bcast=192.168.12.255 netmask=255.255.255.0 s4_tevent: Ending timer event 0x7fed9c4c5ee0 "composite_trigger" s4_tevent: Added timed event "connect_multi_timer": 0x7fed9c505f60 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c505ea0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c505ea0 s4_tevent: Destroying timer event 0x7fed9c505f60 "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 = 23080 SO_RCVBUF = 87380 SO_SNDLOWAT = 1 SO_RCVLOWAT = 1 SO_SNDTIMEO = 0 SO_RCVTIMEO = 0 TCP_QUICKACK = 1 TCP_DEFER_ACCEPT = 0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c3ed5f0 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d0920 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d0920 s4_tevent: Destroying timer event 0x7fed9c3ed5f0 "tevent_req_timedout" Starting GENSEC mechanism spnego Starting GENSEC submechanism ntlmssp negotiate: struct NEGOTIATE_MESSAGE Signature : 'NTLMSSP' MessageType : NtLmNegotiate (1) NegotiateFlags : 0x60088215 (1611170325) 1: NTLMSSP_NEGOTIATE_UNICODE 0: NTLMSSP_NEGOTIATE_OEM 1: NTLMSSP_REQUEST_TARGET 1: NTLMSSP_NEGOTIATE_SIGN 0: NTLMSSP_NEGOTIATE_SEAL 0: NTLMSSP_NEGOTIATE_DATAGRAM 0: NTLMSSP_NEGOTIATE_LM_KEY 0: NTLMSSP_NEGOTIATE_NETWARE 1: NTLMSSP_NEGOTIATE_NTLM 0: NTLMSSP_NEGOTIATE_NT_ONLY 0: NTLMSSP_ANONYMOUS 0: NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED 0: NTLMSSP_NEGOTIATE_OEM_WORKSTATION_SUPPLIED 0: NTLMSSP_NEGOTIATE_THIS_IS_LOCAL_CALL 1: NTLMSSP_NEGOTIATE_ALWAYS_SIGN 0: NTLMSSP_TARGET_TYPE_DOMAIN 0: NTLMSSP_TARGET_TYPE_SERVER 0: NTLMSSP_TARGET_TYPE_SHARE 1: NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY 0: NTLMSSP_NEGOTIATE_IDENTIFY 0: NTLMSSP_REQUEST_NON_NT_SESSION_KEY 0: NTLMSSP_NEGOTIATE_TARGET_INFO 0: NTLMSSP_NEGOTIATE_VERSION 1: NTLMSSP_NEGOTIATE_128 1: NTLMSSP_NEGOTIATE_KEY_EXCH 0: NTLMSSP_NEGOTIATE_56 DomainNameLen : 0x0008 (8) DomainNameMaxLen : 0x0008 (8) DomainName : * DomainName : 'IPADOMAIN' WorkstationLen : 0x0008 (8) WorkstationMaxLen : 0x0008 (8) Workstation : * Workstation : 'IPADOMAIN' s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c44e060 smb_signing_sign_pdu: sent SMB signature of [0000] 42 53 52 53 50 59 4C 20 BSRSPYL s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d0920 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d0920 s4_tevent: Destroying timer event 0x7fed9c44e060 "tevent_req_timedout" Got challenge flags: Got NTLMSSP neg_flags=0x62898215 NTLMSSP_NEGOTIATE_UNICODE NTLMSSP_REQUEST_TARGET NTLMSSP_NEGOTIATE_SIGN NTLMSSP_NEGOTIATE_NTLM NTLMSSP_NEGOTIATE_ALWAYS_SIGN NTLMSSP_NEGOTIATE_NTLM2 NTLMSSP_NEGOTIATE_TARGET_INFO NTLMSSP_NEGOTIATE_VERSION NTLMSSP_NEGOTIATE_128 NTLMSSP_NEGOTIATE_KEY_EXCH NTLMSSP: Set final flags: Got NTLMSSP neg_flags=0x60088215 NTLMSSP_NEGOTIATE_UNICODE NTLMSSP_REQUEST_TARGET NTLMSSP_NEGOTIATE_SIGN NTLMSSP_NEGOTIATE_NTLM NTLMSSP_NEGOTIATE_ALWAYS_SIGN NTLMSSP_NEGOTIATE_NTLM2 NTLMSSP_NEGOTIATE_128 NTLMSSP_NEGOTIATE_KEY_EXCH s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c3e5b90 smb_signing_sign_pdu: sent SMB signature of [0000] 42 53 52 53 50 59 4C 20 BSRSPYL s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d0920 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d0920 s4_tevent: Destroying timer event 0x7fed9c3e5b90 "tevent_req_timedout" smb_signing_activate: user_session_key [0000] 5D AF 08 96 5F 4B A1 72 96 B0 37 24 95 09 ED E2 ]..._K.r ..7$.... smb_signing_activate: NULL response_data smb_signing_md5: sequence number 1 smb_signing_check_pdu: seq 1: got good SMB signature of [0000] 89 B1 AB 4F 7F B0 96 34 ...O...4 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c146aa0 smb_signing_md5: sequence number 2 smb_signing_sign_pdu: sent SMB signature of [0000] 36 DB 64 3A 0B D9 0D B3 6.d:.... s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d0920 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d0920 smb_signing_md5: sequence number 3 smb_signing_check_pdu: seq 3: got good SMB signature of [0000] 3A 65 AE D7 10 E7 02 6D :e.....m s4_tevent: Destroying timer event 0x7fed9c146aa0 "tevent_req_timedout" s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c3e4480 smb_signing_md5: sequence number 4 smb_signing_sign_pdu: sent SMB signature of [0000] 8B DA CF 8F 3D 4D 6D 96 ....=Mm. s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d0920 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d0920 smb_signing_md5: sequence number 5 smb_signing_check_pdu: seq 5: got good SMB signature of [0000] F6 A8 68 C5 4C 33 90 83 ..h.L3.. s4_tevent: Destroying timer event 0x7fed9c3e4480 "tevent_req_timedout" num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=72, this_data=72, max_data=65535, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c146d30 smb_signing_md5: sequence number 6 smb_signing_sign_pdu: sent SMB signature of [0000] 84 F6 F0 B6 6C 90 F5 D6 ....l... s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d0920 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c046c40 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d0920 smb_signing_md5: sequence number 7 smb_signing_check_pdu: seq 7: got good SMB signature of [0000] CE 11 7B 20 C4 99 7C 70 ..{ ..|p s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c50a3c0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c50a3c0 s4_tevent: Destroying timer event 0x7fed9c146d30 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c046c40 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4e2b50 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4e2b50 s4_tevent: Destroying timer event 0x7fed9c4cfdd0 "dcerpc_connect_timeout_handler" netr_DsrEnumerateDomainTrusts: struct netr_DsrEnumerateDomainTrusts in: struct netr_DsrEnumerateDomainTrusts server_name : * server_name : 'ncacn_np:ad03.ADDOMAIN.COM[,]' trust_flags : 0x00000001 (1) 1: NETR_TRUST_FLAG_IN_FOREST 0: NETR_TRUST_FLAG_OUTBOUND 0: NETR_TRUST_FLAG_TREEROOT 0: NETR_TRUST_FLAG_PRIMARY 0: NETR_TRUST_FLAG_NATIVE 0: NETR_TRUST_FLAG_INBOUND 0: NETR_TRUST_FLAG_MIT_KRB5 0: NETR_TRUST_FLAG_AES rpc request data: [0000] 00 00 02 00 20 00 00 00 00 00 00 00 20 00 00 00 .... ... .... ... [0010] 6E 00 63 00 61 00 63 00 6E 00 5F 00 6E 00 70 00 n.c.a.c. n._.n.p. [0020] 3A 00 42 00 45 00 41 00 54 00 52 00 49 00 43 00 :.B.E.A. T.R.I.C. [0030] 45 00 2E 00 4C 00 49 00 42 00 45 00 52 00 4F 00 E...L.I. B.E.R.O. [0040] 2E 00 49 00 4E 00 54 00 5B 00 2C 00 5D 00 00 00 ..I.N.T. [.,.]... [0050] 01 00 00 00 .... s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c3f19c0 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fed9c3ed410 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c3f19c0 s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fed9c3f19c0 num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=108, this_data=108, max_data=4280, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 s4_tevent: Added timed event "tevent_req_timedout": 0x7fed9c50a430 smb_signing_md5: sequence number 8 smb_signing_sign_pdu: sent SMB signature of [0000] D8 50 CD 6B C3 F1 53 4F .P.k..SO s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d0920 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fed9c3f19c0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7fed9c4d0920 smb_signing_md5: sequence number 9 smb_signing_check_pdu: seq 9: got good SMB signature of [0000] FB 79 A8 62 00 8B 53 4A .y.b..SJ s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4bc450 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4bc450 s4_tevent: Destroying timer event 0x7fed9c50a430 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7fed9c3ed410 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c3e5210 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c3e5210 netr_DsrEnumerateDomainTrusts: struct netr_DsrEnumerateDomainTrusts out: struct netr_DsrEnumerateDomainTrusts trusts : * trusts: struct netr_DomainTrustList count : 0x00000001 (1) array : * array: ARRAY(1) array: struct netr_DomainTrust netbios_name : * netbios_name : 'ADDOMAIN' dns_name : * dns_name : 'ADDOMAIN.COM ' trust_flags : 0x0000001d (29) 1: NETR_TRUST_FLAG_IN_FOREST 0: NETR_TRUST_FLAG_OUTBOUND 1: NETR_TRUST_FLAG_TREEROOT 1: NETR_TRUST_FLAG_PRIMARY 1: NETR_TRUST_FLAG_NATIVE 0: NETR_TRUST_FLAG_INBOUND 0: NETR_TRUST_FLAG_MIT_KRB5 0: NETR_TRUST_FLAG_AES parent_index : 0x00000000 (0) trust_type : NETR_TRUST_TYPE_UPLEVEL (2) trust_attributes : 0x00000000 (0) 0: NETR_TRUST_ATTRIBUTE_NON_TRANSITIVE 0: NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY 0: NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN 0: NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE 0: NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION 0: NETR_TRUST_ATTRIBUTE_WITHIN_FOREST 0: NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL sid : * sid : S-1-5-21-1343024091-2000478354-725345543 guid : 6aac190b-04eb-464f-bdcc-b07e27e2d1e5 result : WERR_OK rpc reply data: [0000] 01 00 00 00 00 00 02 00 01 00 00 00 04 00 02 00 ........ ........ [0010] 08 00 02 00 1D 00 00 00 00 00 00 00 02 00 00 00 ........ ........ [0020] 00 00 00 00 0C 00 02 00 0B 19 AC 6A EB 04 4F 46 ........ ...j..OF [0030] BD CC B0 7E 27 E2 D1 E5 07 00 00 00 00 00 00 00 ...~'... ........ [0040] 07 00 00 00 4C 00 49 00 42 00 45 00 52 00 4F 00 ....L.I. B.E.R.O. [0050] 00 00 00 00 0B 00 00 00 00 00 00 00 0B 00 00 00 ........ ........ [0060] 4C 00 49 00 42 00 45 00 52 00 4F 00 2E 00 49 00 L.I.B.E. R.O...I. [0070] 4E 00 54 00 00 00 00 00 04 00 00 00 01 04 00 00 N.T..... ........ [0080] 00 00 00 05 15 00 00 00 DB EB 0C 50 92 E0 3C 77 ........ ...P.. From gjn at gjn.priv.at Fri Feb 27 10:14:34 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Fri, 27 Feb 2015 11:14:34 +0100 Subject: [Freeipa-users] getent group ipauser broken? Message-ID: <9508717.V4A1PbWrMc@techz> Hello, Have i to configure any other things, for a working /home/xxxx I can make a getent passwd xxxx, this is working on the client but I mean I have no export for groups ? with "getent group ipausers" I have no answer? also I can't make a chown -R user:ipausers what can be wrong on my setup ? This is a fresh installed centos 7 with IPA -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From abokovoy at redhat.com Fri Feb 27 10:23:32 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Feb 2015 12:23:32 +0200 Subject: [Freeipa-users] Centos 7 - ipa-server-3.3.3 AD trust trust-fetch-domains and add external group problem In-Reply-To: References: <54F02BEB.5070506@redhat.com> <54F02EC6.5090405@redhat.com> <54F0336A.7060409@redhat.com> <20150227093602.GX25455@redhat.com> <20150227095329.GZ25455@redhat.com> Message-ID: <20150227102332.GA25455@redhat.com> On Fri, 27 Feb 2015, mete bilgin wrote: >[0000] 85 A6 68 FD 0D BF 20 B8 ..h... . >s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4e2a90 >s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4e2a90 >s4_tevent: Destroying timer event 0x7fed9c0487b0 "tevent_req_timedout" >s4_tevent: Destroying timer event 0x7fed9c044ed0 "dcerpc_timeout_handler" >s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4e2760 >s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4e2760 > netr_LogonControl2Ex: struct netr_LogonControl2Ex > out: struct netr_LogonControl2Ex > query : * > query : union >netr_CONTROL_QUERY_INFORMATION(case 2) > info2 : * > info2: struct netr_NETLOGON_INFO_2 > flags : 0x00000080 (128) > 0: NETLOGON_REPLICATION_NEEDED > 0: NETLOGON_REPLICATION_IN_PROGRESS > 0: NETLOGON_FULL_SYNC_REPLICATION > 0: NETLOGON_REDO_NEEDED > 0: NETLOGON_HAS_IP > 0: NETLOGON_HAS_TIMESERV > 0: NETLOGON_DNS_UPDATE_FAILURE > 1: NETLOGON_VERIFY_STATUS_RETURNED > pdc_connection_status : WERR_NO_LOGON_SERVERS > trusted_dc_name : * > trusted_dc_name : '' > tc_connection_status : WERR_NO_LOGON_SERVERS > result : WERR_OK Here is the result -- AD DC was unable to reach IPA DC. Check your firewall and DNS records. For DNS, make sure you can resolve SRV record _ldap._tcp.IPADOMAIN.COM from AD DC console. http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Verify_DNS_configuration For firewall, see http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Firewall_configuration -- / Alexander Bokovoy From abokovoy at redhat.com Fri Feb 27 10:25:24 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Feb 2015 12:25:24 +0200 Subject: [Freeipa-users] getent group ipauser broken? In-Reply-To: <9508717.V4A1PbWrMc@techz> References: <9508717.V4A1PbWrMc@techz> Message-ID: <20150227102524.GB25455@redhat.com> On Fri, 27 Feb 2015, G?nther J. Niederwimmer wrote: >Hello, > >Have i to configure any other things, for a working /home/xxxx > >I can make a getent passwd xxxx, this is working on the client but I mean I >have no export for groups ? > >with "getent group ipausers" I have no answer? > >also I can't make a chown -R user:ipausers > >what can be wrong on my setup ? > >This is a fresh installed centos 7 with IPA Nothing wrong. Groups in IPA can have POSIX attributes or can be set without them. The latter one are used mostly for hierarchical grouping purposes. 'ipausers' is one of non-POSIX groups and therefore is not visible by POSIX tools. -- / Alexander Bokovoy From john.obaterspok at gmail.com Fri Feb 27 12:07:35 2015 From: john.obaterspok at gmail.com (John Obaterspok) Date: Fri, 27 Feb 2015 13:07:35 +0100 Subject: [Freeipa-users] F21 update fails to start dirsrv due to missing libdes Message-ID: Hello, Anyone seen this after updating to 389-ds-base-1.3.3.8-1.fc21.x86_64 Netscape Portable Runtime error -5977: /usr/lib64/dirsrv/plugins/libdes-plugin.so: cannot open shared object file: No such file or directory Could not open library "/usr/lib64/dirsrv/plugins/libdes-plugin.so" for plugin DES # rpm -ql 389-ds-base | grep libdes | wc -l 0 -- john -------------- next part -------------- An HTML attachment was scrubbed... URL: From metebilgin48 at gmail.com Fri Feb 27 12:03:57 2015 From: metebilgin48 at gmail.com (mete bilgin) Date: Fri, 27 Feb 2015 14:03:57 +0200 Subject: [Freeipa-users] Centos 7 - ipa-server-3.3.3 AD trust trust-fetch-domains and add external group problem In-Reply-To: <20150227102332.GA25455@redhat.com> References: <54F02BEB.5070506@redhat.com> <54F02EC6.5090405@redhat.com> <54F0336A.7060409@redhat.com> <20150227093602.GX25455@redhat.com> <20150227095329.GZ25455@redhat.com> <20150227102332.GA25455@redhat.com> Message-ID: 2015-02-27 12:23 GMT+02:00 Alexander Bokovoy : > On Fri, 27 Feb 2015, mete bilgin wrote: > >> [0000] 85 A6 68 FD 0D BF 20 B8 ..h... . >> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4e2a90 >> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4e2a90 >> s4_tevent: Destroying timer event 0x7fed9c0487b0 "tevent_req_timedout" >> s4_tevent: Destroying timer event 0x7fed9c044ed0 "dcerpc_timeout_handler" >> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4e2760 >> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4e2760 >> netr_LogonControl2Ex: struct netr_LogonControl2Ex >> out: struct netr_LogonControl2Ex >> query : * >> query : union >> netr_CONTROL_QUERY_INFORMATION(case 2) >> info2 : * >> info2: struct netr_NETLOGON_INFO_2 >> flags : 0x00000080 (128) >> 0: NETLOGON_REPLICATION_NEEDED >> 0: NETLOGON_REPLICATION_IN_PROGRESS >> 0: NETLOGON_FULL_SYNC_REPLICATION >> 0: NETLOGON_REDO_NEEDED >> 0: NETLOGON_HAS_IP >> 0: NETLOGON_HAS_TIMESERV >> 0: NETLOGON_DNS_UPDATE_FAILURE >> 1: NETLOGON_VERIFY_STATUS_RETURNED >> pdc_connection_status : WERR_NO_LOGON_SERVERS >> trusted_dc_name : * >> trusted_dc_name : '' >> tc_connection_status : WERR_NO_LOGON_SERVERS >> result : WERR_OK >> > Here is the result -- AD DC was unable to reach IPA DC. Check your > firewall and DNS records. > > For DNS, make sure you can resolve SRV record _ldap._tcp.IPADOMAIN.COM > from AD DC console. > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup# > Verify_DNS_configuration > > For firewall, see > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup# > Firewall_configuration > > > -- > / Alexander Bokovoy > Hi, I think get entry for replication server. That's the problem. I remove the replica on dns server. https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=538e023107ed307142ca7302ff34106c53afa932 > _ldap._tcp.ipdomin.com Server: UnKnown Address: ::1 Non-authoritative answer: _ldap._tcp.bilyoner.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = ipa02.ipadomain.com _ldap._tcp.bilyoner.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = ipa01.domain.com ipa02.ipadomain.com internet address = 172.16.50.97 ipa01.ipadomain.com internet address = 192.168.12.27 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Feb 27 12:25:32 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Feb 2015 14:25:32 +0200 Subject: [Freeipa-users] Centos 7 - ipa-server-3.3.3 AD trust trust-fetch-domains and add external group problem In-Reply-To: References: <54F02EC6.5090405@redhat.com> <54F0336A.7060409@redhat.com> <20150227093602.GX25455@redhat.com> <20150227095329.GZ25455@redhat.com> <20150227102332.GA25455@redhat.com> Message-ID: <20150227122532.GC25455@redhat.com> On Fri, 27 Feb 2015, mete bilgin wrote: >2015-02-27 12:23 GMT+02:00 Alexander Bokovoy : > >> On Fri, 27 Feb 2015, mete bilgin wrote: >> >>> [0000] 85 A6 68 FD 0D BF 20 B8 ..h... . >>> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4e2a90 >>> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4e2a90 >>> s4_tevent: Destroying timer event 0x7fed9c0487b0 "tevent_req_timedout" >>> s4_tevent: Destroying timer event 0x7fed9c044ed0 "dcerpc_timeout_handler" >>> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fed9c4e2760 >>> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fed9c4e2760 >>> netr_LogonControl2Ex: struct netr_LogonControl2Ex >>> out: struct netr_LogonControl2Ex >>> query : * >>> query : union >>> netr_CONTROL_QUERY_INFORMATION(case 2) >>> info2 : * >>> info2: struct netr_NETLOGON_INFO_2 >>> flags : 0x00000080 (128) >>> 0: NETLOGON_REPLICATION_NEEDED >>> 0: NETLOGON_REPLICATION_IN_PROGRESS >>> 0: NETLOGON_FULL_SYNC_REPLICATION >>> 0: NETLOGON_REDO_NEEDED >>> 0: NETLOGON_HAS_IP >>> 0: NETLOGON_HAS_TIMESERV >>> 0: NETLOGON_DNS_UPDATE_FAILURE >>> 1: NETLOGON_VERIFY_STATUS_RETURNED >>> pdc_connection_status : WERR_NO_LOGON_SERVERS >>> trusted_dc_name : * >>> trusted_dc_name : '' >>> tc_connection_status : WERR_NO_LOGON_SERVERS >>> result : WERR_OK >>> >> Here is the result -- AD DC was unable to reach IPA DC. Check your >> firewall and DNS records. >> >> For DNS, make sure you can resolve SRV record _ldap._tcp.IPADOMAIN.COM >> from AD DC console. >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup# >> Verify_DNS_configuration >> >> For firewall, see >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup# >> Firewall_configuration >> >> >> -- >> / Alexander Bokovoy >> >Hi, > >I think get entry for replication server. That's the problem. I remove the >replica on dns server. Yes, you can temporarily remove the entry for a replica from the SRV record. Alternative would be to run ipa-adtrust-install on that replica too. > >https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=538e023107ed307142ca7302ff34106c53afa932 > > >> _ldap._tcp.ipdomin.com >Server: UnKnown >Address: ::1 > >Non-authoritative answer: >_ldap._tcp.bilyoner.com SRV service location: > priority = 0 > weight = 100 > port = 389 > svr hostname = ipa02.ipadomain.com >_ldap._tcp.bilyoner.com SRV service location: > priority = 0 > weight = 100 > port = 389 > svr hostname = ipa01.domain.com > >ipa02.ipadomain.com internet address = 172.16.50.97 >ipa01.ipadomain.com internet address = 192.168.12.27 -- / Alexander Bokovoy From gjn at gjn.priv.at Fri Feb 27 12:37:07 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Fri, 27 Feb 2015 13:37:07 +0100 Subject: [Freeipa-users] getent group ipauser broken? In-Reply-To: <20150227102524.GB25455@redhat.com> References: <9508717.V4A1PbWrMc@techz> <20150227102524.GB25455@redhat.com> Message-ID: <9322495.y4b5FprUGP@techz> Am Freitag, 27. Februar 2015, 12:25:24 schrieb Alexander Bokovoy: > On Fri, 27 Feb 2015, G?nther J. Niederwimmer wrote: > >Hello, > > > >Have i to configure any other things, for a working /home/xxxx > > > >I can make a getent passwd xxxx, this is working on the client but I mean I > >have no export for groups ? > > > >with "getent group ipausers" I have no answer? > > > >also I can't make a chown -R user:ipausers > > > >what can be wrong on my setup ? > > > >This is a fresh installed centos 7 with IPA > > Nothing wrong. Groups in IPA can have POSIX attributes or can be set > without them. The latter one are used mostly for hierarchical grouping > purposes. > > 'ipausers' is one of non-POSIX groups and therefore is not visible by > POSIX tools. OK, Thank you I found this in a newer Documentation ? But I found no way to create a /home/xxx directory for a IPA User what is the correct way to create Users /home ?? The /home/ have 0700 root:root but I can't set /home/testuser/ I have always no permission. This is really a long way ............ -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From lkrispen at redhat.com Fri Feb 27 13:31:50 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 27 Feb 2015 14:31:50 +0100 Subject: [Freeipa-users] F21 update fails to start dirsrv due to missing libdes In-Reply-To: References: Message-ID: <54F071C6.9070500@redhat.com> libdes was replaced by libpbe, see ticket: https://fedorahosted.org/389/ticket/4746 during the postinstall of the upgrade the DES config in the dse.ldif should be changed. There have been cases where the postinstall scripts were not propeerly executed. Could you stop your DS and run: setup-ds.pl --update if it still is not corrected, try setup-ds.pl -ddd --update On 02/27/2015 01:07 PM, John Obaterspok wrote: > Hello, > > Anyone seen this after updating to 389-ds-base-1.3.3.8-1.fc21.x86_64 > > Netscape Portable Runtime error -5977: > /usr/lib64/dirsrv/plugins/libdes-plugin.so: cannot open shared object > file: No such file or directory > Could not open library "/usr/lib64/dirsrv/plugins/libdes-plugin.so" > for plugin DES > > # rpm -ql 389-ds-base | grep libdes | wc -l > 0 > > -- john > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.wells at mosaic451.com Thu Feb 26 17:38:24 2015 From: matt.wells at mosaic451.com (Matt Wells) Date: Thu, 26 Feb 2015 09:38:24 -0800 Subject: [Freeipa-users] 2-Factor and services Message-ID: Had an error on my options for the list and the replies failed to get to me. We'll see if this reply works. :) @Dmitri - Anyone coming through this service/host (OpenVPN with pam) will be required to use 2-Factor. Their normal logins at their desk are not required for 2-factor, it's ok if they use it but it's not required at all. This VPN service is as assumed, exposed to the internet. We're wanting to protect ourselves as best we can with AAA. ------------------------------- I've got many of users setup with 2-Factor and I'd like to enforce it with some services. For example. Server vpn.example.com is an openvpn servers setup to use PAM. Since he's tied to my 4.X IDM servers I can use 2-Factor with him. However I want to enforce that users from this system/service require 2-Factor. Can anyone point me in the right direction? My Google Foo is showing to be poor on this one and any guidance would be appreciated. As always thanks for taking the time to read over this. So do you want to use 2FA for some users and 1FA for others or do you want to have flexibility to use 2FA for the same user on one system and not another? Do you plan to use external tokens like RSA or you plan to use native OTP support in IPA? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From rcritten at redhat.com Fri Feb 27 14:16:25 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Feb 2015 09:16:25 -0500 Subject: [Freeipa-users] getent group ipauser broken? In-Reply-To: <9322495.y4b5FprUGP@techz> References: <9508717.V4A1PbWrMc@techz> <20150227102524.GB25455@redhat.com> <9322495.y4b5FprUGP@techz> Message-ID: <54F07C39.2080507@redhat.com> G?nther J. Niederwimmer wrote: > Am Freitag, 27. Februar 2015, 12:25:24 schrieb Alexander Bokovoy: >> On Fri, 27 Feb 2015, G?nther J. Niederwimmer wrote: >>> Hello, >>> >>> Have i to configure any other things, for a working /home/xxxx >>> >>> I can make a getent passwd xxxx, this is working on the client but I mean I >>> have no export for groups ? >>> >>> with "getent group ipausers" I have no answer? >>> >>> also I can't make a chown -R user:ipausers >>> >>> what can be wrong on my setup ? >>> >>> This is a fresh installed centos 7 with IPA >> >> Nothing wrong. Groups in IPA can have POSIX attributes or can be set >> without them. The latter one are used mostly for hierarchical grouping >> purposes. >> >> 'ipausers' is one of non-POSIX groups and therefore is not visible by >> POSIX tools. > > OK, Thank you > > I found this in a newer Documentation ? > > But I found no way to create a /home/xxx directory for a IPA User > > what is the correct way to create Users /home ?? > > The /home/ have 0700 root:root but I can't set /home/testuser/ I have always > no permission. > > This is really a long way ............ > When you run ipa-client-install you can include the --mkhomedir option which will enable it using oddjob-mkhomedir. You can use authconfig --enablemkhomedir --update add it later. rob From john.obaterspok at gmail.com Fri Feb 27 14:51:35 2015 From: john.obaterspok at gmail.com (John Obaterspok) Date: Fri, 27 Feb 2015 15:51:35 +0100 Subject: [Freeipa-users] F21 update fails to start dirsrv due to missing libdes In-Reply-To: <54F071C6.9070500@redhat.com> References: <54F071C6.9070500@redhat.com> Message-ID: "setup-ds.pl --update" corrected things for me. Thanks for the information! -- john 2015-02-27 14:31 GMT+01:00 Ludwig Krispenz : > libdes was replaced by libpbe, see ticket: > https://fedorahosted.org/389/ticket/4746 > > during the postinstall of the upgrade the DES config in the dse.ldif > should be changed. There have been cases where the postinstall scripts were > not propeerly executed. > Could you stop your DS and run: > > setup-ds.pl --update > > if it still is not corrected, try > setup-ds.pl -ddd --update > > > On 02/27/2015 01:07 PM, John Obaterspok wrote: > > Hello, > > Anyone seen this after updating to 389-ds-base-1.3.3.8-1.fc21.x86_64 > > Netscape Portable Runtime error -5977: > /usr/lib64/dirsrv/plugins/libdes-plugin.so: cannot open shared object file: > No such file or directory > Could not open library "/usr/lib64/dirsrv/plugins/libdes-plugin.so" for > plugin DES > > # rpm -ql 389-ds-base | grep libdes | wc -l > 0 > > -- john > > > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.wells at mosaic451.com Fri Feb 27 16:37:03 2015 From: matt.wells at mosaic451.com (Matt Wells) Date: Fri, 27 Feb 2015 08:37:03 -0800 Subject: [Freeipa-users] Fwd: 2-Factor and services In-Reply-To: <54EF99A9.1070701@redhat.com> References: <54EF99A9.1070701@redhat.com> Message-ID: I see how that would work but as you mentioned, I no longer have SSO. My desktops are all 3. Linux, Mac and Windows however the Windows systems talk with AD and a trust exists to facilitate those communications and SSO between the systems. It doesn't sound like this is really possible without the heavy loss of functionality. This would be an amazing option to add though. The ability to define a service and prioritize an authentication mechanism. On Thu, Feb 26, 2015 at 2:09 PM, Dmitri Pal wrote: > On 02/26/2015 12:40 PM, Matt Wells wrote: >> >> Had an error on my options for the list and the replies failed to get >> to me. We'll see if this reply works. :) >> >> @Dmitri - Anyone coming through this service/host (OpenVPN with pam) >> will be required to use 2-Factor. Their normal logins at their desk >> are not required for 2-factor, it's ok if they use it but it's not >> required at all. >> This VPN service is as assumed, exposed to the internet. We're >> wanting to protect ourselves as best we can with AAA. > > > If we just talking about managing users in IdM and having tokens for them > managed in IdM too then the recommendation is: > > - Set users to use OTP or password (set both check boxes) > - Configure VPN to use Kerberos authentication against IPA - that will force > use of 2FA with the policy above > - Configure computers at the desk to use LDAP (you loose Kerberos SSO) - > that would allow single factor with the policy above > > What are your desktops? Lunux? Mac? > Is there any AD involved? > > > > >> >> >> ------------------------------- >> I've got many of users setup with 2-Factor and I'd like to enforce it >> with some services. >> For example. >> Server vpn.example.com is an openvpn servers setup to use PAM. >> Since he's tied to my 4.X IDM servers I can use 2-Factor with him. >> However I want to enforce that users from this system/service require >> 2-Factor. >> Can anyone point me in the right direction? My Google Foo is showing >> to be poor on this one and any guidance would be appreciated. >> >> As always thanks for taking the time to read over this. >> >> >> So do you want to use 2FA for some users and 1FA for others or do you >> want to have flexibility to use 2FA for the same user on one system >> and not another? >> Do you plan to use external tokens like RSA or you plan to use native >> OTP support in IPA? >> >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project -- Matt Wells Chief Systems Architect RHCVA, RHCA #110-000-353 (702) 808-0424 matt.wells at mosaic451.com Las Vegas | Phoenix | Portland Mosaic451.com CONFIDENTIALITY NOTICE: This transmittal is a confidential communication or may otherwise be privileged. If you are not intended recipient, you are hereby notified that you have received this transmittal in error and that any review, dissemination, distribution or copying of this transmittal is strictly prohibited. If you have received this communication in error, please notify this office, and immediately delete this message and all its attachments, if any. From rmj at ast.cam.ac.uk Fri Feb 27 18:19:52 2015 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Fri, 27 Feb 2015 18:19:52 +0000 Subject: [Freeipa-users] Host aliases in freeipa Message-ID: <54F0B548.8050902@ast.cam.ac.uk> Hi I'm trying to migrate of my NIS databases to freeipa and have got to the hosts database. In NIS a typical entry is: ipaddress canonical_name [aliases...] but I don't see how to enter the ipaddress or aliases using the ipa host-* commands. Is that possible? Maybe this is supposed to be done with the ipa dns commands, but I don't want freeipa to control the dns as we have an existing external dns infrastructure to fit into. How should I configure freeipa to do host lookups for aliases like NIS does? Thanks Roderick Johnstone From simo at redhat.com Fri Feb 27 18:33:27 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 27 Feb 2015 13:33:27 -0500 Subject: [Freeipa-users] Host aliases in freeipa In-Reply-To: <54F0B548.8050902@ast.cam.ac.uk> References: <54F0B548.8050902@ast.cam.ac.uk> Message-ID: <1425062007.9346.6.camel@willson.usersys.redhat.com> On Fri, 2015-02-27 at 18:19 +0000, Roderick Johnstone wrote: > Hi > > I'm trying to migrate of my NIS databases to freeipa and have got to the > hosts database. > > In NIS a typical entry is: > ipaddress canonical_name [aliases...] > > but I don't see how to enter the ipaddress or aliases using the ipa > host-* commands. Is that possible? > > Maybe this is supposed to be done with the ipa dns commands, but I don't > want freeipa to control the dns as we have an existing external dns > infrastructure to fit into. > > How should I configure freeipa to do host lookups for aliases like NIS does? While NIS supports hosts maps, FreeIPA strongly encourages the use of DNS, as such we do not have direct means of providing or querying hosts maps. Simo. -- Simo Sorce * Red Hat, Inc * New York From rmj at ast.cam.ac.uk Fri Feb 27 18:59:10 2015 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Fri, 27 Feb 2015 18:59:10 +0000 Subject: [Freeipa-users] Host aliases in freeipa In-Reply-To: <1425062007.9346.6.camel@willson.usersys.redhat.com> References: <54F0B548.8050902@ast.cam.ac.uk> <1425062007.9346.6.camel@willson.usersys.redhat.com> Message-ID: <54F0BE7E.4000001@ast.cam.ac.uk> On 27/02/15 18:33, Simo Sorce wrote: > On Fri, 2015-02-27 at 18:19 +0000, Roderick Johnstone wrote: >> Hi >> >> I'm trying to migrate of my NIS databases to freeipa and have got to the >> hosts database. >> >> In NIS a typical entry is: >> ipaddress canonical_name [aliases...] >> >> but I don't see how to enter the ipaddress or aliases using the ipa >> host-* commands. Is that possible? >> >> Maybe this is supposed to be done with the ipa dns commands, but I don't >> want freeipa to control the dns as we have an existing external dns >> infrastructure to fit into. >> >> How should I configure freeipa to do host lookups for aliases like NIS does? > > While NIS supports hosts maps, FreeIPA strongly encourages the use of > DNS, as such we do not have direct means of providing or querying hosts > maps. > > Simo. > > ok so I have to see how we can run the freeipa servers as dns servers alongside the corporate servers for our domain. I'm not sure how to proceed since I've no idea what the issues could be. Can you give me any hints or point to any docs? Thanks Roderick From simo at redhat.com Fri Feb 27 20:04:57 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 27 Feb 2015 15:04:57 -0500 Subject: [Freeipa-users] Host aliases in freeipa In-Reply-To: <54F0BE7E.4000001@ast.cam.ac.uk> References: <54F0B548.8050902@ast.cam.ac.uk> <1425062007.9346.6.camel@willson.usersys.redhat.com> <54F0BE7E.4000001@ast.cam.ac.uk> Message-ID: <1425067497.9346.8.camel@willson.usersys.redhat.com> On Fri, 2015-02-27 at 18:59 +0000, Roderick Johnstone wrote: > On 27/02/15 18:33, Simo Sorce wrote: > > On Fri, 2015-02-27 at 18:19 +0000, Roderick Johnstone wrote: > >> Hi > >> > >> I'm trying to migrate of my NIS databases to freeipa and have got to the > >> hosts database. > >> > >> In NIS a typical entry is: > >> ipaddress canonical_name [aliases...] > >> > >> but I don't see how to enter the ipaddress or aliases using the ipa > >> host-* commands. Is that possible? > >> > >> Maybe this is supposed to be done with the ipa dns commands, but I don't > >> want freeipa to control the dns as we have an existing external dns > >> infrastructure to fit into. > >> > >> How should I configure freeipa to do host lookups for aliases like NIS does? > > > > While NIS supports hosts maps, FreeIPA strongly encourages the use of > > DNS, as such we do not have direct means of providing or querying hosts > > maps. > > > > Simo. > > > > > > > ok so I have to see how we can run the freeipa servers as dns servers > alongside the corporate servers for our domain. > > I'm not sure how to proceed since I've no idea what the issues could be. > Can you give me any hints or point to any docs? Is the problem that you cannot add entries to the corporate DNS server ? It is recommended to have a delegation or at least forwarding between name servers to avoid headaches. Simo. -- Simo Sorce * Red Hat, Inc * New York From nathan at nathanpeters.com Fri Feb 27 20:08:22 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Fri, 27 Feb 2015 12:08:22 -0800 Subject: [Freeipa-users] [Solaris 10] Cannot login through console or ssh with ipa users In-Reply-To: <54EF9A3D.60608@redhat.com> References: <6a76256421cfb199ed4a9e21658c42d4.squirrel@webmail.nathanpeters.com> <54EE3781.4040400@redhat.com> <68d55813aaa45ea0871f17210093c820.squirrel@webmail.nathanpeters.com> <54EE61A7.2020304@redhat.com> <8912f5330c977b8a1d302c62ce148fab.squirrel@webmail.nathanpeters.com> <54EF9A3D.60608@redhat.com> Message-ID: <9751bca6411559b723c106b07f69e9a7.squirrel@webmail.nathanpeters.com> > root is not an ipa managed user so it is purely your pam configuration. > I thought we were trying to figure out why your ipa users are not > handled properly. > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > I would like to thank you guys for your help in troubleshooting this. I managed to fix the issue. We had a custom jumpstart file creating our Solaris images and it made some configuration changes that broke the pam/kerberos interaction. I still don't know what exactly was the cause, but I re-installed on a Fresh Solaris 10 8/11 image and was able to get an ipa user to log in. For reference, here are the complete steps I had to take from installation of the machine to get it working. Hopefully someone else finds this useful or you can add it to your docs. This instructions assume a minimal console only Solaris install so we have to add some packages first. #pkgadd -d . SUNWbash #pkgadd -d . SUNWuiu8 #pkgadd -d . SUNWwgetr #pkgadd -d . SUNWwgetu #pkgadd -d . SUNWbind #pkgadd -d . SUNWntpr #pkgadd -d . SUNWntpu #pkgadd -d . SUNWman #pkgadd -d . SUNWdoc #pkgadd -d . SUNWtexi #pkgadd -d . SUNWsfdoc #pkgadd -d . SUNWsfman #pkgadd -d . SUNWsfinf #pkgadd -d . SUNWgcmn #pkgadd -d . SUNWsshcu #pkgadd -d . SUNWsshdr #pkgadd -d . SUNWsshdu #pkgadd -d . SUNWsshr #pkgadd -d . SUNWsshu Fix IP Setup #rm /etc/dhcp.e1000g0 #chmod u+w /etc/hosts #echo "10.21.19.17 ipaclient6-sandbox-atdev-van.ipadomain.net ipaclient6-sandbox-atdev-van loghost" >> /etc/hosts #echo "10.21.19.17 netmask 255.255.0.0" > /etc/hostname.e1000g0 #echo "ipaclient6-sandbox-atdev-van.ipadomain.net" > /etc/nodename #echo "ipadomain.net" > /etc/defaultdomain #echo "10.21.0.1" /etc/defaultrouter DNS Configuration This DNS configuration needs to be done no matter whether you used jumpstart or not. #vi /etc/resolv.conf Remove all existing lines and Set the following values domain ipadomain.net nameserver 10.21.19.20 Reboot to get the updated hostname and domainname and ip settings #reboot Enable SSH daemon #/lib/svc/method/sshd -c #svcadm enable ssh NSSwitch Configuration edit /etc/nsswitch.conf and make sure the following lines are set passwd: files ldap group: files ldap hosts: dns files Edit /etc/nsswitch.ldap and make sure the same following lines are set passwd: files ldap group: files ldap hosts: dns files Configure Client edit /etc/krb5/krb5.conf and set the following values --- snip --- [libdefaults] default_realm = IPADOMAIN.NET dns_lookup_kdc = true [realms] IPADOMAIN.NET = { kdc = ipadc1.ipadomain.net admin_server = ipadc1.ipadomain.net } [domain_realm] .ipadomain.net = IPADOMAIN.NET ipadomain.net = IPADOMAIN.NET [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log kdc_rotate = { # How often to rotate kdc.log. Logs will get rotated no more # often than the period, and less often if the KDC is not used# frequently. period = 1d # how many versions of kdc.log to keep around (kdc.log.0, kdc.log.1, ...) version = 10 } [appdefaults] kinit = { renewable = true forwardable= true } --- snip --- First, synchronize the date on the Solaris client bash-3.00# ntpdate ipadc1.ipadomain.net On the Solaris machine setup the ldap configuration # ldapclient -v init -a domainName=ipadomain.net ipadc1.ipadomain.net On the freeIPA domain controller, enroll the host [root at ipadc1 ~]# ipa host-add --force --ip-address=10.21.19.17 ipaclient6-sandbox-atdev-van.ipadomain.net On the IPA server, get the keytab and copy it to the Solaris machine #rm /tmp/solaris.keytab [root at ipadc1 tmp]# ipa-getkeytab -s ipadc1 -p host/ipaclient6-sandbox-atdev-van.ipadomain.net -k /tmp/solaris.keytab [root at ipadc1 tmp]# scp solaris.keytab root at 10.21.19.17:/etc/krb5/krb5.keytab After all this, I was able to login to my Solaris machine using one of my ipa user accounts From munna.hadoop at gmail.com Sat Feb 28 02:24:29 2015 From: munna.hadoop at gmail.com (Hadoop Solutions) Date: Sat, 28 Feb 2015 10:24:29 +0800 Subject: [Freeipa-users] Using Domain Names Message-ID: Hi, I am new to IPA and we are planning to deploy IPA one of our hadoop cluster nodes. But, i have question on IPA: 1. we are using corp DNS on all nodes, but still is it required to install IPA DNS server ? 2. Domain name will it conflicts with if any existing domain? ex: Domain name: corp.abc.com Please let me know right way to install without any conflicts with existing IPA like tools. Thanks, Shaik -------------- next part -------------- An HTML attachment was scrubbed... URL: From munna.hadoop at gmail.com Sat Feb 28 02:54:39 2015 From: munna.hadoop at gmail.com (Hadoop Solutions) Date: Sat, 28 Feb 2015 10:54:39 +0800 Subject: [Freeipa-users] Unable to Install IPA Message-ID: Hi, i am trying to install IPA on RHEL 6, but i am getting following errors while installing the IPA. Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/20]: creating certificate server user [2/20]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname sv2lxdpdsedi02.corp.equinix.com -cs_port 9445 -client_certdb_dir /tmp/tmp-ipQMeE -client_certdb_pwd XXXXXXXX -preop_pin rYjqarUHssRQtfthaFFT -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=LAB.BDP -ldap_host sv2lxdpdsedi02.corp.equinix.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=LAB.BDP -ca_subsystem_cert_subject_name CN=CA Subsystem,O=LAB.BDP -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=LAB.BDP -ca_server_cert_subject_name CN=sv2lxdpdsedi02.corp.equinix.com,O=LAB.BDP -ca_audit_signing_cert_subject_name CN=CA Audit,O=LAB.BDP -ca_sign_cert_subject_name CN=Certificate Authority,O=LAB.BDP -external false -clone false' returned non-zero exit status 255 Configuration of CA failed kindly help me to resolve this issue. Thanks, Shaik -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Sat Feb 28 03:29:15 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Feb 2015 22:29:15 -0500 Subject: [Freeipa-users] Unable to Install IPA In-Reply-To: References: Message-ID: <54F1360B.2080807@redhat.com> Hadoop Solutions wrote: > Hi, > > i am trying to install IPA on RHEL 6, but i am getting following errors > while installing the IPA. > > Configuring certificate server (pki-cad): Estimated time 3 minutes 30 > seconds > [1/20]: creating certificate server user > [2/20]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > sv2lxdpdsedi02.corp.equinix.com > -cs_port 9445 -client_certdb_dir /tmp/tmp-ipQMeE -client_certdb_pwd > XXXXXXXX -preop_pin rYjqarUHssRQtfthaFFT -domain_name IPA -admin_user > admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name > ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa > -agent_cert_subject CN=ipa-ca-agent,O=LAB.BDP -ldap_host > sv2lxdpdsedi02.corp.equinix.com > -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX > -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa > -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX > -subsystem_name pki-cad -token_name internal > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=LAB.BDP > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=LAB.BDP > -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=LAB.BDP > -ca_server_cert_subject_name CN=sv2lxdpdsedi02.corp.equinix.com > ,O=LAB.BDP > -ca_audit_signing_cert_subject_name CN=CA Audit,O=LAB.BDP > -ca_sign_cert_subject_name CN=Certificate Authority,O=LAB.BDP -external > false -clone false' returned non-zero exit status 255 > Configuration of CA failed You'll find more relevant error messages in the full /var/log/ipaserver-install.log and /var/log/pki-ca/debug rob From rcritten at redhat.com Sat Feb 28 03:33:49 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Feb 2015 22:33:49 -0500 Subject: [Freeipa-users] Using Domain Names In-Reply-To: References: Message-ID: <54F1371D.6090703@redhat.com> Hadoop Solutions wrote: > Hi, > > I am new to IPA and we are planning to deploy IPA one of our hadoop > cluster nodes. > > But, i have question on IPA: > > 1. we are using corp DNS on all nodes, but still is it required to > install IPA DNS server ? > > 2. Domain name will it conflicts with if any existing domain? > > ex: Domain name: corp.abc.com > > > Please let me know right way to install without any conflicts with > existing IPA like tools. IPA just needs a sane, available DNS server. It doesn't need to own it. There are some advantages to IPA owning the DNS server but as long as you're willing to maintain the records that IPA needs you'll be fine. If you plan to ever, maybe, even an outside chance want to integrate with an AD server via trust you'll want to pick a unique realm for IPA and a separate DNS zone (ipa.corp.example.com). Even without AD doing that it can still be a good idea. rob From munna.hadoop at gmail.com Sat Feb 28 06:01:53 2015 From: munna.hadoop at gmail.com (Hadoop Solutions) Date: Sat, 28 Feb 2015 14:01:53 +0800 Subject: [Freeipa-users] Unable to Install IPA In-Reply-To: <54F1360B.2080807@redhat.com> References: <54F1360B.2080807@redhat.com> Message-ID: Hi Rob, please find the attached log of /var/log/ipaserver-install.log kindly let me know the solution for this.. Thanks, Shaik On 28 February 2015 at 11:29, Rob Crittenden wrote: > Hadoop Solutions wrote: > > Hi, > > > > i am trying to install IPA on RHEL 6, but i am getting following errors > > while installing the IPA. > > > > Configuring certificate server (pki-cad): Estimated time 3 minutes 30 > > seconds > > [1/20]: creating certificate server user > > [2/20]: configuring certificate server instance > > ipa : CRITICAL failed to configure ca instance Command > > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > > sv2lxdpdsedi02.corp.equinix.com > > -cs_port 9445 -client_certdb_dir /tmp/tmp-ipQMeE -client_certdb_pwd > > XXXXXXXX -preop_pin rYjqarUHssRQtfthaFFT -domain_name IPA -admin_user > > admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name > > ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa > > -agent_cert_subject CN=ipa-ca-agent,O=LAB.BDP -ldap_host > > sv2lxdpdsedi02.corp.equinix.com > > -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX > > -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa > > -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX > > -subsystem_name pki-cad -token_name internal > > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=LAB.BDP > > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=LAB.BDP > > -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=LAB.BDP > > -ca_server_cert_subject_name CN=sv2lxdpdsedi02.corp.equinix.com > > ,O=LAB.BDP > > -ca_audit_signing_cert_subject_name CN=CA Audit,O=LAB.BDP > > -ca_sign_cert_subject_name CN=Certificate Authority,O=LAB.BDP -external > > false -clone false' returned non-zero exit status 255 > > Configuration of CA failed > > You'll find more relevant error messages in the full > /var/log/ipaserver-install.log and /var/log/pki-ca/debug > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa.log Type: application/octet-stream Size: 31299 bytes Desc: not available URL: From rcritten at redhat.com Sat Feb 28 06:18:06 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 28 Feb 2015 01:18:06 -0500 Subject: [Freeipa-users] Unable to Install IPA In-Reply-To: References: <54F1360B.2080807@redhat.com> Message-ID: <54F15D9E.10806@redhat.com> Hadoop Solutions wrote: > Hi Rob, > > please find the attached log of /var/log/ipaserver-install.log > > kindly let me know the solution for this.. Can you see if you have any SElinux failures? # ausearch -m AVC -ts recent I see some SELinux errors in the log. Not sure if this is it or not but for some reason the dogtag SELinux policy doesn't always install correctly. The fix seems to be to re-install the pki-selinux package. You'll also need to run pkiremove manually after running ipa-server-install --uninstall. It doesn't always record the fact that a service install is attempted and fails. # pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca --force rob > > Thanks, > Shaik > > On 28 February 2015 at 11:29, Rob Crittenden > wrote: > > Hadoop Solutions wrote: > > Hi, > > > > i am trying to install IPA on RHEL 6, but i am getting following errors > > while installing the IPA. > > > > Configuring certificate server (pki-cad): Estimated time 3 minutes 30 > > seconds > > [1/20]: creating certificate server user > > [2/20]: configuring certificate server instance > > ipa : CRITICAL failed to configure ca instance Command > > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > > sv2lxdpdsedi02.corp.equinix.com > > > > -cs_port 9445 -client_certdb_dir /tmp/tmp-ipQMeE -client_certdb_pwd > > XXXXXXXX -preop_pin rYjqarUHssRQtfthaFFT -domain_name IPA -admin_user > > admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name > > ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa > > -agent_cert_subject CN=ipa-ca-agent,O=LAB.BDP -ldap_host > > sv2lxdpdsedi02.corp.equinix.com > > > > -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX > > -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa > > -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX > > -subsystem_name pki-cad -token_name internal > > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=LAB.BDP > > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=LAB.BDP > > -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=LAB.BDP > > -ca_server_cert_subject_name CN=sv2lxdpdsedi02.corp.equinix.com > > ,O=LAB.BDP > > -ca_audit_signing_cert_subject_name CN=CA Audit,O=LAB.BDP > > -ca_sign_cert_subject_name CN=Certificate Authority,O=LAB.BDP -external > > false -clone false' returned non-zero exit status 255 > > Configuration of CA failed > > You'll find more relevant error messages in the full > /var/log/ipaserver-install.log and /var/log/pki-ca/debug > > rob > > From munna.hadoop at gmail.com Sat Feb 28 08:49:01 2015 From: munna.hadoop at gmail.com (Hadoop Solutions) Date: Sat, 28 Feb 2015 16:49:01 +0800 Subject: [Freeipa-users] Unable to Install IPA In-Reply-To: <54F15D9E.10806@redhat.com> References: <54F1360B.2080807@redhat.com> <54F15D9E.10806@redhat.com> Message-ID: Hi Rob, In this node we have disabled SELinux. Is it cusing this error??? Thanks, Shaik On 28 February 2015 at 14:18, Rob Crittenden wrote: > Hadoop Solutions wrote: > > Hi Rob, > > > > please find the attached log of /var/log/ipaserver-install.log > > > > kindly let me know the solution for this.. > > Can you see if you have any SElinux failures? > > # ausearch -m AVC -ts recent > > I see some SELinux errors in the log. Not sure if this is it or not but > for some reason the dogtag SELinux policy doesn't always install > correctly. The fix seems to be to re-install the pki-selinux package. > > You'll also need to run pkiremove manually after running > ipa-server-install --uninstall. It doesn't always record the fact that a > service install is attempted and fails. > > # pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca --force > > rob > > > > > Thanks, > > Shaik > > > > On 28 February 2015 at 11:29, Rob Crittenden > > wrote: > > > > Hadoop Solutions wrote: > > > Hi, > > > > > > i am trying to install IPA on RHEL 6, but i am getting following > errors > > > while installing the IPA. > > > > > > Configuring certificate server (pki-cad): Estimated time 3 minutes > 30 > > > seconds > > > [1/20]: creating certificate server user > > > [2/20]: configuring certificate server instance > > > ipa : CRITICAL failed to configure ca instance Command > > > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > > > sv2lxdpdsedi02.corp.equinix.com > > > > > > > -cs_port 9445 -client_certdb_dir /tmp/tmp-ipQMeE -client_certdb_pwd > > > XXXXXXXX -preop_pin rYjqarUHssRQtfthaFFT -domain_name IPA > -admin_user > > > admin -admin_email root at localhost -admin_password XXXXXXXX > -agent_name > > > ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa > > > -agent_cert_subject CN=ipa-ca-agent,O=LAB.BDP -ldap_host > > > sv2lxdpdsedi02.corp.equinix.com > > > > > > > -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password > XXXXXXXX > > > -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa > > > -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX > > > -subsystem_name pki-cad -token_name internal > > > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=LAB.BDP > > > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=LAB.BDP > > > -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=LAB.BDP > > > -ca_server_cert_subject_name CN=sv2lxdpdsedi02.corp.equinix.com < > http://sv2lxdpdsedi02.corp.equinix.com> > > > ,O=LAB.BDP > > > -ca_audit_signing_cert_subject_name CN=CA Audit,O=LAB.BDP > > > -ca_sign_cert_subject_name CN=Certificate Authority,O=LAB.BDP > -external > > > false -clone false' returned non-zero exit status 255 > > > Configuration of CA failed > > > > You'll find more relevant error messages in the full > > /var/log/ipaserver-install.log and /var/log/pki-ca/debug > > > > rob > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Sat Feb 28 19:07:20 2015 From: janellenicole80 at gmail.com (Janelle) Date: Sat, 28 Feb 2015 11:07:20 -0800 Subject: [Freeipa-users] issues with secondary groups? (sssd) Message-ID: <54F211E8.9090407@gmail.com> Hello, I was wondering - I have searched around and seen a few questions and solutions, but nothing I try is fixing my environment. Things have been working quite well with IPA 4.0.5, simple things with auth and logins - some with full ipa-client-install configured, others just using LDAP and that is where the strangeness comes from. with full IPA client integration, secondary groups work just find, as do base commands like "id" and "getent". However, the "ldap" users, never show the secondary group for their uid? Any pointers you might suggest? I have tried the sssd.conf of "ldap_group_member = uniqeMember" - no change. a simple secondary group is defined: dn: cn=web_users,cn=groups,cn=accounts,dc=example,dc=com cn: web_users objectClass: ipaobject objectClass: extensibleobject objectClass: top objectClass: ipausergroup objectClass: posixgroup objectClass: groupofnames objectClass: nestedgroup memberUid: user1 memberUid: user2 memberUid: user3 memberUid: user4 memberUid: user5 member: uid=user1,cn=users,cn=accounts,dc=example,dc=com member: uid=user2,cn=users,cn=accounts,dc=example,dc=com member: uid=user3,cn=users,cn=accounts,dc=example,dc=com member: uid=user4,cn=users,cn=accounts,dc=example,dc=com member: uid=user5,cn=users,cn=accounts,dc=example,dc=com and yet with debug_level = 7 -- sssd still says: [sdap_process_ghost_members] (0x0400): Group has 0 members and "id" or "getent" of any of user1..5 just returns the primary GID. Any ideas? Tips? What else might you want to see? ~J